Fediverse referrer traffic (decentralised social)
The fediverse microblogging network is decentralised: there is no single canonical host, but thousands of independent instances, each on its own domain. Web reads commonly pass that instance's domain as the referrer, so this traffic is often identifiable yet spread across many hosts. Recognising the federation pattern is key to attributing it.
Federation means many referrer domains
The fediverse microblogging network is not one website; it is a protocol implemented by many independent instances, each on its own domain. A user reading on one instance who clicks your link generally sends that instance's domain as the referrer.
So unlike a centralised platform, this traffic does not arrive under a single host. It appears as a scattering of instance domains, which can be undercounted if each is treated as an obscure one-off rather than part of one federated channel.
- No single host — thousands of independent instances
- Referrer is usually the user's instance domain
- Web reads often do pass a referrer
Attributing fediverse traffic
Because the fediverse often does send a referrer, much of its traffic is identifiable if you recognise instance domains and group them. For links you post yourself, add a utm_source for the network and a utm_medium such as social so attribution does not depend on recognising every instance. MDN documents when the referrer is sent.
How it appears in analytics and logs
A fediverse visit typically carries the referrer of the specific instance the user was on — for example a community server's own domain — not a single canonical host. Many small instance referrers can together represent one channel.
Diagnostic use case
Recognise that fediverse referrers arrive as many different instance domains rather than one, and group them when attributing the channel.
What WebmasterID can help detect
WebmasterID records the referrer when sent. Because the fediverse spans many instance domains, grouping them into one channel — rather than treating each instance as an unrelated source — is what makes the traffic legible.
Common mistakes
- Treating each fediverse instance domain as an unrelated obscure source.
- Assuming there is a single canonical host referrer to match on.
- Putting personal data in UTM parameters.
Privacy and accuracy notes
The referrer is browser-controlled; an instance domain is a source signal, not visitor identity. WebmasterID reads the referrer when present and never re-identifies a visitor when it is missing.
Related pages
- Bluesky referrer traffic
Bluesky is a growing social network whose primary web client lives at bsky.app. Links clicked from the web commonly pass a bsky.app referrer, so Bluesky traffic is often identifiable. As with any platform, app and client contexts can reduce the referrer, so UTM tags keep attribution consistent.
- Unknown referrer: causes and handling
Unknown referrer describes the case where a referrer is present but cannot be matched to a known source — it may be malformed, from an obscure domain, or a value the normaliser does not recognise. The honest approach is to bucket it as unknown rather than force-fit it to a familiar channel.
- Website observability
Inspect raw instance-domain referrers so federated traffic is not buried as unknown.
Sources and verification notes
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.