Sites that have been through migrations, rebrands, or CMS changes accumulate redirect chains gradually. HTTP to HTTPS adds one redirect. Non-www to www adds another. A URL slug rename adds a third. Each was added at a different time, nobody updated the original source links, and now every visitor — and every Googlebot crawl — follows a 3-hop chain to reach a page that should have loaded directly.
The page still loads. That's why chains go undetected for months or years. But underneath, latency is compounding, PageRank is leaking, and crawl budget is being spent on hops that should not exist.
Here's how to find every chain, understand what it's costing you, and fix it for good.
Key Takeaways
- Each redirect hop adds 100–300ms of latency before the page starts loading
- PageRank passes through 301 redirects but loses some in transit — chains compound the loss
- A 302 (temporary) redirect does not pass PageRank — using it by accident on a permanent move is a silent SEO mistake
- Google has a redirect hop limit — very long chains may not be fully followed
- Tracing a chain manually with curl misses timing data, server headers, and HTTP version — use a dedicated tracer
What Is a Redirect Chain?
A redirect chain is two or more consecutive redirects between the originally requested URL and the final destination. A single redirect is normal and expected — HTTP to HTTPS, non-www to www, old URL to new URL. A chain is what forms when redirects stack on top of each other over time without anyone updating the originals.
Example of a 3-hop chain that forms naturally over two years:
- Year 1: Site adds HTTPS.
http://example.com/page→https://example.com/page - Year 2: Site standardises on www.
https://example.com/page→https://www.example.com/page - Year 3: URL slug renamed.
https://www.example.com/page→https://www.example.com/new-page
Any link that still points to http://example.com/page — whether in a blog post, an external backlink, or your own sitemap — now sends every visitor and every crawler through all three hops before the page loads.
What Redirect Chains Cost You
Latency
Each redirect hop is a full HTTP round-trip: the client sends a request, the server responds with a 3xx status and a Location header, the client follows the new URL and starts again. On a server averaging 150ms TTFB per hop, a 3-hop chain adds 450ms before a single byte of the final page arrives.
At 150ms per hop: 1 redirect = 150ms added. 3 redirects = 450ms added. 5 redirects = 750ms added — before your page starts loading.
On mobile, where round-trip times are higher and LCP budgets are tighter, the compounding effect is worse. Redirect chains are one of the most common and most overlooked contributors to poor TTFB scores.
PageRank Leakage
Google has confirmed that 301 redirects pass PageRank, but the transfer is not lossless — some authority is lost in transit. A chain compounds the loss. A backlink pointing through a 3-hop chain delivers meaningfully less PageRank to the final destination than the same link pointing directly to that URL. The fix is always to update source links to bypass the chain entirely.
The 301 vs 302 Distinction
This is where silent mistakes happen at scale. A 301 (permanent redirect) tells Google: "this URL has moved permanently — transfer the PageRank to the destination." A 302 (temporary redirect) tells Google: "this URL is temporarily unavailable — keep the PageRank on the original."
Several popular frameworks and CDN configurations default to 302. A site that has migrated URLs and used 302s throughout never accumulates authority on the destination pages — the PageRank stays on URLs that no longer serve content.
| Status | Type | PageRank passed? | When to use |
|---|---|---|---|
| 301 | Permanent redirect | Yes (mostly) | URL has permanently moved |
| 302 | Temporary redirect | No | A/B tests, temporary maintenance pages |
| 307 | Temporary (method-preserving) | No | Same as 302 but preserves POST method |
| 308 | Permanent (method-preserving) | Yes | Like 301 but preserves POST method |
| Meta refresh | Client-side redirect | No | Avoid — not a server redirect |
How to Trace a Redirect Chain
Four methods, from least to most useful.
1. Browser address bar. You see the final URL but not the hops. The browser silently follows all redirects before rendering. Completely useless for diagnosing chains.
2. curl in terminal. curl -I -L https://example.com/page follows redirects and prints each response header block. Shows status codes and Location headers but not timing per hop, server identity, or HTTP version.
3. Browser DevTools → Network tab. Check "Preserve log", navigate to the URL, and each redirect appears as a separate row with individual timing. Useful for one-off debugging but impractical for checking many URLs systematically.
4. ByteWaveNetwork Redirect Tracer. Paste any URL and get every hop with status code, Location header, server, response time (ms), HTTP version, and total chain time. No terminal, no DevTools, no manual work.
Step-by-Step: Tracing With ByteWaveNetwork
1. Go to the Redirect Tracer and paste the starting URL — the original URL, not the final one you think it ends up at. The point is to see the full chain from where links actually point.
2. Read each hop row. Each row shows the URL requested, the HTTP status returned, the Location header (where the server redirects to next), the server header, the response time for that hop, and the HTTP version.
3. Check Total Time. This is the cumulative latency added before your page starts loading. A single hop under 100ms is fine. Three hops totalling 600ms is a real user-experience and Core Web Vitals problem.
4. Look for 302s that should be 301s. Any permanent URL move that's using a 302 is silently blocking PageRank transfer. Update those to 301 in your server config or CDN rules.
5. Look for HTTP in the middle of a chain. A chain that goes HTTPS → HTTP → HTTPS has a plaintext hop where a man-in-the-middle could intercept the request.
http:// in the middle of a chain that starts on https://, that is a security issue — a MITM attacker can intercept the plaintext hop. Fix by ensuring all intermediate redirects use HTTPS.
Fixing Redirect Chains — The Right Approach
Option 1: Update the Source Link (Best)
If you control the page containing the link, update it to point directly to the final URL. This fully eliminates the chain for that source — no server config change needed. For internal links, run the Link Checker and filter to the Redirect tab. Every row there is an internal link pointing to a redirect. Update those source links to skip the intermediate hops.
Option 2: Collapse the Chain at the Server
For inbound links you cannot update — external backlinks, old bookmarks, links on other sites — collapse the chain in your server config so the first hop goes directly to the final URL.
Example in Nginx:
# Instead of: /old-page → /middle → /new-page
# Do: /old-page → /new-page (single hop)
location /old-page {
return 301 /new-page;
}In most CDNs (Cloudflare, Vercel, Netlify), this is a redirect rule in the dashboard or config file. The principle is the same: any URL that currently chains through intermediaries should redirect directly to the canonical destination in a single hop.
Option 3: Fix the Sitemap While You're At It
Redirect chains and sitemap errors frequently surface together. If your sitemap still lists old URLs that redirect to new ones, you're sending Googlebot through the chain on every sitemap crawl. Update your sitemap to list final destination URLs directly. If you're doing this as part of a migration, see our guide to checking broken links before a migration — redirect chain cleanup is a key pre-migration step.
Common Redirect Chain Patterns and Their Causes
| Pattern | Root cause | Fix |
|---|---|---|
http → https → www → /page |
HTTP and non-www redirects stacked on a later URL move | Collapse to a single redirect from the oldest URL to the final one |
/old-slug → /middle → /new-slug |
Multiple URL renames over time, none removing the previous redirect | Update source links; collapse server-side to one hop |
/page → /page/ (or reverse) |
Trailing slash inconsistency — server redirects one form to the other | Pick one canonical form; ensure all internal links use it to avoid the redirect |
| CDN URL → Origin URL | CDN misconfiguration — request hits CDN, gets redirected to origin | Fix CDN routing so the CDN serves the response directly |
| 302 chain across a migration | Framework default or CMS misconfiguration using temporary redirects | Audit all redirects; change any permanent moves from 302 to 301 |
How Often Should You Audit Redirect Chains?
Chains accumulate when URLs change without source links being updated. The right trigger is any URL change — not a calendar interval.
After any URL restructure or migration: run the Redirect Tracer on your most-linked internal URLs and your sitemap URLs. This is the highest-risk moment for chains to form.
After a CMS or framework upgrade: some upgrades change how redirects are issued (301 vs 302, trailing slash handling). Verify nothing changed.
When investigating slow TTFB: if the Page Speed Inspector shows high TTFB on a URL you expect to be fast, trace its redirect chain. A hidden 3-hop chain is often the culprit.
When backlinks underperform: if a page with solid inbound links isn't accumulating authority as expected, trace the chain from those backlink URLs. A 302 in the chain is a common cause.
Trace Your Redirect Chains Now
Free, no signup. Paste any URL and see every redirect hop with status code, response time, Location header, and HTTP version — so you know exactly where latency and PageRank are leaking.
Try the Redirect Tracer Free →Related reading: Redirect Chains and SEO — Impact and How to Fix Them
Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.