How to Fix WordPress Login Redirect Loops (Cookies, URL Mismatch, Cache, Cloudflare)

WordPress login redirect loops feel like getting tailed in a bad neighborhood. You enter the right door, you know the password, and still you’re shoved back out to the sidewalk. Sometimes it shows up as ERR_TOO_MANY_REDIRECTS. Sometimes it just “refreshes” wp-login.php like it’s stuck on repeat.

I’ve fixed this enough times to know the pattern. The loop almost always comes from one of four culprits: cookies, a Site URL mismatch (http/https or www/non-www), a caching layer that won’t forget, or Cloudflare doing “helpful” things twice.

If you also need to confirm you’re using the right login path, I keep a quick reference bookmarked for finding and bookmarking your WordPress login URL.

The 5-minute checklist I run before touching anything risky

When I’m locked out, I want fast signals. No heroics yet, just simple tests that narrow the case.

1. Try Incognito mode: If Incognito mode works, it’s almost always cookies or cached redirects in your browser.
2. Confirm the exact URL you’re entering: Pick one and stick to it for now, https://example.com/wp-admin/ (not sometimes www, sometimes not).
3. Check if you recently changed anything using FTP or cPanel File Manager; investigate plugin conflicts: SSL switch, domain change, Cloudflare toggle, caching plugin update, security plugin install.
4. Temporarily bypass “pretty” redirects: If you have a forced redirect at Cloudflare plus one at your server plus one in WordPress, you’ve built a hall of mirrors.
5. Purge caches you control: Clear browser cache, WordPress cache plugin, host cache, then Cloudflare cache (in that order).
6. Test /wp-login.php and /wp-admin/ directly: If one works and the other loops, it’s a clue.
7. Look for the classic cookie clue: The message “Cookies are blocked or not supported” means WordPress can’t set the login cookie, so it can’t keep you logged in.

If the loop started after you enabled Cloudflare or switched to HTTPS, skip ahead to the Cloudflare section. That’s where the bodies are usually buried.

Fix the two most common causes: cookies and Site URL mismatch

Clear the cookie mess (and prove it’s the problem)

WordPress login relies on browser cookies. If the browser cookie is stale, blocked, scoped to the wrong domain, or marked “secure” while you’re hitting HTTP, WordPress keeps asking you to log in, because it can’t see a valid session.

Here’s what I do, in order:

• Use a private window first. It’s the cleanest test.
• Clear site cookies only (not your whole browser life). In Chrome: Settings → Privacy and security → Third-party cookies → See all site data and permissions → search your domain → Delete.
• Disable “aggressive privacy” for a minute: Some browser extensions strip cookies. Turn them off long enough to test.
• Stop mixing hostnames: Logging in at example.com but loading admin assets from www.example.com can break the session. Pick one canonical hostname and fix the rest.

If you’re working on a staging domain behind a basic auth prompt, that can also get weird. I’ve seen auth popups plus cached redirects cause a loop that looks like cookies, but isn’t.

Correct WordPress Address and Site Address (when you can’t even log in)

This is the classic trap: WordPress thinks the site is http:// but your server forces https://, or WordPress is set to www while Cloudflare rewrites to the apex domain. Result: redirect ping-pong.

If you can access the dashboard, the clean fix is here:

