Redirect chain

What a redirect chain really is

A redirect chain exists the moment a request needs more than one hop to reach a 200. Someone asks for URL A, the server answers 301 and points at B, B answers 301 and points at C, and C finally serves the page. Every intermediate response is a full HTTP round trip: DNS, connection, header parse, then start again. That is the whole mechanism, and it is deliberately unglamorous, because the interesting part is never the definition. It is why the chain exists at all.

Chains are almost never designed. They accumulate. A site moves from HTTP to HTTPS in 2019, drops the www in 2021, restructures its categories in 2023, and consolidates two thin pages into one in 2026. Each of those decisions produced a perfectly reasonable single redirect at the time. Stacked, they produce a four hop path that nobody ever wrote down, that no single person owns, and that silently mediates every legacy link pointing at the site. The chain is a fossil record of your URL decisions, and like most fossil records it is only read after something dies.

The distinction that matters operationally is not chain versus no chain. It is four separate situations that get lumped together in audit tools and should not be. A direct permanent redirect is fine and Google says so. A chain is tolerable but adds cost. A loop or a chain ending on a 404 is a hard failure that blocks resolution entirely. And a redirect sending a user somewhere materially different from what the search result promised is a spam problem, not a technical debt problem. Treating those four as one red row in a crawl report is how teams end up spending a sprint flattening harmless two hop paths while an infinite loop sits untouched.

The second distinction: server side versus everything else. Google recommends server side 301 or 308 for permanent URL changes, and its redirect documentation treats permanent responses as a signal that the target should become the canonical version of the page, while 302, 303 and 307 are temporary signals that do not by themselves transfer canonicalisation. A chain built out of meta refreshes and JavaScript hops is not the same animal as a chain of clean 301s, and it degrades much faster across user agents.

What Google actually says in 2026

Here is the sentence that should end most agency arguments. Google's site migration documentation states that 301 and other permanent redirects do not cause a loss in PageRank. Not « minimal loss », not « negligible decay ». No loss. The widely repeated figure about a percentage of link equity evaporating at each hop has never been traceable to a Google statement, and repeating it in a client deck in 2026 is a tell that the deck was assembled from blog posts rather than from primary documentation.

What the same documentation does say is that chains should be avoided anyway, for reasons that have nothing to do with how authority moves between URLs. They add latency. They are not handled reliably by every user agent. Googlebot can follow up to 10 redirects in a chain, but Google's operational advice is to redirect directly to the final URL where possible, and otherwise to keep the chain ideally to three hops or fewer than five. That gap between the technical ceiling of 10 and the recommended three is the whole game: you have headroom, and you should not spend it.

Google also recommends keeping migration redirects live for at least one year, while updating internal links and important external links to the final URLs. The reasoning is mechanical rather than mystical: recrawling old URLs takes time, and signals get reassigned as those recrawls happen. Pulling the redirects at three months because the traffic looks stable is a recurring self inflicted wound.

No redirect specific ranking update shipped in the last twelve months. The March 2026 core update ran from 27 March to 8 April 2026 and completed in twelve days and four hours according to Search Engine Land, and the December 2025 core update ran roughly eighteen days from 11 December. Both were broad ranking updates with no announced redirect factor. The one update that genuinely touches this territory is the August 2025 spam update, which began 26 August 2025 and whose industry coverage identified sneaky redirects among the practices in scope. Sneaky means deceptive: sending a user or a crawler somewhere materially different from what was requested. An ordinary migration chain is not that, and conflating the two produces a lot of pointless panic in audit debriefs.

The cautionary tale of the period came from Google itself. In September 2025, Search Engine Journal reported that obsolete Google structured data documentation URLs were 301ing to a changelog page that linked back to those same URLs, producing an infinite loop across pages including Course Info, Estimated Salary, Learning Video, Special Announcement and Vehicle Listing. If a team with that much technical discipline ships a redirect loop into production documentation, your client's 2019 migration rules almost certainly contain one too.

Where chains cost you in a netlinking operation

