Redirect Chains: What They Cost and How to Fix Them

Nobody builds a chain on purpose. Each rule was right on the day it was written, and nobody went back to check what it points at now.

A redirect chain is a redirect that points at another redirect. The visitor asks for one URL, is sent to a second, and is sent on again before anything is delivered.

Chains are rarely built on purpose. They accumulate: each rule was correct on the day it was written, and nobody went back to check what it now points at. Because a browser follows the whole sequence silently and shows only the destination, a chain can sit on a site's most-linked URL for years without anyone seeing it.

What a chain looks like

http://example.com/shop
  301 → https://example.com/shop
  301 → https://www.example.com/shop
  301 → https://www.example.com/store/
  200

Three hops, four requests. Each of the three rules is doing its own job properly: one upgrades to HTTPS, one adds www, one reflects a section being renamed. The chain is what happens when they run one after another instead of being resolved into a single answer.

What each hop costs

Time, on every request. A hop is a complete round trip before any content arrives. A hop to a different hostname or protocol is more than that: it can need a fresh DNS lookup, a new connection and a new TLS handshake. On a mobile connection a three-hop chain can add most of a second before the page has started loading, and that delay lands directly in time to first byte and everything measured after it.

Crawl attention. Google's crawler follows up to ten hops, but each hop is a separate fetch. On a large site, chains spend crawl capacity on URLs that deliver nothing.

Clarity of the signal. A permanent redirect passes ranking signals to its destination, and Google has said a 301 no longer loses value on the way, so a short chain of 301s is not a penalty in itself. The real risk is the weakest link: one 302 in the middle makes the whole sequence ambiguous, and a chain is exactly where a forgotten 302 hides.

Fragility. Every hop is a rule somebody can break. A chain of three depends on three rules in possibly three different systems all staying correct.

How many is too many

Two is the practical ceiling, one is the target. A redirect that exists for a reason is fine. A second is tolerable when it comes from a system you do not control. Three or more means rules are stacking that could be combined.

Hard limits exist, and they are higher than you should plan around: browsers give up at around twenty redirects, Google's crawler at ten. The Redirect Checker stops at ten hops and reports the chain as too long rather than following further.

Where chains come from

Four patterns account for nearly all of them.

Protocol and hostname rules applied separately. The example above. An HTTPS rule and a www rule each fire in turn. This is the most common chain on the web, and it affects every URL on the site rather than a handful. Redirecting HTTP to HTTPS has the combined rule.

Trailing slash normalisation. The server or framework adds or removes a final slash as a separate step, after the other rules have already run.

Migrations stacked on migrations. A page moved in 2021 from /a to /b. In 2024 it moved from /b to /c. The old /a → /b rule was never updated, so every link to the original address now takes two hops. Each redesign adds another layer.

Rules in more than one place. A CDN redirects, then the web server redirects, then a CMS plugin redirects. Each system only knows about its own rule, and none of them can see the others.

Finding them

For one URL, trace it. The Redirect Checker requests the address without following redirects automatically, so each hop is listed with its own status code and timing, and a chain of three or more is flagged.

Trace the versions people actually arrive on, not the one you link to yourself. That means the http:// form, the form without www, and the form without a trailing slash. The clean canonical URL is the one address guaranteed not to redirect.

In Chrome, open DevTools, go to the Network tab, tick Preserve log, and load the address. Each redirect appears as its own row with a 3xx status. Without Preserve log the list is cleared on every navigation and the hops vanish.

From a terminal:

curl -sIL http://example.com/shop | grep -iE '^(HTTP|location)'

For a whole site, a single-URL tool is the wrong instrument. A crawler follows every internal link and reports chains in bulk, and that is the right way to find the ones produced by old migrations.

Fixing a chain

The principle is one sentence: every redirect should point at the final destination, not at the next redirect.

Trace the chain and write down the last URL — the one that returns 200.
Find what issues each hop. A hop that changes only the protocol or hostname is a server or CDN rule. A hop that changes the path is usually a CMS redirect entry or a rewrite rule. Check the server config, .htaccess, the CDN's rules and any redirect plugin.
Rewrite each rule to target the final URL directly. In the example, the HTTPS rule should send straight to https://www.example.com, and the /shop entry should point at /store/ on that hostname.
Update the old rules, do not delete them. The /a → /b rule from 2021 still has links pointing at it. Change it to /a → /c.
Fix your own links. Internal links, the sitemap and canonical tags should all use the final URL. A redirect is for visitors arriving from outside; your own pages should never need one.
Trace again from each entry point, in a private window, because browsers cache 301s and will keep replaying the old chain.

Chains and loops

A loop is a chain that arrives back at a URL it has already visited, so it never ends. The browser gives up and shows ERR_TOO_MANY_REDIRECTS.

The two share a cause — rules that do not know about each other — and one is often created while fixing the other, by adding a rule to an already crowded set. If the trace shows a URL repeating, that is a different repair: see fixing a redirect loop.

A chain that contains HTTP

Security scanners sometimes report "redirect chain contains HTTP". It means one hop in the sequence was served unencrypted.

If the unencrypted hop is the first one, that is ordinary. A visitor who types an http:// address has to be answered over HTTP at least once in order to be redirected. The only way to remove that request is HSTS, which makes the browser skip it on later visits.

If it is in the middle, it is a real fault. The chain reached HTTPS and was then sent back to a plain http:// address:

https://example.com/page
  301 → http://www.example.com/page
  301 → https://www.example.com/page

That middle hop exposes the request, and it is almost always a hard-coded http:// destination in a redirect rule or a CMS site-address setting. The Redirect Checker marks hops served over plain HTTP as not encrypted, which makes the offending rule easy to pick out.

When a chain is not yours to fix

Some hops belong to someone else: a link shortener, an affiliate network's tracking redirect, a payment provider's return URL, a single sign-on handoff. Those are part of how the service works and cannot be collapsed.

What you can control is your end of it. Make sure the address you give the third party is your final URL, so their redirect lands on a 200 rather than on the start of a chain of your own.

Trace your most-linked URLs with the Redirect Checker, from the entry points visitors really use. A chain is one of the few performance problems that takes minutes to fix and benefits every request afterwards.