A headless CMS separates content from presentation

What is a headless CMS?

A headless CMS manages content in a backend that has no frontend attached to it, and serves that content over an API. Editors write in one place. Every site, app, or device that needs the content fetches the same record. The CMS never decides what a page looks like.

A CMS like WordPress ties the content editor to a rendering engine. Change the template, and every page changes with it. But you can't reuse that content elsewhere without scraping HTML. A headless CMS removes the rendering engine entirely. Content lives as plain data behind an API. Presentation becomes the frontend team's job, not the vendor's.

This split matters more as teams ship to more places. A product page might render on a Next.js site. Or inside a native app. Or in a partner's store. A headless CMS serves the same content to all three. Through one API. No need to keep three copies in sync.

The global headless CMS market was worth about $1.75 billion in 2025. It's set to grow at a 17.5% yearly rate through 2033, per Grand View Research. (Source) Teams are leaving big, all-in-one CMS platforms. The API-first model fits how modern sites ship today.

Where headless came from

The CMS platforms most people know were designed for one output: a web page. WordPress shipped in 2003, Drupal in 2001. Both stored content, markup, and theme logic in the same box, because in 2003 the box only had to feed a browser. That assumption held for a decade.

Then phones, apps, kiosks, and watches showed up, and every one of them wanted the same product description. The old model couldn't hand it over as data. Content was already glued to a page layout. The API-first CMS arrived as the fix: keep the editor, drop the renderer, expose everything over HTTP. Frontend frameworks like React and Next.js made the other half of that split practical, so the two trends grew together.

How does a headless CMS work?

Think of it as a warehouse with no storefront. The warehouse keeps everything labelled and in stock. Anyone who wants to sell it builds their own shop window. Four steps cover the whole path:

1. Model the content. You define a schema of typed fields for each kind of content you publish: a blog post, a product, an author.
2. Write and publish. Editors fill those fields in an admin UI. An entry moves from draft to published without touching code.
3. Fetch over the API. Your frontend asks the delivery API for published entries, authenticated with a read-only key.
4. Render wherever you want. A Next.js page, an iOS app, and a digital sign each render the same JSON their own way.

A webhook usually closes the loop. On publish, the CMS pings your host, the affected pages rebuild, and the CDN serves fresh HTML. Nobody logs into a server.

Headless vs. decoupled vs. composable CMS

These terms get used as if they mean the same thing. But they cover different scopes of one idea. Headless means content has no built-in frontend. You get it only through an API. Decoupled is a close cousin. The CMS may ship a default frontend, but you can skip it. Composable goes further still. It applies that same idea to the whole stack: search, commerce, personalization. No single vendor owns the whole thing.

Draftbase sits squarely in the headless camp. There is no built-in renderer to skip. Content is served through a REST delivery API and a GraphQL endpoint. Your app owns every pixel.

Headless CMS vs. traditional CMS at a glance

The middle column is where most teams land first, and where the hidden work lives. Generic headless products hand you an API and leave the rendering layer as homework.

Structured content is what makes it work

An API alone doesn't buy you much. If the API returns one giant blob of HTML per page, you've moved the coupling, not removed it. What makes content reusable is structure: small typed pieces with names. A product entry has a title, a price, a gallery, a body. Not a wall of markup with a price buried in a <span>.

The schema that defines those pieces is the content model. In Draftbase it's a template: a named set of fields, each with a type and validation rules. Text, rich text, number, boolean, date, media, reference, JSON. Any field can be localized. An entry that fails validation never lands in the database, so the frontend never has to guard against a missing price.

Getting this right up front is most of the job. Our guide to schema-driven content modeling walks through modeling a real collection, including when to use a reference instead of duplicating fields.

Types of headless CMS

"Headless" covers three products that feel different to run. The split that matters is who operates the thing and how much of the editing experience ships with it.

SaaS, hosted by the vendor

Contentful, Sanity, Storyblok, Draftbase. You get an account, an admin UI, and an API. Upgrades, backups, and uptime are someone else's pager. The trade is a bill that grows with entries and seats, and a vendor holding your content.

Self-hosted open source

Strapi, Payload, Directus. No license cost, full control, and the data sits in a database you own. You also own the server, the upgrades, and the 3am restore. Our guide to a free and open-source headless CMS walks through what that costs in practice.

