Headless WordPress: what it buys you, and what it costs

"Headless WordPress" shows up in a lot of pitches as if it's a strictly better version of regular WordPress. It isn't — it's a different set of tradeoffs, and the plugins and workflows that make WordPress genuinely good at content get partly traded away for a frontend that isn't at the mercy of a PHP theme's rendering performance.

What you actually get

WordPress stays what it's already good at: editors who already know the interface, and a mature plugin ecosystem for content workflows — revisions, scheduling, roles, media management. Meanwhile the public-facing site becomes a fast, modern frontend, usually Next.js, pulling content through the WordPress REST API or GraphQL instead of rendering through a theme's PHP templates. That split is the entire point: editorial stays familiar, delivery gets fast.

What it costs, honestly

A lot of the plugin ecosystem — SEO tools, form builders, page builders — assumes it can render its own HTML into a theme. Once WordPress is just a content API, those plugins stop working the way their documentation describes, and some of that functionality has to be rebuilt on the frontend by hand. You're now maintaining a GraphQL or REST bridge and two deploy pipelines instead of one. And "preview this draft before publishing" — something editors take for granted in normal WordPress — has to be deliberately rebuilt on the headless side. It doesn't come free just because the CMS supports drafts.

When it's worth the tradeoff

Content-heavy sites where publishing velocity actually matters — a media property, a blog with a real editorial team publishing daily — and where the current WordPress frontend's page speed is measurably costing traffic or conversions, not just aesthetically bothering the engineering team. If slow page loads are showing up in real metrics, the tradeoff has already paid for itself before the project starts.

When it's not

A small business site with a handful of pages nobody updates more than once a quarter. The added complexity — two deploy pipelines, a rebuilt preview flow, plugins that need frontend equivalents — has to earn its keep against real publishing volume or real performance numbers. Without those, it's added maintenance for a problem the business doesn't have yet.