WordPress to headless — when it’s worth the move

One of the most common briefs we get from publishers and content-heavy businesses is some variant of: “we’re thinking about going headless — what do you reckon?”. It’s a fair question, and the answer is annoyingly conditional. Here’s the framework we use to decide whether a headless rebuild is the right move or whether a WordPress refresh would do the job for a tenth of the cost.

What “going headless” really means

A headless CMS — Strapi, Sanity, Contentful, Payload — separates the content store from how that content is rendered. The CMS exposes structured content through an API. A separate frontend (typically Next.js or similar) consumes that API and renders the experience. The two halves can be deployed and scaled independently, and the same content can feed a website, a mobile app, a newsletter system, or a third-party syndication partner without being remodelled each time.

When it’s the right move

• You have multiple consumer surfaces. A website, an iOS app, a partner feed, an email digest. Headless removes the pain of keeping them in sync.
• Performance matters at scale. The frontend can be statically generated or edge-rendered, decoupled from a database that you don’t want a viral spike to take down.
• You’ve outgrown WordPress’ data model. If you’re fighting custom post types, ACF complexity, or plugin sprawl just to model your content, that’s a signal.
• You need stricter content workflows. Approval chains, scheduled publishing across time zones, multi-locale variants — these are doable in WordPress but get cleaner with a content-first CMS.

When it absolutely isn’t

• Your editorial team loves the WordPress block editor. Don’t take a tool away from people without a much better one to give them.
• Your traffic is fine and your stack is stable. Migration cost is real, both in agency fees and in the months of editorial productivity you lose during transition.
• You don’t have anyone in-house who can own a more complex stack. Headless gives you flexibility — and the operational responsibility that comes with it.
• SEO is your single biggest channel. Migrations are the highest-risk thing you can do to organic traffic. We’ve spent significant time on post-migration SEO recovery for clients who jumped without a plan.

The middle path

For a lot of publishers, the right answer is somewhere in between. Keep WordPress as the editorial surface — it’s genuinely best-in-class for content authoring — and build a custom frontend that reads from WordPress’s REST or GraphQL API. You get the flexibility of a custom build without retraining the editorial team. We’ve done variants of this for several clients in publishing and have seen it work well.

How to decide

Three honest questions:

1. What problem are you trying to solve, in plain English? “The site is slow” and “we want to launch a mobile app” lead to very different answers.
2. What does success look like in twelve months? Tie it to a metric — load time, editor productivity, conversion, SEO — and check whether headless actually moves it.
3. Who will own the stack on day 367? If the answer is “an agency forever”, that changes the calculation.

We’ll happily help you think through it before you commit. We’d rather lose a project than build the wrong thing.