Publishing your site

Overview

Standard Reader indexes site.standard.document and site.standard.publication records out of AT Proto repos. Platforms like Leaflet, Pckt, and Offprint write these records for you as part of publishing, so their authors get the full reader treatment automatically. If you run your own site and hand-roll your own site.standard integration instead, you write those records yourself — this page covers what to add, including Markpub, the markdown format we recommend for a hand-rolled body.

Discovery

Say in your page's head which records it is built from, and any client on the network can resolve the page back to them. Our browser extension uses this: when you land on a URL it hasn't indexed yet, it reads those tags rather than guessing from the URL.

Use the at: meta tags — the convention the Atmosphere settled on in 2026. at:canonical names the records the page is made of, the ones it would have no reason to exist without. at:alternate names records the page merely shows — the publication a document belongs to, a companion Bluesky post. at:author names the identity that wrote it. Every name repeats, so a page with two alternates emits two tags.

<meta
  name="at:canonical"
  content="at://did:plc:you/site.standard.document/<rkey>"
/>
<meta
  name="at:alternate"
  content="at://did:plc:you/site.standard.publication/<rkey>"
/>
<meta name="at:author" content="at://did:plc:you" />

Standard Reader emits these on its own article, publication, collection, list and profile pages, and reads them from yours.

The site.standard link rels

Emit these too. Discovery hints are part of the site.standard spec itself — a link tag whose rel is the record's collection and whose href is its at:// URI — and plenty of clients across the network still read only these. Include the site.standard.publication hint when the document belongs to a publication record.

The two say overlapping things, and that's fine: the meta tags carry intent the rels can't, while the rels are what the site.standard spec asks for. Carry both, which is what Standard Reader itself does on every article, publication and collection page.

<link
  rel="site.standard.document"
  href="at://did:plc:you/site.standard.document/<rkey>"
/>
<link
  rel="site.standard.publication"
  href="at://did:plc:you/site.standard.publication/<rkey>"
/>

Subscribe embed

Every publication page also serves a themed, embeddable subscribe widget — an iframe you can drop on your own site so visitors can subscribe without leaving your page. The easiest way to get it: open your publication's page on Standard Reader, use Share → Embed subscribe, pick landscape or portrait, and copy the snippet — no account or ownership check required to generate it.

It reads the publication's basicTheme colors automatically, so the card matches your brand with no extra params — fonts aren't picked up though; the card always uses Standard Reader's own type. Here's a live one:

Clicking Subscribe opens Standard Reader itself, not your page — subscribing writes a site.standard.graph.subscription record to the reader's own PDS via their own OAuth session, so it has to happen on our domain. If you'd rather skip the iframe, link straight to /subscribe// and style your own button.

Rendering Content in Standard Reader

Whether tapping an article opens it inline in Standard Reader, or takes the reader straight to your site, depends on one thing: does the record's content field hold a body in a format Standard Reader knows how to render? If content is missing, or set to a format we don't recognize, the article is treated as an external post and always opens on your site — even if textContent carries a plain-text excerpt. To get inline reading, publish the article body in content using one of the recognized formats below.

Supported content formats

Markpub (recommended). at.markpub.markdown — markdown with facets for rich text. It's not part of the site.standard spec either — no markdown format is — but it's the only one that's actually spec'd in a meaningful, reusable way, rather than one app's own ad hoc shape. Use this for a hand-rolled integration unless you already produce one of the platform formats below.

Leaflet, Pckt, Offprint. pub.leaflet.content, blog.pckt.content, and app.offprint.content — the block-based formats those tools write natively.

Everything below is compatibility support for formats already out there in other apps' own repos — none of it is part of the site.standard spec, and none of it is something to model a new integration on.

HTML-in-record. Formats whose payload is { html: "..." } — each from a different, unrelated app, e.g. org.wordpress.html (WordPress) or co.idno.html (Idno). Sanitized before render, never injected raw.

Structured blocks. Rich block-editor documents, each in that editor's own schema — e.g. org.blocknote.document#content (BlockNote) or pub.oxa.document.document (Oxa). Only useful if you're already producing one of these; not worth adopting from scratch.

Other markdown shapes (avoid). site.standard.content.markdown and a scattering of third-party #markdown shapes — e.g. site.standard.document#markdown — carry a raw markdown string under a format-specific key. Don't add another one — publish Markpub instead.

Example record

A minimal loose document — no publication, Markpub markdown body:

{
  "$type": "site.standard.document",
  "site": "https://example.com",
  "path": "/posts/hello-world",
  "title": "Hello, world",
  "publishedAt": "2026-07-01T12:00:00.000Z",
  "content": {
    "$type": "at.markpub.markdown",
    "text": {
      "$type": "at.markpub.text",
      "markdown": "# Hello, world\n\nThis renders inline in Standard Reader."
    }
  }
}