I Scanned 250 WordPress Sites. The First Number Said 39.6%. The Real One Was 4.8%.

The first number the scan gave me was 39.6%.

That was the share of WordPress sites running at least one plugin the WordPress.org directory had closed. Four in ten. It would have made a very shareable headline, and it was wrong by a factor of eight.

After I checked every match by hand, the defensible figure was 4.8%: 12 sites out of 250, each one confirmed. This post is mostly about the distance between those two numbers, because that distance is where every tool that reports on WordPress plugins either earns your trust or loses it.

I built a free WordPress plugin checker that reads a public site and reports the maintenance facts the directory publishes about each plugin it can see. The study used the same detection code. When the study's first count turned out to be wrong, the reasons were bugs and blind spots the tool shared, so the corrections below went into the tool as well as into the figures.

What I measured, and on what

I wanted to know how often a real WordPress site runs a plugin that nobody is shipping anymore. Not a theoretical risk, just a count.

The sample came from the Tranco list (list N2PYW, generated 15 September 2026), which ranks sites by traffic. I drew 3,000 domains at random from ranks 200,000 to 1,000,000, after removing infrastructure, CDN, ad and tracking domains. That is the middle of the list: well-visited sites, but not the household names.

The scanner took those domains in a random order and stopped once it had 250 usable WordPress sites. It worked through 1,984 domains to get there:

Those 250 are the denominator for everything that follows. Every percentage below is a share of WordPress sites with at least one plugin visible from outside, and every one comes with a 95% confidence interval, because 250 is a modest sample and a single number without its range would overstate what it can tell you.

The scan ran on 16 and 17 September 2026, two sites at a time with a pause between each, under a user agent that names the scanner and links to a page explaining it. A site whose robots.txt disallowed it was skipped. On the rest, it asked only for things any visitor can ask for: the home page, at most one inner page, the public REST index, and each plugin's readme.txt where robots.txt allowed it.

"No release in over N years" means the directory's last release date was more than N years before the run started. Nothing in this study assesses vulnerabilities, and nothing here says any plugin is insecure.

How 39.6% became 4.8%

This is the part I would want to read if someone else had written this study, so here is every step, in order, applied to the same 250 sites throughout.

Each stage removed matches that were not what they looked like.

Stage 1: a name is not a plugin

A scanner sees a plugin in one of two ways. The strong way is an asset path: the page loads a file from /wp-content/plugins/some-plugin/, so a folder by that name exists on the server. The weak way is a REST namespace: the site's /wp-json/ index lists a route name that some code registered.

A route name is just a string. Any plugin can register any name, and a plugin often registers names that belong to its own bundled modules.

The clearest case in the data: a wordfence-login-security namespace appeared on 34 sites, every one of them also running Wordfence. There is a standalone Wordfence Login Security plugin whose directory listing is closed, but Wordfence also bundles a login security module of its own, and that is the far more likely source. Matched to the closed listing by name, the namespace put a closure on 28 of the 99 sites. No closure on those sites was ever actually shown.

I dropped every closure that rested on a namespace alone, not just that one, because the same thing can happen to any name. That removed 51 sites.

Stage 2: some closures say nothing

The directory records a reason when it closes a listing. Some of those reasons carry no information.

"Unused" means someone registered the slug and never put code in it, so a site cannot be running the listed plugin. What it is running is a commercial plugin that uses the same folder name. Events Calendar Pro and MetaSlider both matched listings like that. WPML's folder name matches a listing closed as "Unknown" in 2017, while the commercial plugin is current.

Closures marked "Unused", "Unknown" or with no reason at all now read as "not in the directory", which is the honest description. That removed 17 more sites.

Stage 3: leaving the directory is not abandonment

An author can ask WordPress.org to close their listing and carry on shipping the plugin from their own site. That is a business decision, not neglect.

Paid Memberships Pro is the cleanest example. Its listing was closed at the authors' request on 17 October 2024. They shipped version 3.8.6 on 8 September 2026, eight days before the scan started. Counting it as abandoned would have been simply false.

Author withdrawals are reported on their own and are not part of any figure in this post: 2.4% of sites (1.1 to 5.1) ran a withdrawn plugin, and on half of those the plugin is demonstrably still maintained elsewhere. Separating them removed 5 sites from the closure figure.

Stages 4 and 5: checking every match by hand

That left 33 plugins closed by the WordPress.org plugin team itself. I checked each one against the directory's own release history and the version the site was actually running. A match only counted if the site was running a version the closed listing had published.

Three were collisions. The site was running a version number the listing never released, which means the folder holds a different product that shares a name with an old directory entry. Those removed 3 sites.

Eighteen could not be settled either way. Usually no version was visible, or the only version on show belonged to something else: a WordPress core number, a bundled library, or a generic 1.0. I excluded them rather than guess. Some of them are probably genuine closures. I could not show it, so they do not count.

Twelve were confirmed, each on a different site. Those 12 sites are the published figure, and all 12 were seen through a real asset path.

What survived

Here is what holds up, with and without the weaker namespace evidence.

The second column needs one explanation. Removing namespace-only detections leaves 28 sites with no visible plugin at all, so its denominator is 222, not 250. Every figure is computed twice so you can see how much of it depends on the weaker evidence.

About one site in twelve runs a plugin that is either closed or silent for three years. That is 21 sites. The two groups overlap on 5 of them: 7 sites have a plugin-team closure and nothing over three years old, 9 have a three-year silence and no closure, and 5 have both. The overlap is always two different plugins on the same site, because a closed listing publishes no release date to be old.