Hybrid and visual

Builder.io, and Storyblok's visual editor. These add a page-building layer on top of the API, so a marketer can arrange a landing page without a developer. It works, and it quietly reintroduces the coupling headless removed: the layout starts living in the CMS again. Worth it if the people building pages outnumber the people building components.

Where a headless CMS runs, and who hosts it

The first objection from a WordPress team is always this one. With a traditional CMS there is one server and it serves the site. With headless there are two halves, and they can be hosted by different people.

The CMS half stores content and answers API calls. The frontend half is your app, deployed wherever you deploy apps: Vercel, Netlify, Cloudflare, a container you run. Neither half needs to know where the other lives. A CDN usually sits in front of both, caching delivery responses and static pages so a spike in traffic never reaches an origin server.

Self-hosting the CMS half is a real option and a real job. Budget for database backups, version upgrades that touch the schema, image processing, and someone on call. Teams underestimate the last one. The license is free; the operations are not.

Draftbase is hosted. Content and the delivery API run on our infrastructure, media sits on S3 behind CloudFront, delivery responses are cached at the edge, and staging content lives in a separate environment you sync to production. You host the frontend and nothing else. The media and CDN layer covers the asset half of that in detail.

Benefits of a headless CMS

69% of headless CMS users shipped faster after leaving an old platform. That's from a Storyblok survey. (Source) 72% of teams surveyed by Content Science had a hard time reaching every channel on their old CMS. (Source) Here's where that speed actually comes from.

Ship to more than one frontend

One content record, many delivery targets. When a new surface shows up next year, it reads the same API the website reads. No re-platform, no second copy of the content to keep in sync.

Editors publish without a deploy

Content lives in a database, not in the repo. A typo fix is an edit and a webhook, not a pull request and a build queue. Developers get their afternoon back.

Faster pages by default

A decoupled frontend can be statically generated or rendered at the edge. There's no theme layer running template logic on every request, and no plugin stack loading jQuery on a page that never needed it.

A smaller attack surface

The admin and the write API sit behind a login on a different host from your public site. Visitors hit a read-only endpoint or static HTML. The usual plugin-vulnerability route into a CMS isn't there.

Redesign without touching content

Because the frontend owns presentation, a redesign is a frontend project. Rewrite the components, keep every entry. Teams that swapped frameworks the old way remember it as a migration, which is a polite word for re-entering everything by hand.

Who needs a headless CMS?

Three signals say yes. Your content already goes to more than one place, or it will. Your site is built in a JavaScript framework and the CMS is fighting it. Your editors are blocked on a developer for changes that are pure copy.

And the honest other half: plenty of sites don't need one. A five-page brochure site, run by the person who owns the business, on a theme that already looks right, is fine on a traditional CMS. Going headless there means you now own a frontend. If nobody on the team wants that job, the old box wins.

Headless CMS use cases

Headless CMS use cases by industry

The content problem changes shape by industry, even when the architecture doesn't. Five that come up most often:

Ecommerce

Product copy, size guides, and campaign pages get written by marketers but live next to inventory owned by the commerce platform. Headless splits them: the CMS holds the words, the commerce API holds the stock, and the storefront joins the two. Headless CMS for ecommerce goes deeper.

Media and publishing

High volume, many authors, and the same article syndicated to a site, an app, and a newsletter. Structured entries make that one record with three renderers instead of three copies drifting apart.

SaaS docs and marketing sites

Docs need versioning and live code samples; the marketing site needs landing pages shipped without a deploy. One CMS behind both means a feature name changes in one place.

Mobile apps

Onboarding copy, promos, and legal text change more often than an app ships. Fetching them at runtime takes those edits out of the App Store review queue entirely.

Multi-brand and franchise

Several sites, one content team, mostly shared content with local overrides. References and localized fields do that without a CMS instance per brand. More patterns in headless CMS examples.

How do I choose a headless CMS?

Feature lists all look the same at the pricing page. These are the seven questions that decide how much code you end up owning:

Weight the first one heaviest. Rich text is the field every project touches and the one vendors differ on most. Contentful returns a JSON node tree. Sanity returns Portable Text. Both need a walker mapping node types to components, extended every time an editor wants a new block.

