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 116 checks in the full auditlamp audit
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.
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.
<meta refresh> or a location assignment 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.
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.
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.
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.
Landing crawlers on the right URL only matters if the page they reach can be read, trusted and cited. The full AuditLamp audit runs 116 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.