Trace every 301/302/307/308 hop to the final URL
Our redirect checker fetches your URL with the browser-equivalent of "do not follow redirects automatically". On every 3xx response we read the Location header, follow it manually, and record the next hop. The result is the exact path a real browser (or search engine crawler) would take from your starting URL to the final page — including the status code, latency, server software, and Content-Type at each step.
Long redirect chains hurt both SEO and page-load performance. Search engines may stop following after a few hops, and every extra round-trip adds latency, especially on mobile networks. The tool also flags two common security problems: HTTPS → HTTP downgrades (which silently strip TLS protection), and redirect loops (which break the site entirely). For SEO, prefer a single 301 to the final canonical URL rather than chains like example.com → www.example.com → https://www.example.com → https://www.example.com/.
Enter any http:// or https:// URL and the tool will follow up to 20 redirects, displaying every hop in order. URL shorteners, www-to-apex normalisation, country redirects, A/B-test redirects, and login-required redirects are all visible. Use it to debug your own site's redirect rules, audit a third-party link before clicking it, or verify that a vanity URL ends up where you expect.
301 (Moved Permanently) and 308 (Permanent Redirect) tell clients and search engines the resource has moved permanently — they cache the redirect and pass link equity to the new URL. 302 (Found) and 307 (Temporary Redirect) are temporary; clients should keep using the original URL for future requests. The newer 307 and 308 strictly preserve the HTTP method and body (a POST stays a POST), while the older 301 and 302 may be downgraded to GET by some clients. Use 301/308 for permanent moves and 302/307 for short-term things like A/B tests or maintenance pages.
Each redirect hop costs DNS, TCP, and TLS time, multiplying page-load latency on mobile networks. Worse, search engines limit how many redirects they will follow — Google typically stops at around five hops and may drop the page from its index. Every additional 301 in a chain also dilutes link equity slightly. Consolidate chains so that example.com goes directly to https://www.example.com/page in a single 301 instead of bouncing through multiple intermediate URLs.
A downgrade happens when a redirect from an https:// URL points to an http:// URL. Even if the visitor started on a secure page, the redirect drops them onto an unencrypted connection where cookies, form data, and request URLs are visible to anyone on the network path. This is almost always a misconfiguration. The fix is to ensure all your redirect rules preserve the scheme — most CDN and reverse proxy configs let you redirect to "https://$host$request_uri" so the scheme is always https.
On the command line, "curl -I -L example.com" follows redirects and prints headers from each. Adding "-v" shows the raw request/response. You can also use the network tab in browser dev tools — disable "Preserve log" off, refresh, and see every hop with timings. For automated tests, tools like httpie ("http --follow example.com") or Postman with redirect tracing are convenient.
Redirect loops are usually caused by conflicting rules: for example, a CDN rule rewriting http://example.com → https://www.example.com while the origin server simultaneously rewrites https://www.example.com → http://example.com. Other common causes are aggressive HSTS combined with a misconfigured upstream, login-required redirects that fail to set the session cookie, or country-based redirects that detect the wrong country. Trace the chain with this tool to identify the exact pair of URLs bouncing back and forth, then fix one side of the rule.
