You type your password, hit enter, the page flickers, and you land right back on the login screen, no error message, no explanation, just the same form staring back at you. Try again. Same result. This particular WordPress failure mode is uniquely frustrating precisely because it’s silent: no fatal error, no red warning box, nothing you can Google verbatim. Just a loop.
The good news is that this problem has a small, well-understood set of causes, and working through them systematically almost always resolves it without needing to touch server configuration or call in a developer. This guide covers each cause in the order most likely to be the culprit, plus a few less common triggers that don’t show up in shorter troubleshooting lists.
Why This Happens: The Short Version
WordPress authentication relies on cookies to remember that you’re logged in between page loads. The login redirect loop happens when the login process succeeds on the server side, WordPress genuinely verifies your credentials, but the cookie that’s supposed to prove that success either never gets set in your browser, gets set with the wrong values, or gets rejected somewhere between your browser and the server. WordPress then redirects you back to wp-login.php because, as far as it can tell from the next request, you were never actually logged in.
Nearly everything below is some variation of “something is interfering with cookies or the URLs WordPress uses to manage the login session.”
It helps to understand the mechanics briefly, because it makes the fixes below feel less like arbitrary steps and more like a logical process of elimination. When you submit the login form, your browser sends your username and password to wp-login.php. WordPress checks them against the database, and if they’re valid, it generates an authentication cookie and tells your browser to store it via an HTTP response header. Your browser then needs to send that same cookie back on the very next request, the one that loads the admin dashboard. If anything breaks that round trip (the cookie isn’t stored, gets stored against the wrong domain, gets blocked by a browser setting, or gets overwritten by a conflicting value from a plugin), WordPress sees an unauthenticated request on that next page load and sends you right back to the login form, with no way to distinguish “wrong password” from “cookie problem” because from its point of view, it never received proof you were logged in.
1. Corrupted or Conflicting Browser Cookies
This is the most common cause and the fastest to rule out. Cookies stored from a previous session, a different admin URL, or a browser extension that modifies cookie behavior can all break the authentication handshake.
Fix it:
1. Open your browser’s settings and find the cookie/cache management section.
2. Clear cookies and cached data specifically for your site’s domain (clearing everything site-wide is a bigger hammer than necessary, but works too).
3. Close the browser completely, not just the tab, some cookie state persists across tabs within the same browser session.
4. Reopen and attempt to log in again.
If this fixes it, worth noting for next time: try logging in from an incognito/private window first whenever you hit this issue. It rules cookies in or out in about ten seconds, before you touch anything else on the list.
2. A Plugin Conflict
Security plugins, caching plugins, and anything that touches cookies, sessions, or redirects directly are the most frequent offenders here. A caching plugin serving a stale, cached version of the login page is a particularly common variant, you appear to submit credentials, but you’re actually interacting with a cached page that never reaches the real authentication logic.
Fix it (via FTP or your host’s file manager, since you can’t get into the dashboard):
1. Navigate to wp-content/plugins/.
2. Rename the entire plugins folder (to something like plugins_disabled), WordPress automatically deactivates every plugin whose folder it can’t find, without needing dashboard access.
3. Try logging in again.
4. If it works, rename the folder back to plugins, then reactivate plugins one at a time from the dashboard, testing login after each, until you find the one causing the conflict.
5. Once identified, check that plugin’s support forum or changelog for known issues, update it if an update is available, or replace it if the conflict persists.
3. A Theme Problem
Less common than a plugin conflict, but the same logic applies, a theme’s functions.php file can hook into login or authentication behavior in ways that interfere with the session cookie.
Fix it: using the same FTP approach as above, navigate to wp-content/themes/, and switch to a default WordPress theme (Twenty Twenty-Four or similar) by renaming your active theme’s folder, WordPress falls back to a default theme automatically when it can’t find the active one. If login works after that, the theme is the cause; check for theme updates or reach out to the theme developer.
4. A Broken or Outdated .htaccess File
The .htaccess file controls URL rewriting on Apache servers, and a corrupted or misconfigured version, sometimes introduced by a plugin that edits it, sometimes by a manual edit gone wrong, can interfere with how login requests get routed.
Fix it:
1. Connect via FTP or your host’s file manager and locate .htaccess in your site’s root directory (it may be hidden by default since it starts with a dot, enable “show hidden files” in your FTP client if you don’t see it).
2. Download a copy as a backup before touching anything.
3. Delete the existing .htaccess file.
4. Log in to WordPress (this should now work if .htaccess was the problem) and go to Settings → Permalinks, then click Save Changes without altering anything, this regenerates a fresh, default .htaccess file.
5. Mismatched WordPress Address (URL) and Site Address (URL) Settings
WordPress stores two URLs internally, the WordPress installation address and the site’s public address, and when these don’t match what your site is actually running on (common after a migration, a domain change, or switching between HTTP and HTTPS), authentication can fail in exactly this way.
If you can still reach the dashboard through some path (an incognito window, a different browser): go to Settings → General and confirm both URL fields match your site’s actual current address, including the correct protocol (https, not http, if you have SSL installed).
If you can’t reach the dashboard at all: connect via FTP, open wp-config.php, and add these two lines above the line that says “That’s all, stop editing!”:
define('WP_HOME','https://yourdomain.com');
define('WP_SITEURL','https://yourdomain.com');Replace the placeholder with your actual domain. This forces both values regardless of what’s stored in the database, which restores access immediately.
6. Server-Level Redirect Rules
Occasionally the cause sits outside WordPress entirely, a misconfigured redirect rule at the server level (in Apache’s configuration or Nginx’s server block) that catches login requests and sends them somewhere unintended. This is the least common cause on this list, and also the hardest to fix yourself without server access. If none of the above resolves the loop, this is worth raising with your hosting provider’s support team directly, since they can check server-level logs and configuration that aren’t visible from inside WordPress.
7. An Expired or Corrupted Authentication Cookie Secret Key
Less commonly discussed, but worth knowing: WordPress uses a set of security keys (defined in wp-config.php) to encrypt and validate authentication cookies. If these keys were recently regenerated (sometimes automatically by a security plugin, sometimes manually) while old cookies were still cached in your browser, the mismatch causes exactly this symptom. Clearing cookies (step 1) usually resolves this on its own, but if the loop persists specifically after a security plugin update or a manual security hardening pass, regenerating fresh keys from the official WordPress secret-key generator and updating wp-config.php is worth trying.
Special Case: WWW vs Non-WWW Mismatches
A subtle variant of the URL mismatch problem happens when your site is technically accessible at both www.yourdomain.com and yourdomain.com, but only one of them is set as the canonical address in WordPress. Cookies are scoped to the exact domain they were set on, so if you land on the login page via one version of the URL but WordPress’s internal settings point to the other, the cookie gets set for a domain that doesn’t match what your browser thinks it’s talking to on the next request, and the loop begins.
The fix is the same URL correction covered above, but the diagnostic tell is specific: try logging in by typing the URL manually both with and without “www” in front. If one version works and the other loops, you’ve found it. A permanent fix means either setting up a proper 301 redirect from the non-canonical version to the canonical one at the server or .htaccess level, or ensuring your DNS and hosting configuration only serves one version consistently.
Special Case: Multisite Networks
WordPress Multisite installations add a layer of complexity to this issue because cookies need to work correctly across the entire network, not just a single site. A login loop on one subsite within a network sometimes traces back to a cookie domain setting (COOKIE_DOMAIN in wp-config.php) that’s scoped too narrowly or too broadly for how the network’s subdomains or subdirectories are structured. If you’re running Multisite and only one specific subsite loops while others work fine, check that subsite’s domain mapping configuration before assuming it’s the same generic cause as a single-site install.
Special Case: Migrations and Staging-to-Live Moves
Login loops are especially common immediately after migrating a site between hosts, or pushing a staging environment live, because both processes frequently carry over database values (including the stored site URLs) from the old environment without updating them for the new one. If your login loop started right after a migration, deployment, or staging push, rather than appearing on a previously stable site out of nowhere, jump straight to the URL mismatch fix (step 5); it resolves the overwhelming majority of post-migration login issues.
When It’s Not Actually a Redirect Loop
Worth ruling out early: sometimes what looks like a login loop is actually a fatal PHP error that WordPress is silently swallowing and redirecting away from, rather than a genuine cookie/session issue. If you have access to your site’s error logs (via your host’s control panel or FTP access to a debug log file), enabling WP_DEBUG_LOG in wp-config.php temporarily and attempting to log in again will surface any underlying PHP error that a plain redirect loop wouldn’t otherwise reveal. This is particularly worth checking if the loop started right after a plugin or PHP version update rather than appearing spontaneously.
A Faster Diagnostic Order
Rather than working through all seven causes sequentially every time, this order gets you to the answer fastest based on how commonly each one is actually the culprit:
- Try an incognito/private window first, rules cookies in or out in seconds.
- If incognito also loops, disable plugins via FTP (the single most common real cause).
- If plugins aren’t it, switch themes via FTP.
- If the theme isn’t it, check Settings → General URLs (or the wp-config.php override if you can’t reach the dashboard).
- Only then move to .htaccess and server-level rules, which are rarer.
Preventing This From Happening Again
A few habits meaningfully reduce how often this shows up: keep security and caching plugins updated (a large share of login-loop reports trace back to an outdated version of exactly these plugin types), avoid manually editing .htaccess unless you know precisely what a rule does, and always test plugin or theme updates on a staging environment before applying them to a live site, this is exactly the category of subtle, non-obvious breakage that staging testing exists to catch before it locks you out of your own dashboard.
Frequently Asked Questions
Why does the login page redirect me but never show an error message?
Because from WordPress’s perspective, nothing actually failed, your credentials were valid. The problem is downstream, in whether the browser successfully stored and sent back the session cookie proving you’re logged in. That’s a cookie/session issue, not a credentials issue, which is why no authentication error appears.
Can a VPN or ad blocker cause this?
Occasionally, yes. Some VPNs route traffic in ways that interfere with cookie domains, and aggressive privacy or ad-blocking extensions sometimes block first-party cookies they mistake for tracking cookies. If nothing else on this list resolves it, temporarily disabling browser extensions and trying without a VPN is worth ruling out.
Is this the same issue as “too many redirects” errors?
Related but not identical. “Too many redirects” is a browser-level error that stops the page from loading at all after detecting an infinite redirect chain, usually tied to HTTP/HTTPS mismatches or overly aggressive redirect plugin rules. A login loop, by contrast, does load the login page each time, it just never progresses past it. The URL mismatch fix (step 5) is the most common resolution for both.
I disabled all plugins via FTP and login still loops, what now?
If plugins and a theme switch both fail to resolve it, move down the list to the URL mismatch check next, since that’s the second most common cause after plugin conflicts. If that also doesn’t resolve it, the .htaccess reset and server-level rule check are your remaining options, in that order. In the rare case none of the seven causes fixes it, contacting your host’s support with specifics (when it started, what changed right before, and what you’ve already ruled out) gets you a faster resolution than starting the conversation from scratch, hosting support teams see this exact issue often enough to recognize patterns you might not.
Will resetting my password fix a login loop?
No, and this is a common wasted step. A login loop happens after successful authentication, during the cookie/session handoff, the password itself is rarely the actual problem, since WordPress does verify it correctly before the loop begins. Resetting a working password doesn’t touch the actual cause and just adds an extra step before you’re back to troubleshooting the real issue.
A Short Prevention Checklist
Once you’ve resolved a login loop, a few minutes of prevention work reduces the odds of a repeat:
- Confirm Settings → General has the correct, canonical URL (with the right protocol and www/non-www choice) recorded.
- Set up a proper redirect from any non-canonical version of your domain to the canonical one, rather than leaving both technically reachable.
- Keep security and caching plugins updated, since outdated versions of exactly these plugin types are disproportionately represented in login-loop reports.
- Test any plugin, theme, or PHP version update on staging before applying to a live site, especially anything touching authentication, caching, or redirects.
- Keep a bookmark or note of your site’s FTP or file manager access details somewhere separate from the WordPress dashboard itself, if you ever do get locked out, you’ll need that access to resolve it, and it’s the wrong moment to be searching for hosting login credentials.
Interesting reads:
WordPress Maintenance: 10 Practices to Keep Your Website Healthy