Redirects
Redirect Checker
Trace every hop in a redirect chain with its own status code and timing — and catch the 302s, loops and stacked rules that quietly cost you rankings and speed.
What This Tool Does
This tool requests your URL without letting the HTTP client follow redirects automatically. It reads the Location header, records the status code and timing, then requests the next URL and repeats — up to ten hops.
That manual approach is the entire point. A browser follows a chain silently and shows you the destination, so a three-hop chain and a direct hit look identical from the outside. The problems worth finding are in the hops: a 302 where a 301 was meant, an extra rule nobody knew was stacking, a drop from HTTPS back to plain HTTP in the middle.
Every hop is also re-validated before it is followed. A chain pointing at a private or reserved address is refused rather than followed, which is what stops an open redirect on a public site being used to reach an internal network.
How to Read Your Results
The hop list
Each row is one request and one response. The status code is what that specific URL returned, and the timing is that hop’s own round trip. Hops marked not encrypted were served over plain HTTP.
Status codes
301 and 308 are permanent. Search engines transfer ranking signals to the destination, and browsers cache the redirect so it stops costing a round trip.
302, 303 and 307 are temporary. They tell search engines the original URL is still canonical, so signals stay behind. They are correct for genuinely temporary situations — a maintenance page, an A/B test, a country-specific detour — and wrong for a permanent move.
The difference between 301 and 308, and between 302 and 307, is whether the request method is preserved. A 301 or 302 historically allowed a POST to become a GET; 307 and 308 guarantee the method survives. For ordinary page redirects the distinction rarely matters.
Chain length
Two hops or fewer is healthy. Each hop is a full round trip before any content arrives, so the cost is paid by every visitor on every request that enters the chain.
HTTPS
A chain should finish on HTTPS and never move backwards to plain HTTP. A mid-chain downgrade means a redirect rule is sending traffic to an explicit http:// address — usually a hard-coded URL in a server config or a CMS site-address setting.
Destination
The final status code. A redirect ending in a 404 is worse than no redirect: the original URL loses its ranking and visitors get an error instead of content.
Common Problems and Fixes
A permanent move is using a 302
Change the status code to 301 in whatever issues the redirect — server config, CMS plugin, or CDN rule. Search engines will re-evaluate over subsequent crawls. Note that browsers cache 301s aggressively, so test in a private window once you switch, or you will keep seeing the old behaviour.
Three or more hops
Find the rules producing each hop and collapse them into one that jumps straight to the final URL. The usual pattern is an HTTP-to-HTTPS rule and a hostname rule applied in sequence; a single rule can do both at once, for example sending http://example.com directly to https://www.example.com rather than via https://example.com.
A redirect loop
Two rules are disagreeing. Check whether one forces www while another forces the apex. If the site is behind a proxy or CDN, check whether the origin is redirecting to HTTPS because it sees a plain HTTP connection from the proxy — the fix there is to trust the X-Forwarded-Proto header instead.
The chain ends at a 404
Point the redirect at a page that actually exists — ideally the closest equivalent content rather than the homepage, since a redirect to the homepage is treated by search engines as a soft 404 and transfers little. If no equivalent exists, removing the redirect and returning a 410 is more honest and more useful than sending people somewhere irrelevant.
The chain drops to HTTP mid-way
Find the rule with a hard-coded http:// destination and change it. In a CMS this is often the stored site URL rather than a server rule.
What This Tool Cannot Tell You
- It only sees HTTP redirects. A meta refresh tag or a JavaScript redirect happens after the page is delivered and is invisible at the protocol level.
- It traces one URL per check, not your site. There is no bulk mode. Redirect rules often apply per path, so a clean result for one page says nothing about another — a whole-site sweep is a crawler’s job.
- It follows at most ten hops. Longer chains are reported as too long rather than followed further.
- It cannot see redirects that depend on the visitor. Rules keyed to cookies, logged-in state, country or user agent may send our request somewhere different from where they send you.
Frequently Asked Questions
What is the difference between a 301 and a 302?
A 301 says the move is permanent. Search engines transfer ranking signals to the new URL and browsers cache the redirect, so the round trip stops happening on repeat visits.
A 302 says the original URL is still the right one and this is a temporary detour. Ranking signals stay with the old address, and the redirect is not cached. Using a 302 for a permanent move is one of the most common and most costly SEO mistakes, because everything looks like it works — visitors land in the right place, and only the rankings quietly fail to follow.
How many redirects is too many?
Two is the practical maximum for a well-configured site: typically an HTTP to HTTPS upgrade, then a hostname change between the apex and www.
Three or more almost always means two separate rules stacking that nobody realised were compounding. Every hop is a full round trip before the browser receives any content, so a three-hop chain on a slow connection can add most of a second to every request that touches it.
What causes a redirect loop?
Two rules disagreeing. The classic case is one rule forcing www and another forcing the apex, so each sends traffic to the other forever.
The other common cause is an HTTPS redirect behind a proxy or load balancer. The proxy terminates TLS and forwards the request to the origin over plain HTTP, the origin sees an insecure connection and redirects to HTTPS, and the loop closes. The fix is to have the origin trust the X-Forwarded-Proto header rather than inspecting the connection it can see.
Do redirects hurt SEO?
A single well-chosen 301 is fine and is the correct way to move a URL. The damage comes from three things this tool looks for.
Using a temporary code for a permanent move, so signals never transfer. Chaining several hops, which dilutes signals and adds latency. And redirecting to a page that no longer exists, which is worse than no redirect at all — the original URL loses its ranking and visitors get an error.
Why does this use GET rather than HEAD?
Because a meaningful number of servers answer HEAD differently from GET, or reject it outright. A redirect checker that reports a chain no real browser would follow is worse than useless.
The response body is discarded without being read, so the only cost is the server generating a response it would have generated for a visitor anyway.
Does it follow redirects to other domains?
Yes, and cross-domain hops are shown like any other. Every hop is re-validated before it is followed, so a chain that points at a private or reserved address is refused rather than followed — that is how open redirects get abused to reach internal networks.
Tracing stops after 10 hops and reports the chain as too long rather than following it indefinitely.
Can I check several URLs at once?
No. This tool traces one URL per check — there is no bulk field, list paste or CSV upload, and adding one is not planned.
That is a deliberate limit rather than a missing feature. Every hop is a real request to a real server, so a list of a few hundred URLs turns one button press into several hundred requests against someone else's infrastructure. The rate limit exists for the same reason.
For a whole-site sweep, a crawler is the right instrument: a desktop crawler such as Screaming Frog follows redirects across every URL it finds and exports the chains. Use this tool for the URLs that actually matter — the ones you just changed, the ones in a campaign, or the one an audit flagged — where you want the full transcript of a single chain rather than a column in a spreadsheet.
Does it check meta refresh or JavaScript redirects?
No. Only HTTP-level redirects — those sent as a 3xx status with a Location header — are traced. A meta refresh tag or a JavaScript location change happens after the page has already been delivered, so it is invisible at the protocol level.
If this tool reports a clean 200 but your browser still ends up somewhere else, the redirect is in the page rather than in the response, and viewing the page source will find it.