Redirect and Header Check
It shows every hop with its code and destination until the final URL, detects endless loops, and then checks the important headers on the last response.
- No sign-up
- 301 versus 302 detection
- Security and cache headers
Run the tool right here
Follow a URL's redirect chain step by step and check its security and cache headers.
- What it costs Free
- Data source Our own server
- Access No sign-up
The short answer
A 301 redirect means this address has changed for good and Google should pass the old URL equity to the new one. A 302 means it is temporary and Google keeps treating the old URL as the original. Using a 302 where a 301 belongs is the most common way a site migration loses its rankings.
The second use of this tool is speed, and it gets less thought. Every redirect hop is a full network round trip, and on Iranian mobile internet a round trip is not cheap. A visitor typing example.com may be moved three times before seeing a single pixel: http to https, non-www to www, and the home page to a language version. All three are necessary, but all three can be done at once.
The headers on the final response tell a different story. The compression header says whether the server sends content compressed or raw; its absence means every visitor downloads several times more than they need to. The caching header says whether the browser is allowed to keep files or has to fetch them again every time. Together those two usually matter more to a second visit than any other optimisation.
If the site is behind Cloudflare or any other CDN, read the headers more carefully. What you see is the edge response, not necessarily your own server response. You may see compression while the origin server compresses nothing and the CDN is covering for it; the day you take the site out from behind the CDN, that header leaves with it.
Where the data comes from
Our server requests each hop separately without following redirects automatically, up to 10 hops, and detects loops. Something we hit often in practice: redirecting http to https and then www to non-www in sequence costs two hops; at the web-server level both can be done in one, saving a hop.
When it helps
After a URL change or a site migration, to confirm the redirect is a 301 and not a 302. Or when speed is inexplicably poor and you want to see how many times a visitor is bounced before reaching the page.
Where it does not help
The chain is followed up to ten hops and then stopped; a chain that reaches ten hops is already broken and continuing adds nothing to understanding the problem. Redirects performed by JavaScript or by a meta refresh tag are not visible here, because they do not happen at the HTTP header level; if the final URL differs from what you see in the browser, that is probably why. And a point that matters for Iranian sites: the request goes from our server, so if your site behaves differently for non-Iranian IPs, for instance sending them to a notice page, you see that different behaviour here rather than what a visitor inside Iran gets.
One thing we learned using it
The pattern we keep seeing is this: the http to https redirect is done in one layer and the www to non-www redirect in another, usually one at the web server and one in a plugin. That produces two consecutive hops, when both rules can be applied together in the web server first rule and save a full network round trip. For a page opened a thousand times a day, that is a one-line change with a real effect.
What it costs
This tool runs on our own server and we buy no data for it, so it is free and stays free. It only carries a daily cap so a bot cannot swallow the whole capacity.
The daily cap is counted per visitor. If you need more, a free account raises your limit.
Questions about this tool
How many redirect hops are acceptable?
One. Two is tolerable. Three means two rules are colliding somewhere and one should be removed. A longer chain is both slow for the visitor and loses a little link equity at each hop.
After changing a page URL, how long should the redirect stay?
For as long as external links to the old URL exist, which in practice means forever. Removing an old 301 is the most expensive thing you can do to equity that took years to build.
Why do I not see a compression header?
Either the server has compression switched off, or it is not enabled for that file type, or the CDN stripped it. If the site is behind a CDN, check there first; in most cases the setting is a simple switch in the panel.