Redirect Checker

How it works

What we check

• Full redirect chain — Traces every hop from the URL you enter to the page that finally loads. A clean URL resolves directly; a problem URL bounces through two, three, or more intermediate addresses before landing — and each extra hop adds latency and bleeds a little ranking signal.
• Status code at each hop — Shows the exact HTTP code for every step — 301 (permanent), 302 (temporary), 307/308 (their method-preserving equivalents), and the final 200, or a 4xx/5xx error. The code is what tells search engines whether to transfer ranking authority and update their index.
• 301 vs 302 (permanent vs temporary) — Distinguishes permanent moves from temporary ones. A 301/308 tells Google to pass link equity and replace the old URL in its index; a 302/307 tells it to keep the old URL. Using a 302 for a permanent move is a quiet, common ranking leak.
• HTTP → HTTPS upgrade — Confirms insecure http:// requests forward to https://. This redirect should exist and ideally be a permanent 301 — missing it leaves an insecure copy of every page reachable and splits signals between the two protocols.
• Redirect chains & hop count — Counts the hops. One redirect is normal; two is usually fixable; three or more is a chain worth collapsing. Long chains slow the page, risk hitting a browser's redirect limit, and dilute the authority that should flow to the destination.
• Redirect loops & dead ends — Catches the URL that redirects back to itself or bounces between two addresses forever (a loop), and chains that end in a 404 or 500 instead of a working page — both of which leave users and crawlers stranded with nothing loading.

Common issues we catch

• 302 used for a permanent move — A page is moved for good but redirected with a 302 (temporary). Google keeps indexing the old URL and is slower to transfer ranking signals to the new one. For anything permanent — a retired page, a domain migration — use a 301 (or 308) so authority actually moves.
• Multi-hop redirect chains — old.html → /old → /new/ → https://.../new/ — four hops to load one page. Each adds a round-trip of latency, and a little link equity can dissipate along the way. Point the original URL straight at the final destination in one hop.
• Redirect loops — Page A redirects to B, B redirects back to A — the browser gives up with a 'too many redirects' error and nothing loads. Usually caused by conflicting rules (e.g. an HTTPS rule fighting a trailing-slash rule). The checker surfaces the repeating addresses so you can find the clash.
• Missing HTTP → HTTPS redirect — The HTTPS version works, but http:// serves an insecure copy instead of forwarding. Crawlers and old links land on the unencrypted page, and signals split across two protocols. Add a site-wide permanent redirect from http to https.
• Chains that end in a 404 or 500 — A redirect points to a page that no longer exists or errors out. The redirect 'works' — it's the destination that's broken — so it's easy to miss. The final status code in the trace is the tell: it should be 200, not a 4xx or 5xx.
• www vs non-www both resolving — https://example.com and https://www.example.com both load independently instead of one redirecting to the other. Search engines may treat them as separate sites, splitting ranking signals. Pick one canonical host and 301-redirect the other to it.
• Trailing-slash and uppercase duplicates — /page and /page/ — or /Page and /page — both serving the same content without a redirect creates duplicate URLs. Standardize on one form and redirect the variants, or you fragment crawl budget and link signals across near-identical addresses.

Where this matters

• Google & search crawlers — Follow redirects and use the status code to decide indexing: a 301/308 consolidates the old URL into the new one and passes ranking signals; a 302/307 keeps the old URL indexed. Long chains slow re-indexing and can waste crawl budget.
• Browsers — Follow redirect chains automatically but cap the number of hops — too many triggers a 'redirected too many times' error and the page never loads. Each hop is also an extra network round-trip the user waits through.
• CDNs & reverse proxies — Edge layers like Cloudflare often add their own redirects (HTTP→HTTPS, www normalization) on top of your app's. Stacked rules from two layers are a frequent cause of accidental extra hops and loops — which this end-to-end trace exposes.
• WordPress, Shopify & CMS platforms — Redirect plugins and built-in URL-change handlers make it easy to create redirects, and just as easy to stack old ones into chains over time. Periodically auditing the live chain catches accumulated cruft that the admin UI hides.
• Link shorteners & marketing URLs — Short links, UTM-tagged URLs, and vanity domains often add a hop or two of their own before reaching the real page. Tracing them shows the true final destination and how many redirects sit between a click and the content.