WordPress Login Page Refreshing and Redirecting? Here’s How to Fix It

You type your username, type your password, click Log In, and WordPress sends you straight back to the same empty login form. No error. No “incorrect password.” Just the login page again, every single time. The WordPress login page refreshing and redirecting back to itself is one of the most maddening problems on the platform, because WordPress gives you zero clues about what’s wrong.

Here’s the good news: this login loop almost never means your password is wrong or your site is hacked. It means WordPress accepted your login, tried to remember it with a cookie, and then couldn’t read that cookie back on the next page. Fix the cookie problem and you’re in. This guide walks through every real cause in the order worth checking, from a 30-second browser fix to the wp-config.php and database edits that solve the stubborn cases.

Why Does My WordPress Login Page Keep Refreshing?

The WordPress login page keeps refreshing because WordPress can’t confirm you’re logged in on the page after the login form. WordPress stores your login in an authentication cookie, and if that cookie is blocked, stale, set for the wrong domain, or marked secure on a connection WordPress thinks is insecure, wp-admin treats you as logged out and sends you back to wp-login.php.

The WordPress login process works in two steps. First, wp-login.php checks your username and password. If they’re correct, WordPress sets a wordpress_logged_in_ cookie and redirects you to /wp-admin/. Second, wp-admin reads that cookie to decide whether to let you in. When step two fails, the redirect points right back at step one, and you get the loop.

That means the real causes almost always fall into one of these buckets:

• Browser cookies or cache holding an old, broken login session
• A URL mismatch between the WordPress Address and Site Address settings (www vs non-www, http vs https)
• HTTPS confusion, usually from FORCE_SSL_ADMIN, a CDN like Cloudflare, or a reverse proxy
• A plugin or theme that hooks into login or redirects
• A corrupted .htaccess file or server-level cache serving a cached login page

Work through the fixes below in order. The early ones are fast and safe; the later ones touch config files, so take a backup before you start editing anything on the server.

Fix 1: Clear Cookies and Test in a Private Window

Clearing your browser cookies for the site is the fastest fix for a WordPress login redirect loop, because a stale or corrupted authentication cookie is the most common cause. Open a private or incognito window and try logging in there first. If the private window works, the problem is your normal browser’s stored data, not WordPress.

To fix it permanently, clear cookies and cached files for your domain only (no need to wipe your whole browser history). In Chrome, click the padlock or site-settings icon next to the URL, then choose the option to delete data for that site. Also make sure the browser isn’t blocking cookies outright. If WordPress itself detects blocked cookies, it usually shows “Cookies are blocked or not supported by your browser” instead of silently looping, but strict privacy extensions can cause the silent version.

If the loop shows up in every browser and in private windows too, the browser is off the hook. Move on to the server-side fixes.

Fix 2: Check That Your WordPress Address and Site Address Match

A mismatch between the WordPress Address (siteurl) and Site Address (home) is the most common server-side cause of the WordPress login page refreshing. If one says https://www.example.com and the other says https://example.com, WordPress sets the login cookie for one hostname and then redirects you to the other, where that cookie doesn’t exist.

Since you can’t reach Settings > General, override both values in wp-config.php. Connect via FTP or your hosting file manager, open wp-config.php, and 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' );

Replace example.com with your real domain, and be exact: pick either www or non-www, and use https only if your SSL certificate actually works. These constants override whatever is stored in the database, so this is a safe test. If you can log in afterward, the URL mismatch was the problem.

If you have WP-CLI access, you can check the stored values directly before changing anything:

wp option get siteurl
wp option get home

While you’re in wp-config.php, look for a COOKIE_DOMAIN line too. A COOKIE_DOMAIN value left over from a migration or multisite setup that doesn’t match your current hostname will break the login cookie in exactly the same way. On a normal single site, it’s safe to remove that line entirely.

Fix 3: Sort Out HTTPS, FORCE_SSL_ADMIN, and Cloudflare

HTTPS misconfiguration causes WordPress login loops when WordPress thinks the connection is plain HTTP while the browser is on HTTPS. WordPress marks admin cookies as secure-only on HTTPS logins, so if the server reports the request as HTTP, the cookie never matches and wp-admin bounces you back to the login page.

The classic version of this is Cloudflare’s “Flexible” SSL mode. With Flexible, visitors connect to Cloudflare over HTTPS, but Cloudflare talks to your server over plain HTTP. WordPress sees HTTP, the browser sees HTTPS, and login breaks. The fix is to install a real SSL certificate on the origin server (most hosts include a free one) and switch Cloudflare’s SSL mode to “Full (strict).”

If your site sits behind a load balancer or reverse proxy that terminates SSL, WordPress needs to be told the original request was HTTPS. Add this to wp-config.php, above the “stop editing” line:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

