Headless vs classic WordPress: a plain-English guide for UK businesses

Headless WordPress means you keep WordPress as the place where your team writes and edits content, but the website your visitors see is a separate application, usually built in React, Vue or a framework such as Next.js, which pulls that content through an API. Classic WordPress does both jobs in one system: the same install stores the content and renders the pages. For most UK small and mid-sized businesses, a well-built classic WordPress site is faster to deliver, cheaper to run and easier to edit. Headless earns its extra cost when the same content has to feed several front ends (a website, a mobile app, in-store screens) or when you need an interface that a theme genuinely cannot deliver.

We build both, so this is not a pitch for one camp. Below is what changes for the people who edit the site, what it costs over three years with real numbers, the plugins that stop working, and a checklist to decide which one fits your business.

Classic and headless in plain English

A classic WordPress site is one piece of software on one server. When someone visits your services page, WordPress looks up the content in its database, runs it through your theme’s templates and sends back a finished HTML page. Plugins hook into that process, which is why installing a forms plugin or an SEO plugin just works: they live inside the same system that produces the page.

A headless site splits that in two. WordPress becomes a content store with an admin screen. It no longer produces the pages people see. A second application, hosted somewhere else, asks WordPress for content through the REST API or GraphQL (usually via the WPGraphQL plugin) and builds the pages itself. That front end might be pre-built into static files at deploy time, rendered on a server on each request, or a mix of both.

The word “headless” just means the “head” (the theme that renders pages) has been removed. Your editors still log in to the familiar dashboard. Everything that happens after they press Update is different.

What changes for the people who edit the site

This is the part most proposals skip, and it is where headless projects tend to disappoint. On a classic site, what an editor sees in the block editor is close to what goes live, and the Preview button shows the real page. On a headless site, none of that is automatic.

• Preview has to be built. The front end needs a preview route that fetches draft content with authentication. It is doable, but it is a feature you pay for rather than one you get.
• Blocks are only data. Every Gutenberg block your editors use (columns, buttons, galleries, embeds) has to be recreated as a component in the front end, or it will render as raw HTML or not at all. Add a new block plugin and nothing happens on the live site until a developer maps it.
• Publishing delays appear if the front end is pre-built. A typo fix may need a rebuild, which can take anything from seconds to several minutes on a large site, unless incremental regeneration or on-demand revalidation is set up.
• Menus, widgets and forms stop being drag-and-drop. They need API endpoints and front-end code.

None of this is a reason to avoid headless. It is a reason to budget for it and to ask your developer exactly how preview, blocks and publishing will work before you sign anything.

The plugin problem

Most of the WordPress plugin directory assumes a theme is rendering the page. In a headless build, plugins that only change what appears on the front end do nothing. Plugins that work purely in the admin or on data keep working.

If your site relies on a booking plugin, a membership plugin or a complex WooCommerce setup with subscription extensions, count the cost of rebuilding each front-end feature before going further. That list is often what settles the decision.

Is headless faster?

It can be, but the honest answer is that speed comes from engineering discipline, not architecture. A pre-rendered headless site served from a CDN is very fast. So is a classic WordPress theme with no page builder, sensible images, full-page caching and Cloudflare in front. We target Lighthouse 95+ on every classic template we hand over, and we hit it without going headless.

Where headless wins on speed is at scale and under load: thousands of pages served as static files, traffic spikes that never touch the WordPress database, and app-like interactions after the first page load. Where it can lose is JavaScript weight. A React front end that ships a large bundle can score worse on Interaction to Next Paint than a lean PHP theme. If speed is your main reason for considering headless, read our guide to speeding up WordPress first. Most slow sites are slow because of a page builder, cheap hosting and too many plugins, and those are cheaper problems to fix.

Security and hosting

Headless gives you a smaller public attack surface: the WordPress admin can sit on a private subdomain, locked down by IP or behind Cloudflare Access, while the public site is static files or a separate Node server. That is a real benefit for organisations that are regular targets.

The trade-off is that you now run two systems. WordPress still needs updates, backups and monitoring. The front end needs its own hosting (Vercel, Netlify, Cloudflare Pages or a Node server), its own dependency updates and its own deployment pipeline. Two systems means two places for something to go wrong, and two lots of maintenance.

What it costs: a worked comparison

Here is a realistic comparison for a 15 to 20 page business site with a blog, a contact form, a case studies section and a newsletter sign-up. Figures are excluding VAT unless stated.

Classic WordPress

