Headless CMS: what it is and why it matters for your next project

If you've spoken to a web developer recently, there's a decent chance they mentioned "headless CMS" at some point. It's become one of those terms that gets thrown around a lot, often without much explanation. So let me try to fix that.

The traditional approach

A traditional CMS, WordPress is the obvious example, handles everything. It stores your content in a database, it has a back-end admin panel where you write and edit that content, and it generates the web pages that your visitors see. The content and the presentation are tightly coupled. When someone visits your site, WordPress fetches the content from the database, runs it through a PHP template, and sends back a complete HTML page.

This works brilliantly for a lot of sites. WordPress powers something like 40% of the web, and for good reason. But it has limitations.

What "headless" means

So what does "headless" actually mean in practice? A headless CMS strips away the front-end, the "head". It still stores and manages your content, but it doesn't generate web pages. Instead, it provides your content through an API, essentially a structured data feed that any front-end can consume.

Think of it like this: a traditional CMS is a restaurant that cooks the food and serves it to the table. A headless CMS is a kitchen that prepares the food and hands it through a hatch, you decide how and where to serve it.

This means you can build your website's front-end with whatever technology you like. React, Vue, a static site generator, a mobile app, a digital signage screen, the CMS doesn't care. It just serves up the content.

Why this matters

Three reasons come up consistently in my projects.

First, performance. When your front-end isn't tied to a CMS runtime, you can build incredibly fast sites. Pre-rendered static pages served from a CDN will always outperform a PHP application making database queries on every page load. For sites where speed matters, and Google's increasingly making that every site, this is significant.

Second, flexibility. If you want to use your content in multiple places, a website, a mobile app, an in-store kiosk, a headless CMS gives you that out of the box. Write the content once, consume it anywhere.

Third, security. A traditional CMS has a large attack surface. WordPress sites get hacked constantly, usually through outdated plugins or themes. A headless setup reduces that surface dramatically. The CMS sits behind an API, the front-end is static HTML, there's simply less to exploit.

The trade-offs

I'd be doing you a disservice if I didn't mention the downsides. Headless is more complex to set up. You need a developer to build the front-end, there's no picking a theme and installing it in five minutes. The editing experience can be less intuitive, depending on which headless CMS you choose. And the ecosystem of plugins and pre-built solutions is smaller than what you'd find with WordPress.

For a small business that needs a brochure site and wants to update it themselves with minimal fuss, WordPress is still the right answer. For a business that needs speed, multi-channel content delivery, or a highly custom front-end, headless is worth a serious look.

Which headless CMS?

I've been working with a few. Sanity is excellent, flexible content modelling, real-time collaboration, and a generous free tier. Strapi is good if you want to self-host. Contentful is the enterprise option with pricing to match. Each has trade-offs, and the right choice depends on the project.

If you're planning a new website or thinking about whether headless might be right for your next project, I'm happy to talk through the options. Get in touch at [email protected].