Headless WordPress with Next.js is worth it when you need two things at once: a content team that publishes every week in the WordPress editor, and a frontend that has to be fully custom and fast. If only one of those is true, a single stack is cheaper and easier to run. I treat headless as the answer to a specific problem, not an upgrade every site should get.
What does headless WordPress actually mean?
In a normal WordPress site, WordPress stores the content and also renders the pages through a theme. In a headless setup, WordPress only stores and serves content. A separate Next.js app requests that content through the WordPress REST API or WPGraphQL and builds the pages visitors see.
So you run two things:
- WordPress as the admin, the editor, the media library and the content API.
- Next.js as the website, deployed on its own hosting such as Vercel or Cloudflare.
The editing experience stays familiar. Everything the visitor touches is new code.
When is headless WordPress worth the extra work?
I recommend it when all three of these are true:
- The content team is active. Several people publish posts, landing pages or resources every week and need to do it without a developer.
- The frontend is the product. Custom interactions, a strict design system, or speed targets that a theme and page builder will struggle to hit.
- There is budget for integration. Someone has to build and maintain the layer between the two systems.
If nobody edits the site weekly, plain Next.js is simpler. That is the route procol.ai takes: it is a full Next.js site, server rendered from a shared typed component library, so new landing pages are assembled from tested sections rather than built in a page builder. My own portfolio, mohitgoyal.in, skips WordPress entirely. Case studies and posts are Markdown files in the repo, and the profile lives in Firestore.
If the frontend does not need to be special, plain WordPress on a lean builder is cheaper. Most of my client sites are exactly that.
How do the three options compare?
| Factor | Traditional WordPress | Headless WordPress + Next.js | Plain Next.js |
|---|---|---|---|
| Who edits content | Marketing team in WordPress | Marketing team in WordPress | Developer, or a Markdown or CMS workflow |
| Frontend freedom | Limited by theme and builder | Full | Full |
| Speed out of the box | Needs caching and plugin discipline | Fast by default | Fast by default |
| Form, SEO and slider plugins | Work as normal | Frontend plugins stop working | Not applicable |
| Hosting | One server | Two systems to host and secure | One deployment |
| Build effort | Lowest | Highest | Middle |
| Best for | Content-led sites on a budget | Content-led sites with a custom frontend | Product and brand sites that change rarely |
What do you have to rebuild in a headless setup?
This is the part that surprises people. Themes and plugins quietly do a lot of work, and once WordPress stops rendering pages, that work moves to the Next.js side.
- Previews. Editors expect to click Preview and see the page. In headless, preview needs a route in Next.js that fetches draft content with authentication.
- SEO metadata. Titles, descriptions, Open Graph tags and canonical URLs from Yoast or Rank Math have to be fetched and rendered by Next.js.
- Sitemaps and robots rules. Generated by the frontend, from the same content the pages use.
- Redirects. Redirects saved in a WordPress plugin do nothing unless Next.js reads and applies them.
- Forms. Contact Form 7 or WPForms embeds will not render. Forms post to an API route or straight to your CRM, such as HubSpot.
- Menus, search and comments. Each needs an API call and a component.
- Cache refresh. When an editor publishes, the live page must update. Usually a webhook from WordPress tells Next.js to revalidate the affected pages.
None of this is hard, but it adds up. It adds a week or more to a build compared with a single-stack site, and it is ongoing work: every new content type needs a query, a type and a template.
REST API or WPGraphQL?
Both are fine. My rule:
- REST API for simple content models: posts, pages and a few categories. It ships with WordPress and needs nothing extra.
- WPGraphQL when pages pull many custom fields from Advanced Custom Fields (ACF) or several post types at once. One query returns exactly what the page needs.
On WordPress builds such as IIID Inscape and Orilite, I modelled content as custom post types with ACF fields, so editors fill in fields rather than lay out pages. That same discipline is what makes a headless build pleasant later. Structured content travels well over an API. Page-builder layouts do not.
What are the signs that headless is the wrong choice?
- The site lives in a page builder and the team wants to keep building layouts visually. Headless removes the builder.
- The budget covers the launch and nothing after. Two systems need two sets of updates and two sets of security patches.
- The only goal is speed. A lean WordPress build can get there. Ravens Ait, a Bricks Builder site I built with WP Rocket caching, has a reported PageSpeed score of 94 or higher.
- The site depends on WooCommerce checkout. Headless commerce is possible, but it is a much bigger project than headless content.
A quick test
List the five things your team changes most often on the site. If most of them are blog posts and landing pages, the editor matters. If most are design and interactions, the frontend matters. You only need headless when both lists are long.
Is there a middle ground?
Yes, and I use it often. You can keep WordPress rendering the site and add React only where you need it. My HTTP Security Header Scanner is an example. It runs as a page on my WordPress site: PHP exposes a REST API endpoint, and a JavaScript frontend calls it and renders the report. It feels like an app, but it shares the hosting, the brand and the editor with the rest of the site.
For a marketing site, the equivalent is a lean WordPress build with one or two custom components for the parts that need them, such as a calculator or a product configurator. Orilite has a materials calculator inside an ordinary WordPress site, and nobody needed a second system for it.
How should you decide?
Write down who edits the site each week and what the frontend must do that a theme cannot. If you want a second opinion, the free Tech Stack Advisor recommends a stack from what you are building and who maintains it. For the broader choice between the two stacks, read Next.js or WordPress for a marketing site.
If headless is the right call, I build it as a headless WordPress project, with previews, redirects, forms and SEO wired up before launch rather than discovered after it.
