Link Preview Bots: What Each Platform Fetches Per Share

You pasted one short link into one Slack channel, made a coffee, and came back to a counter that reads eleven. Nobody opened it. If you run campaigns, answer support tickets or reconcile clicks against sessions, this is the first surprise every link tracker hands you, and the cause is mundane: the platform fetched your URL to draw the preview card, sometimes from more than one service, before any person decided anything.

This page is the reference for that behaviour, platform by platform, from what the platforms publish themselves. Verified on Sep 10, 2026. Where a company documents timing, caching or a per URL frequency, it is quoted and linked. Where it documents nothing, this page says so, because the web is full of confident fetch counts with no source behind them. For the population question, what share of all short link traffic is automated, see the companion piece on the bot share of short link clicks.

What an unfurl actually is

An unfurl is Slack's word for it; other platforms say preview, card or embed. It is the title, description and image under a pasted link, and building it means requesting your URL, parsing the markup, and usually requesting the image as a second round trip. On a short link that first request lands on the redirect, which is why your shortener sees it before your site does. What the card looks like is an Open Graph question for the Open Graph checker or custom link previews. This page is about the traffic, not the tags.

Why a share alone moves the counter

A redirect is a request like any other: a GET, a 302, a destination. Unless the shortener inspects it and declines to count it, a preview fetch looks exactly like a visit, which is why Flyn's analytics carry a human number and a filtered number side by side. The wider category of traffic that inflates raw counters sits in the click fraud prevention guide; the trigger here is narrower and far more innocent.

Tap to enlarge

This is the table to cite. The last two columns come from each platform's own documentation, linked in the sections below. Note what is missing: not one of these thirteen platforms publishes a fetch count at all, and most publish no cache duration either.

Tap to enlarge

How to read the last column

Read it as a hard limit on what anyone can honestly claim. "Not published" does not mean the fetch does not happen; it means nobody committed to a number, so your own logs are the only authority for your own link. Three gaps deserve naming, because folklore fills them: what a re-share costs, whether every viewer or only the first triggers a media request, and why some fetches arrive from a phone.

In chat, the fetch often happens before you press send. That one fact explains most confused support tickets, because the person reporting mystery traffic had not actually shared the link yet.

Slack

Slack is the only platform here that publishes anything like a rate. Its robot user agents page names three agents: Slackbot-LinkExpanding 1.0 fetches the page for oEmbed, Twitter Card and Open Graph metadata and downloads associated media to validate it, Slack-ImgProxy 0.19 fetches and caches images posted in channels, and Slackbot 1.0 handles everything else. Slack says responses are cached globally for around 30 minutes, that you should not see more than one request per URL in that window, and that it does not currently honor robots.txt. Expect metadata traffic plus separate image traffic per share; the Slack link shortener page covers sharing.

Microsoft Teams

Microsoft documents the trigger rather than the agent. The Teams docs on link unfurling describe an app receiving an invoke activity when URLs are pasted into the compose message area, state that the unfurl result is cached for 30 minutes, and give apps an opt out through a no cache policy. Teams still builds a card for ordinary links with no app involved, but Microsoft publishes neither the user agent nor a request count. Treat Teams as: fetch on paste, 30 minute cache, count unknown.

WhatsApp

Meta's link previews documentation is the most specific messaging source about the request itself. It documents a WhatsApp/2.x.x.x User Agent followed by A, I or N for Android, iOS or web, and an Accept Language header reflecting the recipient's language. Instead of counts you get limits: the head must sit within the first 300KB of HTML, images should be under 600KB, and if no preview appears above the composer after 10 seconds something is wrong. Meta does not say whether the phone or a Meta server sends the request, which matters because it decides whose IP address lands in your log. The OpenGraph plus write up on how WhatsApp crawls URLs reports that previews are generated server side on Meta infrastructure rather than on the sender's device, and that fetching begins as the user types. That is third party observation rather than a Meta commitment, and it contradicts a good deal of forum folklore, so treat it as the best available answer rather than the final one. The WhatsApp link shortener page is the companion.

Telegram and Discord

Neither company publishes a crawler page, and the nearest thing to a Discord statement sits in a thread that has since moved on. The discussion in Discord's api docs repository was opened in August 2023 because image fetches were arriving with a Firefox 92 user agent, and a Discord engineer answered by restating the policy: crawling a URL is done as a bot, but proxying an image is done in response to a user loading that image, so the request carries a user agent of a user and not a bot. Discord named no browser string itself. What matters is the rest of the thread. On 31 December 2024 the person who opened it retested and reported the image being fetched as Mozilla/5.0 (compatible; Discordbot/2.0; +https://discordapp.com) after all, three times for the one share, and in May 2025 another commenter reported the browser style string surviving on the video proxy rather than the image proxy. So the policy dates from 2023, images were reported labelled from the end of 2024, and an unlabelled media fetch is a live risk with a moving target rather than a fixed fact. Both retests are single observations by individual developers, not Discord commitments and not published counts. Telegram publishes nothing; the token commonly seen in logs is TelegramBot, which is what Flyn's screening list carries, but Telegram has never documented it, so treat the string as convention rather than contract. Sharing mechanics live on the Telegram and Discord pages.