For anyone running acquisition campaigns, the chain that matters is the one sitting between a paid or earned link and the page it was meant to strengthen. Google's own migration guidance tells you to contact high value referring sites and get the external links updated to the final URL. That advice is usually ignored because it is tedious, and because the redirect keeps working, so the problem never announces itself.

It still costs. A link pointing at a legacy URL passes its signals through the permanent redirect, but it also imposes an extra request on every crawl and makes the value of that placement dependent on a rewrite rule surviving the next platform migration, the next CDN change, the next WAF ruleset. You paid for a placement and you are renting its resolution from your own infrastructure. When a site consolidates onto a new CMS and the old rules do not get ported, a year of link acquisition degrades to 404 in one deploy, and the only visible symptom is a slow decline nobody attributes correctly.

There is a specific chain risk on the acquisition side too. A 2025 compilation of link building statistics published by Spiralytics reported that 19.9 % of link builders were actively buying and redirecting domains to acquire links. That tactic manufactures chains by design, and it stacks them on top of the relevance and expired domain risk that comes with the practice. When a redirected domain is itself the product of an earlier migration, you inherit somebody else's undocumented hops on top of your own. That is one of the reasons we publish the actual URL structure of the French editorial media we own rather than routing anything through redirect layers: on a catalogue you can inspect before ordering, a link lands where the page lives, and there is nothing to unwind later.

Auditing hops without drowning in noise

Every crawler surfaces chains. Screaming Frog's redirect audit identifies permanent and temporary redirects, chains and loops, and takes uploaded URL lists, which is the mode you actually want for migrations. The free version is capped at 500 URLs per crawl and the licence is listed at £199 per year, also shown as $279, which removes the cap and unlocks crawl comparison and scheduling. Ahrefs Site Audit and Semrush Site Audit both flag chains at scale, with Ahrefs running a credit model where a credit is consumed per internal HTML page returning 200 while redirects and error pages are crawled without that particular charge, and Semrush reporting 100 000 pages per month on Pro. Third party price checks for 2026 put Semrush Pro at $139.95 per month and Ahrefs Lite at $129, so verify at checkout before budgeting. Tooling is not the constraint here. Prioritisation is.

The report that gets acted on is the one sorted by consequence, not by hop count. Pull three inputs together: the number of hops, the referring domain value of the URLs feeding into the chain, and the organic traffic and conversions on the final page. A five hop path on a URL with no links and no traffic is a curiosity. A two hop path standing between your best referring domains and a commercial page is the first ticket. Add a fourth column for final page relevance, because a chain that terminates on a generic category page instead of the intended article is a targeting failure dressed up as a technical one.

Audit the referring URLs from your backlink tool alongside the internal links, not just what sits in the XML sitemap. The sitemap contains the URLs you already believe in. The chains live in the URLs you forgot about, and those are exactly the ones external sites are still pointing at. Budgeting a fix cycle for this is cheaper than most people assume once the list is sorted properly, and it compares favourably to what a comparable gain in authority costs to buy outright.

What we see go wrong

The first failure is regex ordering. Redirect rules are evaluated top down and the first match wins, so a broad legacy rule sitting above a precise new one silently shadows every fix you add below it. Teams then add a third rule to fix the second, and the chain grows by one hop per debugging session. Read the whole rule file before appending to it.

The second is flattening chains without keeping the intermediate rules alive. If A points to B and B points to C, rewriting A to point at C is correct, but deleting the A to B rule while any external site still links to A turns a working chain into a 404. Both rules stay, and A now resolves in one hop.

The third is mixing status codes mid chain. A 301 followed by a 302 muddles the canonicalisation signal, since Google treats temporary responses as not making the target canonical on their own. If the destination is permanent, every hop on the path should say so.

The fourth is treating the redirect layer as untested infrastructure. Nobody writes assertions for rewrite rules, so nothing catches the day a platform change drops the rules. A tiny scheduled check on twenty representative legacy URLs, comparing the final status code and the final URL against an expected list, catches in a day what usually surfaces six months later in a traffic report. Google's own infinite loop in September 2025 is the argument for that check, not against it.