What Is a Headless CMS? Explained Simply, with Real Measurements (2026)

Sooner or later the phrase comes up in every website project: “We should move to a headless CMS.” Usually someone from development says it, and usually everyone else nods without really knowing what will change for them.

What is a headless CMS? A headless CMS is a content management system that only manages content and delivers it through an interface (API), but no longer renders a website itself. The “head”, meaning the frontend with layout, design and HTML, is cut off and built separately. The same backend can then feed a website, an app, a newsletter or a screen in a shop window.

In this article we explain it without the marketing fog: what technically happens when a headless CMS delivers a page, how it differs from WordPress in its normal mode, which systems exist, what it all costs and when a traditional CMS remains the better choice. The numbers come from our own measurements on October 16, 2026, taken on a WordPress test container on our server and on this very website, which runs without any CMS at all.

From February 2026. Sam Anthony explains headless CMS “without the hype” and is explicit about who should stick with a traditional CMS. A good companion to our own conclusion.

What Is a Headless CMS — the Short Answer

If you only want to read five sentences, read these:

1. A CMS (content management system) is the software where content is maintained: texts, images, products, events.
2. A traditional CMS like WordPress in its default mode stores that content and builds the finished HTML page from it, with theme, menu and footer.
3. A headless CMS only does the first part. It stores and manages, but delivers the content as raw data (usually JSON) through an API.
4. The frontend, what visitors see, is a separate project built with Astro, Next.js, Nuxt, a mobile app or whatever you like.
5. The upside is freedom in presentation and reuse; the price is a second system that someone has to build and run.

The name is meant literally: you chop off the CMS’s head. The body (database, editing interface, permissions, revisions) stays; the head (templates, theme, page output) goes and is replaced by one or more new heads.

Traditional CMS vs. Headless CMS: the Difference

To understand what “headless” removes, it helps to look at what a traditional CMS does on every page request.

How a traditional CMS works

When you open a blog post on a normal WordPress site, roughly this happens:

1. The web server hands the request to PHP.
2. WordPress loads its core, every active plugin and the theme.
3. It asks the database for the post, the menu, the widgets and the settings.
4. The theme assembles a complete HTML page, including every script and stylesheet the plugins ask for.
5. The finished page goes to the browser.

Content and presentation are tightly married here. That isn’t bad: it’s exactly why an editor can click “Preview” in WordPress and see precisely how the page will look. But it also means every plugin that wants to show something hooks into that output.

How a headless CMS works

With a headless CMS, the chain ends after step 3. Instead of HTML, a data response comes back, something like this:

{
  "id": 6,
  "date": "2026-10-15T12:54:12",
  "title": { "rendered": "Hello Tacilytics" },
  "content": { "rendered": "<p>Read the <a href=\"/files/guide.pdf\">PDF guide</a> …</p>" }
}

That isn’t a made-up example. It’s the real output of our WordPress test container for one post, fetched through its built-in REST API. More on that in the measurements below.

What happens with this data is decided by a different program: a static site generator like Astro fetches it at build time and writes finished HTML files. A Next.js app fetches it on every request or from a cache. An iOS app renders it natively. A point-of-sale screen shows only the title and price.

The jargon you’ll hear

• Backend — the CMS itself, with database and editing interface.
• Frontend or “head” — what visitors see.
• API — the interface between the two, almost always REST or GraphQL. If the term is still fuzzy, we’ve explained what an API is in depth, and why you have to choose between REST and GraphQL.
• Content model — the structure of your content. Instead of “a page with text” you define fields: title, teaser, author, image, price, ingredient list.
• Decoupled CMS — a middle ground: the CMS still has its own frontend but also offers an API. WordPress with its REST API is exactly that.
• Jamstack — an architecture term for sites built from JavaScript, APIs and prebuilt markup. Headless CMSs are the usual data source there.

Comparison at a glance

How a Headless CMS Delivers Content: Our Measurement

Theory is cheap, so we measured. Our server runs a WordPress test container (WordPress 6.7, PHP 8.3, MariaDB 11) that we use for plugin tests. WordPress has shipped a REST API since version 4.7, so it can do both: deliver HTML the classic way and serve headless data. That lets us fetch the same post both ways and compare.

Same post, two routes

Measured with curl directly on the server, three requests in a row each:

What you can and can’t read from this:

The payload shrinks dramatically. The actual content of the post is 248 bytes. The HTML page around it is more than 400 times larger and contains 21 <script> tags injected by the theme and plugins. That’s the core of the headless idea: the CMS only sends what is genuinely content, and the frontend decides how much baggage to add.

