Headless CMS has gone from a niche architecture to something that comes up in almost every larger website conversation. Some of that interest is justified. Some of it comes from teams adopting an approach designed for complex, multi-channel publishing when what they need is a well-built marketing site.
This article explains what headless actually means, what you gain, what you give up, and the signs that it is or is not the right choice for you.
What headless means
A traditional CMS such as WordPress does two jobs. It stores and manages your content, and it also renders the web pages that visitors see, using themes and templates. The content and the presentation live in the same system.
A headless CMS only does the first job. It stores content in a structured way and makes it available through an API. A separate application, often built with a framework such as Next.js, Nuxt or Astro, requests that content and turns it into web pages. The same content can also be sent to a mobile app, a digital display, an email system or anything else that can read from the API.
The “head” is the presentation layer. Headless means the CMS has none of its own.
The main headless options
There are many headless platforms, and they vary more than the label suggests.
- Sanity is highly customisable, with content schemas defined in code and an editing studio you can shape around your team.
- Contentful is a mature hosted platform popular with larger organisations, with strong governance and localisation features.
- Storyblok stands out for its visual editor, which lets marketers see and arrange components on the page.
- Strapi is open source and can be self-hosted, which appeals to teams who want control over their data and infrastructure.
Several traditional platforms can also run headless. WordPress has a REST API and a GraphQL option through plugins, Craft CMS has a GraphQL API built in, and Drupal has long supported decoupled setups. Shopify offers a headless approach for stores through its Storefront API.
When headless makes sense
You publish to more than one channel
If the same product information, articles or help content needs to appear on a website, in an app and elsewhere, a headless CMS lets you manage it once. This is the original reason the approach exists, and it is still the strongest one.
Your front end is genuinely complex
Some sites are closer to applications than brochures: interactive tools, personalised dashboards, product configurators, heavy integrations with other systems. A modern front-end framework handles this better than a traditional theme layer, and a headless CMS fits in alongside it naturally.
You have a development team who will own it
Headless works best when there is an ongoing development team, in-house or a long-term partner, who can maintain the front end, add new components and keep the build pipeline healthy.
Content structure matters more than page layout
Headless platforms encourage you to model content as structured data rather than free-form pages. For organisations with large, consistent content libraries, that discipline pays off in reuse, consistency and easier future redesigns.
When it doesn’t
Headless is often the wrong choice for a typical marketing site with a small team. Here is why.
- Higher build cost. You are building a CMS configuration and a custom front end. Things that come free with a traditional CMS, such as previews, sitemaps, search, forms and redirects, have to be built or connected.
- Two systems to maintain. The CMS and the front end both need updates, hosting and monitoring. If either breaks, the site breaks.
- Editors depend on developers. In many headless setups, marketers can only build pages from the components developers have created. A new type of section usually means a development ticket.
- Preview takes effort. Showing editors what their changes will look like before publishing is possible with every major headless CMS, but it needs to be set up properly and maintained.
- More moving parts in your subscriptions. Headless CMS plans, front-end hosting, search services, form services and image services can add up.
Ask your team to describe the last five changes they made to the website. If they were all copy edits, new blog posts and new landing pages, a well-built traditional CMS will probably serve you better than a headless one.
Traditional, hybrid or headless
| Approach | Good fit | Watch out for |
|---|---|---|
| Traditional CMS | Marketing sites, small teams, content-led businesses | Plugin sprawl and theme limitations over time |
| Hybrid (traditional CMS with an API) | Mostly website content with some reuse in an app or other tool | Keeping two output paths consistent |
| Fully headless | Multi-channel publishing, complex front ends, dedicated dev team | Build cost, editor flexibility, ongoing maintenance |
The hybrid route deserves more attention than it gets. Keeping a traditional CMS for the website while exposing some content through an API often gives you most of the benefit with far less complexity.
Questions to settle before going headless
- Which channels, apart from the website, will use this content in the next two years?
- Who will maintain the front end after launch, and how quickly can they respond to requests?
- How much layout freedom do editors need, and can a component library give them that?
- How will previews, search, forms and redirects work?
- What are the ongoing subscription and hosting costs for every service involved?
If the answers are clear and the benefits are concrete, headless can be an excellent choice. If the main reason is that it sounds modern, it is worth stepping back.
Getting advice
If you are deciding between headless and a traditional build, get in touch and we can look at your requirements with you.
