Redirect Chains

TL;DR — A redirect chain is when one URL redirects to another URL that also redirects, instead of going straight to the final page — A → B → C instead of A → C. Each extra step is called a “hop.” Chains mostly build up after site moves, they slow things down a little for users and search engines, and the fix is always the same: make every redirect point directly at the final page, not at another redirect.

What a redirect chain is

A redirect chain is multiple consecutive redirect responses before a final resource. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Redirection Google recommends redirecting directly to the final destination and may stop following overly long chains. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Redirects and Search

When you visit an old URL that has moved, your server sends a redirect — an HTTP response that says “the page you asked for lives somewhere else now, go there instead.” Normally that’s one clean step: you ask for page A, you land on page B. Done.

A redirect chain is when that one step turns into several. You ask for page A, which redirects to page B, which redirects to page C, which is the real page. Each of those in-between stops is a hop. Instead of A → C in one move, you get A → B → C — or worse.

Why it happens

Almost always because a site has moved more than once over the years. A URL gets redirected when you switch domains. Then it gets redirected again when you move from HTTP to HTTPS. Then again when you change platforms. Nobody went back and cleaned up the old rule, so now the request has to walk through all of them in a row. It’s not a sign someone did something wrong — it’s just what accumulates.

Does it hurt?

A little, and usually less than people fear. The two real costs are:

• Speed. Every hop is an extra round-trip, so a long chain makes the page load a touch slower for real visitors.
• Crawling. Search engines will follow a chain, but only so far in one go, and a very long chain can delay how quickly they fully “settle” on the final page.

What a chain does not do is drain a chunk of ranking power at every hop — that’s an old myth. A permanent redirect doesn’t cost you ranking value.

The fix

There’s really only one rule, and it never changes: make every redirect point straight at the final destination. Instead of A → B → C, rewrite it so A goes directly to C. Then update any links, sitemaps, or canonical tags that still point at B or an old URL so they point at C too.

Don’t lose sleep over one stray extra hop on a page nobody visits. Do clean up long chains on your important, frequently-visited pages.

Want the specific hop numbers Google publishes, the reasons chains form, and how to actually find them with a command line or a crawler? Switch to the Advanced tab.

TL;DR — A redirect chain is A → B → C instead of a direct A → C, where each hop is one redirect, ending at the first non-redirect response — not necessarily a 200. They’re the near-inevitable residue of stacked migrations, plugin conflicts, and unordered rules — not incompetence. The three hop numbers everyone quotes describe different things and don’t contradict: 10 is the technical ceiling Googlebot will follow (current docs), and ≤3, fewer than 5 is Google’s current practical recommendation. Mueller separately described ~5 per crawl in 2014 and ~5 per crawl attempt in 2020; in 2014 he also described a later crawl continuing the remainder. Those are dated representative statements, not a current scheduling guarantee. My observation that Google often resumes longer chains is separate practitioner evidence. The documented cost is latency and crawl processing, not per-hop PageRank loss — a single permanent redirect doesn’t lose PageRank. The fix is invariant: repoint every redirect straight at the final live destination, then fix the internal links, canonicals, and sitemaps that still feed the chain.

What counts as a chain (and what doesn’t)

Each 3xx hop is a separate HTTP exchange. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Redirection No universal ranking-loss percentage or fixed crawl limit is documented, so one direct hop is the defensible target. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Redirects and Search

A redirect chain is two or more consecutive redirect responses before the first non-redirect response — A → B → C instead of A → C. Each redirect in the sequence is a hop. The chain ends at whatever response isn’t itself a redirect: that’s usually a working 200, but it can just as easily be a 404, a 500, an authentication challenge, or another terminal outcome. A chain that dead-ends in an error is still “just a chain” — a broken one, but not automatically a loop.

A redirect loop is a different, more specific problem: it’s cyclic. One of the hops eventually points back to a URL the path already visited, so the request never reaches a terminal response and the browser throws ERR_TOO_MANY_REDIRECTS. The distinction that matters is cyclic vs. non-cyclic — not “long” vs. “short,” and not “ends in an error” vs. “ends in 200.” A two-hop loop is still a loop; a ten-hop chain that ends in a 404 is still a chain.

