On October 7, 2026, the first results for "astro blog" showed you how to get a first post on screen: the official build-a-blog tutorial, a quick-start course, a gallery of developer blogs and a couple of personal first builds.
A product blog that publishes every week needs a few more pieces. It needs a schema that rejects a post with no description, an editor that keeps posts in Git, a sitemap crawlers can read and a place where drafts wait for your approval.
This guide sets up an Astro blog for a SaaS in six steps, with the config for each one.
I run this blog on Next.js today, and I've also built blogs with Astro and liked working with it. Both setups share the same content layer, because seodraft delivers every approved post to content/blog/{locale}/{slug}.mdoc in the repository.
The last step shows how agent-written drafts land in an Astro repo with draft set to true, so nothing goes live until you change that one field. Start with the template and add one piece at a time.
- 1. Start from Astro's official blog template
- 2. Define the post schema with your SEO fields
- 3. Add Keystatic so posts stay files in the repo
- 4. Publish a sitemap and an RSS feed
- 5. Deploy on Vercel and review every branch
- 6. Let agent drafts arrive marked as drafts
- Pick Astro when the blog can live as its own site
1. Start from Astro's official blog template
Astro's official blog starter gives you a working blog with Markdown and MDX posts, an RSS feed and a sitemap in one command.
npm create astro@latest -- --template blog
The starter's astro.config.mjs loads the MDX and sitemap integrations, and its package.json adds @astrojs/rss. Change the site value from https://example.com to your real domain before the first build, because the sitemap and the feed both build their URLs from it.
The project is static by default. Every post becomes an HTML file at build time, and Astro sends no JavaScript to the page unless a component asks for it.
2. Define the post schema with your SEO fields
The post schema lives in src/content.config.ts, and it should require every field your SEO depends on, so a post that misses one fails the build.
The starter checks a title, a description, a publish date, an updated date and a hero image. For a product blog I add the fields that end up in snippets and AI answers: a short tldr, the FAQs, the tags and a draft flag. What goes inside each post is in the eight-part blog post template.
// src/content.config.ts
import { defineCollection } from 'astro:content';
import { glob } from 'astro/loaders';
import { z } from 'astro/zod';
const blog = defineCollection({
loader: glob({ base: './src/content/blog', pattern: '**/*.{md,mdx,mdoc}' }),
schema: z.object({
title: z.string().max(60),
description: z.string().max(160),
publishedAt: z.coerce.date(),
updatedAt: z.coerce.date().optional(),
tldr: z.string().optional(),
faqs: z.array(z.object({ question: z.string(), answer: z.string() })).default([]),
tags: z.array(z.string()).default([]),
draft: z.boolean().default(true),
}),
});
export const collections = { blog };
The keys mirror the frontmatter this blog receives. seodraft maps its date to publishedAt and its updated date to updatedAt, and writes title, description, tldr, faqs, tags and draft under their own names. The max(60) on the title stops the build the day someone writes a 61-character headline.
Then filter drafts everywhere you list or route posts:
const posts = await getCollection('blog', ({ data }) => !data.draft);
The schema defaults draft to true, so a file that forgets the field stays hidden.
3. Add Keystatic so posts stay files in the repo
Keystatic gives your Astro blog an editing screen while every post stays a file in your repository.
I pick Keystatic for the simplicity of working git-based. Saving a post creates a commit, and you can review, revert or open that commit as a pull request like any product change.
The Keystatic docs install it with two commands:
npx astro add react markdoc npm install @keystatic/core @keystatic/astro
Add keystatic() to the integrations in astro.config.mjs. Then create keystatic.config.ts at the project root with a posts collection whose path points at the folder your content collection loads, such as src/content/blog/*.
Posts saved from the editor are .mdoc files, the Markdoc format the markdoc integration renders. Run npm run dev and open /keystatic to see the editor.
Two limits matter before you commit to it. Keystatic runs server-side code, so its docs say you need an Astro adapter to deploy it, and with local storage it writes to your own disk until you connect it to GitHub.
4. Publish a sitemap and an RSS feed
The sitemap integration and the RSS package hand search engines and readers a list of every post, and both read your site value. How long Google then takes to crawl a listed post is in how long Google takes to index a new page.
@astrojs/sitemap writes sitemap-index.xml and sitemap-0.xml at build time. Add a Sitemap: line to robots.txt with the full URL of sitemap-index.xml so crawlers find it. Its docs note one gap: it cannot list dynamic routes rendered on demand, so keep blog routes prerendered.
The sitemap lists the pages you generate, so filtering drafts out of getStaticPaths() keeps them out of it too. Check the file after each deploy. When we imported seodraft's sitemap on September 27, 2026, it listed 57 pages, 6 of them blog posts, and the free sitemap checker gives you the same count for your own site.
For the feed, create src/pages/rss.xml.js and build its items from getCollection('blog') with the same draft filter, so a hidden post never reaches subscribers.
5. Deploy on Vercel and review every branch
Vercel deploys a static Astro blog with no extra configuration and gives every branch its own preview URL.
Push the repo, import it in Vercel, and it detects Astro on its own. After that, each push to a branch creates a preview deployment, and each change to main becomes a production deployment.
The preview is where I read a post with its real styles and images before merging it. Keystatic's admin routes need the Vercel adapter, which npx astro add vercel installs, while the blog pages stay prerendered.
6. Let agent drafts arrive marked as drafts
An AI agent can write into your Astro blog safely when every post it delivers arrives as a file with draft: true.
This blog works that way. My agent writes through seodraft, the rules check the draft, and when I approve it seodraft commits content/blog/en/{slug}.mdoc with draft: true to the repository. The schema from step 2 hides it from the live site, and the Vercel preview shows it.
Before any file reaches the repo, the draft goes through a fixed order. The current workflow saves the brief before the body and requires every evidence item in the brief to reach the article.
Publishing stays a human step. When I first tested seodraft on a demo account, on September 17, 2026, the run ended with the post marked ready. The workflow stopped at READY: I did not call delivery or publish the article.
Going live means changing draft to false and merging. The CMS delivery page lists the path and frontmatter options seodraft can write.
Pick Astro when the blog can live as its own site
Pick Astro when the blog can live as its own content site, and pick Next.js when it has to share the product app's layout and components.
I've built blogs with both, and this one runs on Next.js at seodraft.app/blog, on the same domain as the product. Why seodraft does this work through your agent instead of its own web editor is in Agent-first: why seodraft killed most of its web UI.
If you go with Astro, do step 2 first, before you pick a theme. The schema decides what every future post has to carry.
When you want the briefs, the rules and the draft delivery handled for you, try seodraft with your own agent (Claude, Cursor, or ChatGPT on Business, Enterprise or Edu): your agent writes, the rules decide, you approve.
