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. A well-structured Next.js site can be 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. It is a React site on TanStack Start, with a chat that answers as me on the Claude API and 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 |
Related guide: Sanity vs headless WordPress: which CMS for Next.js?
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, usually through Next.js Draft Mode.
- SEO metadata. Titles, descriptions, Open Graph tags and canonical URLs from Yoast or Rank Math have to be fetched and rendered by Next.js. Both expose this data for headless use, through the Yoast REST API and Rank Math's headless support.
- 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. If you are moving off a theme, the free Redirect Map Builder turns a list of old WordPress URLs into a redirects() array for next.config.js.
- 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 triggers on-demand revalidation of the affected pages.
None of this is hard, but it adds up. It adds noticeable integration time compared with a single-stack site, and how much depends on the content model. It is also ongoing work: every new content type needs a query, a type and a template. For what that means in budget terms, see how much a headless WordPress site costs. If you are replatforming an existing site, my guide to moving from WordPress to Next.js without losing SEO covers the checks to run before launch.
Related guide: WordPress Multisite: when to use it and when not to
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 with good caching and disciplined plugins can get there without a second system. Ravens Ait, for example, is a Bricks Builder site with 20+ event pages, Stripe bookings and HubSpot forms, all on ordinary WordPress.
- 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. You can keep WordPress rendering the site and add React or JavaScript only where you need it. A common pattern is a custom REST API endpoint in PHP with a small JavaScript frontend that calls it and renders the result. The page feels like an app, but it shares the hosting, the brand and the editor with the rest of the site. My HTTP Security Header Scanner is a free browser tool that sits on inspiredmonks.com alongside the rest of the site, rather than on a separate system.
For a marketing site, the equivalent is a lean WordPress build with one or two custom components for the parts that need them. A calculator or product configurator can live inside an ordinary WordPress page, and nobody needs 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 you are comparing developers, read what to check before hiring a headless WordPress developer.
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. Book a 20-minute discovery call or send me your project details, and I'll tell you plainly whether headless is worth it for your site.
