Answer First
Definition: In link analytics, “bot traffic” is any request to a forwarding entry that comes from software rather than from a person clicking: link unfurlers and preview bots, security scanners, uptime monitors, search and AI crawlers, and generic invalid traffic. Because a forwarding entry answers every HTTP request with a redirect, all of these increment its click counter.
Why: It matters because your entry’s access statistics count requests, not people. Teams who read them as headcount end up celebrating phantom spikes or accusing ad platforms of shorting them, when in fact each system is counting a different event. Read correctly, entry statistics are still one of the most trustworthy signals you have: the count is generated the moment a request reaches your own entry, before any landing page loads. The fix is not to hunt for a single “clean” number; it is to learn which parts of the count mean what.
Example: You paste a campaign entry into Slack. Slack’s servers fetch the URL to build a preview card — one or two requests before anyone clicks. A teammate’s phone prefetches the same link in iMessage, adding another. When the email goes out two hours later, your uptime monitor and a security scanner both check the entry. By the end of the day the Console shows 48 clicks, but only 31 correspond to people who actually clicked through. That is not a bug and not fraud — it is the normal composition of a link’s traffic.
Key Facts
- An entry “click” is one request answered with a redirect — anything that fetches the URL counts.
- Link previews produce clicks with zero human clicks behind them. Slack crawls every URL posted in a channel to build a card by reading Open Graph metadata; iMessage, WhatsApp, Discord, Telegram, and the social platforms all do the same.
- Security scanners and uptime monitors form a small but permanent stream, often on fixed schedules around the clock.
- Most bot traffic is not malicious. It is legitimate infrastructure — previews, monitoring, search — doing its job.
- The patterns differ. Real clicks arrive in bursts tied to your own sends; bots arrive steadily, in clusters, or with machine-like timing.
- No two counters agree. Ad platforms, entry statistics, and landing analytics each define “click” differently — never compare raw counts directly.
- Entry stats are a ceiling, not a floor. Read them as “at least N real people, up to M requests.”
Expert Explanation
Who else is “clicking” your entry
Link unfurlers and preview bots. Anywhere a URL is shown as a card — Slack, iMessage, WhatsApp, Telegram, Discord, X, Facebook, LinkedIn, Notion — something fetched that URL first to read its metadata. Slack’s own documentation states that its servers must fetch every URL in a message to determine what kind of content it references, looking for OpenGraph and X Card metadata. Previews are cached, so one share can produce one fetch or several. The fetches often arrive with recognizable user agents: Slackbot, facebookexternalhit, Twitterbot, Applebot.
Security scanners and uptime monitors. Teams point monitoring tools at entries to verify the redirect chain still works, and security tooling probes subdomains for misconfiguration. The result is periodic or steady low-volume traffic, frequently with clearly named user agents. This is a feature, not an attack: your uptime check proves the entry is alive — and it also quietly inflates the counter.
Generic crawlers and invalid traffic. Search engines, AI training crawlers, link checkers, scrapers, and malformed requests from misconfigured tools round out the rest. Some carry a name, some send a bare or empty user agent, and some are spam probes that never load a real page. The common thread: no human is behind the request.
Three signals that separate bots from humans
Burst versus steady. Humans cluster around your distribution: an email at 09:00 produces a burst at 09:01 through 09:15, then a long tail. Bots do not care about your send schedule. A flat, 24/7 trickle on a link that was shared once is almost certainly machines.
Timing. Real clicks spread over seconds and minutes and follow a session. Machine traffic arrives in same-second clusters, at exact intervals, or at 3 a.m. local time. Requests for the same entry in the same second from one source are a strong bot signal.
User-agent clustering. Where your logs surface the user agent, look at the tails of the distribution: many hits sharing one identical string — especially a known crawler name — is the strongest single signal. So is one IP address generating a large share of the total. The caveat: user agents can be spoofed, and some legitimate bots disguise themselves as browsers, so treat these as indicators, not proof.
Practical limits. No universal bot list exists, and no signal is decisive alone. “Burst” only means something against your own baseline. Previews are cached, so one share can generate multiple fetches over days. These heuristics separate “almost certainly real” from “almost certainly not” — they do not produce an exact human count. That is why the honest workflow is to read the entry’s access statistics in the Console, correlate them with the entry logs, and triangulate — no dashboard can hand you a single filtered “real clicks” number.
Why the three numbers will never match
Entry statistics count requests through your redirect — the closest thing to “someone reached the link.” They are the right tool for link health and for comparing periods, because the measurement point never changes.
Ad-platform clicks are counted where the ad served, under the platform’s own click definition, after its own filtering and deduplication. Previews of your entry almost never touch this number, which is why the entry count usually runs higher than the ad count.
Landing-page analytics count sessions and page views after JavaScript loads. Previews and crawlers never run your JavaScript, and visitors who bounce before it executes don’t count either — so landing analytics almost always run lower than entry statistics.
None of this is a defect. If ad clicks outpace entry clicks, the question is not “which number is lying” but where in the chain the discrepancy originates — the same investigation as when ads get clicks but no conversions. And because attribution decisions often depend on cookies surviving the redirect chain, the entry count can never stand in for a conversion attribution system. When the landing page changes between ad approval and campaign, the gap widens further — the click delivers an experience you no longer measured. Read all three as complementary views of the same funnel: entry stats for link health, ad data for spend, landing analytics for experience.
Decision Framework
| Question you are trying to answer | Number to trust | Caveat |
|---|---|---|
| Is the link itself working? | Entry access statistics and logs | Check status and error patterns, not just volume |
| Which campaign or channel drove more demand? | Entry statistics over time, entry compared with itself | Preview inflation affects every entry, so relative comparison still holds |
| Is the ad delivering? | Ad-platform clicks and CTR | That is ad performance, not user behavior |
| Are visitors converting? | Landing-page analytics | Only counts people who actually loaded the page |
| Why do the numbers disagree? | All three, plus the timing of your sends | The mismatch itself is the finding |
Before you report a spike or a mismatch: check the spike time against your own sends; look for repeated or known-bot user agents in the logs; budget for preview fetches whenever a link is shared; compare trends, not raw totals. If you need to defend the numbers in an audit, the entry logs and traceable change history are the evidence trail that makes the counts explainable.
Key Takeaways
- Entry clicks are requests, not people. Treat the total as an upper bound.
- Previews, scanners, and crawlers are normal and mostly harmless — learn their signatures instead of treating them as anomalies.
- Burst versus steady, timing, and user-agent clustering separate real interest from noise.
- Never compare raw counts across ad platform, entry statistics, and landing analytics; they measure different events by design.
- Use entry statistics for link health and direction, ad clicks for spend decisions, and landing analytics for conversion questions.
FAQ
Why does my entry show more clicks than my ad platform reports?
Because the two systems count different events. Entry statistics count every request the entry answers — including preview fetches, monitors, and scanners — while the ad platform counts clicks on the ad creative under its own definition, after its own filtering. Expect the entry count to run higher, and compare trends rather than totals.
Does a link preview count as a click?
In entry statistics, yes: a preview fetch is a request and is counted. But no human clicked it. Previews are cached, so the same shared link can be fetched again when the cache expires or a different platform renders it — one share can appear as several requests.
Is bot traffic a sign that my entry is broken or compromised?
Almost never. Most of it is legitimate infrastructure: link previews, uptime monitors, security scanners, and search crawlers. It becomes worth investigating only when the pattern changes sharply — for example, a steady stream turning into a sudden flood.
Which number should I report to stakeholders?
Report a range and a direction: “at least N real clicks, up to M requests, and the trend is up.” Choose the system that matches the decision you are supporting — entry stats for link health, ad clicks for spend, landing analytics for conversion — and be explicit that the raw counts measure different things.
Sources
- RFC 9110 — HTTP Semantics: the User-Agent header field. https://www.rfc-editor.org/rfc/rfc9110
- MDN Web Docs — Redirections in HTTP (URL forwarding). https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- MDN Web Docs — User-Agent header. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/User-Agent
- Slack — Unfurling links in messages (classic link unfurling). https://api.slack.com/reference/messaging/link-unfurling
- Open Graph protocol — the metadata standard preview bots read. https://ogp.me/