Half the plugin directory is abandoned

#Introduction

We measured the WordPress.org plugin directory on 10 August 2026. Of 69,286 plugins, 35,696 had received no update for at least two years, which is 51.5 percent. That number is not copied from someone else’s report, because no such report exists. Below is the method, the results at four thresholds, and what follows from them for anyone maintaining other people’s sites.

#In short

• 35,696 of 69,286 plugins with no update in two years, 51.5 percent of the directory.
• 28,146, or 40.6 percent, with no update in five years.
• 20,242, or 29.2 percent, with no update in eight years.
• In a sample of 5,250 abandoned plugins, 5.9 percent have a thousand or more active installs, giving roughly 2,100 such plugins across the tail.
• The figures circulating online, 43.8 percent and 59 percent, have no primary source. I checked both. The truth sits between them.
• The method is documented and repeatable with one command, because a number you cannot check is worth exactly as much as those two.

#Why I measured at all

I set out to write a piece built on the figure of 43.8 percent abandoned plugins. Before using it, I went looking for the source. There is none.

I looked for an alternative and found 59 percent, repeated in many places alongside a figure of roughly 34,000 plugins. It looks sturdier because it comes with an absolute number. I read the piece that introduces it, and there is no attribution there either. The author cites WordPress.org and WPExperts, but for the total plugin count, and offers nothing at all for the abandonment share itself.

This is the ordinary life cycle of a statistic in this industry. Someone publishes a number with no source, the next person cites the first with a link, a third cites the second, and a year later it reads as common knowledge. We adopted a rule on 31 July 2026, after stripping every unsupported figure from our own site. Publishing that number would have broken it outright.

That left one honest route: count.

#The method, so it can be repeated

WordPress.org exposes a public directory API at api.wordpress.org/plugins/info/1.2/. The browse=updated mode returns plugins sorted by last-updated date, newest first.

Because the list is sorted, the answer to “how many plugins are older than two years” is simply the rank of the first plugin older than the cutoff. Finding it does not require downloading the whole directory, only a binary search over the pages. Nine requests instead of seven hundred.

The whole measurement lives in our repository as npm run measure:plugin-abandonment and repeating it takes under a minute. If you read this in six months and the numbers look different, that is not because one of us is wrong. It is because the directory is alive.

#Results at four thresholds

The directory held 69,286 plugins at the time of measurement, and the most recent update was minutes old.

The interesting part is the shape of that distribution, not any single number. Between the two-year and the eight-year threshold only about 15,000 plugins drop out, so most abandoned plugins were not abandoned recently. Nearly three tenths of the entire directory is code nobody has touched in eight years: before Gutenberg, before PHP 7.2, before blocks.

#The number that matters in practice

The share of abandoned plugins is a curiosity on its own. The directory could hold any amount of dead code and harm nobody, as long as nobody runs it.

So I measured a second thing: how many of those abandoned plugins are still running on sites. I took a systematic sample from the tail of the directory, every seventh page of results, 5,250 plugins, and counted active installs.

Carrying the 5.9 percent share across the whole tail gives roughly 2,100 plugins that have had no update in two years and still run on a thousand sites or more each.

That is the number worth remembering instead of the percentage. Two thousand pieces of code, each on at least a thousand sites, each without a maintainer for two years.

To be explicit: this is a sample, not a census. It was taken systematically rather than at random, so if active installs happened to fall into a regular pattern with a period of seven pages, the result would be biased. I see no reason why they would, but I note it rather than pretend I counted all 35,696.

#What this measurement cannot see

Three things the method excludes by design. I list them because without them 51.5 percent would read as more precise than it is.

It cannot see plugins outside the directory. Every premium plugin bought directly from its author or on a marketplace is outside this API and appears in none of the figures above. A typical WooCommerce store runs several, usually the most sensitive ones, because they handle payments, shipping and customer data. Their state has to be checked by hand, one at a time, and that is work no single query replaces.

It cannot see closed plugins. When a plugin is pulled from the directory it disappears from the API, so it lands in neither the numerator nor the denominator. Paradoxically that means plugins closed for security reasons improve the statistic, because they leave the set. The 51.5 percent is a share among plugins still listed.

Active installs are bucketed by WordPress.org, not reported exactly. That is why the table above uses ranges rather than sums. A plugin labelled a thousand installs may have twelve hundred or nineteen hundred, and the directory does not distinguish. That resolution is enough for the conclusion I draw, and would not be enough for anything finer.

#What eight years without an update means concretely

The figure of 20,242 plugins untouched for eight years stays abstract until you recall what WordPress looked like then.

August 2018 is WordPress 4.9. Gutenberg was not yet in core; it arrived that December with 5.0. The block editor, which is how essentially all content is written today, is a future that never arrived for this code. A plugin from that era knows nothing of blocks, of register_block_type, of theme.json, of full site editing.

PHP tells the same story. PHP 7.0 and 7.1 were common then, and plenty of hosting still ran 5.6. Since then came typed properties, named arguments, match expressions, attributes and, most importantly, PHP 8 turned many warnings into fatal errors. Code that emitted a notice to the log in 2018 can take a site down today.

None of this means every such plugin is broken. It means nobody has checked, and the distance between its assumptions and today’s environment is eight years wide.

#What the number does not mean

An abandoned plugin is not automatically vulnerable, and I do not want this piece read as a scare.

A plugin that adds one shortcode and accepts no external input can run for a decade without an update and be entirely safe. A lack of updates can also mean the code is finished, which sounds alien in a world of weekly releases but is genuinely true of small tools.

Risk does not come from age, it comes from attack surface. It rises where a plugin takes user input, registers REST endpoints, handles uploads, builds database queries from parameters, or touches payments and personal data. Age is a multiplier there, not a cause: old file-handling code is dangerous not because it is old, but because PHP and attack techniques moved on and it did not.

