Redirect Chains and Loops: Auditing and Cleaning Them at Scale
A redirect chain is when one URL redirects to another, which redirects to another, before finally reaching a real page. A loop is when that path circles back on itself and never resolves. Both waste crawl, slow users down, and leak a little link equity at every hop. On a site that has been through a few migrations, they accumulate quietly until they are everywhere.
Why chains and loops hurt
Every redirect is a round trip. A chain of three means the user and the crawler make several requests to reach one page, which slows loading and burns crawl budget. Search engines will follow a limited number of hops before giving up, so a long chain can end with the destination never being reached. Loops are worse: they resolve to nothing, so the URL is effectively dead while looking alive.
Chains versus loops
| Type | Behaviour | Result |
|---|---|---|
| Single redirect | A to B, B is a 200 | Healthy, ideal state |
| Chain | A to B to C to D (200) | Wasted hops, leaked equity, risk of being dropped |
| Loop | A to B to A, never a 200 | Dead URL, crawl error, no destination |
Scroll table horizontally →
How many hops is too many
Google has said it will follow up to around ten hops before giving up, so a two-hop chain will not immediately drop your page from the index. That number reassures people into ignoring chains, which is the wrong lesson. The problem is rarely a single clean two-hop redirect. It is what happens across a large site over several migrations, where thousands of URLs each carry a chain, and where a few of those chains quietly exceed the limit or break in the middle.
There is also a cost well before you hit any limit. Every hop is a real round trip that a user on a slow mobile connection waits through, so chains hurt performance and, indirectly, the experience signals that feed into rankings. Every hop is also a chance for something to break later, when someone edits one rule without realising it sits in the middle of a chain. And each redirect passes along slightly less than the full value of the original link.
So the honest answer is that one hop is fine, two is tolerable, and anything beyond that is technical debt you should clear on sight. Do not aim to stay under Google’s limit. Aim for a single hop everywhere, because that is the only state that does not slowly degrade as the site changes around it.
Finding them at scale
A crawler like Screaming Frog or Sitebulb can report the full redirect path, not just the first hop, which is the setting people forget to enable. Crawl the site, then filter to any URL with more than one redirect in its path, plus anything that never resolves to a 200. On a large site, also crawl your list of known old URLs from past migrations, because those are where chains hide.
Server logs add the missing piece: they show which chains Googlebot is actually hitting, so you can prioritise the ones wasting real crawl. Our guide to log file analysis covers pulling that.
Collapsing them safely
The fix is simple to state: every redirect should be a single hop to the final destination. For each chain, find the first URL and the final 200 URL, then rewrite the rule so the first points straight to the last.
# Before: a three-hop chain
/a -> /b [301]
/b -> /c [301]
/c -> /d [200]
# After: every source points to the final URL
/a -> /d [301]
/b -> /d [301]
/c -> /d [301]Keep the intermediate rules in place, pointing to the final destination, so any old link to /b or /c still lands in one hop. Then update your internal links to point at /d directly, so your own site never sends crawl into a redirect at all. Internal links to redirecting URLs are a needless tax you control completely.
Preventing them coming back
Cleaning chains once is satisfying and temporary. They come back because the causes are structural, so the prevention has to be structural too. The biggest source is redirects stored in a flat list that nobody prunes: every migration appends new rules on top of the old ones, and over a few years the list becomes a maze. Keeping that list as a maintained document, where new rules are checked against existing ones, stops most new chains before they form.
Chains form because each migration adds a new layer on top of the old rules without cleaning up. The prevention is process. When you next change URLs, map to the current final destinations rather than the previous URLs, and re-run a redirect crawl after launch to catch new chains before they settle. Keep the redirect map as a living document, not a one-off spreadsheet.
The takeaway: redirect chains and loops are a slow tax that builds up over years of migrations. Crawl for the full path, collapse every chain to a single hop, fix internal links to skip redirects entirely, and re-crawl to confirm. It is tedious at scale, which is why it sits inside our site migration engagements and any cleanup after a messy replatform.