Free tool
Where does this URL actually end up?
The chain gets walked one hop at a time, with nothing collapsed along the way: the status code at every step, the URL it points to next, and what that step costs in milliseconds. You pick the starting point yourself — http or https, with www or without — because those are four different front doors into the same site, and they rarely behave the same way.
What a redirect chain really costs
Every hop is a full round trip that happens before the visitor sees a single pixel, and the first one costs the most: it usually goes out before the secure connection has even been set up. Three hops on a phone over 4G is a second burned before the first byte arrives. Length is not the only thing that bites, either. A chain is where a campaign parameter quietly disappears, where a forgotten 302 keeps a new URL out of the index, and where a loop shows up the day somebody adds a rule without reading the ones already there.
How the chain gets followed
Hop by hop, and never by letting the HTTP client run ahead on its own: each response's location header is read, shown to you, then requested in turn. Redirects written into the HTML with a refresh tag, and the header that does the same job, are followed too — Google treats both as redirects. The walk stops at ten hops, stops at the first loop, and refuses outright to fetch a URL that resolves to an internal network.
The staircase
Four hops nobody ever sees
You type a URL, a page appears, and the round trips in between leave no trace. Here they are step by step, with the code each one returned, and two passengers worth watching: the encryption and the cookies from the starting domain.
- 301http://example.com/promo
The very first request travels in the clear, and it already carries the URL being asked for. — permanent, remembered by browsers and search engines; for historical reasons the method may switch to GET (RFC 9110)
- 301https://example.com/promo
Encryption starts here, one round trip too late. This hop adds the www. — permanent, remembered by browsers and search engines; for historical reasons the method may switch to GET (RFC 9110)
- 308https://www.example.com/promo
One more step for the language and the trailing slash. — permanent, the request method must not change (RFC 9110)
- 302https://www.example.com/fr/promo/
The last hop changes domain. — temporary, nothing is remembered; the same switch to GET may happen (RFC 9110)
- 200https://shop.example.net/fr/promo/
The page arrives. The cookies set on example.com did not follow it here: they do not belong to this domain.
5 requests and 4 redirects before the page starts to appear.
Sample chain, on the domain names reserved for documentation.
What a hop costs
Every hop is paid for before the first byte.
A full round trip before the visitor sees anything — and the first hop often goes out before the secure connection is even up.
- 301permanent: the target becomes canonical
- 308permanent too, method and body preserved
- 302temporary: the starting URL stays on show
Reading the chain
Every link carries its status code, its response time and the URL it points to next. Green is the healthy case, amber is what needs a decision, red is what breaks.
- 301 or 308, then the page
- Two links and it is over. A permanent redirect tells Google to treat the target as canonical, which is exactly what you want after a move. A 308 does the same while keeping the request method and body, which matters for a form.
- 302, 303 or 307
- A temporary redirect. Googlebot follows it, but indexing will not move to the target: the old URL stays in the results. Right for a page that is away for a while, wrong for a migration you finished six months ago.
- Three links or more
- The chain works, it just costs, and it nearly always means two rules stacked: one upgrading to https, another adding or stripping the www. A single rule can do both.
- A refresh inside the page
- The redirect sits in the HTML, not in the header, so the browser downloaded a whole page just to learn it had to go elsewhere. Google follows this kind and reads one with no delay as permanent, but its own documentation points you to a server-side redirect.
- Loop
- The chain comes back to a URL it already passed through. The visitor gets a browser error, not your site. The usual cause is one rule on the server and another in the application, handing the request back and forth.
- The destination answers 404 or 500
- The redirect works, the page it lands on does not. This is the hardest one to catch without a tool, because the chain looks right up to the last link.
- No answer
- Server unreachable, timed out, or certificate rejected at this step. A visitor stops exactly where the tool stopped.
The most common redirect mistakes
Four things we find on half the sites we inherit, and what fixes each one.
The bare domain and the www version land in different places
What causes it: Two rules written at two different times, or only one of the two forms set up at the host. The site answers on both, serves the same content on both, and neither one points at the other.
What fixes it: Pick one canonical form, once, and 301 the other onto it. Then check all four front doors here: http and https, with www and without.
Two hops to upgrade to https and add www
What causes it: The web server handles the https upgrade, the application or a second rule adds the www. Each one fixes half the URL, and they run back to back.
What fixes it: One rule that writes the final URL outright, scheme and host included. Three links become two, and the saving falls on the first request, the one that costs most.
A temporary redirect forgotten after the migration
What causes it: 302 is the default in many tools, and it is handy during a test because browsers don't cache it. Nobody comes back to change it once the migration is over.
What fixes it: Switch to a 301 the moment the change is permanent. For as long as it stays temporary, Google keeps showing the old URL in its results.
The whole old site redirected to the home page
What causes it: A single rule, written in ten seconds to avoid hundreds of 404s during a redesign.
What fixes it: Map each old page to its equivalent. Google treats a redirect to an unrelated page as a page not found, and a visitor who came for one article just leaves. Where there is no equivalent, a real 404 page beats dumping people on the home page.
Redirect status codes, and what each one tells Google
The first two columns come from the HTTP spec, the third from Google's own documentation on redirects. None of it is a house preference.
| Code | Meaning | What Google does with it | Request method |
|---|---|---|---|
| 301 | Moved permanently. | Permanent: Googlebot follows it, and indexing treats the target as canonical. | The client may turn a POST into a GET. |
| 308 | Moved permanently, method preserved. | Permanent, exactly like a 301. | The method and body are preserved. |
| 302 | Found elsewhere, temporarily. | Temporary: Googlebot follows it, but indexing stays put. The starting URL is the one that keeps showing. | The client may turn a POST into a GET. |
| 303 | See other. | Temporary, like a 302. | The next request is always a GET. |
| 307 | Temporary redirect, method preserved. | Temporary, like a 302. | The method and body are preserved. |
| refresh with no delay | Redirect written in the HTML or in the Refresh header, triggered on load. | Permanent: Google interprets an instant refresh as a permanent redirect. | Always a GET: it is the browser starting over. |
| refresh with a delay | Same mechanism, triggered after a number of seconds. | Temporary: Google interprets a delayed refresh as a temporary redirect. | Always a GET. |
| 300 | Multiple choices. Very rarely used. | Nothing specific documented. This tool follows it only when it carries a location header. | Depends on the client. |
| 304 | Not modified. Not a redirect at all — it is a cache response. | No redirect effect. The copy already held is reused. | Not applicable. |
Google also follows a redirect written in JavaScript, once the page has run. This tool does not show those: it runs no scripts, and pretending otherwise would misrepresent what it measures.
The four doors into one site, and where they should end
A site has four front doors, and visitors type all four. The goal is the same for each: reach the canonical URL in one hop at most.
| URL typed | What should happen | Hops |
|---|---|---|
| http://example.com | One permanent redirect to the full canonical URL, scheme and host included. | 1 |
| http://www.example.com | The same thing, in one rule: do not upgrade to https and then strip the www. | 1 |
| https://example.com | The page if this is the canonical form, a permanent redirect otherwise. | 0 or 1 |
| https://www.example.com | The page if this is the canonical form, a permanent redirect otherwise. | 0 or 1 |
Bare domain or www makes no difference to SEO. What does: pick one, and make sure the other three reach it in a single hop.
Frequently asked questions
301 or 302: which redirect should I use?
A 301 when the change is permanent — that is what tells Google to treat the new URL as canonical. A 302 when the page will come back to where it was: maintenance, a temporary promotion. The trap is leaving a 302 up after a migration, because the old URL then stays in the results.
How many redirects can you chain?
As many as you like technically, but each hop is a round trip before the page's first byte. Past two it is nearly always two rules stacked where one would do. This tool stops following after ten hops — beyond that, the chain is broken or looping.
Do redirects hurt SEO?
A permanent redirect is the mechanism built to pass canonical status to the new page, so it is the right way to move. Google keeps both URLs on file and may keep showing the old one for a while. What costs you is not the redirect: it is redirecting to an unrelated page, or leaving it temporary.
Why does my site redirect twice instead of once?
Because two rules run back to back: the https upgrade first, then adding or stripping the www. Each one fixes half the URL. A single rule that writes the full final URL removes the hop in the middle.
Is meta refresh bad for SEO?
Google's documentation calls it a fallback for when a server-side redirect is not possible, not an equivalent. A refresh with no delay is read as a permanent redirect, a delayed one as temporary. Either way the browser loads a whole page before it learns it has to leave.
Why does the checker refuse some URLs?
It turns down names that resolve to an internal network address — private ranges, loopback, a host's metadata service. A public form that will query private machines for any stranger is a vulnerability, not a feature. We run that check at every hop, because a redirect is exactly how you would slip past a filter that only looked at the URL typed in.
Do tracking parameters survive a redirect?
Only if the rule carries them over. Plenty of hand-written rules drop the query string along the way, and those visits land in analytics as direct traffic. That is one reason to read the destination URL under each link, not just its status code.
10hops
Past that the tool stops following: the chain is broken, or it loops.
You can chain several, technically. But past two it is nearly always two rules stacked where one would have done.
Four moves
Getting the four entry points straight
The goal is the same for all four URLs: reach the canonical form in one hop at most.
Pick the canonical form, once
Bare domain or www makes no difference to search. What does: picking one, and sticking to it.Write the final URL in a single rule
Scheme and host included. Three links become two, and the saving falls on the first request — the one that costs most.Switch to 301 as soon as the change is permanent
302 is the default in plenty of tools. For as long as it stays up, Google keeps showing the old URL in its results.Check all four entry points, not one
http and https, with www and without: four different ways into the same site, and visitors type all four.
Twenty checks, no sign-up
- Check when fifty domains expire, in one paste
- Who owns this domain, and since when?
- What is this site built with?
- Is this URL open to crawlers?
- Has my DNS change propagated yet?
- Build your SPF record
- Is this domain blacklisted?
- What security headers does this site send?
- A domain's full health report
- When does this domain expire?
- Is this SSL certificate valid, and when does it expire?
- Are your SPF, DKIM and DMARC set up right?
- Is this domain or its mail server blacklisted?
- Which servers receive mail for this domain?
- Which nameservers answer for this domain?
- What do this domain's TXT records do?
- Where does this CNAME end up?