Redirect Checker
Trace every redirect a URL passes through before it lands. Enter an address and this tool follows the full redirect chain hop by hop, showing each source URL, the status code it returned (301, 302, 307, 308) and the final destination. Redirect chains are a silent performance and SEO drain, and the only way to see one clearly is to walk it.
We follow every redirect live from our server, re-checking each hop. Nothing is stored.
How to use the Redirect Checker
Enter a URL and press Trace redirects. The tool follows the chain from your starting URL to the final page and shows:
- Every hop in order — the URL, the status code it returned, and where it redirected to.
- The final destination and its status code.
- Flags for a http→https upgrade, whether the chain ends on HTTPS, and whether the chain is unusually long.
Try starting from the http:// version of a domain to see the full upgrade path (http → https → www, for example). A bare host defaults to https://, so type the scheme explicitly when you want to test the insecure entry point.
Why redirect chains matter
A redirect tells the browser "the thing you asked for is at a different URL". One redirect is normal and useful. The problem is a chain: when the first redirect points to a second, which points to a third, before finally reaching the page. Each hop is a full round-trip — DNS, connect, TLS, response — and they add up.
Chains hurt in several concrete ways:
- Speed — every extra hop delays the first byte of the real page, which is felt most on mobile networks with high latency. Three redirects can easily add half a second before anything loads.
- SEO — search engines follow redirects but a long chain dilutes signals and wastes crawl budget. Google recommends keeping chains short and pointing redirects straight at the final URL.
- Link equity — each 301 in a chain is a place where ranking value can leak, and a chain that ends in a 302 or an error passes nothing.
- Reliability — chains are fragile. If one hop breaks you get a loop or a dead end, and loops trigger the browser's "too many redirects" error.
The classic offender is the canonicalization path: http://example.com → https://example.com → https://www.example.com → https://www.example.com/. Each step is defensible alone, but together they are three redirects where one well-configured rule would do. Tracing the chain is how you find and collapse them.
Common use cases
- Auditing site speed — find and collapse multi-hop chains that delay the first paint.
- SEO migrations — confirm old URLs 301 straight to the new ones with no intermediate hops.
- Checking short links — reveal where a shortened or tracking URL actually ends up before you click it.
- Debugging redirect loops — see exactly where a "too many redirects" error originates.
- Verifying HTTPS upgrades — confirm http requests are upgraded to https in a single, correct step.
How to collapse a long chain
Once you can see the chain, fixing it is usually about pointing each redirect at the final URL rather than the next link:
- Combine rules — handle the scheme and host in one redirect. A single rule can take
http://example.com/xstraight tohttps://www.example.com/xinstead of redirecting twice. - Update old 301s — when a target itself later moves, repoint the original redirect to the new final URL so you never have a 301 pointing at another 301.
- Mind the trailing slash — pick one convention (slash or no slash) and make the server apply it in the same redirect, not a separate hop.
- Check after CDN changes — a CDN or reverse proxy can add its own redirect; re-trace the chain after any infrastructure change.
The goal is at most one redirect from any entry point to the canonical URL.