# Every Hop in a Redirect Chain Costs You Something

**Author:** John Morabito (Founder, /winston)
**Published:** September 20, 2026
**Reading time:** 12 minutes
**Canonical:** https://www.winstondigitalmarketing.com/playbooks/redirect-chains-and-lost-link-equity/

A redirect chain does not require a migration. It only requires a scheme rule, a hostname rule, a case rule, a trailing-slash rule and one renamed category, each added by a different person on a different Tuesday, all firing on the same request.

## The short answer

A redirect chain is a URL that redirects to a URL that redirects again before anything finally serves a real page. It is easy to assume chains are a migration artifact, something you get when you move a site and do the mapping badly. They are, but that is the visible half. The other half is sitting on sites that have never migrated anything, because a chain does not require a move. It only requires that several sensible rules, written at different times by different people in different systems, all fire on the same request.

Almost every five-year-old site has some form of this. A request for `http://example.com/Winter-Sale` gets upgraded to HTTPS by one rule. The HTTPS request gets sent to the `www` hostname by a second rule. The `www` request gets lowercased by a third. The lowercased request gets a trailing slash added by a fourth. And the trailing-slash version gets sent to `/sales/winter/` by a redirect somebody added in the CMS when the category was renamed. That is five hops with no migration behind any of them, assembled out of five reasonable decisions made on five different Tuesdays.

Nobody owns that chain, because nobody can see it. In a browser the address bar shows the destination and the page looks fine. The chain is only visible if you go looking for it with a tool that reports hops, and there is no team whose job is to look.

This is the accumulated-debt version of a problem that a migration forces you to confront all at once: https://www.winstondigitalmarketing.com/playbooks/seo-migration-without-losing-rankings/. During a migration the redirect map is a deliverable with a deadline and an owner. Outside one, the same rules pile up with neither.

## What a chain actually costs, and what it does not

The argument people usually lead with is the weakest one available. There is no public number for how much link equity a chain costs. The most-quoted piece of the record is a statement from Google that a 301 does not lose PageRank. That statement is about one hop, one signal, and one moment in time, and it is not a promise about a five-hop chain that crosses a scheme change, a hostname change and a CDN rule on the way. Nobody outside the search engines can measure the real figure, and every specific percentage circulating about redirect decay was invented by somebody who also could not measure it. Treat the equity cost as real and unquantified, and do not build your case on it.

Build it on the four costs you can observe on your own site instead.

- **Requests.** Every hop is a separate round trip that a crawler pays for and gets nothing back from. On a site of a few hundred pages this is a rounding error. On a large one it is not, for reasons worth their own section below.
- **Seconds.** Each hop costs a human a full round trip, and potentially a DNS lookup and a TLS handshake when the hop changes scheme or hostname. On a phone on a slow connection, a four-hop chain in front of a landing page is a measurable chunk of the time before anything renders. Paid traffic lands on exactly the URLs most likely to have this problem, because campaign URLs are the ones typed into a media plan once and never revisited.
- **Parameters and referrers.** Plenty of redirect rules do not preserve the query string. A campaign URL carrying UTM parameters through a rule written without them arrives stripped, and the session shows up as direct. Referrer data gets dropped across certain hops too. If your attribution has an unexplained direct bucket, the redirect stack is worth checking before the analytics config.
- **Fragility.** This is the one that eventually bites. A chain assembled from rules in five systems is a chain where no single person can predict what happens when one of those systems is reconfigured. The chain works right up until the day somebody flips the CDN's URL normalization setting, and then a set of URLs nobody was tracking starts returning a loop or a 404.

> **The honest sentence:** If somebody asks you to justify flattening redirects and you reach for a link-equity percentage, you are about to quote a number nobody has. Say this instead: the equity cost is real and not publicly quantified, and the work is worth doing anyway because the crawl cost, the latency cost and the tracking loss are all measurable on this site today, and the fix requires no judgment.

## The five layers a chain gets built from

Chains form quietly because redirects can be written at several layers of the stack, and each layer is usually owned by a different person who cannot see the others. A rule at one layer runs before a rule at the next, so the composed behavior is an accident nobody designed.

| Layer | What lives there | Who added it, and why nobody remembers |
| --- | --- | --- |
| DNS and the edge | Domain forwarding, registrar-level redirects from an old brand domain | Whoever bought the domain, possibly years before the current site existed |
| CDN or proxy | Scheme upgrades, hostname canonicalization, trailing-slash normalization, path rewrites, bulk rules pasted in during an incident | Whoever set up the CDN, in a dashboard the marketing team has never opened |
| Web server | `.htaccess` or nginx rules, often the oldest layer and the least documented | A developer who has left, solving a problem that no longer exists |
| Application or CMS | Built-in canonicalization, case handling, locale prefixing, slug changes that auto-create a redirect | Nobody. It is platform default behavior and it is not written down anywhere on your side |
| Plugin or redirect manager | A database table of one-off rules added over the years, frequently pointing at URLs that are themselves redirected | Everybody. This is the layer where marketing can add a rule without a ticket, which is exactly why it grows |

