Redirect Chain Checker

1. HTTP Redirect Status Codes (301 vs 302 vs 307 vs 308)

All four codes tell a client "the resource is somewhere else," but they differ on two independent axes: permanence (301/308 permanent, 302/307 temporary) and method preservation (307/308 guarantee the request method stays the same on the follow-up request; 301/302 historically don't, though most modern browsers preserve GET regardless). Per Google's own guidance, 301 and 308 redirects consolidate ranking signals from the old URL onto the new one; 302 and 307 are treated as temporary, so search engines are much more likely to keep the original URL indexed rather than replace it.

2. Network Latency Impact of Multi-Hop Chains

Each hop in a chain requires its own full request/response round-trip — and if the redirect target is on a different domain, potentially its own DNS lookup and fresh TLS handshake too. On a typical connection this can add roughly 100-300ms per additional hop before the browser even starts receiving the actual page, directly inflating Time to First Byte and, by extension, Largest Contentful Paint on the final rendered page.

3. Aligning Canonical Tags with Redirect Targets

A page's rel=canonical tag should point at the same URL a redirect chain ultimately resolves to — a canonical tag referencing a URL that itself redirects elsewhere sends search engines a contradictory signal about which URL is actually authoritative. Once you've traced a chain here, verify the final destination's canonical tag with the Canonical Tag Checker.

4. Edge-Executed Redirects via Nimbica Static Platform

Redirects configured through Nimbica's static edge platform execute directly at Cloudflare's edge, without invoking origin PHP at all — removing the origin round-trip that a server-side redirect (a WordPress plugin rule, an .htaccess directive) would otherwise add on every single request that hits it.

5. How to Use This Trace

1. Enter any URL you suspect might redirect — an old page, a shortened link, a URL from an old sitemap or backlink.
2. Review each hop's status code: watch specifically for 302s on what should be permanent moves, and for a chain longer than 1-2 hops.
3. If the trace ends in an error or an unexpected status (4xx/5xx) rather than a clean 200, that's a broken redirect target worth fixing directly, not just shortening.
4. For any chain of 2+ hops, update the original link/redirect rule to point straight at the final destination rather than leaving the intermediate hops in place.

6. Common Redirect Mistakes

• Chaining redirects instead of updating them. Each time a URL's destination changes, it's tempting to add a new redirect on top of the old one rather than updating the original rule to point directly at the current target — this is exactly how 3+ hop chains accumulate over years.
• Using 302 for permanent moves. A very common mistake, especially with CMS "quick redirect" features that default to temporary — check your redirect plugin/rule's actual status code, not just that "it forwards correctly" in a browser.
• Redirect loops. Two URLs pointing at each other (or a URL eventually pointing back at itself) will loop until this tool's 10-hop cap or the browser's own redirect limit kicks in — always a bug, never intentional.
• HTTP-to-HTTPS chains stacked on top of other redirects. A protocol-upgrade redirect plus a separate URL-path redirect is two hops where one combined rule would do — consolidate where possible.

7. Who Should Use This Tool

SEOs and developers cleaning up an old site's accumulated redirect rules, anyone migrating a site's URL structure who needs to verify redirects resolve cleanly, and agencies auditing a client's technical SEO who need concrete evidence of redirect-chain latency to justify a fix.

8. Limitations

This trace caps at 10 hops — a chain longer than that (rare, but possible with badly configured redirect loops) will stop at the cap rather than continuing indefinitely. It requests with a generic user agent and no cookies, so it won't reflect redirect logic that varies by visitor (geo-targeting, A/B test redirects, logged-in-only rules) — those need to be tested with the actual conditions that trigger them.