Fixing the WordPress Login Redirect Loop

You type the right user name and password, press Log In, and land back on the login form with no error. Or the browser gives up with "too many redirects" before the form appears at all. Both get called the WordPress login redirect loop, and they are different faults. In the first, the login succeeds but the browser never presents a valid cookie afterwards. In the second, two parts of the stack disagree about the site's address or about HTTPS, and they bounce the browser between them.

Work out which one you have, then go through the checks below. They run from the browser outward to the server, so the cheapest ones come first.

Two kinds of WordPress login redirect loop

The form keeps coming back. Look at the address bar after you submit. If it reads wp-login.php?redirect_to=...&reauth=1, WordPress accepted the password, set its login cookies and sent you to /wp-admin/. There it found no valid cookie and returned you to the form. The reauth=1 part is the sign. Something stops the cookie from being stored or sent back: the browser, a mismatch between the site's two addresses, a cached copy of the login page, or a plugin.

The browser stops with a redirect error. Chrome shows ERR_TOO_MANY_REDIRECTS, and Firefox says the page is not redirecting properly. No form is involved. The server answers every request with another redirect, usually between http and https or between the www and bare versions of the domain.

You can watch the second kind from a terminal. Each response carries a Location header, and in a loop it either repeats or alternates between two addresses:

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

Rule out the browser and its cookies

Open a private window, or a different browser, and log in there. If that works, the site is fine and your normal browser holds stale cookies. Delete the cookies for this domain only, and switch off privacy or ad-blocking extensions for the site, since some of them block cookies.

Read any message on the login form closely. "Cookies are blocked or not supported by your browser" means the test cookie WordPress sets when the form loads did not come back. "Cookies are blocked due to unexpected output" is a server-side problem with a browser-side name: a PHP file printed something before WordPress could send its headers, so no cookie could be set. The cause is usually a blank line or stray characters before the opening <?php in wp-config.php, in a plugin or in the theme's functions.php, most often left by a recent hand edit.

Compare the two site addresses

WordPress stores two URLs in its options table. siteurl is where the WordPress files live, and home is the address visitors use. Login cookies are named and scoped from these values. If one says http and the other https, or one has www and the other does not, a cookie set at one address is never sent to the other, and you loop.

Export the database before you change either value. Then, with WP-CLI:

wp db export before-url-fix.sql
wp option get siteurl
wp option get home
wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Use the exact scheme and host that visitors should see, with no trailing slash. Without SSH, download a copy of wp-config.php, then set both values in the file, where they override the database:

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

This is a quick, reversible test. While the constants are present, the two fields under Settings > General are greyed out. The wp-config.php reference documents both.

While the file is open, look for values left over from a migration or a staging copy: an old domain in WP_HOME, WP_SITEURL or COOKIE_DOMAIN. A COOKIE_DOMAIN that does not match the current domain makes the browser reject every login cookie. Last, make sure any redirect at the server or CDN agrees with these addresses. If WordPress says the site has no www and a server rule adds it, the two will trade redirects forever.

Fix HTTPS behind a proxy, CDN or load balancer

When a proxy in front of the site handles HTTPS and passes requests to the web server over plain HTTP, PHP sees an HTTP request. WordPress, configured with an https address, redirects to HTTPS. The proxy forwards that as HTTP again, and the cycle never ends.

The best fix is on the proxy. If your CDN offers a mode that encrypts the visitor's side only, that mode is the classic cause. Install a certificate on the origin server and switch the CDN to encrypt the whole path.

Where the proxy must talk HTTP to the origin, tell WordPress what the visitor used. Proxies report it in the X-Forwarded-Proto header. Add this to wp-config.php, above the line that loads wp-settings.php:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

This follows the handbook section on HTTPS behind a reverse proxy. Use it only when all traffic reaches the server through the proxy, because a visitor who connects directly can send that header too. Then remove any "force SSL" plugin that adds its own redirect on top. Our article on HTTPS, HSTS and security headers covers the rest of that setup.

Reset .htaccess and switch off plugins that touch login

Download a copy of .htaccess, rename the file on the server and try to log in. wp-login.php is a real file, so it works without rewrite rules. If the loop is gone, open Settings > Permalinks, press Save Changes to write a clean file, and add your own rules back one group at a time. The usual finding is two rules that each force HTTPS or www in a slightly different way.

Next, plugins. You do not need to disable everything. Four kinds change how login behaves: security plugins that move or lock the login page, login and logout redirect plugins, membership plugins, and SSL helpers. Over SFTP, add .disabled to the folder names of those plugins inside wp-content/plugins and try again. If a must-use plugin from your host handles single sign-on, ask the host about it before touching it.

Custom code deserves the same suspicion. A snippet in functions.php that sends non-administrators away from /wp-admin/ will loop if it also catches the login request. If only some roles are affected, this is almost certainly the cause, not cookies.

Keep caches away from the login page

The login screen and the dashboard must never be served from a cache. When a page cache or CDN stores wp-login.php, every visitor receives the same stale form, and the cookies the server tries to set can be stripped on the way out. Check three rules in whichever layer caches full pages:

• /wp-login.php and everything under /wp-admin/ are excluded from caching.
• Requests carrying a cookie whose name starts with wordpress_logged_in_ bypass the cache.
• Set-Cookie headers are not removed from responses on those paths.

Cache plugins do this by default. The trouble comes from server-level caches configured by hand and from a CDN rule that caches everything. Purge after you change the rules. If the site uses a persistent object cache and you edited the addresses directly in the database, run wp cache flush as well, because the old values may still be held in memory. More on the layers in WordPress caching explained.

Where to stop and ask for help

Cookies, the two addresses and the plugin test are within reach of most site owners, and they resolve the majority of cases. Ask for help when the site sits behind a load balancer or CDN whose configuration you do not control, when it is a multisite network with mapped domains, or when the loop began after a move and old addresses are scattered through the database. That last case needs a careful search and replace, which is part of a proper WordPress migration. For everything else, including the audit of redirect rules that have piled up over the years, our WordPress maintenance service is the place to start.

Frequently asked questions

Why does the loop affect only some users?

Because something redirects by role. Membership, course and store plugins keep customers and students out of the dashboard on purpose. WooCommerce, for example, sends customers to the My Account page. A loop appears when a second plugin or snippet redirects the same users somewhere else.

I changed the site address and now the login page will not load. How do I undo it?

Define WP_HOME and WP_SITEURL in wp-config.php with the correct address. They take priority over the values saved in the database, so the site comes back at once, and you can then correct the stored values.

Can I force every user to log in again?

Yes. Replacing the authentication keys and salts in wp-config.php, by hand or with wp config shuffle-salts, invalidates every existing login cookie. It is a useful last step when cookies issued under the old settings keep causing trouble.

Is a redirect loop a sign that the site was hacked?

Usually not. It is a configuration fault in nearly every case. Be concerned if the redirects lead to a domain that is not yours, or if .htaccess contains rules nobody on your team added.