In October I followed 607 WordPress sites through the 7.1.3 security release. This taught me more about testing methods for a project like this than it did about WordPress, so I wrote down what I’d do differently next time. This is that plan turned into a method and published before any data is collected. If the eventual study departs from it, I’ll come back here to explain how and why.

If you run a website and found this page through a link in your server logs, that’s my scanner. It fetches your homepage, and possibly your /blog/ page and your blog. and news. subdomains, no more than a few times a month, to collect data for my study. A fresh check runs a few days after each WordPress release and at least once a month, and three more follow in the two weeks after a security release. The scanner reads the WordPress version your pages already indicate and nothing else. To be left out of the study and data collection, email me your domain. It will be skipped from then on, and anything already collected about it will be deleted right away.

What the new study asks

• Speed: what share of sampled sites shows the release’s fix about 12 hours, 3 days and 14 days after the announcement?
• Backports versus upgrades: how many sites reach their own branch’s security release, how many move to a newer branch with the fix, and how many stay behind?
• Coverage: how many more WordPress installs turn up beyond the homepage?

Two scans give an interval in which a site’s visible version changed. They don’t give an install time, and they can’t say who installed the update or why a site stayed put. The study doesn’t record IP addresses or hosting networks, so it won’t try to say whether sites update in host-driven clusters.

The clock

Security releases don’t come with advance notice, so I keep a recent baseline ready. A fresh baseline scan runs three days after any WordPress release, once that release’s automatic updates have settled, and at least once a month in between. Sites rarely change version except when WordPress ships something, so scanning more often would mostly re-read the same versions. The last baseline completed before a security release is the one used, and its age gets reported. Follow-ups run about 12 hours, 3 days and 14 days after the release. They start when my watcher first sees the release in WordPress.org’s public update data, so they don’t wait on me, and the announcement time on WordPress News is recorded alongside. If the setup isn’t ready before a release, the study waits for the next one. That’s already happened once: WordPress 7.1.4 came out on October 28, before this page went up, so the study starts with the security release after it.

The announcement, the backports named in the release notes and the updates sites are actually offered are different events, and they don’t always happen at the same moment. The study records the announcement time and, separately, when each branch’s fix appears in WordPress.org’s public API. When each site was first offered its patch can’t be seen from outside. Branch timing helps the analysis, but it’s published only in summary, never branch by branch.

The sample

About 20,000 domains drawn from one dated Tranco top-million list¹, split equally across three rank bands: the top 10,000, the next 90,000, and the remaining 900,000. Equal bands make the bands comparable, but they overrepresent the most popular sites, so any combined figure is weighted, and each band is also reported on its own. The margins of error take the bands into account too. October’s detection rates suggest that would yield about 2,800 WordPress sites and 1,500 readable versions. That’s a planning estimate, not a promise. The draw is already done: Tranco list GQ3LK, 6,667 domains from each band, 20,001 in all.

The October per-site files were deleted, so I can’t exclude October’s sites from the new draw, and the overlap between the two studies is unknown.

How it fetches data

Every request names the study and links to this page. The rules stay the same for the whole study: a 20-second timeout, up to five redirects, one retry only if the connection fails, plain HTTP only if HTTPS never answers, 16 fetches at a time, and no more than 2 MB read from any page. Failures are recorded, not dropped. If a redirect lands on an address already checked, ignoring www., it’s counted once.

Reading a version of WordPress core

Only two kinds of evidence count. One is the WordPress x.y.z generator tag. The other is the version number on a short list of core files that WordPress stamps with its own version: the block library styles, classic theme styles, dashicons, the admin bar, the emoji loader and wp-embed. I checked that list against the source of WordPress 4.7, 5.9, 6.2 and 7.1. Library versions such as jQuery’s, and the hashes on js/dist packages, never count.

When the signals disagree, the site is marked as a conflict rather than guessed at. Sites that hide or scramble their version are counted as such, separately. A REST API link supports a WordPress detection, but it doesn’t give a version or show that a site is headless. So does markup WordPress writes into pages, such as its block classes. That catches sites that rename WordPress’s folders to hide it, but it never gives a version either.

What counts as “patched”?

For each release studied, I’ll record from its notes the fixed version on every branch and the oldest branch that still gets fixes. A site is patched if it’s at or past its branch’s fixed version, or on a newer branch. WordPress.org keeps a public list that marks each release as current, outdated or insecure. I keep dated copies of it, so a later change there can’t quietly reinterpret an earlier result.

Sites start in one of a few groups: on the current branch or an older one, and either already patched, one release behind, or two or more behind. Each site with a readable baseline version gets exactly one outcome per follow-up: already patched; on a branch with no fix; patched on its own branch; patched by moving to a newer branch; advanced but still behind; no change; moved backwards; or no longer readable. Sites with no readable baseline are counted but left out of the uptake figures. A version that disappears is neither an update nor a failure, and it stays in its own column.

Predictions

The working hypothesis is that October showed two populations. Sites that took the previous security round have a working update path, so they take the next one within days. Sites already two or more rounds behind have something stopping them: updates switched off, a host holding them back, or nobody minding the site. Those mostly stay put, and the few that move tend to jump to a newer branch in a manual or host-driven upgrade rather than take their own branch’s backport. If that’s right, at the 14-day check:²

