The page won't load. Instead: "This page isn't working — ERR_TOO_MANY_REDIRECTS." Your site was fine yesterday, and now it's stuck in some invisible loop. What happened?
You've got a redirect loop — page A sends visitors to B, and B sends them right back to A, forever. After a handful of hops, the browser throws its hands up and stops. Let's find the cycle.
What's happening
A redirect tells the browser "go here instead." A redirect loop is when those instructions form a circle:
A → B → A → B → A → … (browser gives up)
Browsers follow only so many redirects (usually ~20) before bailing with this error, to avoid looping endlessly. So the message really means: "I kept getting redirected and never arrived anywhere."
The usual culprits
| Cause | The loop it creates |
|---|---|
| HTTP ↔ HTTPS misconfig | http→https at one layer, https→http at another |
| WWW ↔ non-WWW | example.com→www and www→example.com |
| Trailing slash rules | /page→/page/ and /page/→/page |
| CDN + origin both redirecting | Each forces a rule the other undoes |
| Bad app/CMS redirect rule | A redirect pointing (directly or indirectly) at itself |
| Login/auth loop | "Not logged in → login → not logged in" |
The classic is the HTTPS or WWW one: two layers (say your CDN and your app) each "fix" the URL in opposite directions, bouncing the visitor back and forth.
How to diagnose it
- Open the network tab. Watch the chain of 301/302s — you'll literally see it ping-pong between two URLs. That's your loop.
- Check each redirect layer. CDN, load balancer, web server, and app can each add redirects. Two of them disagreeing is the usual cause.
- Look at recent changes. A new HTTPS rule, a CDN setting, or a CMS plugin often starts it.
- Check cookies. Auth loops can be cookie-related — a stale or blocked cookie that never lets login "stick."
How to fix it
- Pick one canonical form and enforce it once. Decide on https + (www or non-www) + a trailing-slash rule, and apply each redirect in one place only — not at every layer.
- Make sure the destination doesn't redirect back. The end of a redirect should return a 200, not another redirect.
- Coordinate CDN and origin. If your CDN forces HTTPS, your origin shouldn't also be redirecting in a way that conflicts.
The core fix: redirect loops come from two rules fighting. Find the two layers disagreeing, and let only one of them own the redirect.
Catch it before users do
A redirect loop takes a page completely offline, and it often appears after an innocuous config change. Because it sits right at the entrance, monitoring your key URLs — and confirming they end on a 200, not an endless redirect — turns a silent, total outage into an instant alert.
The bottom line
| In one line | |
|---|---|
| What | A redirect cycle the browser refuses to keep following. |
| Usual cause | Two layers (HTTPS/WWW/slash) redirecting against each other. |
| Find it | The network tab shows the ping-pong chain. |
| Fix | One canonical rule, enforced in one place. |
ERR_TOO_MANY_REDIRECTS looks scary but it's almost always two well-meaning rules in a tug-of-war. Pick one canonical URL form, enforce it once, and make sure the finish line is a real page.
More on redirects: 301 vs 302; watch your URLs with web monitoring.