In my 11 Types Of Redirects & Their SEO Impact I put it simply: “Redirect chains are when multiple redirects take place between a requested resource and its final destination.”

Why chains happen in practice

Chains are rarely a single sloppy decision. They accumulate:

• Stacked migrations. This is the big one. A URL redirected during a domain move gets redirected again during the HTTPS migration, then again during a platform switch — each move adds a layer on top of the last instead of replacing it. http://old → https://old → https://new is three rules where one would do.
• www/non-www + HTTP/HTTPS handled as separate rules. http://www → https://www → https://non-www is a classic three-hop chain that should be a single combined rule.
• CMS and plugin conflicts. Two redirect plugins, or a plugin rule plus a server rule, both firing on the same URL.
• Wildcard rules placed ahead of specific rules. A broad catch-all (old domain → new homepage) sitting before the specific rule means the specific rule never fires — the request follows the wildcard first. Bing explicitly tells site owners to put specific redirect rules before the wildcard for exactly this reason.

Worked migration example: three sensible rules, one unnecessary chain

An apparel site has accumulated three separately reasonable changes:

301  http://old-shop.example/products/trail-shoe
301  https://old-shop.example/products/trail-shoe
301  https://shop.example/products/trail-shoe
200  https://shop.example/shoes/trail-runner

The first rule upgrades HTTP, the second moves the domain, and the third reflects a catalog rename. The problem is not any one migration. It is that the old entry point still replays all three historical decisions.

Replace that path with one direct permanent redirect:

301  http://old-shop.example/products/trail-shoe
200  https://shop.example/shoes/trail-runner

Then update internal links, canonicals, and sitemap entries that still advertise an intermediate URL. This is an illustrative .example trace, not a report about a specific company.

And a specific anti-pattern worth calling out: don’t stack a broad “everything → homepage” catch-all on top of existing specific redirects. Google warns that redirecting many old URLs to one irrelevant destination “might be treated as a soft 404 error.” Redirect old URLs to their real equivalents, 1:1.

How many hops does Google actually follow?

This is where competing articles muddle three different numbers into one. They’re complementary, not contradictory:

1. The technical ceiling — 10 hops. Straight from Google’s Site Moves and Migrations doc: “While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly.” Ten is the most Googlebot will ever walk through in total before it gives up.

2. The practical recommendation — ≤3, fewer than 5. Same sentence, same doc: “If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” This is Google’s own advice, not a third-party guess.

3. The dated representative statements — about 5 hops per crawl. In a 2014 webmaster hangout at 46:03, John Mueller described Googlebot following as many as five redirects in one crawl and, if more remained, continuing them in the next crawl. In a separate 2020 Reddit comment reported by Search Engine Journal, he said Google follows “up to 5 hops in the chain per crawl attempt.” The 2014 statement is real representative evidence for later continuation; it was not invented. It is also historical, so don’t turn it into a guarantee that current Googlebot will always resume a chain, or that it will do so on a predictable schedule.

My own observation from real sites independently matches that pattern: Google often picks a longer chain back up, and I use about five hops as a triage threshold. That is practitioner evidence and an operational cutoff, not the source of Mueller’s 2014 statement and not a Google platform limit.

So the reconciliation is: 10 is Google’s current documented ceiling; 3-to-5 (fewer is better) is its current practical target; and ~5 per crawl is dated representative guidance from Mueller. A chain longer than 5 hops doesn’t necessarily fail outright — it typically just delays how quickly Google reaches and consolidates on the destination. Past the 10-hop ceiling, a redirect error can surface in Search Console’s Page Indexing report, but that’s not a guaranteed one-to-one mapping — what gets logged depends on what the crawler actually observed on that attempt, and a chain can also just resolve more slowly rather than throwing a specific error.

Why chains matter — and the myth they don’t