Sites starting…	Measure	Prediction	October
on the current branch, one release behind	patched	80–95%	90–91% after 9 days
on an older branch, one release behind	patched on their own branch	65–85%	79% after 9 days
on an older branch, one release behind	patched by moving to a newer branch	under 10%	1 of 53
on an older branch, two or more behind	patched on their own branch	under 10%	6 of 114 moved within their branch; whether they reached the fix is unknown
on an older branch, two or more behind	patched by moving to a newer branch	10–25%	18%
on an older branch, two or more behind	no change	60–85%	84 of 114 (74%)
on the current branch, two or more behind	patched	30–60%	12 of 27 (44%) moved after 9 days
in the top rank band, versus the bottom	patched	top band higher by 5+ points	not measured

Why those ranges, row by row:

1. Current branch, one behind: 80–95% patched. In October, 90–91% had moved after 9 days, so 14 days should match or beat that. The floor is lower because the new sample reaches much further down the rankings, where sites may be less tended.
2. Older branch, one behind: 65–85% patched on their own branch. October showed 79% after 9 days. Same logic: a working update path takes the next patch.
3. Older branch, one behind: under 10% patched by jumping to a newer branch. Only 1 of 53 did in October. A site still taking its own branch’s patches has probably chosen to stay on that branch.
4. Older branch, two or more behind: under 10% patched on their own branch. In October only 6 of 114 even moved within their branch, and the surviving totals can’t show whether they reached the fix. Whatever blocks these sites blocks backports in particular.
5. Older branch, two or more behind: 10–25% patched by jumping branches. 20 of 114 (18%) jumped from 7.0 to 7.1. The range is wide because that jump may have been tied to 7.1 being fairly new in October.
6. Older branch, two or more behind: 60–85% no change. In October 84 of these 114 (74%) showed no version change after 9 days, and 4 more could no longer be read.
7. Current branch, two or more behind: 30–60% patched. This group doesn’t fit the two-populations idea neatly. In October, 12 of these 27 sites (44%) moved to a newer version within 9 days. The totals don’t say how many reached 7.1.3, but it was the newest release on their branch. On the current branch, one automatic minor update takes a site straight to the newest release, so a site that missed a round only needs its updater to run once. The range is wide because October’s group was small.
8. Top rank band versus bottom: the top band patched more, by at least 5 points. No October data stands behind this one. It rests on a guess that popular sites are more likely to be professionally managed, which makes it the weakest prediction, and the most interesting if it fails.

The scoring rule is fixed now: a prediction is a hit if the observed share falls inside its range, otherwise a miss. No partial credit, and no revising ranges after the baseline. Every prediction gets reported with its denominator, hits and misses alike. Groups with fewer than 20 sites are reported but not scored.

There are good reasons not to trust these too much. They rest on one release and small groups: 53 and 114 sites, so October’s percentages carry wide uncertainty. The new sample reaches much deeper into the long tail than October’s mostly well-known sites, which alone could pull every number down. And a different kind of release, such as one WordPress.org forces sites to take, would break the backport predictions in an interesting way. The ranges are meant to be wide enough to be fair and narrow enough to miss.

What happens to the data?

Watching thousands of WordPress sites take core updates in real time would be really cool, even as a recording after the fact, but it’s a bad idea — because of the bad guys out there.

The per-site records in this study identify sites advertising versions of WordPress core that WordPress.org flags as insecure, so they’re never shared or published. They live in one local folder on my own computer, outside any synced folder and excluded from backups, so there’s a single copy and deleting it actually deletes it. The scanner refuses to write them anywhere that syncs. It never stores page content, and the records are deleted within 30 days of the final scan. Deletion won’t run until the summary tables exist, so the published conclusions keep their supporting counts. The deadline and the date of deletion will be noted here. Only totals are ever published.

This isn’t going to stop bad actors from doing their own research — they are far more sophisticated in this area than I am — but why model or do any of their work for them for free? Plus, privacy.

Limits

This study only collects data that can be seen publicly on sites and that my scanner picks up. Cached pages can lag behind an update, and hidden versions stay unknown. Each reading keeps the cache headers it came with, so readings that may come from a stale page can at least be counted. Tranco ranks domains; it isn’t a representative list of WordPress sites, and a rank says nothing directly about traffic or how well a site is looked after. HTTP Archive‘s public crawl might give a separate comparison, though not this study’s release-relative timing.

Notes

1. Tranco combines several published top-sites rankings into one list built for research, and each dated list has a permanent ID, so a sample drawn from it can be described exactly. Le Pochat et al., “Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation.” ↩︎
2. October figures are the published totals from the first study; its per-site records were deleted after the last check. Knauss, “Who actually gets WordPress security backports?” ↩︎

Sources

• HTTP Archive. Accessed October 28, 2026. https://httparchive.org/.
• Knauss, Dan. “What I’d do differently next time: studying WordPress patch uptake.” Bad Sector. October 16, 2026. https://badsector.blog/wordpress-patch-uptake-study-design/.
• Knauss, Dan. “Who actually gets WordPress security backports?” Bad Sector. October 7, 2026. https://badsector.blog/who-gets-wordpress-backports/.
• Le Pochat, Victor, Tom Van Goethem, Samaneh Tajalizadehkhoob, Maciej Korczyński, and Wouter Joosen. “Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation.” In Proceedings of the Network and Distributed System Security Symposium (NDSS 2019). Internet Society, 2019. https://doi.org/10.14722/ndss.2019.23386.