What each one is
A traditional CMS manages content and presents it. Editors write in the same system that builds the public pages, using its themes and templates. WordPress and many other long-established systems work this way, and for a website alone the arrangement is hard to beat for convenience.
A headless CMS manages content and stops there. It stores each piece in a structured form and makes it available through an API. A separate front end, written by developers, asks for the content and decides how it looks. The same content can then be shown on a website, in an app or anywhere else that can call the API.
The two at a glance
| Traditional CMS | Headless CMS | |
|---|---|---|
| What it does | Stores content and renders the pages | Stores content and serves it by API |
| How content is shaped | Mostly as pages, written top to bottom | As structured types with fields, such as product, author or FAQ |
| Editing | On or near the page, with an instant view of the result | In forms. A preview shows the result once it is set up |
| Design | Themes and templates of the system | Any front end the developers build |
| Reuse | Content belongs to the page it was written on | One piece of content can appear in many places and channels |
| Features | Plugins for most needs | Built in the front end, or added through services |
| Team | Editors, with occasional developer help | Editors, plus developers for every new layout |
| Running it | One system to host and update | A CMS service and a front end, each with its own upkeep |
When each one fits
Choose a traditional CMS when
- The website is the only place the content appears
- Editors build pages freely and want to see them as they work
- Plugins cover the features you need
- No developer will be on hand after launch
- The budget is modest and the site is mostly content
Choose a headless CMS when
- The same content feeds a site, an app, screens or partner feeds
- The front end is custom, for speed or for design
- Content is naturally structured, such as products, locations or courses
- Several sites or languages should share one content source
- Developers are part of the team for the long run
The work headless asks for first: a content model
A traditional CMS lets you start typing. A headless CMS asks a question first: what kinds of content do you have, and what is each made of? The answer is the content model, and its quality decides whether editors enjoy the system or fight it.
- 01
List your content types
Service, case study, team member, article, location, FAQ. Things, not pages.
- 02
Give each its fields
A case study has a client sector, a challenge, an outcome and images. Name them.
- 03
Connect them
An article has an author. A service lists related case studies. Links replace copying.
- 04
Leave room for pages
Landing pages need flexible sections that editors can arrange, within limits you set.
- 05
Test with real content
Enter ten real items before any design is final. Gaps show at once.
What to ask for on behalf of your editors
The usual complaint about headless is that editors cannot see what they are doing. That is a matter of setup, not a law. Four things make the difference, and they should be in the brief.
- Preview. A button that shows the draft on the real site before it is published.
- Flexible page sections. A set of blocks editors can add, order and remove on landing pages without a developer.
- Roles and approval. Who can draft, who can publish, and a record of what changed.
- Languages. If you publish in more than one, translation should be part of each item, not a copy of it.
Our comparison of Next.js and WordPress looks at the same decision from the side of the whole website.
A worked example
A consultancy and a hotel group
Both organizations are invented.
- The consultancyHas one website with service pages and a blog. Two people publish, and they like arranging each page by hand.
- Its decisionA traditional CMS. The content lives in one place, and page-by-page freedom is what the editors value.
- The hotel groupRuns 12 hotels. Room types, facilities and offers must appear on the group site, on each hotel's site, in the booking app and on lobby screens, in four languages.
- Its decisionA headless CMS. Each room and offer is entered once and shown wherever it is needed.
The consultancy writes pages. The hotel group manages information, and information wants structure.
A checklist to decide
Tick what applies. The first four favor a traditional CMS and the last four a headless one.
Traditional or headless CMS
0 of 8 checkedWhat to do next
Write down every place your content needs to appear over the next few years, and who will edit it. One place and free-form pages point to a traditional CMS. Several places and repeating types point to headless. Our guide to writing a website project brief has a section for exactly this.
If you would like help drawing the content model, get in touch.
Common questions
Is a headless CMS harder for editors to use?
It is different. Editors fill in structured forms instead of arranging a page, which is quicker for repeating content and less free for one-off layouts. With preview and a set of flexible page sections in place, most editors adapt quickly. Without them, editing feels blind. Ask to see the editing screens and the preview before you approve a headless build.
Can WordPress be used as a headless CMS?
Yes. WordPress can serve its content through an API while a separate front end displays it. Editors keep the interface they know, and the public site gains the speed and design freedom of a custom front end. You do take on two systems, and some plugins that alter pages stop having any effect, so check which ones you rely on.
Does a headless CMS improve SEO?
Not by itself. Search engines see the pages, not the CMS. Headless setups often produce faster, cleaner pages because the front end is purpose-built, and that helps. They can also hurt if titles, descriptions, redirects and sitemaps, which traditional systems handle through plugins, are forgotten. Put those items in the brief and test them before launch.
What happens to our content if we change the website later?
With a headless CMS, very little. The content stays in the CMS and a new front end reads it, which is one of the main reasons to choose the approach. With a traditional CMS, content and design are more entangled, so a redesign often means reworking pages. Structured content is easier to move in either case.