The documented cost of a chain is latency and crawl processing, not signal loss per hop. Google’s own wording: chaining redirects “adds latency for users, and not all user agents and browsers support long redirect chains.”

Keep this separate from the debunked “PageRank loss per redirect” folklore. Google is explicit that “301 and other permanent redirects don’t cause a loss in PageRank.” That statement is about a single hop — it doesn’t mean an unlimited chain is free, because the chain’s cost is a different thing (crawl latency and time-to-consolidate), not per-hop equity leakage. Both can be true at once: one redirect loses no PageRank, and a long chain still wastes crawl processing and delays indexing.

When to fix a chain — and when not to bother

Here’s where I differ from a lot of the trade content: don’t over-optimize. Many SEOs are obsessed with getting rid of even one additional hop for a redirect. I would not worry about that at all. In my website-migration writing I’ve said I wouldn’t worry about things like a redirect chain on the root path, or chasing every external site to update their links to you.

My actual working threshold: I don’t typically worry about redirect chains under about 5 hops, but past 5 I’ve seen issues with them being crawled and counted properly — so that’s my cutoff for telling people to start working on them. Weight that by the path, too: a 5-hop chain on a frequently-crawled, high-value URL is worth fixing; a stray extra hop on a low-traffic page usually isn’t worth your afternoon.

How to find redirect chains

Detection is layered — command line for spot checks, crawlers for site-wide:

• curl -IL <url> on macOS/Linux (or Invoke-WebRequest on Windows) prints every hop’s status line down to the final 200. Fastest way to trace one URL. See the Scripts tab for copy-paste commands.
• Browser devtools → Network tab. Load the URL, watch the sequence of 301/ 302 requests before the final 200. Good for one-off visual checks.
• Screaming Frog. Response Codes tab, plus Reports → Redirects → Redirect Chains for a site-wide export of every chain and its hop count.
• Ahrefs Site Audit. The Redirects report flags a “Redirect chain too long” issue. In Site Explorer you can also filter backlinks or outgoing links by “No. of redirects,” and the Ahrefs SEO Toolbar’s HTTP headers tab shows the redirect sequence for a link you click.

A chain report is only one slice of the existing-rule review. The redirect-estate audit also checks dead final targets, homepage/generic dumps, broad wildcards that swallow live URLs, and whether a long-unused rule can be retired through a logged, reversible 404 probe.

How to fix them

One rule, everywhere: point every redirect directly at the final live destination, never at another redirect. “Fixing a chain” is really just rewriting each rule’s target from the intermediate URL to the true final URL. A → B → C becomes A → C and B → C.

Then finish the job most people skip:

• Update internal links so they point at the final URL, not at a redirecting one — otherwise your own site keeps feeding the chain.
• Update canonical tags and XML sitemaps that still list old or intermediate URLs.
• Order your rules correctly so you don’t create new chains: specific rules before wildcards/catch-alls, and combine www/HTTPS consolidation into a single rule where you can.
• Check the status codes, not just the destinations, if anything in the chain isn’t a plain page request. 301 and 302 can let a client turn a POST into a GET on the next hop; 307 and 308 preserve the original method. A chain that’s harmless for a browser loading a page can silently break a form submission, an API call, a signed URL, or a webhook if the wrong status type is mixed in.

Do that and the chain collapses to a single hop — which is all you ever needed.

Related reading in this cluster: the difference between a permanent and temporary redirect (301 vs 302), and what happens when a chain never terminates (redirect loops).

AI summary

A condensed take on the Advanced version:

