Redirect Chain Tester
Follow up to 10 redirect hops and show the full chain.
Overview
The Redirect Chain Tester follows a URL through up to 10 HTTP redirects and reports each hop's status code, target Location header, response time, and final destination. It catches the common SEO problems — chains longer than two hops, meta-refresh redirects that don't pass equity, and redirects that loop back on themselves.
Useful for SEO auditors and developers learning how to test a redirect chain or how to find redirect loops on a domain. Reach for it after a migration, when verifying that http:// redirects to https://, or when checking that a campaign URL ends at the intended landing page.
How it works
The tester issues a HEAD (falling back to GET) request and follows each 3xx response's Location header, recording each hop. It captures the canonical chain — 301 permanent, 302 temporary, 303 see-other, 307 temporary preserving method, 308 permanent preserving method — plus client-side <meta http-equiv="refresh"> redirects parsed from text/html responses.
The tool stops at 10 hops to avoid runaway loops and reports the final 200, the chain length, and the total time. Each hop's status code is colour-coded to surface mixed 301/302 sequences (which can confuse search engines).
Examples
http://example.com→ 301 →https://example.com→ 200. Healthy two-hop chain.- A campaign URL goes
bit.ly→ 301 →analytics.example.com→ 302 →example.com/landing→ 200. The 302 should likely be 301 for SEO equity. - A redirect loop:
/a→ 302 →/b→ 302 →/a. Stopped at hop 10. - A meta-refresh chain that engines treat as a soft redirect, reported with the parsed
contentattribute timing.
FAQ
Why are chains longer than two hops bad?
Each hop adds latency for users and slightly reduces the link equity passed by search engines. Aim for at most one redirect between any two URLs.
301 vs 302 — which passes equity?
Both pass equity per Google's recent statements, but a 301 is the right semantic — it tells engines the move is permanent. Misusing 302 for permanent moves slows index updates.
Does the tester send cookies?
It sends none by default, which approximates a search engine bot's view. Some servers behave differently for logged-in users; this view is the bot view.
Why does my redirect work in a browser but show as a 200 here?
The browser may be following a client-side JavaScript redirect, which only fires after running scripts. Search engines and this tool don't run JS, so the destination differs.