Why Preview and Screenshot Fetchers Trip Filters

Whenever a link is shared in a message or post, something fetches the page to build a preview. That fetch is legitimate, unavoidable and almost perfectly shaped to trigger automation filters.

The fetch happens without a user

A preview is generated when the link is posted, not when someone clicks it. The request therefore arrives with no preceding navigation and no interaction of any kind.

The session ends after the page and a few assets are retrieved. There is no scrolling, no pointer movement, no second page and no return visit.

These are the defining characteristics of an automated fetch, because that is exactly what it is. The distinction is intent rather than mechanism.

Modern fetchers run real browser engines

Simple metadata extraction stopped working once pages began rendering their content with scripts, so preview services moved to headless browsers that execute the page fully.

That makes their environment signals look like a genuine browser, which removes the easy checks while leaving the behavioural pattern unchanged.

They also arrive from hosting infrastructure, since they run in the platform's own datacentres, so infrastructure classification places them in the suspicious category.

Volume arrives in unhelpful shapes

A widely shared link generates a burst of near-simultaneous requests from many addresses belonging to the same organisation, which resembles a coordinated fetch.

Preview caches expire, so the same content is fetched repeatedly over time from different nodes without any human activity in between.

Rate limits keyed to address ranges are triggered by ordinary sharing activity, and the failure is silent: the preview simply does not appear.

Blocking them has visible costs

A link that renders without a title or image performs substantially worse when shared, so blocking preview fetchers directly reduces the traffic a site receives.

The failure is also hard to diagnose from the publisher's side, since nothing in the site's own logs indicates that a preview attempt was refused rather than never made.

This makes preview fetchers one of the clearer cases where correct classification has a direct commercial consequence rather than only a technical one.

Identification relies on published infrastructure

Major platforms document the identifiers their fetchers use and publish the address ranges they operate from, which allows verification rather than trust.

Verification by reverse lookup against the operator's own records is the standard approach, since any client can claim an identifier and only the address is difficult to forge.

Smaller platforms often publish nothing, which leaves sites choosing between accepting unverifiable claims and losing previews on those services. Most accept the claim while keeping the traffic rate-limited.