Skip to content
ProbeDNS

Redirect Checker

A redirect checker follows a URL through every hop a browser would take, showing the status code, Location header, server, and timing of each one. This tool follows redirects manually rather than letting the HTTP client hide them, so you see the whole chain instead of only the destination.

What each status code actually does

The number matters more than most people assume. It controls whether browsers cache the redirect, whether the HTTP method survives, and whether search engines treat the move as permanent.

CodeCached by browsersMethod preservedUse it when
301 Moved PermanentlyYes, aggressivelyNo — POST becomes GETThe URL has moved for good and you accept that browsers will remember it
302 FoundNoNo — POST becomes GETA genuinely temporary move, e.g. maintenance
303 See OtherNoAlways becomes GETAfter a POST, to stop resubmission on refresh
307 Temporary RedirectNoYesA temporary move that must keep POST bodies intact
308 Permanent RedirectYesYesA permanent move on an endpoint that accepts POST
A 301 is close to irreversible from the visitor's side. Browsers cache it for a long time and will not re-request the original URL, so a mistakenly published 301 keeps sending your own users to the wrong place long after you fix the server. Test with 302, then switch to 301 once the target is confirmed.

The chain patterns that cost you

The four-hop canonical

The classic bad chain is http://example.com → https://example.com → https://www.example.com → https://www.example.com/. Each hop is a full round trip — DNS, TCP, TLS on the first HTTPS hop — and on a mobile connection that is easily half a second of dead time before a single byte of content moves. It also compounds: every asset behind the same rule pays the cost again.

Read the full explanation of redirect checker results ↓

Collapse it into one rule that jumps straight to the final canonical form. In nginx that is a single return 301 https://www.example.com$request_uri; in the port-80 server block for both hostnames, not a scheme redirect followed by a host redirect.

Redirect loops

Loops produce ERR_TOO_MANY_REDIRECTS and almost always come from a mismatch between what the origin thinks the scheme is and what the edge is actually serving. The textbook case: a CDN terminates TLS and forwards to the origin over plain HTTP, the origin sees http and redirects to https, the CDN serves that redirect, and round it goes. The fix is to make the origin trust X-Forwarded-Proto instead of inspecting the connection.

HTTPS downgrades

Any hop that goes from https:// to http:// is a defect. It exposes the request, breaks under HSTS (the browser will refuse the downgrade and the chain simply dies), and in mixed environments silently drops cookies marked Secure. This tool flags every downgrade it sees.

Meta refresh and JavaScript "redirects"

A chain that ends in a 200 but still lands somewhere else in a browser is redirecting in the HTML body — <meta http-equiv="refresh"> or location.assign(). Neither is an HTTP redirect: they are slower, they are not always followed by crawlers, and they do not pass through proxies the same way. If you see a 200 here but a different final URL in your browser, that is what is happening.

Redirects and SEO

  • Google follows up to roughly 10 hops before giving up; well before that it stops consolidating signals cleanly. Keep chains to one hop.
  • A 301 passes ranking signals to the target. A 302 signals "the original is still canonical", so long-lived 302s leave the old URL in the index.
  • Redirecting everything to the homepage instead of the equivalent page is treated as a soft 404 and throws away the signals you were trying to preserve.
  • Chained redirects across domains dilute more than a single hop: old.com/page → new.com/page in one step is materially better than routing through an intermediate.
  • Keep old redirects in place. Removing them a year later re-breaks every link that was pointing at the original URL.

Tracing a chain from the command line

curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' http://github.com

# or, to see full headers for each hop:
curl -sIL http://github.com | grep -Ei '^(HTTP/|location:|server:)'

HTTP/1.1 301 Moved Permanently
location: https://github.com/
HTTP/2 200
server: github.com
Every hop with its status and Location header
curl -so /dev/null -w 'dns %{time_namelookup}s  tcp %{time_connect}s  tls %{time_appconnect}s  ttfb %{time_starttransfer}s  total %{time_total}s\n' \
  https://example.com
Where the time actually goes on a single hop

One caution when testing: curl -I sends a HEAD request, and a surprising number of origins, WAFs, and CDNs handle HEAD differently from GET — different status, different headers, sometimes a 405. This tool issues real GET requests for that reason. If curl and this page disagree, re-run curl with -sL -o /dev/null -D - to force GET.

Once the chain is clean, check what the final response actually sends with the HTTP headers checker, and confirm the certificate on the HTTPS hop with the SSL certificate checker — an http→https redirect into a broken certificate is worse than no redirect at all.

Frequently asked questions

How many redirects is too many?
One is the target; two is tolerable; three or more is a bug worth fixing. Every hop is a full round trip including DNS and TCP, and on mobile that is 100–300 ms each. Google will follow several but stops consolidating signals cleanly well before its limit. The most common fix is collapsing scheme and host canonicalisation into a single rule.
Should I use 301 or 308?
Use 308 when the endpoint can receive POST and you need the method and body preserved — an API, a form handler. Use 301 for ordinary page moves. Both are permanent and both are cached; the only difference is that 301 allows clients to downgrade POST to GET, which is exactly what breaks form submissions.
Why do I get ERR_TOO_MANY_REDIRECTS only on the live site?
Almost always a proxy/origin scheme mismatch: the edge terminates TLS and talks to the origin over HTTP, the origin sees a plaintext request and redirects to HTTPS, and the loop closes. Configure the origin to trust X-Forwarded-Proto rather than the connection it sees. The same symptom appears with a CDN "Flexible SSL" mode in front of a server that force-redirects to HTTPS.
Does a redirect chain lose link equity?
Google has said 3xx redirects do not lose PageRank, but chains still hurt in practice: crawl budget is consumed, the signals take longer to consolidate, and every extra hop is another chance for a rule to break. Treat "no measurable loss" as an argument against panic, not an argument for leaving four hops in place.
Why does this tool show a different result than my browser?
Three usual reasons. Your browser has a 301 cached and never re-requests the original. HSTS is upgrading http:// to https:// locally before a request is even made. Or the page redirects in HTML via meta refresh or JavaScript, which is invisible at the HTTP layer. Clear the browser cache and test in a private window to separate these.
Can this follow a redirect to an internal or private address?
No, deliberately. Every hop is re-validated, and any redirect pointing at a loopback, private, or link-local address is refused rather than followed. That protects the server from being used to probe internal networks through a public URL — the same reason cloud metadata endpoints are blocked.
Do query strings survive a redirect?
Only if the rule preserves them. return 301 https://example.com$request_uri; keeps path and query; a rule that redirects to a fixed URL drops everything, which silently destroys UTM tracking and shareable links. This tool shows the exact Location header each hop sent, so you can see whether the query string made it.