How do you trace a redirect chain?
Request the URL without letting the client follow redirects automatically, read the status code and Location header, then request that location and repeat until a response isn't a redirect. That's what this tool does from our server, printing each hop so you can see every intermediate URL and status code instead of only where you end up.
Browsers hide this. Type http://example.com and you land on https://www.example.com/ without seeing that it took two hops to get there. Each hop is an extra round trip for visitors and an extra request for crawlers.
Example chain
Entering http://example.com for a site that upgrades to HTTPS first and adds www second produces:
301: http://example.com → https://example.com/
301: https://example.com/ → https://www.example.com/
Final: 200 https://www.example.com/
Each line is the status code, the URL requested, and where the Location header sent it. The last line is the status of the page that finally answered. A URL that doesn't redirect at all gives a single line:
No redirects — https://www.example.com/shoes/trail responded directly with status 200.
Redirect status codes
The codes are defined in RFC 9110, section 15.4. Google's handling comes from its documentation on HTTP status codes and crawling.
| Code | Meaning (RFC 9110) | Method on follow-up | How Google treats it |
|---|---|---|---|
| 301 | Moved Permanently | May change POST to GET | Strong signal the target is canonical |
| 302 | Found (temporary) | May change POST to GET | Weak signal |
| 303 | See Other | Always GET | Weak signal |
| 307 | Temporary Redirect | Unchanged | Same as 302 |
| 308 | Permanent Redirect | Unchanged | Same as 301 |
The practical rule: if the old URL is never coming back, use 301 or 308. A 302 for a permanent move leaves Google less certain which URL to index. Google's redirects guide adds that an instant meta refresh is read as permanent and a delayed one as temporary, and that a JavaScript redirect may never be seen if rendering fails.
Problems this tool surfaces
| Output | Diagnosis |
|---|---|
| Two or more hops | A chain. Point the first URL straight at the final one |
| 302 on a URL that moved for good | Wrong status; switch to 301 |
Final: 404 or Final: 500 |
The redirect lands on a broken page |
Too many redirects (more than 10). |
A long chain, or a loop such as /a → /b → /a |
Received a redirect with an unresolvable Location header. |
The Location value couldn't be turned into a full URL |
| HTTPS redirecting back to HTTP | Mixed configuration; usually a proxy or CMS setting |
Timed out (the server took too long to respond). |
One hop didn't answer within eight seconds; the chain up to that point isn't shown |
Connection refused (could not connect to the server). |
Nothing is listening at that host and port |
A loop never ends on its own, so it always hits the 10-hop cap. If you see the same pair of URLs repeating in your server logs, that's the cause.
Cleaning up a chain
- Run the oldest URL you know of (old domain,
http://, nowww) and note the final URL. - Change each redirect rule so it points directly at that final URL, not at the next hop.
- Update internal links, canonical tags and sitemap entries to use the final URL, so visitors and crawlers skip redirects entirely.
- Run the check again. The ideal for an old URL is one hop; for a current URL, none.
If you're writing new rules, the redirect generator produces Apache .htaccess, meta refresh and JavaScript redirect snippets. Prefer the .htaccess (server-side) version where you can, since that's the one this checker and every crawler sees directly. To confirm the final page names itself as canonical, use the canonical URL checker.
What gets sent, and the limits
The URL goes to our server, which sends a GET request with a user agent that names this site, and an eight-second timeout per hop. Only http:// and https:// URLs are accepted; anything else returns "Enter a valid http:// or https:// URL." Before each hop, the hostname is resolved over IPv4 and IPv6 and refused if any address falls in a private or reserved range.
Relative Location values are turned into full URLs before being shown, using the standard URL resolution rules, so Location: /new appears as https://www.example.com/new and ../new is resolved against the current hop's path. The checker doesn't send cookies, so redirects that depend on a session, a language cookie or your geographic location may differ from what you see in a browser.
For a page full of links, the broken link checker follows redirects on each link and reports which ones end in an error.
Last updated