Headless WordPress vs Traditional WordPress: The Honest Case Against

For most sites, the answer to headless WordPress vs traditional WordPress is traditional. Headless is worth its cost when your content has to feed more than one front-end, when the front-end is a genuine application rather than a marketing site, or when a large editorial team needs publishing workflows a theme cannot support. If none of that describes you, going headless buys you a second system to maintain and takes away the editing experience your team already knows.

That is an unusual thing to read, and the reason is worth stating up front.

Why every article you have read recommends it

Look at who publishes the comparisons that rank for this query. Headless CMS vendors. Hosting companies with a headless product. Platform companies whose commercial interest sits squarely on one side of the question. They are not lying, but they are all answering "should you go headless" from a position where yes is the profitable answer.

Devfinix sells no hosting and no CMS licences. We build on WordPress and we build custom applications, and we get paid either way, which makes this one of the few places you will read the costs written down properly.

What headless WordPress actually means

In traditional WordPress, one installation does everything. It stores content, and a PHP theme turns that content into HTML on the same server. The editor sees roughly what the visitor will see.

In a headless setup, WordPress keeps the content and the admin, and stops rendering pages. A separate front-end application, usually React or Next.js, fetches the content over an API and renders it. WordPress became an API with a login screen attached.

The API has been in core for a long time. WordPress 4.7 shipped REST API endpoints for posts, comments, terms, users, meta and settings, so any modern installation can serve content without a plugin:

curl "https://example.com/wp-json/wp/v2/posts?per_page=10&_embed"

Teams who want typed queries usually add WPGraphQL, a free plugin that exposes a GraphQL schema over the same data:

query LatestPosts {
  posts(first: 10) {
    nodes {
      title
      slug
      excerpt
      featuredImage { node { sourceUrl altText } }
    }
  }
}

Nothing here is exotic. The technology is mature and it works. The question is never whether it can be done. It is whether the operating cost is worth what you get back.

When headless WordPress genuinely earns its cost

There are four situations where we would recommend it without hesitation.

Content that has to reach more than one front-end

If the same articles, product descriptions or help content must appear on a website, inside a mobile app, on a kiosk, and in a partner's system, then a content API is the correct architecture. The alternative is maintaining the same copy in several places, which fails within a month.

This is the strongest case for headless, and it is also the one most often claimed without being true. "We might build an app one day" is not multi-channel. Count the front-ends that exist or are funded.

A real application front-end, not a marketing site

When the site is mostly an application, with authenticated state, complex interactions, and a component library the team is already maintaining, WordPress rendering pages around it becomes the awkward part. Letting the application own the front-end and pulling marketing content in over the API is cleaner than the reverse.

The test is what proportion of the interface is interactive product rather than published content. If it is a handful of forms and some animation, it is a website and a theme will do.

Performance targets a tuned traditional build cannot reach

This one gets overstated. Google's thresholds for a good experience are an LCP within 2.5 seconds, an INP of 200 milliseconds or less and a CLS of 0.1 or less at the 75th percentile. A traditional WordPress site with a custom theme, no page builder, page caching, a CDN and properly sized images clears those on ordinary marketing content. Most slow WordPress sites are slow because of forty plugins and a builder, not because PHP rendered the HTML. How much clearing those thresholds is worth in rankings is a smaller story than the pitch, and we answered it in do Core Web Vitals affect rankings.

Headless becomes genuinely useful at the edges: very large catalogues, heavy personalisation, or front-ends that need fine-grained control over hydration and streaming. Those are real, and they are rarer than the articles suggest.

A large content team with distinct publishing needs

If you have enough editors that content modelling, structured fields, granular workflow and reuse across sections actually matter, decoupling the model from the presentation starts paying for itself. A team of two publishing blog posts does not clear that bar.

What it costs you, specifically

Every one of these is a cost we have watched land on a team after launch, when the enthusiasm from the architecture discussion has worn off.

You lose the visual editing loop

This is the big one, and it is nearly always underweighted. In traditional WordPress an editor changes a heading, clicks update, and sees the page. In a headless build they change a field in the admin, then wait for something else to render it somewhere else, in a layout that does not look like the editor.

Everything the block editor gives you in context, seeing the actual layout, dragging a block, checking the spacing, is gone unless you rebuild it. Editors notice this on day one and mention it for the next two years.

Preview stops being free

