I put my blog posts on the AT Protocol.

Standard.site is a set of AT Protocol schemas for long-form publishing. I’ve now got 1,134 posts published through it across three sites. The most common question is whether it helps SEO. Answering that honestly requires separating two things people habitually conflate.

What is standard.site?

Right now, if you write a blog post on one app, and your friend writes one on a totally different app, the internet doesn’t always know they’re both “the same kind of thing.” Standard.site is a shared rulebook that says: “here’s what a blog post looks like, here’s what an author looks like, here’s what a publication looks like” — so all these different apps can describe their posts the same way. It started when three publishing apps (Leaflet, pckt.blog, and Offprint) teamed up to build a shared format for things like blog posts, articles, and newsletters, on something called the AT Protocol (the same network that powers Bluesky).

Standard.site is not a platform. There’s nothing to sign up for and no company in the middle: your content never sits on their servers. It’s a set of four lexicons (AT Protocol’s schema definitions) that describe what a blog is.

It exists because of a coordination problem. By late 2025 several people were independently building long-form publishing on atproto: Leaflet, pckt.blog, Offprint. Each had a working implementation, with near-identical schemas for “a publication” and “a post.” None of them could read each other’s content, for no better reason than that they’d picked different field names.

So they converged on a shared set instead:

The governance is deliberately thin: the project describes it as “coordination through adoption, not committee.” Notably, the standard covers metadata only. Content format is explicitly left alone, which is why platforms with wildly different editors (Leaflet’s block editor, WhiteWind’s markdown) can all speak it.

The wiring

A publication record is almost trivially small. Two required fields:

{
  "$type": "site.standard.publication",
  "url": "https://example.com",
  "name": "My Blog",
  "description": "Notes on things",
  "preferences": { "showInDiscover": true }
}

A document needs three required fields (site, title, publishedAt) and gets interesting through its optional ones:

{
  "$type": "site.standard.document",
  "site": "at://did:plc:abc123/site.standard.publication/self",
  "path": "/posts/hello-world",
  "title": "Hello, world",
  "publishedAt": "2026-08-01T09:00:00.000Z",
  "description": "A first post",
  "tags": ["meta"],
  "textContent": "Plaintext of the whole article…"
}

Then you prove the domain and the records belong to each other, in both directions. Your domain serves the publication’s AT-URI:

# GET https://example.com/.well-known/site.standard.publication
at://did:plc:abc123/site.standard.publication/self

And each rendered page points back at its record:

<link rel="site.standard.document"
      href="at://did:plc:abc123/site.standard.document/3mrh7qbcjn2lb">

That’s the entire protocol surface. A consumer that finds your record can confirm the domain vouches for it, and a consumer that finds your page can confirm which record it belongs to. There’s also a <link rel="site.standard.publication"> hint, but the spec is emphatic that it’s a discovery convenience only; .well-known stays authoritative.

With the help of Claude, I create a skill that does this implementation on Hugo for me.
https://github.com/halans/integrating-standard-site-hugo

As well as an audit skill that checks the .well-known endpoint and the <link> tags for correctness.
https://github.com/halans/standard-site-audit-skill

Does it help SEO?

No. Not directly, and anyone telling you otherwise is selling something.

Your records live in a Personal Data Server as JSON, addressed by at:// URIs. Googlebot does not speak at://. It will never fetch or parse them, and it will never attribute them to your domain.

The two mechanisms that look like SEO aren’t. The .well-known endpoint is a verification route, not a ranking signal; no crawler assigns it weight. The <link rel="site.standard.document"> tag is an unrecognised rel value that every search engine ignores. Neither is structured data in the schema.org sense; neither feeds a rich result.

I ran this across 1,134 posts and saw no ranking movement attributable to it. I didn’t expect any. If your goal is Google, spend the afternoon on internal linking instead.

Two caveats worth stating precisely, because they’re the honest edge of the answer:

Your canonical URL is untouched. This is the important structural difference from syndication. Cross-posting to Medium or Substack creates a competing copy that can outrank you on your own writing. A standard.site record isn’t a copy at a rival URL: the url plus path resolve back to your domain. You are adding a distribution channel without splitting your ranking equity, which is a genuinely unusual property.