There is a mirror to this. A plugin updated weekly can be vulnerable too, and freshly so. The last-update date is a signal about maintenance, not about code quality.

#How to check your own sites in fifteen minutes

Three steps, in this order, none requiring a paid tool.

Build the list. Pull the slugs of every plugin on every site you maintain. One site means the admin panel; dozens means WP-CLI and a loop. The output should be one list, not twenty browser tabs.

Query the directory. For each slug, fetch the last-updated date and the active install count from the API. That is one request per plugin and can be done in bulk. Plugins outside the directory, meaning premium and bespoke ones, will return nothing, and that absence is itself a result: they will never appear in any listing like this, and they are usually the ones touching payments.

Sort by risk, not by date. A date column on its own says nothing. What you want is the intersection of three things: long unmaintained, touches data or payments, hard to disable without hurting the client. A plugin meeting all three is this week’s work, not someday’s.

While you have the list open, add a column for which plugin can be switched off for an hour without consequence. That information is priceless on the day of an incident, and gathering it then is the worst possible moment.

#What to do when a plugin really is abandoned

In order from cheapest to most expensive, because the first option resolves more cases than people expect.

Check whether it is still needed. A large share of abandoned plugins on client sites do something nobody uses any more: a form from a campaign three years ago, an integration with a service that shut down, a widget in a footer that was rebuilt. Removal is then a complete fix and takes a minute.

Check whether core does it now. WordPress has absorbed a good deal of what once needed a plugin: lazy loading, WebP handling, parts of block work, XML sitemaps. A plugin from 2017 is often simply redundant.

Look for a maintained replacement. Judge it by release cadence and whether the author answers in the support forum, not by install count. A plugin with a million installs and its last release a year ago is a worse bet than one with five thousand and a release last month.

Rewrite it yourself if the feature is small. A plugin that does one thing in fifty lines more often belongs as fifty lines in your own functionality plugin than as a dependency on someone who vanished. That is real work, but it ends the problem rather than passing it to the next maintainer.

Keep it and watch it, deliberately. Sometimes there is no replacement and rewriting is too expensive. That is a legitimate decision, provided it is written down: who made it, when, and what happens when a CVE appears. The difference between technical debt and mess is that debt is documented.

#Three cases from practice, one per decision

To keep this off the level of principles, three typical situations that lead to three different conclusions.

A gallery plugin, last updated five years ago, around a thousand installs, used on one page. The check takes a minute: does core do this already. Block galleries today handle layouts, lightbox and responsive images, so the answer is usually yes. The cheapest route, removing it and moving the content into a block, ends the matter without hunting for a replacement.

A forms plugin, last updated three years ago, tens of thousands of installs, handling the contact form and newsletter signup. Here age matters, because a form takes external input and writes it to the database, exactly the surface that ages worst. The large install count is not reassuring, it is the opposite: it makes the plugin an attractive target. This is a candidate for replacement with a maintained equivalent, migrating stored submissions, and that is half a day’s work rather than a minute’s.

A courier integration, last updated two years ago, a few hundred installs, no replacement, wired into checkout. The hardest case, because it cannot be switched off and has no substitute. The only honest decision is to keep it and write it down: who decided, when, what happens on a CVE, and who checks quarterly whether the author came back. Without that record, in a year nobody will remember it was a decision rather than an oversight.

The common thread is that the last-update date is never a conclusion by itself. It is an input to a discussion that also weighs attack surface, the cost of switching off, and whether a replacement exists.

#Why this will not fix itself

The directory has no mechanism that removes a plugin merely for going unupdated, and that is right, because such a mechanism would also delete code that is finished and working. It does have a mechanism for closing plugins on security grounds, and that one works.

The problem is that both facts together produce a landscape where the default state of a plugin is persistence. The author stops replying, the plugin stays. Installs decline slowly, because sites rarely remove anything. Eight years on, there are twenty thousand plugins in the directory with nobody on the other side.

Add the figure Patchstack reports in State of WordPress Security in 2026: 46 percent of vulnerabilities had no patch at the moment of public disclosure. With a maintained plugin, a missing patch is a matter of hours or days. With an abandoned one there will never be a patch, because there is nobody to write it.

I am not going to end with an appeal to the directory, because the directory is not the main actor here. The only party that can do anything about an abandoned plugin on a specific site is the person maintaining that site.

#How this relates to the six-hour hold

A few days ago I wrote about the Protect the Shire initiative, which holds every new plugin release for up to six hours so an automated reviewer can look at what is about to reach auto-updates. Setting that piece against this measurement gives a conclusion neither yields alone.

The hold protects against a malicious release. For it to work at all, there has to be a release. Its entire value therefore applies to plugins somebody still ships, which is the half of the directory that has a maintainer.

The other half, the one measured here, sits outside that mechanism completely. A plugin untouched for eight years will not ship a malicious release, but it will not ship a patch either. There is nothing to hold, because nothing is coming. The risk moves from what arrives to what is already installed.

These are two different problems that share a word in their name, and it is worth not confusing them. The first is the directory’s to solve, and it is solving it. The second the directory cannot solve, because the solution is somebody looking at a specific site and deciding about a specific plugin.

#Repeat the measurement yourself

The script is public in our repository and runs with one command. It queries only the public WordPress.org API, needs no key, and makes fewer than fifty requests for the entire measurement.

If you get a different answer than I did, write in. I would rather be corrected with a number than cited without checking, because the failure to check is exactly where the 43.8 and the 59 percent I started from came from.

#Sources

• WordPress.org plugin directory API, browse=updated mode, measured 10 August 2026
• Patchstack, State of WordPress Security in 2026, 25 February 2026

Last verified: 10 August 2026.