The instant version of this shows up constantly in link analytics: a link goes out, and a click is logged before there has been enough time for a human to read the message, let alone tap it. That is not a broken tracker. It is a machine fetching the URL for its own reasons, and it happens by two genuinely different mechanisms that get lumped together because they produce the same symptom.
Two different things called prefetching
Browser prefetching is a speed optimization built into modern browsers. Chrome, for example, can speculatively load a page it predicts you are about to visit, using signals like hovering over a link or a rel="prefetch" hint in the page's own HTML, so the next page feels instant when you actually click. This happens client side, inside the visitor's own browser, and it is aimed at the visitor's next click, not the current one.
Link preview bots, sometimes called unfurl bots, are a completely different mechanism. When a URL is pasted into iMessage, WhatsApp, Slack, Discord, or a Facebook or X post, that platform's own server fetches the link in the background, right then, to pull a title, description, and image and build a rich preview card. This happens on the platform's servers, not the recipient's device, and it happens the moment the link is shared, not when someone in the conversation eventually opens it. This explains most of the confusion around getting a click seconds after posting a link, and on a tracked link it is usually the bigger source of the two.
Both processes touch the URL before a human does. Neither one is a lie or a tracking failure (though it can feel like one when a click lands while you're still typing the caption). But if your analytics count every request to the link as a click, both get counted as a real visitor when neither is one.
The three shapes browser prefetching takes
Browser side prefetching is not one setting, it is a small family of hints a page or browser can use, and they behave differently enough to matter if you are trying to explain an odd request in a server log.
rel="preconnect"just opens the network connection early, DNS lookup and handshake, without requesting any content. It shows up as connection activity, not a page hit.rel="prefetch"asks the browser to fetch and cache a specific resource in the background because the current page thinks you are likely to need it next. This does register as a real request to the URL.rel="prerender", and its modern successor speculation rules, goes further and renders the entire next page in a hidden tab, ready to swap in instantly if you click. Safari and Chrome both support versions of this for search results and predicted navigations.
All three exist purely to make browsing feel faster. None of them target your link out of personal interest. They're tuned to whatever the browser predicts a typical visitor does next, which is a meaningfully different thing than someone reading your content and choosing to act on it.
What each common unfurl bot actually does
Not every preview bot behaves the same way, and the differences affect what shows up in your click log.
| Platform | Fetches on paste or on send | Follows redirects | What it typically pulls |
|---|---|---|---|
| iMessage | On send, from the sender's device and again from the recipient's | Yes | Title, description, image (og tags) |
| On send, server side | Yes | Title, description, image (og tags) | |
| Slack | On send, server side, and again if the message is edited | Yes | Full unfurl, can include page title and favicon |
| Discord | On send, server side | Yes | Title, description, image (og tags) |
| Facebook Messenger and Facebook posts | On paste, before the post is even published | Yes | Title, description, image, sometimes re-fetched on each view |
| X (Twitter) | On send, server side (Twitterbot user agent) | Yes | Card metadata, title, image |
The pattern across all of them is the same: server side, near-instant, and every single one follows redirects, which means a link that passes through a redirect on the way to its destination gets logged as a hit at every one of those platforms, regardless of whether a single human ever opens the message.
Does prefetching count as a real click
Not in any useful sense. Nobody chose to visit anything, a server fetched some metadata to render a card. The trouble is that most click trackers cannot easily tell the difference between that fetch and a genuine tap, because both arrive as an ordinary HTTP request to the same URL. The strongest tell is timing, covered in more depth in how to tell if clicks are real: a request landing one to three seconds after a link is shared is a preview fetch, not a person reading a message and deciding to act on it.
This is part of the broader problem of bot traffic, but it deserves its own name because it is not adversarial. Nobody built an unfurl bot to trick you. It exists to make chat apps and social feeds show a nice looking card, and the side effect on click counts is incidental.
What to actually do about it
You cannot stop platforms from prefetching your links, that behavior lives entirely on their side, not yours. What you can do is stop treating every logged hit as a person. Look at unique clicks against total clicks rather than the raw total, check the referrer on early hits, since a preview fetch from Slack or Discord usually arrives with that platform's bot user agent rather than a normal browser referrer, and treat any click in the first few seconds after posting as suspect by default. A link tracker that logs referrer and timestamp on every single click, which is what happens on every raydar.bio link, gives you enough to separate the fetch from the tap without needing to guess.
One more practical wrinkle worth planning around: prefetching is a reason a click count on a freshly posted link can look inflated compared to how the link actually performs over the following hours and days. If you are judging a post's real pull in the first minute after publishing, you are mostly measuring unfurl bots, not your audience. Waiting even an hour before reading too much into an early number filters out most of this noise on its own, and it does not take any special tooling to do it.