Redirect and Header Check
It shows each hop with its code and target up to the final URL, spots endless loops, and then inspects the key headers on the last response.
- No sign-up needed
- Tells 301 from 302
- Security and cache headers
Run the tool right here on the page
Trace a URL's redirect chain one step at a time and inspect 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 permanently and Google should hand the old URL's equity to the new one. A 302 means it is temporary and Google keeps the old URL as the original. Using a 302 where a 301 belongs is the most common way a site migration loses its rankings.
Another use that comes to mind less often is speed. Behind every redirect hop sits a full network round trip, and on mobile inside Iran that round trip has a cost. Someone typing example.com may be shifted three times before a single dot of the page appears: first http to https, then the non-www form to the www form, and finally the home page to a language version. All three are needed, yet all three can be folded into one step.
On the last response the headers say something else. From the compression header you learn whether the server hands over the output compressed or raw; without it, every user pulls down several times the necessary volume. The caching header sets whether the browser may store files or must refetch them on every visit. The effect of these two on a return visit usually exceeds any other optimisation.
For a site that sits under Cloudflare or any other content-delivery network, read the headers with more care. What you see is the edge node's response, not necessarily your origin server's; you might observe compression while the origin compresses nothing and the delivery network has filled the gap. Whenever you take the site out from behind that network, this header is lost too.
The data source and method
Our server requests every hop on its own, without auto-following, up to a ceiling of 10 hops, and it recognizes loops. A case that shows up often in practice: sending http to https and then www to non-www one after the other burns two hops; at the web-server layer the two can be merged into one.
The situations where it helps
After changing a URL or migrating the site, to be sure the redirect is a 301 rather than a 302. Or when speed is unaccountably poor and you want to know how many times a visitor is redirected before the page loads.
Where it falls short
The chain is traced to ten hops and then cut off; a chain that reaches ten is itself a sign of breakage, and going further adds nothing to grasping the issue. Jumps performed by JavaScript or a meta refresh tag do not appear in this output, since they do not take place at the HTTP header level; a difference between the final URL and what the browser shows usually starts there. For Iranian sites, bear this in mind: the request is issued from our server, so if your site treats IPs outside Iran differently, for instance by routing them to an information page, that behaviour is what this output shows, not the behaviour a user inside the country meets.
A lesson from working with it
The pattern we keep running into is this: the http-to-https jump is handled in one layer and the www-to-non-www jump in a separate one, often one at the web-server level and the other in a plugin. The outcome is two jumps back to back, when both rules could sit together in that first web-server rule and cut one full network round trip. On a page opened a thousand times a day, that is a one-line edit with a tangible effect.
What it costs
This tool executes on our own infrastructure with no purchased data behind it, so it costs nothing and stays that way. Its only limit is a daily cap that stops one bot from taking the whole capacity.
The daily cap is measured per visitor. If you need more, a free account lifts your limit.
Common questions about this tool
How many redirect hops are acceptable?
One. Two is tolerable. Three means two rules collide somewhere and one should go. A longer chain is slow for the visitor and sheds 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 costliest thing you can do to equity that took years to build.
Why do I not see a compression header?
Either the server has compression off, or it is not on 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.