And second-order: Bluesky renders enhanced cards for links backed by a standard.site record, showing the publication and author. Those cards get clicked. Clicks and links are what actually move rankings. So there’s a real path from “publish records” to “rank better.” It just runs through humans reading your work rather than a crawler parsing a field.

Does it help findability?

Yes, substantially, but through a mechanism that has nothing to do with search engines.

This is the distinction that makes the SEO answer feel less disappointing than it sounds. Google is a pull system. You publish, you wait, a crawler eventually arrives, budget permitting, and some weeks later you might rank.

The AT Protocol is a push system. Writing a record emits it to the firehose immediately. Indexers are subscribed to that firehose. There is no crawl and no sitemap: the record shows up in consumers within seconds of being written, broadcast rather than discovered.

What’s subscribed today:

• Search: pub-search indexes site.standard.* alongside Leaflet and WhiteWind collections, running keyword FTS, vector similarity, and a hybrid mode over them.
• Aggregators and readers: docs.surf, read.pckt, potatonet, Leaflet, Heron.
• Bluesky itself, via the enhanced card treatment.

None of these asked permission, and I didn’t submit anything anywhere. They consume the firehose; my records were on it.

The catch, and it’s a big one: indexers can only work with what’s in the record. I shipped all 1,134 of mine with textContent empty: title, path, description, no body. Which means pub-search was embedding roughly forty words per post instead of two thousand, and semantic search had almost nothing to match against. The plumbing worked; the content wasn’t there. If you take one thing from this: fill textContent.

The same lesson in a smaller key: preferences.showInDiscover decides whether you appear in discovery feeds. Omit it and every consumer applies its own default. It’s one boolean, and I’d left it off on all three sites.

What the protocol actually changes about blogging

Set search aside. The more durable argument isn’t about traffic at all.

Your archive stops depending on a company

Records live in your PDS. The publishing app is a client. If Leaflet shut down tomorrow, Leaflet-published posts would still exist in their authors’ repositories, still be readable by every other app that speaks the lexicon. Compare that to the standard blogging-platform failure mode, where a shutdown means an export file and a pile of dead inbound links.

Identity is protocol-level

Your DID is your account everywhere on the network. No per-platform signup, no per-platform follower list to rebuild. Verification is a file on a domain you already control, which makes the domain the anchor, not the platform.

Social features become records

Subscriptions and recommends are records, not rows in someone’s private database. A subscription made in one reader is visible to another. Contrast with RSS, which nailed portable content but never made the audience portable: nobody knows who subscribes to their feed. Here the graph is public and shared.

Interoperability turns competitive

Because a post is just a record, you can publish to a platform’s lexicon without using the platform. People run personal sites emitting WhiteWind-format records having never touched WhiteWind. GreenGale reads WhiteWind posts natively. PiPup ships a WhiteWind importer.

Platforms compete on the editor and the reader, not on holding your content hostage. Lock-in stops being a viable business model, because the exit is a protocol feature.

What I’d tell myself before starting

Auditing my own three sites turned up a consistent pattern: the hard part is trivially easy, and the easy part is where everything goes wrong. Verification worked on the first try across all three. Every reachable page carries a correct, record-matching tag. What broke was mundane:

• textContent empty on all 1,134 records. The single biggest self-inflicted wound. Reader apps could only link out; indexers only saw titles.

Every one of those traces to the same root cause: generating records out of band from the build. Your SSG already knows which pages exist, what their real permalinks are, and what their body text says. Emitting records from the build instead of alongside it makes an entire category of these bugs structurally impossible.

Should you bother?

If you’re measuring on Google traffic, the answer is no. You will be disappointed, because it isn’t that. If you want your writing reachable by a growing set of readers and indexers that don’t route through a search engine, and you’d like your archive to outlive whatever tool you’re using, yes.

The cost is genuinely low. WordPress has a plugin. Sequoia handles 11ty, Hugo, Astro, and Jekyll from the command line. EmDash builds it in. For a static site it’s a build-time JSON emit plus a sync step: an afternoon, most of which is deciding which fields to populate.

And that decision is the one that matters. The protocol work is easy and largely done for you. Whether anyone can find what you wrote depends almost entirely on whether you bothered to put your words in the record.