Headless WordPress: Pros, Cons and When It Is Actually Worth It

Headless WordPress is the most over-sold architecture in the WordPress world right now. The pitch sounds irresistible: keep the WordPress admin your editors know, bolt a modern JavaScript front end on top, and get a faster, more secure, more flexible website. Sometimes that pitch is true. More often – for the small business sites, stores and blogs that make up most of the web – it doubles or triples the cost, breaks the editing experience your team loves, and delivers a speed gain you could have had for a tenth of the price with a well-built custom theme.

I build both. In 12+ years and 500+ WordPress projects I have shipped traditional custom themes, headless builds on Next.js with WPGraphQL, and plenty of middle-ground setups in between, for clients in Germany, the UK, the US and Australia. This guide is the honest version: what headless WordPress actually is, how the architecture differs from a normal site, the genuine advantages, the drawbacks nobody puts in the sales deck (with numbers), the performance myth that drives most bad decisions, a decision framework for who really benefits, the middle-ground options, what a real headless stack looks like, and what a migration costs.

Table of contents

• What headless WordPress actually is
• Headless vs traditional: the architecture, side by side
• The real advantages of headless WordPress
• The real drawbacks – with numbers
• The performance myth: headless is not automatically faster
• Who genuinely benefits – and who does not
• Middle-ground options before you go headless
• What a headless stack looks like in practice
• Migration cost and timeline: realistic ranges
• How to decide: site type to recommendation
• Frequently asked questions

What headless WordPress actually is

A traditional WordPress site does two jobs in one application: it manages content (the admin, the database, media, users) and it renders the pages visitors see (the theme, PHP templates, the front end). Headless WordPress cuts that in half. WordPress keeps the first job – it becomes a content backend, sometimes called a “content API” – and a completely separate application, almost always built in JavaScript, takes over the second job of rendering pages.

The word “headless” just means the head (the theme, the visible front end) has been removed. Editors still log in to wp-admin, still write posts, still upload images. But when a visitor requests a page, WordPress does not render it. Instead, the separate front-end application asks WordPress for the content over an API and builds the page itself.

REST API vs WPGraphQL

There are two common ways the front end talks to WordPress:

• The REST API ships with WordPress core. Every post, page, category and media item is available as JSON at predictable URLs (for example /wp-json/wp/v2/posts). It works out of the box, but fetching a page with its author, featured image and related posts can take several separate requests, and custom fields need extra registration.
• WPGraphQL is a free plugin that exposes the same content through GraphQL. The front end asks for exactly the fields it needs in a single query – title, content, SEO meta, ACF fields, menu items – and gets one tidy response. For any serious headless build I use WPGraphQL, usually with the ACF and SEO extensions; it is the de facto standard, and frameworks like Next.js and Faust.js are built around it.

Either way, the principle is the same one behind every WordPress API integration: WordPress becomes a structured data source, and something else consumes the data.

Headless vs traditional: the architecture, side by side

It helps to see the two shapes clearly, because almost every pro and con follows directly from the diagram.

Traditional WordPress: one stack

One server (or one managed hosting account) runs PHP and MySQL. A request comes in, WordPress loads the theme, PHP builds the HTML, a caching layer usually serves repeat visitors from a stored copy, and a CDN may sit in front. One codebase, one deployment, one thing to host, back up and update. The theme and the plugins can touch everything – which is exactly why plugins “just work”.

Headless WordPress: two stacks

Stack one is WordPress itself – admin, database, media library – hosted anywhere PHP runs, but now often hidden from the public behind authentication or an IP allowlist. Stack two is the front end: a JavaScript application (Next.js, Nuxt, Astro, SvelteKit) hosted on a platform like Vercel, Netlify or Cloudflare, usually served from a global CDN. Between them sits the API – REST or WPGraphQL. Content flows one way: editors write in WordPress, the front end fetches it, builds pages (at build time, on request, or a mix), and serves them to visitors.

Two codebases. Two deployments. Two hosting bills. Two things that can break, and a contract between them (the API and its queries) that must be kept in sync every time a content type changes. None of that is a criticism yet – it is just the shape. Whether the shape pays for itself depends entirely on what the site needs to do.

The real advantages of headless WordPress

Headless is not a scam. When the fit is right, the benefits are real and worth paying for.

Complete front-end freedom

The front end is no longer a WordPress theme, so it is not bound by WordPress’s templating, its jQuery legacy or its rendering pipeline. Teams can build with React or Vue components, animation libraries, design systems shared with a native app, and app-like page transitions that a PHP theme cannot match. For genuinely interactive products – dashboards, configurators, editorial experiences with heavy interactivity – this freedom matters.

