How many redirects does Google actually follow before giving up?

Why Does Google Limit Redirect Processing to Five Hops?

Redirects consume crawl budget. Each additional hop represents an HTTP request, a response download, a status check. Googlebot cannot indefinitely follow redirect chains without risking getting trapped in infinite loops or wasting resources on misconfigured sites.

The limit of five redirects at once is a compromise. It allows for the management of standard migrations (HTTP → HTTPS, www → non-www, old structure → new) while avoiding abuse. Beyond that, the bot segments the processing: it notes the last URL reached, waiting for the next crawl to continue.

What Happens After the Fifth Redirect?

Processing becomes asynchronous and fragmented. Googlebot doesn't refuse to index the final page—it simply slows down the process. During the first crawl, it reaches the fifth URL in the chain. During a subsequent crawl (possibly days or weeks later, depending on the site's priority), it resumes from where it left off.

This delay has two direct consequences. First, the freshness of content: your new page will take longer to appear in the index. Second, the loss of PageRank: each 301 or 302 redirect slightly dilutes the equity passed, and a chain of seven redirects amplifies this dilution.

Does This Rule Apply to All Types of Redirects?

Yes, all HTTP redirects count towards this limit: 301 (permanent), 302 (temporary), 307, 308. JavaScript or meta refresh redirects are treated differently—they don't count towards these five hops, but they still slow down the crawl as they require JavaScript rendering.

Server-side redirects (from Apache, Nginx, via .htaccess or configuration files) are the most reliable. CDNs like Cloudflare sometimes add invisible intermediate redirects—monitor your chains with tools like Screaming Frog or command-line curl.

• Five redirects maximum are processed in a single crawl pass by Googlebot
• Beyond that, processing becomes fragmented and asynchronous, slowing down indexing
• Each additional hop dilutes the PageRank passed to the final page
• JavaScript/meta refresh redirects do not count towards this limit, but they further slow down the crawl
• CDNs and proxies can add invisible intermediate redirects—regularly audit your chains

Is This Statement Consistent with Field Observations?

Yes, and it’s even a more generous figure than what was historically observed. For years, the unofficial recommendation hovered around a maximum of three redirects. That Mueller confirms five redirects in a single pass is great news for complex migrations—multiple domains, deep restructurings, brand consolidations.

However, "slowly checks later redirects" remains intentionally vague. How much time between each resume? It depends on the crawl budget allocated to the site, the historical crawl frequency, and the domain authority. A site with a low crawl budget may wait weeks before Googlebot resumes the chain.

In What Cases Does This Limit Present a Real Problem?

Poorly planned migrations are the typical case. Imagine a business migrating HTTP → HTTPS, then changing domain, then reorganizing its structure, then switching to a new CMS—all while keeping each layer of redirects. You end up with seven or eight hops before reaching the final page.

Multilingual or multi-regional sites are also exposed. Geolocated redirect (e.g., .com → .fr), then www → non-www redirect, then language redirect (e.g., /fr/ → /fr-FR/), then category redirect after redesign… Each business logic adds another layer.

What Nuances Should Be Applied to This Rule?

First, this limit applies to crawling, not rendering. If a page redirects via JavaScript after an initial HTML load, Googlebot must first render the page, then follow the redirect—an even slower process. Server redirects are always preferable.

Next, PageRank dilution remains a vague topic. Google has claimed for years that 301 redirects pass 100% of equity, but field tests show a slight loss in long chains. [To be verified]—no official precise data on the exact percentage after five hops or more.

How to Detect and Measure Redirect Chains on Your Site?

Run a complete crawl with Screaming Frog (Spider mode, limited to your domain). Enable the "Always Follow Redirects" option and check the "Redirect Chains" tab. You will see each chain, the number of hops, and the HTTP status codes at each step.

For on-the-spot checks, use curl in the command line with the -L (follow redirects) and -v (verbose) options. You will see each step, the HTTP headers, and response times. Example: curl -L -v https://yoursite.com/old-url. If you count more than five hops, you have a problem.

What to Do if You Discover Chains That Are Too Long?

First priority: shorten critical chains. Identify pages receiving external backlinks or significant organic traffic. For these URLs, redirect directly from the old to the new, without going through intermediate steps. Modify your server configuration (.htaccess, nginx.conf, Cloudflare rules) to point A → D instead of A → B → C → D.

Second step: clean up obsolete redirects. Many sites retain migration redirects that are five or ten years old. If the source URL is no longer receiving any traffic or backlinks, you can delete it (return a 410 Gone or a 404 if preferred). Focus your redirects on what still has value.

How to Avoid Recreating This Problem in Future Migrations?

Plan your redirects in a single layer from the beginning. If you are migrating HTTP → HTTPS and www → non-www simultaneously, set up a direct redirect A → D, not A → B → C → D. Modern servers (Apache 2.4+, Nginx) handle very complex conditional rules well.

Document each wave of redirects in a mapping table (source URL, target URL, HTTP code, implementation date, reason). During the next migration, you can consolidate by directly updating old sources. Automate the verification with a script that tests your critical URLs weekly.

• Crawl your site with Screaming Frog to detect all existing redirect chains
• Prioritize critical URLs (strong backlinks, organic traffic) and shorten their chains to a maximum of 1-2 hops
• Remove or return 410/404 on obsolete redirects that no longer receive any signals
• Configure future redirects in a single step (A → D) rather than in cascading (A → B → C → D)
• Document each mapping in a centralized table with dates and reasons
• Automate a weekly monitoring of critical URLs to quickly detect any new chains