What Is a Redirect Chain?

A redirect chain appears when an address does not lead straight to its destination but to another that redirects in turn, and so on. Instead of A to C, the browser walks A, then B, then C, and only then receives the page.

Each link is a complete request. If the hop changes domain or protocol, DNS has to be resolved again, the connection opened again and TLS negotiated again. That is why a chain's cost grows far faster than the number of hops suggests.

They are almost never built deliberately. They accumulate: a migration changed the URL structure, later everything moved to HTTPS, then www was unified one way or the other, and each step added its own rule without reviewing the earlier ones. The result works, and that is precisely why nobody looks at it.

The extreme case is the loop: A redirects to B and B back to A. The browser detects it after a few attempts and shows an error, making the page entirely unreachable. It is rare, and when it happens the two rules usually come from different people at different times.

One distinction decides whether a chain is a problem or a curiosity: who walks it. A user arriving from an old bookmark pays it once and moves on. The crawler walks it every time it returns, and chains usually affect whole families of URLs rather than a single one.

So the same fault can be irrelevant on a blog with thirty articles and expensive in an e-commerce shop with twenty thousand product pages: there a misplaced rule multiplies with every product, every filter and every variant.

The cost lands in three different places, and separating them helps because they are fixed differently.

For the visitor, each hop is waiting before anything is visible. It carries over in full to TTFB, which in turn is the first sub-part of LCP. A three-hop chain can add more delay than any image optimisation afterwards saves.

For crawling, each hop is a request the crawler spends without reaching new content. On a site with thousands of URLs that competes directly with the pages you want it to look at, and it shows in the indexing of the deeper ones.

For maintenance, every added rule is one somebody will have to understand in two years. Long chains make people afraid to touch the configuration file, and from then on they only grow.

A fourth cost is almost never counted: the campaign one. An ad pointing at a URL with tracking parameters that lands in a chain pays the delay on every click, and those clicks are bought. The same chain that is a nuisance in organic traffic turns into money once the traffic is paid for.

It pays to check this from the advertiser's side rather than only the crawler's: take the destination URLs of live campaigns, follow them with their parameters in place, and count the hops. A five-minute check that rarely happens, because web analytics tools report on the session and not on the route before it.

Google's documentation states that its crawler follows redirect chains but expressly recommends avoiding them and always linking to the final destination. Google publishes no magic threshold number, and that absence gets misread in both directions.

Concluding "then it does not matter" is wrong, because the cost in time and crawl budget exists regardless of how many hops the system tolerates. Hunting for the exact number is equally wrong: the useful question is not how many Google withstands but how many are needed, and the answer is almost always one.

On passing authority, Google has stated that a 301 redirect involves no loss of PageRank. That settles an old worry and changes nothing above: the problem with chains is time and crawling, not strength.

For daily work the rule fits in one sentence: one hop is fine, two are tolerable while you clean up, three or more is an open task.

Another frequent confusion is treating all 3xx codes as interchangeable. A 301 says "this has moved permanently", a 302 says "check back here later". Marking a permanent move as temporary makes Google keep the old URL far longer than necessary.

In a chain the types also mix: a first 301 hop inherited from a migration followed by a 302 added for a promotion produces a route neither the crawler nor the team understands. When cleaning up, decide the type once, working backwards from the final destination.

For a single URL the command line is enough: request it following redirects and count how many 3xx responses appear before the 200. It is the fastest check and needs no installed tooling.

For the whole site you need a full crawl, listing every chain with its length and destination. That usually reveals the real pattern: nearly all chains share the same first hop, typically an old protocol or www rule applied to everything.

Cleaning up has two parts, and skipping the second is the usual mistake. First the rules get shortened: A now points straight at D, without B or C. Second, and more important, the links pointing at A get corrected, in internal linking as well as in campaigns and email signatures. Without that the redirect keeps running on every visit.

Then measure again by the same standard and watch TTFB in Search Console, remembering that field data takes weeks to reflect the change.

A practical note on checking: do it with the same user agent and protocol people actually arrive with. Some configurations redirect differently by device, and a chain invisible from the desktop may exist on mobile, which is where mobile-first indexing decides.

And record the result before touching anything. A list of the current chains with their lengths serves as a baseline; without it you cannot show afterwards that the work achieved something, and in a technical SEO audit that demonstration is half the job.

• Shortening the rules while internal links still point at the first link in the chain: it disappears from the report and keeps happening on every visit.
• Hanging a new rule off the old ones at every migration instead of rewriting the whole set from the final destination backwards.
• Using 301 and 302 without criteria: a permanent move marked as temporary leaves Google waiting for a return that will not come.
• Redirecting everything missing to the homepage rather than to an equivalent destination, which additionally turns an honest 404 error into a response that looks valid and is not.
• Measuring only from the command line with the clean URL, when real traffic arrives with campaign parameters that trigger a different rule entirely.

And one last case that shows up in no hop list: the chain ends where it should, but the destination page has no content. Formally everything is right — a clean 301 to a 200 — and the visitor still finds nothing. That is a soft 404 at the end of the road, which is why the destination deserves checking, not only the number of hops.