Skip to main content

Posts & Content

A Post is a single piece of content you publish to two channels — the web and email — independently or together.

What a post is​

  • Web — a page on your site at /<content_path>/<slug>, defaulting to /content/<slug>.
  • Email — sent to a newsletter list, if one is selected.

A post can be web-only, email-only, or both. Every published post has a web page; email is opt-in per post via a newsletter list.

The content archive​

Published posts with Listed visibility appear in your site's content index (newest first), at /content by default or your configured content path. The archive also gets an RSS feed and sitemap entries, Listed posts only.

Set the archive's title and description in a [blog] block:

[blog]
title: Notes
description: Short guides on building small sites from a text file.

title is the archive heading, its <title> and the RSS feed title. description is the archive's meta description, social-card description and RSS description. You can also set both in the editor under Settings → Blog; the [blog] block overrides those settings. With neither, the title is "Posts" and the description is the site description. Give the archive its own description when your home page also uses the site description, so search engines don't see two pages with the same one.

Unlisted posts still get a page and URL — they're just not in the index, RSS feed, or sitemap. Use Unlisted for content you want linkable but not browsable (e.g. something you're only sharing directly).

If /content (or your custom path) collides with a page you've already built at that URL, your page wins and the archive doesn't mount there.

Lifecycle​

A new post is a draft: saved, but not on the site and not emailed. Nothing happens until you publish.

Publishing puts the post live on the web and, if a newsletter list is set, sends the email to that list.

Once a post is published, editing its content and saving goes live immediately — no separate publish step for content edits.

Unpublishing takes the page down (it 404s) and returns the post to draft. The post itself isn't deleted, and you can publish it again later.

Re-publishing an already-published post re-sends the email to the list, and re-snapshots the recipient list — which resets that post's click-through stats (see below). The CLI guards against this: micropage posts publish without a slug publishes drafts only, and re-publishing an email post that was already sent, even if unpublished since, requires --resend (Posts (CLI)).

Dates​

A post's published date is shown on the post and orders the content index and RSS feed. It defaults to the moment the post is first published. You can set it to an earlier date, or today, with the date front-matter field (Posts (CLI)) or the MCP upsert_post tool; future dates are rejected, since scheduling isn't supported.

A published post also tracks when it was last updated: editing its title, body, description, or hero image sets it. Re-saving unchanged content or changing only the date does not. The updated date isn't displayed; it feeds the sitemap <lastmod> and the dateModified in the post's structured data (see SEO).

Slugs​

Each post has a slug, unique per project, that determines its URL (/<content_path>/<slug>). It's auto-derived from the title and can be overridden.

Emailed posts include a "view this post on the web" link back to the published page. If you Unpublish a post after emailing it, that link in already-sent emails will 404 — this is expected, not a bug.

Click tracking​

Emailed posts track link clicks: an overall click-through rate, unique clickers, and a per-link breakdown. Because re-publishing re-snapshots the recipient list, it also resets the post's click stats. Open-rate tracking is not part of this report.

Authoring​

Two ways to write and manage posts:

  • The web editor — see Posts (App).
  • The CLI, authoring posts as posts/*.md files with YAML front-matter — see Posts (CLI).

Each post has a revision that changes whenever its content changes. Saves from the editor, the CLI, and the MCP server are refused, with nothing written, if the post changed since it was read, so editing in two places at once can't silently overwrite either edit. Re-read the post and apply your changes again, or, from the CLI, overwrite with micropage posts push --force.

Newsletter lists themselves come from forms with the Newsletter option enabled — see Newsletter.