Skip to content

WordPress (headless) review

Familiar editor, existing content

Reviewed by Eugene SuslovUpdated August 2026No affiliate links

Running WordPress headless means keeping the admin your editors already know while rendering the front end in Next.js, Astro or anything else. The REST API ships in core, and WPGraphQL adds a typed GraphQL layer that most serious headless builds standardise on.

The reason to do this is almost never technical elegance. It is that a team already has years of content, an editorial process built around WordPress, and no appetite for a migration, but the front end needs to be fast and modern.

Who WordPress (headless) is for

Organisations with an existing WordPress estate that want a modern front end without retraining editors or migrating content. Also agencies whose clients insist on WordPress.

A poor choice for a greenfield project, where you would be inheriting a lot of complexity for a familiar admin screen you do not need.

Strengths and limits

What it does well

  • Editors need no retraining, which removes the single most common reason CMS migrations stall.
  • The plugin ecosystem is unmatched, and much of it still works in a headless setup.
  • GPL-2.0 and free, running on hosting from a few dollars a month upward.
  • Existing content stays put, so there is no migration project at all.

Where it falls short

  • You now run two systems: a PHP application and a JavaScript front end, with two deploy pipelines and two sets of security updates.
  • Preview, and anything that depends on WordPress rendering a page, needs deliberate work to reimplement.
  • Most SEO plugins assume they control the output. Yoast and Rank Math metadata needs explicit wiring into your front end, and this is where headless WordPress builds most often regress on SEO.
  • The REST API is slow enough at scale that WPGraphQL plus caching is effectively mandatory rather than optional.

WordPress (headless) pricing

The software is free under GPL-2.0. Costs are hosting, which ranges from a few dollars a month on shared hosting to hundreds on managed WordPress platforms, plus any commercial plugins.

In a headless setup you are paying for two things at once: the WordPress backend and the front-end host. That is worth pricing explicitly, because it is a real difference against a single hosted CMS.

Verdict

The pragmatic answer when the content and the editors already live in WordPress and a migration is not on the table. Done well, with WPGraphQL and proper caching, it performs perfectly fine.

Do not choose it for a new project because it is familiar. You inherit a second stack, a second security surface and the metadata problem, and every other option here avoids all three.

Visit WordPress (headless)

WordPress (headless) FAQ

  • Is headless WordPress good for SEO?
    It can be, but it is where headless builds most often regress. Plugins like Yoast and Rank Math assume they are rendering the page, so their titles, descriptions, canonicals and schema have to be explicitly queried and emitted by your front end. If that wiring is missed, pages ship with framework defaults and nobody notices until traffic drops.
  • REST API or WPGraphQL?
    WPGraphQL for anything real. The core REST API works and requires no plugin, but it over-fetches badly and gets slow at scale. WPGraphQL gives typed queries that return only what a page needs, which is why most production headless WordPress builds use it.
  • Should I go headless with WordPress on a new project?
    Usually not. The reason to run WordPress headless is that you already have WordPress. On a greenfield build you would be taking on a PHP stack, a JavaScript stack and the metadata wiring problem in exchange for an admin interface you have no existing investment in.

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 August 2026 and change without notice.