• Definition: A redirect chain is A → B → C instead of a direct A → C. Each redirect is a “hop.” It ends at the first non-redirect response — a success, an error, or another terminal outcome, not necessarily 200. A redirect loop is different: it’s cyclic, looping back to a URL already visited in the same path.
• Why they form: Stacked migrations (domain → HTTPS → platform, each layered on the last), www/non-www + HTTP/HTTPS as separate rules, plugin/CMS conflicts, and wildcard rules placed ahead of specific ones.
• The three hop numbers, reconciled: 10 = the technical ceiling Googlebot will follow (current docs). ≤3, fewer than 5 = Google’s current practical recommendation. ~5 per crawl/attempt = dated Mueller statements from 2014 and 2020; the 2014 statement also described continuing the remainder on a later crawl. That history is not a current scheduling guarantee. Patrick’s observation that Google often resumes longer chains is independent practitioner evidence.
• Past the limit: A chain over ~5 hops typically delays consolidation rather than failing outright. Past the 10-hop ceiling, a Search Console redirect error can surface, but it’s not a guaranteed one-to-one mapping — it depends on what the crawler actually observed.
• The real cost is latency and crawl processing, not per-hop PageRank loss. Google says a single permanent redirect doesn’t lose PageRank; the chain’s cost is a separate, latency/crawl-efficiency problem.
• Patrick’s stance: Don’t over-optimize a single stray hop. His threshold is ~5 hops, weighted by how frequently the path is crawled.
• The fix (invariant): Point every redirect directly at the final destination, then update internal links, canonicals, and sitemaps that still feed the chain, and order specific rules before wildcards.

Official documentation

Primary-source documentation from the search engines.

Google

• Site moves with URL changes — contains the core “avoid chaining redirects” guidance: the 10-hop ceiling, the ≤3 / fewer-than-5 recommendation, and the “don’t redirect many old URLs to one irrelevant destination” warning.
• How HTTP status codes, and network and DNS errors affect Google Search — Google’s 3xx redirection handling, linked directly from the hop-limit sentence in the site-move doc.
• Redirects and Google Search — the redirect types Google recognizes (server-side, meta refresh, JavaScript) and how each is treated.
• Optimize your crawl budget — the crawl-efficiency context for why wasted crawl steps (like long chains) matter on big sites.

Bing / Microsoft

• Website Migration with Bing — explicitly names “unnecessary redirect chains” as a migration QA error to catch by re-crawling, and advises ordering specific redirect rules ahead of the wildcard redirect to avoid creating chains.

Quotes from the source

On-the-record statements from Google and Bing. Each link is a deep link that jumps to the quoted passage on the source page.

Google — the hop limits and recommendation

• “Avoid chaining redirects. While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” — Google Search Central, Site moves with URL changes. Jump to quote

• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.” — Google Search Central, Site moves with URL changes. Jump to quote

• “301 and other permanent redirects don’t cause a loss in PageRank.” — Google Search Central, Site moves with URL changes. Jump to quote

John Mueller, Google (2020, via Search Engine Journal’s reporting of his Reddit comment)

• “The only thing I’d watch out for is that you have less than 5 hops for URLs that are frequently crawled. With multiple hops, the main effect is that it’s a bit slower for users. Search engines just follow the redirect chain (for Google: up to 5 hops in the chain per crawl attempt).” — John Mueller, as reported by Search Engine Journal. Read the coverage

John Mueller, Google (2014 webmaster hangout; primary video)

• Mueller described Googlebot following up to five redirects in one crawl and, if more remained, continuing them during the next crawl. Watch from 46:03

Bing — migration QA

• “Crawling the new website thereafter will reveal any unexpected errors, such as unnecessary redirect chains or error pages.” — Bing Webmaster Blog, Website Migration with Bing. Jump to quote

Auditing for redirect chains — checklist

A pass to find, prioritize, and flatten chains without over-engineering:

Find them

• Crawl the whole site with Screaming Frog or Ahrefs Site Audit and pull the redirect-chain report (Screaming Frog: Reports → Redirects → Redirect Chains; Ahrefs: Redirects → “Redirect chain too long”).
• Spot-check key URLs from the command line with curl -IL <url> and confirm each ends at a single 200 (see the Scripts tab).
• Check the obvious migration culprits: the root/homepage path, http:// vs https://, and www vs non-www variants.
• Review Search Console’s Page Indexing report for redirect errors — a chain that stalls past the hop ceiling can surface here, though not every long chain generates this specific error.