The API is faster, but not magic. The JSON response still takes 60 to 170 milliseconds, because WordPress still boots PHP and queries the database. A headless CMS doesn’t make database work cheaper; it only moves the rendering elsewhere.

Fastest of all is not asking at runtime. The static Astro page answers in around 20 milliseconds because it’s already sitting finished on disk. That’s exactly why headless CMSs are so often paired with static site generators: the CMS is only queried during the build, and visitors get finished files. We described why this works so well for us in Astro vs. Next.js.

Honest caveat: this is a test container with very little content plus WooCommerce plugins, measured on the same machine with no network hop in between. Absolute numbers on your hosting will differ. The ratios, however, are typical.

The trap of the giant API index

A side finding that matters for headless projects: the entry point /wp-json/ of our test container is 1,240,990 bytes, roughly 1.2 MB. It lists every route of every plugin with all its parameters. A frontend that clumsily “fetches everything first” downloads megabytes to get 248 bytes of content.

That’s why our measurement includes ?_fields=id,title,content,date: it makes WordPress return only the fields we need. Without that parameter, the response for a single post was 1,735 bytes, seven times more than necessary. For a list of 100 posts that adds up quickly. Good headless systems make this kind of field selection easy; GraphQL APIs are built for it.

What the API reveals publicly

Second side finding: without any login, /wp-json/wp/v2/users returned the username of the admin account. That’s WordPress default behavior and not a vulnerability in the strict sense, but it halves the work for anyone trying to guess passwords. Write access, on the other hand, was properly locked: a POST to /wp-json/wp/v2/posts without authentication got a 401.

The lesson for every headless project: an API is a public door, even if your website doesn’t use it. Check which endpoints answer without authentication and switch off whatever the frontend doesn’t need. How many bots knock on such doors every day, we counted in our own server log; see the section on scanners in our API article.

Advantages of a Headless CMS

One piece of content, many channels

The strongest argument. If a product description needs to appear on the website, in the app, in the newsletter and on the screen in the shop window, you maintain it once. Each channel pulls the fields it needs. With a traditional CMS you end up copying text by hand, and after the third price update they no longer match.

Free choice of frontend technology

The frontend team is no longer tied to PHP templates. It can use React, Vue, Svelte, Astro or native apps, and switch stacks without touching the content. Conversely, you can swap the CMS without rebuilding the design, as long as the new system delivers the same fields.

Performance

Because the frontend only receives data, it decides for itself how lean it stays. Combined with a static site generator and a CDN, finished pages sit distributed worldwide and the CMS isn’t queried at runtime at all. Our measurement shows the gap: 20 milliseconds for the static page versus 100 to 500 milliseconds for the page rendered by the CMS.

Security through separation

With a traditional CMS, the editing interface is part of the public website. In a headless setup, the CMS can sit behind a firewall, a VPN or on a different domain, while visitors only see static files. Anyone attacking the public site finds no login, no plugins, no database. Important: this only holds if you really shield the API. A headless CMS with a publicly reachable admin is just as exposed as WordPress.

Structured content

Headless CMSs force you to think of content as fields instead of “one big text box”. That feels bureaucratic at first but pays off: structured data can be filtered, translated, emitted as schema markup and read cleanly by AI systems.

Drawbacks Vendors Rarely Mention

Two systems instead of one

This is the point said most quietly in sales calls. You run a CMS and a frontend. Two codebases, two deployments, two sets of updates, two places where things can break. If the frontend build fails, the website is out of date even though everything in the CMS is correct.

Editors lose comfort

In WordPress, an editor drags a block onto the page and instantly sees the result. In a pure headless CMS, she fills in fields and at first sees … fields. A real preview has to be built by the development team. Many vendors have noticed and offer “visual editing” (Storyblok specializes in it, Sanity and Payload have caught up), but it remains setup work.

Nothing happens without developers

A new page layout? An extra field in the teaser? In a headless setup that almost always means a ticket for development. For teams with their own developers that’s fine; for a five-person trade business it’s a deal-breaker.

Costs

With SaaS vendors you pay by users, API calls or data volume, and prices jump quickly as you grow. With open-source systems you pay with hosting and maintenance time. In both cases the frontend comes on top. A rough breakdown from our experience follows below.

SEO isn’t handled automatically

A traditional CMS often brings sitemaps, meta tags, redirects and canonical URLs via plugins. In a headless setup the frontend has to generate all of that itself. Forget it and you build a fast site that Google understands poorly. If you’re just starting out, our Meta Title Generator at least gives you quick help with titles.

