Headless WordPress with Next.js: When It Pays Off

Headless WordPress means using WordPress to write and store your content, and building the website your visitors see as a separate application that reads that content from WordPress. Next.js, the framework I build sites in, is a common choice for that separate front end.

This blog ran that way until October 2026, when I moved it off WordPress altogether. So I've lived with both halves of the trade. Here's what headless gets you, what it costs, and how to tell whether it's worth it for your site.

What "headless" means

A normal WordPress site is one system. You write in the WordPress editor, WordPress stores the post in its database, and the active theme turns it into the page a visitor sees. Plugins add to that page: a contact form, a slider, the tags an SEO plugin puts in the page's head.

In a headless setup, the theme no longer builds anything your visitors see. WordPress keeps the admin, the editor and the database. A separate front end asks WordPress for the content and builds its own pages from it.

The usual connection is WordPress's REST API, which hands your content to other applications as JSON data instead of finished pages. WordPress's own handbook lists building a new front end as one of the things it's for (REST API Handbook). Ask a WordPress site for /wp-json/wp/v2/posts and it answers with a list of posts (Key Concepts).

Older guides, including an earlier version of this post, list "activate the REST API" as a setup step. You don't need to. Its content endpoints, for posts, comments, terms, users, meta and settings, have come with WordPress since version 4.7, released in December 2016 (WordPress 4.7). The handbook says not to disable it, because parts of the WordPress admin depend on it (REST API FAQ).

One detail matters later: by default, the API returns published posts to anyone, but a draft only to a signed-in user who is allowed to read it (WordPress code reference).

What a Next.js front end gets you

• A design without a theme's limits. The front end is ordinary code, so the pages do what you build them to do, not what a theme and its settings allow.
• Pages built ahead of time. Next.js can serve pages that were built in advance, and refresh them on a schedule or on demand without rebuilding the whole site, so most visits get a page that's already made instead of waiting on WordPress (Next.js docs).
• Your editors keep WordPress. Nobody learns a new editor, and years of posts stay where they are.
• One source for more than one place. The handbook mentions bringing WordPress content into completely separate applications, so the same posts can feed a website and an app.

What headless doesn't do on its own is make WordPress safer. WordPress is still on the internet, its admin is still there to sign in to, and its public API endpoints can be reached from any site, by design (REST API FAQ). It needs every update and backup it needed before.

What it costs

Previews

In the WordPress editor, Preview in new tab opens the draft on WordPress's own front end (WordPress documentation). In a headless setup, that's WordPress's theme, not the site your visitors see.

To preview a draft in the real design, three things have to be built:

• The preview link has to point at the front end. WordPress lets code change it, through the preview_post_link filter (WordPress code reference).
• The front end has to sign in to read the draft, for example with an Application Password, which WordPress has shipped since version 5.6 (Authentication).
• It has to skip its cache for that request. Next.js has Draft Mode for this: an editor sees the draft instead of the cached page, behind a secret that only the site and the CMS know (Next.js docs).

None of it is hard for a developer. All of it is work a normal WordPress site doesn't need, and it has to keep working through updates on both sides.

Plugins that add to the page

Many plugins work by adding to the pages the theme builds. WordPress's wp_head hook, for example, prints scripts and data into the head of each front-end page, from inside the theme's header template (WordPress code reference). A separate front end doesn't run the theme, so anything a plugin adds that way never reaches your visitors: the form, the slider, the SEO plugin's tags, the cookie banner.

A plugin's data can reach the front end, because plugins can add their own fields to the API's responses (Modifying Responses). Someone still has to build the part of the front end that shows it. Every plugin feature you want to keep becomes a small project.

Even the post content needs work. On this blog, the post HTML that came from WordPress went through a cleanup step on the Next.js side: sanitized, links rewritten to their new addresses, and YouTube embeds swapped for a version that loads when you click it. Some old posts carried audio files that never appeared on the site at all: the sanitizer left them out.

Two systems to host and keep updated

WordPress doesn't stop needing care because nobody sees its theme. It still needs updates, backups, a current PHP version and a server: everything in my post on looking after a WordPress site. The front end needs its own hosting, its own dependency updates and its own deploys. And the two have to keep agreeing. If a plugin update changes what the API returns, the front end has to follow.

There's one more trap. Unless you stop it, WordPress keeps publishing every post at its own address as well, so the same article lives at two URLs. Google picks one of them as the canonical version, and its documentation suggests choosing your preferred URL and redirecting the others to it (Google Search Central).

Cost and complexity

With a theme, WordPress gives you the blog index, category pages, search and RSS feeds without anyone building them. Headless, the front end has to build each one. On this site, the Next.js side had its own post pages, post cards, a strip of recent posts in the header, the feed, the sitemap and search, all reading from WordPress.

That's why I quote this kind of work instead of pricing it like a plan. The size depends on how much of your WordPress site has to be rebuilt in the front end.

When headless pays, and when it doesn't

It tends to pay when:

• Several people publish often, know WordPress's editor, and shouldn't have to learn another.
• There's a large library of content you don't want to move.
• The front end has to do things a theme can't, or the same content feeds more than one place.
• There's a budget, and a developer, for two systems for years, not just for the build.

It usually doesn't when:

• It's a small business site with a handful of pages that change a few times a year. My post on whether you'll be able to edit your own website covers simpler ways to handle changes.
• The site leans on plugins that put things on the page.
• One person writes the blog and doesn't need WordPress's editor.
• The goal is only a faster WordPress site. Better hosting and a page cache on the site you have are cheaper to try first.

If you're still choosing between WordPress and a site built in code, start with my post on WordPress or a hand-built site.

How this blog left WordPress

Until October 2026, this blog was headless WordPress. Posts were written and stored in WordPress at blog.popproxx.com, and this Next.js site read them through WordPress's API to build its post pages, listings, feed, sitemap and search.

In early October 2026 I moved the posts into files in the site's own code, with their images copied into the same repository. The posts came over as the HTML WordPress had served, so they'd look the same as before. Posts I rewrite, like this one, switch to Markdown.

Every post I kept stayed at its address, and the ones I retired redirect elsewhere on the site. Old addresses on blog.popproxx.com, images included, now redirect to their new pages, and WordPress is switched off.

The trade: one system to run instead of two, and no WordPress editor. A new post is now a file in the site's code. It's checked on a preview copy of the site and goes live when the site deploys. That suits a blog where every post has one author and the rest of the site is code I already maintain. It wouldn't suit a team of writers publishing every day.

How I can help

• You have a WordPress site and want a faster front end on it. That's a custom project. You pay a $500 deposit and complete intake, and I send a free written quote with the scope, the price and the payment schedule. Nothing is built until you accept the quote in writing, and until then the deposit is refundable in full. Once you accept, the deposit counts toward the project price and the quote sets the terms, refunds included. Start a custom project.
• You want a new site and aren't attached to WordPress. My plans are Starter, $2,400 for five pages; Deluxe, $4,080 for seven; and Premium, $6,720 for ten. Each is one build fee, paid in full for 10% off or half now and half before launch, then the $79/mo care plan from launch day. If you'd still like to write your blog posts in WordPress, a WordPress-editable blog on a plan site is quoted separately. See how I design and build sites and the plans.
• You want to keep your WordPress site as it is. I host and look after existing WordPress sites case by case, on a written quote. Content and design changes aren't included. A $500 deposit starts the quote. It's refundable until you accept, and credited to the work. Ask for a quote.