Also check whether wp-config.php contains define( 'FORCE_SSL_ADMIN', true );. The FORCE_SSL_ADMIN constant is a good setting on a site with working HTTPS, but on a site where SSL is half-configured, it forces the admin onto a protocol the server can’t properly serve. Comment it out temporarily to test, then fix the SSL setup and put it back. If the browser shows “Too many redirects” instead of a quiet refresh, that’s a related but different loop, covered in detail in this guide to the WordPress too many redirects error.

Fix 4: Disable Plugins Without Logging In

A plugin can cause the WordPress login page to refresh if it modifies login redirects, security rules, or sessions. Security plugins, custom login URL plugins, membership plugins, and redirect plugins are the usual suspects. Since you can’t reach the Plugins screen, disable them all at once through the file system.

1. Connect via FTP or your hosting file manager.
2. Go to wp-content/ and rename the plugins folder to plugins-off.
3. Try logging in. WordPress deactivates every plugin it can’t find.
4. If login works, rename the folder back to plugins, then rename individual plugin folders one at a time until the loop returns. The last one you re-enabled is the culprit.

With WP-CLI, the same test is one command: wp plugin deactivate --all. The full one-by-one isolation process is broken down step by step in this guide on how to find which WordPress plugin is causing a problem. If plugins aren’t the cause, test the theme the same way by renaming the active theme’s folder in wp-content/themes/ so WordPress falls back to a default theme.

Fix 5: Reset .htaccess and Clear Server Cache

A corrupted .htaccess file or an aggressive page cache can also trap you in a WordPress login loop. Caching layers that store a copy of wp-login.php or wp-admin redirects will keep serving the old response no matter how many times you log in correctly.

For .htaccess on Apache or LiteSpeed servers, rename the existing file to .htaccess-old and create a new one with the default WordPress rules:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

For caching, purge everything: the caching plugin, your host’s server cache (many hosts have a “Purge cache” button in the control panel), and your CDN. Then make sure wp-login.php and /wp-admin/ are excluded from caching. Mainstream caching plugins exclude them by default, but custom server rules and CDN “cache everything” page rules sometimes don’t. If you’re not sure which cache layer is in play, this breakdown of every cache layer that can hide WordPress changes walks through each one.

Fix 6: Destroy Stale Sessions for Your User

WordPress stores active login sessions for each user in the database, and a broken session token can occasionally keep a single account stuck in the login loop while other accounts work fine. Destroying all sessions for that user forces WordPress to issue a fresh one on the next login.

With WP-CLI, run this, replacing admin with your username:

wp user session destroy admin --all

Without WP-CLI, you can delete the session_tokens row for that user in the wp_usermeta table through phpMyAdmin. It’s a narrow fix, so try it only after the URL, HTTPS, and plugin checks come up clean.

Which Fix Should You Try First?

Start with the fix that matches the symptom. Clearing cookies is always first because it takes seconds, but the pattern of the loop usually points straight at the cause.

Symptom	Most Likely Cause	Fix to Try
Works in a private window, fails in your normal browser	Stale cookies or cache	Clear site data in the browser
Started right after a migration or domain change	siteurl/home mismatch or old COOKIE_DOMAIN	Set WP_HOME and WP_SITEURL in wp-config.php
Started after enabling SSL or Cloudflare	HTTPS detection problem	Use Full (strict) SSL, add the proxy HTTPS fix
Started after installing or updating a plugin	Plugin conflict	Rename the plugins folder
Only one user account is affected	Broken session token	Destroy that user’s sessions

How to Stop the Login Loop From Coming Back

The WordPress login redirect loop usually returns when something changes the site’s URL or HTTPS setup without updating WordPress to match. Keeping the URL configuration consistent everywhere is what prevents it.

• Pick one canonical URL (www or non-www, always https) and use it in WordPress settings, your CDN, and your server redirects.
• After any migration, check siteurl, home, and any COOKIE_DOMAIN line before telling anyone the move is done.
• Install SSL on the origin server, not just at the CDN.
• Test login-related plugins (security, custom login URLs, membership) on a staging copy before updating them on the live site.

Once you’re back in, it’s also a good moment to harden the login page properly. This guide on securing the WordPress login page without a plugin covers the changes that block bots without adding another plugin that could cause the next loop.

The Bottom Line

When the WordPress login page keeps refreshing and redirecting, your password is fine. WordPress is failing to read its own login cookie, and the reason is almost always a cookie, URL, HTTPS, or plugin problem. Clear cookies first, then lock down WP_HOME and WP_SITEURL, then check SSL and plugins. Most login loops end somewhere in those first four steps.

Frequently Asked Questions