Redirect Chains: How to Find Them, and Why They Quietly Accumulate After Every Redesign

Why does a URL I fixed two years ago still take three hops to load?

Because each restructure added a rule without revisiting the old ones. The 2024 URL points at the 2025 URL, which points at the 2026 URL. Nobody wrote a bad rule. Every rule was correct on the day it was written, and the chain is the accumulated residue of being correct three times.

Redirect chains are the most boring problem on a mature site and one of the easiest to fix, which is exactly why they survive for years. They never break anything visibly. The page still loads. The only cost is paid quietly, in slower first loads for anyone arriving on an old link and in extra work for every crawler that follows one.

This is how I find them, how I decide which ones to flatten, and what I am careful about when editing redirect rules on a site that is already live.

What exactly is a redirect chain?

A redirect chain is any sequence where one URL redirects to a second URL that itself redirects somewhere else. One hop is a redirect. Two or more hops is a chain. The visitor eventually lands on the right page either way, which is precisely why nobody notices.

The related problem is a redirect loop, where the chain eventually points back at something earlier in the sequence and never resolves. Loops break visibly and get fixed quickly. Chains do not break, so they persist.

A third variant worth naming is the mixed chain, where a permanent redirect points at a temporary one or the reverse. That matters because the two types are treated differently, which is worth understanding before you start editing.

What does Google actually document about redirect types?

Google's redirect documentation splits redirects into permanent and temporary. For permanent redirects, Google says Googlebot follows the redirect and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical. Permanent redirects show the new target in search results.

For temporary redirects, Google's docs say Googlebot follows the redirect but the indexing pipeline does not use it as a signal that the target should be canonical, and that the target page might still be indexed if other canonicalization signals are present. A temporary redirect shows the source page in search results.

Google lists several methods under permanent redirects, including HTTP 301, HTTP 308, meta refresh at zero seconds, HTTP refresh at zero seconds, a JavaScript location redirect, and a crypto redirect. The list is ordered by how likely Google is to interpret each correctly, and Google notes that a server side redirect has the highest chance of being interpreted correctly.

Does Google publish a limit on how many hops it will follow?

Not on the redirect documentation page. I fetched it while writing this and it does not state a maximum number of hops. You will see a specific hop limit quoted confidently all over the industry, and I am not going to repeat a number I cannot point at a source for.

What the documentation does say is worth more than a hop count anyway. Google's guidance is to prefer server side redirects because they are the most reliably interpreted, to only use JavaScript redirects if you cannot do server side or meta refresh redirects, and not to rely on crypto redirects to tell search engines that content has moved unless you have no other choice.

Read that as a preference ordering rather than a rule about chains. The practical implication is the same either way: fewer hops, and each hop implemented the most reliable way available to you. You do not need a documented limit to justify removing work that serves no purpose.

How do you find the chains on your own site?

Take your redirect table, which is a list of source and destination pairs, and treat it as a graph. Any destination that also appears as a source is a chain. That single check, run against the export, finds most of them in seconds without touching the live site at all.

The second pass catches what the table cannot. Some hops are not in your redirect rules at all: a missing trailing slash, an http to https upgrade, a www to non-www normalisation. Those live in platform behaviour rather than your rules, and the only way to see them is to request a sample of old URLs and record every intermediate response.

Combining both is what gives you the real picture. The table tells you about rules you wrote. The request trace tells you about hops that happen regardless of what you wrote, and a chain built from one of each is the most common kind I find.

Which chains are actually worth fixing?

The ones on URLs people and crawlers still hit. Sort your chains by whether the entry URL has inbound links, appears in your analytics, or shows up in Search Console. A chain on a URL nobody has requested in two years is a fact about your history, not a problem.

My order is: chains whose entry URL still has external links pointing at it, then chains on URLs that appear in current search performance data, then everything else, which usually stays untouched. Completionism here has a real cost, because every edit to a live redirect table is a chance to break something that currently works.

I also prioritise mixed chains over long uniform ones. A permanent redirect that passes through a temporary one is doing something more confusing than a clean three hop permanent chain, and the fix is usually a single rule change.

How do you flatten a chain without breaking anything?

Point every source in the chain directly at the final destination, then delete nothing until you have verified the new behaviour. Flattening means rewriting the intermediate rules, not removing them. Removing an intermediate rule that something else also depends on is how a tidy-up turns into an outage.

Work from a copy of the export, compute the final destination for each source by walking the chain to its end, and produce the new pairs as a file before you change anything live. That file is also your rollback, because it records exactly what each rule was before you touched it.

Then apply in batches and check each batch by requesting the old URLs and confirming a single hop to the right place. I covered the discipline of building the mapping properly ahead of a move in building a redirect map before a site migration, and flattening is the same exercise run backwards on a site that never got one.

What is different about doing this on Webflow?

Redirects live in the site settings as a managed table rather than in a server config file you can version, so the export and the file you build are your only real safety net. Check Webflow's own documentation for the current behaviour and any limits on your plan, because that is the part that changes.

The practical consequence of a managed table is that there is no easy diff. You cannot open a pull request against your redirects and see what changed. Keeping a dated copy of the export before and after every editing session is the cheap substitute, and it has saved me more than once.

The other Webflow-specific habit is to be careful with wildcard rules. A broad pattern written during a restructure will happily feed a later, more specific rule and create a chain that never appears as an obvious source and destination pair in the table. I hit this while doing a bulk restructure, which I wrote up in handling 301 redirects during a bulk URL restructure.

How often should you check for chains?

After every restructure, migration, or slug change, and otherwise once or twice a year. The check costs minutes once the script exists, and the failure mode of skipping it is not dramatic, which is why a calendar reminder works better than good intentions.

The moment that matters most is immediately after the next restructure, because that is when chains are created. Checking a month later means a month of every old link taking an extra hop, and it also means the person who made the change has forgotten the reasoning by the time anyone looks.

If you are already thinking about how crawlers spend their time on your site, this fits alongside that work rather than competing with it. I looked at the reporting side of crawl efficiency in what the crawl budget data means for site owners.

What should you do next?

Export your redirect table today and check whether any destination also appears as a source. That one comparison takes a few minutes and tells you immediately whether you have a chain problem or just a long list of old rules doing their job.

If you find chains, do not fix all of them. Fix the ones whose entry URLs still receive traffic or links, keep the before and after export, and leave the rest alone. Tidiness for its own sake is not worth the risk of editing rules nobody is depending on.

If you have been through two or three redesigns and you are not sure what your redirect table is actually doing any more, tell me roughly how many rules are in it and I will tell you what I would check first. Let's chat.