Two things follow from that table. The first is that flattening chains inside the redirect plugin alone will not fix a chain whose first three hops happen at the edge before the application ever sees the request. The second is that the fix has to be tested from outside, against the live site, because the only place the composed behavior exists is on the wire.

## Finding every chain, rather than the ones you already suspect

Spot-checking a handful of URLs in a browser tab finds the chains you already had a hunch about. Two passes find the rest, and you need both because each one sees URLs the other cannot.

### Pass one: crawl, seeded from three places

Run a crawler configured to follow redirects and report the number of hops and the final status of each. The part people get wrong is the seed list. A crawl that starts at the homepage and follows links only finds URLs your current site still links to, which excludes almost every URL that matters here, because a URL stops being linked long before it stops being requested. Seed from three lists and merge:

- **Your XML sitemap**, which should contain only canonical 200s and is worth checking for that reason alone. A sitemap full of redirects teaches crawlers to discount the file.
- **A normal link-graph crawl** from the homepage, which finds internal links pointing at pre-redirect URLs. Those links are what generate the hops in the first place.
- **An export of URLs with external links pointing at them**, from whatever backlink tool you have. These are the chains worth fixing first, because a hop here sits between somebody else's link and your page, and you cannot go back and ask them to update it.

### Pass two: replay the access log

The access log is the only record of what was actually requested, which makes it the only place that knows about the URLs nothing links to anymore: campaign addresses from a print run, URLs inside PDFs, a link in a forum post from 2019, an address a partner hardcoded into their footer. None of these will ever turn up in a crawl. All of them are requests being served today.

The procedure is mechanical. Filter the log to requests that returned a 3xx over a reasonable window, a month is usually plenty, take the distinct paths, and replay each one following redirects while recording every hop. `curl` will do the recording for you:

```bash
curl -sIL -o /dev/null \
  -w '%{num_redirects}  %{url_effective}  %{http_code}\n' \
  "https://www.example.com/winter-sale"
```

Run that across the deduplicated list, sort descending by hop count, and you have the work queue. Keep the request counts from the log attached to each row, because a four-hop chain served ten thousand times is a different priority from a four-hop chain served twice. The wider set of questions the log answers, including which crawlers are spending their requests on what, is in log file analysis for SEO: https://www.winstondigitalmarketing.com/playbooks/log-file-analysis-for-seo/

One detail that catches people: replay as a crawler would, not as your browser would. Request without cookies, without a session, and with a plain user agent. Rules that branch on a logged-in session or a geolocation header will behave differently for you than for anything crawling the site, and the version that matters is the one a stranger gets.

## 301, 302, meta refresh, and the redirect that is not one

Hop count is half the problem. The other half is what each hop communicates, and several of the available mechanisms say something other than what the person who chose them intended.

| Mechanism | What it actually says | When it is the wrong choice |
| --- | --- | --- |
| `301` permanent | This address changed for good. Index the destination, consolidate the signals there, and update your records. | Almost never wrong for a real move. Wrong when the original is genuinely coming back. |
| `308` permanent | The same as a 301, except the request method survives, so a POST stays a POST. | Rarely needed for content pages. It matters for form endpoints and APIs where a 301 silently turning a POST into a GET breaks the submission. |
| `302` found and `307` temporary | Keep the original URL. This detour is temporary. | On a permanent move, which is the single most common type error, usually because it was the framework default or the first option in a plugin dropdown. |
| Meta refresh | A 200 response containing a page plus an instruction to go somewhere else shortly. | Any case where a real HTTP redirect is available. An instant one is usually interpreted as a permanent redirect, a delayed one is not, and the delayed version is an accessibility problem as well. |
| JavaScript redirect | Nothing, as far as the response is concerned. The move exists only for clients that execute scripts. | Any case involving a URL you want indexed or a link you want to preserve. Some crawlers render and will eventually see it; many do not and never will. |

The type error and the chain problem interact in a way worth naming. A chain that starts with a 302 and ends with a 301 has told the engine two contradictory things in one request: keep the original, then no, use the destination. You may well end up with the original URL indexed and the destination's content attributed to it, which is the outcome you were trying to avoid when you set up the redirect at all.

