Redirect chain checker. Trace + verdict.
Paste curl -ILv output (or browser DevTools redirect chain). We trace every hop, count the chain, identify mixed 301/302 (link-equity bug), and flag http→https or apex→www patterns that could be one-hop instead.
Paste output from curl -ILv https://example.com (the verbose-with-redirect-following form). The checker parses every HTTP status line + Location header and reconstructs the full redirect chain with hop count, status codes, and target URLs.
How to capture the redirect chain
- curl:
curl -ILv https://example.com— -I HEAD only, -L follow redirects, -v verbose. The output shows each status line + Location header in the chain - DevTools: F12 → Network → click document → Headers panel → look for "Status Code: 301 (from disk cache)" lines for each hop. The Network table also shows redirect hops as separate rows
Sources used
- RFC 9110 §15.4 Redirection 3xx — canonical status code definitions
- Google Search Central — 301 redirect best practices
- MDN HTTP redirection status codes
- web.dev redirect performance guide
No data is sent to any external service. Parsing happens entirely in your browser by extracting status lines and Location headers from your pasted text.
Privacy: parsing happens in your browser. Nothing is sent or logged.
Each hop is a tax.
Every redirect hop costs 50-300ms of TTFB and slightly degrades passed link equity even with 301s. Google's documentation states crawlers follow chains up to ~5 hops; longer chains may not be fully crawled. The checker above traces every hop, identifies mixed 301/302 (a common SEO bug where temporary redirects break link-equity transfer), flags loops, and recommends collapsing collapsible chains. The most common bug it surfaces: http://example.com → https://example.com → https://www.example.com when a single direct rule could send http://example.com → https://www.example.com in one hop.
Three rules for clean redirects. One, always use 301 (or 308 for non-GET methods) for permanent redirects — 302 does not transfer full link equity. Two, target one hop maximum; collapse multi-hop chains by writing direct rules at the highest layer (CDN edge or origin web server). Three, never chain redirects across services — if Cloudflare redirects http→https and origin redirects apex→www, audit who's doing what and merge the rules into one place.
Tools in the same cluster: HTTP Status Code Checker for the per-URL status verdict. Canonical URL Checker for the canonical-tag audit (often the SEO signal that determines which redirect target is correct). HTTP Headers Checker for the broader headers grade.
Five answers.
Why do redirect chains hurt SEO?
Each redirect hop adds round-trip latency (50-300ms per hop depending on origin). A 4-hop chain can add 200ms-1.2s to TTFB. Google states that crawlers follow chains up to ~5 hops; longer chains may not be fully crawled, costing index inclusion. Each hop also slightly degrades passed link equity even with 301s. The fix is replacing chains with single-hop direct redirects (e.g., http://example.com → https://www.example.com directly, not http → https → www).
301 vs 302 vs 307 vs 308 — what's the difference?
301 (Moved Permanently): old URL transferred to new URL forever; passes link equity. Browsers + crawlers cache aggressively. 302 (Found): temporary redirect; preserves request method but does NOT pass link equity for SEO. Use only for true temporary redirects (A/B tests, geo-redirects). 307 (Temporary Redirect): like 302 but guarantees the request method stays the same (e.g., POST stays POST after redirect). 308 (Permanent Redirect): like 301 but guarantees method preservation. For SEO migrations, ALWAYS use 301 (or 308 for non-GET) — never 302.
What's the maximum healthy chain length?
Best practice is zero or one hop. Two hops is acceptable (e.g., http → https + apex → www can collapse to one-hop). Three hops is the warning line — investigate why. Four+ hops is broken and likely costing crawl budget + TTFB. Common multi-hop bugs: legacy redirect rules left in place after migrations, www/apex preferences fighting protocol redirects, locale-redirect chains stacked on top of CDN redirects, and tracking-link wrappers (utm_source) chained through marketing tools.
What about temporary loops?
Redirect loops (A → B → A or A → A) cause browsers to display ERR_TOO_MANY_REDIRECTS after about 20 hops and crawlers stop indexing the URL entirely. Most loops are caused by misconfigured rewrites (e.g., a rule that redirects http→https without a host condition, applied at multiple layers — origin + CDN both redirecting). The checker above flags repeated URLs in the chain as loops.
Does this tool save my data?
No. Parsing happens in your browser. Nothing is sent to any server. Closing the tab clears the data. The Copy Results button puts a plain-text summary on your clipboard.
Multi-hop chain in production?
Our SEO engagements audit redirect chains across CDN + origin layers, collapse multi-hop sequences to single-hop direct redirects, and ship the migration without losing rankings.
Published .