How it works
Editors write and organise content in an admin screen. The CMS stores it in structured fields (a title, a summary, a date, an image) and exposes it through an API, usually REST or GraphQL. Your website or app fetches that content and decides how to show it. Tools such as Strapi, Sanity and Contentful work this way; our CMS comparison looks at the differences.
Headless and traditional CMS compared
| Question | Traditional CMS | Headless CMS |
|---|---|---|
| Where is the front end? | Built in, through themes or templates | Separate, built with a framework such as Next.js |
| How does content reach visitors? | The CMS builds the pages itself | The front end fetches content through an API |
| Reusing content | Harder, because it is tied to pages | Easier, because one entry can feed a site and an app |
| Setup effort | Lower to start | Higher, because you build the front end |
WordPress can also be run headless, so the choice is about architecture, not about the product name.
When it fits
It suits teams that publish to more than one channel, need a custom front end, or manage several languages with a strict structure. For a small brochure site that one team edits, a traditional CMS is often simpler to run. Multilingual teams should check how each product handles locales; our article on CMS choices for multilingual teams goes through it.
Common mistakes
- Choosing headless for a simple site that does not need it.
- Forgetting preview. Editors need to see content as it will look before they publish.
- Modelling content as page layouts instead of reusable, structured fields.
- Leaving the content API open. Published content can be public, but write access and drafts must be protected.