Headless WordPress with Next.js: when it's worth it (and when it isn't)

"Should we go headless?" is one of the most common questions I get from clients running WordPress. The honest answer is: sometimes. Here's how I decide.

What "headless WordPress" actually means

You keep WordPress as the content management system (the editor, the roles, the media library your team already knows) but the public site is rendered by a separate front-end (here, Next.js) that pulls content through the WordPress REST API or GraphQL.

WordPress becomes the back office. Next.js becomes the storefront.

When headless is worth it

• You want app-like speed and interactivity. A Next.js front-end with server rendering and fine-grained control over JavaScript can outperform a plugin-heavy classic theme.
• You're already building in React. If your team lives in React/Next, reusing that stack for the front-end is a productivity win.
• You need to serve multiple front-ends from one content source: a website, a mobile app, a kiosk.
• You want to escape theme/plugin bloat while keeping editors happy.

When to stay classic

• Small team, tight budget. Headless is genuinely more moving parts: two codebases, two deploys, more to reason about.
• Plugins do the heavy lifting. If your site leans on plugins that render on the front-end (certain builders, forms, membership tools), going headless means rebuilding that functionality.
• Editors rely on live preview exactly as the theme renders it. Preview is solvable headless, but it's work.

A middle path

You don't have to go all-in. I often recommend classic WordPress done well, a hand-coded theme instead of a bloated multipurpose one, which captures most of the performance win without the operational overhead of two codebases.

How I'd approach a headless build

1. Model content cleanly in WordPress (custom post types, ACF fields) so the API is predictable.
2. Consume it in Next.js with static generation plus on-demand revalidation, so pages are fast and still update on publish.
3. Solve preview and auth early; they're the parts teams underestimate.
4. Keep the editor experience first-class; the whole point is to keep WordPress's strengths.

Bottom line

Headless WordPress is a powerful pattern, not a default. Choose it when the speed and flexibility genuinely pay for the added complexity, and be honest when a well-built classic theme would serve the client better.