You migrated your site and confirmed every old URL redirects to the correct new URL. Rankings dropped anyway. The crawl audit revealed the problem: your redirect paths included intermediate hops — a 301 to a 302 to the final 200. Google followed the chain but the mixed redirect types introduced ambiguity about whether the move was permanent or temporary, which affected how much link equity transferred to the final destination. A single clean 301 would have transferred full equity. The chain transferred partial equity and consumed three crawl requests instead of one to resolve a single URL.
Googlebot follows redirect chains up to a hop limit, consuming crawl budget at each hop
Each redirect in a chain requires a separate HTTP request from Googlebot. When Googlebot requests URL A and receives a 301 response pointing to URL B, it must make a new request to URL B. If URL B returns a 302 pointing to URL C, a third request is required. Each hop in the chain consumes one crawl request from the site’s daily crawl budget.
Google follows redirect chains up to approximately 10 hops before abandoning the chain entirely. At that point, Googlebot treats the URL as unreachable and records a redirect error. However, the practical impact threshold is much lower. Even 2-3 hop chains multiply the crawl cost for every affected URL.
The math scales linearly with the number of affected URLs. A site with 10,000 URLs behind 3-hop redirect chains consumes 30,000 crawl requests to resolve what would require 10,000 requests with direct redirects. On a site with a daily crawl budget of 15,000 requests, those extra 20,000 requests represent more than a full day of wasted crawl capacity.
The waste compounds during migration periods when Google re-crawls old URLs frequently to verify redirect destinations. During the first 30 days of a migration, Google may recrawl redirected URLs 3-5 times to confirm the redirect is stable. A 3-hop chain recrawled 5 times produces 15 requests per URL. Across 10,000 URLs, that is 150,000 requests — potentially consuming the entire crawl budget for 10 days.
Common sources of unintentional redirect chains include layered migrations (HTTP to HTTPS added on top of old domain-to-domain redirects), CMS redirect plugins that add trailing slash normalization after existing redirects, and CDN-level redirects that precede origin server redirects. A single URL can accumulate 4-5 hops through successive layers of redirect logic that were never consolidated.
Mixed redirect types within a chain create equity transfer ambiguity
Google has confirmed that both 301 and 302 redirects pass PageRank without dilution when used individually. Gary Illyes stated in 2016 that there is “no PageRank dilution when using 301, 302, or 30x redirects.” However, this statement applies to single-hop redirects. When multiple redirect types are mixed within a chain, the canonical selection logic introduces ambiguity that can reduce effective equity transfer.
A 301 redirect signals a permanent move. Google interprets this as an instruction to transfer canonical status and all associated signals (PageRank, anchor text, indexing history) to the destination URL.
A 302 redirect signals a temporary move. Google interprets this as the source URL remaining canonical, with the destination serving as a temporary alternative. Google may still pass PageRank through a 302, but canonical status remains with the source.
When both appear in a chain, Google must resolve conflicting permanence signals. Consider the chain: URL A (301) -> URL B (302) -> URL C (200).
- The 301 from A to B says “A has permanently moved to B.”
- The 302 from B to C says “B is temporarily redirecting to C.”
- From Google’s perspective, the canonical intent is ambiguous. Did the site permanently move to B (which happens to temporarily redirect to C)? Or did the site permanently move to C through an incorrectly configured intermediate step?
In practice, Google tends to follow the chain to its terminal destination but may attribute canonical status to an intermediate URL rather than the final destination. John Mueller has explained that Google puts all URLs in a redirect chain “into a shared cluster” for canonicalization processing. Within that cluster, Google evaluates which URL should be canonical using up to 20 different signals, with machine learning adjusting the weights. The mixed redirect types add noise to this evaluation.
The safest interpretation of Google’s behavior: a single clean 301 from old URL to new URL produces the strongest, fastest canonical transfer. Any chain, especially one with mixed types, introduces processing overhead and canonical ambiguity that can delay or weaken the transfer.
Intermediate URL canonical capture and crawl efficiency degradation from redirect chains
The canonical selection risk in mixed chains is that Google selects an intermediate URL as canonical rather than the intended final destination. This occurs when the 302 redirect in the chain signals that the intermediate URL is the “real” page.
Scenario: A site migrated from old-domain.com/page to new-domain.com/page using a 301. Later, the new domain restructured its URL format, redirecting new-domain.com/page to new-domain.com/section/page using a 302 (because the developer considered it temporary during testing but never updated it to 301).
The resulting chain: old-domain.com/page (301) -> new-domain.com/page (302) -> new-domain.com/section/page (200).
Google may select new-domain.com/page as canonical because:
- The 301 from old-domain strongly signals that
new-domain.com/pageis the permanent destination. - The 302 from
new-domain.com/pagesignals that the redirect to/section/pageis temporary, reinforcingnew-domain.com/pageas the canonical.
The result: Google indexes new-domain.com/page as canonical, but that URL returns a 302 redirect. Users who click the search result are redirected to new-domain.com/section/page, but the ranking signals accumulate on the intermediate URL rather than the final destination. The final destination page ranks lower than expected because it is treated as an alternate rather than the canonical.
This scenario is diagnosed by checking the canonical URL reported in Search Console’s URL Inspection tool. If the canonical URL is an intermediate redirect rather than the final destination, the chain’s redirect types are confusing canonical selection.
The crawl efficiency impact of redirect chains depends on both the number of hops and the percentage of URLs affected. A site with 5% of URLs behind 3-hop chains experiences a different impact than a site with 40% of URLs behind 2-hop chains.
Impact model:
For a site with N total URLs, C daily crawl requests, and P percent of URLs behind chains of H hops:
- Additional crawl requests consumed: N P (H – 1)
- Effective crawl capacity for non-chained URLs: C – (N P (H – 1)) / recrawl_interval
At typical enterprise parameters (500,000 URLs, 20,000 daily crawl requests, 10% behind 3-hop chains, monthly recrawl interval):
- Additional requests per month: 500,000 0.10 2 = 100,000
- Daily overhead: approximately 3,333 requests
- Effective daily capacity reduction: 3,333 / 20,000 = 16.7%
This 16.7% reduction means new content, updated pages, and important URLs receive fewer crawl resources. The impact is non-linear because redirect chain processing competes with priority crawling during peak crawl sessions. Googlebot does not reserve capacity for non-redirect crawling; it processes redirects alongside normal requests, creating backpressure on the entire crawl queue.
Audit and remediation methodology for identifying and flattening redirect chains
Audit methodology:
- Crawl from the original URL set. Using Screaming Frog or Sitebulb, crawl the site starting from the complete list of known URLs (from sitemaps, server logs, and backlink databases). Configure the crawler to follow redirects and record the full chain for each URL.
- Identify all chains of 2+ hops. Filter the crawl results for URLs that required 2 or more redirects to reach the final destination. Export the chain details: source URL, each intermediate URL and its status code, and the final destination URL.
- Classify chains by type. Separate chains into: pure 301 chains (all hops are 301), pure 302 chains, and mixed chains. Mixed chains require the highest remediation priority due to canonical ambiguity risk.
- Prioritize by equity importance. Cross-reference chained URLs with backlink data. Chains on URLs with external backlinks should be remediated first because they carry the most equity at risk. Chains on URLs with zero backlinks have lower priority (they waste crawl budget but risk no equity).
Remediation protocol:
- Flatten to single-hop 301s. For every chain, replace the multi-hop path with a single 301 redirect from the original source directly to the final destination. This requires updating redirect rules at the server, CDN, or application level.
- Update internal links. After flattening redirects, update all internal links to point directly to the final destination URLs. Internal links that still reference old URLs force Googlebot to follow the redirect on every crawl, negating the benefit of flattening.
- Update canonical tags and sitemaps. Ensure canonical tags on all pages reference the final destination URL. Update sitemaps to include only final destination URLs, not redirect sources.
- Monitor with server logs. After remediation, monitor Googlebot’s crawl behavior for 4-6 weeks. Verify that the old chain URLs are being fetched less frequently and that the final destination URLs are receiving direct crawl requests. The 302 vs. 301 migration distinction determines when chain flattening requires changing redirect types versus just reducing hops.
Does Google pass full link equity through a redirect chain regardless of the number of hops?
Google follows redirect chains up to a limit (typically 10 hops), and while Google has stated that redirects pass PageRank, each additional hop introduces processing overhead and increases the chance of encountering a broken intermediate URL. Longer chains also delay the canonical resolution process because Google must crawl and evaluate each hop before reaching the final destination. Flattening chains to a single redirect eliminates this latency and ensures clean equity transfer.
Does a redirect chain that includes a 302 in the middle pass less equity than an all-301 chain?
Google has confirmed that 301 and 302 redirects pass equivalent PageRank. However, a 302 in the middle of a chain creates canonical selection ambiguity. Google may attempt to keep the 302 source URL in the index because the temporary signal suggests the redirect is not permanent. This delays the canonical consolidation onto the final destination. An all-301 chain sends a consistent permanent signal that accelerates canonical transfer, even though the equity amount is technically equivalent.
Does Google eventually flatten a redirect chain on its own, or must the site owner implement the fix?
Google does not automatically flatten redirect chains at the server level. Its systems follow the chain on each crawl pass, consuming a crawl request per hop every time. Google may eventually learn the final destination and adjust internal references in its index, but this optimization is not guaranteed and operates on a slow timeline. Site owners must implement server-side chain flattening to eliminate the ongoing crawl waste and ensure consistent equity transfer.
Sources
- Search Engine Land. “Too Many Redirects: How to Fix Loop Errors and Protect SEO.” https://searchengineland.com/guide/too-many-redirects
- Builtvisible. “Preserving Link Equity and Managing Crawl Efficiency for Better SEO.” https://builtvisible.com/link-equity-and-crawl-efficiency-maintenance/
- Search Engine Roundtable. “Google Puts Redirected URLs into a Cluster for Canonicalization Processing.” https://www.seroundtable.com/google-redirects-cluster-30425.html
- SEO.ai. “301 vs 302 vs 307: Which Redirect is Best for SEO?” https://seo.ai/blog/301-vs-302-vs-307
- Rankability. “Are Redirect Chains a Google Ranking Factor?” https://www.rankability.com/ranking-factors/google/redirect-chains/