The three-year figure is solid. 13 of its 14 sites were seen through an asset path, and the figure barely moves when namespace evidence is removed.

The two-year figure holds, narrowly. It is 9.6% on all detections and 6.8% on asset paths alone. The second number sits just inside the first one's interval, so state them together.

The one-year figure cannot stand on its own. 33 of its 59 sites rest on a REST namespace alone. The defensible version is a range: between 11.7% and 23.6% of sites run a plugin with no release in over a year. It is also sensitive to where you draw the line. Move the threshold from one year to 15 months and the all-detections share drops from 23.6% to 14.8%, because several widely installed plugins last shipped just over a year before the run.

How many plugins a site shows

The median site showed 7 plugins from outside (95% interval 6 to 8). Counting only asset paths, the median was 5 (4 to 5).

Those two intervals do not overlap, which is worth noticing. The number of plugins you find on a site depends heavily on how you look. Any plugin count quoted without its detection method is hard to compare with anything else.

And both are floors. A plugin that only works in wp-admin, or whose files are bundled into a cache, leaves nothing on a public page to find.

The plugins that are not in the directory at all

63.6% of sites ran at least one plugin that is not listed in the WordPress.org directory.

That sounds alarming and mostly is not. Commercial plugins sold from their developers' own sites are legitimately absent from the directory, and they are a normal part of a professional WordPress build. The figure is context, not a finding. What it does tell you is that on most sites, part of the plugin list sits outside anything a public check can assess. Whether those plugins get updates depends on licences, and no outside scan can see whether a licence has lapsed.

The most-seen plugins say as much about detection as about plugins

I also counted which plugins with no release in over a year turned up most often. Six of the eight most frequently seen were detected only through a REST namespace, on every site they appeared on. That includes all 19 sightings of Regenerate Thumbnails, the most common of them.

So that list shows which namespaces are commonly exposed at least as much as which plugins are commonly installed. A plugin can leave its routes registered on a site where it does little else that is visible. I am not publishing the list as a ranking of neglected plugins, because it would not support that reading, and a release date on its own says nothing about whether an author is still around.

What this study cannot tell you

Every one of these limitations pushes the result in a known direction, and you should read the figures with them in mind.

• Every figure is a floor. Only plugins that show on public pages, or register a REST route, can be seen at all.

• The sites that turned the scanner away are missing, and they are not a random subset. 14.7% of the domains that answered blocked the request, and a further 5.5% of resolved domains disallowed the scanner in robots.txt. Sites that turn away unknown crawlers are probably better looked after than average. Leaving them out probably makes the result look worse than the web really is.

• This is not a sample of all WordPress sites. Tranco ranks sites by traffic, and the band I sampled is a particular slice of the web.

• The closure rules were written after seeing the data. Each one rests on a principle I can state, and each is disclosed above with the figure before and after it. But they were not registered in advance, and you should weigh that.

• Slug matching cannot always separate a commercial plugin from an old directory listing with the same folder name. The audit removed the cases it could identify and excluded the ones it could not settle.

• The list of excluded infrastructure domains matches exact domains only, so a pattern-based infrastructure host could still have slipped into the sample. In practice the rule that a site must serve an HTML page did most of that filtering.

• The one-year threshold is a weak proxy. Moving it by three months moves the figure by nearly nine points.

• Results depend on the day. A rerun with the same seed reproduces the sample exactly and the findings approximately, because sites and the directory both change.

What changed in the checker because of this

The study was worth running for the corrections alone, because each mistake in the first count was a mistake the public tool would also have made.

Before the full run, the scanner could not recognise a closed plugin at all. WordPress.org answers a closed listing with a 404, and the scanner read every 404 as "not in the directory". That was fixed first, and the pilot run that preceded the fix was discarded.

After the run, the checker took on each stage of the narrowing:

• A closure is only reported when a real asset path sits behind it. A namespace alone never puts a closure on a report.

• Closures marked "Unused" or "Unknown", or with no reason, read as "not in the directory", which carries no penalty.

• A plugin-team closure costs 25 points. A withdrawal by the author costs 12 and is labelled as a withdrawal, because the author may still distribute it. Where the author is confirmed to still be releasing it, it costs nothing and shows as updated elsewhere.

• The tool does not name a plugin as a problem until it has gone 24 months without a release or the plugin team has closed it, and nothing it says claims that nobody maintains a specific plugin.

It still makes no vulnerability claims. Reliable vulnerability data for WordPress plugins sits behind commercial APIs, and a free tool that guesses at it either flags plugins that are fine or stays quiet in a way that implies everything else was checked. Both are worse than saying plainly that no security check was run.

The point of reporting less

It would have been easy to publish 39.6%. It came straight out of the scanner, and every individual match in it looked plausible.

But a plugin report is only useful if you can act on every line of it. One false "this plugin was removed from WordPress.org" sends a developer chasing a problem that does not exist, and after that they stop believing the rest of the page. I would rather tell you about 12 sites I can show you than 99 I cannot.

If you want to know how to read these signals for a single plugin yourself (release dates, "tested up to", the different kinds of closure, support threads and premium plugins), I wrote that up separately in How to Tell If a WordPress Plugin Is Abandoned.

To run the same checks on a site you look after, the WordPress plugin checker is free and needs no signup. For a single plugin, the plugin maintenance check covers widely installed plugins one at a time, with the date each was read from the directory.

And if a plugin your business depends on turns out to be one of the ones nobody is shipping, that is the problem we solve: custom WordPress plugin development, including replacing or taking over a plugin that has been left behind. If you are weighing that up, what a custom plugin actually costs is the place to start.