Headless WordPress with Next.js: When It Actually Pays Off

Headless WordPress is recommended far more often than it should be, and dismissed far more often than it deserves. Decoupling the front end from WordPress can transform performance and developer experience, but it also introduces real, recurring cost. Having built both traditional and headless WordPress sites for clients over several years, we have a fairly clear picture of where the line sits, and it is not where most blog posts draw it.

What headless actually changes

In a traditional setup, WordPress renders every page: PHP templates query the database, assemble HTML and send it to the browser. In a headless setup, WordPress becomes a content API. Editors keep the admin interface they know, but the public site is a separate application, in our case usually Next.js, which pulls content over the REST API or WPGraphQL and renders it itself.

That split buys you three things. The front end can be statically generated or cached at the edge, so time to first byte stops depending on PHP at all. The attack surface shrinks, because wp-admin can sit behind a firewall or on a private hostname while the public site is static assets and a handful of server functions. And front-end developers get a modern React toolchain instead of working inside a theme.

The architecture we deploy

Our standard stack is WordPress on a small managed host, exposed only as an API, with a Next.js application in front of it. Incremental Static Regeneration is the piece that makes this practical: pages are built once, served statically, and revalidated in the background when content changes, so the CMS is never in the critical path for a visitor.

const WP = process.env.WP_API_URL;

export async function getPost(slug) {
  const res = await fetch(
    WP + '/wp-json/wp/v2/posts?slug=' + slug + '&_embed',
    { next: { revalidate: 300 } }
  );
  if (!res.ok) throw new Error('WP fetch failed: ' + res.status);
  const posts = await res.json();
  return posts.length ? posts[0] : null;
}

A webhook fired on save_post hits a revalidation route so editors see changes within seconds rather than waiting for a cache window to expire. Previews take more work: you need a preview route in Next.js that authenticates against WordPress and fetches draft content. This is the area teams most consistently underestimate when they scope a headless build.

On the data side, the REST API is enough for most builds; WPGraphQL earns its place when pages compose many content types and you want one query per page instead of a waterfall of requests. Either way, keep the fetching behind a thin client module in the Next.js app, so components never know where content comes from and the contract with WordPress stays in one reviewable place.

Where the costs hide

• Plugins that assume they control the front end, such as forms, SEO output and e-commerce, need API equivalents or custom glue code.
• Previews, menus, redirects and permalink behaviour all require deliberate engineering rather than working out of the box.
• You now operate two deployments, two repositories and two failure modes instead of one.
• Ongoing maintenance needs a team comfortable in both PHP and React, which affects who can support the site later.

When it pays off, and when it does not

Headless earns its keep when the front end is genuinely demanding: publishers with sharp traffic spikes, organisations that reuse content across several channels, products where WordPress is one data source among many, or teams that already run React elsewhere and want a single front-end platform. In those situations the performance ceiling and the flexibility justify the operational overhead.

It is usually the wrong call for a brochure site, a small WooCommerce store, or any project where the editorial team leans on page builders and plugin-rendered features. A well-built classic theme behind full-page caching will match headless performance for most audiences at a fraction of the build and maintenance cost.

Treat headless as an architecture you graduate into when specific constraints demand it, not as a default. Get the decision right at the start and the rest of the project becomes much simpler.

Weighing up a headless build? Talk to STRCLI and we will give you an honest read on whether it fits your project.