How to Fix Redirect Chains and Loops

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.

What Redirect Chains and Loops Are

A redirect chain is two or more consecutive redirects before reaching the final destination URL:

http://example.com/old-page/
  → 301 https://example.com/old-page/
    → 301 https://www.example.com/old-page/
      → 301 https://www.example.com/new-page/

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.

A redirect loop is a chain that never terminates:

https://example.com/page-a/
  → 301 https://example.com/page-b/
    → 301 https://example.com/page-a/

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.

The Crawl Budget and Link Equity Costs

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.

301 vs. 302: Why It Matters for Chains

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:

https://example.com/page-a/ → 302 https://example.com/page-b/ → 301 https://example.com/page-c/

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 HTTP→HTTPS→WWW Collapse Problem

The single most common redirect chain on the web is the four-variant problem. Most sites exist in four forms:

1. http://example.com
2. http://www.example.com
3. https://example.com
4. 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:

http://www.example.com
  → 301 https://www.example.com    (HTTP→HTTPS)
    → 301 https://example.com      (www→non-www)

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 Apache with .htaccess:

RewriteEngine On
 
# HTTP → HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
 
# www → non-www (HTTPS only, after the above rule)
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

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

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 slash
rewrite ^([^.]*[^/])$ $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.

Finding Redirect Chains

A redirect trace on an individual URL:

# Follow the full redirect chain with curl
curl -sIL --max-redirs 10 http://example.com/old-page/ \
  | grep -E "^(HTTP|Location)"
 
# Output:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/old-page/
HTTP/2 301
Location: https://www.example.com/old-page/
HTTP/2 301
Location: 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:

/old-slug/ → /new-slug/
/very-old-slug/ → /new-slug/   # NOT /very-old-slug/ → /old-slug/ → /new-slug/

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/.

What to Skip

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.

The Opinionated Take

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.

Related reading

• Robots.txt Mistakes That Are Tanking Rankings
• How to Fix Time to First Byte
• The Most Common Audit Failures