From November 2025. Adrian Twarog builds a working headless example in about ten minutes, a good hands-on complement to the theory here.

Which Headless CMSs Are There?

The market is big. We sort by what is the first question in practice: do you want to self-host or rent a service? The assessments are based on official documentation and our project experience, not on a benchmark of every system.

Open source, self-hosted

• Strapi — the best-known open-source option, Node.js, visual content-type builder, REST and GraphQL. A solid all-rounder with a large community.
• Payload — written in TypeScript and code-first: the content model lives in code and can be versioned. Since version 3 it integrates directly into a Next.js app. Our favorite for TypeScript teams.
• Directus — sits on top of an existing SQL database instead of forcing its own structure. Ideal when the data is also used by other systems.
• Ghost — really a publishing platform with newsletters and memberships, but it can run headless through its Content API.
• WordPress — yes, really. With the built-in REST API or the WPGraphQL plugin, WordPress is the most widely used headless backend in the world, because editors already know it.

Cloud services (SaaS)

• Sanity — very flexible content model, real-time collaboration, its own query language GROQ. Usage-based billing.
• Contentful — the enterprise classic, mature, but expensive on larger plans.
• Storyblok — focused on visual editing; editors see the page as they type. Often the most approachable option for marketing-heavy teams.
• Hygraph (formerly GraphCMS) — GraphQL all the way, strong for projects that merge data from several sources.

Special case: Git-based CMSs

Systems like Decap CMS or TinaCMS don’t store content in a database but as Markdown files directly in the Git repository. The editing interface creates commits behind the scenes. For blogs and documentation that’s elegant, because there’s no database to fail or get hacked.

Platforms outside the headless world that can replace WordPress, such as Webflow, Kirby or Statamic, are covered in our overview of modern WordPress alternatives.

How Much Does a Headless CMS Cost?

A flat number would be a lie, but the cost blocks are always the same:

The item most often underestimated isn’t the license but the frontend. You buy a classic WordPress theme for a few dozen euros and customize it. A headless frontend gets built, page by page, component by component. For a simple company website that often means several times the effort of a theme-based solution. For large projects with several channels the math flips, because you’d otherwise have to maintain content multiple times.

If you self-host, you don’t need much power: Strapi or Payload for a mid-sized site runs on a small VPS. We measured how much memory is realistic in How much RAM does a server need?. And because the CMS is then a service like any other, it needs a reverse proxy with HTTPS in front and a real backup strategy behind it.

When Does a Headless CMS Pay Off — and When Not?

Headless pays off when …

• several channels need the same content (website plus app, multiple brand sites, displays, checkouts).
• there’s a development team that maintains the frontend long-term.
• performance is a business factor and you want to serve static pages.
• content is highly structured: product data, recipes, events, job listings.
• the CMS should not be publicly reachable for security reasons.
• you want to keep an existing frontend and only modernize the backend (or vice versa).

A traditional CMS is better when …

• a small business wants to maintain its website itself without calling developers for every layout change.
• the budget is one-off with no ongoing development planned.
• the editors are used to and depend on page builders and live preview.
• there’s only one website and no second channel in sight.
• something has to go live quickly.

An honest pattern from practice: many projects go headless because it sounds modern and end up with a website only the agency can change. That isn’t an architecture question but an organizational one. Who will maintain the site in two years, and can that person do it?

From Our Own Practice: getmind.io Has No CMS at All

This website is a useful counterexample because it takes the headless idea to its end and then one step further. getmind.io runs on Astro, and every article is an MDX file in the repository. There’s no CMS, no database and no API that visitors could reach. At build time every page is rendered and copied to the server as files.

Technically that’s the most extreme form of “content and presentation separated”: the content is text files, the presentation is the Astro project, and the “API” between them is the file system during the build. We feel the benefits every day: 20 milliseconds response time, nothing to patch, every change traceable in Git history.

The price is exactly the drawback described in this article: fixing a typo here requires repository access and a build. That suits us, because the content comes out of our day-to-day development work anyway. If tomorrow a marketing department that has never seen a command line started writing with us, the next step would be a Git-based CMS like Decap or Tina on top, or a headless CMS as the data source for the same Astro build. Almost nothing would have to change in the frontend, and that is the real benefit of the separation.

How to Get Started with a Headless CMS

If you want to try it, the fastest route costs nothing and breaks nothing:

