Every hop in a redirect chain costs something. Crawl budget. Link equity. Milliseconds on every page load. And unlike most technical SEO issues, redirect chains compound silently: a site accumulates them over years of migrations, rebrands, and plugin installations until Googlebot is following four-hop chains to reach pages that should be one request away.
The frustrating part is that most redirect chains are created by well-intentioned changes that each looked fine individually. An HTTP→HTTPS redirect here. A non-www to www redirect there. A URL slug change that didn't update the redirect from the slug change before it. Stack these and you get chains that Google's crawlers will patiently follow—up to a point—and then give up on.
That's a 3-hop chain. Each hop adds latency. More importantly, each hop dilutes link equity—301 redirects are estimated to pass 99%+ of PageRank, but that's per hop. A 3-hop chain passes roughly 97% of the original equity. In isolation, negligible. Across thousands of inbound links pointing to an old domain after a migration, significant.
Browsers detect loops and stop after a fixed number of hops (typically 20). Googlebot does the same and logs the URL as an error. Any links pointing into the loop are permanently dead from an equity perspective.
Crawl budget—the number of URLs Googlebot will fetch from your site per day—is finite and influenced by site health signals. A site littered with redirect chains signals poor technical hygiene, which can reduce the crawl rate allocation over time.
More concretely: if Googlebot allocates time to follow a 4-hop chain to reach a page, that's time not spent crawling other pages. For large sites (10,000+ URLs), this matters materially. For small sites under 1,000 pages, crawl budget isn't usually the primary concern—but the equity dilution and latency costs still apply.
The latency cost is real and measurable. Each redirect requires a new HTTP request, which adds at least 100-200ms per hop on a typical connection. A 3-hop chain adds 300-600ms before the first byte of the final page arrives. This shows up directly in Time to First Byte (TTFB) and contributes to poor LCP scores.
Use Recon's Page Speed Grader to check if TTFB is elevated on pages that should be fast—redirect chains are a common culprit that gets misattributed to server performance.
A 301 (permanent) redirect signals to Google that the destination is the canonical URL and the original should be deprecated. Link equity transfers.
A 302 (temporary) redirect signals that the original URL is still canonical and the redirect is situational. Link equity may not transfer fully. Google may keep indexing the 302 source rather than the destination.
Redirect chains mixing 301s and 302s create ambiguity:
Google may treat page-a/ as the canonical because the first hop is a 302, even though the chain terminates at page-c/. The link equity consolidation doesn't happen correctly. Almost always, chains that include 302s are accidental—a developer set up a temporary redirect that never got changed to permanent.
Audit your redirect chains specifically for mixed 301/302 patterns. Any 302 in a chain that's been in place for more than a few weeks is probably a misconfiguration.
The single most common redirect chain on the web is the four-variant problem. Most sites exist in four forms:
http://example.com
http://www.example.com
https://example.com
https://www.example.com
The correct configuration: one canonical form (typically https://example.com or https://www.example.com), and every other variant redirects directly to that canonical in a single hop.
The wrong configuration—which is what most sites have—looks like:
That's a 2-hop chain for one of the four variants. Multiply by inbound links that point to the HTTP or www version (common for older links) and you have systematic equity dilution.
The correct Nginx server block collapses all variants in one rule:
server { listen 80; listen 443 ssl; server_name www.example.com; ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; return 301 https://example.com$request_uri;}server { listen 443 ssl; server_name example.com; # ... normal site config}
For Vercel or Netlify, handle this in the platform config rather than .htaccess. Vercel's automatic HTTPS and canonical redirect handling already collapses HTTP→HTTPS, but www/non-www still needs to be specified.
Trailing slash inconsistency generates redirect chains at scale. If your site serves /services/ and a link somewhere points to /services (no trailing slash), that's a redirect hop if your server normalizes URLs. Multiply by every page across thousands of internal links and you have a sitewide performance and equity issue.
Pick one convention—trailing slash or no trailing slash—and enforce it everywhere:
# Enforce trailing slashrewrite ^([^.]*[^/])$ $1/ permanent;# Enforce no trailing slash (only for non-file URLs)rewrite ^(/.+)/$ $1 permanent;
In Next.js, use trailingSlash: true or trailingSlash: false in next.config.ts and be consistent. Mixing conventions within a Next.js app causes redirect loops in certain routing configurations.
# Follow the full redirect chain with curlcurl -sIL --max-redirs 10 http://example.com/old-page/ \ | grep -E "^(HTTP|Location)"# Output:HTTP/1.1 301 Moved PermanentlyLocation: https://example.com/old-page/HTTP/2 301Location: https://www.example.com/old-page/HTTP/2 301Location: https://www.example.com/new-page/HTTP/2 200
Three hops. Should be one. The fix is to update the first redirect to point directly to the final destination.
For sitewide detection, Screaming Frog (free up to 500 URLs) crawls the full site and flags redirect chains. Filter for "Redirect Chains" in the Response Codes tab. Any URL requiring more than one hop to reach the final destination is a chain.
For redirects you've intentionally set up (slug changes, migrations), maintain a redirect map in a version-controlled file:
Every time you add a new redirect, scan the existing redirect map for chains. If /old-slug/ is already in the map pointing to /interim-slug/, and you're adding /interim-slug/ → /new-slug/, update the original entry to point directly to /new-slug/.
Skip using JavaScript redirects (window.location.href = '...' or meta refresh) for permanent redirects. Googlebot processes JavaScript, but there's a delay—pages may get indexed at the source URL before the redirect is followed. Server-side 301s are always correct for permanent changes.
Skip 302 redirects for anything permanent. If a URL has moved and isn't coming back, use 301. The only legitimate use case for 302 in production is genuinely temporary situations: maintenance pages, A/B test variants with an explicit end date, or session-specific behavior.
Skip fixing redirect chains in staging without verifying production. CDN layers (Cloudflare, Fastly) often have their own redirect rules that stack on top of server-level rules. A redirect that's a single hop in staging becomes a two-hop chain when Cloudflare's page rules add a redirect before the server sees the request.
Redirect chain audits are undervalued in client work because the impact isn't as visible as a rankings position moving. But on sites with aggressive historic link building or multiple past migrations, collapsing redirect chains is often the highest-ROI technical fix available—because every inbound link pointing to an old URL is currently delivering less equity than it should, and fixing that is instant, permanent, and requires no new content.
The audit one-liner for redirect chains: Every URL in your redirect chain beyond the first hop is a tax on every inbound link pointing to that URL—collapse all chains to single-hop 301s before spending another hour on content or link acquisition.
