How many redirects does Google really follow before giving up on crawling?

What is the technical limit for redirect tracking by Googlebot?

Googlebot can handle up to five successive redirects during a single crawl pass. Beyond this threshold, the bot stops tracking and must schedule a new attempt later. This limit is not arbitrary: it protects Google's infrastructure against infinite redirect loops and optimizes crawl budget distribution.

Mueller's statement is factual and unequivocal. If your Page A redirects to B, which redirects to C, then D, E, and F, Googlebot will reach F on the first crawl. But if F redirects again to G, the process stops and Google must come back later. In the meantime, your content is not indexed.

Why do multiple redirect chains pose a problem?

Each redirect imposes an additional HTTP round trip. On mobile, where network latency is often high and bandwidth is limited, the impact measures in real seconds. A chain of three redirects can easily add 1 to 2 seconds to the initial loading time, degrading user experience and Core Web Vitals.

The crawl budget is also consumed unnecessarily. If Googlebot has to follow four redirects to reach your final content, it spends four requests instead of just one. On a site with thousands of pages and a limited crawl budget, this inefficiency can delay the indexing of strategic pages.

In what contexts do these redirect chains appear?

Redirect chains often accumulate due to technical sedimentation. An HTTP to HTTPS migration adds a 301 redirect, followed by a domain migration (old-domain.com → new-domain.com), then URL rewriting (new-domain.com/page.html → new-domain.com/page/): three successive redirects appear without any developer having planned this cascade.

Temporary redirects (302) combined with permanent redirects (301) also create ambiguous situations. Googlebot interprets these statuses differently, and a mixed chain can lead to unpredictable PageRank transfer behaviors.

• Crawl limit: Googlebot follows a maximum of 5 consecutive redirects before temporarily giving up
• Performance impact: Each redirect adds latency and slows down loading time, especially on mobile
• Crawl budget consumption: Multiple chains waste crawl resources on intermediate requests
• Frequent origin: Successive migrations, URL structure changes, poorly planned HTTPS redirects
• Indexing risk: Beyond 5 hops, the final content is not crawled during the initial pass

Is this statement consistent with field observations?

The limit of five redirects is empirically confirmed by SEO practitioners analyzing server logs for years. Laboratory tests consistently show that Googlebot stops at the fifth hop. This statement from Mueller simply formalizes a technical reality that has been observed.

The important nuance: following up to five redirects does not mean Google fully transfers PageRank across the entire chain. Field data suggest a gradual dilution of the signal with each hop, although Google has never precisely quantified this loss. [To be verified] The exact proportion of PageRank retained after three or four redirects remains opaque.

What is the acceptable tolerance in production?

Technically, Google accepts five redirects. Pragmatically, no professional site should exceed two hops. Google’s tolerance is not a usage recommendation. Each additional redirect degrades performance, consumes crawl budget, and introduces potential points of failure.

E-commerce sites managing product variants (colors, sizes) sometimes accumulate cascading redirects: canonical URL → default variant → local redirect based on geolocation. These architectures must be overhauled at the source, not tolerated because Google can technically follow them.

In what cases does this rule not fully apply?

Redirects served via client-side JavaScript (window.location, non-HTTP meta refreshes) do not necessarily consume one of the five HTTP redirect slots. Googlebot treats them differently during the rendering phase. This does not mean they are without impact: they simply delay the problem to another stage of the crawl.

User-Agent conditional redirects can create situations where Googlebot sees a chain different from what mobile users see. Some sites redirect bots differently from actual visitors to "optimize" crawling. This is a risky practice that can be interpreted as cloaking if the final destination significantly differs.

How to audit existing redirect chains?

The Screaming Frog tool allows you to crawl your site in "follow redirects" mode and visualize complete chains. Set it up to display all redirect steps, not just the source and final destination. Export the list of URLs with more than one redirect and prioritize them (traffic, incoming backlinks).

The server logs reveal the chains actually followed by Googlebot, not those that your theoretical crawling tools detect. Analyze sequences of Googlebot requests on the same URL with closely spaced timestamps: they often indicate a redirect follow. Look for patterns where Googlebot abandons after multiple hops without reaching the final content.

What is the procedure for correcting multiple chains?

The optimal solution is to directly redirect all intermediate URLs to the final destination. If A redirects to B, which redirects to C, change A to redirect directly to C. Remove B from the chain. Apply this principle recursively to all detected chains.

Be cautious of conflicting rewrite rules in your .htaccess files, nginx.conf, or CDN configurations. An HTTPS redirect added at the server level may collide with a URL normalization redirect set in the CMS, inadvertently creating a chain. Consolidate all redirect rules into a single control point when possible.

How to prevent the emergence of new chains?

Establish a migration protocol that documents each added redirect. Before any domain migration, URL structure change, or HTTPS transition, audit existing redirects. If you add a layer of redirection, check that it does not stack on previously uncleaned redirects.

Integrate an automated test into your deployment pipeline that crawls a sample of critical URLs and alerts if a chain of more than two redirects appears. This check should block production deployment until corrected. Redirect chains are rarely intentional: they result from successive configurations that have never been consolidated.

• Crawl the entire site with Screaming Frog in follow redirects mode enabled
• Identify all URLs with more than one redirect and prioritize them by organic traffic
• Change redirects to point directly to the final destination, eliminating intermediate hops
• Analyze server logs to detect the actual chains followed by Googlebot (not just theoretical ones)
• Consolidate all dispersed redirect rules (.htaccess, nginx, CDN, CMS) into a unique control point
• Integrate an automated test for detecting multiple chains into the CI/CD pipeline