Short answer: going headless is worth it when your WordPress site is slow and that costs you money, when page builders make every change painful, or when the same content has to reach an app or another channel. It is not worth it for a simple site that already works, or when nobody on your side can look after a JavaScript app.

“Should we go headless?” is a common question for teams on WordPress. The honest answer is “sometimes”. This guide gives you a simple way to decide, explains what happens to your plugins, and lists the parts of a migration that people forget to plan for.

What is headless WordPress?

Headless WordPress means WordPress only stores and edits your content, and a separate app shows it to visitors. Your editors log into the same admin as before. The website people see is built with a modern framework such as Next.js and gets the content through an API.

A normal WordPress site does two jobs at once: it stores your content and it builds every page through a theme and plugins. Headless splits those jobs. WordPress keeps the first one. The second moves to a fast front end that usually serves ready made pages from a CDN.

One system, or two

Headless does not replace WordPress. It takes WordPress out of the request path.

Traditional WordPress

One system stores, renders and serves.

1. VisitorEvery request goes straight to WordPress.
2. WordPressTheme, plugins and PHP rebuild the page on every request.
3. MySQLQueried for every page view.

Every page is built on request. Caching plugins patch it.

Headless WordPress

Editing and delivery become separate systems.

1. VisitorAsks the edge, not WordPress.
2. Edge CDNPre-rendered HTML. Most requests stop here, with no database in the path.
3. Next.js with ISRBuilds pages once and rebuilds them when content changes.
4. WordPressAdmin, editors and media. Sends content out over REST or GraphQL, with no public front end.
5. MySQLOnly WordPress talks to it.

Pages are built once and served from the edge.

Same admin, same editors, same content. What changes is who answers the visitor, and how much of your setup is exposed to them.

The content comes out through the WordPress REST API, which is built in, or through WPGraphQL if you prefer GraphQL. The front end can rebuild a page in the background a few seconds after an editor saves it, using incremental static regeneration, so pages stay fast and still update quickly.

When is headless WordPress worth it?

Headless pays off when at least one of these is true and actually costs you something today.

Your site is slow, and slow costs you money

If the website brings in leads or sales and Google’s Core Web Vitals are in the red, a headless front end is usually the biggest single fix available. Google calls a page good when the main content shows within 2.5 seconds, the page reacts to taps within 200 milliseconds and the layout does not jump around (source: web.dev). Pre-built pages from a CDN, proper image handling and no theme or plugin overhead make those numbers much easier to hit.

Fast pages also matter for AI assistants. They read pages with a time limit and often without running JavaScript, so server rendered HTML gets read in full. More on that in our guide to getting cited by ChatGPT, Perplexity and Google AI Overviews.

You have outgrown the page builder

When every page is a one-off Elementor or WPBakery layout, nobody can change the site consistently. A simple question like “what happens if we change the button style?” means opening dozens of pages. Headless pushes you to a clear content model with proper fields and a design system on the front end. After that, a redesign stops being a rebuild.

Security and updates keep eating your time

When WordPress only serves an API and not public pages, there is far less for attackers to reach. The admin can sit behind a VPN or an IP allowlist. Plugin updates stop breaking the front end, because the front end does not use those plugins.

The same content has to go to more than one place

Website, mobile app, partner feeds, help inside your product, an internal AI assistant: a structured content API makes all of these easy, a theme makes them painful. If a mobile app is on your roadmap, the content model you build now pays for itself later.

Your team already works in React

Headless fits a team that knows React and TypeScript much better than a team that only knows WordPress. This is not a technical detail. It decides whether the site is still easy to look after in two years.

When is headless WordPress not worth it?

Four questions settle most cases. One “keep the theme” answer is enough to stop.

Should you go headless? Four questions

Any single “keep the theme” answer ends the conversation.

1. 1Is this site a revenue channel where speed, scale or content velocity is measurably costing you money today?

   Yes go to question 2

   NoKeep the theme.A fast, lightweight theme on good hosting is enough. Put the budget into content instead.

2. 2Does the front end depend on plugins to work: WooCommerce extensions, membership, an LMS, a page builder?

   No go to question 3

   YesProbably keep the theme.Every front-end plugin has to be rebuilt. It costs much more, or you replatform properly.

3. 3Will someone own a JavaScript application after launch, in-house or on a retainer you actually pay for?

   Yes go to question 4

   NoKeep the theme.A headless site nobody maintains decays faster than a WordPress one does.

4. 4Does the same content need to reach an app, a partner or an AI assistant as structured data, not just a web page?

   NoGo headless on speed aloneif it beats what a theme rebuild and better hosting would buy you.

   YesGo headless.The structured content model pays for itself twice.