The same applies to a chain that passes through a meta refresh or a JavaScript hop in the middle. A crawler that does not execute scripts follows the HTTP hops, arrives at a page containing a script that moves elsewhere, and stops there. It has now indexed an intermediate address as the destination.

## Where the chain ends matters as much as how long it is

Flattening is only half a fix if the destination is wrong. The most common wrong destination is the homepage, usually arrived at through the same reasoning every time: the old page is gone, we do not want a 404, send it somewhere that definitely exists.

A redirect is a statement that this page moved here. Pointing a discontinued product at the homepage states something untrue, and search engines have a name for the resulting pattern, a soft 404, which they handle roughly the way they handle a real 404. You have preserved nothing, and you have also removed the URL from your error reports, so nobody will ever revisit the decision.

The test to apply to every destination is short: would somebody who clicked the original link consider the destination a reasonable answer to what they wanted? Work down this order and stop at the first one that is true.

1. A direct replacement exists. Send it there.
2. No replacement, but a parent category or a closely related page covers the same need. Send it there.
3. Nothing relevant exists and the page is genuinely gone. Return a 404, or a 410 if you want to state that the removal is deliberate and permanent.

The third option is a real answer and worth using. A truthful 404 appears in a report where somebody can act on it. A redirect that lies looks fine on every dashboard you own.

> **The exception worth making:** If a dead URL carries real external links and nothing on your site is a reasonable match, it is worth building something that is. A discontinued product with ten links pointing at it can justify a page that explains what replaced it and why, which gives the links a live destination and gives a visitor an honest answer. Deciding that is content work, and it is the only case here where the right answer involves writing something.

## Why this gets expensive at scale

On a two-hundred-page site, chains cost you latency and tracking accuracy and not much else. The crawl argument only becomes the main argument once the site is large, and it does so for a specific reason.

A crawler works through a finite allowance of requests per site per unit of time, and a redirect hop consumes one of those requests while returning no content. Chains are therefore a pure subtraction from the budget available to your actual pages. The full model of what that allowance responds to, and the other categories of waste competing for it, is in crawl budget optimization: https://www.winstondigitalmarketing.com/playbooks/crawl-budget-optimization/. Two things are specific to chains and worth adding here.

The first is that the cost scales with the number of URLs behind a rule, not with the number of rules. A single trailing-slash normalization applied across a template that generates two hundred thousand URLs is one line in a config file and an enormous number of wasted requests. Counting rules will tell you the problem is small. Counting affected URLs will tell you the truth.

The second is that chains are the only category of crawl waste where the fix involves no judgment at all. Deciding which faceted URLs to allow, which thin pages to consolidate and which parameters to disallow all require somebody to think. Rewriting a rule to point at the URL it eventually resolves to requires only that somebody knows what that URL is, which the replay pass already told you. That makes flattening the highest-certainty work available on most large sites, which is a good reason to do it first.

One sequencing point that gets missed: internal links and redirect rules have to be fixed together. If you flatten every rule but leave your navigation pointing at pre-redirect URLs, every visitor and crawler still pays one hop on every page. If you update every internal link but leave the chains in place, external links and old bookmarks still pay for all of them. Update the links first, since that removes the requests entirely instead of shortening them, then flatten the rules underneath.

## What to do first

In order, smallest and most certain first. Most of the value is in the first three.

1. Replay one URL through `curl` with `num_redirects` and look at the number. Do it for your homepage in its non-canonical form, one campaign landing page, and one page you know has external links. If any of them return more than one, you have the problem and you now have the evidence to say so.
2. Pull a month of access log, filter to 3xx, deduplicate, and replay the list. Sort by hop count and keep the request volume attached. This is the whole inventory, and it takes an afternoon.
3. Fix the rows where external links point at the start of the chain. These are the only hops you cannot fix later by updating your own markup, because the link is on a site you do not control.
4. Rewrite every remaining rule to point at its final destination in one hop, and check each destination against the relevance test rather than assuming the existing target was correct.
5. Crawl your own site for internal links pointing at any URL that redirects, and update them to the destination. Include navigation, footers, canonical tags, hreflang annotations and the sitemap, all of which are easy to forget and all of which are read by machines.
6. Re-run the replay after the change to confirm every chain now resolves in one hop, and put the replay on a schedule. Chains regrow, because the conditions that produced them are still in place.

## Hiring someone for this

This work rarely gets sold as its own project. It turns up inside a technical SEO engagement or a migration, which is fine, as long as whoever is doing it has thought past running a crawl and exporting the redirect tab. Three questions separate the two quickly.

