Headless WordPress with Next.js: When to Choose It and What It Costs

The question of when to choose headless WordPress with Next.js gets answered badly more often than it gets answered well. It is a fashionable architecture, it photographs nicely in a proposal, and it carries the quiet promise of being more modern than a plain WordPress theme. None of that tells you whether it is right for a specific site, and the honest answer is that for most small and mid-sized business sites it is not. A well-built classic WordPress theme will serve them better, cost less, and be easier for the people who actually edit the content.

Headless is the right call in three concrete situations, and only those three. You already have a React team who can own the frontend. The same content has to be reused somewhere beyond the website, such as a native mobile app. Or you have a genuine performance or scale requirement that a properly tuned classic build demonstrably cannot meet. If one of those is true, the architecture earns its keep. If none of them is true, you are paying more money for a more fragile setup and a worse editing experience. This article walks through the full stack you would actually have to build and run, names the three scenarios precisely, and frames the cost without the usual optimism.

What headless WordPress actually means

In a normal WordPress site, one system does everything. WordPress stores the content, and a PHP theme running inside that same WordPress install renders the pages a visitor sees. The browser asks WordPress for a page, WordPress builds the HTML, and that is the website.

Headless splits that in two. WordPress keeps the half it is genuinely good at, which is content editing, the media library, user roles, and the familiar admin screens your client already knows. It stops rendering the public website. Instead it exposes the content as an API, and a separate application fetches that content and renders the pages. With a Next.js stack, that separate application is a React framework that builds the public site and serves it to visitors. The browser never talks to WordPress directly any more. It talks only to the Next.js app, and the Next.js app talks to WordPress behind the scenes.

That separation is the whole idea, and it is also the source of every cost in this article. You are no longer running one system. You are running two.

The headless WordPress stack: a bill of materials

People discuss headless WordPress as if it were a single product you switch on. It is not. It is an assembly of parts, and you should see the full list before you commit, because each part is something to build, host, secure, and maintain.

The first part is the WordPress backend itself. Going headless does not delete WordPress. You still have a real WordPress install that needs a host, core and plugin updates, backups, and security hardening. It can sometimes run on a smaller, cheaper plan than a public-facing site would need, because it serves API requests rather than page traffic, but it is not free and it is not maintenance-free. Managed WordPress hosting is the sensible home for it. One thing changes in its security profile worth noting. The admin login now serves no public pages at all, so it should sit behind authentication or an IP allowlist rather than being openly reachable.

The second part is the API layer, and in a Next.js stack that almost always means WPGraphQL. WPGraphQL is a free plugin that exposes your WordPress content as a GraphQL API. It is preferred over the built-in WordPress REST API for headless work because GraphQL lets the frontend request exactly the fields it needs in a single query, rather than over-fetching data or making several round trips. In practice you will also install companion plugins so that custom fields and SEO metadata are available to the API. WPGraphQL for Advanced Custom Fields exposes ACF field groups to the graph, and WPGraphQL for Yoast SEO exposes the meta titles, descriptions, and social tags so that your SEO survives the move off the theme. A typical query the Next.js app would send looks like this.

query PostBySlug($slug: ID!) {
  post(id: $slug, idType: SLUG) {
    title
    content
    seo {
      title
      metaDesc
    }
  }
}

The third part is the Next.js frontend, which is the website your visitors actually see. This is a full React application. In 2026 it will be built on the Next.js App Router, and the rendering choices you make here matter more than anything else for a content site. Pages that rarely change can be generated as static HTML at build time. Pages that change can use Incremental Static Regeneration, which means they are served as static files but quietly rebuild themselves in the background. You also choose where this application is hosted. Vercel, made by the team behind Next.js, is the zero-configuration option, though its usage is metered and a busy site has a bill. Self-hosting on your own Node server or in a container is fully supported and gives you more control, but then you own the scaling, the caching, and the CDN setup yourself.

The fourth part is the revalidation strategy, and this is the part that catches teams out. In classic WordPress, an editor clicks Publish and the page is instantly live. In a headless setup, that page was already built as a static file, so clicking Publish in WordPress does nothing to it until something tells Next.js to rebuild. You have two ways to solve this. Time-based revalidation rebuilds the page on a fixed interval, which is simple but means content can be stale for up to that interval. On-demand revalidation has WordPress fire a webhook when content is saved, and that webhook calls a Next.js endpoint that rebuilds only the affected page. On-demand gives editors a near-instant experience, but it is real plumbing that you build and that can fail. A minimal revalidation endpoint looks like this.

// app/api/revalidate/route.js
import { revalidatePath } from 'next/cache'

export async function POST(request) {
  const { slug, secret } = await request.json()
  if (secret !== process.env.REVALIDATE_SECRET) {
    return Response.json({ ok: false }, { status: 401 })
  }
  revalidatePath(`/blog/${slug}`)
  return Response.json({ revalidated: true })
}

The fifth part is preview mode. In classic WordPress, previewing a draft simply works. In headless it does not, because drafts are never published to the static frontend. Next.js provides Draft Mode and you build a preview route that authenticates against WordPress and fetches the unpublished draft through WPGraphQL. This has to be built and tested deliberately. Skip it, and your editors lose the ability to see their work before it goes live, which is a workflow regression they will notice within an hour.

