WordPress Admin Login Redirect Loop After an SSL Change

The Problem

A WordPress admin login redirect loop after an SSL or proxy change can make correct credentials look broken. The login form accepts the username and password, then sends the browser back to wp-login.php, the admin dashboard, or a browser "too many redirects" error because WordPress, the host, CDN, or proxy disagrees about the correct protocol or login URL.

This is usually a routing and cookie problem, not proof that the password or WordPress core is broken. Preserve the current redirect chain before changing passwords, reinstalling WordPress, or disabling unrelated plugins.

First Checks Before You Change Anything

• Write down the last SSL, CDN, proxy, host, site URL, redirect, cache, or security change before the loop appeared.
• Check the same URL in a private browser window and from another device so you can separate browser cookies from server behavior.
• Capture the redirect chain with browser developer tools or a command-line request before editing rules.
• Compare the visible login URL with the expected WordPress Address and Site Address values.
• Temporarily disable CDN page rules, host redirects, or security redirects only in a controlled way and record each change.
• Use staging or a maintenance window before broad plugin deactivation on a revenue-generating site.

How to Fix It Manually

1. Clear site cookies and confirm the login page works in a private browser window.
2. Compare WP_HOME and WP_SITEURL with the home and siteurl values in the database.
3. Check whether the CDN, host, Apache, Nginx, or security plugin is forcing HTTPS in a different layer than WordPress expects.
4. If WordPress is behind a reverse proxy, confirm the proxy sends the correct X-Forwarded-Proto header and that WordPress recognizes HTTPS.
5. Use FORCE_SSL_ADMIN only when SSL is correctly configured on the server or proxy path.
6. Exclude wp-login.php, wp-admin, admin-post.php, and cookie-based pages from full-page cache.
7. Temporarily remove new redirect rules, then add them back one layer at a time.

After each step, retest the exact symptom that started the investigation. If a WordPress admin login redirect loop disappears, stop and document the cause before adding other changes. If it remains, reverse any temporary change that did not help so the site does not accumulate accidental workarounds.

How WPlura Helps

Web Plura Diagnostics helps after you regain wp-admin access or on a staging copy. It does not automatically fix SSL redirects, but it can document the surrounding site health, URL alignment, cache signals, front-end response, REST response, hosting, update risk, and support-handoff context.

Confirm the Redirect Loop

A login loop is not the same as a rejected password, a blank admin screen, or an account lockout. Confirm that the browser is being redirected between URLs before you change credentials.

• The login form accepts credentials but returns to wp-login.php or the admin dashboard.
• The browser reports too many redirects after an HTTPS, CDN, proxy, host, or site URL change.
• The redirect chain alternates between http and https or between www and non-www versions.
• Only logged-in pages loop, while the public site may still load normally.
• Clearing cookies changes the symptom briefly, but the loop returns when the site sets a new login cookie.

Likely Causes

The cause is usually one of a few mismatched layers. Work from the redirect chain so you know which layer is sending the browser away.

• WP_HOME, WP_SITEURL, home, and siteurl do not agree on protocol, host, or subdirectory.
• FORCE_SSL_ADMIN is enabled before SSL or the reverse-proxy HTTPS header is correctly configured.
• A reverse proxy terminates SSL but WordPress thinks the request is still plain HTTP.
• A CDN, host, security plugin, .htaccess rule, or Nginx rule redirects the same request WordPress is also redirecting.
• Full-page cache serves logged-in or login responses that should never be cached.
• Cookie domain, path, SameSite, or mixed host settings prevent the admin cookie from matching the final URL.

Use Diagnostics After Access Returns

Use Diagnostics after the loop is fixed enough to open wp-admin, or run it on a staging copy that reproduces the stack. The goal is to document the surrounding risks so the same SSL, proxy, cache, or update issue is easier to prevent.

1. Install the free Web Plura Diagnostics plugin from WordPress.org, activate it, and open Web Plura Diagnostics in wp-admin.
2. Run Diagnostics before making another live change so you have a local view of Site Health-style signals, cache hints, URL alignment, REST and front-end response, PHP limits, cron pressure, update risk, and email readiness.
3. Start with Fix First items and use the problem, impact, owner, urgency, and next-action fields to decide whether the follow-up belongs to the site admin, developer, host, CDN provider, or security vendor.
4. Use the support-safe snapshot, JSON export, or CSV export when you need to send concise evidence without copying private logs into email.
5. After the SSL or redirect fix, rerun the diagnostic review and keep the before/after result with your maintenance notes.
6. Use the WordPress.org plugin page as the installation reference: download the free plugin on WordPress.org
7. Use the WPlura product page for product details and support context: WPlura product details
8. Keep the final decision human-owned. Diagnostics can organize local evidence, but it should not replace backups, staging, hosting support, or developer review when the issue is business-critical.

The free WordPress.org plugin is the primary CTA for this workflow: download the free plugin on WordPress.org. For broader product information, use WPlura. Keep product usage practical: install, activate, run the local check, review findings, export or document the result, then continue with the manual fix described in this guide.

Document the URL Stack

Redirect loops often return when another admin changes CDN mode, certificate settings, proxy headers, or a WordPress URL value without knowing how the site is layered. Write down the final working stack.

• Record the final WordPress Address and Site Address values.
• Record whether WP_HOME, WP_SITEURL, or FORCE_SSL_ADMIN is defined in wp-config.php.
• Record where HTTPS is enforced: WordPress, web server, host panel, CDN, security plugin, or load balancer.
• Record proxy headers such as X-Forwarded-Proto when SSL terminates before WordPress.
• Record cache exclusions for wp-login.php, wp-admin, admin-post.php, admin-ajax.php, and logged-in cookies.

Prevent the Same Issue From Returning

• Keep a short change log for plugin updates, theme edits, PHP changes, SSL changes, redirects, and hosting moves.
• After SSL or CDN changes, test wp-login.php, wp-admin, a logged-in admin page, REST response, and the public homepage.
• Keep login and admin paths excluded from full-page cache and edge cache.
• Avoid enforcing HTTPS in multiple layers unless the ownership and order are documented.
• Test risky fixes on staging whenever the site handles orders, leads, memberships, or client traffic.
• Keep backups and restore instructions ready before editing .htaccess, wp-config.php, theme files, or plugin folders.
• Review the same issue again after the immediate fix so the underlying cause is not left waiting for the next update.

Good troubleshooting leaves the site easier to support next time. Keep the final fix, the source of the problem, the rollback option, and the owner of the setting in one short note that another admin can understand later.

Related WPlura Plugin Help

If an admin login redirect loop starts after an SSL, CDN, proxy, cache, or site URL change, finish the redirect-chain and URL-stack checks first. Then use Web Plura Diagnostics for a local site health and handoff review. Start with the free WordPress.org plugin download: download the free plugin on WordPress.org. Product details: WPlura product details. For teams that need recurring comparison, connected reports, alerts, or portfolio oversight, the Pro purchase and private download path starts here: WPlura Pro purchase and private download.

1. Install and activate the free Web Plura Diagnostics plugin from WordPress.org after access is restored or on a staging copy.
2. Run the diagnostic review before making another live change so you have one local snapshot of site health, cache, front-end response, REST response, hosting, update risk, and ownership clues.
3. Start with Fix First items and decide whether the next action belongs to the site admin, developer, host, CDN provider, DNS provider, or security vendor.
4. Use a support-safe snapshot, JSON export, or CSV export when you need to share concise evidence with a developer or hosting support team.
5. After the manual fix, run the same check again and keep the before and after notes with the site maintenance record.

References

Frequently Asked Questions