Headless WordPress: keep the CMS, ditch the front-end

We had a call last year with an organisation running about nine hundred articles through WordPress, with six people who publish to it every week. They'd read our piece on why we don't build on WordPress and their question was blunt: we agree the site is slow and we're sick of it breaking, but you are not taking this editor away from our team. What are our options?

That's the exact situation headless WordPress exists for. It's the half-step: you keep the WordPress admin, the editing workflow, the user roles and the publishing habits your team has spent years settling into, and you throw away the part visitors actually see. A new front-end, built on something modern, pulls the content out of WordPress and serves it fast.

It's a real option and we've built it. It is also oversold, usually by people who charge by the hour to maintain both halves. So here's the honest version: what it fixes, what it quietly doesn't, and who should skip it and just leave properly.

What headless WordPress actually is

A normal WordPress site does two jobs with one piece of software. Editors write in the admin, and the same PHP application renders every page for every visitor, pulling from the database each time, through whatever theme and page-builder layers have accumulated.

Headless splits the jobs. WordPress keeps the first one: it becomes a content database with a familiar editing screen on top. The second job goes to a separate front-end, usually built with Astro, Next.js or TanStack Start, which fetches the content over the WordPress REST API (built into every WordPress install since 2016) or WPGraphQL if you'd rather query it like a proper API. The front-end renders the pages, mostly at build time, and serves them from a CDN.

Your editors notice almost nothing. Same login, same post editor, same media library. Visitors notice a lot, because the thing answering their request is no longer a PHP application warming up a database connection. It's a pre-built page sitting on an edge server.

What it genuinely fixes

Three things, and they're not small.

Speed is the obvious one. WordPress's Core Web Vitals record is poor: on HTTP Archive's technology report, fewer than half of WordPress sites pass all three Core Web Vitals, and the failures are concentrated in loading speed rather than interactivity. That's the theme, the page builder and a dozen plugins each injecting scripts into every page. A headless front-end doesn't carry any of that. The comparison Search Engine Journal ran between WordPress and Astro sites shows the gap plainly. Same content, different renderer, very different numbers.

Second, the public attack surface shrinks. Visitors hit static pages on a CDN. There's no wp-login.php on your public domain for bot armies to hammer, no vulnerable theme rendering untrusted input, no plugin exposing an endpoint it shouldn't. Sucuri's hacked-website reporting has shown for years that infections overwhelmingly arrive through the software bolted onto the CMS, and the headless front-end simply doesn't run any of it.

And the bloat treadmill stops mattering to visitors. The page builder your last agency installed in 2019 can keep doing whatever it does inside the admin. None of its output ships to the browser anymore, because the front-end renders from content, not from the theme.

What it doesn't fix, and this is the part people skate over

You still run WordPress. All of it. The install, the database, the PHP version, the hosting bill, the updates, and above all the admin attack surface.

The numbers here haven't improved. Patchstack's State of WordPress Security report logged 7,966 new vulnerabilities across the WordPress ecosystem in 2024, roughly 22 a day, 96% of them in plugins, and 43% exploitable with no authentication at all. Going headless doesn't change a single one of those numbers for your install. Your WordPress admin is still on the internet somewhere, it still runs plugins, and it still needs someone patching it. WPScan's vulnerability statistics tell the same story from a different database. If your WordPress gets compromised, the attacker owns your content, your user accounts, and whatever the compromised server can reach. The static front-end will cheerfully keep serving whatever poisoned content the build pulls out.

And now you run two systems, not one. Two things to host, two things to deploy, two things that can be the reason the site is broken on a Saturday. When a page looks wrong, the first debugging question becomes "is this a WordPress problem or a front-end problem?", and you need someone on hand who can answer it. That someone is more expensive than a WordPress generalist, because the pool of developers comfortable on both sides of the split is smaller.

We think this trade is worth it for some teams. But it's a trade, not a free upgrade, and anyone pitching it as "all the benefits of leaving WordPress without the migration" is selling you the invoice for maintaining both halves.

Who it suits, and who should just leave

The honest test is your editorial team, not your technology.

If you have several people publishing every week, workflows built on WordPress roles and revisions, editors who've used this admin for a decade and will revolt at anything else, then keeping the CMS has real value. Newsrooms, content-heavy marketing teams, organisations with non-technical contributors across departments. For them, headless keeps the muscle memory and fixes the part readers experience. That was the right answer for the nine-hundred-article client.

