Astro CMS: how to choose a CMS for an Astro site, and how to connect it.

Does Astro have a built-in CMS?

No. Astro is a web framework that handles presentation, so content lives either in Markdown files in your project or in a separate content management system. Astro's own docs put it plainly: "Because Astro takes care of the presentation of your content, you'll want to choose a headless CMS." They list guides for 45 of them.

A headless CMS stores and manages content, then sends it to any frontend through an API. The CMS has no say in how pages look. That split is the point: marketers edit in the CMS, and developers keep control of the components, performance, and markup in Astro.

Two notes on that list of 45. First, Astro says "many of these pages are stubs," so a guide's presence tells you a CMS has been used with Astro, not that it is well supported. Second, one entry is close to a built-in option: StudioCMS calls itself "the Astro-native CMS," is open source under the MIT license, and stores its data in a remote libSQL database. Its site says it works with Astro v5 projects, so check Astro 7 support before you commit.

Ownership changed in 2026, though the license did not. On January 16, 2026, The Astro Technology Company joined Cloudflare and said Astro stays "open-source and MIT-licensed" and continues to support "a wide set of deployment targets, not just Cloudflare."

When are Astro content collections enough?

Content collections are enough when developers write and publish the content, it changes a few times a month, and nobody needs to preview drafts. Add a CMS when marketers need to publish on their own, preview pages before they go live, schedule posts, manage translations, or control who can edit what.

Content collections are Astro's built-in way to manage "a set of related, structurally identical data," such as blog posts or customer stories. They come in two kinds, and the difference decides much of your CMS setup.

Astro recommends build-time collections by default and live collections "when your content needs updating in real time." Previews are one of the use cases it lists for live collections, which is the first sign that a marketing team's CMS setup will need some server rendering.

Signs you have outgrown files in the repository:

• Marketers wait for a developer to publish a post or fix a typo.
• Nobody can see a draft page before it ships.
• You publish in more than one language and translations drift.
• Landing pages need reusable sections that non-developers can assemble.
• Legal or brand teams need approval steps and an edit history.

What types of CMS work with Astro?

Five types work with Astro: Git-based CMSs that write files to your repository, hosted headless CMSs with an API, open-source CMSs you host yourself, traditional CMSs used headless, and Astro-native CMSs. They differ most in where content lives, who maintains the service, and how much previewing and visual editing your team gets.

For B2B SaaS marketing sites, the choice usually narrows to Git-based for a developer-run site and hosted headless for a site that a marketing team runs day to day. Our headless CMS comparison covers the criteria in more depth, without a ranking.

Which CMSs have full Astro guides, and how does each connect?

Most CMSs that Astro teams shortlist have a full setup guide in Astro's docs or an official Astro integration. They connect in one of three ways: an integration package, an SDK or REST API, or an editor that writes files to your repository. The table lists common options alphabetically; it is not a ranking.

A full guide counts for more than a logo on a list. Astro marks many of its CMS pages as stubs; Payload's, for example, is a short overview that points to an example project. The guides for Contentful, Decap CMS, Keystatic, Storyblok, Strapi, TinaCMS, and WordPress walk through setup, data fetching, and deployment, and those for Contentful, Storyblok, and Strapi also cover rebuilding the site through webhooks.

How do you choose a CMS for an Astro site?

Choose by who edits, how often, and what they must see before publishing. Then check five things in a short trial: previews, content modeling for your page sections, localization, roles and workflow, and how the CMS tells Astro that content changed. A one-page pilot built on two candidates shows more than any feature grid.

1. Previews and visual editing. Ask how editors see a draft on the real page design, as a live preview or in a visual editor. On Astro, this usually means server-rendered preview routes: live collections need on-demand rendering, and Sanity's Visual Editing, for one, only works on server-rendered pages.
2. Content modeling. Model reusable sections, such as a hero, a logo bar, or a pricing table, that map one to one to Astro components. Marketers then assemble approved sections instead of editing raw layouts.
3. Localization. If you sell in several markets, test field-level translation and fallbacks on one real page.
4. Roles and workflow. Check drafts, scheduled publishing, approvals, and edit history against how your legal and brand reviews work.
5. Change signals. Confirm the CMS can send a webhook when content changes, so your site can rebuild or clear its cache.

