Headless CMS: why and when it is the right choice

A traditional CMS like WordPress does two things at once: it manages your content and displays it as a web page. A headless CMS does only the first and leaves the displaying to a separate front end. That separation sounds abstract, but it has concrete consequences for speed, security and flexibility. The only question is whether you need those benefits.

What headless actually means

The "head" in a CMS is the presentation layer, the part that displays pages. Headless literally means: without that head. You keep the body (the content management) and deliver the content through an API to whatever front end you want.

• Editors work in a familiar editor and see no difference from a regular CMS.
• Developers build the front end separately, for example in Next.js, and fetch content through the API.
• The content itself is one source you can send to multiple places: a website, an app, a screen in the store.

The benefits in a row

Headless solves a number of problems that are structural with a coupled CMS.

• Speed: the front end can be served statically or through a CDN, separate from a database. That hits Core Web Vitals a coupled CMS struggles to reach.
• Security: the management environment is separate from the public site, often behind its own protection. The public attack surface is much smaller.
• Flexibility: the same content on website, app and other channels, without copying. One source, multiple outputs.
• Future-proof: you can replace the front end without migrating your content, and the other way around.

For a media company that displays content on web and app, headless is not a luxury but the logical architecture. One editorial team, all channels.

The drawbacks you should know

Headless is not a free improvement. There are real costs.

• Higher build cost: you build two things (management and front end) instead of one integrated whole.
• More technology: a simple page change that is instantly visible in WordPress now runs through an API and a build step.
• No ready-made previews without extra work. What an editor sees needs configuration.

For a simple business site with ten pages these drawbacks outweigh the benefits. There a traditional CMS goes live faster and is cheaper to manage.

When you do choose headless

Headless pays off from a certain point. If you recognize one of these situations, it is worth serious consideration.

• Multi-channel: you display content on website and app and maybe screens or kiosks.
• Scale: hundreds or thousands of pages where speed and management both count.
• High speed demands: performance is a selling point or an SEO priority.
• Custom design and interaction: you want a bespoke front end that a coupled theme does not offer.

The middle ground: headless WordPress

You do not have to give up your familiar WordPress. With headless WordPress you keep WordPress as the management environment and build the front end in Next.js. Editors work as always, visitors get a blazing-fast site. The best of editing convenience and modern performance, provided the scale justifies it. Read our comparison of Next.js and WordPress too.

How we approach it

At NedDev we build front ends by default in Next.js 16 with React 19. For content-driven projects we connect a headless CMS to that, hosted on Hetzner with Cloudflare in front. We advise headless only when the scale or the demands justify it, not because it sounds modern.

In doubt whether your project needs headless? The rule of thumb: under twenty pages and one channel, traditional is usually better. Above that, headless gets interesting. Look at our headless CMS approach or let us think along about what fits your scale.

Which headless options there are

Headless is not a single product but a category. The choice depends on your team, budget and how much control you want. Roughly there are three flavors:

• Hosted headless platforms like Contentful or Sanity. You pay a subscription, get a polished editor and have nothing to manage. Quick to set up, but you are tied to their pricing as you grow.
• Open-source headless like Strapi or Payload, which you host yourself. More control and no vendor lock-in, but you manage the infrastructure yourself.
• Headless WordPress if your team already knows WordPress. You keep the familiar editor and only rebuild the front end.

There is no universally best option. The right choice depends on who manages the content and how hard you expect to grow.

The hidden costs of headless

Be honest about what headless asks extra. You build two things instead of one, so the initial cost is higher. An editor used to seeing changes go live instantly has to get used to a build step or a preview environment that needs configuring. And you need developers who maintain the front end, not just a theme manager. Factor those things in before you choose headless. The benefits are real, but they only come into their own with enough scale and the right expectations.