Budget matters too, in both directions. Self-hosting Strapi, Payload, or Directus buys you a free and open-source headless CMS and hands you hosting, upgrades, and backups. Hosted plans trade that for a bill. Draftbase's published plan pricing starts free and runs to $499/mo, with no call to see a number.

Is a headless CMS good for SEO?

Yes, with one condition: render pages on the server or at build time, not in the browser. A crawler that receives an empty div and a bundle has nothing to index. Next.js, Astro, and every framework in that class do server rendering by default, so this is a setup choice you make once.

What you gain is control. Titles, meta descriptions, canonical URLs, hreflang, JSON-LD, sitemaps, and redirects are all your code, not a plugin's settings screen. Speed is the other half. Good Largest Contentful Paint scores rose from 44% of mobile pages in 2022 to 62% in 2025 as sites moved to this model. (Source)

Treat metadata as content, not as settings. A title, a meta description, an OG image, and a canonical override are typed fields on the template, filled in by the person writing the entry. That is the part a plugin used to own, and it is why nothing here is capped by what a plugin exposes.

Two things reliably go wrong. The first is the stale cache after a publish: wire publish webhooks to your revalidation route on day one, before anyone asks why the price on the live page is last month's. The second is redirects during a migration. Old URLs rarely survive a re-platform intact, and a redirect map built after launch is built from a rankings report instead of from the old sitemap.

The newer half of this is not Google. Answer engines read content too, and they read it differently — which is the next section.

Is your CMS ready for AI search?

Answer engines don't rank ten links, they assemble one answer. To do that they have to extract a fact and be confident about what it means. A price inside a styled <span> is a string on a page. A price field with a number type is a fact with a name. Same content, and only one of them survives being read by a machine.

That is what a delivery API gives a crawler that a rendered page cannot. The API returns named, typed fields with no markup wrapped around them, no navigation to strip, and no layout to guess at. The entry that a website renders is the entry an agent reads, so there is no second version to keep accurate.

Reading is only half of it. An agent that can read your content can answer questions about it; an agent that can also write to it can do the work. A native MCP server is the difference — the same templates, the same validation, and the same draft and publish states an editor works through, exposed as tools an agent can call. Nothing an agent writes skips a rule a human would have hit.

What to actually do about it, in order: model the facts you want cited as their own fields instead of burying them in prose; publish FAQ and Article JSON-LD from those fields, so the structured data can't drift from the page; keep canonical URLs stable, because a citation is a URL and a re-platform that changes every path drops every one of them; and make sure the page is server-rendered, since an answer engine has even less patience for a client-side render than a search crawler does.

How to migrate to a headless CMS

Eight steps, in execution order. The order is the whole trick — every painful migration is one of these done out of sequence, usually the redirect map.

Do the import into a non-production environment first, then sync it to production once the frontend renders it. Draftbase has environments with sync for exactly this, and it means a botched field mapping is a reimport rather than an incident.

This is the outline. The full CMS migration guide covers the parts that bite: mapping a WYSIWYG blob onto typed fields, what to do with content nobody will admit is dead, and how to run the two systems side by side during a cutover.

How Draftbase implements headless architecture

That split is what "API-first" means once it leaves the pitch deck. The write API needs a login. The read API needs a key. They stay separate, which is why Draftbase can safely fire webhooks on publish without touching your write path.

Here's the angle most comparisons skip. The real cost of an old CMS isn't the license. It's the custom rendering layer every generic headless CMS still makes you build for rich text. Draftbase skips that step. MDX is the native format, and the Next.js and Astro starters render it the moment content is written.

Common pitfalls when adopting a headless CMS

Teams that struggle with a headless move usually hit one of three walls. First, they model content around the old page templates, not the real data shape. That just moves the old coupling up one layer. Second, they treat the API as an afterthought. Then they find slow query bugs once the site goes live. Third, they pick a rich-text format that needs a custom renderer. That renderer becomes its own maintenance burden.

The fix for the first two: model templates around what the data actually is. A blog post. A product. An author. Not a page layout. Use the GraphQL endpoint when a view needs several related entries in one trip. The fix for the third: pick a CMS where rich text already fits your frontend. That's the exact problem MDX-native editing solves.