How to Resolve the WordPress Login Redirect Loop (8 Fixes)

A WordPress login redirect loop happens when you enter the right username and password, but WordPress sends you straight back to wp-login.php instead of the dashboard. The login works. The cookie that proves you logged in doesn’t. WordPress either never receives it or doesn’t trust it, so it asks you to log in again. WPOptimizers treats every login loop as a cookie problem first.

Being locked out of wp-admin feels urgent, because you can’t update, publish or fix anything else. The good news: your content is safe, and most loops clear with one change once you know which clue to look at.

How Do You Fix a WordPress Login Redirect Loop?

To fix a WordPress login redirect loop, check what the login page does after you submit, clear your site’s cookies, and make sure the WordPress Address, Site Address and the URL you log in on match exactly. Then remove bad cookie constants, stop caching the login page, and disable plugins. WPOptimizers resets user sessions last.

Here are the 8 fixes:

1. Read what the login page is telling you
2. Clear your site’s cookies and test in a private window
3. Match the WordPress Address, Site Address and login URL
4. Remove or correct COOKIE_DOMAIN and cookie path constants
5. Stop caching wp-login.php and wp-admin
6. Fix “headers already sent” errors that block the cookie
7. Disable plugins and switch to a default theme
8. Reset your user sessions and password

Download a copy of wp-config.php, .htaccess and your theme’s functions.php before you edit anything. You’ll need hosting access (File Manager, SFTP or SSH) or phpMyAdmin, since the dashboard is out of reach. If an edit goes wrong, here’s how to restore WordPress from backup.

What Is a WordPress Login Redirect Loop?

A WordPress login redirect loop is a lockout where wp-login.php accepts your details, sends you toward /wp-admin/, and wp-admin sends you back because it can’t find a valid login cookie. There’s no error and no “wrong password” warning. The front end of the site usually still loads. WPOptimizers calls it a silent lockout.

Here’s what happens behind the scenes when you log in:

1. WordPress checks your username and password against the wp_users table.
2. It sends your browser login cookies: one named wordpress_logged_in_ (for the whole site) and one named wordpress_ or wordpress_sec_ (for wp-admin, the second one on HTTPS).
3. It saves a session token for you in the wp_usermeta table.
4. Your browser loads /wp-admin/ and sends those cookies back.
5. WordPress checks the cookies against the session token. If they match, you see the dashboard.

A loop means step 2, 4 or 5 failed. The browser didn’t save the cookie, didn’t send it back, or WordPress rejected it.

Why Does WordPress Keep Redirecting to the Login Page?

WordPress redirects to the login page when the auth cookie is missing, set for the wrong domain or protocol, served from cache, or blocked by a plugin. The most common causes are a Site Address mismatch after an SSL change or migration, page caching on wp-login.php, and security plugins. WPOptimizers traces it back to whatever changed last.

What Changed Recently	Why the Login Cookie Fails
Moved the site or changed the domain	Cookies are named and set for the old Site Address
Switched to HTTPS or added SSL	Secure cookie is set on HTTPS, but wp-admin loads over HTTP (or the reverse)
Switched between www and non-www	You log in on one version, WordPress sets the cookie for the other
Turned on a caching plugin, Cloudflare cache rule or host cache	A cached copy of wp-login.php or wp-admin is served without your cookie
Installed a security or custom login URL plugin	The plugin redirects or blocks the login request
Edited wp-config.php or functions.php	Stray spaces or a COOKIE_DOMAIN line stop the cookie from being sent
Moved to a proxy, load balancer or new host	WordPress can’t tell the visitor is on HTTPS

Fix 1: Read What the Login Page Is Telling You

The login page gives small clues that point to the cause. Look at the URL after you submit, any message under the form, and whether the browser shows its own error. A “reauth=1” in the URL means WordPress rejected the cookie. WPOptimizers checks these clues before touching any file.

