What is a headless CMS, in plain English?
A headless CMS is a place to write and organize content that sends that content to a website through an API instead of building the pages itself. The website, often built in a framework like Next.js, asks the CMS for the content and decides the layout, fonts and colors.
The name comes from separating the body (the content store and editor) from the head (the front end visitors see). Because content isn't tied to one design, you can redesign without moving it. You'll also hear it called a decoupled CMS. For how it fits a full marketing setup, start with our guide to CMS setup for marketing websites.
Headless vs traditional CMS: what's the difference?
A traditional CMS stores content and renders the pages in one system, while a headless CMS only stores content and leaves rendering to a separate front end. Website builders like Webflow and Framer sit in between: they bundle a CMS with a visual design tool and hosting.
Type | Who builds pages | Examples | Best for |
|---|---|---|---|
Traditional CMS | Themes and templates inside the CMS | Classic WordPress | Content sites with plugin needs |
Visual builder with CMS | Designers in a visual editor | Webflow, Framer | Marketing sites run by designers |
Headless CMS | Developers in a separate front end | Sanity, Contentful, Payload, Strapi | Custom sites, multiple channels, structured content |
Why does a headless CMS matter for marketers?
For marketers, a headless CMS matters because it changes who can do what. Content edits become easy and safe, but layout changes depend on what the developers built. If the team building it designs good blocks, fields and previews, editors get freedom without breaking the site. If not, every change becomes a ticket.
That's why headless CMS complaints are mostly about the editing layer, not the brand of CMS: confusing fields, no preview, and no way to build a new page. The fixes are reusable page builder blocks, live preview and visual editing, and sensible roles and permissions.
Example: one customer story, three places
For example, suppose a SaaS company publishes customer stories. In a headless CMS, each story is an entry with fields: company, industry, challenge, quote, person, role and logo.
The website shows the full story on its own page. The home page pulls just the quote and logo into a proof strip. The pricing page shows two quotes from customers on the top plan. An editor updates the quote once, and all three places change, because the content is stored as structured fields rather than pasted into three pages.
What are common mistakes with a headless CMS?
The most common mistake is treating headless as a developer decision and forgetting the editors. Content models get designed around the code, previews come last or never, and marketing ends up with a CMS they avoid.
- No preview. Editors publish blind and learn what broke from customers.
- One giant rich-text field. You lose the structure that made headless worth it.
- Too many fields. Every page type has 40 inputs and nobody knows which matter.
- No owner. Nobody prunes old fields or updates help text after launch.
- Choosing the CMS first. Pick the editing workflow you need, then the tool that supports it.
How does a headless CMS relate to other terms?
A headless CMS connects to a few related ideas. The content model is the structure of types and fields inside it, covered in content modeling for SaaS sites. The front end is the code that renders pages, often a framework like Next.js. An API is how the two talk. Composable or Jamstack architecture describes building a site from separate services like these, with pages often prebuilt and served from a CDN.
If you already have a site on a builder and wonder whether to move, that's a different question, covered in our guides on Webflow CMS to a headless CMS and headless CMS migration.
