Most people treat a too many redirects error like a mystery outage — they clear the cache, restart the server, and pray. It isn’t a mystery. A redirect loop is almost always two rules quietly disagreeing about where a URL should end up: one insists on https://, the other bounces you back to http://; one wants a trailing slash, the other strips it. The browser watches the request ping-pong about twenty times, decides you’re in a circle, and gives up with ERR_TOO_MANY_REDIRECTS. Once you see it as a disagreement rather than a glitch, fixing it takes minutes instead of an afternoon.
What “too many redirects” actually means
When you request a page, the server can answer with a redirect — a 301, 302, 307, or 308 status plus a Location header pointing somewhere else. Your browser follows it, requests the new URL, and repeats. That’s normal: a single hop from http to https happens on nearly every site. A loop happens when following the chain never resolves to a final 200 response. Chrome caps this at roughly 20 hops, then throws the error rather than looping forever. Firefox says “The page isn’t redirecting properly.” Same underlying fault: the redirect target eventually points back to a URL you’ve already visited.
The one framework that explains every redirect loop
Every loop reduces to a single question: which URL is canonical, and does every rule agree on it? A healthy site has exactly one canonical shape for each page — say https://example.com/page/ with HTTPS, no www, and a trailing slash. Redirects exist to funnel all the other variants to that one address. A loop appears the moment two systems hold different opinions about the canonical shape and each tries to “correct” the other’s output. Rule A rewrites to add www; Rule B rewrites to remove it. Neither wins, and the request oscillates. Keep this in mind while you diagnose: you are not hunting a bug, you are hunting a contradiction.
Is it your browser or the server?
Before touching server config, spend 30 seconds ruling out the client. The error is server-side if it happens for everyone, everywhere. It’s local to you if it’s tied to your session. Run this triage:
- Try incognito / private mode. If the error vanishes, a stale cookie or cached redirect on your machine is the culprit, not the server.
- Try a second device or network. Phone on mobile data reproducing it means the fault is on the server.
- Clear cookies for that domain specifically. Corrupt session cookies are the number-one cause of login-page loops.
- Check the URL you typed. A cached 301 from a previous config can stick in the browser for months; incognito bypasses it.
If incognito fixes it, tell your visitor to clear cookies and move on. If it reproduces everywhere, the problem is in your redirect rules, and the rest of this guide is for you.
The six mechanisms that create a server-side loop
Almost every server-side loop traces to one of these contradictions:
- HTTPS and www rules fighting. One rule forces HTTPS, another forces a domain variant, and they trigger in the wrong order so each undoes the other.
- CDN or proxy SSL set to “Flexible.” Cloudflare’s Flexible SSL talks to your origin over HTTP while your origin has its own “force HTTPS” rule. The origin redirects to HTTPS, the CDN downgrades to HTTP, forever. This single setting causes a huge share of loops.
- CMS site URL mismatch. WordPress with its Site Address set to the non-www URL while a server rule forces www — the app and the server each redirect toward their own version.
- Two redirect systems stacked. An
.htaccessrule plus a plugin plus a host-level rule all managing the same hop. - Trailing-slash disagreement. The app adds a slash, a rewrite rule strips it, repeat.
- A self-referencing rule. A redirect whose target matches its own condition, so it fires on its own output.
A worked example: tracing the loop with curl
Guessing is slow; tracing is fast. curl follows and prints every hop without a browser cache muddying the picture. Run:
curl -sIL https://example.com/ | grep -i "HTTP/\|location"
Suppose the output reads:
HTTP/2 301→location: https://www.example.com/HTTP/2 301→location: https://example.com/HTTP/2 301→location: https://www.example.com/
There’s your contradiction in black and white: one rule sends the bare domain to www, and another sends www straight back to the bare domain. The fix isn’t to delete a redirect — it’s to pick a single canonical (say, the www version), point every other variant to it, and make sure the canonical URL itself returns a 200, not another 301. Re-run the curl command after the change; a healthy chain is at most one or two hops ending in HTTP/2 200.
The reverse-proxy trap most guides miss
Here’s the mechanism that stumps experienced developers. When your site sits behind a CDN, load balancer, or reverse proxy, the connection between the proxy and your origin is often plain HTTP even though the visitor is on HTTPS. Your origin sees an HTTP request and its “force HTTPS” rule fires — but the visitor is already on HTTPS, so the proxy dutifully downgrades and forwards it as HTTP again. Neither side is wrong in isolation; together they loop.
The correct fix is to make the origin trust the proxy’s protocol header instead of the raw connection. Check X-Forwarded-Proto: only force a redirect to HTTPS when that header equals http, not when the local connection is HTTP. In Nginx that’s if ($http_x_forwarded_proto = "http"); in Apache, a RewriteCond %{HTTP:X-Forwarded-Proto} =http. On Cloudflare, switching SSL mode from Flexible to Full (strict) and installing a real origin certificate eliminates the downgrade entirely. This one setting resolves a large fraction of “everything looks correct but it still loops” cases.
Cookie and login redirect loops
A distinct family of too many redirects errors has nothing to do with HTTPS or www. It’s authentication logic. The page checks “is the user logged in?”, decides no, and redirects to the login page — but a corrupt or misconfigured session cookie means the login page also thinks the user isn’t authenticated and bounces back. The two pages disagree about session state and trade the visitor endlessly. Symptoms: the error only hits logged-in areas or the login form itself, and incognito mode fixes it because it starts with a clean cookie jar. Fixes live in cookie configuration — a wrong cookie domain (.example.com vs example.com), a Secure flag on a cookie being set over HTTP, or a session store that isn’t persisting. Clearing the domain’s cookies resolves it for the individual user; fixing the cookie attributes resolves it for everyone.
Fixing it: the durable pattern
Patching one rule until the error disappears tends to spawn the next loop a month later. The durable fix is structural:
- Declare one canonical shape and write it down: protocol, www-or-not, trailing-slash-or-not. Every decision below flows from this.
- Consolidate to a single redirect layer. Handle protocol and domain canonicalization in one place — the edge/CDN, the server, or the app — never two of them managing the same hop.
- Fix the CMS site URL to match your canonical exactly, so the application stops issuing competing redirects.
- Use exclusion conditions so a rule never fires on its own output — the classic
RewriteCond %{HTTPS} offguard prevents self-reference. - Set your SSL/proxy mode to Full (strict) if a CDN sits in front, and trust
X-Forwarded-Protoat the origin.
After each change, re-run the curl trace rather than reloading the browser — browser caches lie, and a 301 you thought you deleted can still be cached client-side for months.
Why a redirect loop quietly wrecks your SEO
A too many redirects error isn’t just a broken page for humans — it’s a wall for Googlebot. A crawler hitting a loop wastes crawl budget, can’t index the affected URLs, and over time drops them from results. Because loops often hit only certain URL variants (the www version, say, while the bare domain works), you can lose rankings for a swath of pages while your homepage looks perfectly fine — which is exactly why these go unnoticed for weeks. If organic traffic to a section falls off a cliff with no obvious content change, a redirect loop on a canonical variant is a prime suspect. This is where rank tracking earns its keep: SEO Rocket’s top-100 rank tracking surfaces the sudden position drop, and its real-crawler site audit follows redirect chains the same way Googlebot does, flagging loops and multi-hop redirects before they cost you indexed pages.
Catching loops before users and Google do
The cheapest redirect loop is the one you catch in staging. Any config change touching HTTPS, domains, CDN settings, or CMS URLs should be followed by a full-site crawl, because loops love to appear on obscure URL patterns — an old paginated path, a category variant, a language subfolder — that no human tests by hand. A crawler that follows redirects end to end will find the hop that never resolves. Running SEO Rocket’s site audit on a schedule turns “we found out when customers emailed us” into “we found it in the Tuesday crawl,” and it does the same for the slower-burning problems — redirect chains longer than two hops, mixed 302s where 301s belong, and canonical tags that point somewhere the redirects contradict.
Frequently asked questions
Why do I get “too many redirects” on only one browser?
Because the loop is cached locally, not live on the server. A previous 301 or a stale cookie is stored in that browser and keeps replaying. Clear the site’s cookies and cached data, or test in incognito. If it works everywhere except one browser profile, the fault is client-side and the server is fine.
Does clearing cookies fix a redirect loop permanently?
Only for you, and only if the loop was cookie-driven. Clearing cookies resolves a stuck session for a single visitor, but if the underlying cookie attributes or server rules are misconfigured, the next visitor with the same cookie state hits the same wall. Clear cookies to unstick yourself, then fix the root cause on the server.
Is a 301 or 302 to blame for the error?
Either can loop — the status code doesn’t cause the loop, the target does. A 301 that points back to a URL already in the chain loops just as surely as a 302. That said, prefer 301 (or 308) for permanent canonicalization so browsers and Google cache the correct hop; scattering 302s where 301s belong causes its own indexing headaches.
Can Cloudflare cause too many redirects?
Frequently. The usual trigger is SSL mode set to “Flexible,” which forces HTTP to your origin while your origin forces HTTPS back. Switch to Full (strict) with a valid origin certificate, and remove any duplicate “always use HTTPS” rule that the origin is also enforcing. One layer should own the redirect, not two.
The bottom line
A too many redirects error is never random — it’s a contradiction you can read straight off a curl trace. Find the single URL two rules disagree about, decide once which shape is canonical, consolidate the redirect into one layer, and make sure your proxy passes the real protocol through. Do that and the loop doesn’t come back. Then crawl the site on a schedule so the next contradiction shows up in a report instead of an angry email — because the pages caught in a silent loop are the ones Google quietly stops ranking while your homepage looks perfectly healthy. That kind of monitoring, built on a playbook proven across 1,000,000+ ranking pages, is the difference between a five-minute fix and a lost quarter of traffic.
