Free redirect checker
Every redirect is a small tax on speed and a chance to leak ranking signals. A redirect that downgrades https to http, or bounces through three hops, or lands on a soft 404, costs you crawl budget and trust. We follow your URL and show where it actually ends up: the final resolved address and status, and whether the trip upgraded, downgraded, or wandered. One honest limit up front: a browser can read the final URL and status, but it cannot see each hop's individual 301-versus-302 code, and it cannot follow a JavaScript redirect. We say so where it matters. Grounded in Google's redirect guidance.
free / no email / follows the redirect in your browser
redirect health is part of the 164 checks in the full auditlamp audit
Or paste the HTML. We read it here.
Server redirects (301, 302) happen before any HTML arrives, so a trace above is the way to see them. But some pages redirect from inside the HTML itself, with a <meta http-equiv="refresh"> tag or a JavaScript location assignment. Those are slower and weaker signals to Google. Paste your page source and, if you add the page's own URL, we will also judge whether the refresh target upgrades, downgrades, or leaves your domain.
One clean hop to the right place. Not three to the wrong one.
Google follows redirects, but every extra hop and every mixed signal costs you. The expensive mistakes are quiet: a downgrade to http, a chain that loses the trailing slash, a redirect to a page that then redirects back. Here is what we read, grounded in Google's Redirects and Google Search guidance.
- The final URL and status, stated firstThe single most useful fact is where you actually land and with what status. A 200 is healthy. A 404 or 5xx at the end of a redirect means you are sending crawlers and visitors to a dead end. We put the resolved URL and final status at the top of the readout.
- http to https is an upgrade, the reverse is a leakRedirecting an old http URL to its https version is exactly right. The opposite, an https page that redirects to http, hands the vote to the insecure duplicate and can trip browser security warnings. We call the direction plainly.
- www and trailing-slash changesAdding or dropping www, or adding or removing a trailing slash, is a normal canonicalizing redirect, but it should happen in one hop and land on the version your canonical and internal links agree on. We show exactly what changed.
- Chains and loops waste crawl budgetGoogle follows a limited number of hops before giving up. A chain of redirects delays indexing and dilutes signals; a loop is never crawled at all. A single trace tells you whether the browser had to redirect at all to reach the end.
- meta-refresh and JavaScript redirects are weakerA redirect written into the HTML, whether a
<meta refresh>or alocationassignment in script, is slower for users and a softer signal for Google than a server 301. In paste mode we detect these and name the target so you can move it to a real server redirect.
One honest boundary: a browser fetch reports the final URL and status after following redirects, but it does not expose each intermediate hop's own 301-versus-302 status the way a server-side trace (or the full AuditLamp engine) does, and it cannot execute a JavaScript redirect. Where that limit applies, we say so rather than guess.
If your trace ends on a 404, our guide to fixing 404 and soft-404 errors walks the repair. And because redirects and canonicals vote together on which URL Google credits, check how to fix canonical tag errors while you are at it.
A clean redirect chain lands on a URL that matches your canonical tag exactly. If the two disagree -- the redirect settles on www.example.com but the canonical says example.com -- Google must choose between them. Our canonical tag checker reads any live page and flags that mismatch in seconds.
The honest version.
What is the difference between a 301 and a 302 redirect?
A 301 is a permanent redirect and a 302 is temporary, and Google treats them differently. A 301 tells Google the old URL has moved for good, so it should pass ranking signals to the new URL and eventually swap it into the index. A 302 says the move is temporary, so Google tends to keep the original URL indexed and does not fully transfer signals. For a genuine, permanent move, use a 301. Use a 302 only when you truly intend to send visitors back to the original later, such as a short A/B test or a temporary maintenance page.
Are redirect chains bad for SEO?
Yes, in proportion to their length. Each hop adds latency for the visitor and consumes a little of the crawl budget Google spends on your site, and Google follows only a limited number of hops before it stops and treats the URL as an error. A single redirect from an old URL to its final destination is fine and often necessary. A chain of three or four, old URL to https to www to trailing slash, should be collapsed into one redirect that jumps straight to the final address. Redirect loops, where two URLs point at each other, never resolve and are never indexed.
Does a meta-refresh redirect work as well as a 301?
No. A meta-refresh redirect, written as a <meta http-equiv="refresh"> tag in the HTML, does technically send visitors onward, but it is slower because the page must load first, and Google treats an instant meta-refresh as a weaker, less certain signal than a server-side 301. The same is true of JavaScript redirects that set location in script, which also depend on the crawler executing the code. When you control the server, a 301 is the correct tool for a permanent move. Reserve meta-refresh for the cases where you genuinely cannot set a server redirect.
A clean redirect is one of 164 checks. We run them all.
Landing crawlers on the right URL only matters if the page they reach can be read, trusted and cited. The full AuditLamp audit runs 164 documented checks on your live site in one free scan, tracing redirects with a real server-side fetch that sees every hop, then reading whether your content survives without JavaScript and whether there is an answer worth quoting near the top. Full score on screen, no email taken.