One content source, many channels

This is the strongest argument in practice. When WordPress is an API, the same content can feed a website, a native mobile app, a partner site, digital signage, a newsletter pipeline and a voice or chat interface. A publisher managing recipes or product data once and syndicating it everywhere gets real leverage from headless. If your only channel is one website, this advantage is worth exactly nothing to you.

A smaller public attack surface

The public site is static or server-rendered JavaScript with no wp-login, no xmlrpc, no plugin endpoints exposed. WordPress itself can be locked away behind a VPN or allowlist. Automated bot attacks that hammer every WordPress site on earth simply have nothing to hit. This is a genuine security improvement – though a hardened, maintained traditional site closes most of the same doors at far lower cost.

A better fit for JavaScript teams

If a company already employs React developers, giving them a Next.js front end is easier than teaching them PHP theme development. Modern tooling – hot reload, TypeScript, component testing, preview deployments on every pull request – is a real productivity gain for teams who live in that ecosystem. Note the assumption hiding in this paragraph: a company that employs React developers. That assumption is where most headless projects for small businesses go wrong.

The real drawbacks – with numbers

Here is the part the agency pitch deck leaves out. None of these are edge cases; they are the default experience of going headless, and each one costs money or workflow comfort.

It costs 2-3x more to build

A custom WordPress theme for a typical business site might be EUR 1,500-4,000 from a senior freelance developer (I break the ranges down in what a custom WordPress website costs). The same site built headless is realistically EUR 5,000-15,000, and agency quotes for headless routinely start around EUR 20,000. Why: you are building the front end from scratch in a framework, rebuilding things WordPress gave you for free (menus, search, pagination, sitemaps, feeds, 404s, redirects), wiring up the API layer, and setting up two deployment pipelines. Every hour of that is skilled JavaScript work.

Things stop “just working”

• Preview breaks. Click “Preview” in a normal WordPress site and you see your draft. In a headless build, preview has to be engineered: authenticated API requests, draft routes on the front end, token handling. It is solvable (Next.js draft mode, Faust.js) but it is a project task, not a checkbox.
• Most plugins only half-work. A plugin that adds a shortcode, a widget, a form or any front-end output renders nothing on your JavaScript front end. Contact Form 7, sliders, table plugins, membership plugins, most of WooCommerce’s front end – all need re-implementing against their APIs, if they have one.
• Forms become development tasks. Every form needs a front-end component, validation, a submission endpoint and spam protection, built by hand or via a third-party form service with its own monthly fee.
• SEO plugins lose half their job. Yoast or Rank Math still store meta titles, descriptions and schema – but outputting them, generating sitemaps and handling redirects on the front end is now your developer’s job, usually via the plugin’s GraphQL extension plus custom code.

You host and maintain two stacks

WordPress hosting (say EUR 10-30 per month) plus a front-end platform (Vercel or Netlify free tiers are fine for small sites, but production teams typically land on EUR 20+ per month) plus, often, a paid form service, an image service or a search service (Algolia and friends) to replace what WordPress did natively. The bigger cost is people: every WordPress update that touches the API, every ACF field change, every new content type needs coordinated changes on both sides. Ongoing maintenance now requires a JavaScript developer on call, not just a WordPress generalist – and JS framework versions move fast. A Next.js app left alone for two years is a migration project in itself.

Editors lose the editing experience they love

This is the drawback that causes the most regret. In a traditional site, editors see the page roughly as visitors will, preview instantly, and rearrange blocks or sections visually. In a headless build, wp-admin becomes a form-filling exercise: fields in, published page out, with a build delay in between if the front end is statically generated. Marketing teams who were promised “a modern website” discover they can no longer build a landing page themselves – every new layout goes through a developer sprint. I have been hired more than once to un-headless a site for exactly this reason.

The performance myth: headless is not automatically faster

The number one reason businesses are sold headless is speed. The claim: “WordPress is slow, headless is fast.” Both halves are wrong.

Slow WordPress sites are slow because of a bloated multipurpose theme, a page builder stacking div soup and render-blocking assets, 40 plugins each loading their own CSS and JS, unoptimised images and no caching. Remove those causes and WordPress is quick. A lean custom theme with optimised images, proper caching and a CDN routinely scores 90+ on PageSpeed mobile – my own site is a plain traditional WordPress build with a custom theme and scores 95+ mobile, and I hand builds over at that level as a standard, using nothing more exotic than the checklist in my complete WordPress speed guide.

