We have been quoting headless WordPress builds since 2019. Over the last twelve months, the requests have tripled. Every prospect with a marketing budget over a hundred thousand wants to know whether they should be on Next.js with a WordPress backend, and whether the editorial team is going to hate it.
The architecture is now mature enough to recommend. It is not the right call for every project, though. Here is the framework we use to decide.
What headless WordPress is
Headless means decoupling the WordPress admin and database from the public site rendering. WordPress still hosts the content — posts, pages, custom post types, media, users, taxonomies. But the public site is rendered by a separate front-end framework, usually Next.js, that pulls content from WordPress through a REST or GraphQL API.
The editor still logs into the WordPress admin. The dashboard still looks like WordPress. The content still lives in wp_posts. The plugin ecosystem still works. What changes is that wp_query and the_content() are not running on the public URL the visitor hits. Next.js is.
The most common stack we ship is WordPress on a managed host (Kinsta, WP Engine, Pantheon), exposed via WPGraphQL, consumed by a Next.js app running on Vercel with incremental static regeneration. ACF Pro for custom fields. Yoast for SEO meta exposed through the GraphQL schema.
What you gain
Three things, mostly.
First, performance. A pre-rendered Next.js page served from Vercel’s edge is faster than any PHP-rendered WordPress page on any host. We see real-world LCP numbers in the 0.8 to 1.4 second range, against 2.0 to 3.5 seconds for the same content rendered through PHP on similar hosting.
Second, front-end developer experience. Next.js gives you React, modern JavaScript tooling, a real build pipeline, a real component model. For a marketing team that wants to ship interactive features — animations, dynamic forms, live search, personalization — the React front end is meaningfully easier to extend than the PHP theme it replaces.
Third, separation of concerns. The editorial team works in WordPress and never sees the front-end code. The front-end team works in Next.js and never touches the admin. The two teams can ship on different cadences, with different stacks, without stepping on each other.
What you lose
Plugin previews stop working in many cases. If a plugin relied on adding a shortcode that ran in the_content() and printed HTML on render, that shortcode does not run on the Next.js side unless you build a mapper for it. The same applies to most page builders, which we already do not recommend, but the conversation is sharper in a headless setup.
The preview workflow gets harder. The native ‘preview post’ button in WordPress assumes the front-end is the same WordPress. In a headless setup you need to wire up a preview URL on Next.js that authenticates against WordPress, pulls the unpublished post, and renders it. WPGraphQL has decent tooling for this, but it is custom work.
The build cost goes up. A custom Next.js front end is a real software project. Six to twelve weeks of front-end engineering, plus the WordPress backend setup, plus the GraphQL schema configuration. The total project cost is typically 1.5x to 2x a comparable monolithic WordPress build.
The operational cost also goes up. Two hosting environments, two deploy pipelines, two monitoring stacks. For a marketing site, this might mean an extra hundred to three hundred dollars a month in infrastructure. Not enormous, but not zero.
When it earns the architecture
Four conditions, any of which by itself is enough to justify the build.
First, the front-end performance budget is tight. If the brief calls for Lighthouse mobile scores in the 90s on a content-heavy site, you can hit that target on a tuned monolithic WordPress, but you have to fight for it every release. On a Next.js front end you hit it by default and have to actively break it to lose it.
Second, the front-end is going to have a lot of interactive features. Filterable product catalogs with instant updates. Personalization based on signed-in user state. Real-time search. A configurator. Anything that benefits from a real component model is easier to build in React than in PHP-rendered templates with jQuery sprinkled on top.
Third, the editorial team is large and the developer team is large and they need to ship independently. If both teams are bottlenecking each other in a single deploy pipeline, decoupling the stacks lets each team ship on its own cadence.
Fourth, the project has a real budget and a multi-year horizon. A headless build is a six-figure investment. It pays back over years, not months. For a small-business marketing site with a 30-thousand-dollar budget, the math does not work.
When monolithic WordPress is the right call
For most projects that arrive in our discovery calls — content sites with a marketing team of two or three, moderate performance budgets, no exotic interactivity, three-year horizons — monolithic WordPress on managed hosting with a tuned theme is still the right answer. It is cheaper to build, cheaper to operate, cheaper to extend, and the team can ship without learning React.
The headless conversation is not about being modern. It is about specific requirements. If the requirements are not there, the architecture is wasted.
The 2022 outlook
The reason these requests are tripling, in our read, is that Next.js 12 has made the developer experience genuinely good and WPGraphQL has stabilized to the point where it is a serious option. Both of those changes happened in the last twelve months.
We expect the trend to continue through 2022. Enough marketing teams now know what ‘headless’ means that they ask for it by name. The job of the agency is to be honest about whether it is the right call, not to take every brief that asks for it. Our discovery process now includes a headless-fit assessment for any project above a certain budget threshold because the answer is so often genuinely ‘not yet.’