WordPress Login Loop After an Update: The Exact Fix

If WordPress is bouncing you back to the login page every time you enter your credentials — immediately after a core, plugin, or theme update — the most likely culprits are a broken authentication cookie, a corrupted wp-login.php handler, or a misconfigured URL setting exposed by the update. The loop is fixable without losing any content, and in most cases you can resolve it in under ten minutes following the steps below.

What You're Seeing (and What Makes This Different)

A login redirect loop looks deceptively simple: you enter your username and password, click Log In, and WordPress sends you straight back to /wp-login.php — no error, no white screen, just an endless loop. It's especially disorienting after an update because the site was working fine five minutes ago.

What makes the post-update variant distinct is that the update itself often triggers the cause rather than hiding a pre-existing one. A plugin update might drop a bad setcookie() call that fires before headers are sent. A core update can overwrite wp-login.php with a version that conflicts with an old caching rule. A theme update can introduce output buffering issues. Knowing when the loop started is your biggest diagnostic shortcut.

Why This Happens: The Four Real Causes

1. Cookie domain mismatch

WordPress writes authentication cookies scoped to the domain defined in Settings → General. If your WordPress Address (URL) or Site Address (URL) got changed during an update — or if a plugin reset them — the cookie domain won't match where the browser thinks it is. The login form accepts your credentials, WordPress sets the cookie for the wrong domain, the browser ignores it, and the redirect sends you back to the login screen.

2. Stale cache serving the login page

Page caching plugins sometimes cache wp-login.php or the post-login redirect target. After an update flushes the wrong files, a logged-in user hits a cached "not logged in" page and gets bounced. This is the number-one cause on managed hosts that run server-level caching (WP Engine, Kinsta, SiteGround, and similar).

3. A plugin or mu-plugin conflicting with authentication

Security plugins, SSO plugins, and redirect-manager plugins all hook into wp_redirect or the authenticate filter. A bad update to any of them can introduce a redirect that fires before WordPress finishes the login handshake. Because the loop produces no visible error, this cause is easy to miss.

4. Corrupted or mismatched secret keys and salts

If a security plugin regenerated your secret keys during an update, every existing authentication cookie is immediately invalidated. WordPress tries to validate the cookie, fails, and redirects to the login page — where the cycle repeats because the cookie it just set is also validated against the new keys, which sometimes triggers a race condition in certain hosting environments.

Before You Start: Back Up and Get Alternative Access

Before touching anything, confirm you have a working backup. If your host provides a one-click restore point (most do), note where it is. You should also have either FTP/SFTP access or access to your hosting control panel's file manager — several of the fixes below require editing files when you can't reach wp-admin.

Step-by-Step Fixes (Easiest First)

Step 1: Clear every cache layer

Start here because it resolves the majority of post-update login loops.

1. Log into your hosting control panel and clear the server-level cache. On SiteGround it's under Speed → Caching; on Kinsta it's under Sites → Tools → Clear Cache; on WP Engine it's under Purge All Caches.
2. Clear your browser cookies for the site. In Chrome: Settings → Privacy → Cookies → See all site data, search for your domain, and delete all entries.
3. Try logging in again in a private/incognito window so no stale cookies interfere.

If that works, the culprit was cached state. Reconfigure your caching plugin to exclude wp-login.php and the /wp-admin/ path from caching (most plugins do this by default — check that the update didn't reset those exclusions).

Step 2: Verify and correct your WordPress URLs

Via SFTP or your host's file manager, open wp-config.php and look for these two lines:

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

If they're missing, add them above the line that says /* That's all, stop editing! */. Use the exact URL your site should have — including or excluding www consistently. This hard-codes the values and overrides anything garbled in the database, which is often enough to break the loop immediately.

If the lines are already there and look correct, check that your database values match. In phpMyAdmin, open the wp_options table and find the rows siteurl and home. They should be identical to what's in wp-config.php.

Step 3: Deactivate plugins via the file system

Since you can't reach wp-admin, you'll do this via SFTP or file manager. Navigate to wp-content/plugins/ and rename the folder of the plugin you most recently updated to something like plugin-name-disabled. Try logging in. Repeat for each suspect plugin — particularly security, redirect, SSO, and caching plugins — until the loop stops. Once you're back in wp-admin, re-enable plugins one at a time and retest.

If you updated multiple plugins at once and aren't sure where to start, rename the entire plugins folder to plugins-disabled. WordPress will deactivate everything. Get back in, then rename it back and re-enable plugins individually. See our guide on finding which plugin is breaking your WordPress site for a more thorough isolation process.

Step 4: Regenerate secret keys and salts

Go to https://api.wordpress.org/secret-key/1.1/salt/ and generate a fresh set. Open wp-config.php via SFTP and replace the existing block of eight define() lines for AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and the four SALT equivalents. Save the file. This invalidates all active sessions (including your own), but you'll be able to log in cleanly with a new cookie immediately afterward.

This step is especially important if a security plugin updated and silently regenerated keys — you want to be certain the keys in the file and the keys in active use are definitively in sync.

Step 5: Switch to a default theme temporarily

If none of the above works, a theme update may be outputting content before the login redirect fires. Via SFTP, rename your active theme's folder inside wp-content/themes/. WordPress will fall back to the most recent default theme (Twenty Twenty-Four, or similar). If the login loop clears, the theme's functions.php is the source — contact the theme developer or roll back to the previous version.

After You're Back In: Prevent It Happening Again

The best protection against post-update login loops is a structured update process: update one item at a time, test the login in a private window immediately after each update, and keep automated cache-clearing tied to the update event. Most managed hosts handle this, but if you're on shared hosting you need to do it manually or let a maintenance plan do it for you.

Make sure your caching plugin's exclusion list always includes wp-login.php, wp-admin, and any cookie names your security plugin uses. Check this list whenever you update your caching plugin — it occasionally resets to defaults. Our article on updating WordPress safely without breaking your site covers the full pre-update checklist worth bookmarking.

Also worth doing: hard-code WP_HOME and WP_SITEURL in wp-config.php permanently. It costs nothing, and it means no plugin or database corruption can ever silently mismatch your URLs again.

When to Call a Professional

If you've worked through every step above and the loop is still there — or if you're not comfortable editing files over SFTP — the issue is almost certainly something deeper: a server-level redirect rule in .htaccess or an nginx config that's overriding WordPress's own redirects, a mu-plugin loaded before you can disable it, or database table corruption affecting the options. These require server access and forensic reading of error logs that go beyond what most site owners should be expected to handle themselves.

That's exactly the situation Mend's Quick Fix is built for. A senior engineer picks it up, diagnoses the exact cause, fixes it — usually the same day — and sends you a plain-English report of what was wrong and what changed. Flat $129, and if it's not fixed you pay nothing. You can also start with a free Diagnosis if you're not sure what you're dealing with — no card required, and we'll quote a flat price before touching anything.

A login redirect loop is one of the more unsettling WordPress errors because it gives you nothing to go on — no error message, no stack trace, just a page that seems to be working and isn't. But it has a finite list of causes, and the fixes above cover all of them in order of likelihood. Work through them methodically and you'll be back in your dashboard well before you need to call anyone.