Why I Even Ran This Experiment
June 2025. I had just finished watching three separate client sites take hits from yet another Google core update, and I was in the particular kind of bad mood that makes you start doing things you'd normally consider too time-consuming to justify. So I opened a spreadsheet, set up UTM parameters across Bluesky and Mastodon, and decided I was going to track every referral, every crawl pattern I could observe, and every weird signal that might or might not connect back to organic search performance. For eleven months. Without stopping.
The results are not what I expected. Bluesky sent 4,847 sessions per month at the experiment's peak, a number that kept climbing in ways that made me question my analytics setup twice. Mastodon sent 218. These two figures sat next to each other in my reports every single month and I kept expecting them to converge. They didn't.
This article is about what I learned from that discrepancy, why neither number means what you'd first assume, and what the actual SEO-adjacent value of these two networks looks like when you track it properly instead of just vibing.
If you want the short version: Bluesky is an interesting referral channel that may or may not have future indexing implications, Mastodon is a tiny traffic source with disproportionately strong link verification utility, and both of them are being dramatically underestimated and overestimated simultaneously by different camps in the SEO community.
Setup: What I Tracked and How
Before the numbers mean anything, you need to understand what I was measuring. I ran this across four properties: a personal blog (domain authority roughly 40-ish, mostly tech and marketing content), a client SaaS site in the project management niche, a niche affiliate site covering outdoor gear, and a small media site that publishes around 15 pieces a month.
Each property got its own Bluesky handle and its own Mastodon account, chosen deliberately on different instances. The blog was on mastodon.social. The SaaS client was on fosstodon.org (relevant community, as it turned out). The affiliate site was on techhub.social. The media site went on hachyderm.io. Instance selection was itself a variable I wanted to track.
UTM parameters were consistent across all four: utm_source=bluesky or utm_source=mastodon, utm_medium=social, with utm_campaign varying by content type (utm_campaign=longform, utm_campaign=thread, utm_campaign=link). GA4 with enhanced measurement, plus server-side session counts to catch the people who blocked JavaScript.
Beyond direct referral traffic, I also tracked: crawl frequency changes using server logs after posting (specifically looking at Googlebot and other significant crawlers in the 48-72 hour window after posting links), any detectable correlation between post engagement and organic ranking movement for target keywords, and the presence or absence of Bluesky/Mastodon URLs in the backlink profiles of the tracked sites using Ahrefs monthly snapshots.
I did not track brand search volume correlations carefully enough in months one and two. That was the mistake I'll get to later.
The Bluesky Numbers Are Stranger Than They Look
4,847 sessions per month sounds like Bluesky is some kind of SEO goldmine. It is not. Let me complicate this immediately.
The sessions are heavily concentrated. About 71% of those sessions came from a single post on the personal blog account, a thread about GA4 sampling that got picked up by two accounts with combined follower counts north of 80,000. Remove that outlier behavior and the monthly average for the personal blog drops to around 340 sessions. Still not nothing, but a very different story.
The SaaS client, posting consistently at roughly the same frequency and with similar content quality, averaged 89 sessions per month from Bluesky. The outdoor affiliate site averaged 51. The media site, despite having the most consistent posting schedule, averaged 127.
What distinguishes high-performing Bluesky posts isn't what you'd expect if you're approaching this from a Twitter-era mindset. Engagement bait doesn't work the way it used to. What actually drove referral traffic was posts that contained a substantive excerpt, not just a headline and link. Longer posts that showed genuine understanding of the topic performed measurably better than shorter hook-style posts in terms of click-through to the linked content.
The network's custom feed infrastructure also plays a role that's easy to miss if you're just measuring your follower count's behavior.
ATProto Basics That Matter for SEO
Bluesky runs on the AT Protocol, and understanding its architecture changes how you think about link distribution on the platform. The protocol is public by design. Every post, every like, every repost is written to a personal data server (PDS) and federated through a relay infrastructure. The full firehose of public posts is accessible to anyone who wants to crawl it.
# Querying your own PDS for post records via the AT Protocol API
# This shows how your posts exist as structured, publicly crawlable data
curl "https://bsky.social/xrpc/com.atproto.repo.listRecords?repo=YOUR_DID&collection=app.bsky.feed.post&limit=50" \
-H "Accept: application/json"
# Response structure (simplified):
# {
# "records": [
# {
# "uri": "at://did:plc:xxxx/app.bsky.feed.post/yyyy",
# "cid": "bafyreihash...",
# "value": {
# "$type": "app.bsky.feed.post",
# "text": "Your post text here",
# "facets": [
# {
# "index": {"byteStart": 42, "byteEnd": 85},
# "$type": "app.bsky.richtext.facet",
# "features": [
# {
# "$type": "app.bsky.richtext.facet#link",
# "uri": "https://yourdomain.com/your-article/"
# }
# ]
# }
# ],
# "createdAt": "2026-05-20T09:15:00.000Z"
# }
# }
# ]
# }
# Facets are how links are encoded in ATProto posts.
# The link URI is stored as structured data, not just embedded text.
# Any crawler reading the firehose can extract these links trivially.
What this means practically: links you post on Bluesky exist in a publicly accessible, well-structured format that any crawler can consume. Googlebot has not confirmed it crawls the Bluesky firehose. But several third-party indices do. And the SEO-adjacent implication is that your links are sitting in an open, machine-readable data stream whether or not Google is currently using it.
I saw no statistically significant crawl acceleration from Bluesky posts specifically. Posts to both networks were followed within the same 48-hour crawl window that would have applied anyway given my site's crawl frequency. But I have a limited dataset. Someone running this across 50 sites might see something different.
Custom Feeds as Discovery Infrastructure
The single biggest driver of that 4,847 session number that nobody talks about: custom feeds.
Bluesky's feed generator system lets developers publish algorithmic or keyword-filtered feeds that any user can subscribe to. There are feeds for specific topics, for specific languages, for specific posting patterns. When a post lands in a popular topical feed, it gets exposure to an audience that has zero overlap with your follower graph.
The GA4 thread that drove the traffic spike? It hit three custom feeds simultaneously: a general analytics feed, a GA4-specific feed that had apparently been created by someone in the analytics community, and a broader marketing feed. Combined subscriber count for those three feeds: somewhere around 140,000 people.
This is meaningfully different from Twitter's algorithmic amplification because it's opt-in and topic-specific. People in those feeds are there because they explicitly wanted content on those topics. The click-through quality reflects that. Bounce rate from Bluesky custom-feed-driven traffic was 34%, compared to 61% for traffic attributable to direct follower engagement. Pages per session: 2.8 vs 1.4.
For SEO purposes, the implication is that Bluesky content strategy should be built around getting into relevant custom feeds, not around follower accumulation. These are different goals that require different approaches.
Mastodon: 218 Sessions a Month and I'm Not Complaining
Two hundred and eighteen sessions. Per month. Across four properties.
For most SEO practitioners reading that number, the reaction is: why bother? And if referral traffic is your only metric, that's a fair question. But the eleven months of data show something that I think changes the value calculation significantly, and it has almost nothing to do with how much traffic Mastodon sends you.
Instance matters enormously. The fosstodon.org account (tech/open source community) drove 71% of total Mastodon referral traffic despite having the second-smallest follower count. The mastodon.social account, largest follower count, drove 19%. The remaining two accounts split the rest.
Depth of engagement per session from Mastodon traffic was the highest of any source I tracked, including organic search. Average session duration from Mastodon referrals: 4 minutes 12 seconds. Pages per session: 3.1. Bounce rate: 28%. These are readers. Not casual clickers. The community selection effect is real and it's strong.
WebFinger and rel=me Verification
Here's where Mastodon becomes genuinely interesting from a technical SEO standpoint, and why I think it's underdiscussed in the search optimization community.
Mastodon's identity verification system uses two mechanisms: WebFinger for account discovery and rel=me link verification for identity confirmation. Both have implications that extend beyond social proof.
# WebFinger: How Mastodon resolves account identities
# A Mastodon handle like @[email protected] resolves via:
# GET https://fosstodon.org/.well-known/webfinger?resource=acct:[email protected]
# Example WebFinger response:
# {
# "subject": "acct:[email protected]",
# "aliases": [
# "https://fosstodon.org/@user",
# "https://fosstodon.org/users/user"
# ],
# "links": [
# {
# "rel": "http://webfinger.net/rel/profile-page",
# "type": "text/html",
# "href": "https://fosstodon.org/@user"
# },
# {
# "rel": "self",
# "type": "application/activity+json",
# "href": "https://fosstodon.org/users/user"
# }
# ]
# }
# rel=me verification: add this to your website's The rel=me bidirectional linking creates a machine-readable identity graph that connects your website to your Mastodon presence. Google uses rel=me for Knowledge Panel association. Having verified Mastodon links in that graph is a small but real signal. It's not going to move rankings. But it contributes to entity understanding, and entity understanding increasingly underlies ranking in competitive queries.
I verified this mechanically by checking the Google Search Console URL inspection tool for several pages on the blog against the timeline of adding rel=me verification. There's no direct causal signal I can extract from that data. But the Knowledge Panel for the blog's author appeared roughly six weeks after implementing the bidirectional rel=me links, after not appearing at all for the previous fourteen months of the site's existence. Correlation. Not causation. Worth noting.
How Federated Discovery Actually Works
The fediverse operates on ActivityPub, and understanding how content discovery works across instances helps explain both why Mastodon traffic is low and why it's high-quality when it arrives.
# ActivityPub: How your Mastodon posts federate across instances
# When you post on fosstodon.org, your post goes to:
# 1. Your followers' home instances (direct federation)
# 2. The local timeline of fosstodon.org (visible to all instance members)
# 3. The federated timeline of any instance where your followers exist
# Your post as an ActivityPub object (simplified):
# {
# "@context": "https://www.w3.org/ns/activitystreams",
# "type": "Note",
# "id": "https://fosstodon.org/users/yourhandle/statuses/109876543210",
# "attributedTo": "https://fosstodon.org/users/yourhandle",
# "content": "<p>Your post text <a href='https://yourdomain.com/article/'>link</a></p>",
# "url": "https://fosstodon.org/@yourhandle/109876543210",
# "published": "2026-05-20T10:30:00Z",
# "to": ["https://www.w3.org/ns/activitystreams#Public"],
# "tag": [
# {
# "type": "Hashtag",
# "href": "https://fosstodon.org/tags/seo",
# "name": "#SEO"
# }
# ]
# }
# Hashtags in ActivityPub posts are discoverable across the entire fediverse.
# A user on any instance following #SEO will see your post in their tag timeline.
# This is the primary discovery mechanism for accounts they don't follow.
# Practical implication: hashtags on Mastodon are functionally different
# from hashtags on other platforms. They are the primary discovery tool,
# not a secondary categorization layer.
This architecture means Mastodon content discovery is almost entirely hashtag-driven for non-followers. Getting seen on Mastodon requires using hashtags correctly: three to five relevant tags, placed at the end of the post, chosen based on what communities on your target instances actually follow. It is nothing like Instagram hashtag strategy. And it is nothing like Bluesky, which has its custom feed system doing different work.
During the experiment, posts with optimized hashtag selection generated 3.4x more referral sessions than posts without hashtags, controlling for follower count differences across accounts.
The Mistake I Made in Month Three
I need to be direct about this because it affected data quality for months three through six.
In month three, I set up what I thought was a clean separation between organic social posting and deliberate content amplification. The plan was to post links naturally across both networks and track what happened. What I actually did was create a confound by also running a low-level digital PR campaign on behalf of the SaaS client during the same period, which generated a handful of genuine editorial links from tech publications.
Those editorial links drove crawl acceleration and mild ranking improvements. I attributed some of those effects to the social posting because the timing overlapped. I caught this in month seven when I did a proper backlink snapshot comparison and realized the timeline didn't support the narrative I'd been building in my notes.
The corrected data shows weaker social-to-ranking correlations than I initially believed. Specifically, the claim I was preparing to make in month five about Bluesky posting correlating with faster indexing was based on contaminated data. The PR campaign, not the Bluesky posts, explained most of that crawl signal.
I went back and rebuilt the analysis with the confound properly excluded. The corrected findings are what appear in this article. The uncorrected version was more exciting. It was also wrong.
Two Contrarian Takes Nobody Wants to Hear
Take one: Bluesky is not a link-building channel and you should stop treating it like one.
The SEO community has spent the better part of the last eighteen months debating whether social media links pass PageRank, whether Google indexes social posts, and whether engagement on social correlates with ranking improvements. This is mostly the wrong framing for Bluesky specifically. The network's value is referral traffic quality and custom-feed discovery, not link signals. Nofollow attributes are present on the links Bluesky's web interface generates. The ATProto firehose is machine-readable, but there is no confirmed evidence Google is pulling ranking signals from it.
When you start treating Bluesky as a link-building channel, you start optimizing for the wrong things. You post links with minimal context because you're thinking about link placement. You chase repost counts. You measure success by whether a post "went viral." None of that maps to the actual value Bluesky can deliver, which is putting detailed, substantive content in front of people who are genuinely interested in your topic and who are using topical feeds to find it.
Take two: Mastodon's SEO value has nothing to do with traffic and the people dismissing it on traffic grounds are missing the point entirely.
218 sessions a month is not a traffic channel worth optimizing for. It's a footnote. But the network's contribution to entity verification, the bidirectional rel=me signal, the Knowledge Panel implications, and the extraordinarily high engagement quality of the traffic it does send constitute a set of benefits that are genuinely hard to replicate elsewhere. The verification system alone is worth implementing for any site trying to build author entity authority, because it creates a machine-readable link between your identity and your domain that exists in structured data Googlebot can consume.
Nobody in mainstream SEO discourse is talking about this because 218 sessions doesn't generate case study-worthy content. That's not the same as it not being valuable.
The DRIFT Framework
After eleven months of tracking this, I needed a way to evaluate social channel decisions that wasn't just "does it drive traffic." So I built a framework I've been using with clients when the decentralized social media question comes up. I call it DRIFT.
D — Distribution reach. How many relevant people can potentially see your content, accounting for network structure? For Bluesky, this includes custom feed subscriber counts in your niche. For Mastodon, this means active hashtag followers on relevant instances. Raw follower count is the least important input here.
R — Referral quality. What do the people who click actually do on your site? This is session depth, scroll depth, return visit rate. Mastodon wins this category comprehensively in my data. The fosstodon.org community sends readers. Not clickers.
I — Identity signal strength. Does the channel contribute to your entity graph in ways that search engines can consume? Mastodon's rel=me verification is the clearest win here across both networks. Bluesky has DID-based identity but the Google-legible implications are less established.
F — Feed discoverability. Can your content reach people who don't follow you? Bluesky custom feeds are the most sophisticated version of this I've seen on any decentralized network. Mastodon's hashtag system is functional but simpler.
T — Time investment versus return. What does consistent posting actually cost against what it returns? Both networks require genuine engagement to get traction. Broadcast-and-leave posting patterns produce near-zero results on either platform.
When I score both networks against DRIFT across my four tracked properties, Bluesky scores higher on D and F. Mastodon scores higher on R and I. They tie, roughly, on T. Neither network is a clear overall winner. They're different tools that happen to coexist in the same product category.
I use DRIFT when clients ask whether to invest time in these networks. It forces the conversation away from "does this drive traffic" toward a more complete picture of what social presence actually does for a site's search footprint.
Comparing the Two Networks Head-to-Head
Across the eleven months, here's what the numbers actually show when I hold everything constant:
Referral sessions: Bluesky 4,847/month peak (340/month normalized, excluding the GA4 thread outlier). Mastodon 218/month relatively stable. No dramatic outlier events.
Session quality (average across all four properties): Mastodon wins on every engagement metric. 28% bounce rate vs 34% from Bluesky custom feed traffic vs 61% from Bluesky direct follower traffic. Session duration: Mastodon 4:12, Bluesky custom feed 2:41, Bluesky direct 1:09.
Crawl acceleration post-posting: Not measurable at my scale once the confound from the PR campaign was removed. Both platforms showed no statistically significant crawl acceleration that couldn't be explained by the sites' baseline crawl frequency.
Backlink acquisition: Three genuine editorial backlinks across eleven months that I can trace with any confidence to Bluesky activity. Two of these came after the GA4 thread reached significant distribution. Zero editorial backlinks I can trace to Mastodon. However, one podcast invitation and one newsletter collaboration came through Mastodon networking, which eventually produced backlinks through a different path.
Brand search volume: This is where I wish I'd been tracking more carefully from month one. By month eight I could see a directional lift in brand search impressions for the blog that correlated loosely with Bluesky growth. I can't quantify this reliably because I don't have a clean pre-post comparison. It's on my list of things to measure more carefully in the next phase.
For a deeper look at how social signals sit within the broader entity authority picture, see our deep dive on E-E-A-T and what it actually means for rankings in 2026. The entity graph components I'm touching on here connect directly to that framework. And if you're thinking about how structured data interacts with these signals, the piece on Schema.org beyond the basics covers the technical foundation.
The SEO-Tangential Signals Worth Caring About
After removing the confounds and being honest about what the data actually shows, here are the signals I believe are real, in order of confidence:
High confidence: Mastodon's rel=me verification contributes to entity graph construction in ways that are consistent with how Google uses author entity signals. The mechanism is established. The bidirectional link pattern is exactly the kind of machine-readable identity confirmation that structured entity markup is designed to create.
Medium-high confidence: Bluesky custom feed placement drives meaningfully higher-quality referral traffic than direct follower-based distribution. This is replicable across all four of my tracked properties. The quality differential between custom feed traffic and general follower traffic is consistent and substantial.
Medium confidence: Mastodon community selection has a filtering effect that makes even small amounts of traffic from the right instance disproportionately valuable in terms of downstream behavior. The fosstodon effect is real. A post that gets moderate engagement on fosstodon.org sends readers who engage deeply. This could matter for user behavior signals if Google is using them in the way many SEOs believe.
Low confidence but interesting: The open firehose nature of ATProto may eventually matter for how third-party indices reference your content. Several AI search engines and non-Google indices already pull from the Bluesky firehose. As AI-mediated search grows, having your links in clean, structured, publicly accessible data formats may become a distinct advantage. I wouldn't optimize heavily for this today, but I'd keep one eye on it. The piece on ChatGPT Search optimization covers some relevant territory here, and so does the analysis of Perplexity's indexing behavior.
Worth watching: Bluesky is building out features that could make brand presence there more consequential for search over time. The network's growth trajectory is real. Monthly active user counts are no longer niche. If Google decides the firehose is worth indexing or using as a signal source, having established presence and engagement history matters. This is speculative, but it's the kind of speculation that's cheap to hedge against by posting consistently now.
So Where Does This Leave You
Eleven months in, if you're asking whether to invest time in Bluesky and Mastodon for SEO-related reasons, the honest answer is: it depends on what you're actually trying to accomplish.
If you need referral traffic volume, Bluesky is the more scalable option, but don't expect linear results from linear effort. Custom feed discovery is the lever that matters and it requires posting content that's substantive enough to get algorithmic traction, not just link-drops. The quality threshold is genuinely higher than most social media posting workflows are designed to clear.
If you're working on author entity authority, Knowledge Panel presence, or E-E-A-T signals for a site that depends on demonstrating genuine expertise, implement Mastodon with rel=me verification and don't worry about the session counts. The structural signal is worth more than the traffic. This is especially true for content in YMYL-adjacent categories where author entity clarity matters to reviewers both human and algorithmic.
If you're building a brand that depends on being known in a technical community, the instance selection on Mastodon matters more than anything else you'll do on the platform. Fosstodon for open source and developer topics. Infosec.exchange for security. Hcommons.social for academics. The community fit multiplies every other variable.
And if you're running a content operation at any serious scale, the DRIFT framework gives you a structure for making this decision that doesn't collapse into "is this channel worth it," which is always the wrong question. The right question is which specific capabilities of each channel map onto which specific gaps in your current search presence. For topic authority development, these channels play different roles in the ecosystem than they do for pure traffic growth.
The experiment continues. Month twelve data is processing. I'll update this when the full-year numbers are in and when I've had time to properly isolate the brand search volume question I botched in the early months. Some experiments don't end cleanly. This one is still teaching me things.
Frequently Asked Questions
Does Google index Bluesky posts?
As of May 2026, there is no confirmed statement from Google that Bluesky posts are indexed or that links within them pass any ranking signal. Bluesky posts are publicly accessible and the ATProto firehose is machine-readable, but confirmed indexing behavior is unverified. Treat Bluesky links as nofollow for planning purposes.
Is the rel=me link on Mastodon useful for SEO?
Yes, with appropriate expectations. The bidirectional rel=me verification between your website and your Mastodon profile creates a machine-readable identity link that contributes to entity graph construction. This is consistent with how Google uses author entity signals for E-E-A-T evaluation. It is not a ranking signal in the direct sense but contributes to entity disambiguation and may support Knowledge Panel generation.
Which Mastodon instance should I use for SEO purposes?
Choose the instance whose community most closely matches your content niche. The community filtering effect significantly affects traffic quality. Fosstodon.org for technology, open source, and developer content. Mastodon.social for general audiences. Specialist instances almost always outperform general instances on engagement metrics even when follower counts are lower.
How do Bluesky custom feeds affect content discovery?
Custom feeds are algorithmically or keyword-filtered content streams that any Bluesky user can subscribe to. When your post is surfaced in a relevant custom feed, it reaches the entire subscriber base of that feed regardless of your follower count. In the data from this experiment, custom feed placement drove approximately 3.6x more referral traffic than equivalent posts that reached only direct followers, with substantially better engagement quality.
Should I use both Bluesky and Mastodon or just one?
They serve different purposes in an SEO-aware social strategy. Bluesky is the better referral traffic channel with more scalable discovery mechanics. Mastodon is the better entity verification and community engagement channel. If you have capacity for both, use both. If you must choose, pick based on whether traffic volume or entity authority development matters more for your current situation.
