ERR_TOO_MANY_REDIRECTS: What Causes the Redirect Loop and How to Fix It
ERR_TOO_MANY_REDIRECTS (Chrome's wording; Firefox says "The page isn't redirecting properly", Safari says "too many redirects occurred") means one thing: your site sent the browser in a circle. The browser requested a URL, got told to go somewhere else, followed that, got told to go somewhere else again, and eventually landed back where it started. After roughly 20 hops with no real page at the end, the browser stops and shows the error rather than looping forever.
The important part: the loop is almost never random. It's two rules that each think they're right, fighting each other on every request. One rule says "force HTTPS", another quietly downgrades to HTTP, and the two hand the request back and forth. Your job is to find the two rules. This post walks through the usual suspects in the order we actually run into them during audits, then shows you how to trace the exact chain so you're fixing the real loop instead of guessing.
The single most common cause: Cloudflare Flexible SSL
If your site is behind Cloudflare and you're seeing this error, check the SSL/TLS mode first. It's the cause more often than everything else combined.
Here's the mechanism. Cloudflare's SSL/TLS encryption mode has a setting called Flexible. In Flexible mode, Cloudflare talks to your visitor over HTTPS but talks to your origin server over plain HTTP. Now suppose your origin server (or your CMS, like WordPress) is also configured to "force HTTPS" and redirects any HTTP request to HTTPS. Watch what happens:
- Visitor requests
https://example.com. - Cloudflare receives it over HTTPS, then forwards to your origin over HTTP.
- Your origin sees an HTTP request and returns
301 -> https://example.com. - Cloudflare passes that redirect back to the visitor, who requests
https://example.comagain. - Go to step 1. Forever.
The fix is to change the Cloudflare SSL/TLS mode from Flexible to Full or Full (strict). Full (strict) is correct if you have a valid certificate on your origin (Cloudflare's free Origin CA cert counts). This single change resolves the majority of Cloudflare-related loops we see. Do not "fix" it by removing the HTTPS redirect on your origin; that just papers over a broken TLS setup.
Conflicting www and HTTPS rules
The second-most-common loop comes from redirect rules that don't agree on the final destination. You want, say, https://www.example.com as canonical. But you've configured:
- Rule A: redirect non-www to www.
- Rule B: redirect www to non-www (left over from an old config, or added in a second place).
Every request now ping-pongs: www sends you to non-www, non-www sends you back to www. Same thing happens when an HTTP-to-HTTPS rule and a host rule are evaluated in the wrong order, each stripping the other's work.
The cure is to pick exactly one canonical host and make every other variant point at it in a single hop, with no rule pointing back. If you're deciding which host to standardise on, our guide to www vs non-www covers the choice and the clean redirect config for each server.
WordPress plugin and settings conflicts
On WordPress specifically, three things fight over redirects: the Site Address (URL) and WordPress Address (URL) fields in Settings > General, an SSL plugin (Really Simple SSL and similar), and any redirect or security plugin. We've seen loops caused by:
- The Site URL set to
http://while an SSL plugin forceshttps://. - Two plugins both adding HTTP-to-HTTPS redirects.
- A caching layer serving a cached
301after you've already fixed the rule.
Work through it in order: set both URL fields in Settings > General to your exact canonical (https://www.example.com or whichever you chose), then deactivate redirect-related plugins one at a time, clearing the cache between each, until the loop stops. The plugin that was live when it stops is your culprit.
Cookie-based and session loops
Some loops only happen for logged-in users or after a login attempt, and clear up in an incognito window. That points at a cookie. A common pattern: the app redirects to /login when a session cookie is missing, but the login page can't set the cookie (wrong Domain, Secure flag on an HTTP page, or SameSite blocking it), so every load of /login still looks logged-out and redirects to /login again.
If clearing cookies for the domain fixes it temporarily, the cookie is the problem, not the redirect rule. Look at what the login response actually sets in the Set-Cookie header and whether the flags match the scheme and host the user is on.
Trailing-slash ping-pong
The subtlest one. Two systems disagree about whether URLs end in a slash. Your framework redirects /about to /about/, and a rewrite rule (or a reverse proxy) redirects /about/ back to /about. Neither is wrong on its own; together they loop. This shows up a lot behind CDNs and on static-site hosts where one layer adds slashes and another strips them.
Decide on one form, slash or no slash, and make sure only one layer enforces it.
How to actually diagnose it instead of guessing
Do these three things before you change any config, because the loop tells you exactly what's wrong if you look at it.
Clear cookies and try incognito first. This instantly separates a cookie loop (fixed by clearing) from a redirect-rule loop (still broken in incognito). Thirty seconds, and it halves your search space.
Watch the chain with curl. From a terminal:
curl -sIL https://example.com | grep -i -E 'HTTP/|location'
-I fetches headers only, -L follows redirects, and the grep prints just the status line and Location header for each hop. In a loop you'll see the same two URLs alternate:
HTTP/2 301
location: https://www.example.com/
HTTP/2 301
location: https://example.com/
HTTP/2 301
location: https://www.example.com/
That output names the two URLs fighting, which tells you whether it's www vs non-www, http vs https, or a slash mismatch.
Trace the full path in a browser tool. If you don't want to use curl, run the URL through our redirect checker. It lays out every hop with its status code (301, 302, 307, 308) so you can see where the chain turns back on itself. That same view is how you confirm a fix later: a healthy URL should reach a 200 in one hop, or zero.
Once you've identified the two rules in the loop, the fix is always the same shape: remove or correct one of them so the chain terminates at a real page. If your site has longer chains that stop short of a full loop but still cost you speed and crawl budget, our walkthrough on how to fix redirect chains and loops covers collapsing multi-hop redirects down to one.
Frequently Asked Questions
What does ERR_TOO_MANY_REDIRECTS actually mean?
It means the browser followed a chain of redirects that never reached a real page and instead looped back on itself. Browsers cap redirect-following at around 20 hops. When that cap is hit with no final 200 OK response, the browser stops and shows the error instead of looping indefinitely.
Why does the error go away in incognito mode?
Incognito starts with no cookies for the site. If the loop disappears there, a cookie is causing it, usually a session or login cookie that can't be set correctly (wrong domain, or a Secure flag on an HTTP page), so the app keeps redirecting as though the user is logged out. If the loop persists in incognito, it's a server-side redirect rule, not a cookie.
I'm on Cloudflare and getting this error. What do I check first?
Check your SSL/TLS encryption mode. If it's set to Flexible while your origin also forces HTTPS, Cloudflare talks HTTP to your origin, the origin redirects to HTTPS, and the request loops. Switch the mode to Full or Full (strict), which is the correct setting when your origin has a valid certificate.
How do I see the exact redirect loop?
Run curl -sIL https://yoursite.com in a terminal to print each hop's status code and Location header, or paste the URL into a redirect checker for a visual hop-by-hop trace. In a loop you'll see the same two URLs alternate, which identifies the two rules fighting each other.
Can a redirect loop hurt my SEO?
Yes. A looping URL returns no content, so Google can't index it, and crawlers waste crawl budget bouncing between the same URLs. If the loop is on an important page or your homepage, that page effectively drops out of search until you fix it. It won't penalise the rest of your site, but the affected URLs become unreachable.