Headless WordPress with Next.js - when it makes sense and when it is overengineering
"Let's go headless" - you hear it more and more often in meetings about a new website or store. It sounds modern, it suggests speed and the kind of technology big companies use. Few people mention what it costs and what you lose along the way.
I have built a headless WooCommerce store, and I will say it plainly: in that case it was not worth it. Below I explain what this setup is, what it really gives you, where it gets expensive and how to check whether your project needs it at all. I am not against it. I also build applications in Next.js and React, so I know when it is the right call. In my experience that happens less often than agency offers suggest.
The short answer
Headless WordPress is a setup where WordPress is only used to enter and store content, while a separate application, for example in Next.js, renders the website. It gives you full freedom over the interface and lets you reuse the same content in several places. It also costs more, because instead of one system you have two, and some plugins and editing conveniences stop working.
Most business websites, blogs and stores do not need headless. Speed and SEO can be achieved with regular WordPress. At the end you will find six questions that help you decide, plus a short note on how AI has changed the cost of building this kind of setup.
What headless WordPress is (without the jargon)
Traditional WordPress is a restaurant where the kitchen and the dining room are one space. The same system stores the content and displays it. When you change a text in the admin panel, you see it on the site right away.
Headless splits this into two parts. WordPress stays the kitchen: the admin panel, post editing, media, users. The dining room becomes a separate application that fetches the content and shows it to visitors. Between them sits the serving hatch, the API. WordPress has a built-in REST API (since version 4.7), and the WPGraphQL plugin adds an alternative in the form of GraphQL.
Next.js is the most common choice for the front end. It is a React-based framework that can prepare pages ahead of time and serve them very quickly. The same approach works with other frameworks. In my project the front end was Gatsby and the communication went through GraphQL. The principles are the same regardless of the tool.
It is called "headless" because WordPress is left without the layer the visitor sees. If you have been reading about WordPress as a headless CMS, this is the setup people mean.
What headless really gives you
There are four reasons this setup can be justified.
Freedom in the interface. Any animations, unusual navigation, solutions a WordPress theme cannot handle without fighting its structure.
The same content in many places. One admin panel feeding the website, a mobile app and other services. This is the strongest argument, and regular WordPress has no simple equivalent.
Separated workflows. The front-end team and the editors do not get in each other's way. Editors work in a familiar panel, developers in their own code.
A potentially faster site. Careful here. In my project the site loaded noticeably faster, and I will not play that down. At the same time, the authors of the WPBeginner guide to headless WordPress point out that in smaller projects regular optimization with caching and a CDN gives a similar result. A high PageSpeed score is achievable on regular WordPress too, with a lightweight custom theme and no page builder. If speed is your only reason, start with what I described in the post on a slow WooCommerce store.
What headless costs (what offers do not tell you)
I am not giving price ranges, because they depend on the scope. Instead I describe where the cost comes from, so you can judge an offer yourself.
Two systems instead of one. Separate hosting for WordPress and for the application, separate updates, monitoring, backups. More places where something can stop working.
Plugins do not work on their own. Many plugins handle forms, SEO, cookies, search, pop-ups or bookings and render their output through the theme. In a headless setup there is no theme, so a plugin installed in WordPress shows nothing on the front end. Its features have to be exposed through the API and built separately in the application, or replaced with another service. This one fact decided the whole story I describe below.
No preview before publishing. The "Preview" and "View" buttons in the admin panel no longer show the page as the visitor will see it. In my project previewing a post before publishing was practically impossible. Content appeared on the site only after publishing and rebuilding the application, and until then the editor could only see it in the WordPress editor. Preview can be built (Next.js has Draft Mode for that), but it is one more feature to develop. For a team used to editing "live", that is a big change.
The block editor and templates need translating. Every new block type in Gutenberg needs a counterpart in the application. That is developer work every time a new need comes up.
SEO has to be implemented. Meta tags, the sitemap, structured data, redirects and canonicals all have to be built in the front end. I did an SEO migration from WordPress to Gatsby using Yoast SEO: I exposed the plugin's data through GraphQL and used it in the application. It can be done well, but it does not happen by itself, and a mistake during migration costs you visibility in Google. If you are planning such a move, read about rebuilding a store without losing SEO first.
In general: a custom front end is a separate software project, not an add-on to your existing WordPress. How to count the cost over time rather than on launch day, I show in the posts on how much a WordPress website costs and how much a WooCommerce store costs.
Traditional WordPress vs headless
| Criterion | Traditional WordPress | Headless |
|---|---|---|
| Systems to maintain | One | Two (WordPress and the application) |
| Design freedom | Limited by the theme | Practically full |
| Speed | Good after optimization (caching, lightweight theme) | Potentially higher, but not guaranteed |
| Plugins on the front end | Work after installation | Need a separate implementation |
| Post preview | Built in | Has to be built, or unavailable |
| Editor convenience | High | Lower, depends on what the developer builds |
| SEO | Ready after installing a plugin | Has to be implemented in the front end |
| Changes and new features | Often a ready-made plugin | Usually developer work |
| Dependence on the developer | Lower | Higher |
| Best fit for | Business websites, blogs, typical stores | Applications, multiple content consumers, custom interfaces |
When headless makes sense
Headless is justified when at least one of the conditions below is met and you have someone who will maintain it.
- You have an application (web or mobile) or several services that should draw on one content base.
- The interface is genuinely custom and cannot reasonably be built in a theme, for example because it behaves like an application.
- You have high traffic, a budget and a technical team that will maintain two systems. WPBeginner names this as the main condition.
- Your front-end team already works in React or Next.js and wants to keep the familiar WordPress panel for editors.
It is also worth knowing that WordPress as a CMS has no licence fees, unlike many commercial headless CMSs billed by subscription. If you have a reason to separate content from presentation, it is a sensible compromise.
When NOT to go headless
This is the most important part of the post.
A business website with a few subpages and a blog. Regular WordPress with a lightweight, well-written theme is more than enough. Whether the theme should be ready-made or custom, I cover in the post on template vs custom theme.
When the main reason is speed or SEO. Optimization, caching, a CDN and a decent theme come first. A high PageSpeed score does not require headless.
A typical WooCommerce store. Here I speak from experience. The cart, checkout, customer accounts, payments and courier integrations are an area where plugins are tightly bound to the theme. In a headless setup you have to build all of that on the front end yourself.
In the store I worked on, we had to write custom GraphQL connections for recurring payments and the InPost parcel locker integration. In my opinion headless was not a good decision there, and it was not really about the technology. The problem was communication between the person responsible for the product and the business. The feature specification was very weak, and nobody said out loud something that seems obvious today: installing a plugin in WordPress does not mean it works on the Gatsby front end. The plugin adds a feature on the WordPress side, and the front end has to receive it through the API and implement it separately.
The business expected that a plugin would be enough. The result: a gap between expectations and reality, and missing features written by hand. The lesson for the future: before choosing headless, list which features must work on the front end and who will implement each of them. Do not assume a plugin takes care of it.
Nobody to maintain two systems. A year from now, and three years from now, someone has to update both parts and fix whatever breaks.
Editors used to a page builder and a "just like on the site" preview. With headless they get something different, and they have to accept it.
Headless is usually not an upgrade of an existing solution. It is a different set of trade-offs.
Six questions that settle it
- Should the content go to more than one place, for example the website and an app?
- Is the interface genuinely custom, or do you just want it to "look more modern"?
- Do you have a team or a contractor who will maintain two systems on an ongoing basis?
- Will the editors accept a different preview and a different way of working?
- Does every plugin you rely on have a front-end counterpart, and will someone build it?
- Is the main reason speed that you could get more cheaply?
If you answer "no" to the first two questions, you probably do not need headless. It is an architectural decision, not a visual upgrade.
What AI has changed
A few years ago, writing custom connections between WordPress and the front end was tedious manual work. Today, with AI models and coding agents, building a headless website or store is much faster and more reliable. That changes the calculation, and it is only fair to admit it.
The change is not limited to the build. AI also speeds up maintenance in the sense of fixing bugs and shipping changes, because that is development work too.
What does not go away is what comes from the architecture itself: two systems, two hosting setups, two sets of updates, responsibility for failures in two places, and no ready-made preview for the editor. AI lowers the cost of writing code, but it does not change the fact that you have more parts that can fail. It moves the break-even point, but it does not remove it.
Alternatives worth knowing
Regular WordPress with a good theme and caching is usually enough. When a ready-made theme holds you back, a custom theme without a page builder helps. And when the project is really an application (user logins, a dashboard, software-like features), a standalone Next.js project without WordPress is often the better choice. I cover this in more detail in the post does WordPress still make sense.
FAQ
It is a setup where WordPress stores and manages the content, while a separate application, for example in Next.js, fetches it through an API and shows it to visitors. The editors' admin panel stays the same, only the layer the visitor sees changes.
It can be, but it is not guaranteed. In my project the site loaded noticeably faster. At the same time, in smaller projects regular optimization with caching and a CDN gives a similar result, and very good PageSpeed scores are also achievable on a custom WordPress theme without headless.
It can be, but SEO has to be implemented in the front end: meta tags, the sitemap, structured data and redirects. When migrating an existing site, you risk your visibility if you miss something. I do not judge the impact on rankings in general, because it depends on the execution.
It depends on the scope, which is why I do not give price ranges. The cost is developer work on the front end, integrations and maintaining two systems, not a software fee. The costs of a regular WordPress website and a regular WooCommerce store, which I describe in separate posts, give you a point of reference.
It can, I have done it myself. But you have to build the cart, checkout and support for plugins separately, all of which work out of the box in a regular store. For a typical store it rarely pays off.
On the WordPress side, yes, but their output will not appear on the front end by itself. The plugin has to expose its data through the API, and the application has to display it. Theme-bound plugins (forms, cookies, pop-ups, bookings) have to be replaced with your own code or an external service.
Yes, the admin panel stays. What changes is what you see after saving: a preview before publishing may not be available, and the change appears on the site after a refresh or an application rebuild.
Separating the layers can reduce the number of publicly exposed components, but it is not a guarantee. Two systems also mean two places to update and watch. Security depends on execution and maintenance, not on the architecture itself.
Summary
Headless WordPress is a tool for specific problems: many consumers of the same content, a custom interface, a technical team that will maintain it. It is not a "premium version" of regular WordPress. AI has made it cheaper to build, but it has not changed the fact that you have two systems instead of one.
If you are not sure, start with regular WordPress and optimize it. And if you want to check whether your case really needs headless, book a free consultation - I will tell you straight, and very often the answer will be "no". How the collaboration works step by step is described on the process page.