The WordPress Plugin Reliability Problem Nobody Talks About

It’s 8pm on a Friday. A client texts: “The site is down.” You log in, and the plugin you updated three weeks ago — the one that’s been quietly handling forms on a dozen sites for a year — just shipped a release that breaks under PHP 8.2. You roll back, you patch, you apologize. By 11pm the site is up again. And the question that won’t leave your head all weekend is the one nobody trains us to answer: could you have predicted this?

The hidden cost of “free” plugins

WordPress.org hosts more than 60,000 plugins. Most agency developers pick from maybe fifty they’ve grown to trust. But “trust” here is mostly a mix of memory, word of mouth, and the inertia of “we used it last time and it worked.” It’s not data, and it’s not systematic. Which means a plugin can quietly degrade for months before anyone notices.

The failure modes are predictable once you start looking for them. Abandoned plugins — last updated two or three years ago — quietly break with each WordPress core release until something snaps. Plugins with known security vulnerabilities sit unpatched in the public Wordfence database for months while site owners have no idea. A plugin you trusted gets sold to a new owner whose priorities are different, or whose intentions are worse: ad injection, data harvesting, an SEO link farm built on the back of your client’s site.

Premium plugins are not automatically better. A CodeCanyon plugin with no public changelog and no vulnerability tracking is, in many ways, less inspectable than a free wordpress.org plugin. You paid for it, so you assume someone is maintaining it. Often, somebody is. Sometimes nobody is. There’s no way to tell from the marketplace listing.

Why this stays invisible

Agencies don’t have time to audit plugin quality per site. If you manage thirty client sites and each has thirty plugins, that’s nine hundred plugin-installations to evaluate. Even a fast audit — five minutes per plugin — is seventy-five hours of work. So it doesn’t happen. Plugins get installed, sites get launched, and the audit becomes “we’ll check it when something breaks.”

Site owners are further removed. Most clients can’t tell you what plugins are installed on their own site, let alone whether those plugins are maintained. They trust their agency. The agency trusts their memory. The memory was formed two years ago when the plugin was actively maintained.

WordPress.org itself doesn’t surface reliability signals prominently. You can see “last updated” and “tested with,” but those numbers are easy to skim past on a plugin page, and they don’t combine into a single legible measure. There’s no equivalent to a credit score for a plugin. The result is an ecosystem where everyone is depending on plugins without a systematic way to evaluate them.

What the data actually looks like

Once you start looking systematically, the pattern is striking. In our own sampling of widely-installed plugins on wordpress.org, roughly one in five has not been updated in twelve months. A meaningful slice of plugins in everyday use have an open vulnerability listed in public databases. A non-trivial number have changed hands at least once, and a smaller but real subset have shown up in compromise reports after an ownership change.

These aren’t doomsday numbers. Most plugins work fine. But “most” isn’t the same as “the one you just installed on a client site.” The whole point of measurement is to distinguish the safe majority from the risky minority before they collide with your roadmap.

What changes when you measure it

Once you have plugin reliability data attached to every site you manage, the work changes shape. Onboarding a new client stops being a gut-feel exercise and becomes a triage: which plugins are healthy, which are tolerable, which need to go in the first month. Retainer conversations get easier because you have something to point at — “we replaced four high-risk plugins this quarter” is a real artifact, not a vibe. Site monitoring gets a new dimension: you can be alerted when a plugin’s score drops, not just when the site goes down.

Most importantly, plugin reliability becomes a thing you can defend. When a client asks why you recommended one form plugin over another, “this one has a track record of timely security patches and the other has been abandoned” is a better answer than “I’ve used it before.”

A note on what we built

We built SteadyScore because we needed this measurement layer for our own agency work and couldn’t find it anywhere else. It scores every plugin on a site against update frequency, vulnerability history, install base, ratings, and a handful of other signals, and rolls the result into a single 0–100 number with categories you can read at a glance. But the post you’re reading isn’t really about the tool. It’s about the gap the tool fills.

The measurement gap

Plugin reliability has been one of the least-measured aspects of WordPress for a long time. Hosting reliability is measured. Page speed is measured. Security threats are measured. Plugin health, the thing that most often breaks client sites, has been left to memory and good intentions. The agencies that start measuring it will be the ones whose clients trust them more — not because they say “trust us,” but because they can show their work.