Skip to content

↪️ Redirect Chain Tracer

Trace URL redirects hop by hop. Shows status code, latency per hop, HTTPS upgrades/downgrades, loops, and excessive chains.

100% Free No signup Server-side No logs / DB Rate-limited 5 languages Dark mode

⚠️ Requests are made from DevLab servers. Private IP addresses and localhost are not allowed.

📚 Redirect Best Practices

• SEO ideal: ≤3 hops. Google may stop following after 5.

• Use 301 for permanent, 302 / 307 for temporary.

• Never downgrade from HTTPS to HTTP.

• Redirect loops are critical bugs to fix immediately.

📖 What this check tells you

This check follows the Location header hop by hop from the URL you enter and shows the status code and target of each step plus the final destination. The hop count a real user experiences may differ. In a browser with HSTS in effect the first hop from HTTP to HTTPS is replaced internally before anything reaches the network, and on sites that vary by cookie or region the route itself changes.

Item What it means How to fix it
Choosing between 301/302 and 307/308 For historical reasons, 301 and 302 permit the browser to change a POST into a GET while redirecting. 307 and 308 preserve both the method and the request body. Moving a form endpoint or an API route with a 301 therefore produces the baffling failure where the request arrives with its body gone. For a permanent move, use 301 on pages that only ever receive GET and 308 on endpoints that accept POST. For a temporary switch such as a maintenance page or an A/B test, prefer 307 over 302: keeping the method intact removes a whole class of accidents.
The chain has an avoidable extra hop Writing the HTTPS upgrade and the www canonicalisation as separate rules always costs two hops: http://example.com to https://example.com to https://www.example.com. Add a trailing-slash rule and it becomes three. Every hop is a full round trip, which is noticeable on a mobile connection. Have the first rule jump straight to the final form — scheme, host and trailing slash included. On nginx this is one line in the listen 80 server block: return 301 https://www.example.com$request_uri;. Stacking individual redirects gets harder to reason about with every rule you add.
The final URL differs from the canonical When the end of the chain and the canonical declared on that page disagree, Google decides for itself which one is canonical. This is the state behind the pair of Search Console messages about a page with a redirect and about Google choosing a different canonical than the one you marked. Confirm that the canonical on the final page points at its own URL, matching exactly — trailing slash, letter case and tracking parameters included. In a site migration the rule is one old URL to one new URL; funnelling everything to the home page instead makes Google treat those as soft 404s.

Redirects are not something to clean up. External links to the old URL and unrefreshed bookmarks survive for years, and Google itself recommends keeping migration redirects for at least a year. We run the 301s from our own former domain on exactly that basis. A few months after a migration, run this check again to catch redirects whose destination has since become a 404.

🔗 Related Tools