Redirect Chain SEO: How to Find and Fix Redirect Chains That Drain PageRank

A redirect chain is a series of redirects where URL A redirects to URL B, which redirects to URL C — instead of A redirecting directly to C. Each intermediate hop reduces the PageRank passed to the final destination, wastes crawl budget, and adds latency that degrades user experience. Redirect chains are common after site migrations, URL restructures, and CMS platform changes — and are frequently overlooked because each individual redirect appears functional when tested in isolation.

What is a redirect chain?

A single 301 redirect: old-url.com/page → new-url.com/page — this is correct. PageRank and link equity flow from the old URL to the new URL through the 301.

A redirect chain: old-url.com/page → staging.new-url.com/page → www.new-url.com/page → new-url.com/page — this is three hops. The staging URL was left in place after launch; the www redirect is a protocol normalisation; and the final URL is the actual destination. A link pointing to old-url.com/page must traverse three redirects to reach the canonical destination.

Redirect chains accumulate when:

• A URL that already redirects gets redirected again (site migration on top of prior migration)
• HTTP → HTTPS and www → non-www redirects are layered on top of content redirects
• Redirect plugins or rules are added incrementally without auditing existing chains
• A CMS changes URL structures (Shopify collection URL updates, WordPress permalink changes) and old redirects aren't consolidated

How redirect chains affect SEO

PageRank loss at each hop. Google has confirmed that PageRank dilution occurs through redirect chains. Each 301 hop passes the majority of link equity — but not all of it. A two-hop chain (A → B → C) passes less equity to C than a direct redirect (A → C). A five-hop chain loses substantially more. Google's crawlers follow chains up to approximately 5 redirects before stopping, meaning a URL 6 hops deep from its inbound links effectively receives no link equity from those links.

Crawl budget waste. Googlebot has a finite crawl budget per site — it won't crawl infinitely many URLs per day. Each URL in a redirect chain consumes crawl budget even though none of the intermediate URLs deliver unique content. A site with hundreds of redirect chains consumes crawl budget on intermediate redirects rather than on new or updated content. For large sites (10,000+ pages), this is measurable in crawl frequency and indexing speed.

User experience latency. Each redirect hop is an additional HTTP round-trip. A three-hop chain can add 200–600ms of latency before the browser begins loading the final page. This affects real Core Web Vitals measurements (TTFB, LCP) because the browser cannot request the page's resources until all redirects resolve.

Indexation inconsistency. Google may index the intermediate redirect URLs rather than the final destination, particularly when those intermediate URLs have been crawled multiple times. This creates inconsistencies in Search Console's Index Coverage report — indexed URLs that don't deliver content.

How Google handles redirect chains

Google follows redirect chains up to 5 hops. A chain deeper than 5 hops will not be fully followed — the sixth hop and beyond will not be crawled, and the final destination URL will not receive equity from links pointing to the chain's start.

For chains of 2–5 hops, Google does follow them, but the PageRank transfer is reduced at each hop. Google has published guidance that a single clean 301 from old URL to final destination is preferred over any multi-hop chain.

Google also handles redirect chains differently across crawl types:

• First-time crawl of a URL: follows up to 5 hops, indexes the final destination
• Subsequent crawls: rechecks the first hop; if the chain has changed, follows the updated chain
• Google may not immediately update its link graph when chains are collapsed — allow 1–4 weeks after collapsing for the link equity to propagate

Finding redirect chains in your site

Crawl your own site with a tool that follows and reports redirect chains (Screaming Frog, OnCrawl, or Sitebulb). Look for URLs with status code 301/302 that point to another 301/302 URL — those are chains. The tool should show the full chain (hop 1 → hop 2 → hop n → final URL) and the chain length.

Check high-priority URLs manually by curling the response headers:

curl -I -L "https://yoursite.com/old-url"

The -L flag follows redirects; the -I flag shows headers only. Look at the Location: header sequence — each hop appears as a separate 30x response before the final 200.

