Headless CMS and Sanity 5 min
Headless site with Astro and Sanity: who edits what, at what cost
A headless CMS is a content editing tool separated from the site that displays it. Writers work in an interface such as Sanity, and the site, built with Astro, fetches the content through an API at every publication and turns it into static pages. You keep the editing comfort of a WordPress with the speed and security of a site without an application server. It is only justified when several people publish regularly.
Headless, in one picture
In a classic CMS, editing and display live in the same software: WordPress stores your texts and builds your pages. In a headless set-up, the head is cut off. The CMS only stores and edits (the body), and a separate site, here built with Astro, takes care of the display (the head). The two talk through an API.
This split has a consequence visitors never see but your host, your rankings and your security lead notice immediately: the published site is static. The CMS is never exposed to visitors, it is not even on the same server. What the browser receives is HTML built at publication, as we explain in why migrate to a static site with Astro.
Do you need a CMS? The question that comes before all the others
A headless CMS costs modelling time, a subscription beyond a certain number of users, and one more layer to operate. So it is not justified on principle. The grid we apply comes down to four questions.
| Question | Files in the repository are enough | A headless CMS is justified |
|---|---|---|
| Who publishes? | One or two people, comfortable with a text editor or helped by a content engine | A team, external contributors, reviewers distinct from authors |
| How often? | A few pieces a month | Daily publications, product page updates, a calendar |
| What kind of content? | Articles and pages: structured text | Product sheets, authors, places, relations between contents, media in volume |
| What workflow? | Review is the review of the change before merging | Drafts, validation by role, scheduled publishing, visual preview for non-technical people |
Our own case illustrates the first column. This site was wired to Sanity in 2025. In September 2026 we brought the articles back into the repository, as Markdown files validated by a schema, because a single person was publishing and a content engine now writes drafts directly into the repository: human review is the review of the change, and publishing is a merge. A CMS would have been one more layer to pay for and maintain, for a comfort nobody used.
Conversely, an agency where five people write, one manager validates and a designer manages visuals needs an editing tool, a preview and roles. That is where Sanity takes its place.
How Astro and Sanity fit together
Sanity is not a WordPress without a theme: it is a hosted content database, with an editing studio whose model is defined in code. Five mechanisms hold the set-up together.
- The content model in code. You describe your types (article, author, offer, case study) and their fields in files versioned with the site. The editing studio follows from them. Adding a field is a reviewed code change, not a click in an interface nobody documents.
- Structured rich text. Sanity stores rich text in a structured form (Portable Text) rather than HTML: the site decides the rendering, and the same content can feed a page, a feed, an application or an AI assistant.
- The official Astro integration. Sanity publishes an official integration for Astro: the site queries the content at build time and turns it into static pages. Queries are written in GROQ, Sanity’s query language, which fetches only what a page needs.
- Publishing triggers the rebuild. A webhook notifies the host at every publication. The site rebuilds and redeploys in a few minutes. Between two publications, nothing runs.
- Preview and visual editing. Writers see the page as it will be published, with their drafts, before clicking publish. That is what makes the set-up acceptable for a non-technical team.
What the set-up does not change: the published site remains a folder of files served by a CDN, with the same automatic checks (links, sitemap, hreflang, structured data) as a static site without a CMS.
What it really costs
Three items, and none is hidden.
The Sanity subscription. Prices checked on 3 September 2026 at sanity.io/pricing: the Free plan is $0 for up to 20 users and 2 public datasets. The Growth plan is $15 per user per month, up to 50 users, with private datasets, comments, scheduled publishing and AI assist. The Enterprise plan is on quote. For a small business with five writers, the Free plan is often enough as long as the content can be public. Moving to Growth is decided on roles and confidentiality, not on volume.
Site hosting. That of a static site: a few euros a month, with no server to administer.
The set-up. It is the main item, and it is paid once: content modelling, studio, Astro templates, preview, webhooks, migration of existing content, training. In our static site migration offer, the headless tier with Sanity starts at €8,900 excluding VAT.
The traps we have seen
- Putting everything in rich text. A product sheet whose price sits in a paragraph cannot be filtered, sorted or displayed elsewhere. Whatever has business meaning becomes a field.
- Modelling too early. A content model designed before ten real pieces have been written is almost always wrong. Write first, model afterwards.
- Forgetting the preview. Without a visual preview, writers publish to see, and the site rebuilds twenty times a day.
- Neglecting languages. Multilingual content is modelled from the start (one document per language or fields per language), otherwise the second language costs as much as the first.
- Confusing headless with bespoke. The CMS does not exempt you from careful templates or build-time checks. It moves the editing, not the quality.
Frequently asked questions
Sanity or another headless CMS? Sanity is our default choice for its model in code, its structured rich text and its wide free plan. Other tools fit better in some cases (very file-oriented content, hosting that must stay in-house). The scoping says so on evidence.
Do my writers have to learn Git? No. With a headless CMS they work in the editing studio with a preview. Git stays the business of the publishing chain, invisible to them.
What happens if Sanity goes down? The published site does not depend on Sanity to display: it is static. Only the publication of new content waits for the service to come back.
Can I start without a CMS and add one later? Yes, and it is often the right sequence: Astro reads content from wherever it comes from. You start with files, measure who publishes, and plug Sanity in the day the team needs it.