If you're a business with forty pages and a blog that gets touched once a month, none of that applies to you. The editing workflow you'd be preserving barely exists. Port the content to markdown once, put it in git next to the code, and stop hosting a PHP application forever. That's a smaller job than people expect, and it's most of what we cover in our WordPress to Astro guide. You end up with one system instead of two, and the WordPress maintenance bill goes to zero rather than continuing alongside a new one.

Most of our clients are in the second group. We'd rather say that plainly than sell the fancier architecture.

The practical bits the tutorials skip

If you do go headless, three things deserve attention before anyone writes code.

Hide the origin. The WordPress install should not sit on your public domain waving at scanners. Put it on a separate hostname, lock the admin behind IP restrictions or an access proxy, strip the parts of the REST API you don't use, and work through the official hardening guide rather than a plugin that claims to do it for you. The install is now an internal tool. Treat it like one.

Sort out publishing before launch. A static front-end doesn't notice when an editor hits publish; something has to tell it. The usual answer is a WordPress hook that pings a deploy hook and triggers a rebuild, or on Next.js, incremental static regeneration so individual pages refresh without a full build. Either works. What doesn't work is discovering after launch that publishing a correction takes eight minutes to appear and nobody warned the editors.

Previews are the genuinely annoying part. In classic WordPress, preview is a button. In headless, the draft lives in WordPress and the renderer lives somewhere else, so previewing an unpublished post means wiring the front-end to authenticate against WordPress and render draft content on demand. Every headless framework has a documented pattern for this and every one of them is fiddlier than the button it replaces. Budget for it, because editors judge the whole project on it.

What it costs

Nothing gets cheaper. Be clear-eyed about that. The WordPress hosting stays, because WordPress stays, though you can usually move it to a smaller server since it no longer serves public traffic. The front-end hosting is close to free at small-business scale on Cloudflare or similar. The real costs are the build, which is comparable to a front-end rebuild in any migration, and the ongoing reality of two systems needing two kinds of attention. Compare that against a full migration where the WordPress line item disappears entirely, and headless is the more expensive path over a few years for most sites. It buys workflow continuity, not savings.

Where AI tooling changes the maths

One shift since we started doing these: the front-end half of a headless build is exactly the kind of codebase AI coding tools are good at. It's typed TypeScript in a git repository, built on frameworks like Next.js and Astro that tools such as Claude Code know deeply from training data. An agent can read the whole thing, make a change, and open a pull request a human reviews, and the type checker catches most of what it gets wrong. Front-end changes that used to be a billed dev ticket increasingly land as a reviewed diff the same afternoon. The rebuild itself is meaningfully cheaper in 2026 than the quotes people remember from a few years ago, for the same reason.

But notice what stays out of reach. In a headless setup your content still lives in WordPress's MySQL database, and the WordPress half is still PHP smeared across plugin options and a themed runtime, which is precisely the environment an agent can't safely operate. No diffs, no review, no type errors to catch mistakes, and nobody sensible points an autonomous tool at a production database. Fully migrated sites keep content as markdown in the same repository, where an agent can draft a new page or fix a stale price and you review it like any other change. Headless gets you AI-assisted code but not AI-assisted content, and that gap is a real, recurring cost of stopping halfway. We'd count it as a genuine argument for going the whole way, not a dealbreaker for headless.

Our verdict

For an editorial team with entrenched workflows, headless WordPress is a defensible place to stand for a few years: readers get the fast site now, editors keep their tools, and the eventual CMS decision gets deferred rather than forced. For everyone else, it's paying to maintain two systems in order to avoid a one-off content export. Almost every headless build we've scoped for a small business turned out to be a full migration wearing a compromise costume, and the numbers WordPress keeps putting up on market share (40.7% of the web) don't change what's right for one site with one team.

If you're weighing it against a clean break, the migration hub post walks the whole decision, the Next.js path covers the framework most headless builds use anyway, and the migration checklist applies to headless cutover too, because your URLs are changing renderer even when the CMS stays.

We do both jobs: headless builds where the editorial case is real, and full migrations with content import, redirect map and Cloudflare hosting where it isn't. If you're not sure which side of the line you're on, start a project and we'll tell you honestly, or get a free audit of what the current site is actually costing you first.