Does Your Business Really Need a Headless CMS?
“Our developer says we should go headless.” It sounds like something out of a horror film, and for plenty of business owners the quote that follows feels about the same. Headless is a real way of building websites, with real advantages on the right project. It also gets sold to firms who’d be better off without it. So it’s worth knowing what the word means before you sign off a proposal that’s built around it.
In brief
- Headless means the system that stores your content and the website people see are two separate things that talk over an API.
- It can make sense for big shops, apps and anyone publishing the same content to several places.
- For a typical service business it usually means more cost, more moving parts and a reliance on specialist developers.
- It won’t make a site fast or good for SEO by itself. How it’s built decides that.
What ‘headless’ actually means
A normal WordPress site does two jobs at once. It stores your pages, posts and images, and it builds the pages visitors actually see using a theme, so the back end and the front end live together in one system.
Headless chops the head off. WordPress, or another content system, keeps storing the content, but a separate front end pulls that content across and displays it. That front end is often written in a JavaScript framework. The two talk through an API, which is just a structured way for one piece of software to ask another for data. WordPress already has one built in, the REST API, and its developer handbook describes using it to bring your content into “completely separate applications”, whether that’s a JavaScript front end, a mobile app or a desktop tool.
Some content systems are headless from birth. They’ve no front end at all. You write in them and developers fetch the content for whatever they’re building.
Why developers get excited about it
There are proper reasons. Picture a national retailer with a website, a phone app and screens in its shops, all showing the same product details. One store of content feeding all three is tidy. Change a price once and it updates everywhere.
Developers like the freedom as well. They can build the front end in the tools they prefer instead of working inside a WordPress theme, and bigger teams can split the work, with one group on content and another on the front end. Built well, pages can be generated in advance and served very quickly.
That last bit has a big ‘if’ attached. More on that shortly.
What it costs a smaller business
Now think about a four-partner accountancy practice with twenty pages, a blog and a contact form. What does headless give them?
Mostly more things to pay for. There are two systems instead of one, and each needs hosting, updates and someone who understands it. The content system sits in one place and the front end sits somewhere else, often on a different kind of hosting. When something breaks, the first job is working out which half it’s in.
Then there are the plugins. On a normal WordPress site a forms plugin drops a form onto the page, an SEO plugin writes your page titles and sitemap, and a cookie plugin shows the banner. Go headless and a lot of that stops happening by itself, because WordPress isn’t building the pages any more. Each piece has to be wired into the new front end or rebuilt from scratch. Even previewing a draft before it goes live, which editors take for granted, can need extra development.
Who’s going to maintain it? Ask that early. A standard WordPress site can be looked after by a huge pool of agencies and freelancers. A custom JavaScript front end needs people who know that framework, and ideally that codebase. If the developer who built it moves on, you’re picking from a much smaller crowd and paying for whoever’s next to learn the setup. That’s exactly how sites end up carrying the kind of technical debt that makes every change slower, and it piles up faster when only one person understands how the thing hangs together.
Faster isn’t guaranteed
Headless gets sold as the quick option. It can be. It can also end up slower than the site it replaced.
A lot depends on where each page gets built. If the visitor’s browser has to download a pile of JavaScript and assemble the page itself, that’s client-side rendering. Google’s web.dev team points out that the JavaScript this needs tends to grow as a site grows, and that it’s hard to keep fast on mobile. It can drag down INP too, the Core Web Vitals measure of how quickly a page reacts when someone taps, clicks or types. Building pages on the server and then ‘hydrating’ them in the browser helps the first view, though web.dev warns it can still hurt INP, because the browser has to chew through the script before the page responds properly.
Building pages in advance avoids most of that, as long as the amount of JavaScript sent to the browser is kept down. It’s a skill, mind, and not every headless project gets it right. A lean WordPress site on decent hosting is quick enough for most businesses, which is a theme running right through our guide to website speed and performance. For what Google actually measures, see our piece on LCP, INP and CLS in plain English.
What Google needs to see
Google can read JavaScript sites. It handles them in stages. It crawls the page, then renders it by running the JavaScript, and only after that does it index what it found. The rendering step joins a queue, and Google says a page may sit there for a few seconds or longer.
That’s why Google’s own JavaScript SEO documentation still calls server-side rendering or pre-rendering “a great idea”. It makes the site faster for people and crawlers alike, and Google adds that not every bot can run JavaScript at all. An older fix, serving search engines a separate pre-built copy of each page, is known as dynamic rendering. Google now calls that a workaround and doesn’t recommend it.
None of this rules headless out for search. Headless sites can rank perfectly well. The developer just has to handle rendering, page titles, redirects, sitemaps and structured data deliberately, much of which a WordPress SEO plugin would otherwise do for you. Ask how each one’s covered before any work starts.
When headless does make sense
Some businesses really do suit it. A retailer with thousands of products feeding a website, an app and marketplace listings is one. So is a manufacturer whose product data lives in a stock or ERP system and has to appear on several regional sites. A large charity pushing the same stories to its website, an app and email newsletters might qualify too. And if your website is more of a web application, with logins, dashboards and live data, a JavaScript front end may be the natural fit anyway.
What those have in common is scale, several channels and a development team on hand to look after it. If that sounds like your business, headless deserves a proper conversation.
What most businesses should do instead
For a café, a cleaning firm, a consultancy or a training provider, the money’s usually better spent on a well-built traditional site. A lean theme. A short plugin list. Good hosting, and someone keeping it updated. Need a booking system, a link to your CRM or a price calculator? Those can be built into an ordinary WordPress site with custom integrations instead of splitting the whole website in two.
If the choice you’re actually facing is WordPress against a hosted builder, our comparison of WordPress, Wix and Squarespace looks at ownership and long-term cost.
When someone does recommend headless, ask them what problem it solves that a normal build can’t. Then ask who’ll be maintaining it in three years, and what both halves will cost to run each year. A good developer won’t struggle to answer.
Talking it through
Been handed a headless proposal and not sure it fits? Or do you just want a quick site that’s easy to run? Our website design and development work is built around sites owners can manage themselves. Send us a message with what the site needs to do and we’ll tell you plainly which way we’d go.
Keep reading
- Website Speed and Performance
- Do Page Builders Slow Your Website Down?
- What Happens During a Website Redesign, Stage by Stage
