Astro CMS: 7 Headless CMS Options Your Marketing Team Can Edit

Can your marketing team still edit an Astro site?

Yes, if you pick the right CMS on day one. Astro is a framework, not a CMS. Out of the box, content lives in Markdown files in a code repository, which is fine for developers and a dead end for a 2-person marketing team.

Astro pulls content from a headless CMS through its content layer. You have two modes:

• Build-time collections (defineCollection() with a loader). Content is fetched when the site builds and served as fast static pages. Publishing a change triggers a rebuild, usually through a webhook to your host.

• Live collections (defineLiveCollection() in src/live.config.ts, stable since Astro 6). Content is fetched on each request, so edits show up without a rebuild. This needs server rendering and an adapter, and there are no built-in live loaders, so someone has to write or install one.

Both can live in the same project. The CMS you choose decides how painful each one is to set up and what your editors see.

Astro CMS comparison: 7 options side by side

Prices checked on the vendors' pricing pages in October 2026. They change often, so confirm before you budget.

The options, from a marketing lead's chair

Sanity: the default for structured, reusable content

Sanity stores content as structured data, not pages. You write a customer story once and reuse it on the homepage, the industry page and the sales deck. When you rebrand, you change one component, not 40 pages.

The official @sanity/astro integration gives you a preconfigured client, an option to embed Sanity Studio inside your Astro project at a path you choose, and support for Visual Editing. Visual Editing means your team sees the live page in Sanity's Presentation tool and clicks any text to edit it. The catch: it requires Astro in server output mode, because draft mode checks a cookie on every request.

The editor is fully customizable, which cuts both ways. A good build gives your team a clean, labeled screen. A lazy build gives them a wall of fields. We wrote more on this in our Sanity CMS guide.

Contentful: enterprise structure, enterprise feel

Contentful is mature, well documented and strong on roles, environments and localization. In Astro, the standard setup uses the contentful JavaScript SDK, the Preview API for drafts and the delivery API for published content, plus a rich text renderer to turn Contentful's rich text into HTML.

The editor is form-heavy. Marketers can use it fine, but it feels like filling in a database. The bigger issue for a small team is the pricing curve: the free tier is limited, and the paid tiers are priced for larger organizations. If you are torn between the two, read Contentful vs Sanity.

Storyblok: when visual editing is the whole point

Storyblok is built around a visual editor. Your team drags components onto a page and sees the result as they type. If the brief is "marketing must launch campaign pages without filing a ticket," Storyblok is the strongest answer.

The @storyblok/astro package supports live preview inside the Visual Editor. To get it, the site needs livePreview turned on, server output, and an HTTPS connection for the preview, plus storyblokEditable attributes on each component so the editor knows what you clicked. For static builds, you add your host's build hook to Storyblok's webhooks so publishing triggers a rebuild.

Trade-off: content is shaped around pages and components, so reusing a single fact across the site takes more discipline than in Sanity.

Payload: powerful, but you are running a second app

Payload is open source and has an excellent admin. With Astro, though, it runs as a separate backend with its own database. Your developer now maintains two apps, two deployments and a database. That is a fine trade for a product team with engineers. It is a poor one for a marketing team whose developer leaves in six months.

Decap and Tina: Git-based, friendly-ish

Both store content as Markdown in your repository and add an admin screen on top. Decap gives you a simple dashboard at /admin and commits changes to Git. Authentication is easiest on Netlify; elsewhere you set up an OAuth flow yourself. Tina offers a nicer editing experience and a hosted cloud option that commits to GitHub.

They are cheap and simple. They are also limited: light content modeling, basic media handling and a workflow that still assumes someone understands Git when things break.

Markdown or MDX in Git: only for developer-run sites

Astro handles Markdown brilliantly. For a docs site or an engineering blog, it is the right call. For a marketing site, it means every headline change is a pull request. If your team cannot open a code editor, rule it out.

Headless WordPress: a bridge, not a destination

You can keep WordPress as the editor and use Astro as the front end, pulling content through the REST API or WPGraphQL. Your team keeps a familiar screen. But themes, page builders and many plugins stop doing anything on the live site, and you now host two systems. It makes sense as a step during a move, not a long-term plan. If you are planning that move, see our WordPress to Astro migration page and Sanity vs WordPress.

What we recommend, by situation

Goodspeed is an AI-native website studio that builds with the best tool for the job, and we build Astro sites with headless CMSs for marketing teams. Our default is Sanity. Here is how that changes by situation:

• You are about to raise, launch or get press, and the site needs case studies, team pages and proof that stay in sync: Sanity, with Visual Editing set up from day one.

• Your team ships a new campaign page every week and wants to build it themselves: Storyblok.

• You have a governance team, multiple regions and a procurement process: Contentful.

• You have engineers who want to own every layer: Payload.

• A developer runs the site and marketing rarely touches it: Markdown in Git.

If the new site is being scoped now, our Astro agency page covers how we plan the CMS, the content model and the editor handover together, so your team can publish on launch day without calling a developer.

How to choose an Astro CMS in 5 questions

1. Who publishes, and how often? If marketers publish weekly, rule out Markdown and Git-based tools.

2. Do you build new pages or update existing ones? New pages every week points to Storyblok. Mostly updating reusable content points to Sanity.

3. Do you need to see the page before it goes live? If yes, budget for server rendering and a proper preview setup. It is not free in any CMS.

4. How many people need access, with what permissions? Count seats and roles. Sanity's free plan includes 20 seats but only Administrator and Viewer roles; Editor and Contributor roles come with Growth. Storyblok's free plan has 1 seat.

5. Who maintains it after launch? If nobody technical is staying, avoid anything you have to host yourself.

Setup gotchas to raise with your developer

Preview and draft mode. Visual Editing in Sanity and live preview in Storyblok both need Astro running in server output mode. If your developer plans a fully static site, ask how drafts will be previewed. "Publish and check" is not a preview.

Rebuild on publish vs server rendering. Static sites are fast and cheap, but every publish triggers a build. On a small site that takes a minute or two. On a large one, editors wait. Server rendering or live collections show changes instantly but add hosting cost and moving parts. Many sites mix both: static marketing pages, server-rendered preview.

Images. Each CMS serves images from its own CDN. Astro's <Image /> component only optimizes remote images from domains you allow in the config, and live collections cannot optimize images at runtime. Agree who handles crops, alt text and file sizes, or your homepage hero will ship at 4 MB.

Roles and permissions. Decide before launch who can publish and who can only draft. On some free plans the only roles are admin and viewer, which means everyone can publish everything.

Content modeling. This is where most projects quietly fail. If the developer models content page by page, you get a CMS that mirrors today's site and fights tomorrow's. Ask for reusable types: testimonial, case study, person, logo, CTA. Then ask to see the editor screens before the build starts.

Where it breaks

• Visual editing on a static site. Your team expects click-to-edit and gets a form plus a rebuild. Settle the rendering mode first.

• Over-flexible page builders. Give a team unlimited components and the brand drifts within a quarter. Lock down spacing, colors and layouts.

• Over-rigid schemas. The opposite failure. Every new section needs a developer, and you are back where you started.

• Seat and usage creep. Per-seat and usage-based plans look cheap at launch and grow with your team, traffic and document count. Check the overage terms.

• The departed developer. Custom loaders, webhooks and preview routes are invisible until they break. Insist on written handover notes.

• Migration debt. Moving rich text between CMSs is messy. Choose well now and you avoid doing it again in two years.

If you are still deciding on the framework itself, our Astro vs Next.js comparison covers that call.