What You See	What It Means	Go To
Back on the login page, URL contains reauth=1	The cookie reached WordPress but wasn’t valid	Fix 3, Fix 4, Fix 8
Back on the login page, no message, no reauth	The cookie was never saved, or a cached page loaded	Fix 2, Fix 5
“Error: Cookies are blocked or not supported by your browser”	The test cookie WordPress sets on the login page didn’t save	Fix 2, Fix 6
Browser says “redirected you too many times”	A server, SSL or CDN redirect loop, not only a login issue	Our ERR_TOO_MANY_REDIRECTS guide
Login works in one browser but not another	Old cookies or a browser setting	Fix 2
Login page reloads instantly, even with a wrong password	A plugin or cache is intercepting the form	Fix 5, Fix 7

You can also check the cookies directly. In Chrome, press F12, open the Application tab, then Storage → Cookies → your domain. Log in and watch the list. If no cookie starting with wordpress_logged_in_ appears, the browser never got it.

Fix 2: Clear Your Site’s Cookies and Test in a Private Window

Old login cookies from before a domain, SSL or settings change can confuse WordPress. Delete the cookies for your domain only, then log in from a private or incognito window. If the private window works, the problem was in your browser. WPOptimizers always runs this quick test before editing server files.

1. Open a private window (Ctrl+Shift+N in Chrome and Edge, Ctrl+Shift+P in Firefox) and log in there.
2. If that works, go back to your normal browser and delete cookies for your site only. In Chrome, click the icon to the left of the address bar, open the cookies and site data option, and delete the data for your domain.
3. Check that the browser isn’t blocking cookies for your site. Strict privacy settings, some extensions and “block all cookies” options stop the WordPress test cookie.
4. Try a second browser to confirm.

If the private window loops too, the cause is on the site. Keep going.

Fix 3: Match the WordPress Address, Site Address and Login URL

WordPress builds the cookie name from your WordPress Address and sets the cookie for your Site Address. If either one uses a different protocol, domain or www setting than the URL you log in on, the cookie lands in the wrong place. Make all three identical. WPOptimizers checks these first after every migration or SSL install.

Look at the address bar on the login page. Then check what WordPress has stored. Both values need to match it exactly, for example https://example.com with no trailing slash.

Option A: wp-config.php. Add these two lines above the line that says “That’s all, stop editing”:

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

These temporarily override the database. Once you’re back in, set the same values under Settings → General, then delete the two lines so the URL lives in one place.

Option B: phpMyAdmin. Open your database, find the options table (usually wp_options, though your prefix may differ), and edit the siteurl and home rows. Or run:

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name IN ('siteurl', 'home');

Option C: WP-CLI over SSH:

wp option get siteurl
wp option get home
wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Changing the WordPress Address logs everyone out, because the cookie name depends on it. That’s expected. Log in again in a fresh private window.

If your site sits behind Cloudflare, a load balancer or a reverse proxy, WordPress may think a secure visit is plain HTTP and refuse the secure cookie. The proxy fix and the FORCE_SSL_ADMIN check are in Fix 4 of our ERR_TOO_MANY_REDIRECTS guide. If the certificate itself isn’t working yet, start with installing an SSL certificate on WordPress.

Fix 4: Remove or Correct COOKIE_DOMAIN and Cookie Path Constants

Some wp-config.php files set COOKIE_DOMAIN, COOKIEPATH, SITECOOKIEPATH or ADMIN_COOKIE_PATH by hand, often copied from a tutorial or left over from multisite. If the value doesn’t match the domain you log in on, the browser silently discards the cookie. Comment those lines out and test. WPOptimizers finds this cause often on migrated sites.

Open wp-config.php and search for lines like these:

define( 'COOKIE_DOMAIN', 'old-domain.com' );
define( 'COOKIEPATH', '/' );
define( 'SITECOOKIEPATH', '/' );
define( 'ADMIN_COOKIE_PATH', '/wp-admin' );

Put // in front of each one to disable it, save, and try logging in from a private window. On a normal single site, WordPress works out the right cookie domain and paths on its own.

On WordPress Multisite, COOKIE_DOMAIN matters more. A value pointing at the main domain can break logins on mapped domains or subsites. If you run multisite, ask your developer or host before removing it, since the right value depends on how domains are mapped.