Meanwhile, headless sites are not fast by default. A client-heavy React front end can ship a megabyte of JavaScript and score worse than the PHP site it replaced; hydration cost is a real Core Web Vitals problem, which is exactly why the JavaScript world invented static generation, server components and partial hydration to claw performance back. A well-built Next.js site is fast. A well-built WordPress theme is also fast. The honest comparison is “good headless vs good traditional”, and at that level the difference for a content site is milliseconds – invisible next to the 2-3x cost difference.

If your current site is slow, the cheapest fix is almost never a re-platform. A speed optimisation pass on the existing site – or a rebuild on a lean custom theme – gets most sites to 90+ for a fraction of a headless budget. The same logic applies to page builders: as I argued in custom development vs page builders, the performance problem is usually the build quality, not the platform.

Who genuinely benefits – and who does not

After enough of these projects, the pattern is clear. Headless earns its cost when at least one of these is true; if none are, it is an expensive way to make your site harder to edit.

Headless is genuinely worth it for

• Content hubs feeding multiple channels. Publishers, media companies and documentation teams whose content goes to a website plus apps, syndication partners or other properties. One editorial workflow, many heads.
• Enterprises with in-house JavaScript teams. If React developers are already on payroll and the design system already exists in components, the build premium shrinks and the maintenance question answers itself.
• Multi-site, multi-brand organisations. Five brand sites sharing one content backend and one component library amortise the headless investment across every launch.
• Genuinely app-like front ends. Products where the “site” is really an application – logged-in experiences, real-time features, heavy interactivity – where WordPress is only the marketing/content layer behind it.
• Strict security or compliance environments that want the CMS entirely off the public internet.

Headless is usually the wrong call for

• Small business websites. A 5-15 page site with a blog and a contact form gains nothing a good custom theme does not provide, and loses easy editing.
• Most WooCommerce stores. Headless WooCommerce means rebuilding cart, checkout, my-account and every payment and shipping extension’s front end. The engineering bill is enterprise-sized; most stores are not.
• Most blogs and content sites with one channel. The multi-channel advantage does not exist, and the publishing workflow gets worse.
• Marketing teams that ship landing pages weekly. If layout changes must not require a developer, headless directly contradicts your workflow.
• Anyone without ongoing access to a JavaScript developer. The site will need one, roughly monthly, for as long as it exists.

Middle-ground options before you go headless

Most of the benefits people want from headless can be had inside a normal WordPress stack, one at a time, at a fraction of the cost. Before approving a headless budget, check whether one of these gets you there.

A modern custom theme

A lean, hand-coded theme with structured editable sections gives you the design freedom, the performance and the clean markup people associate with headless – while preview, plugins, forms and SEO tooling keep working. This is my default recommendation for 80% of the businesses who ask me about headless, and it is exactly what my WordPress theme development service produces. Sprinkle in Alpine.js, vanilla JS or a few mounted Vue/React components where a page genuinely needs interactivity.

Static export or full-page caching plus a CDN

If the goal is “static-site speed and security”, full-page caching with long TTLs behind Cloudflare gets you 95% of the way: visitors are served cached HTML from the edge, and PHP only runs for editors. True static export (Simply Static, WP2Static, or hosting like Strattic) goes further for brochure sites that rarely change – the public site is literally files on a CDN, with WordPress hidden away, and no JavaScript rewrite anywhere in sight.

Partial hydration inside WordPress

You do not need to re-platform to use React. A traditional theme can mount interactive islands – a booking widget, a filterable product grid, a calculator – as components on otherwise server-rendered pages. WordPress core itself now ships an Interactivity API for exactly this pattern. You get app-like moments where they matter without paying the two-stack tax everywhere.

Headless for one thing, not everything

Sometimes only one channel needs the API: a mobile app that pulls posts, a partner site that syndicates content, a screen in a showroom. WordPress happily serves REST or GraphQL to that consumer while continuing to render its own website normally. This “hybrid” pattern – a normal site that is also an API – is cheap, low-risk, and covers a surprising share of the “we need headless” briefs that land in my inbox.

What a headless stack looks like in practice

When headless is the right call, this is the stack I actually deploy – useful to know both for planning and for sanity-checking an agency proposal.

The backend: WordPress as the content API

Standard WordPress on any decent PHP host, hardened and hidden (separate subdomain like cms.example.com, admin behind allowlist or SSO). WPGraphQL as the API layer, with WPGraphQL for ACF exposing custom fields and an SEO extension exposing Yoast or Rank Math data. Custom post types and field groups are designed API-first: clean, predictable structures the front end can rely on.

The front end: Next.js or Nuxt

