We Still Love WordPress. Here's Why We Stopped Shipping Its Frontend.

We've been running WordPress sites for the better part of 13 years. It's still, hands down, the best content editor a non-technical client can use. Block editor, media library, revision history, scheduled posts - a marketing team can pick it up in an afternoon and never need to ask a developer how to publish a page.

That's not the part that's getting old.

The part that's getting old is everything WordPress does after you hit publish. A PHP request hits the server, loads a theme, loads a dozen plugins, queries the database a few dozen times, and assembles a page from scratch - on every single visit, for every single visitor, unless a caching plugin is doing the job a proper frontend should be doing anyway. Add a page builder, an SEO plugin, a form plugin, a security plugin, an image optimiser, and a slider plugin nobody remembers installing, and you've got a site that needs updating every week just to stay patched, and still loads slower than it should.

The actual problem isn't WordPress

It's the coupling. WordPress bundles two very different jobs into one system: the admin, where content gets written and managed, and the frontend, where that content gets rendered for a visitor. The admin side has had a decade of real investment and it shows. The frontend side is still, on most sites, a theme built on inherited PHP templates, held together by plugins that each want their own JavaScript, their own CSS, their own database calls.

Every plugin update is a gamble. Every theme update risks breaking a customisation someone made three years ago. Every unpatched plugin is a door left open. None of that is a WordPress problem exactly - it's a consequence of asking one system to be both a CMS and a web server, rendering everything live, every time.

What we build instead

Headless WordPress splits the two jobs apart. WordPress keeps doing what it's good at: content, media, users, the block editor your team already knows. It stops being the thing a visitor's browser talks to directly.

In front of it sits a separate JS frontend - built by us, deployed independently, pulling content from WordPress through its REST or GraphQL API and rendering it as fast, static or server-rendered pages. The visitor never touches PHP, a theme, or a plugin stack. They get plain HTML and JS, served from a CDN edge, most of the time before their browser has even finished the handshake.

What that changes in practice:

• The client keeps the same editor. Same login, same dashboard, same block editor, same media library. Nothing changes about how content gets written or published.
• The frontend has nothing to hack. No PHP running on the page a visitor loads, no plugin vulnerabilities exposed to the public internet, no exploitable admin panel sitting on the same domain as your traffic.
• Page speed stops depending on plugin count. A visitor-facing page is pre-built or rendered once and cached at the edge, not assembled from scratch on every request - the kind of technical SEO fix that used to take a full plugin audit now comes for free.
• Nothing breaks on update day. WordPress core and its plugins can update on their own schedule without ever touching what a visitor sees, because the visitor-facing code lives somewhere else entirely.
• The frontend can be whatever fits the job. Astro for a marketing site, Next.js for something more interactive - the choice isn't locked to what a WordPress theme can do.

So what happens to all the plugins?

They don't disappear. A typical WordPress install carries two or three dozen of them - an SEO plugin, a form plugin, a security plugin, a page builder, an image optimiser, a caching plugin trying to paper over everything else. None of that is a mistake on its own. Plugins are one of the best things about WordPress. But every one of them can add its own database queries, its own script, its own opinion about how a page should render, and all of it runs again on every single request.

Going headless doesn't mean ripping the plugins out. It means a visitor no longer needs your entire plugin stack to load just to read a blog post. WordPress still runs whatever the content team actually uses day to day. The page a visitor loads doesn't pass through any of it, because that page isn't being assembled by WordPress at all. If your install has 40 plugins, nobody reading an article needs to touch all 40 of them.

Does headless make a site more secure?

Not automatically, and we won't pretend otherwise. There are still APIs, still servers, still dependencies, and a badly configured headless setup can be just as exposed as a badly configured WordPress theme.

What changes is what a visitor can actually reach. On a normal WordPress install, the same system managing your content is also the system serving every public page, with wp-login.php, wp-admin, and every plugin's public-facing code sitting on the same domain as your traffic. In a headless setup, WordPress can sit behind the API entirely, with nothing but content requests ever reaching it. That's a different security model, not a guarantee - it still needs the same discipline: WordPress and its plugins kept patched, the admin locked down, and the API layer treated as something that needs securing too, not something that's automatically safe because it isn't a "website" in the traditional sense.

Does headless make SEO better?

Only if someone actually does the work. A well-built headless site can be faster and cleaner for search engines to crawl. A badly built one can quietly break indexing altogether, because none of it happens automatically the way a mainstream WordPress SEO plugin handles it out of the box.

Whatever sits on the frontend, someone still has to get canonical tags, XML sitemaps, structured data, redirects from old URLs, correct status codes, and actual renderable HTML right, rather than leaving content to appear only after JavaScript runs. That has to be part of the build from day one, not bolted on after launch. It's the same groundwork behind Google's stricter JSON-LD parsing and how long canonical re-evaluation actually takes - the discipline doesn't change just because the frontend is a JS framework instead of a WordPress theme.

What doesn't change, and what we won't claim

Headless isn't free. It's a second codebase, and it means whoever built the frontend needs to be involved when a new content type or page layout is needed - a client can't drop in a new page template themselves the way they could with a page builder. It's a real trade-off, not a hidden catch. For a five-page brochure site with no real traffic, plain managed WordPress hosting with a couple of well-chosen plugins is honestly fine, and we'll tell a client that rather than sell them a rebuild they don't need.

Where it earns its cost is anywhere content velocity, traffic, or security actually matter: publishers, e-commerce catalogues, multi-location businesses, anything getting real search traffic that a slow page or a compromised plugin would actually cost money. The question was never "is headless better than WordPress" in the abstract. It's whether this particular site, with its particular traffic and team, needs the trade-off at all.