WordPress vs headless: which should you build on?

"Should we go headless?" is one of the more fashionable questions we field on a first call, and it is usually asked by someone who has read that headless is faster and more modern, but not what it costs to run. So before the sales instinct kicks in either direction, here is the plain version — what each approach actually is, when each one is the correct choice, and the trade-offs nobody puts on the pitch deck.

What "traditional WordPress" actually means

Traditional — or monolithic — WordPress is the setup most of the web runs on. One system does everything: it stores your content, and it renders the pages a visitor sees, using a PHP theme. When someone requests a page, WordPress assembles it from the database and hands back finished HTML. The editing experience, the design and the public site all live in the same place. That coupling is the whole point, and it is also the thing headless deliberately breaks.

What "headless" actually means

Headless — sometimes called decoupled — keeps WordPress as the place you write and store content, then cuts off the "head" that draws the pages. Instead of WordPress rendering the site, it exposes your content through an API, and a separate front end — commonly built in a framework like Next.js or Astro — fetches that content and renders it, often as pre-built static pages served from a CDN. You keep a familiar editor; you replace the entire presentation layer with custom code. It is not a plugin you switch on. It is a second application to build, host and maintain.

When WordPress is the right, boring, correct choice

For most small and medium businesses, traditional WordPress is not a compromise — it is the sensible answer, and we say so even though "just use WordPress" is a less impressive line than "we'll architect a headless stack".

• Your team already knows the editor. Marketers can publish a page, swap an image or edit a menu without filing a developer ticket. That autonomy has real commercial value and headless routinely erodes it.
• The plugin ecosystem does the work for you. Forms, SEO controls, bookings, memberships, multilingual, ecommerce via WooCommerce — decades of mature, supported tooling that mostly just works.
• The cost is lower at every stage. One system to build, one to host, one to maintain. Less bespoke code means fewer things only a developer can touch.
• It is more than fast enough. A well-built WordPress site on decent hosting, with sensible caching and disciplined images, comfortably clears the Core Web Vitals thresholds Google measures. Speed problems on WordPress are almost always a bloated theme, twenty plugins and unoptimised images — not the architecture itself.

Most brochure sites, service businesses, professional practices and modest ecommerce stores should build on WordPress and spend the money they saved on content and marketing instead. That is not a cop-out. It is where the return is.

When headless earns its complexity

Headless is a real tool with real advantages — the mistake is reaching for it by default rather than for a reason. It earns its keep when the constraints below genuinely apply to you, not when they merely sound aspirational:

• Performance is a hard commercial requirement. High-traffic sites where milliseconds move revenue, or where you need the tightest possible control over what ships to the browser, benefit from a purpose-built front end.
• You are publishing to many channels at once. If the same content has to feed a website, a mobile app, in-store screens and a partner's system, an API-first content store stops you copying it four times.
• You have developers — in-house or retained. Headless replaces a mature theme-and-plugin ecosystem with code you now own and must keep alive. Without ongoing engineering capacity, that is a liability, not an asset.
• You want deep control over the front-end experience. Highly interactive, app-like interfaces are simpler to build in a modern JavaScript framework than to bend a PHP theme into.

Notice the pattern: every one of those is a specific capability or constraint, not a vibe. If you cannot point to which one is yours, you probably do not need headless yet.

The trade-offs nobody puts on the pitch deck

The honest way to choose is to look at what headless costs you, because the marketing rarely does.

• Editor experience. The biggest quiet loss. Live preview, drag-and-drop layout and "what you see is what you get" often break or require extra engineering to restore. Marketers used to editing freely can find themselves back to raising tickets.
• Cost and time. Two applications cost more to build and more to run than one. Expect a higher initial budget and a longer timeline before anything is live.
• Maintenance. You now own custom front-end code plus its framework, dependencies and build pipeline. Plugins that used to add a feature in an afternoon may need bespoke development instead.
• Hosting complexity. Instead of one host you manage a headless CMS and a separately deployed front end, with a build-and-deploy step between edit and publish. More moving parts, more to monitor.

The practitioner's verdict

There is no platform to worship here. Headless is neither the future everyone must migrate to nor an over-engineered fad — it is a specialised tool that is excellent for a narrow set of problems and overkill for everything else. Our rule is simple: default to well-built WordPress unless a concrete requirement — genuine performance pressure, true multi-channel publishing, or a front-end sophisticated enough to justify the engineering — forces the decoupled route. If you cannot name that requirement, you have your answer, and it is the cheaper one. We would rather talk you out of complexity you do not need than sell you architecture that impresses at kick-off and frustrates your marketing team for years.