Headless WordPress, explained for business owners

Headless WordPress means WordPress keeps doing the part you work in, where you write, edit and publish, while a separate, faster system builds the pages your visitors actually see. You keep the editor you know; your visitors never touch WordPress at all.

Most of what is written about headless WordPress is written for developers choosing a framework. This guide is for the person paying for the website: what changes, what it costs, what you give up, and how to tell whether your business needs it. I build and look after headless WordPress sites, so where I can, I use real numbers from one of them instead of promises.

What is headless WordPress?

Every website has two jobs. One is managing the content: storing the text, images and pages, and giving you a screen to edit them. The other is presenting it: turning that content into the pages a visitor loads. Developers call the presenting part the "head," because it is the part people face.

On a normal WordPress site, WordPress does both jobs. Every time someone visits, WordPress, its theme and its plugins work together to assemble the page. A "headless" site cuts the head off: WordPress keeps the content and the editing screen, and a separate front end takes over the presenting.

You will also see it called decoupled WordPress. Same idea. One thing it is not: leaving WordPress for a different "headless CMS" such as Contentful or Sanity. That is a migration to new software. Headless WordPress keeps WordPress and changes only how the public site is made.

Is WordPress a headless CMS?

Not by default, but it can be one without adding anything. WordPress has shipped with a REST API, a built-in way for other software to read its content, since version 4.7 in December 2016 (REST API handbook (opens in a new tab)). That is the door a headless front end uses. Some developers add WPGraphQL (opens in a new tab), a free, actively maintained plugin that offers a second door with a different query language. Either works. On the sites I build, the REST API that ships with WordPress is enough, so there is one less plugin to keep updated.

How does a headless WordPress site work?

From the editor's chair, almost nothing changes. Here is what happens behind it on a typical build, including the one I describe in the next section:

1. You publish in WordPress, the way you always have.
2. WordPress tells the front end that something changed, usually by calling a private address (a "deploy hook") that starts a build.
3. The front end reads your content through the REST API and turns every post and page into finished HTML files.
4. The finished files go to a hosting network with servers around the world, such as Cloudflare Pages.
5. Visitors get those ready-made files. Nothing is assembled while they wait, and WordPress does not handle the visit.

That is the most common setup, called a static or pre-built site. There are two other ways a front end can get your content, and the difference matters more than most guides admit:

• Built ahead of time (static): the fastest and simplest. The cost is a short delay between Publish and live.
• Built on each request (server rendering): pages are made fresh when someone asks for them. No delay after publishing, but a server, or serverless functions, has to answer every visit.
• Built in the visitor's browser (client-side rendering): the page arrives nearly empty and JavaScript fills it in. This is the one to avoid for a business site, for reasons I cover in the SEO section below.

What do you gain by going headless?

Speed

A pre-built page is just a file. No database is queried, no plugins run, and the file is served from a location near the visitor. That is where the speed comes from, and it is the gain I can put the clearest numbers on. It is not automatic, though: a heavy front end can be as slow as the site it replaced, and the neutral data only says that classic WordPress sites often struggle. In the HTTP Archive's 2025 Web Almanac, about 45% of WordPress sites passed Google's Core Web Vitals on mobile, against 74% of Wix sites (Web Almanac 2025, CMS chapter (opens in a new tab)).

On one client's site I rebuilt this way, a video library with 571 posts, each post on the old WordPress site made about a hundred requests and loaded about 2 MB before anyone pressed play on the video. Those posts now come from the same WordPress, through a new front end built with Astro and hosted on Cloudflare. A post page now loads about 0.6 MB, roughly 70% less, and a new post goes from Publish to live in about six minutes.

One caveat on those numbers: they come from one site I built and measured myself, not from a neutral benchmark. Part of that saving came from decisions any site could make, like loading a lightweight preview instead of a full YouTube player on every post. Going headless did not do all of it. What it did was remove the page builder, the theme and the plugin stack from every visit, which is the part a classic site cannot shed.

Security

On a classic site, every visitor's request runs through WordPress, its theme and every plugin. That is a lot of code facing the internet, and plugins are where almost all of WordPress's known weaknesses are: security firm Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025. 91% were in plugins and 9% in themes; only 6 were in WordPress itself, all low priority (State of WordPress Security in 2026 (opens in a new tab)).