Next.js (React) is the most common choice, Nuxt (Vue) close behind; Astro is excellent for content-heavy sites with minimal JavaScript. Pages are statically generated or server-rendered at the edge, with incremental revalidation so a published post appears within seconds rather than after a full rebuild. A typical page query looks like this:

query PostBySlug($slug: ID!) {
  post(id: $slug, idType: SLUG) {
    title
    content
    date
    featuredImage { node { sourceUrl altText } }
    seo { title metaDesc }
  }
}

Hosting, previews and glue

The front end deploys to Vercel, Netlify or Cloudflare from a Git repository; every push gets a preview URL. Editorial preview is wired through draft mode: a “Preview” link in wp-admin opens the front end with a token that lets it fetch unpublished content. Webhooks from WordPress trigger revalidation or rebuilds on publish. Forms go to a serverless endpoint or a form service; search goes to a hosted index if the site is large. Expect the preview-and-publish plumbing alone to take days, not hours – it is the part every underscoped headless quote forgets, and it sits squarely in API integration territory.

Migration cost and timeline: realistic ranges

Numbers vary with scope, but after quoting and building enough of these, honest ranges for a senior freelance developer look like this (agencies typically run 2-4x higher):

• Small marketing site (5-15 pages, blog): EUR 5,000-9,000, roughly 4-7 weeks. The same site as a custom traditional theme: EUR 1,500-4,000 in 2-4 weeks.
• Content hub (large blog/publisher, custom post types, search, multiple feeds): EUR 9,000-20,000, 6-10 weeks.
• Multi-brand or app-backed platform: EUR 20,000+, 2-4 months, and genuinely needs a team rather than one developer.
• Headless WooCommerce: start around EUR 15,000-25,000 and treat any lower quote with suspicion – cart, checkout, accounts and extension parity are where these projects sink.

Add ongoing costs: two hosting bills, third-party services (forms, search, image CDN – commonly EUR 20-100 per month combined), and a JavaScript developer for maintenance at a few hours a month minimum, more when frameworks release major versions. Budget the first year of ownership, not just the build. And plan content parity honestly: redirects, meta data, structured data and feeds all need to survive the move, or the migration pays an SEO tax on top of the invoice.

How to decide: site type to recommendation

My honest defaults, the same ones I give paying clients:

One more test that settles most debates: ask who will maintain the front end in year two, and what happens when marketing wants a new landing page on a Friday. If the answers are “we would hire someone” and “they wait for a sprint”, build traditional.

Not sure whether headless is right for your site?

Send me your site and what you are trying to achieve, and I will give you a straight answer – including “you do not need headless” when that is the truth, and a fixed quote within 24 hours for whichever route fits: a fast custom WordPress build, a headless setup done properly, or a speed and architecture review of what you have. Have a look at my portfolio and send me a message – I reply within 24 hours.

Frequently asked questions

What is headless WordPress?

Headless WordPress is an architecture where WordPress manages content only, exposing it through the REST API or WPGraphQL, while a separate JavaScript application (such as Next.js or Nuxt) renders the public website. The WordPress theme layer – the “head” – is removed.

Is headless WordPress faster than normal WordPress?

Not automatically. A well-built traditional theme with caching and a CDN reaches 90+ PageSpeed scores, while a poorly built headless front end can be slower than the PHP site it replaced. Compare build quality, not architecture labels.

How much does a headless WordPress site cost?

Realistically 2-3x a comparable traditional build: about EUR 5,000-9,000 for a small marketing site from a senior freelancer, EUR 9,000-20,000 for a content hub, and EUR 15,000+ for headless WooCommerce, plus higher ongoing hosting and maintenance costs.

Do plugins work with headless WordPress?

Backend plugins (SEO data, ACF, security, redirects) largely work, but anything that outputs front-end markup – forms, sliders, shortcodes, most WooCommerce extensions – must be rebuilt on the JavaScript side.

Should I use the REST API or WPGraphQL for headless?

For a full headless site, WPGraphQL: single-query fetching, typed schema, and first-class support in Next.js tooling. The built-in REST API is fine for feeding a single simple consumer like a mobile app.

Can WooCommerce run headless?

Technically yes, via the Store API and WooGraphQL, but cart, checkout, accounts and extension front ends must be rebuilt, which puts costs at enterprise level. Most stores are better served by an optimised traditional WooCommerce build.

Is headless WordPress better for SEO?

Not inherently. Server-rendered or static headless pages index fine, but sitemaps, meta output, redirects and structured data all become developer tasks instead of plugin checkboxes. A traditional site with a well-configured SEO plugin is easier to keep correct.