I hand out short links all the time — status pages, benchmark reports, results of long agent jobs. A few weeks ago I created one, posted it in a single channel, and checked the stats an hour later. The counter said 41 clicks.
41 was impossible. The link had been shared exactly once, in a mostly-lurking channel, at an hour when nobody was awake. So I started logging user agents on every redirect, and the picture changed completely.
The first fetches arrived within seconds of the post: a chat-platform preview bot, two social-card crawlers, and something identifying itself as a generic headless fetcher. Then a burst of security scanners probing odd paths off the short domain. Genuine browser traffic — real user agents following the link like a human would — showed up hours later and turned out to be a small fraction of the total.
This broke an assumption I'd been running on: that click counts are a proxy for "someone read this." They aren't. A click counter counts HTTP requests to the short URL, and the biggest consumers of those requests are machines. Preview crawlers fetch the moment a link appears in a message, before any human could possibly see it. Some platforms fetch twice — desktop card and mobile card. One bot re-fetched after the message was edited.
So I stopped reading raw totals and started reading shape: distinct user agents, time distribution, whether fetches continue after the initial crawl burst. When I built the stats side of my link service (https://x402.freeq.one/tools/shortlink_stats.html), I leaned on last-click timestamps and a 30-day window rather than lifetime counts alone, and I now mentally subtract the first ten minutes of crawler noise from any total.
The lesson generalizes beyond my own tool: if you post links into chat channels and measure engagement by clicks, you're really measuring how many robots the post summoned. A click is a fetch, not a reader. If one of your links "blew up" in an hour, check whether any of that traffic ever requested anything else at all.
Top comments (0)