Redirect Loop

A redirect loop is a redirect configuration that circles back on itself — A sends you to B, B sends you back to A, forever — so the request never reaches an actual page. Users get the browser's ERR_TOO_MANY_REDIRECTS wall, Googlebot gets nothing to index, and every ranking and backlink signal pointed at the looping URL is stranded until someone fixes the config.

Unlike its cousin the redirect chain, which is slow but arrives, a loop is a full outage wearing a 301 costume.

Diagnosing ERR_TOO_MANY_REDIRECTS in two minutes

The browser error tells you a loop exists but not where. curl tells you where:

$ curl -sIL --max-redirs 8 https://example.com/account/

HTTP/2 301
location: https://www.example.com/account/    <- server rule: force www

HTTP/2 301
location: https://example.com/account/        <- CDN rule: strip www

HTTP/2 301
location: https://www.example.com/account/    <- and around we go

curl: (47) Maximum (8) redirects followed

Two rules, written by two people, in two systems, each undoing the other. That's the anatomy of nearly every loop: not one broken rule but two correct-looking rules fighting. The origin server wants www, the CDN wants bare domain, and neither layer can see the other. Diagnosis is reading the location headers until you spot the repeat, then asking which layer issued each one (response headers like server: or cf-ray: usually give it away).

Important gotcha while testing: browsers cache 301s aggressively. After you fix the server, your browser may keep replaying the cached loop — test in a private window or with curl, which never caches, before declaring the fix dead.

Loop causes and how each one is diagnosed

How to check it on your own site

1. Crawl and filter for the failure. Screaming Frog reports loops under Response Codes → Redirect loop; any URL whose redirect path revisits an earlier URL gets flagged. Zero flagged URLs is the pass condition.
2. Manually test the four base variants — http/https × www/bare — with curl -sIL --max-redirs 8. Loops love living in the protocol/host normalization layer, and those four requests exercise all of it. (While you're there, confirm HTTP actually lands on HTTPS in one hop — how to force HTTPS properly.)
3. Check Search Console → Indexing → Pages → "Redirect error." That bucket contains both loops and over-long chains; every URL in it is unreachable to Google through its redirect path.
4. Reproduce conditionally. If users report the error but your tests pass, the loop is state-dependent: test with cookies cleared, from another country (VPN), with a mobile user-agent, and logged out. Conditional loops are the ones that survive months because the developer's own browser always has the magic cookie.
5. After fixing, verify with curl first, browser second — and if the loop was cached by a CDN, purge it there too before trusting any test.

Common audit mistakes

• Testing only in a browser. Between browser 301 caching and CDN caching you can chase a ghost for an hour. curl is the source of truth.
• Fixing the loop by deleting all redirects on the URL. Now the old URL 404s and its backlink equity is gone. The goal is one working redirect, not zero.
• Looking for the loop in one config file. Loops are almost always cross-layer — CDN vs. origin, plugin vs. .htaccess. If you've read one config and found nothing, the answer is in the layer you haven't read. (Full layer-by-layer method in redirect chains and loops.)
• Missing conditional loops in the audit. A crawl from a US datacenter with no cookies won't trip a geo-redirect loop that hammers your European logged-in users. Vary geo, UA, and cookie state on money paths.
• Declaring victory without purging caches. The config is fixed, the CDN still serves the cached 301 pair, users still see the error, and the ticket gets reopened with everyone slightly angrier.

FAQ

What does ERR_TOO_MANY_REDIRECTS actually mean?

Chrome followed about 20 redirects without reaching a page and gave up (Firefox says "The page isn't redirecting properly"). It means loop — or an absurdly long chain — somewhere between the browser and a real 200 response.

Can a redirect loop get pages deindexed?

Yes, with time. Google first marks the URL "Redirect error" and keeps the last indexed copy briefly, but a loop that persists gets the URL dropped — it's indistinguishable from a page that no longer exists. Fix within days, not quarters.

Why do I get the error but my colleague doesn't?

Conditional loop or cached 301s. Different cookie state, geography, or browser cache means you two are literally traveling different redirect paths. Clear cookies and retest in a private window before comparing notes.

Why did switching my CDN's SSL setting cause a loop?

In "flexible" SSL modes the CDN talks to your origin over plain HTTP. If the origin has a force-HTTPS rule, it redirects that request back to HTTPS, the CDN downgrades again, and the loop is complete. Set the CDN to full/strict TLS and give the origin its own certificate.

Is a redirect loop worse than a redirect chain?

Yes, categorically. A chain costs latency and crawl efficiency; a loop costs availability — no user or crawler gets through at all. Chains are tech debt; loops are incidents.