For a site of this size our fixed-price packages cover most of it: the Elite Website package at £999 covers up to 15 unique responsive pages with forms and newsletter, and the Business package at £2,650 adds a fully custom WordPress or PHP build with multi-language, search and ordering. If you need a custom hand-built theme with bespoke post types instead, a typical build is around 40 hours of WordPress development at £50 per hour. With our 20-hour volume discount of 15 %, that is £2,000 less £300, so £1,700 plus £340 VAT, or £2,040 in total.

Hosting for a well-configured single WordPress install from a decent UK or EU host typically runs from about £10 to £40 a month, with Cloudflare’s free plan in front.

Headless WordPress

You still need the WordPress back end set up properly (custom fields, API exposure, preview, admin lock-down), roughly 15 to 20 hours. Then the front end: page templates, block components, SEO output, sitemap, forms, preview and the build pipeline. For the same site, 60 to 80 hours of custom development is a realistic range. Taking 60 hours at £60 per hour gives £3,600; the 50-hour discount of 20 % brings that to £2,880, plus £576 VAT, so £3,456. Add the WordPress side and you are usually at two to three times the classic budget.

Running costs also go up: WordPress hosting plus front-end hosting (free tiers exist, but commercial sites often end up on paid plans of roughly £15 to £40 a month per seat or project), plus more developer time for updates on two codebases.

Over three years, a classic site that costs £2,040 to build and £300 a year to host comes to around £2,940 before maintenance. A headless equivalent at £6,000 plus £600 a year in hosting is closer to £7,800. That gap is fine if headless delivers something you need. It is wasted money if it does not.

When headless makes sense

We recommend headless when at least one of these is true:

• One content source, several outputs. A charity that publishes the same appeals and news to its website, a Flutter mobile app and donation kiosks. Editors write once in WordPress; every channel reads from the API.
• The front end is really an application. Product configurators, dashboards, map-based search or interfaces with lots of client-side state. React or Vue handle these better than a PHP theme with sprinkles of JavaScript.
• Very high or spiky traffic. Media sites, campaign launches, ticket releases. Pre-rendered pages on a CDN do not care whether 50 or 50,000 people arrive at once.
• Strict security separation. Organisations that want the CMS completely off the public internet.
• An existing React or Vue team. If your in-house developers already work in that stack, headless lets them own the front end while marketing keeps WordPress.

When it does not

• A brochure site, a service business or a local shop with a few hundred visitors a day.
• A site that depends on WordPress plugins for bookings, memberships or courses.
• A small team with no developer on retainer. Two systems need more looking after than one.
• A tight launch date. Headless adds weeks of work that a classic build does not need.
• Speed is the only reason. A lean classic theme is cheaper to make fast.

The middle ground most businesses miss

You do not have to choose all or nothing. Some of the most sensible builds we see use a classic WordPress site for the public website and expose content through the REST API only where another channel needs it. The website keeps preview, plugins and the familiar editing experience; a mobile app or a partner portal reads products, locations or news over the API. Our API development and integration work is often exactly this.

Another option is a classic site with one interactive section built in React or Vue and mounted inside a WordPress template: a quote calculator, a store finder or a member dashboard. You get the app-like part where it matters and keep everything else simple.

For mobile-first experiences without a separate app, a progressive web app on top of WordPress can also cover offline access and home-screen installation for far less than a native build.

Questions to ask before you commit

If an agency has proposed headless, these questions will tell you quickly whether they have thought it through:

1. How will editors preview drafts, and can I see it working on another project?
2. Which of our current blocks and plugins will not work, and what will replace them?
3. How long between pressing Update and the change appearing live?
4. Where is each part hosted, and what does each cost per month?
5. Who updates the front-end dependencies, how often, and at what cost?
6. How are SEO titles, schema, canonical tags, redirects and the XML sitemap handled?
7. If we part ways, can another UK developer take over the front end easily?

Vague answers to the first three are a warning sign. Those are the areas where headless projects run over budget.

Our recommendation

If you are a typical UK business, whether a law firm in Leeds, a manufacturer in the Midlands or a clinic in Cardiff, start with classic WordPress, hand-built without a page builder. It will be fast, accessible, easy to edit and maintainable by a very large pool of developers. We explain our approach in why we build on WordPress without page builders, and if you are still weighing up platforms, our guide to choosing a CMS compares WordPress with Shopify and Webflow.

Go headless when you have a clear multi-channel or application-style reason and the budget to run two systems properly. If you are unsure, talk to us. Our team is based in St Albans, we meet clients in London and the Home Counties, and we work remotely with businesses across the UK. You can book development time by the hour through Hire us or ask for a fixed quote for a CMS build.

Photo: Jakub Żerdzicki via Unsplash