Preview in traditional WordPress is a link. In a headless build it is a feature someone has to implement and maintain: a token, a route that flips the front-end into an uncached mode, and a fetch that returns unpublished content. Next.js provides Draft Mode for exactly this, which makes it tractable rather than free:

// app/api/preview/route.ts
import { draftMode } from "next/headers"

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url)
  if (searchParams.get("secret") !== process.env.PREVIEW_SECRET) {
    return new Response("Invalid token", { status: 401 })
  }
  const draft = await draftMode()
  draft.enable()
  return Response.redirect(new URL(`/blog/${searchParams.get("slug")}`, request.url))
}

That is perhaps an hour of work. Keeping it correct through framework upgrades, caching changes and new content types is the part nobody budgets.

The plugin ecosystem partly stops applying

The WordPress plugin directory describes itself as the largest directory of free and open source WordPress plugins, and a great deal of what a normal site needs is already sitting in it. Going headless keeps the plugins that work on data and the admin, and discards most of the ones that produce front-end output, because your front-end never loads the WordPress theme.

In practice that means rebuilding, in your front-end:

• Forms, validation and spam protection
• Page-builder or block layouts, unless you render blocks yourself
• Pop-ups, sliders, galleries, cookie banners
• Redirect management, if the redirects were handled by a plugin
• Whatever your SEO plugin was emitting: titles, meta descriptions, canonicals, Open Graph tags, structured data, the sitemap

None of that is difficult. All of it is work, and each item becomes something your team now owns forever. The structured data half is the easiest to get subtly wrong, and which schema types earn their place is worth reading before you rebuild it by hand.

Two systems to maintain instead of one

You now run a WordPress installation that still needs core, plugin and PHP updates, plus a JavaScript application with its own dependency tree, build pipeline and upgrade path. Two deploy processes. Two places a security advisory can land. Two things to test when either one changes.

The framework side moves faster than WordPress does. A front-end left alone for a year is a genuinely unpleasant upgrade.

Two hosting bills instead of one

You pay to host WordPress, which is still doing real work, and you pay to host or build the front-end. Costs vary by provider and by how often you rebuild, so check current pricing rather than a figure in an article. The structural point stands: one site, two bills, and a rebuild or revalidation cost every time content changes.

An editor's change becomes a developer ticket

This is the cost that shows up in month three. Adding a section to a page, changing the order of a block, adding a new field to a template: in traditional WordPress an editor does some of that alone. In a headless build, anything the front-end does not already render needs a JavaScript developer, a pull request and a deploy.

Sites in this state accumulate a queue of small content changes waiting on engineering time. That queue is the real price of going headless, and it is paid in weeks, not pounds.

Headless WordPress vs traditional WordPress, side by side

What to do instead on a B2B marketing site

WordPress is still on a very large share of the web. W3Techs' running survey put it at 40.2% of all websites as of 23 September 2026. Most of those sites do not need re-architecting. They need the boring work done properly.

If your WordPress site is slow, the fix is almost always a custom theme instead of a page builder, ruthless plugin reduction, page caching, a CDN, and images served at the size they are displayed. That is the approach behind our WordPress development work, and it costs a fraction of a headless migration.

If the site is not really a content site at all, the honest answer may be that it does not need a CMS. Several projects in our portfolio are content-heavy without one: the Synergy Financial Management site carries eleven service pages and a thirty-guide tax library, and the stack we documented for it is a Next.js build with no CMS in it. Schultz Inc. is the same shape, with a filterable portfolio of fifteen documented transactions and LegalService schema. When content changes a few times a month and a developer is already in the loop, that is often simpler than either option in this comparison. It is the kind of thing our web design and development engagements scope up front.

And if you genuinely have a second front-end coming, build the API layer when the second front-end is funded, not when it is a slide in a deck.

The decision rule

Go headless if you have more than one front-end consuming the same content today, if the site is mostly application, or if a large editorial team needs a content model that a theme cannot express.

Stay traditional if you have one website, a small team, and a performance problem that is really a plugin problem. Fix the plugins.

The underlying question is the same one that decides custom software versus off the shelf: you are choosing what you want to own and maintain. Headless gives you total control of the front-end and hands you every responsibility that used to come included. The same trade decides whether to stay on a website builder or hire a team. That is a fine trade when you need the control. It is a bad one when you just wanted a faster website.