WordPress (headless) review
Familiar editor, existing content
WordPress is the option in this directory that most developers would not pick and many clients will insist on, and the reason is worth taking seriously rather than dismissing. It is GPL software running on commodity hosting, with an editor your client has probably already used, and a market of agencies who can pick the project up if yours goes away. That is a procurement argument, not a technical one, and it is a good argument.
Used headlessly, you get the REST API that has been in core since version 4.7, exposing posts, pages, custom post types, taxonomies, media and users out of the box. Most serious headless builds add WPGraphQL, because the REST API's response shapes are verbose and fetching a page's worth of related content takes several round trips where one GraphQL query would do.
The commercial position is the part the rest of this directory cannot match. It is GPLv2 or later, so there is no vendor who can reprice you, change your acceptable-use terms or be acquired. That is not theoretical: elsewhere in this directory you can read about a customer facing a 20x increase for adding a third language and another told mid-build that their industry was now enterprise-only. Headless WordPress is what people named in both threads.
Our scorecard
Our editorial read across six dimensions, scored 1 to 5. This is our own assessment, not an aggregate of user reviews, and it is deliberately kept out of the page's structured data.
- Content modelling3/5
Custom post types and fields work well, usually via ACF. It is a blog schema extended, not designed.
- Developer experience2/5
The weakest here. PHP, a plugin stack you assemble yourself, and REST responses you will want to replace.
- Editor experience4/5
Familiar to almost everyone, which is worth more in practice than a better interface nobody knows.
- Pricing5/5
GPL software on commodity hosting. Nothing else here is this cheap or this un-repriceable.
- Governance3/5
Roles and revisions in core, and everything beyond that is a plugin you chose and now maintain.
- Ecosystem5/5
The largest in existence by an enormous margin, with all the security implications that carries.
An editorial read, not an aggregate of user reviews, and deliberately kept out of this page's structured data.
What you can query
REST API (core)
/wp-json/wp/v2/
Posts, pages, custom post types, taxonomies, media, comments, users and settings as JSON, with no plugin required since 4.7
WPGraphQL
Community plugin, not core
A typed GraphQL schema over the same content, which most serious headless builds add because REST needs several round trips per page
Advanced Custom Fields
Third-party, now Automattic-owned lineage disputed
The de facto content-modelling layer, exposing structured fields to both APIs. Almost every headless build uses it or a rival
Custom post types and taxonomies
Registered in code or UI
Registered in PHP or via a plugin, they become REST and GraphQL resources automatically, which is how you escape the blog schema
Application passwords
Core, no plugin needed
Core authentication for API clients since 5.6, avoiding a plugin for basic authenticated reads and writes
Media library
Your infrastructure
Uploads with generated image sizes, served from your own host or an object store, with no vendor CDN in the path unless you add one
Who WordPress (headless) is for
Projects where the client owns the decision, where content already exists in WordPress, or where the priority is that any agency can take over later. Those are real and common situations, and in all three the alternatives lose on grounds that have nothing to do with engineering quality.
It is also the pragmatic answer for a team that has been repriced by a SaaS CMS and wants a backend nobody can change the terms on. What it is not is a pleasant developer experience, and choosing it means accepting a maintenance obligation that never ends.
Strengths and limits
What it does well
- GPLv2 or later, so no vendor can reprice you, change acceptable-use terms, or be acquired and repositioned. That is unique in this directory.
- A REST API in core since 4.7, so a headless build needs no plugin to start reading content.
- The editor is already familiar to a very large share of clients, which removes a training cost most comparisons ignore.
- Agency portability: clients can replace their developer without replacing their CMS, which is why they ask for it.
- Hosting is commodity and cheap. As a headless backend it serves JSON rather than rendering pages, so it needs less than a traditional install.
- WPGraphQL gives you a proper typed GraphQL layer when the REST responses become the bottleneck.
- Custom post types and ACF cover most content modelling requirements, and both surface automatically in the APIs.
- Existing content stays where it is, so migrating a large WordPress site to a headless front end is a front-end project rather than a content one.
Where it falls short
- The developer experience is the weakest in this directory. PHP, a self-assembled plugin stack, and REST responses verbose enough that most teams add GraphQL.
- Maintenance never ends and it is entirely yours: core updates, plugin updates, PHP version upgrades and the security consequences of all three.
- Security exposure scales with plugin count, and headless does not remove the admin surface unless you deliberately lock it down.
- The content model is a blog schema extended rather than designed, so deeply structured content always feels retrofitted.
- Nearly every serious build depends on third-party plugins, particularly ACF and WPGraphQL, which are not core and are not guaranteed.
- No official GraphQL, no MCP server and no first-party headless tooling. Everything past the REST API is community.
- Performance depends on your caching and hosting decisions rather than on a vendor CDN, so a slow headless WordPress is usually a configuration you own.
- Two systems to reason about: the WordPress admin and your front end, with preview and revalidation to wire up yourself.
WordPress (headless) pricing
The software is free under the GPL and there is no vendor to bill you. What you pay for is hosting, and as a headless backend WordPress needs noticeably less than a traditional install, because it is serving JSON to a build process or a front end rather than rendering pages for every visitor. Shared hosting genuinely suffices for many projects, and one practitioner in the Prismic thread reports running a Next.js site on a headless WordPress backend at around 3 million visits a month for roughly $200 a month in hosting.
The real cost is maintenance, and the honest way to present it is as an ongoing obligation rather than a one-off. Core updates, plugin updates, PHP version upgrades and the security posture of whatever plugin stack you assembled are all yours, permanently, with no vendor SLA behind them. A team that will not budget those hours should buy a hosted CMS instead, because an unmaintained WordPress is a liability rather than a saving.
Set against that is the thing nobody else here can offer. Every hosted platform in this directory can change its prices, its limits or its acceptable-use policy, and this directory documents customers who found that out the hard way. GPL software cannot be repriced, and that is worth something real when you are choosing a backend you intend to keep for a decade.
The software
Free
GPLv2 or later
- No seats, no documents, no API calls, no locales metered
- No vendor who can reprice or reclassify you
- Copyright 2011-2026 by the contributors
- The only licence here that cannot be changed on you
Hosting
From a few dollars
Commodity to enterprise
- Shared hosting is genuinely enough for a headless backend
- One practitioner reports ~$200/mo serving 3m visits a month
- The backend serves an API, not page renders, so it does less work
- Managed WordPress hosting is available at every price point
The real cost
Maintenance
Yours, permanently
- Core, plugin and PHP updates are your responsibility
- Security exposure scales with your plugin count
- No vendor SLA, no support queue, no roadmap
- Budget the hours rather than pretending they do not exist
Query example
A minimal fetch against the live API, with credentials read from the environment rather than pasted inline.
# Core REST API, no plugins required:
curl -s -G "https://cms.example.com/wp-json/wp/v2/posts" \
--data-urlencode "per_page=10" \
--data-urlencode "_embed=1" \
--data-urlencode "status=publish"
# _embed pulls the author and featured media in rather than
# leaving you three more requests to make. Without it, a list of
# ten posts with authors and images is a request storm.
#
# That verbosity is why most headless builds add WPGraphQL:
# { posts(first: 10) {
# nodes { title slug author { node { name } }
# featuredImage { node { sourceUrl } } } } }
# One query, exactly the fields the page needs.Limits and quotas
- Licence: GNU General Public License version 2 or later, copyright 2011-2026 by the contributors.
- REST API is in core from WordPress 4.7 onward at /wp-json/wp/v2/.
- Application passwords for API authentication are core from 5.6.
- GraphQL requires the WPGraphQL plugin; it is not part of core.
- Structured field modelling in practice requires ACF or an equivalent plugin.
- No vendor-imposed limits on seats, documents, API calls, locales or bandwidth.
- Requires PHP and MySQL or MariaDB.
- No vendor SLA, support queue or security guarantee of any kind.
What developers say on Reddit
Developers argue about WordPress endlessly and the most useful threads are not about the software at all. In r/webdev's recurring "is WordPress still relevant" discussions, the highest-voted answer is that clients do not care how a site is built, they care that it loads fast and they can update it. The rebuttal, also heavily upvoted, is sharper and more interesting: larger clients absolutely do care, because they want a stack that lets them replace one agency with another without a rebuild.
That second point is the real argument for headless WordPress and it is a procurement argument. Agencies report clients specifically requesting it to avoid dependence on a single specialist, and describe choosing headless WordPress for the blog of an otherwise custom JavaScript site for the same reason.
It is also the escape hatch. In the Prismic repricing thread and in Storyblok's acceptable-use thread, both documented elsewhere in this directory, headless WordPress is what people reach for when a SaaS vendor has just changed the deal. One commenter there gives the practical numbers: a Next.js front end on headless WordPress at around 3 million monthly visits for roughly $200 a month.
“Web design agency owner; clients don't care how their sites are built. They want them to load fast, convert, be responsive with a modern design and be able to update them easily.”
r/webdev on Reddit“This might be true for small businesses, but not for any relevant business or enterprise customer we catered to over the last 20 years. They do care [...] they want to be able to drop and replace one agency for another without any thinking”
r/webdev on Reddit“I had a big client who requested Wordpress recently because he believed it will be cheaper, less maintenance, and more compatible between different agencies. [...] we recently developped a custom made website in Javascript, and we choose to use headless Wordpress to manage its blog.”
r/webdev on Reddit“Many customers want WordPress, because they know it best, and to avoid being too dependent on one specialized agency”
r/webdev on Reddit“Headless WordPress is great, I have a next.js website with Headless WordPress backend that get around 3M visits per Month, we pay around 200$ per month for Hosting.”
r/webdev on Reddit
Verdict
Choose headless WordPress for commercial reasons, not technical ones, and be honest that this is what you are doing. The editor is already familiar, the content may already be there, any agency can take the project over, and no vendor can reprice you or decide your industry is now enterprise-only. Those are the reasons clients ask for it and they are legitimate.
Budget the maintenance properly or do not do it. Core updates, plugin updates, PHP upgrades and the security surface of whatever stack you assemble are permanent obligations with nobody behind them. A hosted CMS is charging you partly for that work, and pretending it is free is how a cheap decision becomes an expensive incident.
Add WPGraphQL early if the site is anything more than a blog. The core REST API is fine for reading posts and painful for assembling a page, and the round-trip count is the thing that turns a headless WordPress build slow. Plan the plugin stack, particularly ACF and WPGraphQL, as architecture rather than as things you add when you hit a wall.
WordPress (headless) FAQ
What does headless WordPress cost?
The software is free under GPLv2 or later. You pay for hosting, which as a headless backend is cheaper than a traditional install because it serves JSON rather than rendering pages. One practitioner reports around $200 a month serving a Next.js front end at roughly 3 million visits a month.Do I need a plugin for the API?
Not to start. The REST API has been in core since WordPress 4.7 and exposes posts, pages, custom post types, taxonomies, media and users at /wp-json/wp/v2/. Application passwords for authentication are also core, from 5.6.Why do people add WPGraphQL?
Because the REST API's responses are verbose and assembling a page takes several round trips. WPGraphQL gives you a typed schema where one query returns exactly the fields a page needs. It is a community plugin rather than core, which is a dependency worth acknowledging up front.Why do clients keep asking for WordPress?
Portability. Agencies report that clients, including large ones, specifically want a stack where they can replace one agency with another without rebuilding the site. That is a rational procurement position and it has nothing to do with whether developers enjoy the software.What is the real downside?
Maintenance that never ends and belongs entirely to you: core updates, plugin updates, PHP upgrades and the security exposure of your plugin stack, with no vendor SLA behind any of it. If nobody on the project owns that permanently, a hosted CMS is the safer purchase.How do I model structured content?
Custom post types and taxonomies for the shapes, and in practice Advanced Custom Fields or an equivalent for the fields. Both surface automatically in the REST and GraphQL APIs. It works well, though the result is always a blog schema extended rather than a model designed for your content.Is it a good escape from a SaaS CMS repricing?
It is the most-named one. This directory documents a customer facing a 20x increase for a third locale and another moved to enterprise mid-build over their industry. GPL software cannot be repriced or reclassified, which is exactly why headless WordPress comes up in both of those threads.Headless WordPress or a modern headless CMS?
A modern headless CMS if your team owns the decision and values developer experience, editorial tooling and somebody else handling maintenance. Headless WordPress if the client owns the decision, the content already exists, agency portability matters, or you specifically want a backend no vendor controls.
Other platforms worth a look
This is an independent review. We have no affiliate relationship with WordPress (headless), earn nothing if you sign up, and no vendor pays for placement in the directory. Prices were read from the vendor's own pages in September 2026 and change without notice.