A headless CMS separates where content is managed from where it's displayed. Instead of one system that stores your pages and also renders them, a headless CMS stores content and serves it through an API, while a separate front end, often built with a framework like Next.js, turns it into a website, app or anything else. It's a powerful setup, but it isn't right for everyone. Here's how it works and how to decide.
Traditional vs headless CMS
| Traditional CMS (e.g. WordPress) | Headless CMS (e.g. Sanity, Contentful) | |
|---|---|---|
| Content and design | Managed together in one system | Content managed separately from the front end |
| Front end | Themes and templates | Custom-built in any framework |
| Channels | Mainly one website | Website, apps, kiosks, email and more |
| Editing experience | Familiar page editing and previews | Structured content; previews need setting up |
| Speed | Depends on theme and plugins | Usually very fast with static or edge rendering |
| Developer needs | Lower for simple sites | Higher: a front end must be built and maintained |
| Typical cost | Lower to start | Higher to build, can be efficient at scale |
How a headless setup works
- Editors create content in the CMS as structured entries: a case study has a title, client, summary, images and results, rather than one big block of text.
- The CMS exposes that content through an API.
- The front end requests the content and renders pages, often ahead of time (static generation) or on the server.
- The same content can feed other channels, such as a mobile app or an in-store screen, without being re-entered.
The real advantages
- Speed: front ends built with modern frameworks and served from a CDN can be extremely fast, which helps Core Web Vitals.
- Flexibility: designers and developers aren't constrained by a theme system.
- Multi-channel content: write once, publish to the website, app and partners.
- Security: the CMS isn't exposed on the public site, reducing the attack surface.
- Structured content: content becomes reusable data, easier to keep consistent and to feed to AI tools and search engines.
The real disadvantages
- Higher build cost: you're building a custom front end, not installing a theme.
- Previews take work: editors expect to see changes before publishing; headless setups need preview configured.
- More moving parts: CMS, front end and hosting must all be maintained.
- Plugin gaps: features WordPress gets from a plugin, like forms or SEO tools, may need building or integrating.
- Editor learning curve: structured content is cleaner but feels different from page builders.
Popular headless CMS options
| CMS | Best for | Hosting | Notes |
|---|---|---|---|
| Sanity | Flexible content models, real-time editing | Cloud | Highly customisable editing studio |
| Contentful | Larger organisations, many channels | Cloud | Mature, enterprise features |
| Storyblok | Marketing teams wanting visual editing | Cloud | Strong visual editor |
| Strapi | Teams wanting to self-host | Self-hosted or cloud | Open source |
| Payload | Developer-led projects on Next.js | Self-hosted or cloud | Open source, code-first |
| Headless WordPress | Teams who know WordPress | Self-hosted | Familiar editor, custom front end |
When headless is worth it
- Your site is performance-critical, such as e-commerce or high-traffic content.
- You publish the same content to several channels.
- You need a highly custom design or app-like features.
- You have, or will have, developers to maintain the front end.
- Content is highly structured: products, locations, case studies, documentation.
When it probably isn't
- A small brochure site that changes a few times a year
- A team that relies on drag-and-drop page building
- A tight budget with no ongoing developer support
- A marketing team that needs to build new page layouts without help
In those cases a well-built WordPress or Webflow site may serve you better. Our comparison of Next.js vs WordPress explains the trade-offs in more detail.
SEO in a headless world
Headless sites can rank brilliantly, but only if the front end handles the basics:
- Server-side or static rendering, so search engines get complete HTML (see our guide to JavaScript SEO)
- Editable titles, descriptions and canonical tags for every page
- Structured data generated from content fields
- XML sitemaps that update automatically when content changes
- Redirect management that editors can use
Questions to ask before choosing
- Who will edit content, how often, and how technical are they?
- Which channels does content need to reach now and in two years?
- Who will maintain the front end after launch?
- What integrations do you need: e-commerce, search, forms, CRM?
- What's the total cost over three years, including hosting and maintenance?
A worked example: a growing services firm
Imagine a consultancy with 40 service pages, 200 articles and plans for a client app.
| Need | Traditional CMS | Headless CMS |
|---|---|---|
| Fast pages for SEO | Possible with careful theme and plugin choices | Fast by default with static or server rendering |
| Same case studies on site and in the app | Content copied manually | One source, published to both |
| Marketing team builds new landing pages | Easy with page builders | Needs a block library designed upfront |
| Strict brand consistency | Depends on editor discipline | Enforced by structured fields |
In this case, headless makes sense, provided the team invests in a library of flexible content blocks so marketers can still assemble new pages without developers.
Moving from WordPress to headless: what's involved
- Model the content: turn pages and posts into structured types such as services, case studies and team members.
- Migrate content: export, clean and import, often with scripts for large sites.
- Build the front end: templates, components and previews.
- Recreate SEO features: titles, descriptions, sitemaps, redirects and schema.
- Train editors on the new workflow.
- Redirect old URLs if any paths change.
A partial approach also works: keep WordPress as the editing tool and use it headlessly, so editors keep a familiar interface while the front end gets faster.
How we approach it
We build both traditional and headless sites, and recommend one after understanding how your team works. For many clients a custom business website in Next.js with a structured CMS is ideal; for others, WordPress development is the better fit.
The short version
A headless CMS manages content separately from the front end and delivers it through an API. It offers speed, flexibility and multi-channel publishing, at the cost of higher build complexity and the need for developers. Choose it for performance-critical, multi-channel or highly custom projects; choose a traditional CMS for simpler sites edited by non-technical teams.