On a headless site, the public pages are plain files, with far less to break into. Anything that still takes input, like a contact form, needs protecting as it always did. WordPress lives at its own address, which can be locked down so that only you and the build can reach it. This shrinks what an attacker can reach; it does not make WordPress safe to ignore. The dashboard, the plugins and the logins still need updates and care. They are just no longer on the front line.

The site stays up when WordPress doesn't

Because the public site is a set of finished files, it keeps working if WordPress is down, being updated or being restored from a backup. A bad plugin update on a classic site takes the whole site with it. On a headless site, the worst case is that you cannot publish for a while.

One source of content, more places to use it

The same content can feed the website, an app, an email newsletter or a kiosk, because it is available through the API rather than locked into a theme. Most small businesses will not need this. The ones that do tend to need it badly.

What do you give up?

This is where most guides go quiet, and it is the part that decides whether headless is right for you.

Plugins that change what visitors see stop working on their own. A plugin that works inside WordPress, like a backup tool or a user manager, carries on as usual. A plugin that draws something on the public pages does not, because WordPress no longer draws the public pages. That includes:

• Page builders like Elementor, Divi and Bricks. Their layouts live in WordPress's front end, which is gone. If you build your own pages by dragging blocks around, headless takes that away.
• Form plugins. Forms have to be rebuilt in the front end, sending to WordPress or to a form or email service.
• SEO plugins. Yoast and Rank Math still help you write titles and descriptions, and both can hand them to a headless front end (in Rank Math's case, once you switch that on), but the front end has to be built to print them into each page. Redirects, sitemaps and structured data become the front end's job.
• Online stores. WooCommerce can run headless, but the cart, checkout and account pages are the hardest part of any headless build. For a small store, it is rarely worth it.
• Anything "drop-in": sliders, popups, chat widgets and cookie banners installed from the plugin directory. Each becomes a small development task instead of a setting.

Publishing is not instant. On a pre-built site, your change goes live when the rebuild finishes, and the rebuild takes longer the more content there is: under a minute on many small sites, several minutes on one with hundreds of posts. For most businesses that is fine. For a newsroom, it is not.

Previews take work. WordPress's Preview button shows a draft through WordPress's own front end, which a headless site no longer uses. A good build adds a preview that shows drafts in the new design, using tools made for it, such as Next.js's Draft Mode or WP Engine's free HWP Previews (opens in a new tab) plugin; a cheap one leaves you publishing to see how something looks.

You now have two systems. Two things to host, two things to keep updated, and a front end that only a developer can change. That last point is the real cost: small layout changes you could once make yourself now go through whoever built the front end.

Things can fail quietly. A build can finish without a single error and still publish an incomplete site: if a firewall or a login blocks the build from reading WordPress, a careless build treats "blocked" as "nothing to show" and publishes the pages it has. A good build stops and fails when it finds no posts, so a broken build never replaces a working site. Every headless site needs checks like that, because nobody is looking at the pages when they are made.

Is headless WordPress good for SEO and AI search?

It can be better than classic WordPress, or much worse. The difference is how the pages are built.

A pre-built or server-rendered front end hands search engines complete HTML: the text, headings and links are all there in the first response. That is ideal, and on a fast host it helps with Google's page-experience signals too.

A front end that builds pages in the visitor's browser hands them a nearly empty page and a bundle of JavaScript. Google can run JavaScript, but it does it in a second pass that can lag behind. Many AI crawlers, including OpenAI's and Anthropic's, do not run JavaScript at all (Vercel's crawler study (opens in a new tab)), so to ChatGPT and Claude a page like that is close to blank. If you care about showing up in AI answers, which I cover in my guide to answer engine optimization, this is the setting that matters most.

Three more SEO jobs move from plugins to the front end, and each should be on your builder's checklist:

• Every old address has to redirect to its new home. On the site above, every old post address was carried over, and the build checks the redirects against Cloudflare's limits every time it runs.
• Titles, descriptions and structured data have to be read from WordPress and written into each page.
• The sitemap and robots file have to be generated by the front end.

None of this is hard. All of it is easy to forget, and a missing redirect map is one of the surest ways for a redesign to lose its search traffic.

