WordPress login page refreshing and redirecting: how to fix it

You type your username and password on the WordPress login page, click Log In, the page reloads, and you are back at the login screen. No error message, no “incorrect password” warning, just a fresh login form as if nothing happened. You enter your credentials again. Same result. The loop continues indefinitely.

This is one of the most frustrating WordPress errors because there is no feedback. A wrong password gives you an error message. A 500 error gives you a blank page. But the login redirect loop silently discards your valid credentials and sends you back to the starting point, giving you nothing to work with.

The cause is always the same category of problem: WordPress authenticated you successfully, set the login cookies, and then on the next request could not validate those cookies. Since the cookies appear invalid, WordPress redirects you back to the login page. Understanding why the cookies fail is the key to fixing it.

How WordPress login works#

The login process has several steps, and the redirect loop can break at any of them:

1. You submit your username and password to  wp-login.php
2. WordPress verifies the credentials against the database
3. If valid, WordPress generates authentication cookies ( wordpress_logged_in_{hash}  and  wordpress_{hash} )
4. WordPress sets these cookies in the browser with specific domain, path, and secure attributes
5. WordPress redirects you to wp-admin (or wherever you were going)
6. On the redirected request, the browser sends the cookies back
7. WordPress reads the cookies, validates them (domain, path, HMAC signature, session token), and grants access

If step 2 fails, you see “incorrect password.” If steps 3-7 fail, you see the redirect loop. The cookies were set but could not be validated on the next request.

For a deeper explanation of the cookie mechanism including HMAC signatures and session tokens, see WordPress keeps logging out: how to fix it – the underlying mechanics are the same, but the login redirect loop happens immediately rather than after a period of activity.

Cause 1: URL mismatch between siteurl and home#

The most common cause by far. WordPress generates the cookie name by hashing the site URL. If the URL you access the site through does not match the URL stored in the database, the cookie hash does not match, and WordPress cannot find the cookie it set.

Common mismatches:

• http://example.com  in the database but you access via  https://example.com
• https://www.example.com  in the database but you access via  https://example.com
• https://example.com  in the database but you access via  https://example.com/  (trailing slash)
• https://example.com/wordpress  in the database but you access via  https://example.com

How to confirm

Check the stored URLs:

wp option get siteurl
wp option get home

Compare these with the URL in your browser’s address bar when you visit the login page. They must match exactly – same protocol, same domain (with or without www), same path.

How to fix

Update both values to match the URL you actually use:

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

If you cannot access WP-CLI (because you cannot log in and do not have SSH), force the values in wp-config.php :

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

If the mismatch is HTTP vs HTTPS and you want HTTPS, also add:

define('FORCE_SSL_ADMIN', true);

This URL mismatch is especially common after migrations, SSL certificate installations, or domain changes. The migration process should include a search-replace to update all URLs in the database – see How to migrate WordPress to another hosting provider for the complete procedure including serialization-safe URL replacement.

Cause 2: Cookies blocked by browser#

If the browser refuses to store or send the cookies WordPress sets, every login attempt succeeds server-side but fails client-side.

How to confirm

After attempting to log in, open your browser’s developer tools (F12), go to Application > Cookies, and look for cookies from your domain. If there are no wordpress_logged_in_* cookies, the browser is blocking them.

Common browser causes

Privacy settings. Some browsers block all cookies by default or block cookies from sites you have not visited before. Ensure cookies are allowed for your domain.

Extensions. Privacy extensions like Cookie AutoDelete, Privacy Badger, or uBlock Origin can intercept WordPress cookies. Temporarily disable all extensions and try logging in.

SameSite attribute. Modern browsers enforce the SameSite cookie attribute. If a plugin or server configuration sets SameSite=None without the Secure flag (or sets SameSite=Strict when the login form posts cross-origin), the browser may reject the cookie.

Incognito mode. Try logging in from an incognito/private window. If it works in incognito but not in your normal browser, a corrupted cookie or extension is the problem.

How to fix