Add search fields to the model from day one: title, meta description, canonical URL, Open Graph image, and a noindex switch. We set up titles, descriptions, Open Graph images, and canonical tags as CMS fields on our headless builds, and our post on headless CMS SEO covers the rest of the pre-launch checks.

How does Astro fetch content from a CMS?

Astro fetches CMS content in one of three ways: through an official integration from the CMS vendor, through the vendor's JavaScript SDK or a plain fetch call in a page, or through a content collection loader. Loaders are the tidiest route for most sites, because content arrives typed and validated in one place.

• Integrations. Some CMSs ship an Astro integration that wires up a client and helpers; the Astro docs name Storyblok as one example, and Sanity has another.
• SDK or fetch. "Others provide a JavaScript SDK," in the docs' words, which you call from a page's frontmatter. This is quick to start but scatters queries across pages.
• Loaders. A build-time loader pulls entries into a content collection when the site builds. On third-party loaders, the docs say: "Several already exist for popular content management systems." A live loader fetches on each request instead.

The loader you pick sets your publishing model. With build-time collections, publishing in the CMS usually triggers a webhook that starts a new build, which is simple and fast to serve but slower to update. With live collections and server rendering, content is current on every request, at the cost of a fetch each time.

Astro 7 adds a middle path. Route caching is now stable, a live loader can attach cache hints such as tags and a last-modified time to the data it returns, and code can invalidate cached routes by tag. A CMS webhook can then clear only the pages an edit touched. Astro 7 also adds experimental CDN cache providers for Netlify, Vercel, and Cloudflare.

How do you connect Sanity to Astro?

Install Sanity's official integration, @sanity/astro, add your project ID and dataset to the Astro config, and query content with its configured client. For previews, add Sanity's Visual Editing on server-rendered routes with a read token. You can also load Sanity content into a content collection with its experimental loader.

1. Install the integration. Add @sanity/astro and set your Sanity project ID and dataset in astro.config.
2. Query content. Import sanityClient from "sanity:client" in a page or loader and fetch with GROQ, Sanity's query language. Named clients cover more than one project or dataset.
3. Embed the Studio if you want one URL. Set studioBasePath, for example /admin, and add a sanity.config.ts file. This needs the React integration, @astrojs/react.
4. Add Visual Editing for previews. Sanity's plugin page says "Visual Editing only works for server-side rendered pages," and it needs a read token with Viewer permissions. Keep the token on the server, and keep preview routes out of search with noindex.
5. Render rich text and images. Sanity's page points to astro-portabletext for Portable Text and @sanity/image-url for images.
6. Try the loader. The experimental sanityLoader feeds GROQ results into Astro content collections and needs Astro 5 or later.

Our own site runs on Astro and Sanity, and its robots.txt points to a sitemap index with one child sitemap. On our headless builds, content arrives in the HTML through server-side rendering or static site generation, so search engines and AI crawlers read it without running JavaScript.

We build headless sites on Astro and Next.js with Sanity, so we have an interest in the topic. See our headless CMS agency page for how we run those projects.

What changed in Astro 7 for CMS-driven sites?

Astro 7, released June 22, 2026, made route caching stable, switched to a Rust compiler, and made a new Rust-based processor, Sätteri, the default for Markdown and MDX. Sites that render CMS content should test templates and Markdown output before upgrading, because the new compiler is stricter about markup.

Three changes matter for sites fed by a CMS:

• Stricter markup. Unclosed tags and unterminated attributes now raise errors instead of being corrected, and whitespace between inline elements collapses. Templates that render CMS content can fail to build, or change spacing, after the upgrade.
• Markdown pipeline. Sätteri replaces the unified pipeline by default. If your CMS stores Markdown and you rely on remark or rehype plugins, you need to opt into @astrojs/markdown-remark.
• Caching. If you tried route caching while it was experimental, the cache and routeRules settings move out of the experimental block to the top level.

Astro reports build times 15% to 61% faster in its own benchmarks, which helps sites that rebuild on every CMS publish. For Core Web Vitals on Astro sites, the bigger risk is usually third-party scripts, as our Core Web Vitals guide explains.

Questions about choosing a CMS for Astro