A redirect chain is what you get when one URL redirects to another, which redirects to another, before a browser or crawler finally reaches the page it was after. A single redirect is normal and healthy. A chain of three, four or five is a quiet tax on every visit, and most site owners never notice because the browser follows the whole sequence automatically and the address bar only ever shows the final destination.
What a chain actually looks like
The classic chain builds up one well-intentioned rule at a time. You add HTTPS, so http:// redirects to https://. You standardise on the www host, so the bare domain redirects to www. You later move a page, so the old path redirects to the new one. Stack those together and a link someone shared years ago now resolves like this:
http://example.com/old → https://example.com/old → https://www.example.com/old → https://www.example.com/new
That is four requests to serve one page. The destination is correct, but three of those four requests exist only to tell the client to ask again somewhere else.
Every hop is a round trip
Each redirect is a complete HTTP request and response. On a fresh connection to a new host, the client may also pay for a DNS lookup, a TCP handshake and a TLS negotiation before it even receives the 301 that sends it onward. On mobile networks, where latency dominates, a single extra hop can add hundreds of milliseconds. Multiply that across a chain and you have added real, measurable delay to your slowest and most impatient visitors — the ones arriving from search, social and email, precisely the traffic redirects are meant to preserve.
This is also why redirect chains hurt Core Web Vitals. The time spent bouncing between hops is time before the first byte of real HTML arrives, so it pushes out Time to First Byte and, downstream, Largest Contentful Paint. The page might be beautifully optimised; the chain in front of it undoes some of that work before rendering even starts.
Where link equity leaks
Search engines pass ranking signals through redirects, and Google has said that 301 and 302 redirects no longer lose PageRank simply for being redirects. That is the modern position, and it is reassuring. But it comes with caveats worth taking seriously. Crawlers do not follow chains indefinitely: Googlebot will follow a run of redirects, but long chains are followed fewer hops per crawl and the far end may be treated as a soft error or left unconsolidated. Mixing signal types — a 302 buried inside a chain of 301s — muddies whether the move is permanent, which is the exact signal you want to send cleanly. And every hop is another rule that can rot: if one link in the chain breaks later, everything behind it becomes unreachable and any equity it carried evaporates. A single hop has none of these failure modes.
How crawlers treat long chains
Crawl budget is finite. When a bot spends requests walking redirects, that is budget not spent discovering and refreshing real content. On a small site this is invisible; on a large one with thousands of legacy URLs each resolving through three or four hops, it is a meaningful drag on how quickly new and updated pages get indexed. Consolidation of signals to the canonical URL also happens faster and more reliably when the path is short. If you want a move to be understood as permanent and singular, give the crawler one unambiguous 301 to the final URL.
Collapse the chain to one hop
The fix is to make every legacy URL point directly at its final destination in a single redirect, rather than handing off through intermediaries. Instead of http → https → www → final, write rules that jump straight to the end: any request for the old URL, on any scheme or host, returns one 301 to the canonical https://www.example.com/new. Order your server or edge rules so the scheme and host normalisation and the path change are resolved together, not in separate sequential redirects. If you use an edge platform, a single rewrite-then-redirect at the edge can replace a stack of origin rules.
Pair this with HSTS Studio to confirm your HSTS policy is doing its job: with a Strict-Transport-Security header in place, compliant browsers upgrade http:// to https:// internally and skip the first redirect entirely, shortening the chain before a request is ever sent. And check the certificate on every host in the path with TLS Studio, because a chain that crosses hosts is only as trustworthy as the weakest certificate along it.
Find them before they cost you
Chains hide well because they work — the visitor lands on the right page and no error appears. The only way to see them is to trace the full sequence of hops, not just the final result. Run your canonical URLs, your top inbound links and your old campaign URLs through a checker that lists every hop with its status code, then look for any path longer than one redirect. Anything that reaches its destination in two or more hops is a candidate for flattening. Fix the highest-traffic offenders first, retest, and confirm each now resolves in a single 301.
Redirects are supposed to be invisible plumbing. Kept short, they are. Left to accumulate, they quietly slow your site and blur the very ranking signals you set them up to protect.