The question before the how
There is a separate article on how to build headless WordPress with Next.js. This one is about whether to. The architecture has a real upside and a real cost, and the deciding factor is almost never technical. It is what the site is for, who edits it, and who maintains it.
What headless gives you
Speed and Core Web Vitals headroom. A Next.js front end serving cached pages from the edge is faster than a well-tuned WordPress theme and much faster than a typical one. LCP under a second is normal. For sites where performance is a ranking or conversion lever, this is the argument.
Front-end control. Every pixel is a React component you wrote. No theme constraints, no plugin injecting markup, no builder CSS. Design systems, animations, interactive tools are all first-class.
Security surface. The public site is static files and cached pages. WordPress sits behind authentication on a private hostname. Most WordPress attack surface is not reachable from the internet at all.
Multi-channel content. The same WordPress content feeds the website, a mobile app, a kiosk, a partner integration, via the same API.
Editor familiarity. Editors keep the WordPress admin they know. That is the whole reason to choose WordPress as the headless CMS over a purpose-built one.
What headless costs you
Two systems instead of one. WordPress hosting plus Next.js hosting. Two deploy pipelines. Two things to update and monitor. Two sets of logs when something breaks.
Plugins that stop working. Any plugin whose value is on the front end does nothing: SEO plugins' output, form plugins' rendering, comment systems, membership gates, related posts, sliders, most of the block library's front-end styles. Each needs a headless equivalent built or bought. This is the largest hidden cost and the one that ends projects.
Preview and editing friction. The "Preview" button has to be rewired. The "View page" link has to be rewired. Live preview needs work. The block editor's what-you-see-is-what-you-get promise weakens, because the front end renders blocks its own way. Editors notice.
Developer dependency. A WordPress theme can be tweaked by a WordPress developer, of whom there are many. A Next.js front end needs a React developer. New page types, new layouts and new blocks all need code. The client's "can we add a testimonials section" becomes a ticket rather than a drag-and-drop.
Cost. Build cost is typically 1.5 to 2.5 times a comparable WordPress theme build, because you are building a rendering layer from scratch and re-solving the plugin problems. Ongoing cost is higher too.
Profiles where it pays
A content-heavy site with performance as a commercial priority. A publisher, a large marketing site, a site competing on search in a crowded market, where editors are already in WordPress and a fast front end is worth the build cost.
A site that already needs a React front end. An application with a marketing site and a blog attached, where the team is React developers, and WordPress is chosen because it is the best editor for the content people, not because of its themes.
Multi-channel content. The content genuinely goes to more than one destination.
A brand with strict design requirements that WordPress themes and builders fight.
Developer-led teams. An in-house or retained developer who will own both halves.
Profiles where it does not
A ten-to-thirty page business site. The performance gap between a good block theme and a headless front end is real but small at this scale, and the plugin and editing costs dominate. Build a good WordPress site or a plain Next.js site with MDX content; do not do both.
A store. Headless WooCommerce is a much larger project than headless content, because cart, checkout, account and payment are all front-end features that WooCommerce provides and headless throws away. Only for large stores with a team.
A site edited by non-technical owners who add sections and pages themselves. The block editor with patterns lets them; headless takes it away.
No developer after launch. The site will freeze at the state it launched in. A WordPress theme degrades more gracefully.
Plugin-dependent sites. Memberships, LMS, directories, events, forums. The plugin is the product; headless removes it.
Budget-constrained projects. If the difference between headless and a theme is the difference between doing the project and not, do the theme.
A middle path worth knowing
For a business site that wants a fast front end and a familiar editor without the plugin problem, the alternative to headless WordPress is often a Next.js site with content in MDX or a lightweight headless CMS built for the purpose. The editor is different from WordPress but purpose-built for structured content, the plugin problem does not exist because nothing was expecting plugins, and the cost is lower than headless WordPress. Our own site is built this way. The case for headless WordPress specifically is that the editors must keep WordPress; if they are open to another editor, the calculus changes.
How to decide in one meeting
- List every plugin on the current or planned WordPress site and mark which have front-end output. Each is a cost line in headless.
- Ask who edits, what they add (content only, or sections and pages), and how often.
- Ask who maintains it in year two.
- State the performance target and whether a good theme could hit it.
- Put the two build costs side by side, with year-two running costs.
If the plugin list is short, the editors add content not structure, there is a developer in year two, and the performance target needs it, headless pays. Otherwise, it usually does not, and a well-built WordPress theme or a plain Next.js site is the better spend. We build all three, which is why we can say which one a given project needs before quoting it.