Redirect Checker: Chains, Loops, Status

Redirects are harmless in small doses and painful in chains. They slow pages, waste crawl budget and can dilute link equity — especially when mixed protocols and 302s sneak in.

What the redirect checker shows

• Every hop with its HTTP status (301/302/307/308/200/4xx/5xx) and Location target
• Mixed http → https or www ↔ apex patterns
• Loops and long chains that add latency
• Rough timing by hop so you can see where delays appear

Worked example

http://example.com/page → 302 to https://example.com/page → 301 to https://www.example.com/page → 200. That’s 2 hops before content. If each hop adds ~200ms, you just spent ~400ms of TTFB on redirects.

What to do with the result

• Collapse to a single 301 to the final canonical URL whenever possible.
• Make HTTP→HTTPS and apex↔www decisions once at the edge, not three times in app code.
• Update old internal links and sitemaps so crawlers hit the canonical URL directly.
• See other diagnostics on the Tools index. Planning paid traffic? Check CTR and ROAS too.

Common mistakes and when not to trust redirect results

• 302 for permanent moves: Use 301/308 for permanent changes; 302 invites recrawling and cache misses.
• JS/meta refresh “redirects”: Those are not real redirects; fix on the server.
• Conditional redirects: User‑agent, geo or cookie‑based logic can hide alternate paths; test with multiple clients.
• Relative Location headers: Some stacks emit invalid or relative Location; browsers forgive; crawlers don’t.
• Mixed http/https and slash rules: Consolidate protocol, host and trailing‑slash in one hop.

Second example (collapse hops): http:// → https:// (301), then https:// → https://www. (301), then add slash (301) = 3 hops. Replace with a single 308 to the final canonical URL and remove ~400–600ms TTFB.

Run your own URLs

Open the free Redirect & HTTP Status Checker and paste any URL to see chains, loops and timing.