Headless WordPress: Keep the Editor, Lose the Bloat?

Headless WordPress keeps the admin your editors already know, but swaps the theme and front end for a separate, faster-built site that pulls content through an API. It fixes WordPress’s biggest weakness, speed, without forcing anyone to relearn how to publish. The cost: a second codebase, plugins that stop working, and features like previews you now rebuild yourself.

Quick links

• What is headless WordPress, exactly?
• What does going headless actually fix?
• What does it complicate?
• When does a purpose-built headless CMS make more sense?
• So is it worth it?
• FAQ

What is headless WordPress, exactly?

Headless WordPress means WordPress stops rendering the pages people see. It becomes a content store that a separate front end talks to through an API, usually WPGraphQL or the built-in WP REST API.

In a normal WordPress site, the same install does two jobs: it stores your content in a database, and its theme turns that content into the HTML a browser shows. Going headless splits those jobs apart. WordPress still does the first job, and does it well: the editor, the media library, the roles and permissions, the workflow your team already knows. A different application, built in whatever framework the developers choose, does the second job.

The plugin that made this practical is WPGraphQL, a free, open-source tool that exposes your WordPress content through a single GraphQL endpoint. A front end built in Astro, Next.js, or something else entirely queries that endpoint for exactly the fields it needs, then renders the page itself. WordPress’s own description of the pattern is blunt about the trade: it becomes “a CMS that exposes content via an API, allowing you to choose any front-end technology to power the user-facing site or app,” according to WordPress.com’s own explainer. You keep the backend. You replace everything downstream of it.

Why this is even a conversation

WordPress runs a genuinely enormous share of the web: 40.7% of all websites, and 58.9% of the sites where the CMS is known, according to W3Techs’ technology survey. A lot of teams have years of muscle memory in that admin screen, a content library built up inside it, and no appetite to retrain editors on a new interface. Headless is the answer for teams who want out of the slow, bloated front end without giving up all of that.

What does going headless actually fix?

It fixes the three things that make a typical WordPress site painful: speed, the security surface, and the front-end straitjacket of a theme.

Speed

A standard WordPress page is assembled at request time (or from a cache) by PHP, a theme, and however many plugins are active, several of which are usually adding their own scripts and stylesheets whether the page needs them or not. That accumulation is why WordPress performs poorly on Core Web Vitals as a category: across major platforms, WordPress sites passed Core Web Vitals at roughly 49%, against about 67% for Astro sites and 85% for the best-performing platform, per HTTP Archive data reported by Search Engine Journal. Strip the theme and plugin stack out and hand rendering to a lean framework, and that bottleneck goes away, because the thing that was slow is no longer in the request path at all.

Security

Most WordPress security problems live in the plugin ecosystem, not in WordPress core. Patchstack’s 2025 security report found 7,966 new vulnerabilities across the WordPress ecosystem in 2024, a 34% rise on 2023, with 96% of them found in plugins and only seven in WordPress core itself. A headless setup does not touch WordPress core’s own record, but it does shrink the attack surface that matters in practice: the public-facing site no longer runs a theme, a page builder and a dozen front-end plugins that could be exploited to deface or hijack what visitors see. The WordPress admin can even sit behind a separate, more restricted URL or network, since nobody outside your team needs to reach it.

Front-end freedom

This is the part developers actually want. Once WordPress is just a data source, the front end can be built in whatever gives the best result for a marketing site: static generation for content that barely changes, islands architecture for the odd interactive widget, full control over markup, schema and page weight. You are no longer waiting for a theme update or a plugin compatibility fix to change how a page looks or performs. That matters for AEO as much as for humans: clean, fast, well-structured HTML is easier for AI crawlers like GPTBot and PerplexityBot to read and cite, and a purpose-built front end gets you there deliberately rather than by luck.

What does it complicate?

Going headless trades one set of problems for another. Be honest with yourself about these before committing.

You now maintain two things, not one

A themed WordPress site is one codebase. Headless WordPress is two: the WordPress install and the front-end application, usually on separate hosting, sometimes in separate repositories, often maintained by different people. That is more moving parts to deploy, monitor and keep in sync, and more places for something to break quietly between them.

Plugins that touch the front end stop working

WordPress’s plugin ecosystem is a large part of its appeal, and a good chunk of it assumes a theme is rendering the page. Anything that injects front-end markup, styling or scripts, from a page builder to a lot of “one-click” SEO or conversion plugins, has nothing to hook into once the theme is gone. Plugins that only shape the data, like an SEO plugin’s metadata fields or a custom fields plugin such as ACF, generally survive, because that data still flows through the API. Anything that assumes it can draw on the page does not.

Previews and drafts need rebuilding

In a normal WordPress site, clicking “preview” just renders the draft through the theme. In a headless setup, there is no theme to render it, so preview has to be built as its own feature, usually by having the front end fetch draft content and render it through the same components as the live site. Search, comments, contact forms and anything else the theme used to hand you for free need the same treatment. None of this is exotic engineering, but it is work that a stock WordPress site does not require.

It needs a developer, indefinitely

A themed WordPress site can, in principle, be run entirely by a non-technical editor for years. A headless site cannot: someone has to own the front-end codebase, its dependencies, its hosting and its deployments. If the plan is to hand the whole thing to an editor and walk away, headless is the wrong shape.

When does a purpose-built headless CMS make more sense?

Choose a headless CMS built for the job, rather than WordPress adapted into one, when your content model does not fit neatly into posts and pages, or when nobody on the team has WordPress habits worth protecting.

WordPress’s data model, at heart, is posts, pages and custom post types built on top of them. That works well for a blog or a fairly standard marketing site. It works less well for a product catalogue with dozens of variant fields, a multi-brand site with genuinely different content structures per brand, or an application-like site where content and app state are tightly linked. A CMS designed headless from the start, such as Sanity, Storyblok or Contentful, tends to model that kind of content more cleanly and ships editor previews as a built-in feature rather than something you assemble yourself. We compared the strongest options in detail in our headless CMS roundup.

The other signal is simpler: if there is no existing WordPress content, no editor who already knows the WordPress admin, and no plugin dependency worth keeping, there is no inertia to preserve. Headless WordPress earns its complexity by saving you a migration and a retraining exercise. Take those away and a CMS built headless from day one is usually the tidier choice, with less legacy plumbing to work around.

So is it worth it?

For a content-heavy WordPress site with editors who already know the admin, yes, usually, provided someone is committed to owning a front-end codebase for the long haul. For everyone else, it is worth comparing the honest shape of both routes before picking one. We go deeper on the underlying platform trade-off in Astro vs WordPress for SEO, and on the numbers behind either path in what a headless build actually costs.

The honest middle path is this: headless WordPress is not a compromise that leaves everyone slightly unhappy. It is a genuinely good fit for one specific situation, a WordPress site with content and editors worth keeping and a speed or flexibility problem worth solving, and a poor fit outside it. Know which one you are before you start building.