Fix WordPress Login Redirect Loop (wp-login.php Keeps Reloading)

You type your password into wp-login.php, WordPress accepts it, the page flickers — and you're back at the login form. No error message, no clue, just an endless loop. It's one of the more disorienting WordPress bugs because everything looks fine right up until the moment it isn't. Here's what actually causes it and how to fix it without guessing.

Symptom

You submit correct credentials on /wp-login.php. The page reloads and dumps you right back at the login form, sometimes with the URL growing a redirect_to= parameter that gets longer each time you try. No "incorrect password" message appears. In the worst cases the loop happens even after a fresh password reset, and it can affect only the admin login while the rest of the site loads normally.

Why This Happens

WordPress logs you in by setting an authentication cookie and then redirecting your browser back to wp-admin. If the cookie WordPress sets doesn't match the URL WordPress checks against on the next request, it decides you're not logged in and sends you back to the login form — forever. There are a handful of common root causes:

• WP_HOME / WP_SITEURL mismatch. Something in wp-config.php, the database, or a migration left the site URL inconsistent — often http:// in one place and https:// in another, or a trailing www mismatch.
• Forced SSL without a matching site URL. A security plugin or .htaccess rule forces HTTPS, but siteurl/home in the database still says http://. The redirect and the cookie domain disagree.
• Page or object cache serving a stale logged-out page. A caching plugin or server-level cache (Varnish, LiteSpeed Cache, Cloudflare) caches the login page's HTML, including an old nonce, so your submitted form is checked against stale data.
• Cookie domain problems. Multisite installs, recent domain changes, or a manually set COOKIE_DOMAIN constant that no longer matches the live domain will silently reject the auth cookie.
• Server clock drift. WordPress auth cookies and nonces are time-sensitive. If the server's clock has drifted, cookies can expire before your browser thinks they should.
• A conflicting plugin. Security plugins that rewrite login behavior (custom login URLs, brute-force protection, 2FA) are common offenders when they're misconfigured or left half-updated.

Fix It: Step by Step

1. Check WP_HOME and WP_SITEURL first

This single mismatch causes more login loops than everything else combined. Open wp-config.php via File Manager or SSH and check for these lines:

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

If they're not there, or they don't match, add or correct them — matching scheme (https), matching www or non-www, no trailing slash. If you're not sure what the database currently has, check via phpMyAdmin in the wp_options table for the siteurl and home rows, or from SSH with WP-CLI:

wp option get siteurl
wp option get home
wp option update siteurl "https://yourdomain.com"
wp option update home "https://yourdomain.com"

2. Confirm SSL is actually forced consistently

If you're forcing HTTPS at the server level (via .htaccess, a plugin like Really Simple SSL, or a WHM-level redirect) but the database still points to http://, you get a redirect fight: the server pushes to HTTPS, WordPress checks the cookie against HTTP, and neither wins. Fix step 1 first, then re-test before touching redirect rules.

3. Clear every layer of cache

Login pages should never be cached, but misconfigured setups sometimes cache them anyway. Clear, in order:

• Any WordPress caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) — purge everything, not just "site cache."
• Object cache, if you're running Redis or Memcached: wp cache flush from SSH.
• Any CDN or reverse proxy cache (Cloudflare: Caching → Configuration → Purge Everything).
• Your own browser cache and cookies for the domain — test in a private/incognito window to rule this out entirely.

4. Check for a stray COOKIE_DOMAIN or session constant

Search wp-config.php for COOKIE_DOMAIN. If it's set and doesn't exactly match your current domain (including subdomain), remove the line or correct it:

define('COOKIE_DOMAIN', 'www.yourdomain.com'); // must match exactly

This is especially common after moving a site between subdomains (like a staging-to-live migration) where the constant was left pointing at the old hostname.

5. Rule out server time drift

SSH in and check the server clock:

date -u
timedatectl status

If the time is off by more than a minute or two, it's worth fixing NTP sync regardless — clock drift causes subtler problems too, including SSL and mail authentication failures.

6. Isolate plugins by disabling them via SSH or File Manager

If you're locked out and can't reach wp-admin to deactivate plugins normally, rename the plugins folder temporarily:

mv wp-content/plugins wp-content/plugins-disabled
mkdir wp-content/plugins

Try logging in again. If it works, rename the folder back and reactivate plugins one at a time (via File Manager, moving each plugin folder back individually) until the loop returns — that's your culprit.

7. Last resort: reset the auth salts

If cookies seem corrupted for no obvious reason, generating fresh security keys forces every session to reset cleanly. Get a new set from the WordPress secret key generator and replace the block of AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY (and their _SALT counterparts) in wp-config.php.

Quick Reference

Prevention

Most of these loops trace back to migrations and domain changes where siteurl/home didn't get updated, or an SSL redirect got added without checking the database first. When you move a site — to a new domain, from staging to live, or even just from HTTP to HTTPS — update wp_home and wp_siteurl as one of the first steps, not an afterthought. Keep server time synced with NTP by default, and avoid caching plugins that don't automatically exclude wp-login.php and logged-in sessions from the cache.

Frequently Asked Questions

Why does the loop only happen for admin accounts, not other users?

It usually doesn't — if it looks that way, it's often because you're testing other accounts in the same browser session where a valid cookie or cache is masking the issue. Test each account in a fresh private window.

Can I fix this without SSH access?

Yes. Everything above — editing wp-config.php, renaming the plugins folder, checking wp_options via phpMyAdmin — can be done through cPanel's File Manager and phpMyAdmin. SSH just makes WP-CLI commands faster.

I fixed siteurl and home, but the loop continues. What now?

Clear cache at every layer (step 3) before assuming the fix didn't work — a cached copy of the old login page is the most common reason a correct database fix doesn't seem to take effect immediately.

Could this be caused by a hack rather than a misconfiguration?

It's rare but possible, especially if the loop appeared suddenly with no changes on your end. If you also notice unfamiliar admin users, unexpected files, or your site flagged by Google Safe Browsing, treat it as a potential compromise and scan the site (ImunifyAV or a malware scanner) before assuming it's a simple config issue.

Does this affect WooCommerce "My Account" logins too?

Yes — the same cookie and siteurl logic applies to front-end logins, including WooCommerce's My Account page, since they use the same WordPress authentication system as wp-admin.