What Is a Redirect Chain (and Why Every Hop Costs You)

Aug 08, 2026 · SEO Glossary

Run this against any established site and prepare to be mildly horrified:

curl -sIL http://example.com/old-page | grep -i "^HTTP\|^location"

What you'll often see: http:// 301s to https://, which 301s to the www version, which 301s to a URL with a trailing slash, which 301s to wherever the content moved in 2023. Four responses before any content. That's a redirect chain, and once a site has been through a couple of redesigns, they're everywhere.

What is a redirect chain, formally? Any sequence where URL A redirects to B, and B redirects onward to C (and possibly D, E, F) instead of A pointing straight at the final destination. A related defect is the redirect loop — A eventually redirects back to A — which returns no content at all and throws ERR_TOO_MANY_REDIRECTS.

What Each Hop Costs

The latency cost lands directly on users: a chain in front of your page pushes back time to first byte, and every downstream metric — LCP included — inherits the delay. On the crawling side, Google's documentation is explicit that Googlebot follows up to 10 hops before giving up; in practice it often stops following within a session much sooner and resumes later, which is why deeply chained URLs update sluggishly in the index. On sites with hundreds of thousands of URLs, chained redirects are a genuine crawl budget leak.

What about PageRank? Google has said for years that 301 redirects pass full link equity, and that this holds through reasonable chains. Believe it — but note the fine print: "reasonable." A signal passed through five hops depends on Google faithfully crawling and consolidating five steps, and every extra step is a place for something to break (one hop flips to a 302, one URL starts 404ing, one hop gets blocked by robots.txt). Flat redirects have no fine print.

Two hop types people forget to count: meta refresh redirects and JavaScript window.location redirects. Google processes both (slowly, and the JS variant only after rendering), and they chain with your server-side redirects — an htaccess 301 landing on a page that meta-refreshes onward is a two-hop chain that most redirect reports miss, because the second hop lives in the HTML, not the headers. If you find either type in an audit, replace it with a proper server-side redirect.

How Chains Accumulate

Nobody builds a five-hop chain on purpose. They're geological — each layer was correct when deposited:

• Protocol and host normalization stacking. The http→https rule, the non-www→www rule, and the trailing-slash rule each fire as separate redirects instead of one combined rule. This alone puts 2–3 hops in front of every legacy URL.
• Migration on top of migration. 2019's URL structure redirects to 2022's, which redirects to the current one. The old maps never get updated to point at final destinations.
• CMS slug changes. Each rename adds a redirect from the previous slug — chains grow one hop per edit.
• Internal links pointing at redirected URLs. Not a chain by itself, but it forces every user and crawler through at least one needless hop, thousands of times a day.

What Is a Redirect Chain Audit? Finding and Flattening

The fix has two halves, and most people only do the first.

Flatten the redirects. Crawl your site with a tool that reports full redirect paths — a site auditor will list every chain with each intermediate URL and status code. For each chain, update the first redirect to point directly at the final destination. Keep the old rules' sources (external links still point at those URLs) but make every source resolve in one hop. Combine your protocol/host/slash normalization into a single server rule where the stack allows it.

Fix the internal links. This is the half that gets skipped. Every internal link that points at a redirecting URL should be updated to the final URL — otherwise you've flattened the chain but still tax every crawl and click with a hop. Your crawl report shows which pages contain links to redirecting URLs; fixing the templates usually clears most of them at once.

Then verify with curl (the command up top shows the whole path) and spot-check in Search Console's URL Inspection, which reports "Page with redirect" and follows the trail. After a big cleanup, watch crawl stats for a few weeks — total crawl requests spent on redirects should drop visibly.

Rules of Thumb

• One hop is fine and often unavoidable. Two is tolerable during transitions. Three or more is a defect worth a ticket.
• Never link internally to a URL you know redirects.
• After any migration, crawl the old URL list and confirm every entry resolves in a single 301 to its final home.
• Re-check quarterly — chains regrow with every redesign, and monitoring is cheaper than archaeology.