What does headless WordPress cost?

It costs more to build than a comparable classic WordPress site, because you are paying for two things: the WordPress setup and a custom front end. There is no theme to start from, so a headless site is almost always a custom build, and it starts where custom builds start. In my guide to what a website costs, that is about $10,000 and up for a custom site from a studio or agency, against roughly $500 to $5,000 for a freelancer working from a template. A site moving hundreds of posts, with previews, custom forms and search, sits well above the bottom of that range.

Running it can cost about the same as classic WordPress, because the new half is often cheap or free to host.

The larger ongoing cost is change. Because the front end is custom code, new page layouts and features are development work. If your site changes shape often, budget for that, or keep it classic.

When is headless WordPress worth it?

Headless is usually worth it when most of these are true:

• You have a lot of content, and people come to read it: hundreds of posts, videos or resources, where speed and a stable site pay off on every visit.
• You want to keep WordPress because your team knows it, or because years of content already live there.
• Security matters more than average: a public figure, a medical practice, anyone who attracts more attackers than a typical small business.
• The design is settled. You add content often but change layouts rarely.
• You have someone to call. A developer or care plan that looks after both halves.

It is usually not worth it when:

• You build and rearrange pages yourself with a page builder and like doing it.
• The site is a store that depends on WooCommerce and its extensions.
• The site is small and rarely changes. A fast classic WordPress site, or a simple site without WordPress, will cost less and do the job.
• Nobody will look after the front end after launch.

A quick test: if your biggest website frustration is speed, security or a sprawling pile of plugins on a site full of content, headless is worth a conversation. If it is that you cannot change pages yourself, headless will make that worse.

Is there a middle ground?

Yes, and for many sites it is the better first step:

• Make classic WordPress faster. Good hosting, page caching, a content delivery network, fewer plugins and a lightweight theme fix most slow WordPress sites without a rebuild.
• Export a static copy. Plugins like Simply Static (opens in a new tab) turn a classic WordPress site into plain files you can host anywhere. You keep your theme and page builder; you lose anything that needs WordPress to answer live, like built-in search and some forms.
• Go headless in part. Keep WordPress drawing most of the site and build one section, such as a resource library, as a separate fast front end.

How do you move an existing WordPress site to headless?

This is the order I work in, and the order I would ask any builder about:

1. List what draws on the public pages. Every plugin, shortcode and widget visitors see needs a plan: rebuild it, replace it or drop it.
2. Tidy the content. Headless front ends reward structured content, like consistent categories, fields for things like a speaker or an address, and images at sensible sizes. This is the moment to fix it.
3. Build the front end against a copy of your real content, not samples.
4. Map every old address to its new one, and test the redirects before launch.
5. Wire Publish to a rebuild, and add previews if your team needs them.
6. Make failure loud. A build that finds no content should stop, not publish an empty site.
7. Lock WordPress down at its own address, and keep watching the build that turns a post into a page.

Where do AI agents fit?

WordPress is also becoming something AI agents can work in directly. WordPress 6.9, released in December 2025, added an Abilities API: a standard way for WordPress and its plugins to describe what they can do in terms software can read (Abilities API in WordPress 6.9 (opens in a new tab)). The WordPress project's MCP adapter (opens in a new tab), a separately installed plugin that is still early, lets an AI assistant such as Claude use those abilities through the Model Context Protocol. What an assistant can do depends on which abilities your plugins offer and which permissions you give it.

A headless setup suits this well, with one large caveat. Because the public pages are built separately, an agent limited to content cannot break the code that draws them; the worst it can do is a bad edit. That protection ends at the agent's permissions. An agent connected with administrator rights, or through a server that can run code, can change settings, delete users and data, or alter the database itself, and much of that has no undo. Headless does not change that.

I call this agentic WordPress, and it is what the rest of this series covers.

The short version

Headless WordPress keeps the editor you know and replaces the part that is slow, fragile and exposed. It pays off for content-heavy sites that care about speed and security and have someone to look after the front end. It costs you page builders, drop-in plugins and a little publishing speed, and it is the wrong choice if you like building pages yourself. If you are unsure, ask the builder two questions: how are the pages rendered, and what happens when a build fails? The answers tell you most of what you need to know.