Headless WordPress Explained: When It Makes Sense

Headless WordPress means using WordPress only as the place where content is written and stored, and building the public website as a separate application that fetches that content through an API. The WordPress admin stays; the WordPress theme goes. The front end is usually built with a JavaScript framework such as Next.js, and reads content from the REST API that has been part of WordPress core since version 4.7, or from a GraphQL API added by the WPGraphQL plugin.

It is a genuinely useful architecture in the right situation. It is also sold to businesses that do not need it. This article explains how it works, what it changes and how to tell which side of that line you are on.

How a traditional WordPress site works

On a normal WordPress site, one system does everything. A visitor requests a page, WordPress runs PHP, queries the database, applies the theme's templates and plugins, and returns HTML. Caching stores the result so the next visitor gets it faster.

The strength of that model is that everything is connected. A plugin can add a form, an SEO plugin can write meta tags, an editor can preview a page exactly as it will appear. The weakness is that the theme, the plugins and the database all sit on the critical path for every page view.

How headless WordPress works

In a headless setup there are two systems:

1. WordPress, at an address such as cms.example.co.uk, used by editors. It stores content and exposes it through an API.
2. The front end, at the main domain, built separately. It requests content from WordPress and renders pages, often at build time or on a schedule rather than on every visit.

When an editor publishes, the front end is told to rebuild the affected pages. Visitors never touch WordPress at all.

What you gain

• Performance. Pages can be pre-rendered and served from a CDN, so the response does not wait on PHP or the database.
• Front-end freedom. The front end can be anything: highly interactive interfaces, app-like behaviour, designs that would fight a WordPress theme.
• One content source, several outputs. The same content can feed a website, an app, a kiosk or another site.
• Security posture. The WordPress admin can be locked to known IP addresses or a VPN, because the public never needs to reach it.
• Scaling. Traffic spikes hit the CDN, not the database.

What you give up

This is the half that sales pages leave short.

• Front-end plugins stop working. Forms, sliders, SEO meta output, cookie consent, related posts, schema, anything that prints to the page must be rebuilt or replaced in the front end.
• Preview gets harder. Editors expect to see a draft as it will look. In headless that needs a preview mode built into the front end.
• The block editor's layouts do not transfer automatically. Blocks arrive as HTML or structured data, and the front end has to know how to render each one. Most headless builds restrict editors to a defined set of blocks and fields.
• Two systems to host and maintain. WordPress still needs updates and security. The front end needs its own hosting, dependency updates and deployments.
• Fewer people can work on it. Many WordPress developers do not build headless front ends, and many front-end developers do not know WordPress.
• Cost. Building the front end is a separate development project, often larger than a theme.

Headless vs traditional WordPress at a glance

When headless makes sense

• The front end is an application. Complex interactive features, user dashboards or app-like behaviour that a theme would fight. Website or web application covers how to tell the difference.
• Content feeds more than one channel. A website, a mobile app and a partner site all reading the same content.
• Performance is a competitive requirement. High-traffic publishing or ecommerce where milliseconds matter and the budget exists to maintain two systems.
• A team that already works in a JavaScript framework wants WordPress's editor for content without adopting WordPress for the front end.
• Security policy requires the CMS to be private. Some organisations cannot expose an admin login to the internet.

When it does not

• A service business site of twenty pages, edited by one person.
• A site that depends heavily on front-end plugins, such as page builders, form builders or WooCommerce extensions.
• A budget that covers a good traditional build but not two systems and their maintenance.
• A team that wants to preview and lay out pages visually.

For most business sites, a well-built traditional WordPress site, with a custom or block theme and good hosting, hits every realistic performance target. The comparison between WordPress and a framework such as Next.js as a whole is covered in Next.js vs WordPress for a business website.

What a sensible headless build includes

If headless is right for you, these are the parts to check are in the plan:

1. A content model of custom post types and fields designed for the API, not for a theme. Custom post types and custom fields explains the structure.
2. A defined block set, with a front-end component for each block editors are allowed to use.
3. Preview mode, so editors can see drafts before publishing.
4. Revalidation, so publishing in WordPress updates the live site within seconds or minutes, not at the next full build.
5. SEO output rebuilt in the front end: titles, descriptions, canonicals, sitemaps, structured data and redirects.
6. Forms handled by the front end or a form service, with spam protection and delivery to the right place.
7. Hosting and access for both systems, with the WordPress admin restricted.
8. A maintenance plan that covers both.

What headless costs to run

Headless changes the running costs as well as the build. Instead of one hosting account, you usually have:

• WordPress hosting for the CMS, which can be modest because only editors use it
• front-end hosting, often on a platform built for frameworks such as Next.js, priced by usage
• a CDN, sometimes included in the front-end hosting
• a form or email service, because WordPress form plugins no longer handle submissions
• maintenance for two codebases: WordPress updates on one side, framework and package updates on the other

None of these is individually expensive for a small site. The cost that adds up is developer time, because every change to how content is displayed is a front-end code change rather than a template edit, and every new block editors want needs a matching front-end component. Budget for that ongoing work before deciding, not after.

A middle path

Before committing to headless, consider whether the specific problem can be solved without it. A slow site is usually fixable with better hosting, caching and a lighter theme. A need for app-like features on one section can sometimes be met by a small JavaScript application embedded in an otherwise traditional WordPress site. Going fully headless is the right answer when the requirements genuinely need it, not because it is the newer pattern.

Next step

If you are weighing up headless for a new build, the website development service covers Next.js and headless WordPress, and the WordPress development service covers traditional builds. I will recommend whichever fits. The WordPress website development guide sets out the structural decisions that apply either way.