What is a headless CMS?

What it means

A traditional CMS like WordPress does two jobs: it stores your content and it shows that content to visitors through a theme. Content and design come as one package.

A headless CMS cuts off the “head,” the part that displays pages. What’s left is a content library with an editor. Developers build the front end separately and pull content from the library.

Your team gets a similar editing screen. Behind it, the setup is very different.

How it works

Editors log in and fill in structured fields: title, summary, body, image, author. The headless CMS stores that content and makes it available through an API, a doorway that other software can request data from.

The front end, often a JavaScript app or a static site, asks the API for content and turns it into pages. One content library can feed a website, a mobile app and an in-store screen at the same time.

WordPress can work both ways. Out of the box it’s traditional, but developers can also use it as a headless back end and build the front end with other tools.

Why it matters when you build a site

Headless solves real problems for larger teams: one source of content for many channels, freedom to use any front-end technology, and fast pages when paired with a CDN.

For a small business, it usually adds cost and complexity. You run two systems, and simple jobs like adding a new page layout or a contact form now need a developer.

It’s becoming more relevant with AI app builders. Lovable, Bolt and v0 don’t include a built-in CMS, so if non-technical staff need to update text on a vibe-coded site, connecting a headless CMS is one way to give them an editor.

How the big builders handle it

• Squarespace and Wix: traditional. Content and design live together on the platform. Wix CMS collections can be exported; Wix blog posts can’t.
• Webflow: a CMS tied to its visual designer (20,000 items and 40 collections on the Premium site plan). CMS content exports and imports as CSV, and Webflow’s MCP server lets AI agents query the CMS.
• Framer: built-in CMS collections connected to its designer, from 2 collections on Basic to 10 on Pro.
• Self-hosted WordPress: traditional by default, and able to run headless. Most of the sites we build stay traditional, because it keeps editing, previews and plugins working the way clients expect.
• Lovable, Bolt and v0: no built-in CMS. Content is written into the app’s code unless you connect an outside CMS.

Common mistakes

• Going headless for a five-page site. If one person updates a handful of pages a month, a regular CMS or builder does the job with far less setup.
• Forgetting preview. Editors want to see a page before it goes live. On a headless setup, preview has to be built and maintained.
• Underestimating the bills. You may pay for the CMS plan, front-end hosting and developer time, all separately.
• Losing plugin conveniences. SEO fields, forms and redirects that a WordPress plugin handles in minutes become developer tasks.
• Skipping content planning. Headless works best when content types and fields are planned up front. Changing them later means changing the front end too.

Related terms

• CMS: the traditional, all-in-one version.
• Static website: a common front end for headless content.
• CDN: how headless sites often serve pages fast.
• Vibe coding: AI-built apps that may need a CMS added.

Weighing a designer tool against WordPress? See Webflow vs WordPress.