Keeping a WordPress site maintainable without plugin sprawl

Every plugin is a dependency on someone else’s release schedule, security posture and continued interest. Thirty of them is a supply chain, and nobody signed a contract for it. The installs we inherit are all the same shape: built five years ago by someone competent, extended a dozen times by people solving one problem each, now at thirty-four active plugins nobody can safely remove because nobody knows what any of them still do.

Count is the wrong metric

“Use fewer plugins” is not actionable, and taken literally it produces bad decisions. People remove three small well-maintained plugins and keep the abandoned one holding the site together.

Each plugin carries three liabilities that are not correlated with each other: security surface, maintenance surface, and runtime cost. A plugin with two million installs is a large runtime cost and a small maintenance liability. A forty-line plugin last touched in 2019 is the reverse. Auditing on count treats them identically.

What the vulnerability data says

Patchstack recorded 11,334 new WordPress vulnerabilities across 2025, up 42% year on year. 91% were in plugins and six were in core. 46% had no patch available at the point of disclosure, and the weighted median time to mass exploitation was five hours, so keeping everything updated is necessary and not sufficient. Wordfence, counting differently, found 58% of its 2024 vulnerabilities in software with under 10,000 installs. The totals are not comparable, but the shape is: risk sits in plugins, and disproportionately in small ones.

Abandonment is the quiet failure

We walked the full wordpress.org directory in September 2026, all 71,581 plugins, reading each one’s last update date. Half have not been touched in two years. That figure is dominated by plugins nobody installed, so the useful cut is by install count: 33% of plugins with 100 or more installs are two years stale, 18.5% at 1,000, 7.8% at 10,000, 1.9% at 100,000.

WordPress also will not tell you when a plugin is closed. Closure stops the directory generating downloads and does nothing else. No admin notice, no Site Health warning. The info API reports the closure with a date and a reason, but the update-check API that core actually calls returns an empty response, so core renders the plugin as current. The Trac ticket asking for a dashboard alert was opened in November 2014 and is still open.

Closure is common and not always about security. During one Patchstack bug bounty event in October 2024 that targeted abandoned plugins, 977 plugins were closed, covering 7.1 million active installs, and in roughly 75% of cases the developer could not be contacted.

The audit we run

One row per active plugin, six columns, an afternoon of work.

• What it does, in one sentence, in the client’s words. If nobody can write that sentence, that is the finding.
• Active installs and last update date, from the directory rather than wp-admin.
• Is it still in the directory? Query the info API by slug. Nothing in WordPress does this check for you.
• Is it premium? Premium and freemium plugins were 29% of Patchstack’s 2025 reports but 76% of the exploitable ones, and no directory signal applies.
• What breaks if it is removed: content, settings, or nothing.
• Could this be twenty lines of code?

The last column produces most of the reduction, with one caveat: twenty lines you own beats a plugin you do not, but only if someone still understands those twenty lines in three years.

Put the install in version control

Composer changes how a site ages more than anything else here. Core, plugins and themes become dependencies, the lock file goes in Git, and DISALLOW_FILE_MODS in production means nobody installs a plugin through wp-admin on the live site again.

The reason to pin your update source and not just your version numbers is Advanced Custom Fields. In October 2024 the WordPress security team forked it into Secure Custom Fields, and the directory slug now serves a different codebase. Anything resolving that slug, wp-admin auto-updates included, switched projects without asking.

What we would not remove

Keep the well-maintained plugin with a large install base doing something genuinely hard. Nobody should be writing their own forms handling, SEO metadata layer or e-commerce, and a bespoke version maintained by nobody is the larger liability. Keep anything you cannot confidently explain until you can: the expensive outcome of an audit is the plugin removed by someone who did not understand it, discovered eleven days later.

The target is a site where, in two years, someone who has never seen it can answer three questions in an hour: what is installed, why, and how to change it safely. None of that reduces the plugin count. It changes what the count costs.