Apple Messages and Google's apps

Apple documents Applebot as the crawler behind Spotlight, Siri and Safari, says that when robots instructions mention Googlebot but not Applebot it follows the Googlebot rules, and states that it does not follow crawl delay. Apple documents iMessage link previews nowhere. What is well attested outside Apple, from Siggi Simonarson's write up on iMessage impersonating Twitter and Facebook bots onward, is that the preview is fetched by the device and that the request carries both the facebookexternalhit/1.1 and Twitterbot/1.0 tokens instead of an Apple one. Google is split. It publishes user triggered fetchers including GoogleMessages, noting that because a user requested the fetch, those fetchers generally ignore robots.txt rules. Google Chat previews are documented nowhere public. No count for either.

A preview fetch is not fraud and it is not a bug. It is the platform doing its job at a moment you did not choose, on a counter that was never built to tell the difference.

Tap to enlarge

On social networks the fetch is tied to composing or publishing, and the crawlers are easier to name because the companies want you to allow them.

Tap to enlarge

Meta: Facebook, Instagram, Messenger

Meta's web crawlers page lists the exact strings, each with and without a URL comment: facebookexternalhit/1.1, meta-externalagent/1.1, meta-externalfetcher/1.1, meta-webindexer/1.1 and meta-externalads/1.1, and it asks for up to 24 hours for a robots.txt change to take effect. Note what is missing: Facebot, the legacy string still carried in most filter lists including Flyn's, is not on Meta's page any more. The sharing crawler page says FacebookExternalHit crawls content shared on Meta's family of apps, warns that content must be crawlable within a few seconds, and explains how to force a fresh crawl with the Sharing Debugger or the Sharing API. Neither page publishes a count per share or a cache lifetime, so the widely repeated "Facebook re-scrapes every thirty days" claim is not attributable to Meta today. Forcing a re-crawl is the usual fix after you repoint a Facebook campaign link.

X

X documented the bot and the robots.txt contract, not the volume, and has since taken the page down. Its Cards getting started guide stated that the crawler identifies as Twitterbot with a version, that it respects the robots.txt specification, that a blocked page yields no card and a blocked image no thumbnail, and it gave example robots.txt rules for allowing Twitterbot. It also stated that content is cached for 7 days after a link is posted, which is the third cache window on this page. Checked on Sep 10, 2026, the old developer.x.com URL redirects to the X docs home and the guide is not in the current documentation, so the reference here is the archived copy from 1 January 2026, the last capture with the content. No fetch count either way; the X link shortener page covers posting.

LinkedIn

LinkedIn's help article on making content shareable documents the four Open Graph tags and the image sizes it wants, and nothing else: no user agent, no cache duration, no count. LinkedInBot is the token seen in logs, and Post Inspector forces a fresh read when a preview is wrong. Treat any specific LinkedIn fetch count you read elsewhere as somebody's measurement, not LinkedIn's statement; the LinkedIn link shortener page covers posting.

Pinterest, Reddit and the reference card

Pinterest is forthcoming about politeness and silent about volume. Its crawler help page documents Pinterest/0.2 and Pinterestbot/1.0, says the bot scrapes the pages behind Pins when people create them and also crawls proactively to index content, states that it rate limits concurrent requests, says it honors crawl delay values up to 1 and treats anything larger as 1, and warns that it does not support robots.txt files on subdomains. Reddit publishes no crawler page at all; redditbot is the token seen on submission, by convention rather than by documentation. Both have sharing notes on the Pinterest and Reddit pages. Here is the whole set in one card.

This is what decides your dashboard. A shortener sees a bare HTTP request and must judge, before it issues the redirect, whether a person is behind it.

Tap to enlarge

Screening by user agent, and only that

Flyn screens by user agent pattern. Requests matching a known crawler, link preview fetcher, headless browser, HTTP client library or uptime monitor, and requests with a blank user agent, are excluded from click analytics before counting and tallied separately as the filtered number for that link. The list covers the unfurlers named above, the search and AI crawlers (Googlebot, bingbot, redditbot, DuckDuckBot, YandexBot, Baiduspider and the rest), and the generic bot, crawler and spider conventions for the long tail. One signal, read per request, nothing stored per hit. For the vendor question, see the bot filtering comparison.

