Headless WordPress vs traditional WordPress

WordPress does two jobs. It stores your content, meaning the pages, posts, products and images your team adds, and it turns that content into the web pages a visitor sees, using a theme. On an ordinary WordPress site the same installation does both jobs. On a headless site WordPress only does the first job. A separate program, in our case one written in Next.js, reads the content from WordPress and builds the pages.

In practice it looks like this. WordPress is installed on its own address, something like admin.yourdomain.co.za, and your team logs in there as they always have. The public site on yourdomain.co.za is a separate application that we deploy to a network of servers around the world. A visitor to the public site never connects to WordPress at all.

An ordinary WordPress page is assembled when someone asks for it. The request arrives, PHP starts, every active plugin loads, the database is queried, and then the page is sent. A caching plugin saves a copy of the finished page so the next visitor gets it faster, which helps a lot. But the cache has to be rebuilt whenever anything changes, and every plugin, slider, font and tracking script you add still ends up in the page the visitor downloads.

A headless site is built once, when you publish or deploy, and the finished pages are stored on servers near your visitors. There is no PHP and no database involved when someone opens a page, so the slow work has already happened before they arrive.

To be fair, an ordinary WordPress site on a light theme with a good cache can pass Google’s speed tests, and we have built those. The difference is what happens over time. An ordinary site tends to get slower as plugins and features are added, and someone has to keep trimming it. A headless site starts fast and stays fast unless someone goes out of their way to slow it down.

Our own figures, which anyone can check. This site scored 100 on Google’s mobile speed test in September 2026. The product pages on ROQ Gear, our keyboard store, are about 317 KB each and scored 98 when the store launched. The Al-Burhaan site moved from a plugin-heavy theme to this setup. None of them needed a speed plugin, because the speed comes from how the site is built.

Speed matters more in South Africa than the test scores suggest. Most visitors are on phones, many of them on prepaid data, and the server is often overseas. A request from Durban to a server in Frankfurt takes roughly 150 to 200 milliseconds to travel there and back before the server does any work, and an ordinary page needs several of those trips. Pages that are built in advance and stored nearby cut most of that out.

Most WordPress sites that get hacked are not targeted by a person. They are found by automated scripts that look for a WordPress login page, try a list of known plugin weaknesses, and move on if nothing works. On a headless site the public domain has no login page, no PHP and no database, only finished pages, so there is very little for those scripts to find.

WordPress itself still exists and still needs updates, a strong password and two-factor login. But it now lives on a separate address that can be kept out of search results, protected with strict security headers and, where the client wants it, limited to the office network. When the next plugin vulnerability goes around, the thing the scripts are probing is no longer your public website.

This is where clients worry most. People hear “headless” and assume they will lose the ability to edit their own site. They don’t. The person who adds news posts logs into the same WordPress admin, uses the same editor and the same media library. If we have set the content up well they see fewer confusing options than before, because each page only has the fields it actually uses, and there is no way to accidentally break a layout.

Two things do change. The first is timing. When you press Publish the public site does not update instantly; a build runs, usually in under a minute. For almost every business site that is fine. If you need changes to appear within seconds, tell us early and we design for it.

The second is more important. You give up the freedom of a page builder, where anyone can drag a new layout together. On a headless site the structure is designed at the start and content goes into it. That keeps the site looking coherent for years, which most clients want. It is a real limitation if your team wants to invent new page layouts every week without a designer.

Ordinary WordPress lives in one place, on a shared PHP host, and that simplicity is genuinely useful.

Headless uses two places. WordPress stays on ordinary South African shared hosting (most of our clients use Xneelo), and because it now only serves your editors it does not need to be fast or large. The public site goes on a platform built for it, which at the size of a brochure or portfolio site is free, or it can be exported as plain files and uploaded to the same Xneelo account if you prefer one bill. Either way the monthly cost is the hosting you already pay for.

Setting up two places takes more work at the start, meaning DNS on both, configuration, and a deployment that runs when content changes. It is not more work month to month, but it is a few hours of experience up front, and a team that has never done it will find it fiddly.

We would rather talk a client out of headless than hand over a site they cannot run. We recommend staying with ordinary WordPress when:

• The site depends on plugins. Membership systems, learning platforms, booking engines with room inventory and marketplaces come as complete products with their own screens. Rebuilding those screens headlessly costs a lot and gains little.
• The site is small and the budget is tight. A five-page brochure site on a light theme works well. Headless would not earn back the extra build cost.
• Nobody will look after it. If the site may be handed to whichever developer is available in two years, an ordinary install is easier for them to pick up.
• Layouts change constantly and speed is not a priority. A team producing new landing pages every week without a designer is better served by a page builder.

Headless makes sense when the website is where your customers decide whether to contact you, and speed, search visibility, security and a design nobody else has are things you would pay for. That is the work described on our headless WordPress page.

Is headless better for SEO?

Not on its own. Google ranks pages, and it does not care what built them. What headless gives you is pages that are fast on a phone by default, and a site where every title, description and piece of structured data is written deliberately rather than set in a plugin. Those things do affect rankings, and they are easier to keep right.

Can we keep our WooCommerce store?

Yes, and we usually recommend it. On ROQ Gear the browsing happens on the fast public site, and the cart, checkout and PayFast payment stay on WooCommerce, which handles them well and is what customers expect.

Can we go back to ordinary WordPress later?

Yes. The content never leaves WordPress. Install a theme and the site renders the old way.

How much more does it cost?

More to build and the same to run. The extra cost is the public site, which is designed and coded rather than chosen from a theme. We quote a fixed price once we have seen what the site needs to do, and if an ordinary WordPress site would serve you better we say so in the first conversation.

We ask three questions. Does the value of the site come from plugins, or from its design and content? Do visitors arrive mostly on phones, through search, on connections you cannot control? And will someone be maintaining the site in two years? If two or three answers point the same way, the decision is usually clear. There is no credit for choosing the more sophisticated option. The aim is a site that loads quickly, stays up, and that your team is comfortable editing.