Fix 5: Stop Caching wp-login.php and wp-admin

If a caching layer stores a copy of the login page or the dashboard, every visitor gets that copy, cookie or not. You log in, the cache serves the logged-out version, and you’re back at the form. Exclude wp-login.php and /wp-admin/ from every cache. WPOptimizers checks the plugin, host and CDN caches together.

Caching plugin: if you can’t reach wp-admin, open wp-content with File Manager or SFTP and rename the caching plugin’s folder, for example plugin-name to plugin-name-off. Also check for an advanced-cache.php file in wp-content. If it’s there, rename it too, and set define( 'WP_CACHE', true ); in wp-config.php to false while you test.

Cloudflare: look under Caching → Cache Rules (and any older Page Rules) for “Cache Everything” or a rule that covers the whole domain. Add a rule that bypasses cache when the URL path contains /wp-admin or /wp-login.php, or when the request has a cookie starting with wordpress_logged_in. Then purge the cache.

Host-level cache: many managed hosts run Varnish, Nginx FastCGI cache or LiteSpeed cache. Clear it from your hosting panel and ask support to confirm the login page and wp-admin are excluded.

With WP-CLI, you can flush the WordPress object cache too:

wp cache flush

Fix 6: Fix “Headers Already Sent” Errors That Block the Cookie

Cookies travel in the response headers, so they must go out before any page content. A single space or blank line before <?php in wp-config.php or functions.php sends content early, and the cookie never leaves. Check the PHP error log for “headers already sent.” WPOptimizers finds this after hand edits to config files.

1. Turn on logging. In wp-config.php, above “That’s all, stop editing,” add the three lines shown below.
2. Try to log in once, then open wp-content/debug.log.
3. Look for a line like “Cannot modify header information – headers already sent by (output started at /path/to/file.php:1)”. The file and line number show you exactly where the extra output is.
4. Open that file and remove any spaces, blank lines or invisible characters before <?php. If the file ends with ?>, delete anything after it, or remove the closing ?> altogether.
5. Save the file in UTF-8 without BOM. Some text editors add an invisible BOM character at the start, which counts as output.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Set WP_DEBUG back to false when you’re done. If a broken edit leaves you with a blank page instead, follow the steps for the WordPress white screen of death.

Locked Out and Need Back In Fast?

WPOptimizers WordPress developers can check the cookies, cache, config files and plugins, and get you back into wp-admin without risking your content.

Get WordPress Help

Fix 7: Disable Plugins and Switch to a Default Theme

Security plugins, custom login URL plugins, membership plugins, role-based login redirects and two-factor tools all hook into the login process. If one breaks, it can send you back to the login page every time. Disable all plugins from your file manager, then test the theme. WPOptimizers brings plugins back one at a time to find the culprit.

Disable all plugins without the dashboard:

1. Open wp-content with File Manager or SFTP.
2. Rename the plugins folder to plugins-disabled.
3. Log in. If it works, rename the folder back to plugins. Every plugin will show as inactive.
4. Reactivate them one by one from Plugins → Installed Plugins, logging out and back in after each one.

If you only suspect one plugin, such as a custom login URL plugin, rename just that plugin’s folder. With a hidden login URL plugin, renaming its folder brings back the normal /wp-login.php address.

Switch to a default theme: a theme’s functions.php can also redirect logins. Rename your active theme’s folder in wp-content/themes, and WordPress falls back to a default theme such as Twenty Twenty-Five if one is installed. With WP-CLI:

wp plugin deactivate --all
wp theme activate twentytwentyfive

Reset .htaccess: a bad rewrite rule can redirect wp-login.php as well. Rename .htaccess to .htaccess-old and test. If logins work, rebuild the default rules as shown in Fix 5 of our ERR_TOO_MANY_REDIRECTS guide, or save Settings → Permalinks once you’re in.

If deactivating plugins brings up a server error, our guide to the 500 internal server error in WordPress covers the next steps.

Fix 8: Reset Your User Sessions and Password

