How to Fix the WordPress Login Redirect Loop

Quick fix: delete cookies for the site, open the exact canonical HTTPS login URL, and try again in a private window. If the loop remains, verify that WP_HOME, WP_SITEURL, database home/siteurl, HTTPS and proxy settings all describe the same public site.

A login loop is usually a cookie or URL consistency problem—not an incorrect password. Wrong credentials normally produce a visible authentication error.

Confirm the symptom

Open browser developer tools and keep the Network panel visible while submitting /wp-login.php. Look for:

• repeated redirects between HTTP and HTTPS;
• redirects between www and non-www;
• a successful login POST followed by another login page;
• Set-Cookie headers that the browser rejects;
• cached 200 login responses;
• ERR_TOO_MANY_REDIRECTS before the form appears.

Test one browser only after clearing its site data, then compare a private window. This separates browser state from server configuration.

Clear cookies for the exact domain

Remove cookies for both domain variants if they were used:

example.com
www.example.com

Then visit one canonical URL directly:

https://example.com/wp-login.php

WordPress uses test and authentication cookies to manage login. Its official login troubleshooting documentation recommends checking cookies, site URLs, plugins and caching for redirect loops.

Check WordPress Address and Site Address

With WP-CLI:

wp option get home
wp option get siteurl

Both normally use the intended scheme and hostname. They can differ when WordPress core intentionally lives in a subdirectory, but that requires a documented setup.

Check wp-config.php for overrides:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

If constants exist, they override values shown in the database. Correct the authoritative source; do not repeatedly edit both without understanding the deployment.

Avoid changing URLs through raw SQL unless you have a database backup and understand serialized data. WP-CLI is safer for simple option checks.

Make HTTPS consistent

The browser, CDN/reverse proxy, web server and WordPress must agree that the public request is HTTPS. A common loop is:

CDN sends HTTPS to visitor
origin sees HTTP and redirects to HTTPS
proxy repeats the HTTP origin request

Use the proxy provider’s recommended WordPress configuration. Do not trust arbitrary forwarded headers from the public internet; configure trusted proxies at the server/application layer.

If FORCE_SSL_ADMIN is enabled, verify the origin and proxy arrangement. WordPress’s HTTPS administration guide notes that reverse-proxy SSL misconfiguration can create an infinite loop.

Exclude login and admin from page cache

Full-page caches should bypass:

/wp-login.php
/wp-admin/*

and responses for authenticated cookies. Check plugin, host and CDN layers; clearing only the browser cache is not enough.

After updating rules, purge the affected cache and test with response headers. Do not disable the entire CDN permanently if one bypass rule solves the problem.

Disable authentication and security plugins

If the loop began after a plugin update or SSO/security change, disable the suspected plugin through WP-CLI:

wp plugin deactivate plugin-name --skip-plugins --skip-themes

Without SSH, rename its directory through SFTP. If no plugin is obvious, use How to Disable WordPress Plugins Without Admin Access.

Check must-use plugins and host drop-ins too; renaming the normal plugins directory does not disable them.

Check custom cookie constants

Search wp-config.php for:

COOKIE_DOMAIN
COOKIEPATH
SITECOOKIEPATH
ADMIN_COOKIE_PATH

Most sites do not need custom values. A copied staging configuration can set cookies for the wrong hostname or path. Back up the file and remove/correct only values you understand.

Verify the repair

Sign in, navigate through several wp-admin screens, leave the session idle briefly, and refresh. Test logout and password reset. Confirm the browser stores wordpress_logged_in_* and secure authentication cookies for the correct host.

If every user is forced out repeatedly rather than only looping at login, investigate server time, authentication salts, database/session changes and security-plugin events. Do not rotate salts casually during diagnosis because doing so intentionally invalidates every session.