We’re moving our clients away from WordPress.

On 21 October, the PHP team released an emergency fix for two critical flaws. Both allowed someone to run code on your server without logging in to anything. Prefecture sites across France went dark as a precaution, along with government sites in Belgium, the Netherlands and Finland.

None of the sites we look after were affected. We still spent the week thinking about it and reassuring clients, because PHP runs something like seventy per cent of the web and WordPress alone is more than forty per cent of every website there is. When the thing underneath that much of the internet needs an emergency patch, the question stops being whether your site is well built.

In July I said this wasn’t about WordPress being bad

That’s still true, and the argument in that piece hasn’t changed: WordPress is a publishing tool, and it’s very good at publishing. What has changed is what it now costs to keep one safe, and who ends up carrying that cost.

So this is us changing our position. Over the next six months we’re looking to move the sites we look after onto Payload, and here’s the reasoning rather than the announcement.

The problem was never WordPress itself

There were over 11,000 new WordPress vulnerabilities disclosed in 2025, up forty per cent on the year before. Ninety-one per cent of them were in plugins. Nine per cent were in themes. Six were in WordPress core.

Six. The thing everyone pictures when they worry about WordPress is almost never the thing that goes wrong. It’s the twenty or thirty pieces of other people’s code bolted to it, each with database access, each maintained by someone you’ve never heard of and have no contract with.

Six vulnerabilities in WordPress core last year. Eleven thousand in the things attached to it.

Five hours against weeks

The rough time between a vulnerability being made public and being exploited at scale is about five hours. Most site owners take weeks to patch. Close to half of what was disclosed last year had no fix available on the day it was disclosed. The window is shorter than the time it takes most people to read the email telling them about it.

What happens after we hand a site over

We build with as few plugins as we can get away with and write the rest directly into the site. Then we hand it over, and a site that’s been handed over is a site someone else can add to.

Six months later we get asked to look at something and find a stack of plugins that weren’t there when we left. Analytics added through a plugin when it belongs in the header (when it’s already there in most cases). An additional form builder that’s unused. A cookie banner. Each one is a standing invitation, and most of them aren’t set to update themselves because nobody turned that on.

That isn’t a poke about clients. It’s exactly what the platform invites you to do, and it works, right up until it doesn’t.

And the attacks have got worse

Automated attacks on WordPress sites have climbed steadily for the last eighteen months. Highly exploitable vulnerabilities have more than doubled year on year. We block the worst of the bot traffic at server level, by region, before it ever reaches a site. It cuts the volume down a lot. It doesn’t fix anything, because a VPN costs a few pounds a month and moves you somewhere we aren’t blocking.

Why Payload

• Three reasons, in order of how much they matter.
• No PHP, so October simply wouldn’t have applied.
• No plugin chain, because everything a plugin used to do gets written into the site instead.
• Structure, because content is defined properly rather than bent into pages and custom fields until it fits.

The second one is the real prize. A plugin update that unfortunately takes out a section of the site is a domino, and the next one goes over a week later. We find out when the client finds out.

Code we wrote doesn’t change overnight because someone else pushed a release.

Why this is possible now and wasn’t before

Rebuilding a working site on a different platform used to be a quote nobody approved. There was nothing wrong with the site, so spending five figures to move it was impossible to justify, and everyone stayed where they were and hoped for the best.

That calculation has changed. We can take the database, the theme and the content files out of an existing site and rebuild it properly on the other side, for a fraction of what the same move cost two years ago. We’re doing this now because it finally makes financial sense, not because the argument is new.

What falls off on the way

Speed, mostly, and it isn’t subtle. Part of it is the platform. A lot of it is the years of accumulated weight: every image uploaded to WordPress gets copied into three or four more versions at different sizes, and on a site that has been running for years, that’s most of the bulk. We regularly open media libraries in the tens of gigabytes.

Moving across is a chance to put that right. The site comes out substantially lighter, loads faster, and it’s the user who notices first.

If we look after your site

We’ll come to you over the next six months to talk through timing and what it would involve. It needs very little from you unless you want to change things while we’re in there, which is usually worth doing. In the meantime nothing is being left alone: everything stays patched and monitored exactly as it is now.

If you take one thing

Count the plugins your site can’t work without, then check when each one was last updated and whether automatic updates are switched on. If that takes more than a couple of minutes, you have your answer on how exposed you are, and it’s worth knowing before someone else finds out for you.

Three more
worth the time.