Then start with the audit, not the build. An audit turns the estimate into a real number before anyone commits to it.

• A simple site with a blog and no speed problem. A light, well built theme on good hosting is fast enough. Headless adds cost without adding anything a visitor would notice.
• Lots of plugins that show things on the page. Every one of them has to be rebuilt in the new front end. This is what blows up budgets. See the table below.
• Nobody to look after the code. A headless site needs someone who can maintain a JavaScript app. Its dependencies change faster than WordPress plugins, so a neglected one ages badly.
• Editors who build pages by dragging blocks around every day. Headless can support this with custom blocks and live preview, but it is real work. If free layout is how your marketing team works, be sure the trade is worth it.

What happens to your plugins?

Plugins that shape content keep working. Plugins that draw something on the page do not, and their features have to be rebuilt in the front end. Count your front-end plugins before anyone gives you a price: that number decides the size of the project more than anything else.

Plugin type	What happens to it	Rebuild effort
Custom fields (ACF)	Keeps working. It becomes your content model.	None
SEO (Yoast, Rank Math)	Titles and descriptions come through the API. The front end prints them.	Low
Caching and speed plugins	Removed. The CDN does this job.	None, you save licences
Contact forms	Rebuilt as front-end forms with your own spam protection.	Low to medium
Sliders, galleries, page builders	Rebuilt once as reusable components.	Medium
Membership and paywalls	Login and access rules rebuilt in the front end.	High
Online courses (LMS)	Usually a separate product to rebuild.	Very high
WooCommerce with extensions	Every extension is its own rebuild.	Very high, often not worth it

WooCommerce deserves a warning. Headless WooCommerce works, but subscriptions, bookings, shipping rules, tax and loyalty extensions each need their own rebuild against an API that was not made for them. For a store with many extensions, the better options are usually “keep the theme and make it fast” or “move to a platform built for commerce”.

What does a headless migration involve?

A migration has six phases. They overlap instead of waiting for each other, which keeps the project short.

What ten weeks actually looks like

A content site with a handful of templates and no e-commerce. Phases overlap; nothing waits for a sign-off ceremony.

1. W1
2. W2
3. W3
4. W4
5. W5
6. W6
7. W7
8. W8
9. W9
10. W10

1. Audit and inventoryA few days in week 1

2. Content modelInto week 3

3. Front-end buildWeeks 2 to 7

4. Editor experienceWeeks 5 to 8

5. SEO parity and redirectsWeeks 6 to 9

6. Launch and monitorThe last weeks

Editor experience is the phase most often cut to save money. It is the main reason editors end up disliking headless.

1. Audit. List every content type, plugin, form, integration and redirect. Mark each one as “moves easily”, “needs rethinking” or “drop”. This is where the real price comes from.
2. Content model. Turn content into clear fields instead of HTML blobs. Get this wrong and every later phase pays for it.
3. Front end. Build the Next.js site and its design system, connected to the WordPress API.
4. Editor experience. Preview, custom blocks, field rules and help text, so editing still feels easy.
5. SEO. Keep URLs where you can, redirect the rest, move titles, descriptions, sitemaps and structured data.
6. Launch. Switch over in steps, watch speed and errors, and have a tested way back.

The phase that gets cut: editor experience

Preview and good editing tools are invisible to whoever signs the budget and obvious to everyone who edits the site every day. That is why they get cut first, and why editors end up disliking headless. If a proposal does not list preview, blocks and field rules as real work with real days, ask why.

The phase that fails in public: SEO

Redirects and URL decisions are not a launch week task. They start on day one, because the content model decides which URLs you can keep. Google explains how to move a site without losing traffic in its guide to site moves with URL changes. Follow it and rankings hold. Skip it and you can lose a year of search traffic in a week.

What decides the cost?

Three things decide the price of a headless migration far more than the number of pages:

• Front-end plugins. Each one that draws something on the page is a rebuild. A few is a migration. Dozens is a new platform.
• Templates. How many different page layouts the site really has.
• Editor needs. Simple fields are quick. Rich page building with live preview takes much longer.

Running costs are a bit higher, because you host WordPress and a front end. For most content sites the difference is small and is partly offset by the caching and security plugins you no longer pay for. The cost people forget is the second year: a Next.js app needs updates. Plan a little time every month, or a small support plan.

A sensible first step is a short audit. It gives you a real number before you commit, and you can stop there if headless is not right for you.

Keep reading

• How to get your website cited by ChatGPT, Perplexity and Google AI Overviews: why fast, server rendered pages get read and slow ones get skipped.
• The six-week MVP: how AI changes the design process: what got faster in building products, and what did not.

Not sure which side you are on? Our headless WordPress migration service starts with exactly this check. Send us your site if you want a second opinion.