Headless WordPress is a setup where WordPress is used only as the editing dashboard and content store, while a separate front end, often built with a framework such as Next.js, fetches that content through an API and renders the public site. It is worth it for app-like sites with a development team, and overkill for most small business websites.
Headless WordPress is WordPress used as the editor and the database, with the pages your visitors see built by a different piece of software. We get asked about it by owners who have heard it is faster or more modern and want to know if they are missing something.
Usually they are not. We have not needed a headless build for any client site so far, and we would rather say that than sell one. What we do every day is a close relative: we drive WordPress through its REST API from scripts. On one law firm's site, a script converted 552 blog posts to a new layout through that API. Same API, different purpose.
That experience is why we have opinions about when the full headless setup earns its cost.
What does headless WordPress mean?
Headless WordPress means separating the two jobs WordPress normally does together. The "body" is the dashboard where people write and the database that stores the content. The "head" is the theme that turns content into pages. A headless setup keeps the body and replaces the head with a separate application.
In a normal install, a visitor asks for a page and WordPress builds it with the active theme. In a headless install, a visitor asks a different application for the page. That application gets the content from WordPress over an API and builds the HTML itself.
Editors notice almost nothing. They log in to the same dashboard and write in the same editor. The theme is simply no longer what the public sees.
How does headless WordPress work?
Headless WordPress works by exposing content through an API, which a separate front end reads. WordPress ships with a REST API that returns posts, pages, and media as structured data. The front end requests that data, either when the site is built or when a visitor arrives, and renders the pages.
The flow looks like this:
- An editor publishes or updates a post in the WordPress dashboard.
- WordPress stores it and makes it available at an API address.
- The front end application requests the post as data.
- The front end renders the page with its own templates and sends it to the visitor.
- A cache or a rebuild keeps the public page in step with later edits.
A request for the five most recent posts is one line:
const posts = await fetch('https://example.com/wp-json/wp/v2/posts?per_page=5').then((r) => r.json());Step five is where the work hides. In ordinary WordPress, an edit is live as soon as the cache clears. In a headless setup someone has to build the mechanism that tells the front end a post changed.
What are the benefits and costs of going headless?
The benefits of going headless are front end freedom, speed, and a smaller public attack surface, because visitors never touch WordPress directly. The costs are two systems to host and maintain, a developer needed for every layout change, and the loss of most plugins that work by changing what the theme outputs.
| Traditional WordPress | Headless WordPress | Static site, no WordPress | |
|---|---|---|---|
| Who builds pages | The theme | A separate front end | A build script |
| Editing | Dashboard | Dashboard | Developer or a custom screen |
| Preview while editing | Built in | Has to be built | Not applicable |
| Plugins that change the front end | Work | Mostly do not | Not applicable |
| Systems to maintain | One | Two | One, with nothing running |
| Speed | Needs caching work | Fast when built well | Fast by default |
| Typical fit | Publications, most business sites | App-like sites with a dev team | Sites that change monthly |
The plugin row surprises people most. Form plugins, page builders, and anything that inserts markup into a theme assume the theme is there. Take it away and those features have to be rebuilt in the front end.
When is headless WordPress worth it?
Headless WordPress is worth it when the front end has to do things a theme cannot do comfortably, and the organization already has developers to maintain it. Typical cases are a site that is really an application, content that feeds several places at once, or a team that already builds everything in one framework.
- The site behaves like an app. Accounts, dashboards, and live data alongside editorial content. See website vs web application for where that line falls.
- One body, several heads. The same articles feed a website, a mobile app, and a kiosk.
- Editors love WordPress, developers need a framework. Both groups keep their tool.
- The public site must be isolated from the dashboard. The WordPress install can sit where visitors cannot reach it.
If none of those describes you, the benefits can be had more cheaply.
When is headless WordPress overkill?
Headless WordPress is overkill for a brochure site, a local service business, or a blog whose main complaint is speed. Those problems have cheaper answers: caching and cleanup on the existing site, or a static site with no WordPress at all. Headless doubles the moving parts to solve a problem you may not have.
We have taken both of the cheaper routes. For the law firm, we kept ordinary WordPress, rebuilt every practice page on one template system rendered from a spec file, and did a mobile performance pass. For a realtor, we retired WordPress entirely and moved the site to a static build with every original address intact. Neither needed two systems. We compare those two paths in WordPress or a static site.
Can you automate WordPress without going headless?
Yes. The same REST API that feeds a headless front end can be used in the other direction, to write content into an ordinary WordPress site from scripts. You keep the theme, the plugins, and the dashboard, and gain the ability to create and update pages in bulk.
This is how we work on most WordPress projects. RankAZona, our Arizona business publication, runs on WordPress, with Python scripts working through the REST API and a news engine that publishes every morning. The site visitors see is still ordinary WordPress.
For many businesses this is the useful half of the headless idea. We go into detail in automating WordPress with the REST API.
Frequently asked questions
Is headless WordPress faster than regular WordPress?
It can be, because the front end can serve pages that were built ahead of time. A well cached ordinary WordPress site can also be fast. Speed alone is a weak reason to go headless, since caching and cleanup cost far less than a second system.
Is headless WordPress more secure?
Somewhat. Visitors interact with the front end, so the WordPress login and plugins can be kept out of public reach. The WordPress install still exists and still needs updates. You have reduced exposure, not removed the maintenance.
Do WordPress plugins work on a headless site?
Plugins that work in the dashboard or on stored data generally still work, such as custom fields and editorial tools. Plugins that change what the theme outputs generally do not, because the theme is no longer used. Forms, sliders, and page builders are the common losses.
Does headless WordPress cost more to run?
Yes, in most cases. There are two things to host and two codebases to maintain, and changes to layout need a developer. The dashboard is unchanged, so editors need no retraining, but the total upkeep is higher than a single WordPress site.
What is a headless CMS?
A headless CMS is any content system that stores and serves content through an API without rendering the site. Headless WordPress is one way to get that.
If you are weighing a headless build, tell us what the site has to do. We will say so if plain WordPress or a static site would serve you better.