Headless CMS vs. WordPress: which one is worth it, and for whom?

WordPress powers a huge chunk of the web — and for good reason. Even so, it isn't the best solution for every case. More and more often the word “headless CMS” shows up in proposals and sales calls, these days with two companions: “composable” and “visual headless CMS”. What's actually behind them, what's marketing, and what fits you?

The difference in one sentence

Classic systems like WordPress tie content and presentation firmly together. A headless CMS separates the two: it only manages the content and makes it available through an interface. How that content looks is determined by a separate, freely designable frontend.

Headless, composable, visual: sorting the buzzwords

Three words that get used interchangeably in sales conversations, even though they describe different things:

• Headless CMS. The CMS has no “head” anymore — no output layer of its own. It hands content out as data through an API, and everything to do with appearance happens in the frontend. Examples: Strapi, Contentful, Sanity, Storyblok.
• Composable CMS. This isn't about separating content and presentation, it's about the architecture around it: instead of one suite that does everything, you assemble your stack from separate, swappable services — CMS, search, commerce, media, forms. The term comes out of the MACH world (microservices, API-first, cloud-native, headless). Every composable setup is headless; not every headless setup is composable.
• Visual headless CMS. A headless CMS that pulls a live preview of the real frontend into the editing interface — sometimes including click-on-the-page-and-type editing. The label exists as positioning, because that was headless's biggest weakness for years.

In practice: “headless” is a statement about one system, “composable” a statement about your landscape, and “visual” a statement about your editors' daily life. Only the last two decide whether your team enjoys logging in on a Monday morning.

Where WordPress is strong

Be fair to WordPress — it has its strengths:

• Quick to get going for classic blogs and simple websites.
• A huge ecosystem of themes and plugins.
• Familiar: plenty of editors already know the interface.
• All in one place: forms, search, media, newsletter integration — one plugin in WordPress, one separate decision in a composable setup.

If you need a manageable website with a blog and don't have particular demands on design or performance, WordPress is often perfectly sufficient. Even a grown pile of plugins is fine, as long as somebody keeps it patched.

Where a headless CMS wins

As soon as things need to get more custom, faster or more versatile, the headless approach plays to its strengths:

• Design freedom: the frontend isn't bound to the CMS's constraints.
• Speed: pre-rendered pages arrive as finished HTML instead of being assembled from database and plugins on every request. That does not make headless automatically faster — a bloated React frontend can be slower than a lean WordPress site. It gets faster when rendering strategy, image sizes and hosting line up.
• Multiple channels: the same content can be delivered to a website, an app and other channels.
• Security: the editing system no longer runs in the same process as the public site, so the classic WordPress entry point — an outdated plugin on a publicly reachable install — goes away. It is not a free pass: Strapi and the frontend need updates too.

How does a visual headless CMS compare to WordPress?

That is the question people ask the moment the phrase “visual headless CMS” comes up — and it aims straight at the one real weakness of the headless approach.

In WordPress you write in the block editor and roughly see the finished page while you type. In classic headless you write into a form with fields, and what you see is: a form with fields. For structured content — product data, job ads, case studies — that is an advantage, because nobody can bend the layout by accident. For editorial pages that live on the interplay of text, image and whitespace, it was a genuine step backwards for years.

The “visual” features are what closes that gap. With Strapi it looks like this:

• Preview embeds the real frontend page inside the admin panel. A toggle switches between the draft and the published version, and you can copy the preview link and pass it around for sign-off. According to the Strapi documentation, the feature is available to all users, including the free Community edition.
• Live Preview puts the editor and the preview side by side and lets you edit straight in the preview. That tier has been around since Strapi 5.12 and belongs to the paid Growth and Enterprise plans.

An honest caveat: preview in a headless setup is not a switch you flip. It has to be built — the frontend needs a route that renders drafts, plus a secured way in. That is manageable work, but it is work. Anyone who believes a vendor claiming headless is “just as convenient as WordPress” will be disappointed two weeks after launch.

