Referrers from PDF viewers
When a reader clicks a link inside a PDF, the originating context is a document viewer, not a web page, so the click commonly arrives with no Referer or an opaque one. Native readers, in-app viewers, and downloaded files all behave differently, which is why links inside PDFs need UTM tags to stay attributable.
What this means
PDFs are opened in many contexts: a browser's built-in viewer, a desktop reader, a mobile app, or a downloaded file on disk. When a reader clicks a hyperlink inside the document, the navigation does not originate from a web page, so most viewers send no Referer or an opaque one.
The consequence is that clicks from a whitepaper, brochure, or report you distributed tend to appear as direct or unknown traffic, even though they came from a specific document.
Recovering document clicks with UTM
Because the Referer is unreliable from a PDF viewer, the embedded link itself must carry the attribution. Add UTM parameters such as utm_source and utm_medium=pdf (and a utm_campaign naming the document) to every outbound link before you publish or distribute the file.
With tagged links, WebmasterID can separate document-driven visits from genuine direct traffic and measure how a specific PDF performs, regardless of which viewer opened it.
- PDF-viewer clicks usually send no usable Referer
- Recommended tags: utm_medium=pdf, with source and campaign
- Tag links before publishing the file — you cannot fix it after
How it appears in analytics and logs
A click from a link inside a PDF usually carries no usable Referer because the viewer is not a referring web page. Such visits fall into direct or unknown traffic unless the embedded link carries its own attribution.
Diagnostic use case
Explain why clicks from links embedded in PDFs land in direct or unknown traffic, and recover them with campaign tags so document-driven visits are attributable.
What WebmasterID can help detect
WebmasterID reconciles UTM-tagged links from your PDFs against the direct/unknown bucket, so document-driven clicks are attributed to the document rather than lost as anonymous direct traffic.
Common mistakes
- Assuming PDF clicks will show a referrer the way web-page links do.
- Distributing a PDF with untagged links, so every click lands in direct traffic.
- Reading a direct-traffic bump after a PDF launch as organic rather than document-driven.
Privacy and accuracy notes
This concerns only the Referer header and any UTM parameters on the embedded link. No visitor is identified. WebmasterID records the channel, not the person.
Related pages
- Direct traffic: what it really means
Direct traffic is the bucket analytics uses when no referrer is available. It includes genuine type-ins and bookmarks, but also a large share of visits whose referrer was stripped — app opens, HTTPS-to-HTTP transitions, shorteners, and privacy settings. Treating 'direct' as a single intent is the classic analytics mistake.
- Referrer-Policy and missing referrers
Referrer-Policy is the web standard that controls how much of the referrer a browser sends with a request. Site owners set it via an HTTP header or a meta tag, and modern browsers default to a privacy-leaning value. Understanding the policy values explains why so many referrers arrive trimmed to the origin or missing entirely.
- SSRN referrer traffic
SSRN is a repository of working papers and preprints, especially in social sciences, economics, and law. Links from an abstract page, author page, or download page can appear as ssrn.com referrals, but referrer-policy downgrades and download-redirect flows often collapse the originating page, so UTM tags keep the traffic attributable.
- Campaign links
Tag links inside PDFs so document clicks are attributable.
Sources and verification notes
- MDN — Referer headerThe Referer reflects a referring web page; PDF viewers are not such a context.
- MDN — Referrer-Policy
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.