Headless WordPress: When It Makes Sense (And When It Doesn't)

Headless WordPress is having a moment. Next.js, Astro and Remix all have polished WP integrations. Hosting providers offer headless-first plans. The case studies are flashy. But for most sites, headless is the wrong answer.

We''ve shipped 8 headless WP builds in the last 18 months — and counselled at least 30 clients to not go headless. Here is the framework we use to decide.

What headless WordPress actually means

The standard WordPress install renders pages on the same machine that stores them. You write content, WP themes turn it into HTML, the user gets a page. Headless decouples those two: WordPress just serves data through the REST API or GraphQL, and a separate frontend (Next.js, Astro, etc.) renders it.

The promise: you get the editor experience of WordPress and the performance of a modern static-site framework. The cost: significant complexity in deployment, debugging and maintenance.

When headless is the right call

Headless makes sense in three specific scenarios:

• You need extreme performance. If LCP must be under 0.8s and Lighthouse must be 99+, the rendering overhead of PHP themes becomes the bottleneck.
• Your frontend is part of an existing app. You already have a Next.js product and want WP as a content backend. Headless lets you embed content into the existing application.
• You have specific UI requirements native WP cannot serve. Heavy interactivity, real-time data, complex client-side state — things React/Vue do well that PHP themes do not.

When headless is the wrong call

Most sites — including most that "want headless" — are better served by a well-built block-based theme:

• Your editorial team is non-technical. Headless breaks the WP preview experience, complicates plugin compatibility, and makes content edits riskier.
• You don''t have a dev team to maintain it. Headless adds a second codebase that needs deploys, monitoring, error tracking. Without ops, things break silently.
• Your performance issues are theme-level, not architecture-level. 90% of "WordPress is slow" problems are bloated themes — fixing the theme costs less and ships faster than going headless.
• You use WooCommerce. Going headless on Woo is doable but painful. Most stores should not.

If you''re going headless, do this

1. Pick the frontend deliberately. Next.js for product-style apps, Astro for content-heavy sites, Remix for hybrid. They are not interchangeable.
2. Use ISR / SSG, not pure SSR. The whole point of headless is shipping cached HTML. Server-side rendering on every request defeats the purpose.
3. Mirror the WP preview experience. Editors must be able to preview drafts. This requires extra work but is non-negotiable for adoption.
4. Plan for plugins. Half your plugin features will not work as-is. Map every plugin you depend on before committing.