What is a headless CMS, and when do you actually need one?

You will see both words. Strictly, a decoupled CMS still ships a rendering layer you may choose to use; a headless one has none. In practice people use them interchangeably, and the distinction rarely changes a decision.

The question worth asking about any product is simpler: can it render a page? If yes, going headless with it means running a renderer and then ignoring its output.

#When it pays off

You have more than one front end. A website, an iOS app, a kiosk, a partner who wants a feed. In a traditional CMS the second consumer is a scraping problem. In a headless one it is a second API client.

You have more than one project. An agency with ten clients, a group with five brands, a SaaS where every customer needs their own content. This is where the pricing models start to diverge sharply — some products bill per project, per dataset, or per space, and the third project is where you find out.

Your content is not page-shaped. A product catalogue, a docs site, a changelog, a job board. If you are fighting the "post" model with custom fields, you are already paying the tax without the benefit.

Localisation is real. Not "we translated the menu" — genuinely parallel content in several languages, with different publication states per language. Traditional CMSs do this with plugins. Headless ones treat it as a field-level property.

Front-end performance is a business number. Decoupling lets you serve pre-rendered, cacheable output instead of computing a page per request. That is not automatic, but it becomes possible.

#When it is the wrong tool

This is the section most vendor articles skip, because they are selling.

One site, one language, one team, no developer. A headless CMS moves the rendering work to you. If nobody is going to do that work, you have paid for a subtraction. Use WordPress, or a site builder, and spend the money on content.

A five-page brochure site. The API, the build step, the deploy pipeline and the front-end repo are all overhead against five pages that change twice a year.

Your team edits with a visual preview and will not give it up. Some headless products have excellent live preview; many have none. If "I want to see the page as I type" is non-negotiable, put that at the top of your criteria and let it eliminate candidates early.

You need a plugin ecosystem. Bookings, forms, memberships, e-commerce — if your site depends on off-the-shelf modules, headless means writing them. That is a budget line, not a detail.

A useful test: count your front ends and count your projects. If both are one, the honest answer is usually "not yet".

#The part that decides the bill

Once you have decided you need one, the model that decides your invoice is how the vendor charges for reads.

Most hosted headless products meter something that visitor traffic moves: API calls, bandwidth, CDN requests, or a combined usage quota. The consequence is easy to state and easy to miss: a successful launch is indistinguishable from a billing incident. Nothing about your content or your work changed — only the number of strangers reading it.

There is an architectural alternative, and it is worth understanding whichever product you pick: serve published content as pre-built, immutable files from a cache, instead of computing a response per request.

That is how corpusctl works. Hitting publish runs a build: the content is validated, rendered, and written to a hash-addressed file in object storage, then the manifest is refreshed. The reader's client resolves the slug to a manifest shard locally, then fetches that address from the nginx edge cache. Because the address is a content hash, the same address can never return different content — so it can be cached for thirty days with no invalidation strategy at all. Publishing writes a new address.

Two HTTP requests, both from cache. Neither reaches the API. Neither reaches the database. There is no per-call meter because there is no per-call.

You do not have to pick corpusctl to use this as a criterion. Ask any vendor: what happens to my bill if this post does ten times better than expected?

#What to look at when you compare

1. What is metered. API calls, records, seats, bandwidth, projects — and the overage price of each.
2. What a second project costs. The number is sometimes startling.
3. Where the data lives, and whether you can run it yourself.
4. What the client library imposes. Renderers that ship opinionated markup have renamed your styling problem, not solved it.
5. What happens when you downgrade. Does a feature become inaccessible, or does data get deleted?
6. Localisation depth. Per-field, or a plugin?
7. The read path. Computed per request, or pre-built and cached?

#Frequently asked

Is headless WordPress a real headless CMS? Functionally yes — the REST API and WPGraphQL expose content. Architecturally it is a retrofit: you keep the page-rendering machinery and then discard its output.

Does it hurt SEO? Not inherently. The three common ways teams lose traffic in a migration are rendering only on the client, dropping canonical tags during the rebuild, and serving from a slow origin instead of a cache.

Is it more expensive? Usually more expensive in engineering time up front, and cheaper in the specific case where you were about to build three websites.

Next: Headless CMS comparison — we ran all six · Headless CMS SEO: where the traffic leaks