A headless CMS stores your content and hands it to any website or app through an API, without deciding how it looks. Here is how that works, which platforms do it, and when it is worth the extra setup.
"Headless" is one of those words that sounds more complicated than the idea behind it. Strip away the jargon and it is a simple split: one system holds your content, another decides how it looks. That split changes how fast your site loads, how safely it runs and how easily it can grow. It also adds cost and moving parts, which most explainers skip. This one does not.
What is a headless CMS?
A headless CMS is a content management system that stores and organises content but does not build the pages people see. It delivers that content through an API to a separate front end, such as a Next.js website or a mobile app, which decides how it looks. The "head" is the presentation layer, and a headless CMS simply does not have one.
Think of a traditional CMS as a restaurant that cooks and serves. A headless CMS is the kitchen alone. It prepares the content, and any number of front ends can take it out to the table, each plating it in their own way.
How does a headless CMS work?
Behind the scenes there are five steps, and editors only ever see the second one:
- Content is modelled. A developer defines the types of content you have, such as pages, posts, products or team members, and the fields each one holds.
- Editors write. They log in to the CMS, fill in those fields, upload images and press publish, much as they would anywhere else.
- The CMS serves content through an API, usually REST or GraphQL, as structured data rather than finished HTML.
- The front end fetches that content and turns it into pages, either ahead of time at build or when a page is requested.
- Publishing triggers an update. A webhook tells the front end which pages changed, and those pages refresh without a full rebuild.
Picture an editor adding a new case study. They fill in a title, a summary, a few images and a results section, then publish. Within moments the case study page exists on the website, appears in the work index, and shows up in the mobile app's portfolio screen. Nobody touched the code, and visitors never connected to the CMS itself.
Headless vs traditional CMS: the key differences
A traditional CMS such as WordPress or Drupal bundles content, design and delivery into one system. A headless CMS keeps only the content part. Here is what that changes in practice:
| What changes | Traditional CMS | Headless CMS |
|---|---|---|
| What it does | Stores content and renders the pages | Stores content and serves it through an API |
| Where the design lives | In a theme inside the CMS | In a separate front end built in code |
| Channels | Mainly one website | Websites, apps, kiosks, email, anything that can call an API |
| Speed | Depends on themes, plugins and caching | Fast when the front end pre-renders pages |
| Security | Public admin and plugins on the same server as the site | CMS kept away from visitors, smaller attack surface |
| Redesign | Often means rebuilding content inside a new theme | Swap the front end and keep every piece of content |
| Cost to start | Lower, especially with a ready-made theme | Higher, because a developer builds the front end |
| Who can launch it | Anyone comfortable installing a theme | A developer or a headless CMS development agency |
Neither column is better for everyone. The traditional column wins on cost and speed to launch. The headless column wins on almost everything that matters once the site is a serious sales channel.
Why choose a headless CMS?
Teams that go headless usually do it for one of these reasons, and the strongest cases have several at once:
- Speed. The CMS is not in the loading path. Visitors get pre-rendered pages from the front end, which helps Core Web Vitals and conversions.
- Security. There is no admin login on your public domain and no stack of front-end plugins to patch every week.
- Freedom to redesign. Content is stored as structured data, not tangled in a theme, so a new design does not mean a content migration.
- One source, many channels. The same product details, FAQs or locations feed the website, an app and anything else, edited once.
- A better editing screen. The editor is shaped around your content, with fields that make sense to your team instead of one big text box.
- Room to grow. Adding a new section, a new language or an app means extending the model, not starting over.
The downsides of a headless CMS
This is the part sales pages leave out. Going headless has real costs, and you should weigh them before anyone builds anything:
- A front end has to be built and maintained by developers. There is no theme to install.
- Two systems instead of one: the CMS and the website each have hosting, updates and accounts.
- Live preview of unpublished drafts does not come free. It has to be wired up between the CMS and the front end.
- Plugins you relied on in a traditional CMS, such as forms, search or SEO tools, become separate services or code.
- A badly designed content model is painful to fix later, and editors feel every mistake in it.
None of these is a reason to avoid headless. They are reasons to plan the content model properly and to work with people who have done it before.
Headless CMS examples: the main platforms
The platforms below are the ones that come up most often in projects. They all serve content through an API. They differ in hosting, editing style and who they suit.
| Platform | How it runs | Best suited to |
|---|---|---|
| Sanity | Hosted content platform with an editing studio you customise in code | Teams that want an editor tailored closely to their content |
| Contentful | Hosted service with a fixed editing interface | Larger editorial teams and many locales |
| Strapi | Open source on Node.js, self-hosted or on Strapi Cloud | Teams that want control of their data and server |
| Payload | Open source, written in TypeScript, can live inside a Next.js app | Developer-led teams that want the CMS in the same codebase |
| Storyblok | Hosted, with a visual editor for arranging blocks on the page | Marketers who want to see the page while they build it |
| Hygraph | Hosted, built around GraphQL | Projects that pull content from several sources into one API |
| WordPress (headless) | Your existing WordPress, read through its REST API or WPGraphQL | Teams attached to the WordPress dashboard |
The right pick depends more on your editors than your developers. If the people publishing every day hate the editing screen, the platform was the wrong choice, however elegant its API.
Headless CMS examples: what businesses build with one
Platform names only go so far. These are the kinds of sites where headless genuinely earns its setup cost:
- Marketing sites where the team launches landing pages every week from a library of approved blocks.
- Sites in several languages, with translators working in the same editor as the original authors.
- A website and a mobile app that must always show the same prices, services or menu.
- Directories and listings, such as properties, clinics or locations, where each record becomes its own page.
- Help centres and documentation written by support staff rather than developers.
- Brands running several sites or regions from one pool of content.
Does a headless CMS help SEO?
It helps when the front end is built properly, and the help comes from the front end. A Next.js site on a headless CMS can send complete HTML to search engines, load quickly on phones, and set titles, canonical tags and structured data precisely for every page. Those are real advantages over a slow, plugin-heavy site.
It hurts when the build cuts corners. Content rendered only in the browser, SEO fields missing from the content model, and old URLs left without redirects after a move all cost rankings. Ask how a team handles those three before you hire them.
How much does a headless CMS cost?
There are two separate costs. The platform itself, where open source options can be self-hosted and hosted services usually offer a free tier with paid plans by seats, usage or features. And the build: modelling content, setting up the editor, building the front end and moving existing content across. The build is almost always the larger number.
What moves it is the number of content types, how much freedom editors need to compose pages, how many languages you run, and how much content has to migrate. For the front-end side in more detail, see our breakdown of what a Next.js website costs, and when you want a real number, our headless CMS development team quotes a fixed price on a written scope.
When you do not need a headless CMS
Be suspicious of anyone who says every site should be headless. You probably do not need it if:
- One person runs a small blog and wants to pick a theme and publish today.
- The site has a handful of pages that change a couple of times a year.
- There is no developer on your side and no budget to keep one on call.
- Your current site is fast, secure, easy to edit and bringing in enquiries.
In those cases a well-built traditional CMS, or even content kept in the codebase, is cheaper and perfectly good. Our comparison of Next.js and WordPress goes through where that line sits.
Going headless without leaving WordPress
If your team already writes in WordPress, you do not have to retrain anyone. WordPress can act as a headless CMS through its built-in REST API, with a Next.js front end serving the public site. Editors keep their dashboard and visitors get a faster, safer site.
The move needs care, because every old URL has to land somewhere. Our WordPress to Next.js migration work covers the redirect map, metadata and content scripts that keep rankings intact.
How to choose a headless CMS development agency
The platform matters less than the people setting it up. Before you hire a headless CMS development agency, ask them these questions:
- Which platform would you recommend for us, and why that one rather than the one you usually use?
- How will you design the content model, and will our editors see it before the build?
- How do previews of unpublished drafts work?
- How are SEO fields, redirects and structured data handled?
- Who owns the CMS account, the hosting and the code at the end?
- What does training for our editors look like?
A good answer to the first question names your editors and your content, not a favourite tool.
Thinking about going headless?
Tell us what your site does today, who edits it and what you want it to do next. We reply within one business day and will tell you honestly whether headless is worth it for you, or whether a simpler setup does the job. See how our headless CMS development service works, or start a project.
FAQ
Frequently asked questions
Not by default. Out of the box WordPress is a traditional CMS that stores content and renders pages through a theme. It can run headless, though, because it exposes content through its REST API, and the WPGraphQL plugin adds a GraphQL API. A separate front end, often built in Next.js, then serves the public site while editors keep using the WordPress dashboard they know.
A decoupled CMS separates content from presentation but still ships its own front end, which you can use or replace. A headless CMS has no front end at all and only delivers content through an API. In practice the terms are often used loosely and interchangeably. What matters is whether you want the option of a built-in presentation layer or are happy to build every front end yourself.
Shopify is a commerce platform rather than a CMS, but it can run headless. Its Storefront API lets a custom front end, such as a Next.js site, display products, collections and carts while Shopify handles checkout, inventory and orders. Many headless stores pair Shopify for commerce with a headless CMS for editorial content, so product data and marketing pages each live where they are easiest to manage.
Yes. Once it is set up, editors work in a normal editing screen with labelled fields, image uploads and a publish button. A well-built setup goes further, with reusable page blocks, help text on every field and a live preview of drafts. The technical work happens once, when developers model the content and build the front end. After that, everyday publishing needs no code at all.
Most major headless platforms work well with Next.js, so the choice comes down to your team. Sanity suits teams that want a customised editor. Strapi suits teams that want to self-host and control their data. Payload suits developer-led teams, because it can run inside the Next.js app itself. Contentful suits larger editorial teams. Headless WordPress suits teams who do not want to change editors.
No, but they are related. Jamstack is an approach to building sites where pages are pre-rendered and served from a CDN, with JavaScript and APIs handling anything dynamic. A headless CMS is often the content source in that setup, because it delivers content through an API at build time. You can use a headless CMS without following Jamstack ideas, for example with pages rendered on each request.
A marketing site with a modest content model usually fits the same four to eight weeks as a typical Next.js build, with the content model agreed in the first week. Many content types, several languages, live previews and a large content migration each add time. The slowest part is often agreeing the content structure with editors, which is why it should happen before any templates are built.
Yes, and it is easier than switching traditional CMSs, because the front end and the content are separate. Content is exported from the old platform, mapped to the new model and imported by script, and the front end is pointed at the new API. The work grows with the number of content types and how tightly the front end was written around one platform's quirks.
Written by
Kavion Solutions Team
The senior team behind Kavion Solutions. We build websites, apps, AI tools and cloud setups, and run the SEO and ads that bring in customers, so everything here comes from work we have actually shipped.
Want this done for you?
Start a project