301 vs 302 vs 307 vs 308, in practice
The number matters more than most people treat it as mattering. 301 (permanent) and 302 (temporary) are the two anyone recognises, but the distinction that actually changes crawler and cache behaviour is permanent versus temporary, not the exact number. A 301 tells a crawler to consolidate ranking signals onto the new URL and update its own records; a 302 tells it "check the original again later", so signals stay split between the two. 307 and 308 are the same permanent/temporary split as 301/302, with one added guarantee: a 307 or 308 promises the request method and body are preserved across the redirect, which 301 and 302 technically don't (in practice every modern browser preserves GET either way, but a POST is where the difference actually bites). For a link a marketer sets up by hand, the choice is almost always between 301 and 302, and the deciding question is simple: is this move permanent? If yes, use a 301.
Why redirect chains cost you
Each hop in a chain is a full round trip: the browser has to send a request, wait for a response, then send another request to the new address, before the destination page can even begin loading. That latency lands on every single visitor, every single time, forever, until someone fixes it. A two- or three-hop chain adds a noticeable delay on a slow connection; a longer one is often the actual reason a landing page "feels slow" when the page itself loads instantly once you finally reach it. Chains also compound risk: every extra hop is another server, another DNS lookup, and another chance for a single broken link in the middle to take down the whole path, even though the two ends still work fine independently.
How redirects interact with query parameters, and therefore with attribution
This is the failure mode that costs real money and is genuinely hard to notice, because the page still loads. A redirect rule written to forward a path (/promo to /landing-page) does not automatically forward whatever query string was attached to the original request, unless the redirect is specifically configured to carry it. If a visitor arrives at /promo?utm_source=instagram&fbclid=abc123 and the redirect rule only knows about the bare path, the destination page loads at /landing-page with nothing after it. The visit still happens. The page still works. What's gone is every piece of information about where the click came from: the UTM tags your analytics groups by, and the click ID (gclid, fbclid, ttclid, msclkid) that an ad platform needs to match this visit back to the ad that generated it and to fire a conversion event. Nothing errors. The report for that campaign just quietly under-counts, and there's no obvious symptom pointing at a redirect rule as the cause. This is exactly why the tool above treats a dropped parameter as a critical finding and names the exact hop where it disappeared, rather than only reporting that the final URL differs from the first one.
Meta refresh and JavaScript redirects are worse
An HTTP redirect (a 3xx status with a Location header) happens before any page content loads at all; it's the fastest and most transparent way to send someone from one URL to another, and it's what every tool, including this one, can actually see and trace. A meta refresh (<meta http-equiv="refresh" content="0;url=...">) and a JavaScript redirect (window.location = "...") both require the browser to load the entire original page first, parse it, and only then act on the instruction to leave. That means slower (there's a real page load in the middle of the redirect, not just a header exchange), and less reliable (a JavaScript redirect does nothing at all if a script is blocked, and a meta refresh depends on the page being interpreted as HTML in the first place). Search engines also treat them with more suspicion by default, historically because both mechanisms were common in the deceptive-redirect and cloaking playbook, forwarding a crawler to different content than a human sees. If a redirect can be an HTTP redirect, it should be. Meta refresh and JavaScript redirects are for the narrow case where the destination genuinely can't be known until code runs in the browser, not a default choice.
What a shortener chain looks like
A link that has passed through more than one shortener, or through an affiliate network's own redirect on top of a shortener, often shows a distinctive shape: three, four, sometimes more hops, each one a different domain, several of them adding or stripping a slightly different set of query parameters along the way. Every extra service in that chain is a place attribution can silently break, and it's exactly the pattern the query-parameter check above is built to catch, since the destination page is often several domains and several redirects removed from wherever the original click ID was set.
Why this tool needs the server hop, and what that means for you
A browser cannot read another site's response headers or follow its redirect chain from client-side JavaScript; that's a deliberate cross-origin restriction, not a bug, and it applies no matter how the request is made. Tracing a redirect chain genuinely requires a server making the requests on your behalf, one hop at a time, checking each destination is safe to fetch before following it there. Unlike the robots.txt tester and the canonical checker, there is no paste-it-instead fallback for this one, since the whole point is seeing hops nobody but a server can observe. If the fetch fails, you'll see exactly that rather than a blank or broken result. If you're checking a link's tracking parameters rather than its redirect path, the link decoder covers what those parameters mean once you have a URL to look at; if you're the one adding UTM tags in the first place, the UTM builder and a quick pass through this tool are worth running together, since a UTM tag built correctly is only as good as the redirect chain that carries it to the landing page. Sub IDs on affiliate links have the exact same fragility, covered in more depth in how to track affiliate links. See all free tools for the rest of the set.