Prioritize (don’t fix everything)

• Sort chains by hop count — flag anything at 5+ hops first.
• Weight by traffic and crawl frequency: fix long chains on important, frequently-crawled paths before stray hops on low-traffic URLs.
• Confirm each flagged item is a chain (ends at 200), not a loop (never resolves / ERR_TOO_MANY_REDIRECTS) — loops are a separate, more urgent fix.

Fix them

• Repoint every redirect rule at the final live destination, not an intermediate URL (A → B → C becomes A → C and B → C).
• Update internal links pointing at redirecting URLs so they hit the final URL.
• Update canonical tags and XML sitemaps that still list old/intermediate URLs.
• Reorder rules: specific redirects before wildcard/catch-all rules.
• Combine www/non-www + HTTP/HTTPS consolidation into a single rule where possible instead of separate chained rules.
• Re-crawl to confirm each fixed URL now resolves in one hop.

Trace a redirect chain from the command line

The fastest way to see every hop for a single URL is curl. The -I fetches only headers, and -L tells curl to follow the redirects so you see the whole chain, not just the first hop.

-I sends a HEAD request, not GET. Most redirect rules answer HEAD and GET identically, but an application layer, CDN, WAF, or authentication check can respond to them differently. For a quick spot check that’s usually fine; for anything method-sensitive — a form endpoint, an API, a signed URL — drop -I and run a GET-based trace instead so you’re seeing the same path a real request takes.

macOS / Linux

# -I headers only, -L follow redirects, -s quiet, and print each status line + Location
curl -sILo /dev/null -w '%{http_code} %{url_effective}\n' https://example.com/old-page

# Or see the full header of every hop in the chain, down to the final response:
curl -sIL https://example.com/old-page | grep -Ei '^(HTTP/|location:)'

# GET-based trace (safer than -I's HEAD request for method-sensitive paths;
# -o /dev/null discards the response body, -w prints the final status/URL)
curl -sL -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com/old-page

A clean, single-hop result prints one redirect status (e.g. 301) and then a 200. A chain prints several redirect status lines before the 200 — count them; that’s your hop count.

HTTP/2 301
location: https://example.com/intermediate
HTTP/2 301
location: https://www.example.com/final
HTTP/2 200          # <- 2 hops before landing here = a 2-hop chain

Windows (PowerShell)

PowerShell’s Invoke-WebRequest follows redirects automatically, so trace them by inspecting the history:

# Follow redirects and print the status of each hop plus the final URL
$r = Invoke-WebRequest -Uri "https://example.com/old-page" -MaximumRedirection 10
$r.BaseResponse.RequestMessage.RequestUri   # the final resolved URL

# To see each intermediate hop, disable auto-follow and step through manually:
$u = "https://example.com/old-page"
do {
  $resp = Invoke-WebRequest -Uri $u -MaximumRedirection 0 -SkipHttpErrorCheck
  "{0}  {1}" -f $resp.StatusCode, $u
  $u = $resp.Headers.Location
} while ($u)

Site-wide detection (crawlers)

Command-line checks are for spot-checking one URL. For a whole site, use a crawler:

• Screaming Frog SEO Spider — crawl the site, then Reports → Redirects → Redirect Chains exports every chain with its hop count and the full path from first URL to final destination. The Response Codes tab (filtered to redirects) is the interactive view.
• Ahrefs Site Audit — the Redirects report surfaces a “Redirect chain too long” issue automatically on each crawl. In Site Explorer you can also filter backlinks or outgoing links by “No. of redirects” to find external links pointing into a chain.

Either tool gives you the site-wide list; use curl -IL to verify individual fixes resolve in a single hop afterward.

Common redirect-chain symptoms

HTTP → HTTPS → www (or the reverse) on every request

Likely cause: Scheme and hostname normalization live in separate rules, so each rule adds a hop.

Fix: Combine normalization so every variant points directly to the one canonical scheme-and-host destination. Confirm with a trace from each common variant; each should reach the final URL without visiting the other variant first.

