Astro CMS: choosing the right headless CMS for Astro.

No. Astro reads content straight from the project through content collections – Markdown, MDX, Markdoc, JSON, YAML or TOML – validates it against a Zod schema and exposes it type-safely via getCollection(). For sites whose content is maintained by developers anyway, that is the simplest setup: no subscription, no second login, no API that can go down. A CMS is added once people without Git access need to publish.

Technically almost any of them – Astro is CMS-agnostic and pulls content over each system's API. Your team decides the answer. Git-based CMSs like Decap, Keystatic or TinaCMS suit small editorial teams close to the repository. API-based systems like Storyblok, Sanity or Contentful suit multiple editors, approvals and languages. Strapi, Payload CMS or Directus suit cases where the data has to stay in house.

Yes. Astro documents headless WordPress explicitly: the WordPress instance stays in place and serves content over its API, while Astro builds the front end. Your editors keep working in wp-admin, but visitors receive static HTML. It makes most sense when your team knows WordPress and wants to keep it. We describe the whole move on WordPress as a headless CMS.

Content collections are Astro's built-in way to manage structurally identical content – all blog posts, all job openings, all locations. They are defined in src/content.config.ts, their schema is written and validated with Zod, and Astro derives TypeScript types from it automatically. Two built-in loaders read the data: glob() for a directory of files, file() for several entries inside one file. They arrived in Astro 2.0.

A git-based CMS writes every change back into your repository as a commit. Content therefore stays in the project, versioned, with no second database. An API-based headless CMS stores content at the vendor and Astro fetches it over an interface. Git-based is cheaper and simpler to operate. API-based brings roles, approvals, draft preview and localisation – everything larger editorial teams depend on.

For build-time content, yes – and usually that is the point, because the output is static HTML served without a database query. The build is triggered by a webhook from the CMS and runs in the background; for a typical marketing site it takes minutes. Where that is not enough we mix: render individual routes on demand, or let live collections fetch data per request via getLiveCollection().

Yes, though the route there depends on the system. API-based CMSs usually expose drafts through a dedicated preview token; we build a server-rendered preview route that pulls exactly that draft version. Git-based CMSs work through branches and your host's deploy previews instead. We test this before launch – it is the feature that decides whether an editorial team adopts a system or quietly abandons it.

Three things set the frame: the number of content types, the depth of editorial features (roles, approvals, languages) and the licence cost of the chosen system. Content collections carry no licence, only development time. An API-based CMS comes with a subscription that grows with seats and traffic. We quote both separately – one-off build and running cost. Details on Astro development cost.

Yes, and it is exactly what the CMS choice turns on. If people are to publish without a developer, the answer is not content collections but a system with an editing UI: git-based for one to five editors, API-based as soon as roles, approval stages or several languages are involved. We set up preview, permissions and the webhook that triggers a build after publishing. New page types and layout changes stay development work – that is true in every system, WordPress included.

They get inventoried, migrated by script and re-served – not copied by hand. Astro's built-in image component sets the alt attribute, loading behaviour and dimensions itself, which avoids layout shift. Two points we flag up front: remote images from a headless CMS have to be allowed in the configuration, and files in public/ bypass processing entirely. Documents get stable URLs and redirects so that externally linked PDFs do not break.

From two maintained languages with their own editors onwards, almost always the API-based one: language variants, translation status and per-language permissions are built in. Technically Astro handles localisation in any family – each language is a branch of the routing tree over the same content model. What is missing without a CMS is the workflow: nobody sees that the French version has fallen behind the German one. Budget build and sign-off time per additional language, not just translation cost.

Through a field-by-field mapping and a script, not through copy-paste. We take an inventory of the old model, map every field onto a field in the new schema, name explicitly what has no equivalent, and then import automatically – repeatably, so a second run shortly before launch refreshes the content. Media and internal references come along. For WordPress we describe both routes in detail: WordPress to Astro and WordPress as a headless CMS.

No, if we set it up that way from the start. Content access lives in a data layer of its own; pages query that layer, not the CMS directly. The switch then replaces the loader and the field mapping, not the templates. Work remains: moving the content, configuring preview and permissions, training the editors. That is why we deliberately keep the Zod schema close to what a later CMS can represent – it is half the migration, done in advance.

Yes, and you keep everything you need for it. The repository is yours from week one, CMS, hosting and domain accounts are in your name, and Astro is open source under the MIT licence. The repository holds the documented content model, the build and deployment steps and the encapsulated data layer, and any team working with JavaScript and Git can take over. With a self-hosted CMS, server, database, updates and backups then belong to your operations – the point where teams routinely underestimate the effort.

We are – under statutory warranty and without a new invoice, if preview, permissions or the build webhook do not behave as agreed. That is separate from a change request: an additional content type or a new field is a commission, not a defect. Which of the two categories a report falls into, we say before we start rather than afterwards. Fixed response and recovery times are agreed in writing; they belong in the maintenance agreement.

That the attack surface does not disappear, it moves – and becomes auditable in the process. The deployed build has no admin login and no database in the delivery path, so the familiar route through a vulnerable front-end plugin does not exist. What has to be reviewed instead: CMS accounts with mandatory two-factor and least privilege, API tokens and their expiry, permissions on the repository and the build pipeline, the provenance of npm dependencies, and form and webhook endpoints. Self-hosted systems add a server, a database, updates and backups.

With content collections, in your repository; with a self-hosted system, on your infrastructure; with an API-based CMS, at the vendor – whose hosting location and subprocessors we check before the selection and name to you. Editorial content is rarely personal data; form submissions, comments and analytics are where it gets sensitive. We list every service provider involved so your data protection officer can put the agreements in place. More on GDPR-compliant websites. We do not give legal advice; the sign-off stays with you.

Yes, that is a regular option here. Astro content lives in a typed, schema-validated model – content collections with Zod or a headless CMS – which makes it machine-addressable: an agent can only fill fields that exist, in formats that validate. A faulty edit fails in the build, not on the live site; every change becomes a traceable commit. Chat agents are day-to-day work for us; the proof is our own WhatsApp AI agent. It does not replace multi-stage approvals or structural layout changes. More on editing your website by chat.

Less than it sounds. Astro components are HTML, CSS and TypeScript; interactive islands are written in React, Preact, Svelte, Vue, SolidJS or Alpine.js. So you hire from the general JavaScript market, not from an Astro market, and the CMS side is documented by the vendor. What is true: there are more CVs with WordPress on them. Budget for onboarding, keep the content model small, and insist that the data layer is documented.

Because we would rather say so than invent one: we have no publicly showable Astro client project yet. What we do have is a Webflow reference we built and still maintain, including its editorial reality, our own products that we developed and shipped, and years of software development with repositories, continuous integration and operations. Checking us is cheap: the first assessment costs nothing, the repository is yours from day one, and the CMS recommendation arrives with the arguments against it.

Yes. Astro is open-source software under the MIT licence; there is no licence fee for the framework. Costs come from design, build, content, hosting and operations – and from the CMS, if you use one. Content collections cost nothing extra.

No. Astro ships content collections as a built-in way to manage content, but no editing UI. If you need one, you put a CMS on top – Astro stays CMS-agnostic and remains the presentation layer either way.

An editorial system without a front end of its own: it manages content and serves it over an API while another system renders the pages. Astro's documentation puts the division of labour like this: a CMS helps you write your content, but does not generate the site that displays it.

Not necessarily. By default the entire site is prerendered and served as static HTML, which runs on any CDN or static host. Preview routes, form handling or live collections add an adapter for the target runtime; officially maintained ones include Node, Vercel and Cloudflare.