Headless WordPress With Next.js: The Honest Trade-offs
Pairing WordPress with a Next.js front end can give you a faster, safer site that editors still know how to use. It also doubles what you maintain. Here is how to tell if it is worth it.
Headless WordPress gets pitched as the best of both worlds: the editor your team already knows, with a fast, modern front end in Next.js. Sometimes it is exactly that. Other times it is two systems to maintain where you used to have one, and a marketing team that has lost half the features it relied on. I have built both kinds of project. Here is how the trade-offs actually play out.
What "headless" means here
In a traditional WordPress site, WordPress stores your content and also builds every page with a PHP theme. In a headless setup, WordPress only stores and manages content. A separate Next.js application fetches that content and renders the website visitors see. WordPress becomes an admin screen and a data source, often on a subdomain the public never visits.
The general case for separating content from presentation is in headless vs traditional CMS. This post is about the WordPress version specifically.
REST API or WPGraphQL
There are two common ways for Next.js to get content out of WordPress:
- The REST API is built into WordPress core. Posts live at
/wp-json/wp/v2/posts, pages at/wp-json/wp/v2/pages, and so on. Nothing to install and well documented, but you often fetch more data than you need, or make several requests to assemble one page. - WPGraphQL is a free plugin that adds a GraphQL endpoint. You ask for exactly the fields a page needs in one query, including related data like authors and categories. Plugins with their own data, such as Advanced Custom Fields, usually need an extra extension to expose their fields.
For a simple blog I am happy with REST. For anything with custom fields and relationships between content types, WPGraphQL is usually cleaner.
The benefits are real
Speed. The Next.js front end can serve pre-rendered or cached pages with minimal JavaScript, and no PHP runs when a visitor loads a page. The difference in practice is the one I describe in Next.js vs WordPress speed, and it sidesteps most of the usual reasons a WordPress site is slow.
A smaller security surface. The public site has no login page, no plugin endpoints and no PHP to exploit. WordPress can sit on a separate subdomain behind IP restrictions or extra authentication. It still needs updating — the basics in my WordPress security guide still apply — but a vulnerable plugin is far harder for an attacker to reach.
Design freedom. The front end is an ordinary Next.js app, so there are no theme constraints, and you can pull in content from other sources — a product database, a booking system — alongside WordPress.
The costs people leave out of the pitch
Two systems, two sets of updates
You now maintain a WordPress install and a Next.js application, with separate hosting, updates and monitoring. Budget for both, every month, not just at launch.
Previews take real work
In normal WordPress, "Preview" just works. In a headless build, the preview button has to open the Next.js site in a mode that fetches draft content, usually through Next.js' draft mode and an authenticated request back to WordPress. It is solvable, but it is custom work, and editors notice immediately if it is flaky.
Many plugins stop working
Anything that outputs HTML on the front end — page builders, sliders, galleries, shortcodes, pop-ups — does nothing on a Next.js site. Page builders like Elementor are effectively incompatible. Before you commit, list every plugin and ask what happens to it; my WordPress plugin audit guide is a good way to do that inventory.
Forms need rebuilding
Contact Form 7 or Gravity Forms will not render themselves on the new front end. You either rebuild forms in Next.js and submit them to a route handler or a form service, or post to the plugin through its API. Either way, validation, spam protection and form UX are now your code to own.
SEO plugins only do half the job
Yoast or Rank Math still let editors write titles and descriptions, and both can expose that data through the API. But nothing reaches the page unless the Next.js front end reads it and renders the tags, sitemaps and structured data itself. I cover how in Next.js SEO done right.
Side by side
| Area | Traditional WordPress | Headless WordPress + Next.js |
|---|---|---|
| Page speed | Depends heavily on theme, plugins and caching | Fast by default when pages are cached |
| Security surface | Login, plugins and PHP exposed publicly | Public site separated from WordPress |
| Editor previews | Built in | Custom work |
| Plugins and page builders | Work as expected | Front-end output does not carry over |
| Forms | Plugin handles everything | Rebuilt in the front end |
| SEO plugins | Output tags automatically | Data must be wired into Next.js |
| Hosting and maintenance | One system | Two systems |
| Upfront cost | Lower | Higher |
Who should do it
- Teams with a lot of existing WordPress content and editors who are happy in the WordPress admin, but a front end that has become slow or hard to change.
- Sites where performance or security is a hard requirement and there is budget for proper development.
- Businesses pulling content from several systems into one front end.
- Anyone with a developer, in-house or retained, who will own the Next.js side long term.
Who should not
If your marketing team builds landing pages in a page builder every week, going headless takes that ability away unless you rebuild it as flexible content blocks in Next.js — which is possible, but it is a project in itself. If your budget covers a site but not ongoing development, you are better off with a well-built traditional WordPress theme and good hosting. And if the real problem is simply a slow site, fix the plugins and hosting first. That is far cheaper than a new architecture.
How I approach it
When headless is the right call, I keep WordPress as boring as possible: a minimal plugin list, custom fields for structured content, and the block editor for body copy. The Next.js front end uses the App Router with cached pages that revalidate on demand when an editor hits publish, so changes appear within seconds without rebuilding the whole site. It follows the structure I outline in the App Router for business websites. Previews, forms and SEO are scoped and priced up front, not discovered halfway through the build.
Wondering whether headless is worth it for your WordPress site? Tell me how your team uses it today and I will give you an honest recommendation, or see projects I have built.
