Headless and React
Headless WordPress With Next.js: When It’s Worth It for Client Projects
A practical decision framework for agencies: the client situations where headless WordPress with Next.js pays for itself, the ones where it does not, and a ten-question scorecard to use in scoping.
Headless WordPress with Next.js is the most requested “modern” stack we see in agency briefs, and also the one most often chosen for the wrong reasons. The technology is excellent. The question is whether this particular client gets enough benefit to justify running two systems instead of one, for years.
This post gives you a practical way to decide. It assumes you know the basics; if not, start with our headless WordPress guide for agencies.
What Next.js adds on top of WordPress
Next.js is a React framework that can render pages on the server, generate them statically ahead of time, or refresh them incrementally when content changes. Paired with WordPress, it gives you:
- Full control of the front end in React, with the client’s component library and design system.
- App-like interactions — instant filtering, client-side navigation, logged-in areas — without fighting a PHP theme.
- Flexible rendering: static pages for marketing content, server rendering for personalised pages, both in one project.
- Edge hosting on platforms such as Vercel or Netlify, which can be very fast globally.
What it takes away is just as important: theme-rendered plugins stop working, previews and SEO output need to be rebuilt, and every content change has to reach the front end through a cache strategy you design.
Four situations where it is worth it
1. The client already runs React
A SaaS company with a React product and an in-house design system wants a marketing site its developers can contribute to. Headless lets them reuse components while the marketing team keeps WordPress. This is the clearest win.
2. The site is really an application
Product configurators, booking flows, dashboards, member areas with live data. Building these inside a classic theme is possible, but the code ends up as a React app squeezed into PHP templates anyway.
3. One content source, several outputs
The same content feeds the website, a mobile app and partner integrations. WordPress becomes the content hub and each channel renders its own way.
4. Strict security or scale requirements
Enterprise policy requires the CMS to sit behind a firewall, or traffic spikes are large and unpredictable. A statically generated front end with a private WordPress back end handles both cleanly.
Four situations where it is not
- “We want it to be faster.” A good classic theme on good hosting is fast. Our Core Web Vitals guide shows how to get there for a fraction of the cost.
- The marketing team builds pages in Elementor or Divi. They lose their page builder. That is usually a deal-breaker once they understand it.
- The site depends on front-end plugins — forms, memberships, LMS, bookings, most WooCommerce extensions. Each becomes custom work.
- Nobody will maintain the front end. If the client has no JavaScript developer and no maintenance budget, a headless site slowly rots.
The costs people forget
| Item | Classic WordPress | Headless with Next.js |
|---|---|---|
| Editor previews | Built in | Custom preview routes and authentication |
| SEO meta, schema, sitemaps | SEO plugin outputs them | Fetched via API and rendered by the front end |
| Redirects | Redirect plugin | Synced to the front-end host |
| Forms | Form plugin | Rebuilt in React with a submission endpoint |
| Hosting | One host | WordPress host plus front-end host |
| Updates | WordPress and plugins | WordPress, plugins, Node packages and framework upgrades |
None of these is hard for an experienced team. All of them are hours, and they recur. If the quote does not include them, the client will discover them after launch.
A ten-question scorecard for scoping
Ask these in the first call. Score one point for every “yes”. Six or more and headless is worth a serious proposal; three or fewer and a well-built classic or block theme is almost always the better recommendation.
- Does the client already have React developers or a React design system?
- Does the site need app-like features beyond normal content pages?
- Will the same content be used outside the website?
- Is there a security requirement to keep the CMS off the public internet?
- Can the editorial team work without a visual page builder?
- Can every front-end plugin the site depends on be replaced or rebuilt?
- Is there budget for previews, SEO wiring and redirects as line items?
- Is there budget to host and monitor two systems?
- Will someone own front-end updates after launch?
- Can the client explain the business benefit in one sentence?
Question ten matters most. “Our competitor did it” and “it is the future” are not business benefits.
A middle path worth considering
Many projects that ask for headless really need one interactive feature — a product finder, a calculator, a filtered directory. You can build that feature in React and embed it in a classic or block theme, keeping everything else simple. Another option for interactive blocks is the WordPress Interactivity API, which we will compare with React in a later post in this series.
How to propose it
- Sell a paid discovery first. Inventory plugins, decide on WPGraphQL or REST, define preview and SEO approach, then quote the build.
- Quote in components: content model, front end, previews, SEO, forms, deployment, documentation. Clients understand the price when they see the parts.
- Include a maintenance plan in the proposal, not after it. Two systems need looking after.
- Show the classic alternative alongside, with its lower cost. It builds trust, and sometimes the client chooses it — which is fine.
The same thinking applies to theme decisions generally; our post on custom versus premium themes for client projects uses a similar approach.
Frequently asked questions
Next.js or Astro?
Next.js when the front end is interactive or app-like. Astro when the site is mostly content and you want minimal JavaScript in the browser.
Can we move an existing site to headless later?
Yes. The content stays in WordPress; you build a new front end against it. Clean up the content model first, because theme-specific shortcodes and builder markup do not translate well.
Does headless hurt SEO?
Not if it is built properly with server or static rendering and complete meta output. It hurts when SEO output is an afterthought, which is common.
Is it more secure?
It reduces the public attack surface when the WordPress admin is not exposed. It also adds a second system to keep updated, so it is not automatically safer.
Need a Next.js team without hiring one?
We build headless WordPress projects for agencies under their brand, from the content model to the Next.js front end and the run book. Read how the white label model works, or send us the brief and we will tell you honestly whether headless is the right call.