Clear all cookies for your domain specifically (not all cookies for all sites). In Chrome: Settings > Privacy > Cookies > See all site data > search for your domain > Remove. Then try logging in again.

If clearing cookies fixes it temporarily but the problem returns, an extension is interfering. Disable extensions one by one to find the culprit.

Cause 3: HTTPS not detected behind a reverse proxy#

If your site runs behind a reverse proxy, CDN, or load balancer that terminates SSL, the proxy forwards the request to WordPress over HTTP. WordPress sees an HTTP request and does one of two things:

1. Sets cookies without the  Secure  flag (so the browser only sends them over HTTP, not HTTPS)
2. Generates HTTP redirect URLs that conflict with the browser’s HTTPS connection

Either way, the cookies do not travel correctly between the HTTPS login page and the HTTP backend, causing the redirect loop.

How to confirm

Your site URL starts with https:// but the server’s $_SERVER['HTTPS'] variable is not set. You may see the login page flicker between HTTP and HTTPS during the redirect.

How to fix

Tell WordPress to trust the proxy’s protocol header. Add this to wp-config.php before the line that says “That’s all, stop editing”:

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

On Hostney, Nginx automatically sets the X-Forwarded-Proto header when proxying to PHP or when Apache is configured as the backend web server. WordPress detects HTTPS correctly without manual configuration.

Cause 4: Caching the login page#

If a caching layer caches the login page, different users receive the same cached page. The page contains a nonce (a security token) that is specific to a session. When you submit the cached login form, the nonce does not match your session, and WordPress rejects the submission silently by redirecting back to the login page.

How to confirm

The redirect loop happens for some users but not others. It may work after clearing caches but return later.

How to fix

Ensure the login page is excluded from all caching layers:

WordPress caching plugins: Exclude /wp-login.php and /wp-admin/ from page caching. Most plugins do this by default, but check the settings.

Server-level caching: Nginx FastCGI cache should bypass the cache when the request URL matches wp-login.php or when WordPress login cookies are present.

CDN caching: If using Cloudflare or another CDN, add a page rule to bypass cache for *wp-login.php* and *wp-admin* .

On Hostney, the Nginx FastCGI cache automatically excludes wp-login.php , wp-admin , and all requests with WordPress authentication cookies. The Hostney Cache plugin manages these exclusions out of the box.

Cause 5: COOKIE_DOMAIN or COOKIEPATH misconfigured#

WordPress allows you to override the cookie domain and path in wp-config.php . If these are set incorrectly, cookies are set for the wrong domain or path and the browser does not send them back on the redirect.

How to confirm

Check wp-config.php for these constants:

grep -i "COOKIE" wp-config.php

If you see COOKIE_DOMAIN , COOKIEPATH , SITECOOKIEPATH , or ADMIN_COOKIE_PATH with values that do not match your site’s actual domain and path, this is the cause.

How to fix

For most single-site WordPress installations, remove all custom cookie constants from wp-config.php . WordPress calculates the correct values automatically from the site URL.

If you need custom cookie settings (multisite, subdirectory installations, or multi-domain setups), ensure the values match exactly:

define('COOKIE_DOMAIN', 'example.com');   // No www, no https://, no trailing slash
define('COOKIEPATH', '/');                 // Must match the WordPress installation path

Cause 6: Authentication keys changed#

The authentication cookie contains an HMAC hash generated using the keys and salts in wp-config.php . If someone changed these keys (intentionally for security, or accidentally during a file edit), every existing cookie becomes invalid. The cookies your browser sends are cryptographically valid for the old keys but invalid for the new ones.

How to confirm

The redirect loop started immediately after someone edited wp-config.php . Or after a migration where wp-config.php was recreated with new keys.

How to fix

If the keys were changed accidentally, restore the original wp-config.php from a backup.

If the keys were changed intentionally (security measure after a compromise), the redirect loop is expected for one login cycle. Clear your browser’s cookies for the domain and log in fresh. The new login will generate cookies with the new keys and work correctly.

