What is a headless CMS, and why your AI-native site needs one
A headless CMS keeps your content as structured data and hands it over through an API, with no website attached. That separation is what lets an agent read and update your posts safely.
TL;DR
A headless CMS holds your content as structured records and serves them over an API, with no website attached.
Your blog post stops being a page and becomes a record: queryable, versionable, and editable by software as well as people.
Agents can only work with content they can address, which is why a site built by Claude Code, v0, or Lovable outgrows hard-coded JSX fast.
The price is setup work: preview, caching, webhooks, and revalidation all become your job.
Webhook-driven refresh and a tested preview mode are the two things to prototype before you sign anything.
Six posts a year on one channel does not need any of this, markdown in the repo is fine.
A CMS decides where content lives, it has nothing to say about whether the content is any good.
In this article
The short answer
A headless CMS stores your content as structured data and serves it over an API, with no front end bolted on. Your website asks for a post and renders it however it likes, and so can an app, a newsletter tool, or an agent. On a site built with an LLM, that separation is what lets software read and write your content safely, because every field has a name and a type instead of sitting inside a component file.
The trade is setup work. Preview, caching, and webhooks all become your job, where a traditional platform handled them for you.
What headless means
The head is the presentation layer, the templates and pages a visitor sees. WordPress ships both halves together, content in a database, theme on top, one system doing everything. A headless CMS keeps the body and drops the head, so content lives in a central repository and reaches your site through an API, reusable across platforms, devices, and applications.
That sounds abstract until you have tried to reuse a WordPress post somewhere other than WordPress. The body copy is welded to the theme, the layout, and a decade of plugin decisions, so pulling it into a newsletter or an app means scraping your own site.
Underneath, a headless platform is two things: a store where every piece of content has a defined shape, and an API that hands it over on request. Sanity describes those shapes as schemas declared in your codebase, objects that set out the structure, relationships, and constraints of your content. Contentful serves the result through a content delivery API that returns JSON from a CDN. Different products, same shape of idea.
The practical result is that your blog post stops being a page and becomes a record. A record can be queried, versioned, translated, syndicated, and rewritten by something other than a person clicking around an admin screen.
Coupled, headless, and the middle ground
Coupled platforms bundle content, design, and hosting together, which is why a marketer can edit a page in Webflow without asking anyone for help. Headless platforms hand you the content and leave rendering entirely to you. Webflow itself takes a hybrid route, visual editing on the front with API access behind it, and others have followed: Storyblok leads with a visual editor sitting on top of a structured, API-first backend, which is the compromise a lot of small teams end up wanting.
WordPress can be dragged into the same territory. Leave the content where it is, ignore the theme layer, and pull posts through the REST API into a separate frontend. You keep the editor your writers know, you get an API, and you inherit a content model built for themes rather than for structured data. Plenty of teams run it this way and it holds up, until you need fields the post schema never had.
Pick coupled when your team edits visually and your site is the only channel. Pick headless when your content feeds more than one surface, or when software needs to read it reliably. The hybrid middle is where you land when both are half true.
How the content reaches the page
Splitting content from presentation raises a question a coupled CMS answered for you: when does the page get built?
Three timings, roughly. Build time means your site generator fetches everything and produces static files, which is what Astro content collections do for a blog held in the repo or pulled from an API. Request time means the page calls the CMS on every visit, simple to reason about and slower under load. In between sits cached rendering with on-demand refresh, where pages are served static and a webhook from the CMS tells the site to regenerate the affected ones, which is how ISR on Vercel works.
The one to get right is the refresh. If publishing a correction means waiting for a scheduled rebuild, your editors will lose faith in the system inside a fortnight. Webhook-driven revalidation fixes that, and it is the first thing to test in a prototype rather than take on trust from a features table.
Preview is the twin problem. Unpublished content needs to render on the real layout for whoever is reviewing it, which frameworks handle with a dedicated mode: Draft Mode in Next.js bypasses the cache and fetches the draft at request time. Support for it varies a lot between platforms, and that variation deserves more attention than the marketing pages give it.
Why an AI-native site changes the requirement
Agents cannot work with content they cannot address. That is the whole argument, and it lands hardest on anyone who built their site with Claude Code, v0, or Lovable.
An agent asked to refresh a post needs to fetch that post, change the second section, and write it back. With a headless CMS, that is a query against a slug and an update to a field. With posts hard-coded into JSX, it becomes a code change, a pull request, and a redeploy, which is a lot of ceremony for correcting a stat from 2024.
Structured fields also keep the output honest. When title, excerpt, body, and meta description are separate fields with rules attached, an agent fills them correctly or fails loudly. When everything is one blob of HTML, you find out it went wrong on the live page.
Then there is approval. A content API that anything can write to is a bad idea, so you want drafts, roles, and a human signing off before publish. Our guide to CMS options for AI-native websites goes through which platforms give you all three.
The connection itself has standardised faster than anyone expected. Model Context Protocol servers give a model a defined set of tools against a system, so an assistant can list posts, read one, and write an update without anyone gluing together a bespoke integration for it. A CMS with a clean API is a short step from being addressable that way. A folder of JSX components is not.
Refresh work is where this pays back first. Updating 30 published posts against fresh search data is a week of manual labour, or an afternoon of agent time, provided every post is a record with a slug, a body field, and a date on it. Our notes on building an agent-friendly website cover the site-side half of the same job.
What to look for when you compare platforms
Feature tables all blur together after the third one. These are the things that decide whether you are still happy in a year.
Content modelling. Can you define the fields you need, with relationships between them, without writing a migration every time the site changes shape? This separates a CMS that grows with you from one you end up fighting.
API shape. REST returns a fixed payload per endpoint, GraphQL lets the frontend ask for exactly the fields it needs, which is what Hygraph built its whole platform around. Either works. Pick the one your developer, or your agent, will find predictable.
Editorial workflow. Drafts, roles, scheduled publishing, and a review step that exists before anything reaches the site. A CMS without this is a database with a nice font.
Hosting model. SaaS platforms take the operations off your plate and bill you monthly. Open source options like Payload or Directus hand you the whole thing to self-host, cheaper on paper, and it costs you patching, backups, and monitoring in practice.
Exit. Ask how content comes out before you put any in. JSON export, API access to everything, media files you can retrieve in bulk. A platform that makes leaving awkward will keep you long after it stopped fitting.
What headless costs you
Nobody mentions this part in the sales deck. Preview, cache invalidation, webhooks, and revalidation all need explicit configuration in your frontend, where a coupled CMS handed them to you as defaults. Editors lose the tightly integrated visual editing they were used to, and self-hosting adds patching, backups, and monitoring to somebody's week. Developers love headless right up until they are the ones maintaining it.
Pricing deserves the same scepticism. Entry tiers are generous, then the bill climbs with API calls, seats, locales, or environments, and arrives in a shape nobody modelled at signup. Ask what year two costs at triple your current volume.
The editor experience is the part people underestimate. Your writers move from a familiar page-shaped editor to a form full of fields with no sense of the finished layout, unless preview is wired properly. That change lands on the person least interested in your architecture, and when it slows them down, publishing volume drops within a month or two.
For a two-person team publishing four posts a month, that overhead is worth counting before you commit.
When you do not need one
If you publish six posts a year on a one-page site, markdown files in your repo are fine. If your whole team lives inside a visual builder and nothing else consumes your content, a coupled platform will serve you better and cost you less time. Headless earns its keep when content has more than one destination, or when agents are part of the publishing workflow. Sites shipped through prompt-to-code tools usually cross that line faster than their founders expect, which we covered in the CMS options for Claude-built sites.
The simple test is destinations and hands. One destination, one or two people, low volume: stay coupled or stay in markdown, you are buying nothing. Several destinations, agents doing part of the work, or a publishing schedule you keep missing because the process is painful: the setup pays for itself.
The content still has to come from somewhere
A headless CMS solves storage and delivery. It has nothing to say about what goes in the fields. Plug an agent into Sanity with no brand knowledge behind it and you get well-structured slop, delivered at speed, over a very fast API.
Contengi handles the other side. Your brand voice, strategy, rules, and source material live in a knowledge base built for AI to read, agents research and draft against it, and a review layer catches the draft before it reaches your CMS. There is two jobs here, and you want both done properly.
Frequently asked questions
What is a headless CMS in simple terms?
A headless CMS is a content store with no built-in website attached. It holds your content as structured data and delivers it through an API, so your site, app, or agent can pull it and display it however it needs to.
Is WordPress a headless CMS?
Not by default, though it can run headless. WordPress ships with its own theme layer, and you can bypass that by pulling content through the REST API into a separate frontend, which plenty of Next.js teams do.
Do I need a headless CMS for an AI-built website?
If you plan to publish regularly or let agents update content, yes. Structured fields and API access are what let software read and write your posts safely. For a small static site with occasional updates, markdown files in the repo are enough.
What is the downside of a headless CMS?
Setup and maintenance. Preview, caching, webhooks, and revalidation become your responsibility, and non-technical editors lose the visual editing a coupled platform provides. That work is manageable, it just needs somebody to own it.
Which headless CMS should a small team pick?
Sanity and Storyblok are the usual landing spots for small teams, with Payload for anyone who wants to self-host. The better question is who edits content day to day, because the interface they use every day counts for more than the API you will rarely touch.
Is a headless CMS the same as a static site generator?
No. A static site generator builds pages from content it is handed, while a headless CMS is where that content lives and gets edited. They pair well: the CMS holds the records, the generator turns them into pages at build time or on demand.
Can I move to a headless CMS later, or do I have to decide now?
You can move later. The expensive part is the migration itself, and how expensive depends on how your content is stored today. Content sitting in structured fields moves cleanly. Content buried inside page builders or hard-coded into components has to be pulled apart by hand first, which is the argument for storing it properly from the start.