The Redirect Chain Checker follows a URL through every redirect until it lands on a non-redirect response — and shows you the full trail. For each hop it records the URL, method, status code (301 vs 302 vs 307 vs 308), the Location header target, protocol (http/https), hostname, response time, and the Server banner. It then classifies the chain: is it a single clean hop (fine), a chain of 2 (acceptable), or a chain of 3+ (fix). It detects loops (a URL revisiting itself), HTTPS downgrades (https→http, which browsers and search engines flag), www drift (a hop between www and naked hostname that should have been consolidated), mixed 301/302 usage (only 301/308 pass link equity), and chains that exceed Google's ~10-hop limit. The output is a step-by-step timeline with colour-coded status, plus a scored verdict and a list of exact fixes. Ideal for post-migration audits, http→https rollouts, CDN configuration checks, and debugging why a page "disappeared" from search.
301 vs 302 vs 307 vs 308 — the only chart you'll need
HTTP has four redirect status codes and they matter for very different reasons. 301 (Permanent, method may change). The classic. Tells browsers and search engines: this URL has permanently moved. Google passes link equity to the destination. Use for URL renames, http→https, www consolidation, and anything intended to be permanent. 302 (Temporary, method may change). The default in most languages if you just say "redirect." Google does not pass full link equity, treating the original URL as still authoritative. Use only for truly temporary redirects like maintenance pages or A/B tests. 307 (Temporary, method preserved). Same as 302 but the HTTP method (GET/POST) is preserved. Used mainly for API redirects. 308 (Permanent, method preserved). Modern 301 equivalent. Passes link equity. Use interchangeably with 301 for GET requests. Bottom line for SEO: 301 or 308 for permanent, everything else for temporary. Using 302 by accident is one of the most common SEO regressions we see.
Why chains are worse than they look
Every extra hop in a redirect chain adds real latency (typically 100–300ms of round-trip time) and loses a small amount of link equity — a fact Google has confirmed but never quantified. Google will follow up to about 10 redirects before giving up; users on slow connections give up earlier. The practical rule: one hop is fine, two is acceptable, three or more should be collapsed. Common causes of accidental chains: (a) an old redirect (http→https) followed by a new one (URL rename) — never collapsed, so users go through both. (b) A trailing-slash normalizer followed by a www redirector followed by a URL rewriter — three hops for what should be one. (c) A migration that left old redirects in place instead of updating them to point at the new final destination. Fix: rewrite chained redirects so every source URL points directly at the final destination in a single hop.
Loops — how they happen and why they're catastrophic
A redirect loop is a chain where a URL eventually redirects back to itself (directly or through a cycle). Browsers detect loops after 5–20 hops and show ERR_TOO_MANY_REDIRECTS. Google detects them faster and drops the URL from the crawl queue. Loops usually come from three sources: 1. Conflicting normalizers — one rule redirects /page to /page/, another redirects /page/ to /page. Classic. 2. Case-sensitivity fights — /Page redirects to /page, but the origin lowercases before matching so /page tries to redirect again. 3. Middleware misconfigured — an auth middleware redirects to login, login checks the same auth and redirects back. When our tool detects a loop, the score drops to 0 immediately — nothing else matters until it's fixed. Fix at the server config level, not with more redirect rules.
HTTPS downgrades and www drift — the sneaky killers
HTTPS downgrade (https→http). Some chains accidentally step down from HTTPS to HTTP mid-chain — usually because a rule was added years ago and never updated when the site went HTTPS. Modern browsers refuse to follow this without a warning; HSTS-preloaded sites won't follow it at all. Search engines treat it as insecure. Never acceptable — fix immediately. WWW drift. Common pattern: the http://example.com redirect points to https://example.com (naked), which then redirects to https://www.example.com (www). Two hops when it should be one. Google is fine with either www or naked as the canonical, but not both — pick one and redirect the other directly. Our tool detects both patterns and calls them out explicitly so you know the exact fix.
Practical fixes at the server layer
Nginx. Combine multiple return 301 rules into a single one that goes to the final URL. Use if sparingly (Nginx's if is evil guidance applies here). Apache. RewriteRule chains can cause double-encoding — use [L] flag to stop rewrite processing and prevent chains. Cloudflare / CDN. Page Rules are evaluated in order and can chain if you're not careful. Use Bulk Redirects when you have many rules — they're evaluated as one lookup rather than sequential rules. Node.js (Express). The express-normalizr pattern (canonicalize before doing anything else) prevents most chain problems. Next.js. The redirects config in next.config.js lets you specify permanent (301) or temporary (302); set permanent: true for URL renames.