Headless WordPress: what you gain, what you lose, and who should switch

Headless WordPress keeps WordPress as your editing interface and content database, but hands the front end to a separate application — usually built with Next.js or Astro — that pulls content through the REST API or WPGraphQL. You gain genuine front-end freedom and, done well, a noticeably faster site; you give up live previews, most of what plugins do on the front end, and a great deal of operational simplicity. For most content-led marketing sites the trade is not worth it; for sites where the front end is the product, it often is.

What does headless WordPress actually mean?

A standard WordPress site is monolithic: the same PHP application stores your content, runs your plugins, and renders the HTML a visitor sees. Headless splits that in two. WordPress stays on as the content management layer — editors keep the admin, the block editor, media library, users and roles — but its theme layer goes quiet. A separate front-end application, typically Next.js or Astro, requests content over an API and builds the pages itself.

Two APIs make this possible. The REST API ships with WordPress core and exposes posts, pages, media and custom content as JSON endpoints. WPGraphQL is a widely used plugin that exposes the same content through a single GraphQL endpoint, letting the front end ask for exactly the fields it needs in one request. Either way, the visitor never touches WordPress directly; they see pages served by the JavaScript application, often pre-rendered and pushed to a CDN.

The word "headless" describes the CMS, not the site. Your site very much has a head — it is just a different codebase, deployed separately, usually on different hosting, and built by developers rather than assembled from a theme.

What do you gain by going headless?

The honest gains fall into three groups.

Front-end freedom

You are no longer designing inside a theme's assumptions. Component libraries, design systems, complex interactivity, app-like navigation, animation frameworks: all of it becomes ordinary front-end work instead of a fight with template hierarchy and enqueued scripts. If your site needs to behave like a product — a configurator, a member dashboard, a search experience with instant filtering — a dedicated front end is simply the right tool. That is the same reason teams reach for web application development in the first place.

Performance ceilings

A monolithic WordPress site can be fast, but its ceiling is set by PHP rendering, plugin weight and hosting. A headless front end can pre-render pages at build time, serve them as static files from edge locations, and hydrate only the interactive parts. Astro in particular ships almost no JavaScript by default. The result, when the build is disciplined, is consistently strong Core Web Vitals without the cache-plugin whack-a-mole that monolithic WordPress performance work tends to become.

Security and stability on the public site

When visitors only ever touch static or server-rendered pages from the front-end host, the WordPress installation can sit behind authentication, on a separate domain, patched on its own schedule. The public site keeps working even while WordPress is being updated. That separation shrinks the attack surface that makes unmaintained WordPress sites such a common target.

There is a quieter gain too: the same WordPress content can feed a website, a mobile app and other channels from one editorial workflow, which matters for organisations publishing in more than one place.

What do you lose, honestly?

This is the part sales pages skip, and it is where most regretted headless projects go wrong.

Previews and the editing experience. Out of the box, "Preview" stops working: WordPress no longer renders the page, so it has nothing to show. Draft previews, scheduled-post previews and any theme-level editing tools all need to be rebuilt against the new front end. It is solvable — preview routes, draft tokens, on-demand rendering — but it is real engineering, and until it is done your editors are publishing blind.

Plugins that touch the front end. SEO plugins that print meta tags, form builders that render forms, page builders, membership gates, e-commerce templates, related-posts widgets: anything that outputs HTML on the public site no longer reaches it. Some plugins expose their data over the API so the front end can re-implement the output; many do not. Every one of them becomes a line item in the build.

Simplicity. One system becomes two codebases, two deployments, two hosting bills and two failure modes, joined by an API contract someone has to maintain. Content model changes now need coordinated releases. A site an office administrator could manage end to end now needs a developer in the loop for anything structural. None of this is exotic for a software team; all of it is new overhead for a marketing team.

Headless does not remove complexity from a WordPress site. It moves the complexity out of the theme and into your architecture, where only developers can reach it.

Effort. The shape is predictable even with no numbers attached: a headless build asks for more engineering up front than a theme build of the same design, and its ongoing maintenance assumes developer time rather than plugin updates.

REST API or WPGraphQL: which should feed the front end?

The core REST API is the zero-dependency choice. It is stable, well documented and fine for straightforward models: posts, pages, a few custom post types. Its weaknesses show as the model grows — fetching a page with its author, featured image, categories and related items can take several round trips, and you receive whole objects when you wanted three fields.

WPGraphQL answers both problems. The front end describes the exact shape of data it wants — nested relationships included — and gets it in a single request. It pairs naturally with typed front ends, integrates with Advanced Custom Fields through a companion extension, and its tooling for Next.js front ends is well established. The costs are an extra plugin to maintain, a schema to think about, and query-complexity controls to configure so an expensive query cannot hurt the server.

Our rule of thumb: simple content model and a small site, use REST and keep the dependency count down; anything with rich relationships, custom fields or multiple content types, start with WPGraphQL. Retrofitting it later means reworking queries across the whole front end, so it is easier to start with it.

How do the approaches compare?

The framework choice inside headless matters less than the decision to go headless at all, but it is not cosmetic. Next.js suits sites that are partly application: authenticated areas, personalisation, heavy interactivity. Astro suits sites that are mostly content and want the speed without shipping a framework to every visitor. Both are current, well maintained choices at the time of writing.

Who should go headless, and who should not?

Headless earns its keep when at least one of these is true: the front end is genuinely application-like; the same content feeds several channels; performance targets are strict and the design is too custom for theme-level optimisation; or security policy requires the CMS to be isolated from the public internet. Publishers with large editorial teams and product companies using WordPress purely as a content source both fit.

Stay monolithic when your site is pages, posts, landing pages and forms; when non-developers manage it day to day; when your budget assumes plugin functionality rather than custom builds; or when nobody on the team will own a JavaScript codebase after launch. A well-built classic theme on good hosting remains an excellent choice, and modern WordPress full-site editing has narrowed the design gap. If the honest driver is "our site is slow," audit the current build first — hosting, images and plugin weight are cheaper fixes than an architecture change. Our notes on CMS platforms cover how we weigh these choices across systems, not just WordPress.

A middle path exists as well: keep WordPress monolithic but build the few app-like sections — a calculator, a portal, a booking flow — as embedded components. Many teams get most of the benefit for a fraction of the upheaval.

How OlDevs approaches headless builds

OlDevs has been building on WordPress and on modern JavaScript stacks since 2014, from our studio in Vancouver, meeting clients by video call in their own time zone. We treat headless as an engineering decision, not a fashion: we will tell you plainly when a well-tuned monolithic build serves you better, and when it does not we design the whole system — content model, WPGraphQL schema, front end, previews and editor workflow — as one piece, so your team is not publishing blind after launch. You see a working demo every week, the finished site meets WCAG 2.2 AA, and you own all of the code, designs and accounts outright.

If you are weighing headless WordPress against a rebuild, a refresh or something in between, our web development team can map the options against your content, your editors and your roadmap. Request a quote and we will reply within one business day.