What screening cannot see, and what you can

Three limits bound every number here and in your dashboard. First, a fetcher that sends a normal browser user agent is invisible and lands in your human count for ever. Discord stated that policy for proxied media in August 2023, and the latest report in that same thread, from May 2025, puts the browser style string on its video proxy while images were reported labelled as Discordbot from December 2024, so treat this as a live risk with a moving target rather than a fixed example. Second, a token with no bot substring in it slips past generic pattern matching, which is the shape of Slack-ImgProxy, meta-externalfetcher, meta-webindexer and meta-externalads, so an explicit list of names beats a clever regular expression. Third, a human on a niche browser whose user agent happens to contain a flagged token gets screened out, the opposite error. Apple Messages, for once, is the easy case: it arrives from a consumer IP that would defeat any network based filter, wearing borrowed tokens that a user agent list catches anyway. Every plan does give you the human count and the filtered count per link, which is what verified human clicks and bot filtered analytics describe. What you do not get is a breakdown: the user agent of each filtered hit is not stored, so the dashboard can say thirty one automated hits arrived and cannot say eleven of them were Slack.

Since the platforms publish no counts, the only trustworthy number is the one you collect on a link nobody else has touched. This is the long version of the quick paste test in the filtering comparison, and it returns named families rather than a yes or no.

Tap to enlarge

The eight steps

1. Build a capture endpoint that logs per request: timestamp to the second, method, path, User Agent, Accept, Accept Language, Range and the client IP class. Return a tiny page with one image on the same host, so you can see whether the platform came back for media.
2. Give each platform its own path and its own fresh short link, so every log line is self identifying without a referrer. See creating a link, or the API shorten endpoint to script it.
3. Start logging before you touch the compose box, because WhatsApp and Teams fetch while you type or paste.
4. Paste each link exactly once, into one private channel or a one to one chat, and do not click it.
5. Write down the wall clock time of each paste, since log timestamps only mean something relative to the share.
6. Wait 24 hours, then group the log lines by user agent family, count them per link, and mark which families asked for the image too.
7. Read both counters per link, in the dashboard or through the API clicks endpoint and links endpoint, then reconcile: filtered plus human should roughly match your log lines. A gap on the human side is the interesting result, because something fetched your link wearing a user agent no filter would flag.
8. Re-read at seven days for late search crawlers, then archive the raw log with its date.

Each of these has sent somebody down a wrong path, usually towards accusing a platform of something it did not do.

• Caches hide the second fetch. Slack and Teams both document about 30 minutes. Paste the same URL twice inside that window and you measured a cache, not a platform. Use a fresh link per test.
• Pre send fetches break your timeline. Teams unfurls on paste, and WhatsApp previews render above the composer. Start your log at send and you will conclude nothing happened.
• Images are separate requests, and may not look automated. Most platforms fetch the image after the HTML, so one share is often two lines from one company, and Discord's stated policy is that proxied media carries a user agent of a user rather than a bot.
• Your own tooling shows up. Uptime monitors, a teammate pasting the link into a ticket and your own QA sweep all arrive as automated hits. A bulk health check looks like a bot wave the next morning.
• Platforms change without telling you. Meta has added crawler names, Slack changed its robots.txt stance, and X took its Cards guide offline between January and March 2026. Re-run the rig quarterly and date stamp what you find.

The point is not a trivia table. It is reporting that survives somebody asking how many real people clicked.

Tap to enlarge

Report the human number, show the filtered one

Keep both numbers visible. A campaign that looks flat with a large filtered number is usually a link pasted around internally, and assistant traffic needs the same discipline, which the ChatGPT referral post covers. Small links look worst, because a fixed automated cost dominates a tiny sample, so compare links of similar size using the click tracking guide, the link click counter and the unique versus total clicks definition. If a campaign lives in chat apps, use one link per channel so the filtered count tells you which surface produced it: bulk shortening makes that cheap, the per link split is on every plan, and deeper analytics and routing sit on Pro. When the card is wrong rather than the count, customising the link preview is the fix, and clicks not showing is the support article for a counter that looks stuck.

One honest sentence about this page: Flyn counts preview bot hits but does not store the user agent of each hit, so there are no Flyn measured per platform counts here. Every timing, cache window and user agent above is the platform's own statement, verified on Sep 10, 2026, with one exception flagged in place: X's Cards guide has been taken offline, so it is quoted from an archived copy. Where a platform publishes nothing this page says so instead of filling the gap. This is a technical reference, not legal advice; if you need to know what a preview fetch means for privacy or consent in your jurisdiction, ask a qualified professional.