Old URLs pass through several historical paths

Likely cause: Successive migrations stacked new redirects on top of old maps: /old → /less-old → /new.

Fix: Resolve the current final destination and update every historical source to point there directly. Re-run the old URL inventory and confirm no source lands on another redirect.

The chain returns after a CMS or plugin change

Likely cause: Application redirects overlap with web-server, CDN, or another plugin’s rules.

Fix: Trace the hop fingerprints and headers to identify which layer emits each redirect, choose one owner for the rule, and remove the duplicate. Test after cache purges so a stale edge response does not look like a current rule.

A specific redirect is swallowed by a wildcard

Likely cause: A broad pattern runs before the more specific mapping, sending the URL to an intermediate destination.

Fix: Put exact/specific rules before general patterns or exclude the known paths from the wildcard. Confirm the specific URL and a representative wildcard URL both go directly to their intended final destinations.

Prompt: prioritize a batch of redirect traces

Export hop-level data with source URL, each hop’s status and destination, final URL, organic traffic or clicks if available, and internal-link count. Paste the data after this prompt.

Audit these redirect traces. For each source URL:
- count redirect hops before the final non-redirect response;
- flag loops, broken final responses, temporary redirects inside an intended
  permanent move, and chains longer than 5 hops;
- identify the direct source-to-final mapping that would flatten the chain;
- prioritize by user/search traffic, internal-link count, and severity;
- distinguish a technical ceiling from best practice: do not claim that every chain
  under 10 hops is healthy or that one low-value extra hop is automatically urgent;
- never invent a destination when the supplied trace has no valid final equivalent.

Return a table with source URL, hop count, final status, issue, recommended direct
mapping, priority, and evidence. Then list internal links, canonicals, and sitemap
entries that still point into a chain if those columns are present.

DATA:
[PASTE REDIRECT TRACE CSV HERE]

Review the proposed mappings against content equivalence before changing production redirect rules.

The redirect-hop numbers, reconciled

These figures answer different questions. Ten is the outer following limit, roughly five describes work in one crawl attempt, and three-to-five is practical guidance. None justifies preserving a chain you can safely flatten.

Tools for finding and flattening chains

• Redirect Chain Mapper — trace every hop for one URL or a batch, see what changes at each step, and export cleanup rules for common server platforms. Start here for visual diagnosis and a direct source-to-final map.
• Redirect Checker — a fast check of final status, destination, and hop sequence for one URL or a small batch.
• Bulk HTTP Status Code Checker — paste a larger URL list, filter multi-hop paths and temporary redirects, and export the affected rows.
• A full-site crawler — find internal links, canonicals, hreflang references, and sitemap URLs that still enter a chain. Flattening the server rule is only half the cleanup if the site keeps requesting the old source.

Test yourself: Redirect Chains

Five quick questions on what redirect chains are, how many hops Google follows, and how to fix them. Pick an answer for each, then check.

Redirect chain

A → B → C instead of A → C. Each hop loses link equity and adds latency.

Related: 301 redirect, Redirect loop

Redirect chain

A redirect chain is a sequence of redirects (A → B → C) instead of a direct hop (A → C). Each intermediate step — a “hop” — adds latency for users and crawlers and increases the risk that ranking signals don’t fully consolidate on the final destination.

Chains are usually the byproduct of stacked site migrations: a URL redirected during one move gets redirected again during the next (domain change, then HTTP→HTTPS, then a platform switch), each layer added on top of the last instead of replacing it. Googlebot will follow up to 10 hops total, but Google recommends keeping chains to no more than 3 and fewer than 5, and John Mueller has said Google processes about 5 hops per crawl attempt (resuming a longer chain on a later crawl). The fix is always the same: point every redirect directly at the final live destination, never at another redirect.

A chain is distinct from a redirect loop — a chain terminates at a real 200 page, whereas a loop never resolves and eventually throws ERR_TOO_MANY_REDIRECTS.

Related: 301 redirect, Redirect loop

Changelog