What it means for your editors: on a content-driven site with lots of free-form layouts, WordPress still has the edge day to day — unless the preview is planned in from the start. With structured content the picture flips: there, the form fields aren't the weakness, they're the reason the site still looks consistent two years later.

Composable CMS vs. WordPress: the difference in operations

A composable setup replaces one install full of plugins with several services that each do one job. What that means in practice:

The upside is swappability: when the shop no longer fits, you replace the shop, not the website. The price is integration work — every connection between two services is code somebody has to write and maintain, plus several contracts, invoices and contacts instead of one.

So here is the honest rule: composable pays off from the size at which a single plugin update hurts. With three editors and one website, you are buying complexity with no return. With several brands, a shop and a product data system, you passed that point a while ago.

Headless WordPress: the third option

There is a middle path that rarely shows up in proposals: run WordPress as a pure backend and let a separate frontend handle output. Technically that works through the REST API, which has been part of core since version 4.7, or through GraphQL via a plugin.

Where it makes sense: your editors keep the interface and editor they know, the content doesn't have to be migrated, and the frontend still becomes freely designable and pre-rendered.

What you don't get rid of: the WordPress install stays, and it still has to be maintained and secured — so the security benefit of headless largely disappears. On top of that, plenty of plugins deliver their functionality through the theme, which is exactly the part you just switched off; you get to rebuild those in the frontend. Headless WordPress is a good route when your problem is the design. It is the wrong route when your problem is the plugin pile.

What it costs — the honest comparison

The cost difference is not in the CMS, it is in the frontend. WordPress ships a finished presentation with a purchased theme; with headless, the frontend gets built. That is why a company website on a classic CMS starts at €990 with us, while a headless setup with its own frontend sits in custom development territory — from €3,900 for a scoped first step, €79/h for the build-out. How a calculation like that comes together is spelled out in what custom software costs.

In operation the picture partly reverses. These are the line items worth comparing:

The number that decides it is rarely the hosting bill. It is how often somebody touches the design: in WordPress a layout change is frequently theme configuration, in headless it is always code. If you rebuild landing pages every month, price that in honestly.

And what about the editors?

A common worry: “will my people still be able to handle it?” Yes. A well-configured Strapi gives you clear, structured fields instead of a cluttered editor. Maintaining content often gets easier as a result — and nothing can accidentally break the design anymore.

Two things belong in the plan anyway, or the first month gets unpleasant: the preview (see above) and a sign-off path. Strapi keeps drafts and published entries apart; being able to hand someone a preview link saves you the round of screenshots over email. Both are setup work up front and invisible afterwards.

The decision guide

• Simple blog, small budget, familiar interface? WordPress is usually enough. If you are still weighing up whether a classic website is all you need, how a website project actually runs helps you place it.
• Custom design, high performance, multiple output channels? Headless with Strapi.
• Several brands, a shop, product data, your own search? Then composable is the right question, and the effort is justified.
• Design is the problem, editors should stay put? Look at headless WordPress before you migrate everything.
• Want to get away from plugin sprawl and security worries? Headless is worth the switch — properly, though, not as headless WordPress.

We migrate existing WordPress sites to a headless architecture. What is plannable: content moves over completely, URLs stay the same or get 301 redirects, meta data and structured data come along. What nobody can honestly promise is an unchanged Google ranking — search engines re-evaluate after every relaunch, and anyone offering ranking guarantees is selling you something. How we handle a move like that is in our process.

Wondering whether a headless CMS makes sense for you? Count three things: how many channels the same content should appear on, how often your design changes, and how many plugins your current site depends on. Those are the numbers the decision hangs on. If you are unsure, let's talk about your project — we will look at your existing site and tell you when WordPress remains the right call for you. What headless looks like with us is on our headless CMS page.

Frequently asked questions