WordPress login redirect loop: why it happens

A WordPress login redirect loop happens when authentication succeeds but the session cookie never makes it back to the server. This article explains the mechanism behind the loop, the configurations that cause it, and what it is not, so you land on the right fix instead of guessing.

A login redirect loop is one of those symptoms that looks the same from the outside but can have very different causes underneath. You submit your password, the login succeeds on the server side, and a fraction of a second later you are staring at wp-login.php again. No "wrong password" message. Nothing broken in the browser. Just a quiet bounce back to the start. Understanding why that happens is the difference between blindly toggling plugins for an hour and walking straight to the one setting that is wrong.

What a login redirect loop actually is

A login redirect loop is a state where WordPress accepts your credentials, issues the authentication cookies, redirects you toward wp-admin/, and then the very next request is treated as anonymous and bounces you back to wp-login.php. The credential check worked. The loop is not about whether you know your password. It is about whether the browser and the server can agree on the cookie that proves you just logged in.

That single detail is the most important thing to internalise. Every fix in this area targets one specific reason the cookie round-trip broke, and if you do not know which reason applies, every fix looks equally plausible.

How WordPress keeps you logged in

When you POST your credentials to wp-login.php, WordPress validates them and then calls wp_set_auth_cookie(). That function writes three separate cookies into the response:

  • wordpress_[hash] (the auth cookie), scoped to /wp-admin/ and /wp-content/plugins/ via ADMIN_COOKIE_PATH and PLUGINS_COOKIE_PATH.
  • wordpress_sec_[hash] (the same auth cookie, but the secure variant), written when the request is over HTTPS. This is the SECURE_AUTH_COOKIE name.
  • wordpress_logged_in_[hash] (the LOGGED_IN_COOKIE), scoped to the whole site via COOKIEPATH, used for everything outside the admin area.

Every one of those cookies uses the COOKIE_DOMAIN constant as its domain attribute, as documented in the wp-config reference. If you do not set COOKIE_DOMAIN yourself, WordPress leaves the domain attribute empty, which means "whatever host the browser just talked to". That detail matters for the rest of this article.

After setting the cookies, WordPress issues a 302 redirect to wp-admin/. The browser follows the redirect and sends back whatever cookies match the destination's host and path. On the next page load, WordPress looks for the auth cookie with wp_validate_auth_cookie(). If it is there and valid, you see the dashboard. If it is missing, you see the login screen again.

Why the loop forms

The loop is the direct consequence of the step above failing. WordPress does not know that it just set cookies for your browser a second ago. It only knows what the current request looks like, and the current request looks like an anonymous visit. So it sends you to wp-login.php, which sees that you submitted credentials (you did, a moment ago) and redirects you to the dashboard, which again looks anonymous, which redirects you to wp-login.php, and so on.

Your browser eventually gives up and shows ERR_TOO_MANY_REDIRECTS, or it silently lands you on the login page without an error at all. The server is not misbehaving. It is doing exactly what it was told to do with the information it has.

Four configuration mistakes account for the overwhelming majority of WordPress login redirect loops in my experience.

WP_HOME and WP_SITEURL do not match the URL the browser actually uses. The auth cookies are written for the hostname WordPress thinks it is. If WP_HOME is https://example.com but the user lands on https://www.example.com/wp-login.php, the cookie is set for example.com and the browser sends the next request to www.example.com, where it does not send the cookie back. Same problem in reverse: http:// in the database, https:// in the browser. Very common right after an HTTPS migration or a domain move.

COOKIE_DOMAIN is hard-coded to a domain that does not match. Some security hardening guides tell you to set COOKIE_DOMAIN explicitly. If you copy a stale value during a migration, or if the site has been moved to a new host without updating wp-config.php, the domain attribute on the cookie no longer matches the real hostname and the browser drops the cookie on the next request.

A multisite install is sharing cookies across subdomains incorrectly. Multisite with domain mapping needs COOKIE_DOMAIN at the default empty value so each site writes cookies for its own host. A forced COOKIE_DOMAIN across subsites breaks the round-trip for every site except the one that matches the hard-coded value.

A reverse proxy is rewriting the Host header or dropping the HTTPS scheme. Cloudflare, nginx in front of Apache, and most load balancers terminate TLS and proxy plain HTTP to the origin. If they forget to send X-Forwarded-Proto: https, WordPress believes the request is HTTP and writes the non-secure wordpress_[hash] cookie when it should have written wordpress_sec_[hash]. The browser then tries to send the secure cookie back over HTTPS, and the mismatch breaks validation. If the proxy also rewrites Host, the domain attribute can end up wrong in the same way as the first case above.

What a login redirect loop is NOT

Most of the wasted time I see on this problem comes from confusing it with adjacent symptoms that have completely different fixes.

  • It is not ERR_TOO_MANY_REDIRECTS on the front end of your site. That error is a browser-level redirect loop triggered by HTTPS or www canonicalisation, and it affects visitors, not just logged-in users. If the front end itself is unreachable and cycling between URLs, read Too Many Redirects in WordPress instead. The login redirect loop only happens after credentials are submitted and only involves wp-login.php and wp-admin/.
  • It is not a password problem. When the password is wrong, WordPress shows an explicit error on the login screen ("ERROR: The password you entered is incorrect"). A redirect loop means authentication succeeded; a password error means it did not. If the login form is rejecting you with a message, read why you cannot log in to WordPress and follow the "account" branch.
  • It is not the "cookies are blocked" error. That error is a separate safety interlock where WordPress places a short-lived probe cookie on the login page and refuses to proceed if the probe does not come back. It fails before authentication, not after. Different symptom, different mechanism, different fix. Read cookies are blocked or not supported in WordPress if you see that message on the login screen.
  • It is not a permissions problem. If you reach the dashboard and then see "Sorry, you are not allowed to access this page", the login itself worked. That is a capability check, not a session check, and the fix has nothing to do with cookies.

Where to go next

If you recognise the symptom and want the step-by-step fix, the troubleshooting variant of this article lives under errors: login redirect loop in WordPress walks through each cause in diagnostic order with verification checks. If the dashboard loads partially and then stalls instead of bouncing you straight back to login, that is a different failure and is covered in WordPress admin stuck loading after login.

Locked out of wp-admin too often?

Login and access issues usually come down to changes, conflicts or security rules. WordPress maintenance reduces surprises with controlled updates and checks.

See WordPress maintenance

  1. Why you cannot log in to WordPress

    Being shut out of your own WordPress site is unsettling. This article is the starting point: it explains how WordPress login actually works, the three categories every login problem falls into, and where to go for the specific symptom you are seeing.

    1282 words
  2. No access to wp-admin without an error

    You try to reach the WordPress dashboard, but instead of an error you get nothing you can read: a blank page, a silent bounce to the homepage, or a login screen that will not stay logged in. This article explains the three categories that cause the silent version of wp-admin lockout and how to recognise which one you are in.

    1212 words
  3. WordPress admin stuck loading after login

    You log in successfully, the admin top bar appears, and then the page just keeps spinning. This article explains why the post-login bootstrap is the single most fragile request in a WordPress install, which mechanisms cause it to stall, and how to tell this symptom apart from the lookalikes that get blamed for it.

    2038 words

Start typing to search, or browse the knowledge base and blog.