Most CMS conversations start with technology and end with the editors finding out what they got. We prefer to start at the other end, with the person who presses Publish and the three or four things they change every week. Once you know who edits, how often, and where the content has to appear, the choice between a traditional and a headless CMS is usually smaller than it looked in the first meeting.
Two ways to get from an edit to a page
A traditional CMS, meaning WordPress, Drupal, Joomla and the like, keeps content and rendering in one application. The editor writes in the admin, a theme turns that into HTML, and plugins add features to the same install. One login, one server, one thing to keep updated. For a lot of sites that is exactly the right amount of moving parts.
A headless CMS only stores and manages the content. Contentful, Strapi, Sanity and Storyblok are the names you will hear most, and WordPress itself can run headless too. The CMS hands content out over an API, REST or GraphQL, and your own frontend decides what the page looks like. That frontend can be a Next.js site, a mobile app, or both reading the same entries.
- Editor writes in the admin
- Theme renders the page
- Plugins extend the same app
- Content and design live together
- Editor writes in the admin
- API returns structured content
- Your frontend renders the page
- A mobile app can read the same API
The difference is where rendering happens and who owns it.
Notice that the first line is the same in both columns. Editors still write in an admin screen either way. What changes is everything after they press Save.
What the editor actually sees
In a traditional CMS the editor is working on a page. They type into something that looks roughly like the finished result, click Preview, and see the page in the site's theme. If the theme has a page builder, they can also move sections around. People who have used WordPress for a few years know where everything is, and that familiarity is worth more than most feature lists admit.
In a headless CMS the editor is working on an entry. It is a form with named fields, and the page is assembled somewhere else. Take a coaching institute in Kota that publishes batch schedules, fee notices and result lists. On a traditional site the batch schedule is a page that somebody formats by hand each time. In a headless setup it is a batch entry with a course, a centre and a start date, and the website, the student app and the WhatsApp notification template all read the same record.
{
"type": "batch",
"course": "JEE Main crash course",
"centre": "Talwandi",
"startDate": "2026-01-12",
"seatsOpen": true
}
The editor fills five fields and never touches a layout. The catch is that they also cannot see the result unless someone has built a preview that shows the entry in the real layout. Keep that in mind, because it comes back in the mistakes section.
Comparing them on what changes your plan
| Attribute | Traditional CMS | Headless CMS |
|---|---|---|
| Architecture | One application for content and pages | Content store and frontend are separate |
| Frontend control | Bound by the theme system | Any framework your developers build with |
| Other channels | Possible, but the website comes first | Same entries served to web, apps and other clients |
| Time to first page | Short, themes and page builders exist | Longer, the frontend has to be written |
| Editor preview | Usually built in | Has to be built or bought |
| Performance | Depends on theme, plugins and caching | Depends on how the frontend is built and hosted |
| Security surface | Admin, plugins and rendering share one app | Public pages can be static, with the admin kept separate |
We put "depends" against performance on purpose, because people assume headless wins it automatically. It does not. A headless site that fetches every entry at request time from a CMS hosted on another continent will feel slower to a visitor on 4G in Lucknow than a well-cached WordPress site on a nearby host. Headless gives you the option of being fast and keeping the public site small. The build still has to take that option.
The mistakes that cost the most
The most common one is going headless and only afterwards realising the editors have lost their preview. In WordPress you click Preview and see the page. In a headless setup that preview is something a developer has to build, and until it exists editors either publish blind or message someone to check staging. That message is the exact developer dependency headless was supposed to remove.
The second is modelling content around page layouts instead of around what the content is. If the content type is called "homepage hero", the mobile app cannot reuse it. If it is called "announcement" and has a title, a summary and an image, anything can read it. Content model first, screens second. It is cheap to fix on a whiteboard and expensive to fix after two hundred entries exist.
The third runs the other way, and it is the more wasteful one. A firm with one website, one marketing person and no in-house developers picks headless because it sounds future-ready, then pays someone for weeks to rebuild what a theme already gave them. If that sounds like your situation, our piece on what to do instead of relying on a free CMS covers the middle ground.
Four questions, asked in order
Go through these in order and stop at the first one that fits, because each later question only matters if the earlier ones did not settle it.
- Is the content shown on one website only, and edited by people who are not technical? Start with a traditional CMS.
- Must the same content appear in more than one place, such as a website, a mobile app and an internal dashboard? Use a headless CMS, or a headless setup of WordPress, from the start.
- Do you have frontend developers who want control over rendering and hosting? Headless is a reasonable fit.
- Can you name who will build and maintain the preview and the frontend? If not, do not choose headless yet.
The fourth question is the one teams skip. A name next to "preview" tells you more about whether headless will work than any vendor comparison.
One content set, several places
Take a D2C brand that sells on its own site and on marketplaces, with a React storefront, an Android app and an internal dashboard for the operations team. Product descriptions, size guides and offer banners should read the same in all three. On a traditional CMS each extra client needs a plugin or hand-written endpoints, and the content still carries the shape of the website's templates. A headless CMS gives all three the same structured entries, and each one lays them out its own way. When the Diwali offers change on a Sunday night, one edit updates the storefront and the app together.
- 01Editorsaves an entry
- 02Content APIREST or GraphQL
- 03Frontendweb or app
- 04Visitor
Each client calls the same content API and renders the entry its own way.
For a small business site or a personal blog the same reasoning points the other way. WordPress with a decent theme gets it online quickly, and the person editing it already knows where everything is. If you land on headless with Next.js, the piece on what editors need from a headless CMS for Next.js goes through previews, build times and reusable blocks in more detail.
What to do this week
Write down three things on one page: who edits, how often, and every place the content has to appear. If the last answer is "one website", price a traditional setup first and be honest about how many plugins it will need. If it is several places, sketch the content types and the preview before you compare vendors, because those two will shape the build more than the vendor does. When you have that page, it is also the right brief to bring to a CMS development team, whichever way you lean.
