Infinite redirect loops
An infinite redirect loop occurs when URL A redirects to B which redirects back to A (directly or through a cycle), so the request never reaches a final response. Browsers and crawlers stop after a few hops and report an error. Loops make pages completely unreachable, blocking both users and indexing.
What a redirect loop is
A redirect loop happens when following a redirect leads back to a URL already visited in the chain. The simplest case is A → B → A, but loops can span several hops. Because there is no terminating response, clients cannot complete the request.
Browsers surface this as a 'too many redirects' error after a hop limit; crawlers similarly give up and treat the URL as a failed fetch.
Common causes and how to break them
Loops usually come from conflicting rules. Classic examples: a force-HTTPS rule and a force-HTTP rule fighting each other; a trailing-slash add rule and a strip rule cancelling out; a CDN redirect that disagrees with an origin redirect; or a canonical redirect pointing at a URL that redirects back. Case sensitivity and host normalisation can also collide.
To break a loop, trace the redirect chain hop by hop and find where it returns to an earlier URL. Then reconcile the conflicting rules so every URL converges on exactly one final destination in a single direction, ideally one hop.
- Conflicting HTTPS/host/slash rules are common causes
- Trace the chain hop by hop to find the cycle
- Make every URL converge on one final destination
Operator checklist
When a URL reports 'too many redirects', map the full chain and locate the repeat. Reconcile overlapping redirect rules (HTTPS, host, slash, canonical) so they agree. Re-test the URL and related variants to confirm single-direction, ideally single-hop resolution.
How it appears in analytics and logs
A redirect loop means a URL never resolves to a final response because the redirects cycle. Crawlers abandon the URL after a hop limit, so the page cannot be fetched or indexed — a hard failure, not a slow degradation.
Diagnostic use case
Detect and break redirect loops that make pages unreachable, and identify the conflicting rules that create the cycle.
What WebmasterID can help detect
WebmasterID can surface URLs where crawlers receive repeated redirects without resolving, helping you spot loops before they keep pages out of the index.
Common mistakes
- Force-HTTPS and force-HTTP (or add-slash and strip-slash) rules fighting.
- A CDN redirect disagreeing with an origin redirect.
- A canonical redirect pointing at a URL that redirects back.
Privacy and accuracy notes
Redirect-loop diagnosis concerns URLs and redirect rules, not personal data. WebmasterID reports redirect patterns for crawler traffic without exposing individual visitors.
Related pages
- Redirect chains and loops
A redirect chain is a sequence of hops (A to B to C) before reaching the final URL; a redirect loop never resolves. Chains waste crawl budget, slow signal consolidation, and can stop crawlers following beyond a hop limit. The fix is to point each source straight at the final destination.
- HTTP vs HTTPS canonicalization
https://example.com and http://example.com are different URLs, so serving content on both creates duplication and mixed signals. The standard fix is to force HTTPS: 301-redirect HTTP to HTTPS, reference only HTTPS in links, sitemaps, and canonicals, and use HSTS so clients default to the secure scheme.
- Website observability
Spot URLs where crawlers loop through redirects without resolving.
Sources and verification notes
- MDN — Redirections in HTTPDocuments redirect behaviour and loop detection by clients.
- Google Search Central — Redirects and Google Search
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.