• WordPress Dashboard → Settings → General
• Set WordPress Address URL and Site Address URL to the same scheme/host (example: https://example.com)
• Save, then retry login

If you can’t access wp-admin, I usually go straight to WP-CLI because it’s quick and leaves an audit trail. If you need a refresher, I’ve got a full guide on WP‑CLI commands for quick WordPress updates, and the same approach applies here.

Example WP-CLI commands (run from the WordPress root folder):

• Check current values: wp option get home and wp option get siteurl
• Update both: wp option update home 'https://example.com' and wp option update siteurl 'https://example.com'

If WP-CLI isn’t available, use FTP or File Manager to access the wp-config.php file and hard-set it there to stop the bleeding with the configuration pair WP_HOME and WP_SITEURL:

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

Warning: Editing the database directly (phpMyAdmin, Adminer, raw SQL) works, but it’s high-risk, especially in the wp_options table or other database tables where the siteurl and home settings live. If you typo the domain or break serialization in other fields, you can take the site down in a louder way. If you must do it, back up first.

Also watch your server redirects. If .htaccess forces HTTPS and Cloudflare also forces HTTPS, that’s fine. If Cloudflare is set to “Flexible” SSL (more on that next) and your server forces HTTPS, that’s where loops are born.

Cache and Cloudflare: where good intentions go bad

Disable caching for login while you troubleshoot

A login page should not be cached. Neither should the redirects around it. During a loop, I want fewer moving parts.

• If you can still use WP-CLI: wp plugin deactivate --all (you can reactivate later)
• If plugin conflicts are suspected and WP-CLI is unavailable, use FTP or File Manager to rename plugins folder (you can rename it back later)
• Purge your caching plugin’s cache (menu varies by plugin, but it’s usually in the top admin bar or the plugin’s settings page)
• If your host has server cache, purge it too (managed hosts often do this in their control panel)

For background on why caching layers can cause “refreshing” login pages, Cloudways has a solid breakdown in their post on fixing WordPress login refreshing and redirecting.

Once you’re back inside, I always exclude these from any cache rule I control:

• /wp-login.php
• /wp-admin/
• Anything with ?loggedout=true or redirect_to=

Fix Cloudflare SSL mode and redirect settings (the big one)

When Cloudflare is in front of WordPress, the most common loop I see is this:

• Browser → Cloudflare over HTTPS
• Cloudflare → origin over HTTP (because SSL mode is “Flexible SSL”)
• Origin forces HTTPS
• Cloudflare keeps talking HTTP to origin
• Loop

Flexible SSL often causes loops if the SSL certificate on the origin isn’t configured for HTTPS. Here’s the path I check:

• Cloudflare Dashboard → SSL/TLS → Overview
• Set encryption mode to Full (strict) if your origin has a valid certificate
• Avoid Flexible for WordPress logins

Then I check the “extra” redirect knobs to force HTTPS correctly and avoid redirect rules fighting each other:

• Cloudflare Dashboard → SSL/TLS → Edge Certificates
• Review Always Use HTTPS and Automatic HTTPS Rewrites
• If you’re debugging a loop, I temporarily turn off Always Use HTTPS, confirm origin behavior, then re-enable one redirect source at a time
• Check your .htaccess file for bad redirect rules that conflict with Cloudflare

For a real-world example of how this loop shows up after switching WordPress and turning Cloudflare on, this Cloudflare Community thread on infinite HTTPS redirect loops mirrors what I see in client fixes.

Finally, make sure Cloudflare isn’t caching admin paths:

• Cloudflare Dashboard → Caching → (use Cache Rules)
• Create a bypass rule for /wp-admin* and /wp-login.php*

Warning: Temporarily disabling WAF rules can help confirm a false positive, but it’s a high-risk move. If you must test it, do it briefly, note the time, and turn it back on. I prefer allowing a specific challenge rule or whitelisting my IP over shutting the door completely.

When I stop tinkering and contact hosting support

If I’ve fixed cookies, confirmed home and siteurl, and Cloudflare is set to Full (strict), but WordPress login redirect loops keep dragging me back, especially after a site migration, I call the host to regain wp-admin access.

I ask them to check, in plain terms:

• Server-level redirects (Nginx rules, Apache vhosts, control panel “Force HTTPS” toggles)
• Any built-in cache like Varnish, Nginx FastCGI cache, or a host “edge cache”
• Security layers (ModSecurity, bot protection) blocking wp-login.php POST requests or causing 403 Forbidden error
• Whether PHP sessions or disk permissions are failing (rare, but nasty)

I also send them one detail they can act on fast: the exact URL chain (from browser dev tools or a HAR), the ERR_TOO_MANY_REDIRECTS error code, and whether Cloudflare proxy (orange cloud) is on.

Conclusion

WordPress login redirect loops aren’t random; they’re a trail of small decisions that don’t agree with each other. I fix them by shrinking the problem: clean cookies, clear browser cache, make the site URLs match reality, then peel back caches and Cloudflare settings until there’s only one redirect in charge. Once the loop breaks, refresh your permalink settings to ensure everything is synced, then re-enable layers one at a time, slow and careful, like resetting a trap. If you’re stuck, start with the checklist, keep your Site URL consistent everywhere, and if issues return after a theme or plugin update, check the .htaccess file one last time.