Ask how they would find a chain on a URL nothing links to anymore, and listen for the access log rather than a bigger crawl. Ask what they would do with a discontinued product page that has external links and no replacement, and listen for whether a 410 and a purpose-built page are both on the table. Ask where in the stack they would look for the first hop, and listen for whether they know the request passes through layers they may not have been given access to.

On our side the pricing is published rather than quoted after a call, and every engagement is a written scope with the number attached before you pay anything: https://www.winstondigitalmarketing.com/pricing/. The done-for-you version of this sits inside our SEO service: https://www.winstondigitalmarketing.com/services/seo/, and if you want to see what your own URLs do before you talk to anybody, put one through the free audit: https://www.winstondigitalmarketing.com/audit/

## Frequently asked questions

### What is a redirect chain, and why does it matter?

A redirect chain is a URL that redirects to another URL that redirects again before anything finally answers with a real page. One hop is normal and fine. Three or five hops is a chain, and it usually means several rules written at different times by different people are all firing on the same request. It matters for four reasons you can actually observe: every hop is a separate request, so a crawler spends several times what the destination alone would have cost; every hop adds a round trip a human waits through, which is worst on a phone; hops routinely drop query strings and referrer data, so campaign tracking goes missing; and a chain assembled from rules nobody wrote together is a chain that breaks the day one of those layers is reconfigured.

### How many redirects is too many?

One. That sounds fussy until you notice it is the only target that survives the next change. Search engines follow a bounded number of hops rather than an unbounded one, and past that bound they stop and treat the destination as unreachable, so a long enough chain is functionally a broken page. But the practical limit is lower than the documented one, because a chain that works today at four hops is one new rule away from being a chain that does not work at all. The rule worth holding is that any URL you publish, link to, or care about resolves to its destination in a single hop, and everything else gets flattened when you find it.

### Do redirect chains actually lose link equity?

Nobody outside the search engines can answer that with a number, and any specific percentage you have seen was invented. What is on the public record is a statement from Google that a 301 does not lose PageRank, which is about one hop, one signal, and one moment in time. It is not a promise about a five-hop chain that crosses a scheme change, a hostname change and a CDN rule. The honest position is that the equity cost is real, unquantified publicly, and the weakest argument for doing the work. The strong arguments are the observable ones: requests spent, seconds added, parameters lost, and a rule stack that eventually breaks.

### Should I use a 301 or a 302?

Use a 301 when the address changed and you want the destination to be the version that gets indexed and consolidated. Use a 302 or a 307 only when the original URL is genuinely coming back, which is rarer than the amount of 302s in the wild suggests. The common failure is a permanent move shipped as a 302 because that was the framework default or the plugin dropdown's first option. Engines will often work out what you meant, but you have explicitly asked them to keep the old URL as the indexed one, and while they are deciding you get neither. If the move is permanent and the request is a form submission you need to preserve as a POST, a 308 is the version of a 301 that keeps the method intact.

### How do I find every redirect chain on my site?

Two passes, because each one finds chains the other cannot see. First, crawl the site with a tool set to follow redirects and report the hop count, and seed it from three places at once: your sitemap, a normal link-graph crawl from the homepage, and an export of the URLs that have external links pointing at them. Second, replay your access log. The log contains URLs real people and real crawlers actually requested, including ones no crawl will ever discover because nothing on your site links to them anymore: old campaign URLs, addresses printed in PDFs, links in somebody else's blog post from 2019. Pull the distinct paths that returned a 3xx over a month, deduplicate them, and replay each one following redirects while recording every hop. Then sort by hop count and by whether anything external points at the start of the chain.

### Is it okay to redirect old pages to the homepage?

Only when the homepage is genuinely the closest thing to what the visitor asked for, which is almost never. A redirect is a statement that this page moved here. Pointing a discontinued product at the homepage states something untrue, and search engines have a name for the pattern: a soft 404, handled roughly the way a real 404 is handled, with the added cost that you have also made it invisible in your error reports. Send the URL to the replacement product if there is one, the parent category if there is not, and if neither exists, let it return a 404 or a 410 honestly. A truthful 404 is better than a redirect that lies, because the 404 shows up in a report where somebody can act on it.

### Do I need to keep old redirects forever?

Keep any redirect that something still requests, and let the access log tell you which ones those are. A redirect that has served zero requests in a year, has no external links pointing at it, and appears in no sitemap or export is a candidate for retirement. A redirect that still receives traffic from a link on a site you do not control is permanent infrastructure, however old it looks. The failure mode worth avoiding is the audit that deletes a redirect file wholesale to clean things up and discovers six weeks later which of those rules had been quietly carrying links the whole time. Retire by evidence, in batches, and watch the 404 report after each one.