What Is Headless WordPress, and Do You Need It?

Your developer has mentioned headless WordPress, and you’re not sure if it’s a smart upgrade or an expensive extra. It’s a fair thing to question.

This post explains what it is in plain English, who it suits, and what you give up.

What is headless WordPress?

A standard WordPress site does two jobs in one place. It stores your content, and it builds each page every time someone visits.

A headless setup splits those jobs apart. WordPress stays where your team logs in to edit pages, add posts and upload photos. A separate front end, which is the part visitors actually see, delivers the website. The “head” is the front end, and WordPress keeps working without it. Developers sometimes call WordPress used this way a headless CMS, which just means a content management system with no website attached.

For our headless builds, the front end is made with Astro. When you publish a change in WordPress, Astro rebuilds the pages in advance and saves them as simple, ready-made files. When a visitor arrives, nothing needs to be assembled. They get the finished page straight away.

Your editors still use the WordPress screens they already know. The only changes they’ll notice are one extra sign-in step with two-factor authentication, and that a published edit takes a minute or two to appear. Saving a draft never touches the live site, and the Preview button opens the draft on a dedicated preview page, so editors can check changes before publishing. Only publishing or updating live content starts a rebuild, and several quick edits made close together are combined into one.

This website runs on a headless setup. So does adrianhewitt.com, and we’re building a new site for a land management organisation the same way. Pre-built pages also help with Core Web Vitals, Google’s measures of how quickly a page loads and how stable it feels.

Is headless WordPress right for your business?

It suits a business that cares most about speed and security, changes its content daily or weekly rather than minute by minute, and has a developer on hand for the long term.

It also suits sites with a very specific design. A custom front end can follow a design exactly, without the limits of a theme.

There’s a resilience benefit too. Visitors never touch WordPress, so if the editing side has a problem, your public pages keep working as normal.

It’s a poor fit if you need edits to appear instantly, or if your site depends on lots of plugins that change the live page. Page builders, membership tools and booking systems are common examples. A complex online store is another case where regular WordPress is usually the better choice.

If you’re weighing this against a fully static site with no WordPress at all, our guide to WordPress vs a static site generator covers that comparison.

What are the downsides of headless WordPress?

Here’s the honest list.

Changes aren’t instant. After you publish, the site rebuilds. That takes a minute or two. For most businesses that’s fine, but it’s not the same as a live edit.

There are more moving parts. You have WordPress, a front end and a build process connecting them. That costs more to set up and look after than a standard site.

Some plugins need extra work. Plugins that change the live page don’t work out of the box here. Features like forms, search and previews have to be custom-built into the front end. It’s very doable, and it’s what we do on every build, but it’s real work, and it’s worth asking about up front.

Editing depends on the WordPress side. If WordPress has a problem, visitors carry on as normal, but nobody can edit or publish until it’s fixed. A fault with the hosting server itself is a bigger issue, so it’s worth asking how quickly your developer can recover from one.

How do you keep a headless WordPress site secure?

This is where headless can help, as long as it’s done properly.

WordPress is still there, and it still runs on PHP. A headless site isn’t immune to problems, so it still needs regular patching. We updated every site we host the morning the PHP2Shell flaws were announced.

What headless adds is distance. On our builds, the editing side of WordPress isn’t open to the public internet. Anyone trying to reach it hits a separate login with two-factor authentication first, so bots never get near the WordPress login page. Visitors see only the finished pages and your media files.

Behind that, there are encrypted nightly backups stored offsite, regular test restores, and monitoring that alerts us when something changes. WordPress also has a REST API, which is how the front end reads your content. We keep access to it tightly limited.

Five questions to ask before saying yes to headless

Use these with any developer who suggests it:

1. How quickly do my edits need to appear, and is a one to two minute delay acceptable?
2. Which plugins or features does my site rely on, and how will each one work in a headless build?
3. Who patches and hosts the WordPress side, and how fast do they act on a serious security flaw?
4. What happens if the server has a problem, for visitors and for my editors?
5. What will it cost to run and maintain each year, compared with a standard WordPress site?

A good developer will answer all five without hesitating. If you get vague answers, that tells you something too.