Published September 2, 2026

The clicks that arrive before anyone clicks

A link pasted into a chat or an email collects requests within seconds, from preview crawlers, mail scanners and browser prefetch. Why a shortener sees them, and how each one is reported with its reason.

A link is pasted into a group chat and has clicks before anyone in the chat has looked at it. The natural first thought is that the counter is wrong. It is not: those requests really happened, and something really fetched the address.

Sample data from a demonstration workspace.

Why the shortener is the first thing anything touches

A short link is not a pointer to a URL. It is a URL. Anything that decides to fetch it, for any reason, sends a real request to the redirect, and the redirect has to answer before it knows who is asking.

That puts a shortener in front of a class of traffic a script on the destination page rarely sees at all. Three sources produce most of it.

The preview card. Chat and social applications fetch a shared address to build the little card with a title and an image. That fetch happens when the message is sent or displayed, not when anyone taps it, and in a group it can happen once per client.

The mail gateway. Corporate mail filtering opens links to check where they lead before allowing the message through. A campaign sent to a company can therefore collect a request per recipient with nobody having read anything yet.

Browser prefetch. Browsers fetch pages ahead of an actual click, on hover or when preloading a likely result. These come from an ordinary browser and would otherwise be indistinguishable from a person, except that the browser says so in the request itself.

What the report says about each one

None of these are counted as clicks here, and none of them are silently dropped either. Each is filed under a reason the dashboard prints by name.

Known crawler. Anything that identifies itself as a bot in its user agent, which most preview crawlers and monitors do.

Link prefetch. Detected from the request headers a browser sends to declare that a fetch is speculative rather than requested.

No user agent. A request with no user agent header at all, which essentially never comes from a browser with a person in front of it.

The filtered total sits beside the unfiltered one rather than being quietly subtracted from it. That is the part worth checking: a number that has been reduced without saying so is indistinguishable from a number that was small to begin with.

A fourth reason, traffic from datacenter address ranges, exists in the product's vocabulary and is not being applied today. It is mentioned here because it appears on the methodology page, not because it is filtering anything.

Specific crawler names are deliberately absent from this post. The classification is by behaviour, not by a list of applications, and a list published today would be wrong within a quarter.

What to do with a share that looks high

A filtered share is not a problem to fix. It is a property of the channel, and it is worth reading as one.

A link sent by email to corporate recipients will show a large share of filtered traffic, and a link sent to consumer mailboxes far less. A link posted in several group chats collects preview fetches proportional to the number of clients that rendered it, not to the number of people who read it. A link on a page that search engines index keeps collecting crawler traffic for as long as it is there.

The number worth trusting is the one after filtering, and the number worth watching is the ratio between them over time. A ratio that jumps for a link that has not moved is a signal about where the link ended up.

Why the destination's analytics disagrees

Almost none of this reaches a script on the destination page. Preview crawlers and mail scanners do not run JavaScript, and prefetch usually never becomes a rendered page.

That is one of the reasons a shortener's raw number is larger than a session count on the destination, and it is the reason the filtered breakdown exists at all: without it, the two numbers would differ with no way to say why. The full accounting is in the reconciliation post, and the counting rules themselves are on the methodology page.

All posts