Checking redirects
Between the link someone clicks and the page that appears there are often several stations. The browser only shows the last one.
How chains grow without anyone noticing
Hardly any chain is built on purpose. It grows because every change leaves another rule behind:
- The site moves from
httptohttps– one redirect. - Then from
wwwto the bare domain – the second. - A relaunch changes the URL structure – the third.
- An affiliate or shortening service is put in front – the fourth.
- The target shop forwards to its country version – the fifth.
Every step is right on its own. Together they form a detour nobody designed and nobody sees in daily use.
Why this is more than untidy
It costs time. Every hop is a separate request including name resolution and TLS handshake. On a mobile network that adds up noticeably before a single byte of the actual page arrives.
It costs clarity. Search engines do follow chains, but every additional station makes it less certain which address ends up counting as the authoritative one.
And it breaks quietly. If a station in the middle disappears – a discontinued shortening service, a deleted rule – the link is dead even though start and destination both work perfectly. Checking only the destination never finds it.
The cases you have to see individually
The loop
A points to B, B points back to A. Browsers give up after a few rounds with an error, search engines abandon the address. Typical cause: one rule enforces www, a second enforces the opposite.
The changed request method
With 301 and 302, browsers are allowed to turn a submitted form (POST) into a plain fetch (GET) along the way – the entered data is then gone. To prevent that, use 307 or 308: what the codes mean in detail.
The silent jump into nothing
Some chains do not end at the expected page but on a home page or an error page that still reports 200. To a search engine that looks like a valid result. Only comparing the requested and the final address reveals it.
Different answers for different visitors
Not everyone is redirected the same way. Some servers send mobile devices somewhere else than desktop browsers, and search engine bots somewhere else again. What looks clean in your own browser can be an entirely different chain for Googlebot.
Redirects that are not in the header
The classic redirect is a response with a 3xx code and a Location field in the header. Not every detour looks like that. Interstitials, consent bridges and the intermediate pages of affiliate networks regularly answer with a friendly 200 – and only then send the visitor onwards. Read headers alone and you mistake such a waypoint for the destination.
Meta refresh
The document head then carries a line like <meta http-equiv="refresh" content="0; url=…">. Browsers follow it; search engines treat it as a weak signal at best – it is no substitute for a 301, because neither permanence nor target are declared unambiguously. Rarer, but just as effective: the same instruction as a Refresh header.
LinkSniffer follows both like any ordinary hop. The station in the chain is labelled meta refresh or refresh header, so you can see that this step did not come from the header.
Jumps made by JavaScript
The third variant lives in the script: location.replace(…), location.href = … and their relatives. To a visitor this is a redirect like any other. Technically it is not – there is no status code, no target in the header, nothing a plain request could follow.
Here LinkSniffer deliberately shows less. Such targets are found in the page source and reported separately – but not followed. We do not execute JavaScript; whether a browser really goes there depends on conditions that only exist at runtime (consent, device, timing). Listing such a find as a station in the chain would be a claim, not a measurement. So it stands beside the chain as a note, and it does not count towards the domains involved.
In practice: if a chain ends on an intermediate page and a script target is reported below it, that is exactly the next step worth checking by hand.
How to make the chain visible
The browser is little help here: it follows every hop and shows only the result. LinkSniffer walks the chain step by step instead and records each hop with its own status code – up to 20 stations.
Every station is shown with its complete address, path and all parameters included. That is not a detail: whether a campaign tag gets lost on the way, which target hides inside a return= parameter, and which identifiers an affiliate station appends – you can only see that from the whole address, never from the hostname alone. Below it, the domains involved are listed in order.
You can also choose what to ask as: desktop browser, mobile device or Googlebot. That is exactly where it shows whether a redirect works the same way for everyone.