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 and follow buttons

Once your records are discoverable, you can put a Standard Reader subscribe button for the publication — or a follow button for yourself — back on your own site, as a small themed card or a plain link. It needs none of the wiring on this page to work, so it has its own: Embed buttons.

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."
    }
  }
}