Redirect chains: what they cost and how to flatten them

What a chain actually is

A redirect chain is any sequence where the browser is sent from one location to another more than once before it receives a page. A short link that points at a campaign URL, which the site then rewrites to add a trailing slash, which then upgrades from HTTP to HTTPS, which then redirects a country code into the path, is a four-hop chain. Each hop is a full request: DNS may already be resolved, but the browser still opens or reuses a connection, waits for a response, parses a Location header and starts again.

Chains form by accretion rather than by decision. Nobody designs one. A rule added for a site migration two years ago is still in place, a marketing team pastes a URL that was already a redirect, and a platform-level HTTPS upgrade sits in front of all of it. The result is invisible in a browser, because browsers follow chains silently and quickly on a good connection. It is very visible on a slow mobile network and in your analytics.

The cost is mostly latency, and mostly on mobile

On a fast desktop connection an extra hop might cost thirty milliseconds and nobody notices. On a congested mobile network with high round-trip times, each additional hop can cost several hundred milliseconds, and if a hop crosses to a different hostname it may also require a fresh TLS handshake. Two extra hops on a bad connection is a realistic second of delay before the destination page even begins to load.

That second lands at the worst possible moment. The person has just tapped a link and is looking at a blank screen with no feedback. Abandonment at this stage is not visible as a bounce, because the destination page never registered a visit at all. You simply see fewer sessions than clicks and assume the difference is bots.

What search engines do with chains

Search engines follow redirects and will generally consolidate signals to the final destination, but they do not follow indefinitely and they do not enjoy the work. Long chains consume crawl budget on large sites and increase the chance that a crawler gives up before reaching the target. More practically, a chain is a fragility: every hop is a rule someone can break, and a broken middle hop turns a page that ranked into a page that errors.

For short links used in marketing this matters less than people fear, because campaign links are usually not the canonical route to a page. Where it matters sharply is when short links are used inside your own site, in documentation, or in places that get crawled and cited. There, the short link should resolve to the canonical URL in one hop, not to a URL that then redirects again.

Find the chain before you argue about it

Do not guess. Use a command line HTTP client that prints every response in the sequence rather than following silently. With curl, requesting the short link with headers shown and redirects followed will print each status line and Location header in order. Read them from the top and write down the hostname of each hop. Anything more than the short link plus the destination deserves an explanation.

Do this from a mobile-like context as well as from your desk. Some hops only appear for certain user agents, certain countries or certain devices, particularly if the site has geographic or app-banner redirects. A chain that is two hops for you may be four hops for the audience you are actually targeting.

Fix the destination, not the short link

The instinct is to point the short link at whatever the browser eventually landed on. That works, but it hides the problem rather than solving it, and it hard-codes the output of a redirect rule that may change. The better order is: find out why each hop exists, remove the ones that are obsolete, and only then update the short link to the URL that the site genuinely considers canonical.

The most common removable hop is the non-canonical host — linking to the version without the subdomain when the site immediately adds one, or the version with a trailing slash when the site strips it. Copying the URL from the address bar after the page has fully loaded, rather than from a colleague's message, eliminates most of these instantly.

Watch what chains do to query parameters

Not every redirect preserves the query string. A site-level rule that rewrites a path may drop everything after the question mark, which silently destroys your UTM parameters. The click is recorded on the short link, the visit is recorded in analytics, and the two cannot be joined because the campaign tags evaporated in the middle of the chain.

Test this specifically: append a distinctive parameter to the short link's destination, follow the chain, and check whether the parameter survives to the final URL. If it does not, either fix the redirect rule to preserve query strings or point the short link past the offending hop.

Keep the one hop you actually need

The short link itself is a redirect, and that is fine. It is doing work: it is short enough to print, it can be repointed, and it counts clicks. What you are trying to eliminate is every hop that does no work — the legacy migration rule, the scheme upgrade that could have been avoided by linking to HTTPS in the first place, the marketing URL that is itself a redirect to a real page.

A reasonable standard for a published campaign link is exactly two responses: the short link returns a redirect, the destination returns a page. Make that the thing you check before anything goes to print, into an email, or onto a sign, because those are the places where you cannot fix it afterwards.