Redirect chains: how one extra hop costs you speed and rankings

Type your domain into a browser and watch what happens before a single byte of your homepage arrives. On a lot of sites, the request bounces: http://example.com sends a 301 to https://example.com, which sends another 301 to https://www.example.com, which sends a third to https://www.example.com/. Four requests, three of them returning nothing but a Location header. That is a redirect chain, and almost nobody puts one there on purpose.

One redirect is normal and often correct. The problem starts at the second, and compounds at the third. Each hop is a full network round trip that happens before your server sends any content at all, and search crawlers treat long chains as a reason to spend less time on your site.

What a redirect chain actually is

A redirect chain is any sequence where a URL points to another URL that also redirects, rather than pointing straight at the final destination. The browser follows each Location header in turn until it reaches a response with actual content.

Chains almost always form from stacked rules that were each reasonable on their own:

• A hosting-level rule that forces HTTPS
• A DNS or CDN rule that forces the canonical hostname (www or bare)
• An application rule that normalizes trailing slashes or lowercases paths
• A years-old migration rule mapping /old-page to /new-page, where /new-page later moved again

Nobody wrote a four-hop redirect. Four people wrote one hop each, at different times, in different layers, and none of them knew about the others.

What each hop costs

The cost is not the redirect response itself, which is tiny. The cost is everything the browser has to do before it can read that response.

A redirect to a different hostname or protocol can require a new DNS lookup, a new TCP connection, and a new TLS handshake. On a fast desktop connection that might be 100 to 200 milliseconds. On mobile, where round-trip latency is routinely 100 milliseconds or more on its own, a single hop can easily cost 300 to 600 milliseconds. Two extra hops on a slow connection can push a second of pure waiting in front of a page that has not started rendering.

That delay lands squarely on Time to First Byte, which feeds directly into Largest Contentful Paint. You can optimize images, defer every script, and inline your critical CSS, and still lose the first second to redirects that run before any of that work matters. It is the least visible performance problem on most sites because it happens before the page you are profiling even exists.

Chains also multiply. If your canonical host redirect sits in front of every URL on the site, then every inbound link, every ad click, every email link, and every crawler request pays the same toll, every time.

What search engines do with chains

Google's guidance on redirects and Google Search is direct about this: Googlebot follows up to ten redirect hops, and it recommends keeping chains as short as possible, ideally to a single hop. Past ten, the URL is treated as an error and the destination never gets crawled.

Between one hop and ten, nothing dramatic breaks, but three things degrade quietly:

1. Crawl efficiency drops. Every hop is a separate fetch. A crawler spending requests on redirect responses is not spending them on your new content.
2. Signal consolidation gets slower. Google says ranking signals do pass through redirects, but longer chains take longer to resolve and give more opportunities for a broken or misconfigured link in the middle to strand the whole path.
3. Mixed redirect types confuse intent. A chain that goes 302, then 301, then 302 tells a crawler you are not sure whether this move is permanent. Per RFC 9110, a 301 signals a permanent move and a 302 signals a temporary one. Mixing them in a single path is a contradiction, and temporary redirects do not consolidate signals the way permanent ones do.

The worst version is the loop: A redirects to B, B redirects back to A. Browsers give up with an error, crawlers drop the URL, and users see nothing. Loops usually come from two layers disagreeing about the canonical form, for example a CDN forcing www while the application forces the bare domain.

The chains you are most likely carrying

The protocol and host stack. http:// to https:// to https://www is the classic three-request start. It is fixable in one hop by redirecting straight to the final canonical origin, including protocol and hostname together.

Trailing slash normalization. A framework or CMS that adds or strips a trailing slash after the host redirect has already run adds a fourth hop to every directory-style URL.

Old migration layers. Sites that have moved platforms twice often have two live rule sets. The 2021 rules map to URLs that the 2024 rules then map somewhere else. Each set works. Together they chain.

Marketing links. Shortened links, tracking redirectors, and QR code services add hops before your own redirects even begin. A shortlink pointing at http:// instead of https://www. turns a two-hop campaign into a four-hop one, on the exact traffic you paid for.

Internal links. If your own navigation, sitemap, or canonical tags point at URLs that redirect, you are sending crawlers through the chain on purpose. Fixing the link is free and removes the hop entirely.

How to flatten them

The rule is simple: every source should point at the final destination, not at another redirect.

• Collapse protocol and host into one rule. One 301 from any variant straight to the canonical origin.
• Rewrite old migration rules to target current URLs. If /old pointed to /interim and /interim now points to /final, update the first rule to point at /final and keep both.
• Decide the canonical form once, at one layer. Pick CDN or application, not both. Two layers enforcing the same rule is how loops start.
• Use 301 for permanent moves and reserve 302 for genuinely temporary ones. Consistency matters more than which one you prefer.
• Update internal links, sitemaps, canonical tags, and ad destination URLs to the final form. Redirects should be a safety net for other people's links, not a routing layer for your own.
• Retest after every infrastructure change. New CDN, new host, new SSL setup, new CMS version: each can quietly insert a hop.

How to see your own chain

The fastest manual check is curl, which prints every hop in order:

curl -sIL https://example.com | grep -iE "^(HTTP|location)"

Run it against your bare domain, your www domain, the http:// version of each, and a handful of real content URLs. Anything that prints more than two HTTP status lines before a 200 is a chain worth fixing. Do the same for your top campaign and shortlink destinations, since those often carry the most hops and the most valuable traffic.

To check the full path without piecing together curl output, the AcuityScan redirect checker traces every hop for a URL and shows the status code, destination, and timing at each step, including loops and mixed permanent and temporary redirects. Because redirect hops show up as first-byte delay rather than slow rendering, it pairs well with the performance tool when a page feels slow but profiles clean, and with the HTTP headers tool when a hop is being added by a header rule such as HSTS.

For the whole picture, a full scan at acuityscan.com runs 350+ checks across 8 modules, including redirect behavior, performance, SSL, headers, and accessibility, and returns each finding with a plain-English fix.

TL;DR

• A redirect chain is any path where a redirect points at another redirect instead of the final URL.
• Each hop can add a DNS lookup, TCP connection, and TLS handshake, commonly 300 to 600 milliseconds on mobile, all of it before your page starts loading.
• Googlebot follows up to ten hops, but long chains waste crawl requests and slow signal consolidation.
• Chains form from stacked rules across CDN, host, and application layers, plus old migration rules nobody removed.
• Collapse protocol and host into a single 301, point old rules at current destinations, fix internal links, and enforce the canonical form at one layer only.
• Verify with curl -sIL or a redirect trace after every infrastructure change.