Where does this address actually end up?
Enter a URL. This follows every hop the way a browser does, shows you the whole chain, and tells you what it costs you. No signup, no email required.
Every test, explained
A redirect can fail in more ways than not working, and most of them still show a page at the end. Here is what each test looks at.
The chain — every hop between the link and the page
A redirect is one server saying "not here, try there". The tool follows each of those the way a browser does, up to ten of them, and shows you the whole route with the status code each hop returned.
Two things end a chain badly. A loop sends the browser in a circle, and the visitor gets an error page rather than your content. A chain that never terminates hits the browser's own limit and does the same thing. Both are usually two rules fighting each other — one forcing www, another forcing the apex.
Length matters even when the chain works. Every hop is a full round trip before anything renders, and search engines pass less through each one. So three hops gets flagged, and so does the two-hop case where one rule would have done the job.
The destination — what you actually arrive at
A redirect can work perfectly and still be broken. It sends the visitor somewhere, and nobody checks that the somewhere is still there.
This is the expensive one, because it looks fine in the logs. The redirect succeeded. Only the last request failed, and by then it is a different line in a different file. Meanwhile every old link, bookmark and search result points at a dead end.
So the tool reads the final status. A 404 at the end of a working chain is reported as critical, and a server error at the end is reported as high.
The path — does the deep link survive
Enter a URL with a path and the tool checks whether that path still exists at the end of the chain, or whether everything has been swept onto the homepage.
This is the classic sign of a migration that mapped the domain and never mapped the URLs. One rule catches every request and points it at the root. The site looks fine, the homepage loads, and nobody notices until traffic drops.
Search engines call that a soft 404 and pass nothing through it. Visitors following an old link land somewhere they have to start over, and most of them leave instead.
Permanent or temporary — which one you told them
A 301 says the address moved for good. A 302 or 307 says it moved for now. Search engines treat those completely differently.
Temporary tells them to keep the old address indexed and to keep sending people to it. That is the opposite of what a canonical redirect is for. Browsers will not cache it either, so every visitor pays for the extra request every single time.
The tool only flags this on hops that change the hostname or the scheme, because those are permanent moves by definition. A temporary status on a path is frequently correct — logins, carts and one-time links all use it properly.
www and the apex — do they agree
Whatever you enter, the tool also checks the other form of your address. Enter example.com and it checks www.example.com too, and the reverse.
One of them should redirect to the other. When both answer with a page instead, search engines see two sites with identical content, and links to your pages get split between them. Each version then ranks on a share of the total rather than the whole.
Visitors get two sets of cookies and two sessions out of it as well, which is how "it logged me out for no reason" reports usually start. Whether the DNS records for both names exist at all is a different question, and the DNS Health Check answers that one.
HTTP to HTTPS — and anything that goes back
The tool asks port 80 the same question a visitor does. Type the address without https:// and do you end up encrypted, or do you stay on plain HTTP.
If you stay, anyone typing your address sees "Not secure" in the address bar and sends everything in the clear. Search engines index both versions and split the ranking between them, which is the same problem as the www one and usually the same fix.
Then there is the worse case: a chain that starts encrypted and drops back to HTTP partway through. Everything after that point travels in the open, including any session cookie the first request set. That is almost always one rewrite rule with a hardcoded http:// target nobody updated when the certificate went on. The certificate itself belongs to the SSL Certificate Checker.
Redirects done inside the page
Not every redirect comes from the server. A page can return a perfectly normal 200 and then move the visitor on with a meta refresh tag or a line of JavaScript.
Browsers follow those, so it mostly works and nobody files a bug. Search engines treat them as a weak signal at best and pass little or nothing through them, which is the whole point of a redirect after a move.
So the tool reads the final page and reports one if it finds it. The JavaScript check is deliberately narrow — it only fires on a small holding page that does nothing else, because real pages set the location for menus and consent banners all day and flagging those would make the result worthless.
What usually goes wrong, and how it gets fixed
Most redirect problems come down to the same handful of causes. Here they are, with the fix.
Four hops to reach the homepage
This is the most common result on an older site, and no single rule is wrong. They accumulated. One rule forces HTTPS, another adds www, a plugin adds a trailing slash, and each was added by someone solving one problem at a time.
The fix is to make every entry point reach the destination in one hop. On Apache, send the whole of port 80 straight to the canonical HTTPS address rather than to HTTPS and then onward:
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
Redirect permanent / https://example.com/
</VirtualHost>That takes both http://example.com and http://www.example.com to the final address in a single hop. Then give https://www.example.com its own port 443 block redirecting to the same place, and the longest route into the site becomes one hop. Re-run this check on all four addresses afterwards, not just the one you use.
Every old URL lands on the homepage
The domain moved and the redirect was written to catch everything. On nginx that is usually one line, and the missing part is at the end of it:
# Drops the path — every page ends up at the root
return 301 https://example.com/;
# Keeps it
return 301 https://example.com$request_uri;On Apache, Redirect permanent already appends the rest of the path, so the equivalent mistake is RedirectMatch with a pattern that swallows it. Either way, test with a deep URL rather than the homepage — the homepage works in both versions, which is exactly why this survives so long.
The move was announced as temporary
Sometimes deliberate, more often a default nobody changed. Plenty of plugins and control panels write a 302 unless you tell them otherwise.
On Apache the word to look for is temp, and the fix is one word:
Redirect temp / https://example.com/ # 302
Redirect permanent / https://example.com/ # 301On nginx it is return 302 against return 301. One caution before you change it: a 301 gets cached hard by browsers, sometimes indefinitely. So make sure the destination is the one you want to keep before you make it permanent, because taking it back is genuinely difficult.
Both www and the apex serve the site
Usually both names sit in the same virtual host, so both answer and neither hands over to the other. Nothing looks broken, which is why it survives.
Pick whichever one is already in more of your links, then redirect the other to it. On Apache, give the name you are dropping its own block:
<VirtualHost *:443>
ServerName www.example.com
Redirect permanent / https://example.com/
# certificate directives still required here
</VirtualHost>The certificate has to cover the name you are redirecting away from, because the browser completes the handshake before it ever sees the redirect. That is the step people miss, and it turns a tidy-up into a certificate warning. Then update the site URL in your CMS to match, or it will keep writing the old form into links and undoing the work.
The redirect is a meta refresh left over from years ago
A holding page with <meta http-equiv="refresh"> in the head. It usually dates from a move that happened before anyone had server access, and it has worked well enough that nobody revisited it.
There is no clever fix here. Delete the page and replace it with a real server redirect, using whichever of the examples above matches your setup. A 301 tells search engines to move the ranking across. A meta refresh asks them to guess.
Found something broken?
Send me the result. I'll tell you what it takes to fix it, and whether it's worth paying anyone to do — including me.
Prefer to talk? Book a free call ↗ · Or hire me on Upwork ↗ · Typical reply within one business day.