Headless WordPress vs traditional WordPress: what actually matters

WordPress does two jobs. It stores your content (pages, posts, products, images, every field your team fills in) and it renders that content into the HTML a browser sees, through a PHP theme. Traditional WordPress does both jobs. Headless WordPress keeps the first and hands the second to something else: in our case a Next.js frontend that pulls the content over an API and ships finished pages.

That is the entire architectural difference. Everything below is a consequence of it.

In practice a headless build looks like this. WordPress lives on its own private subdomain, where your team logs in exactly as they always have. The public site on the main domain is a separate application, deployed to a global edge network. Visitors never touch WordPress. They have no idea it’s there.

A traditional WordPress page is assembled on demand. Someone requests it, PHP boots, the plugins load, the database gets queried, and HTML comes back. Caching plugins put a lid on that, but it’s a lid on a pot that keeps reheating: every extra plugin, slider, font and tracking pixel adds weight, and the theme was built to satisfy a demo page, not your business.

A headless frontend is built once, when you deploy or when content changes, and served as static HTML from a location near the visitor. No PHP, no database in the critical path. The expensive work happens before anyone arrives.

The honest version: a carefully tuned traditional WordPress site, on a lean theme with real caching, can absolutely pass Core Web Vitals. We’ve built those too. The difference is direction of travel. On headless you have to work to make the site slow. On traditional WordPress you have to work to keep it fast, and you are always one plugin update away from losing ground.

In South Africa that gap matters more than the benchmark suggests. Most of your traffic is mobile, on data people pay for by the gigabyte, often far from wherever your server sits. Cutting a megabyte and a couple of round trips decides whether someone reads the page or gives up on it.

Most WordPress sites aren’t broken into by a genius. They’re found by a bot that scans for a login page, tries a list of known plugin vulnerabilities, and moves on within seconds if nothing bites.

A headless frontend has no login page. No PHP execution, no plugin code, no database reachable from the public domain. It is HTML, CSS and JavaScript on a CDN. There is very little there to exploit.

WordPress still exists, still needs updating, still needs a strong password and two-factor. But it now sits on a subdomain you can lock down properly: kept out of search results, wrapped in strict security headers, restricted where the client’s workflow allows it. When the next plugin vulnerability does the rounds, the thing every bot on the internet is knocking on is no longer your shopfront.

This is where the conversation usually goes wrong. Clients hear “headless” and picture losing control of their own website.

In reality the person publishing your news posts logs into the same WordPress admin, sees the same editor, drops images into the same media library. If the content model has been built properly they see fewer confusing options than before, not more: fields that match the page they’re actually editing, and no way to accidentally break a layout a designer spent a week on.

What genuinely changes is timing. The live site doesn’t update the millisecond you hit Publish. A build runs, usually under a minute, or the page revalidates on a schedule. For the large majority of sites that is a non-issue. If your business depends on publishing to the second, say so early and we design for it.

The real trade-off is one people rarely raise: you give up the drag-anything-anywhere freedom of a page builder. Structure is decided up front, in design, and content flows into it. That’s a feature if you want the site to still look coherent in three years. It’s a limitation if your team wants to invent a new layout every Tuesday without a designer involved.

Traditional WordPress is one bill and one place: a PHP and MySQL shared host, and everything lives on it. Simple, and genuinely a virtue.

Headless is two places. WordPress can stay on inexpensive shared hosting because it only serves your editors and an API now, so it no longer has to be fast for the public. The frontend deploys to a platform built for it, which at portfolio and brochure scale is usually free, or exports to static files you upload to the same host if you’d rather keep everything under one roof.

Two moving parts is more setup: DNS on both, environment variables, a deploy that fires when content changes. It is not more ongoing work but it is an hour of someone’s expertise at the start, and a team that hasn’t done it before will feel every minute of it.

We would rather talk a client out of headless than hand over something they can’t run. Stay traditional when:

• The site’s value lives in plugins. Complex membership systems, learning platforms, booking engines with room inventory, multi-vendor marketplaces. These ship as complete PHP products, front end included. Rebuilding their screens headlessly is expensive and buys you very little.
• The budget is tight and the site is small. A five-page brochure site on a lean theme is fine. Headless won’t earn back the extra build cost in that shape.
• Nobody will own the pipeline. If the site will eventually be handed to whoever is available, a conventional install is easier for the next person to pick up.
• Layouts change constantly, speed doesn’t matter much. A team building new landing pages weekly, with no designer in the loop, is better served by a page builder than by us.

Headless earns its keep when the website is a shopfront rather than a pamphlet: when speed, search visibility, security and a design nobody else has are things you would genuinely pay for.

Does the value of this site come from plugins, or from design and content? Does its traffic arrive on a phone, through search, on a network you don’t control? And will anyone be maintaining it in two years’ time?

Two or three answers pointing the same way settle it quickly. There is no prize for choosing the more sophisticated architecture. The prize is a site that loads fast, stays up, and that your team is not afraid to touch.