If the keys are set to the default placeholder text ( put your unique phrase here ), generate new ones:

https://api.wordpress.org/secret-key/1.1/salt/

Replace the placeholder keys, clear your browser cookies, and log in.

Cause 7: Plugin conflict during login#

Some plugins hook into the login process and can disrupt cookie setting, redirect handling, or authentication flow. Security plugins, custom login page plugins, SSO (single sign-on) plugins, and two-factor authentication plugins are the most common offenders.

How to confirm

The redirect loop started after activating or updating a plugin. Or it only occurs on specific browsers or devices where the plugin’s JavaScript is involved.

How to fix

Deactivate all plugins via SFTP:

cd wp-content/plugins/
mv plugins plugins-disabled

Try logging in. If it works, rename the directory back and reactivate plugins one at a time. The culprit is the one that brings back the redirect loop.

Common plugin conflicts:

• Custom login page plugins that redirect wp-login.php to a custom URL but break the cookie redirect flow
• Two-factor authentication plugins with misconfigured redirect handling
• SSO plugins that expect specific server configurations
• Security plugins with overly aggressive cookie validation

Cause 8: Database connection issue during cookie validation#

WordPress validates the authentication cookie against session tokens stored in the usermeta table. If the database connection is slow, times out, or fails during this validation step, WordPress cannot confirm the session and redirects to the login page.

How to confirm

The redirect loop is intermittent rather than constant. The Nginx error log may show 502 or 504 errors interspersed with the redirects. The site may be slow in general.

How to fix

This is a database performance or connectivity issue, not a WordPress configuration issue. See Error establishing a database connection in WordPress: how to fix it for the complete diagnostic approach.

Quick checks:

# Test database connection
wp db check

# Check if session tokens are intact
wp user meta get admin session_tokens

If session tokens are corrupted, delete them and log in fresh:

wp user meta delete admin session_tokens

Quick diagnostic checklist#

Work through this in order. Most cases are resolved in the first three steps.

1. Check URLs. wp option get siteurl and wp option get home must match the URL in your browser exactly. This is the #1 cause.
2. Clear browser cookies. Delete all cookies for your domain and try logging in. This rules out corrupted or conflicting cookies.
3. Try incognito. If login works in incognito, a browser extension or corrupted cookie is the cause.
4. Check wp-config.php. Look for COOKIE_DOMAIN , COOKIEPATH , custom WP_HOME / WP_SITEURL values, or recently changed authentication keys.
5. Deactivate plugins. Rename the plugins directory via SFTP and try logging in.
6. Check HTTPS detection. If behind a proxy, verify that $_SERVER['HTTPS'] is set correctly.
7. Check caching. Clear all server-side caches and CDN caches.

How Hostney handles this#

Consistent HTTPS. SSL is provisioned automatically during site setup, and Nginx sets the X-Forwarded-Proto header correctly. The HTTP/HTTPS mismatch that causes most login redirect loops is avoided from the start.

Cache exclusions. The Nginx FastCGI cache automatically excludes wp-login.php and authenticated requests. Cached login pages with stale nonces cannot occur with the default configuration.

Per-site isolation. Each site’s PHP runs in its own container, so cookie validation runs against an isolated database connection. One site’s database contention cannot cause login failures on another.

Summary#

The WordPress login redirect loop means your credentials are correct but the authentication cookies cannot be validated after login. The most common cause is a URL mismatch between what is stored in the database and what appears in your browser – check siteurl and home first. After that, check browser cookie storage, HTTPS detection behind proxies, custom cookie constants in wp-config.php, and plugin conflicts.

The redirect loop gives no error message, but the browser’s developer tools show whether cookies are being set and sent. If no cookies appear after login, the browser is blocking them. If cookies are set but not sent on the redirect, the domain or path does not match. If cookies are sent but WordPress still redirects, the authentication validation is failing server-side. For a complete reference of WordPress errors and their quick fixes, see How to fix the most common WordPress errors.