1. Sketch the content model. Before choosing a system, write down which content types exist and which fields they have. That’s the real work, and it’s system-independent.
2. Start a system locally. Payload and Strapi can be scaffolded as test projects with one command (npx create-payload-app or npx create-strapi@latest). Directus is available as a Docker container, most conveniently with a Docker Compose file.
3. Enter some real content. Not “lorem ipsum” but three real articles or products. Only then will you notice whether the model fits.
4. Query the API by hand. With curl or in the browser. Look at what comes back and how big it is. Use field selection (?fields= or _fields=), as in our measurement.
5. Build a mini frontend. An Astro page that fetches the articles at build time and outputs them as a list is a few dozen lines.
6. Let the editors in. Have the person who will maintain content later work with it for an hour. Their face after that hour is the most important data point of the whole evaluation.

If you already run WordPress, you can even skip step 2: open https://your-site.com/wp-json/wp/v2/posts?_fields=id,title and you’ll see your own site acting as a headless CMS.

Conclusion: Off with the Head, but with a Plan

A headless CMS isn’t an upgrade; it’s a division of labor. It separates maintaining content from presenting it, and that is enormously valuable when several channels, an in-house development team or hard performance goals are in play. Our measurement shows how large the difference can be: 248 bytes of content versus 104,803 bytes of rendered page, and 20 milliseconds for a statically served page.

But it is also a second system with its own costs, its own maintenance and an editorial team that types in the dark until someone builds a preview. For the small company website that one person maintains on the side, a well-maintained traditional CMS is usually the more honest solution. The right question isn’t “headless or not?” but “who maintains this in two years, and on how many channels?”.

Frequently Asked Questions About Headless CMS

What is a headless CMS in simple terms?

A headless CMS is a program where you maintain content like text, images and products, but which doesn’t display a website itself. It hands out the content as data through an interface (API). A separate website, app or other program fetches that data and displays it.

What is the difference between a headless CMS and a traditional CMS?

A traditional CMS manages content and also generates the finished HTML page with design from it. A headless CMS only manages content and delivers it as data; the design is created in a separate frontend. That lets the same content appear on many channels, but you need a second system.

Why is it called “headless”?

“Head” stands for the frontend, the visible part of the website. A headless CMS is a CMS with that head cut off. What remains is the “body”: database, editing interface and API.

Is WordPress a headless CMS?

Not in its default mode, where WordPress outputs finished HTML pages. But it can be used headless: since version 4.7 WordPress has a built-in REST API under /wp-json/, and with the WPGraphQL plugin also GraphQL. Editors then work in WordPress as usual and a separate frontend fetches the data. This is often called a “decoupled” setup.

Which headless CMSs are there?

Well-known open-source systems for self-hosting are Strapi, Payload, Directus and Ghost. Well-known cloud services are Sanity, Contentful, Storyblok and Hygraph. There are also Git-based systems like Decap CMS and TinaCMS, which store content as files in the repository.

Which headless CMS is the best?

There’s no best one for everyone. For TypeScript teams who want everything in code, Payload is strong. For existing SQL databases, Directus fits. If you want a proven all-rounder, take Strapi. If editors need to work visually, Storyblok is often the most approachable. Test with real content and real editors before committing.

Is a headless CMS faster?

It can be much faster, but not automatically. It gets fast mainly when the frontend fetches content at build time and serves finished static pages. In our measurement a static page took about 20 milliseconds, the CMS-rendered HTML page 100 to 500 milliseconds. If the frontend queries the API on every request instead, it’s only as fast as the API itself.

Is a headless CMS more secure?

It can be, because the CMS doesn’t have to be publicly reachable and visitors only see static files. But that security only exists if the API and admin interface are really shielded. A public API is an additional door that needs checking. In our test, WordPress revealed the admin username through the API without any login.

How much does a headless CMS cost?

Open-source systems are license-free but cost hosting and maintenance time. Cloud services usually have a free entry tier and then charge by users or usage. In both cases the biggest cost block is the frontend, which has to be developed specifically, and it is the one most often underestimated.

Do I need programming skills for a headless CMS?

Not for day-to-day content editing, which works through an editing interface. But you do for setup, the content model and above all the frontend. Without a developer or agency, a headless setup is hard to build and harder to evolve.

What is the difference between a headless CMS and a static site generator?

A headless CMS stores and manages content. A static site generator like Astro or Hugo turns content into finished HTML files. The two complement each other: the generator fetches content from the headless CMS at build time and builds the website from it. You can also use a static site generator without any CMS, with Markdown files, just like getmind.io.