Guides /WordPress
WordPress

WordPress Login Redirect Loop: Why You Cannot Log In and How to Fix It

May 4, 20257 min readHostBible Team

You enter your username and password on the WordPress login page. It accepts your credentials, starts to redirect you to wp-admin, and lands you back on the login page as if you never logged in. Sometimes there's a "cookies required" message. Sometimes there's nothing. Here's why this happens and how to break the loop.

What causes a login redirect loop

WordPress login works using browser cookies. When you submit your credentials, WordPress validates them and sets an authentication cookie in your browser. Your browser then sends that cookie with the redirect request to wp-admin. WordPress checks for the cookie, sees you're authenticated, and lets you in.

The redirect loop happens when WordPress sets the cookie but the browser doesn't send it back on the next request, or when the cookie is set for one URL but the redirect sends you to a different one. The server sees no valid cookie, assumes you're not authenticated, and redirects back to the login page. This repeats indefinitely.

The most common root causes are: a mismatch between the site URL in the database and the URL the browser is actually visiting (http vs https, www vs non-www), a corrupted or conflicting .htaccess file, a caching plugin incorrectly caching the login page, a WordPress security plugin interfering with cookies, or an incorrectly configured SSL certificate creating a redirect chain that changes the URL.

Fix 1: Clear browser cookies and try a different browser

Start with the fastest check. Clear your browser's cookies and site data specifically for your domain, or open a completely private/incognito window and attempt to log in fresh. Some browsers block third-party cookies in ways that affect sites with certain proxy or CDN configurations. Try a different browser entirely, if login works in a different browser, the issue is browser-specific (an extension blocking cookies, browser cookie restrictions, or stale corrupted cookie data).

In Chrome, go to Settings > Privacy > Clear browsing data, filter by "yourdomain.com," and clear cookies specifically. Do not clear all cookies, you'll log out of everything else. In Firefox, use the lock icon in the address bar to manage and clear cookies for the specific site.

Fix 2: Check siteurl and home values in the database

Open phpMyAdmin from your hosting control panel, select your WordPress database, and look in the wp_options table. Find the rows with option_name values of siteurl and home. Both values should match exactly the URL you're using to visit the site in your browser, including whether it uses https:// or http://, and whether it has www or not.

If you recently migrated from HTTP to HTTPS and didn't update these values, WordPress sets the authentication cookie for http://yourdomain.com but the HTTPS redirect sends the browser to https://yourdomain.com. Browsers treat these as different cookie origins, the cookie is set but never sent, producing the redirect loop.

To fix: click Edit on the siteurl row and update the value to your correct full URL (e.g., https://yourdomain.com). Do the same for home. You can also set these overrides in wp-config.php which takes precedence over the database values:

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

Fix 3: Add cookie constants to wp-config.php

If your WordPress installation is in a subdirectory, or if there's any ambiguity about the cookie domain and path, explicitly defining these in wp-config.php removes the ambiguity:

define( 'COOKIE_DOMAIN', 'yourdomain.com' );
define( 'COOKIEPATH', '/' );
define( 'SITECOOKIEPATH', '/' );

If WordPress is installed in a subdirectory (e.g., yourdomain.com/wordpress/), set COOKIEPATH to /wordpress/ and SITECOOKIEPATH to /wordpress/. Mismatched paths are a common cause of login loops on subdirectory installs.

Do not set COOKIE_DOMAIN with a leading dot (e.g., .yourdomain.com) unless you specifically need cookies to work across subdomains. On a standard single-domain install, the domain without the dot is correct.

Fix 4: Rename .htaccess

Via FTP, rename .htaccess to .htaccess_old in your WordPress root. A corrupted or conflicting .htaccess can produce unexpected redirect behaviour that interferes with the login authentication flow, particularly if it contains redirect rules that change the URL structure during the login sequence.

Test the login without .htaccess. If login works, go to Settings > Permalinks in wp-admin and click Save Changes to regenerate a fresh .htaccess. Then compare the original file against the new one to identify which rule was causing the problem.

Fix 5: Disable caching plugins

Caching plugins should never cache the wp-login.php page or any wp-admin page, doing so breaks authentication. If a caching plugin is misconfigured, it may serve a cached (stale) login page that strips or ignores the authentication response headers.

Disable all plugins by renaming /wp-content/plugins/ to /wp-content/plugins_disabled/ via FTP, then test the login. If it works, the issue is plugin-related. Re-enable plugins one at a time to isolate the culprit, start with caching plugins (WP Rocket, W3 Total Cache, WP Super Cache) and security plugins (Wordfence, iThemes Security) as these interact most directly with the login process.

Once you identify the plugin, check its settings for options related to login page caching, cookie handling, or login protection. Most caching plugins have specific settings to exclude wp-login.php and wp-admin, make sure these are enabled.

Fix 6: Check SSL and redirect configuration

If your site has both HTTP and HTTPS active, or if you have both www and non-www versions resolving, a redirect chain can cause the login loop. The sequence might be: login at http://www.yourdomain.com/wp-login.php, cookie set for that URL, redirect to https://yourdomain.com/wp-admin/, browser considers it a different origin and doesn't send the cookie. The fix is ensuring a single canonical URL is used consistently throughout the site and that redirects happen before WordPress sets cookies, not after.

Check that your SSL certificate covers both www and non-www versions of your domain, and that your .htaccess redirects all HTTP traffic to HTTPS in a single step rather than through a chain of redirects.

LSCache is configured to never cache admin or login pages

HostBible's LiteSpeed setup excludes wp-admin and wp-login.php from caching by default, so login loops from caching misconfiguration don't happen here.

View Hosting Plans