A client rang me in 2021 — a mid-sized e-commerce brand in Manchester, about 40,000 SKUs, multiple regional storefronts — furious. They'd spent £180,000 over 18 months on a headless Shopify build with a Next.js front end, and their page load times were slower than the Shopify theme they'd replaced. Their development team had grown from one contractor to four. Content editors needed a developer present just to push a blog post live.
Headless had been sold to them as the future. And technically, it is. But nobody told them what it would actually cost to operate.
I've built or overseen builds on well over 12,000 sites at Seahawk Media. Headless has been the right call on maybe 8–10% of them. The other 90%? It would've been a disaster — expensive, slow to ship, and miserable to maintain. This post is about knowing which bucket your project falls into before you've already written the cheques.
---
What "Headless" Actually Means in Practice
Let's get the definition out of the way fast. A traditional CMS — WordPress, Squarespace, whatever — couples the content management back end to the front-end presentation layer. They talk to each other natively. Headless decouples them. Your CMS (Contentful, Sanity, Strapi, WordPress in headless mode) becomes a pure content API. Your front end — Next.js, Nuxt, Astro, SvelteKit, whatever you fancy — fetches that content and renders it however it wants.
Simple idea. The complexity creeps in everywhere else.
The stack that actually shows up on projects
In practice, when someone says "headless," they usually mean one of these combinations:
- Contentful or Sanity as the CMS, serving JSON over REST or GraphQL
- Next.js on the front end, either statically generated (SSG) or server-side rendered (SSR)
- Vercel or Netlify for deployment and edge functions
- Shopify Storefront API or BigCommerce if there's commerce involved
- Some flavour of Algolia for search, because the native search options are usually rubbish
Each of those is a separate vendor relationship, a separate billing line, and a separate thing that can go wrong at 2am on a Friday.
---
The Genuine Case For Going Headless
Here's the thing — there are real, legitimate reasons to do this. I'm not dismissing the architecture. I'm just tired of it being applied indiscriminately.
Multi-channel content delivery is the strongest argument. If the same content needs to appear on a website, a mobile app, a kiosk display, and a smart TV interface, a coupled CMS becomes genuinely painful. One content API that all four surfaces query? That actually makes sense. Seahawk had a hospitality client in Dubai — one of those resort groups with a public-facing site, an internal staff app, and digital signage across the property. Single Sanity instance feeding all of it. That was the right call, full stop.
Performance at real scale is the second legitimate argument. Statically generated pages served from a CDN edge are fast in a way that PHP-rendered WordPress pages simply aren't, regardless of how well you've optimised your server. When you're talking about millions of page views per month, those milliseconds compound into meaningful revenue differences. Google's research has documented the correlation between load speed and conversion rate repeatedly — it's not theoretical.
Team separation matters too, though only for organisations big enough to have separate front-end and back-end teams. If your content team is a 20-person marketing department that wants to move independently of your engineering team, a clean API contract between CMS and front end lets both sides work without blocking each other.
Those three cases? Genuinely worth the complexity cost. Everything else is usually wishful thinking dressed up as architecture.
---
When Headless Is Just Expensive Over-Engineering
A five-page brochure site for a London accountancy firm does not need a headless architecture. Neither does a 200-product WooCommerce store with one developer on retainer.
I see this mistake constantly, especially from developers who've just discovered Next.js and want to use it on everything. (I was guilty of this myself in 2019 — built a headless blog for a small charity client, spent three days configuring webhooks to trigger Netlify rebuilds on new posts, charged them for it, and they still ring me when something breaks.) The problem is that headless shifts operational complexity from the CMS to the infrastructure. WordPress updates itself. Your custom Next.js + Contentful pipeline does not.
Specific scenarios where headless usually costs more than it returns:
- Small content teams — if one or two people manage all the content, the editorial DX of a proper coupled CMS like WordPress is genuinely better than a headless CMS. Preview environments are harder. Inline editing is gone. WYSIWYG is neutered.
- Tight budgets — a proper headless build costs 2–3x a comparable WordPress build to develop, and the ongoing maintenance is higher. If budget is a constraint, that money almost always does more good elsewhere.
- Frequent content changes — static generation means build times. A news publisher pushing 50 articles a day doesn't want to wait 8 minutes for a full site rebuild every time. (Yes, incremental static regeneration helps. It also adds its own complexity.)
- No dedicated DevOps — someone has to own the deployment pipeline, the CDN config, the environment variables, the preview URLs. On a small team, that someone is usually the developer who's also doing everything else.
---
The WordPress Headless Middle Ground
One thing I'd push back on is the false binary between "traditional WordPress" and "full headless with a separate CMS." There's a middle path that works really well for a certain class of project.
WordPress as a headless back end — using WP REST API or WPGraphQL — gives you the content management experience your clients already know (and honestly, most clients know WordPress), combined with the flexibility of a modern front end. You're not paying for Contentful. You're not retraining anyone. The editorial team keeps Gutenberg. The front end gets to be whatever framework suits the project.
I've used this pattern on probably 30–40 projects over the last four years. It lands well particularly for marketing sites that have a substantial existing content library in WordPress and don't want to migrate, but do want a React front end for performance or interactivity reasons. The trade-off is that WPGraphQL plugin maintenance can get fiddly, and you're still running a PHP server — you haven't escaped WordPress hosting entirely.
---
Choosing Your Headless CMS: A Practical Comparison
Not all headless CMSes are the same, and the choice matters more than people admit when they're excited about the front-end framework.
Contentful
The enterprise-grade option. Solid API, good SDKs, reasonable editorial UI. Pricing is the pain point — the free tier is genuinely useful for small projects, but once you hit the limits, you're looking at $300+/month before you've done anything interesting. I'd reach for Contentful on projects with real budgets and organisations that need proper roles and permissions workflows.
Sanity
My personal favourite for most mid-market headless projects. The GROQ query language is expressive once you've spent a day with it, Sanity Studio is customisable in ways Contentful isn't, and the real-time collaboration is excellent. Pricing is more reasonable. The downside is that the learning curve for non-technical content editors is steeper — the Studio looks different enough from WordPress that there's always a training period.
Strapi
Open-source, self-hosted, free to run. If you've got a client who won't pay SaaS CMS fees and has a server, Strapi is worth considering. The admin panel is decent. But you're taking on hosting, upgrades, and security patches yourself. Not nothing.
Astro with content collections
For content-heavy sites that are mostly static — documentation, blogs, marketing sites — Astro with local content collections is worth considering. No CMS at all. Content lives as Markdown or MDX files in the repo. Developers love it. Non-technical editors usually hate it. Know your audience before going this route.
---
The Performance Argument: What the Numbers Actually Say
Let me give you a real benchmark rather than a hand-wavy claim about speed.
A Seahawk client — a SaaS company, around 80 pages, moderate traffic — moved from a managed WordPress install to Next.js with Sanity, deployed on Vercel. Before the migration, Lighthouse scores were sitting around 62–68 on mobile. After, consistently 91–96. Time to First Byte dropped from roughly 420ms to under 80ms. That's not a marginal improvement. That's a different product.
But — and this matters — they had a dedicated front-end developer, a content team of four who went through Sanity training, and a budget that absorbed an eight-week build. The performance gains were real because the conditions for making headless work were in place.
The Web Almanac's data on CMS performance shows that the performance gap between headless-oriented frameworks and traditional coupled CMSes is real but not automatic. A badly implemented Next.js site can absolutely underperform a well-configured WordPress site. Architecture alone doesn't save you.
---
Making the Decision: A Framework I Actually Use
When a client brief lands on my desk and there's any question about whether headless is appropriate, I run through five questions before I'll commit to a recommendation.
- Does the content need to appear on more than one surface? If yes, headless gets a serious look. If no, it loses a major justification.
- What's the content team's technical comfort level? Non-technical editors on a tight deadline in an unfamiliar CMS is a bad combination.
- What's the expected traffic and performance requirement? Sub-50,000 monthly visitors on a reasonable host? WordPress handles it fine.
- Is there a dedicated developer for ongoing maintenance? If the answer is "we'll call someone when it breaks," headless infrastructure is a liability.
- What's the actual budget, including the first year of operation? Not just the build. Hosting, CMS subscriptions, developer time for updates. Total cost of ownership.
If questions 1, 4, and 5 don't line up, I'll recommend a traditional or hybrid approach and sleep well.
---
FAQ
Is headless WordPress better than a traditional WordPress setup?
Depends entirely on what "better" means for your specific project. For multi-channel delivery, team separation, or performance at high traffic volumes, headless WordPress — or replacing WordPress with a dedicated headless CMS — can meaningfully improve things. For a standard business website with a small team and moderate traffic, traditional WordPress with a good theme and proper caching is easier to build, cheaper to run, and simpler to hand off to a client.
Does headless always mean better performance?
No. And this myth is doing real damage to project budgets. Statically generated pages served from a CDN are faster by default, but a poorly configured headless build with unoptimised images, waterfall API requests, and no proper caching can absolutely underperform a well-tuned WordPress site. Performance is about execution, not just architecture.
What's the cheapest way to go headless?
Strapi on a £5/month VPS combined with Astro or Next.js deployed on Vercel's free tier can get you a functional headless setup for very little monthly cost. You'll pay in developer time instead. Nothing is actually free — you're just choosing where the cost lands.
How long does a headless build typically take versus a traditional CMS build?
In my experience: a comparable project takes roughly 1.5x to 2.5x longer in a headless setup than in WordPress, especially if it's the team's first headless project. That gap narrows as the team builds familiarity with the stack. Factor this into timelines and quotes honestly — clients who've been told "just a few weeks" for a headless build, when it ends up taking four months, do not come back.
Is headless dying now that WordPress has the Block Editor?
No, but the use cases are narrowing at the lower end. Gutenberg has eaten into some scenarios where headless used to be justified — interactive, component-driven content experiences are more achievable in WordPress now without decoupling. At the high end, for large-scale multi-channel publishing and commerce, headless is as relevant as it's ever been.
---
Headless isn't a status symbol. It's a trade-off — more flexibility, more complexity, more cost, in exchange for genuine gains in specific situations. Know the situation before you commit. The Manchester e-commerce client I mentioned at the top eventually migrated back to a Shopify theme with some custom front-end components. They cut their development overhead by 60% and their load times finally improved. Sometimes the old way is the right way. There's no shame in that.