What a Redirect Chain Is (and Why It Forms)
A redirect chain occurs when a URL redirects to an intermediate URL, which then redirects again before reaching the final destination. Instead of a direct A → B redirect, the browser or crawler must follow multiple hops:
REDIRECT CHAIN — 3 hops:
https://example.com/old-page
↓ 301
https://example.com/interim-page
↓ 301
https://www.example.com/interim-page
↓ 301
https://www.example.com/new-page ← Final destination
Each arrow represents a separate HTTP request-response cycle. A user clicking a link to /old-page triggers four requests before receiving any content — and every hop adds latency.
Redirect chains almost never result from a deliberate decision. They accumulate over time through a predictable sequence of events:
- A page is moved and a redirect is created from the old URL to the new one.
- Later, the site migrates from HTTP to HTTPS — adding a redirect from the HTTP version to the HTTPS version across all URLs.
- Later still, the site standardises on
www— adding a redirect from the non-www version. - The page is reorganised again — another redirect is added pointing to the latest URL.
Each of these changes was individually sensible. Together they created a four-hop chain that nobody intentionally built and that no single team member has full visibility over.
How Redirect Chains Hurt SEO and Performance
PageRank and link equity dilution
Google has confirmed that PageRank passes through 301 redirects, but the signal weakens with each hop. A link pointing to /old-page that chains through three intermediate redirects delivers less equity to the final destination than a direct redirect would. The exact amount lost per hop is not publicly disclosed, but the principle is well-established: every unnecessary redirect is unnecessary dilution.
Crawl budget consumption
Googlebot allocates a crawl budget to each site based on its crawl health and server response times. When Googlebot follows a redirect chain, it consumes crawl budget on each intermediate URL — including URLs that carry no indexable content. For large sites with thousands of redirect chains, this meaningfully reduces the number of real pages Googlebot crawls per day.
Page load time and user experience
Each redirect hop adds a full round-trip HTTP request — typically 100–300ms per hop depending on server location and network conditions. A three-hop chain adds 300–900ms to the time before the browser receives the first byte of the actual page. For mobile users and users in high-latency regions, this is directly measurable in Core Web Vitals metrics.
HSTS and mixed content complications
When redirect chains cross protocol boundaries (HTTP → HTTPS) or domain boundaries, they can interact badly with HSTS preloading and mixed content rules. A chain that starts on HTTP and switches to HTTPS mid-chain may prevent browsers from applying HSTS preload rules correctly.
⚠️ Warning: Redirect chains built with 302 (temporary) redirects are significantly worse for SEO than 301 chains. Google does not reliably pass PageRank through 302 redirects, and Googlebot may continue crawling the original URL rather than updating its index to the destination. Audit for 302s in your redirect chains specifically.
Redirect Chains vs Redirect Loops — The Difference
These are related but distinct problems with different symptoms and fixes.
A redirect chain has a final destination that eventually responds with a 200 OK. The problem is the number of hops to get there — too many intermediate steps, each adding latency and diluting signal.
A redirect loop has no final destination. URL A redirects to URL B, which redirects back to URL A (or through a longer cycle back to the start). The browser aborts after hitting the loop limit and displays an error:
REDIRECT LOOP — infinite cycle:
https://example.com/page-a
↓ 301
https://example.com/page-b
↓ 301
https://example.com/page-a ← Back to start — browser gives up
Chrome displays ERR_TOO_MANY_REDIRECTS. Firefox shows The page isn't redirecting properly. Both are fatal — the page is completely inaccessible to users and crawlers alike.
Redirect loops most commonly occur when:
- A CMS plugin or rule redirects all non-HTTPS requests to HTTPS, while the server is also configured to handle HTTPS — creating a conflict
- A www → non-www (or non-www → www) rule conflicts with a CDN or proxy layer rule pointing the opposite direction
- A page-level redirect points back to a URL that is itself redirected to the original page
How to Find Redirect Chains on Your Site
Method 1: Manual check with curl
# Follow all redirects and show each hop with status code and Location header
curl -IL --max-redirs 10 https://example.com/old-page
# Output shows each hop:
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/interim-page
#
# HTTP/1.1 301 Moved Permanently
# Location: https://www.example.com/interim-page
#
# HTTP/1.1 200 OK
# Count the number of hops (lines containing HTTP/)
curl -ILs --max-redirs 10 https://example.com/old-page | grep -c "^HTTP/"
The -I flag fetches headers only (no body), -L follows redirects, and -s suppresses the progress meter. This is the fastest way to inspect a specific URL.
Method 2: Redirect Checker tool
Use our Redirect Checker to trace the full redirect path for any URL — it shows every hop, the HTTP status code at each step, and the final destination, without needing command-line access.
Method 3: HTTP Headers inspection
Use our HTTP Headers Check to inspect the raw response headers at any URL — useful for verifying that a redirect is actually a 301 vs 302, and checking for cache-control headers that affect how redirects are handled.
Method 4: Crawl-based audit (for full site coverage)
For finding all redirect chains across a large site, a dedicated crawl tool is necessary. Screaming Frog, Sitebulb, and Ahrefs Site Audit all report on redirect chains. The workflow:
- Crawl your entire site including redirect chains
- Filter the crawl report for URLs with 3xx status codes
- Export the redirect chain report — this shows every URL that is part of a chain and the full hop sequence
- Prioritise chains that originate from URLs with external backlinks (highest equity loss) and URLs listed in your XML sitemap (crawl waste)
💡 Tip: Cross-reference your redirect chain report with your XML sitemap. Any URL in your sitemap that itself redirects is a problem — sitemaps should only list canonical, indexable 200-response URLs. A redirecting sitemap URL tells Google your sitemap is out of date.
How to Fix Redirect Chains: The Right Way
The correct fix for a redirect chain is always the same: update every redirect in the chain to point directly to the final destination.
BEFORE (3-hop chain):
/old-page → 301 → /interim-page → 301 → /www-interim-page → 301 → /new-page
AFTER (direct redirect):
/old-page → 301 → /new-page
/interim-page → 301 → /new-page
/www-interim-page → 301 → /new-page
Every URL that previously pointed anywhere in the chain now points directly to the final destination. The final destination itself returns 200 OK. No intermediate hops remain.
Post-fix verification checklist:
- Run
curl -ILon every URL that was part of the chain — confirm each resolves to the final destination in exactly one hop - Confirm the final destination returns HTTP 200
- Check that the redirect type is 301 (permanent) for all permanent moves
- Verify no URLs in your XML sitemap redirect — update the sitemap to list only the final destination URLs
- Update any internal links on your site that point to old URLs — internal links should always point directly to the canonical destination
- Check that any high-value external backlinks pointing to old URLs now resolve to the final destination in one hop
- Re-crawl the affected URL set after 48 hours to confirm no new chains have formed
Fixing redirect loops
A redirect loop requires identifying the conflicting rules, not just updating a destination. Common approaches:
- Check your web server configuration (
.htaccess, Nginx config) for conflicting redirect rules - Check your CDN or proxy layer (Cloudflare, Fastly, CloudFront) for rules that conflict with server-level redirects
- Check CMS plugins or middleware that automatically add redirects (HTTPS enforcement plugins, www canonicalisation plugins)
- Disable one rule at a time and test until the loop breaks — then rebuild the correct rule set without the conflict
Redirect Best Practices for Technical SEO
Use the correct redirect code
| Code | Name | SEO Treatment | When to Use |
|---|---|---|---|
| 301 | Moved Permanently | Passes PageRank; Googlebot updates index to destination | Permanent URL changes, site migrations, domain moves |
| 302 | Found (Temporary) | Does not reliably pass PageRank; Googlebot may continue crawling origin | Genuinely temporary redirects — A/B tests, maintenance pages |
| 307 | Temporary Redirect | Same as 302 but HTTP method preserved | Temporary redirects where POST method must be preserved |
| 308 | Permanent Redirect | Same as 301 but HTTP method preserved | Permanent redirects where POST method must be preserved |
For the vast majority of SEO use cases, 301 is the correct choice for permanent redirects. Use 302 only when you genuinely intend to restore the original URL — if the redirect will be in place for more than a few weeks, use 301.
Keep redirect chains to a maximum of one hop
The goal is always source URL → final destination in a single redirect. Any chain longer than one hop should be collapsed.
Never redirect to a page that itself redirects
Every redirect destination should resolve with HTTP 200. If you redirect /old → /new and /new later gets moved to /newest, update the redirect for /old to point directly to /newest rather than letting the chain grow.
Update internal links immediately after adding redirects
Redirects are a safety net for external links you can't control. Internal links — which you fully control — should always point directly to the current canonical URL without relying on any redirect. An internal link that goes through a redirect is a crawl budget waste that you can eliminate with a simple link update.
Common Scenarios That Create Redirect Chains
HTTP to HTTPS migration layered on existing redirects
When a site migrates from HTTP to HTTPS, a redirect is added from every HTTP URL to its HTTPS equivalent. If those HTTP URLs already had redirects pointing elsewhere, a chain is created. The fix: during an HTTPS migration, audit all existing redirects and update them to point directly to the HTTPS version of the final destination.
www to non-www (or vice versa) canonicalisation
Adding a www canonicalisation rule on top of existing redirects creates chains for every URL that was already redirecting. This is one of the most common chain patterns. Fix by combining the canonicalisation into the existing redirect rules wherever possible.
CMS URL structure changes
WordPress, Drupal, and similar CMS platforms create redirects automatically when a page's URL slug changes. Over multiple slug changes, chains accumulate. The CMS redirect manager typically shows only the most recent redirect — the full chain is only visible by following each hop manually or with a crawl tool.
Domain consolidations and acquisitions
When one domain is redirected to another (brand rename, acquisition, consolidation), all the redirects that existed on the source domain are effectively prepended to any existing redirects on the destination domain. A URL that redirected twice on the old domain and once on the new domain is now a three-hop chain.
Frequently Asked Questions
Q: How many redirects is too many before it hurts SEO?
Google's John Mueller has indicated that Google can follow chains of up to 5 redirects, but the recommendation is to keep chains to a maximum of 1 hop. Two hops is acceptable if unavoidable. Three or more hops is a technical SEO problem that should be fixed. The performance impact is also cumulative — every hop adds latency for real users regardless of how Google handles it.
Q: Does a 301 redirect pass 100% of PageRank?
Google has stated that 301 redirects pass "essentially the same" PageRank as a direct link, but the practical evidence suggests some small dilution occurs — and that dilution compounds across multiple hops in a chain. The safest assumption is that unnecessary redirect hops cost you something, even if the exact figure is small.
Q: My site forces www and HTTPS — does that create a redirect chain for all URLs?
It can, depending on implementation. The correct approach is to handle both transformations in a single redirect rule: http://example.com/page → https://www.example.com/page in one hop. If your server handles them in two separate rules (HTTP→HTTPS then non-www→www), that's a two-hop chain on every URL. Combine them into a single rule.
Q: Should I put redirecting URLs in my XML sitemap?
No. Your XML sitemap should only contain canonical URLs that return HTTP 200. A redirecting URL in a sitemap signals to Google that your sitemap is out of date and adds unnecessary crawl budget consumption. After fixing redirect chains, audit your sitemap and update it to reference only final destination URLs.
Q: How do I fix a redirect loop caused by a Cloudflare HTTPS rule conflicting with my server?
This is a common issue. Cloudflare's "Always Use HTTPS" setting redirects HTTP → HTTPS before the request reaches your server. If your server also redirects HTTP → HTTPS (e.g., via .htaccess), you get a loop. The fix is to disable the server-level HTTP→HTTPS redirect and rely on Cloudflare's rule exclusively — or vice versa. Never run the same redirect at both the CDN and server level.
Q: After fixing redirect chains, how long does it take Google to update its index?
Googlebot will re-crawl fixed URLs over time as part of normal crawling. You can accelerate this by submitting affected URLs in Google Search Console's URL Inspection tool. For high-priority pages, requesting a re-crawl can prompt Googlebot to update the index within days rather than weeks.
Next Steps
Audit your most important URLs first — start with your XML sitemap URLs and any pages with significant external backlinks. Use our Redirect Checker to trace the full redirect path for each one and identify any chains immediately.
For a broader view of your site's HTTP response health, run an HTTP Headers Check across key URLs — this surfaces not just redirect behaviour but also cache-control headers, canonical headers, and other signals that affect how crawlers and browsers handle your pages.
Browse all webmaster guides on DNSnexus for related technical SEO topics.