The sixth part is image handling. WordPress generates and stores multiple image sizes in its media library. The Next.js Image component wants to optimise and serve images itself, handling resizing, modern formats, and lazy loading. You have to reconcile those two. Either you configure Next.js to proxy and optimise images that are still hosted on the WordPress domain, or you offload media to a CDN or object storage. Neither happens automatically, and image handling done carelessly is a common reason a headless build ends up slower than the classic site it replaced.

That is the stack. Six parts, two systems, several plugins, and a webhook in the middle. None of it is exotic, but all of it is yours to run.

The three SMB scenarios where headless is the right call

Headless WordPress with Next.js is genuinely the better architecture in three situations. They are worth stating precisely, because the value depends on actually being in one of them.

The first is when there is already a React team. If the agency or the client has developers who build and maintain React or Next.js products elsewhere, a headless WordPress frontend uses exactly the skills they already have. Editors stay in WordPress, developers stay in React, and nobody has to learn PHP theming. The tooling and the learning curve, which are the main hidden costs of headless, are already paid for because the team and the capability exist. In this situation headless removes friction rather than adding it.

The second is when the same content has to be reused beyond the website. If the articles, products, or listings that appear on the site must also appear in a native mobile app, a kiosk display, or a partner integration, then WordPress as a headless content API becomes a single source of truth that every one of those clients can consume. A classic WordPress install can render exactly one website and nothing else. The moment you need the content in two places, the headless API stops being an indulgence and becomes the obvious design. This is the textbook content-as-a-service case.

The third is a genuine performance or scale need that a classic build cannot meet. Think of a high-traffic site where even a well-optimised classic theme with full page caching is straining, or a site that needs genuine app-like interactivity that a server-rendered PHP theme keeps fighting against. Static Next.js pages served from a CDN edge absorb traffic spikes without effort and produce very strong Core Web Vitals. The useful comparison is the one Shopify developers will recognise. A classic WordPress theme is the equivalent of a Liquid template, rendered by the platform from the CMS. A headless Next.js frontend is the equivalent of a custom Hydrogen storefront. The trade-off has the same shape in both worlds, and you reach for the custom build only when the templated one has hit a real wall.

Honesty matters most on this third point. For the large majority of SMB sites, a good classic theme with sensible caching and a CDN already delivers excellent Core Web Vitals. The scenario where classic genuinely cannot keep up is real, but it is rarer than proposals like to suggest. If someone is selling you headless on performance grounds alone, ask them to show you the classic build that failed first.

What headless honestly costs

The cost of headless WordPress is not a single number, and the upfront quote is the smallest part of it.

You are committing to two systems instead of one. There is a WordPress backend and there is a separate Next.js application, which means two codebases, two deployment pipelines, and two independent things that can break. The upfront build reflects that. A classic custom theme is one project. A headless build is a WordPress configuration project plus a complete frontend application, so it costs more to deliver before a single visitor arrives.

The ongoing cost is higher in the same way. You pay for WordPress hosting and for Next.js hosting, whether that is metered usage on Vercel or the operational time of self-hosting. On top of that you pay for the developer time to keep the frontend healthy. Frontend frameworks move quickly, and Next.js major versions arrive with migration work attached, which is a recurring cost a classic theme does not carry.

Some things that were free in classic WordPress now cost real effort. Instant publishing becomes the revalidation plumbing described earlier. Draft preview becomes a feature you build. And a significant slice of the plugin ecosystem simply stops working, because many plugins assume they control the theme and the rendered page. Most form plugins, many analytics and SEO injectors, and page builders in particular do not survive the move to headless. If a client loves their page builder, headless takes it away from them.

Crucially, none of this replaces WordPress maintenance. The backend still needs updates, backups, and security hardening exactly as before. Headless adds a second system to maintain. It does not subtract the first.

The fair summary is that headless is an investment that pays back cleanly when one of the three scenarios applies and does not pay back at all when none of them does. In that second case you have spent more money to get a more fragile architecture and a worse experience for the people editing the site. There is also an SEO cost to budget for. Headless neither helps nor harms search rankings automatically. You have to actively carry the SEO across, with Yoast metadata exposed through the graph, sitemaps generated on the Next.js side, and canonicals, redirects, and structured data all handled correctly. Done well it can improve rankings through faster pages. Skipped, a headless migration quietly loses them.

Making the headless decision honestly

The right way to approach headless WordPress with Next.js is to start from the three scenarios and work backwards. Is there a React team to own the frontend. Does the content need to live somewhere beyond the website. Has a real, measured performance need outgrown what a tuned classic build can do. If you can answer yes to one of those with evidence, headless is a sound, deliberate choice and the stack in this article is what you will build. If you cannot, a custom classic WordPress theme is the better, cheaper, more maintainable answer, and choosing it is not settling for less.

This is the assessment we make at WitsCode before any architecture is decided. We will tell a client plainly which side of that line they fall on. If they are genuinely in one of the three scenarios, we build the headless stack properly, with WPGraphQL configured cleanly, a revalidation strategy that keeps editors happy, working preview, sensible image handling, and SEO carried across in full. If they are not, we build them a fast, well-structured classic theme and save them the cost and the operational weight of a system they did not need.

If you are weighing a Next.js and WordPress headless build and want a straight answer about whether it is right for your site before anyone writes code, that is the conversation to have with us first.