Google Search Console → Crawl Stats shows redirect percentages in crawl responses. A high proportion of 3xx responses relative to 2xx responses suggests many redirects — potentially chains.

Inbound link audit. Check which URLs your backlinks point to. If multiple inbound links point to a URL that is the start of a redirect chain rather than a clean 301 to the final destination, you're losing link equity through those links.

Fixing redirect chains

The fix is always the same: update the source of each hop to point directly to the final destination URL, collapsing the chain to a single 301.

Step 1: Map the full chain. For A → B → C, you need to know A, B, and C — and which URLs (internal links, external backlinks, XML sitemap entries) currently point to A or B.

Step 2: Update the redirect rule for A. Change A's redirect from A → B to A → C. This is usually done in your .htaccess file, nginx config, CDN redirect rules, or redirect manager plugin.

Step 3: Update internal links. Any internal link pointing to A (or B) should be updated to point directly to C. This improves link equity distribution and ensures future crawls reach C in one request.

Step 4: If B had its own inbound links, keep B → C in place — don't delete B's redirect. You've collapsed the chain (A now goes directly to C), but B's redirect to C should remain for any external links pointing to B.

Step 5: Check the XML sitemap. The sitemap should list only canonical, live URLs (returning 200). Remove redirect chain entry points (A, B) from the sitemap and ensure C is listed.

Step 6: Verify no new chains. After updating redirects, re-crawl the paths to confirm no new chains were introduced.

Common causes of redirect chains in popular CMS environments

WordPress. Redirect plugins (Redirection, Yoast Premium redirect manager) often create chains when a URL is redirected twice without auditing existing rules. A slug change in WordPress creates a default redirect via WordPress's own built-in redirect functionality — and then a plugin redirect might add another hop. Permalink structure changes (e.g., from /?p=123 to /post-slug/) affect all existing posts simultaneously. The combination of: built-in WordPress redirect + plugin redirect + HTTP→HTTPS redirect + www→non-www redirect can easily create 4-hop chains on all posts simultaneously.

Shopify. Shopify's URL structure for collections changed (from /collections/[handle]/products/[product-handle] to simply /products/[product-handle]). Sites that went through this migration and created redirects, then later changed product handles, can have chains. Shopify's built-in URL redirect manager doesn't detect or prevent chains — if you redirect A→B and then B→C, both rules remain independently without collapsing.

Next.js. The redirects() array in next.config.mjs can create chains if a redirect destination later itself gets redirected. This is more common in projects that add redirects incrementally over time. The Next.js development server logs chain warnings, but they may not be visible in production builds.

FAQ

How many redirect hops is too many?

More than one hop is worth fixing. More than three hops is urgent to fix. More than five hops means Googlebot will stop following the chain and the final destination won't receive link equity from the chain's entry points. Even a two-hop chain (A→B→C) reduces PageRank transfer to C compared to a direct A→C redirect — the fix is always worth doing.

Do redirect chains affect Core Web Vitals?

Yes, directly. Each redirect hop requires an HTTP round-trip before the browser can begin loading the final page. A three-hop chain can add 300–900ms of latency, degrading Time to First Byte (TTFB) and consequently LCP. In CrUX field data, real users experience this latency — it appears in p75 LCP measurements for affected URLs.

What's the difference between a redirect chain and a redirect loop?

A redirect chain has a definitive end (eventually reaches a 200 OK URL). A redirect loop has no end: A redirects to B, B redirects back to A, or A→B→C→A. Redirect loops cause browser errors ("too many redirects") and are always bugs rather than intentional. Redirect loops must be fixed immediately — they make affected URLs completely inaccessible. Redirect chains are less severe (the page still loads) but still cause SEO and performance problems.

Should I 301 or 302 when collapsing redirect chains?

Always 301 (permanent redirect) when the old URL is permanently gone and the new destination is the canonical home for that content. Use 302 (temporary redirect) only when you intend to revert the redirect later. PageRank flows through 301 redirects; Google's handling of 302 redirects is less predictable for link equity transfer.