Trace Every Hop in a URL's Redirect Chain

What it does

Paste a URL in and the tool follows it through every redirect until it lands on a final page, listing each hop along with its status code. That matters because a URL can look fine in a browser, since browsers follow redirects silently, while still running through three or four hops behind the scenes.

How it follows the chain

The checker requests the URL you give it and reads the response header. If that response is a redirect (a 301, 302, 307 or similar status code) it requests the address given in that header, then repeats the process until it reaches a page that returns a normal 200 status or gives up after too many hops. Each step gets recorded with its status code and destination, so you can see where a chain adds an unnecessary detour or loops back on itself.

Why the chain length is worth checking

Every redirect adds a round trip before the page loads, so a chain of four or five hops can add a noticeable delay for a visitor and for a crawling bot alike. Search engine crawlers work through a limited allowance of requests on any site, often called crawl budget (the number of pages a search engine will fetch from your site in a given period), and long redirect chains eat into that allowance for no real benefit. A chain that loops back on itself will simply fail to resolve at all, which is worth catching before a customer or a bot runs into it.

When a quick check is enough

• You have just moved a single page and want to confirm the redirect rule fired the way you expected.
• You are troubleshooting a specific URL that a client or colleague has flagged as slow or broken.
• You are checking a domain migration one URL at a time before rolling it out more widely.

For checking redirects across an entire site, a crawler built for that job, covered on the technical SEO crawlers comparison, will surface chains you did not already know to look for. A worked example of reading the results sits in the redirect chain checker guide.

What it cannot see

This checker follows server-side redirects, the ones set through HTTP status codes. It will not catch a redirect handled by JavaScript in the browser, or a meta refresh tag buried in the page's HTML, because neither of those shows up in the response header the tool is reading. A live fetch can also return a different result from what a search engine saw on its last crawl, so treat the output as a reading of the URL's current state rather than a record of what is presently indexed.