WordPress stores your active logins as session tokens in the wp_usermeta table. If that record is corrupted or full of old sessions, a fresh cookie may not match it. Clearing your sessions forces a clean login. Resetting the password does the same and closes any session you don’t recognise. WPOptimizers does both when a login loop has no other cause.

With WP-CLI:

wp user session destroy admin --all
wp user update admin --user_pass='a-new-strong-password'

Replace admin with your username or user ID.

With phpMyAdmin:

1. Open the wp_usermeta table and find the row where meta_key is session_tokens and user_id is your user ID. Delete that row. This only logs you out everywhere. It doesn’t delete your account.
2. To reset the password, open wp_users, edit your user, type a new password in user_pass, choose MD5 from the Function dropdown, and save. WordPress upgrades it to a stronger hash the next time you log in.

If you also see “Sorry, you are not allowed to access this page” after logging in, the problem is your user role, not the cookie. See the FAQ below.

After you’re back in, turn on two-factor login to protect the account. Our guide on two-factor authentication without a plugin walks through it.

How Do You Avoid Getting Locked Out of wp-admin Again?

Prevent future login loops by keeping one final site URL everywhere, never caching the login page or dashboard, and testing SSL, CDN and plugin changes on staging first. Keep a way into your files that doesn’t depend on wp-admin. WPOptimizers keeps SFTP or SSH access ready for every site it maintains.

A lockout prevention checklist:

1. Use one exact URL (protocol, www or not) in Settings → General, your CDN and your host
2. Exclude wp-login.php and /wp-admin/ from every cache layer
3. Don’t add COOKIE_DOMAIN or cookie path constants unless your setup needs them
4. Install security and login plugins one at a time, and note any custom login URL somewhere safe
5. Edit wp-config.php and functions.php with a code editor that saves without BOM
6. Keep hosting panel, SFTP or SSH login details where you can find them
7. Test changes on a staging site and take a backup before big updates

Or let our WordPress maintenance team watch your logins, security and updates for you.

Frequently Asked Questions About the WordPress Login Redirect Loop

These answers cover what site owners ask most about the WordPress login redirect loop, including password issues, permission errors, hacked sites, single-browser loops, data safety and custom login URLs, based on how WPOptimizers fixes client websites.

Why Does WordPress Accept My Password but Not Log Me In?

The password check passed, but the login cookie failed. WordPress either couldn’t set it, the browser didn’t send it back, or it didn’t match your session. A Site Address mismatch, cached login page or plugin conflict is usually the reason.

Why Do I See “Sorry, You Are Not Allowed to Access This Page” After Logging In?

That’s a permissions issue, not a login loop. It often happens after a migration when the table prefix changed but the role entry in wp_usermeta (for example wp_capabilities) still uses the old prefix. The meta keys must start with the same prefix as $table_prefix in wp-config.php.

Can a Hacked Site Cause a Login Redirect Loop?

Yes. Malware sometimes adds redirects to wp-login.php, .htaccess or a theme file, or creates its own admin user. If you see unknown users, strange files or redirects to other domains, scan the site and change every password. Our list of WordPress security plugins can help with the scan.

Why Does the Login Loop Only Happen in One Browser?

Old cookies, a strict privacy setting or an extension in that browser. Clear the site’s cookies there and check that cookies aren’t blocked for your domain. If other browsers work, the site itself is fine.

Will Fixing the Login Loop Delete My Content?

No. Clearing cookies, editing URLs, renaming plugin folders and resetting sessions don’t touch your posts, pages or media. Back up wp-config.php, .htaccess and the database before editing, so you can undo any change.

Does a Custom Login URL Plugin Cause Login Loops?

It can, especially after an update or alongside another security plugin. If you forgot the custom address or it loops, rename the plugin’s folder in wp-content/plugins. The default wp-login.php page comes back straight away.

Let Us Handle Your WordPress Site

WPOptimizers WordPress maintenance plans start at $49 per month, with tested updates, daily backups and uptime monitoring, so problems like login lockouts get caught early.

View Maintenance Plans