88% of WordPress Sites Are "Out of Date". The Number Underneath It Is Smaller and Worse.

On 22 September the hosting company 20i published a piece called "The WordPress Update Gap". It took BuiltWith's data on 44 million live WordPress sites and found that 87.62% of them were not running WordPress 7.1. The headline rounded that to 88%, and by the time it had been through a few news sites and a Reddit thread it had become "88% of WordPress sites are over a month out of date".

Neither version is wrong. Both measure the wrong thing. The same data contains a much more useful number, and it is worse.

What "behind the latest release" measures

The report classifies any site below 7.1 as outdated. 7.1 shipped on 19 August, five weeks before the data was pulled. It is not a security release. Every security fix of the summer is in 7.0.4, which shipped a week earlier.

So a site sitting on 7.0.4 on 22 September is not at risk from anything 7.1 fixed, because 7.1 fixed nothing of the kind. It is what a sensible policy produces. The handbook's advice on core is to let minor releases apply themselves and to run major releases through staging first with a day or two of observation. Anyone who did that with 7.1 watched WP Rocket take sites down on launch day and was glad they waited. The 88% includes every one of those sites.

The breakdown by business size makes the same point from the other side. Enterprise sites, the ones with organisations turning over more than a hundred million dollars behind them, were 86.76% "outdated". Micro-businesses were 88.42%. That is not a story about careless small businesses. It is what a five-week-old major looks like everywhere.

The number that matters

The report also says where the outdated sites actually were. Around 63% of them, roughly 25 million sites, were running something between 6.9.0 and 6.9.4, or 7.0.0 and 7.0.1.

Every one of those versions predates 7.0.2, released on 17 July, which fixed a SQL injection reachable through the REST API's batch route without an account and leading to remote code execution. WordPress pushed 7.0.2 as a forced update. It backported the fix to 6.9.5 and 6.8.6 so that sites which had chosen not to move to 7.0 would still get it. A site running 6.9.4 or 7.0.1 in late September did not get it.

That is not a site that is a little behind. That is a site where the minor auto-updater, which is on by default and has been since 2013, did not run, and has not run for more than two months. Whatever stopped it from applying 7.0.2 also stopped 7.0.3 and 7.0.4. And it is more than half of every site in the sample.

The 88% is a mild finding about a young major release. The 25 million is a serious finding about broken auto-updates, and it was in the same table.

Why an auto-update does not happen

A site does not end up on 6.9.4 in September because the owner decided to stay there. It ends up there because the updater tried, or never tried, and nobody was told. The usual reasons, roughly in the order I find them:

File ownership the PHP user cannot write through. The updater checks whether it can write to the WordPress files as the web server user. If it cannot, it gives up silently and falls back to asking for FTP credentials nobody enters. This is the most common cause on self-managed servers where files were copied in as root.
WP-Cron not firing. Background updates run from WP-Cron, which runs on page views. A low-traffic site, or one with DISABLE_WP_CRON set and no real cron job to replace it, has no heartbeat to run them on.
A constant that turns them off. AUTOMATIC_UPDATER_DISABLED, DISALLOW_FILE_MODS, or WP_AUTO_UPDATE_CORE set to false. All three are legitimate on a site with a deployment pipeline that carries the patch instead. All three are a problem on a site that has no such pipeline and was set up from a tutorial.
A host that "manages updates". Managed hosts often disable the built-in updater and apply core releases on their own schedule. Most are quick with security releases. Some are not, and the site owner has no way of knowing which kind they have until a forced update fails to arrive.
Version-controlled deployments. If WordPress core is in your repository, the updater is off by design and the release has to come through your deploy. That is fine when someone owns the job. It is a two-month gap when nobody does.
Outbound requests blocked. The updater talks to api.wordpress.org. A firewall that blocks outbound traffic from the web server, which is otherwise a good idea, needs a hole for that.

None of these produces an error in the dashboard. Most produce an email to the admin address that nobody reads.

Check yours in a minute

Three commands, or two clicks.

wp core version
wp core check-update

Or Dashboard, then Updates. Then, and this is the one people skip, Tools, then Site Health, then the Status tab. Site Health includes a test called "Background updates" that reports whether the updater can actually run and, if not, which of the reasons above is stopping it. It is the one place WordPress tells you.

If you are below 7.0.4, update by hand today, then fix whatever Site Health reports so the next one arrives on its own.

Caveats on the data

BuiltWith identifies WordPress versions from public markers: the generator tag, version strings on scripts and styles, readme files. A site that strips those, which several security plugins do by default, may be reported as an older version or not at all. Managed hosts that hide version markers across their whole estate skew the sample in ways nobody outside them can measure. And 20i is a host with managed WordPress to sell, so the framing was always going to favour "you need someone to do this for you".

The direction of the finding survives all of that. The precise figures do not, and I would not quote them to two decimal places as the report does.

Where the five hours go

Patchstack's 2026 report put the median time from a vulnerability being disclosed to its first exploitation at five hours. That figure gets quoted a lot, usually to argue that nobody can patch fast enough, which is true. The other thing it tells you is where the window lives. It lives in the gap between a fix shipping and a site receiving it, and for 25 million sites this summer that gap has been open since July.

The fix for the 88% is patience. The fix for the 25 million is a minute in Site Health.

Where this fits

Chapter 2 of the Protect My WP handbook covers core auto-updates: what they apply, what they do not, the constant to set if you want it explicit, and why the point releases of 2026 are the argument for leaving them on. Chapter 12 has the update workflow for the plugins that need more care than that.

Get the book for £19.