How Many Redirects Is Too Many?

Every redirect adds a network round trip between the browser and the server. One redirect is fine. Two is usually acceptable. But at some point, the chain becomes too long and causes real problems for users, search engines, and site performance. The question is where that line falls, and the answer depends on who is following the redirect.

For background on what redirect chains are and how they form, see Redirect Chains Explained.

Google's Limit: 10 Hops

Google's crawler, Googlebot, follows up to 10 redirect hops before giving up. If the final destination is more than 10 redirects away from the original URL, Googlebot stops following the chain and treats the URL as an error. The page does not get indexed, and any link equity flowing through the chain is lost.

Google has documented this limit in their Search Central documentation. John Mueller has also mentioned it in public Q&A sessions, noting that while Googlebot can follow up to 10 hops, "you really should not need more than one or two."

The 10-hop limit is a technical ceiling, not a recommendation. Google will follow 10 hops, but that does not mean 10 hops is acceptable. Each hop consumes crawl budget and introduces delay. On large sites with millions of pages, redirect chains of even three or four hops can meaningfully impact how efficiently Google crawls your content.

Browser Limits

Browsers impose their own limits on redirect chains to prevent infinite loops:

• Chrome: 20 redirects before showing ERR_TOO_MANY_REDIRECTS
• Firefox: 20 redirects before showing a "The page isn't redirecting properly" error
• Safari: Varies, typically 16-20 redirects before showing an error
• Edge: 20 redirects (Chromium-based, same as Chrome)

These limits exist to catch redirect loops, not to accommodate long chains. If your users are hitting browser redirect limits, something is fundamentally wrong with your redirect configuration.

The ERR_TOO_MANY_REDIRECTS error is one of the most common redirect problems users encounter. For troubleshooting, see How to Fix ERR_TOO_MANY_REDIRECTS.

The Performance Cost Per Hop

Each redirect hop requires a complete HTTP request-response cycle. The time this takes depends on the network latency between the user and the server, plus the server's processing time for the redirect rule.

On a typical broadband connection with 50ms latency to the server:

• 1 redirect: ~100ms added (request + response)
• 2 redirects: ~200ms added
• 3 redirects: ~300ms added
• 5 redirects: ~500ms added (half a second before content even starts loading)

On a mobile connection with 150ms latency:

• 1 redirect: ~300ms added
• 2 redirects: ~600ms added
• 3 redirects: ~900ms added
• 5 redirects: ~1,500ms added (a second and a half of waiting)

These numbers assume the redirects are to the same server. If redirects cross domains (for example, from olddomain.com to newdomain.com), each cross-domain hop adds DNS resolution time, TCP connection setup time, and potentially TLS handshake time. A single cross-domain redirect can add 300-500ms even on a fast connection.

The cumulative effect is significant. Google has found that as page load time increases from 1 second to 3 seconds, the probability of the user bouncing increases by 32%. From 1 to 5 seconds, it increases by 90%. Redirect chains that add a full second or more of latency before the page even starts loading have a measurable impact on user experience and engagement.

How Redirect Chains Form

Nobody sets out to create a five-hop redirect chain. Chains grow over time through a series of individually reasonable decisions:

Migration layering. In 2020, you migrated from oldsite.com to newsite.com and set up 301 redirects. In 2022, you restructured URLs from /blog/post-title to /articles/post-title and added more redirects. In 2024, you moved from newsite.com to brand.com. Now a visitor following a link from 2019 goes through three redirect hops.

HTTP to HTTPS plus www normalization. A link to http://www.example.com/page might first redirect to https://www.example.com/page (HTTP to HTTPS), then to https://example.com/page (www to non-www), then to https://example.com/page/ (trailing slash normalization). That is three redirects before the page loads.

Third-party redirect services. Link shorteners, tracking links, and affiliate redirectors add hops. A link from a social media post might go through t.co (Twitter/X's shortener), then a UTM tracking redirect, then your server's HTTP-to-HTTPS redirect, then your application's routing redirect.

CMS and plugin conflicts. WordPress sites with multiple redirect plugins, SEO plugins, and caching plugins can end up with redirect rules defined in three different places, each adding a hop that the others do not know about.

What the Right Number Is

One hop is ideal. A single redirect from the old URL to the current, final URL. No intermediate stops. This is what you should aim for in every redirect you control.

Two hops are acceptable as a temporary state. During a migration, you might have a legitimate two-hop chain while you update internal links and wait for external links to update. But two hops should not be permanent. Flatten to one as soon as practical.

Three or more hops indicate a problem. At three hops, you are adding noticeable latency, wasting crawl budget, and creating maintenance complexity. Audit and flatten.

Five or more hops are unacceptable. Users on slow connections will notice the delay. Search engine crawling is meaningfully impacted. The chain is fragile because any single hop failing breaks the entire path. This requires immediate attention.

Crawl Budget Impact

Crawl budget is the number of pages Google will crawl on your site within a given time period. Every redirect hop counts as a separate crawl request. If Googlebot follows a three-hop chain, it uses three requests from your crawl budget to reach a single page.

For small sites (under 10,000 pages), crawl budget is rarely a concern. Google can crawl the entire site quickly regardless of redirect chains. But for large sites with hundreds of thousands or millions of pages, redirect chains can consume a meaningful portion of the crawl budget.

Consider a large e-commerce site with 100,000 product pages. If 20,000 of those have been redirected through migrations, and the average chain length is 2.5 hops, that is 50,000 crawl requests spent just following redirects. That is crawl budget that could have been used to discover new content or re-crawl updated pages.

How to Flatten Redirect Chains

The fix for long chains is straightforward: update every redirect to point directly to the current final URL, eliminating intermediate hops.

Step 1: Identify chains. Use a crawler like Screaming Frog, a redirect checker like Redirect Tracer, or server log analysis to find URLs with more than one redirect hop.

Step 2: Map old URLs to final destinations. For each chain, identify the original URL and the current final destination. Create a mapping table.

Step 3: Update redirect rules. In your server config (.htaccess, nginx.conf) or CDN rules, replace the chain with a single redirect from the original URL to the final destination.

Step 4: Test. Verify that each old URL now reaches the final destination in one hop. Check that no new loops have been introduced.

Step 5: Update internal links. Any internal links that point to redirected URLs should be updated to point to the final destination directly. This eliminates the need for the redirect entirely on internal navigation.

For detailed detection methods, see How to Find Redirect Chains.

The Special Case of HTTP-to-HTTPS Chains

The most common multi-hop chain is the combination of protocol and hostname normalization:

http://www.example.com/page
  -> https://www.example.com/page
    -> https://example.com/page

This two-hop chain can be collapsed to a single hop by configuring your server to redirect directly from any non-canonical URL to the final canonical form:

http://www.example.com/page -> https://example.com/page (one hop)
http://example.com/page -> https://example.com/page (one hop)
https://www.example.com/page -> https://example.com/page (one hop)

In Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

In Nginx:

server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

This handles both the HTTP-to-HTTPS and www-to-non-www redirects in a single hop. For the full HTTP-to-HTTPS setup, see the HTTP to HTTPS Redirect Guide.

References

1. Google, "Redirects and Google Search," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/301-redirects
2. Google, "Crawl budget management," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget
3. Google, "Find and fix: Why speed matters," 2019. https://web.dev/why-speed-matters/
4. IETF, "RFC 9110 - HTTP Semantics, Section 15.4: Redirection 3xx," June 2022. https://httpwg.org/specs/rfc9110.html#status.3xx