Short answer: for a marketing site in 2026, using WordPress as a headless CMS is usually the worst of both worlds. You pay to build and run two systems (a WordPress backend and a JavaScript front end), you lose the block editor's live preview and almost every plugin that touches the page, and your editors get a worse experience than they had before. The three classic reasons for going headless (speed, security, publishing to more than one channel) are now met more cheaply by a well-built conventional WordPress site, by a flat-file site, or, when you genuinely need an API-first content backend, by a code-first headless CMS such as Payload, Sanity, Directus, Strapi or Keystatic, which AI-assisted development has made far cheaper to build on. Headless WordPress still makes sense in two or three situations, and we cover them at the end.
What "headless WordPress" actually commits you to
Conventional WordPress renders the page: PHP templates, the block editor, plugins that output markup, one host. Headless WordPress keeps WordPress only as an editing screen and a database. Content comes out through the REST API or WPGraphQL, and a separate application, almost always Next.js, fetches it and renders every page. That front end has its own repo, its own build pipeline, its own Node hosting and its own set of failure modes.
Pantheon's own guide to the approach puts it plainly: "What was once a single WordPress site becomes an ecosystem of APIs, frontend applications, deployment pipelines and integration points that your team must build and maintain." (Pantheon, Should you use WordPress as a headless CMS) That is a vendor that sells headless hosting saying it.
The tooling has matured since 2020, but it has not settled. WP Engine's Headless Platform (formerly Atlas) rewrote its Faust.js framework from the ground up in 2025; the new version is a separate package that is incompatible with sites built on the old one, and the old Atlas Blueprints starter sites were discontinued with it (WP Engine, The next generation of Faust.js). WPGraphQL's creator left WP Engine for Automattic in late 2024 to turn it into a canonical WordPress.org plugin. Both are healthy moves for the ecosystem, and both are exactly the kind of churn a marketing team has no budget to follow. When the headless plans launched in 2022 they ran from $49 to $499 a month (WP Engine press release), on top of the WordPress side, and today the plans page sends you to sales.
What you lose, specifically
We would be more relaxed about the cost if the result were a better site for the people who use it every day. It usually is not.
Preview. In classic WordPress an editor clicks Preview and sees the page. In a headless build, "preview functionality often has to be rebuilt using API endpoints, authentication tokens and custom frontend logic" (Pantheon). Faust.js ships a preview implementation, which is a large part of why it exists, but it is one more thing that breaks when either side updates.
The block editor. Gutenberg's whole value is that what you arrange is what renders. Headless turns blocks into JSON or HTML strings that your front end has to reinterpret, block type by block type. Every block your editors use needs a matching React component, maintained forever. Most teams end up restricting editors to a handful of blocks, which is the opposite of what they were sold.
Plugins. The ecosystem is the reason most companies chose WordPress. Forms, SEO output, redirects, galleries, cookie consent, membership, WooCommerce: in a conventional site the plugin renders into the page. In a headless site it renders nothing unless you rebuild its output in the front end. As Lucky Media's review puts it, "for headless specifically, you only use a fraction of this ecosystem," and the free-software pitch "can be misleading for headless projects" once you add hosting, premium plugins, content modelling, preview configuration and maintenance (Lucky Media).
Operations. Two deploys, two hosts, two sets of credentials, two things to monitor. A content model change in WordPress can silently break the front end. We have inherited headless sites where nobody left at the company could run the build.
The reasons people wanted headless, and what meets them now
Speed
WP Engine's headless page claims "incredible performance up to 10x classic WordPress." The honest comparison is not headless versus the average WordPress site; it is headless versus a WordPress site built properly. The average is genuinely poor: in the HTTP Archive's Core Web Vitals Technology Report for June 2025, only 43.4 percent of WordPress origins passed all three Core Web Vitals, against 83.6 percent for Duda and 75.2 percent for Shopify (Search Engine Journal). But that figure is dragged down by page-builder themes and plugin stacks, not by PHP rendering. A block theme with no page builder, correctly sized images, full-page caching and a CDN passes Core Web Vitals without a JavaScript front end. We have never had to go headless to fix a slow marketing site; we have had to remove a page builder.
If you want to go further, a flat-file site removes the database and most of the plugin surface entirely and serves pre-rendered HTML from a small server. We compared the two in detail in WordPress or flat-file for a marketing site.
Security
The argument is that a static front end has no PHP to attack. True, but the WordPress backend still exists, still needs patching and still holds the admin logins; you have moved the attack surface, not removed it, and added a Node application and an API in the process. A conventional site with a hardened host, two-factor login, a short plugin list and a web application firewall gets most of the benefit. A flat-file site gets more of it, because there is no database at all.
Multi-channel content
This one is real, but it is rare for a marketing site. If the same content genuinely has to feed a website, a mobile app, a kiosk and a partner portal, you need an API-first backend. The question is whether WordPress is the right API-first backend, and in 2026 it usually is not.
The headless CMS calculus changed in 2025
Two things happened. First, the code-first headless CMSs grew up. Payload is MIT-licensed, installs inside a Next.js app, runs on Postgres, MongoDB or SQLite, and generates its admin panel, REST and GraphQL APIs and TypeScript types from a schema you write in code. In June 2025 the Payload team joined Figma, which confirmed that "Payload will remain an open-source product" (Figma, Welcoming Payload). Sanity, Directus, Strapi and Keystatic cover the same ground with different trade-offs (hosted versus self-hosted, SQL versus document store, git-backed content in Keystatic's case).
Second, AI coding tools made schema-first CMSs dramatically cheaper to build on. The expensive part of a Payload or Sanity project was never the CMS; it was the weeks of writing collections, fields, access rules and front-end components by hand. That work is now largely generated. Payload publishes official agent skills covering collections, fields, hooks, access control and a cms-migration skill for moving from WordPress, Contentful or Strapi. In our own AI integration work we routinely have a coding agent produce a complete content model, admin configuration and a typed Next.js front end in an afternoon, then spend the real time on design, content and QA. A headless WordPress build gets far less of that acceleration, because the hard parts (mapping Gutenberg output to components, rebuilding plugin behaviour, wiring preview) are integration work against a system that was never designed as an API.
So the honest comparison for a team that needs an API-first CMS is no longer "headless WordPress or an expensive enterprise CMS." It is "headless WordPress or Payload," and Payload wins on editor experience, preview, type safety and build cost.
The decision table
| Conventional WordPress | Flat-file (Grav) | Headless WordPress | Payload or similar | |
|---|---|---|---|---|
| Cost to build | Low to medium | Low to medium | High: two applications | Medium: schema plus front end, AI-accelerated |
| Cost to run | Managed WordPress host | Small VPS | Two hosts, two pipelines | One Node host plus database, or a hosted tier |
| Editor experience | Block editor, familiar | Visual builder, inline editing | WordPress admin with no page context | Generated admin, drafts, live preview |
| Preview | Native | Native | Rebuilt per project | Built in |
| Plugin ecosystem | Full | Small | Backend-only; front-end plugins do nothing | Growing; most needs are code |
| Performance | Good if built well; average is poor | Excellent | Excellent, at a price | Excellent |
| Security surface | PHP, database, plugins | Files only, no database | WordPress backend plus Node app plus API | Node app plus database |
| AI-readiness (Markdown, API) | With plugins | Every page served as Markdown; MCP server built in | Full API | Full typed API; agent skills published |
| Choose it when | You need the ecosystem, many authors, commerce | Marketing site, few editors, want speed and low running cost | You must keep WordPress editing and feed other apps | You need API-first content and are starting fresh |
Where headless WordPress is still the right answer
We are not against it; we are against it by default. These are the cases where we would build it.
A large editorial team that will not leave WordPress, feeding more than one app. A publisher with dozens of writers, established workflows and a mobile app has a real reason to keep WordPress as the writing tool and push content out through WPGraphQL. The editorial team's productivity outweighs the cost of the second system, and at that scale there is a developer to own it.
Very high traffic with strict separation between editing and serving. When the public site must survive a traffic spike or a security incident that takes the admin offline, a statically generated front end on a CDN with WordPress tucked behind a VPN is a defensible architecture. This is a security and resilience decision, not a marketing one.
An existing headless site that works. If you already run a healthy headless WordPress setup with a team that knows it, do not migrate for the sake of a blog post. Keep it, pin the Faust.js version, and plan the next rebuild around what you actually need.
Outside those, when someone asks us for headless WordPress, what they usually want is one of three things: a faster site, a safer site, or a site that AI assistants and other systems can read. We can deliver each of those without the second application.
What to do next
If you have a headless WordPress proposal on your desk, or a site that was built that way and now costs more than it should, send us the brief. We build conventional WordPress, flat-file and Payload sites, so the recommendation depends on your site, not on what we would rather build. Book a call and we will tell you which one fits, and why.