Why “unlimited plugins” is the wrong goal
Plugins are how WordPress gets things done, so the instinct is to install one for every need. But every plugin you add is code that runs on your site, scripts that load in your visitors’ browsers, and a potential door for attackers. The numbers are blunt: Patchstack’s State of WordPress Security in 2025 found 96% of newly disclosed WordPress vulnerabilities were in plugins — and 7,966 new vulnerabilities were disclosed across the ecosystem in 2024, roughly 22 every day.
So a plugin audit is not housekeeping for its own sake. It is risk reduction. Fewer plugins means fewer things to patch, fewer conflicts when WordPress or PHP updates, and fewer scripts dragging down responsiveness on the pages where customers act.
The audit framework: sort by what each plugin protects
Start by sorting every plugin into one of three buckets based on what it actually does for the business. This instantly separates the plugins worth keeping and watching closely from the ones quietly adding risk for little return.
- Revenue-critical: checkout, payment gateways, forms, bookings, subscriptions, analytics, core SEO.
- Trust-critical: security, backups, redirects, accessibility, privacy/consent.
- Nice-to-have: visual flourishes, small conveniences, duplicate page builders, old campaign or popup plugins.
What to check for each plugin
Within each bucket, every plugin should earn its place. Run each one through these questions, and be honest about the nice-to-haves.
- Is it actively maintained, with recent updates and compatibility for your WordPress version?
- Does another plugin — or WordPress itself — already do the same job?
- Does it load scripts or styles on every page, even pages that never use it?
- Would removing it actually break a customer path, or just remove a feature nobody uses?
- Is there a simpler native WordPress, theme, or hosting-level option instead?
Why this improves both speed and safety
Plugin cleanup is one of the highest-leverage maintenance tasks because it simplifies everything that comes after it. Fewer plugins means a smaller attack surface (the core of any security hardening checklist), fewer update conflicts, less admin confusion, and lighter pages that respond faster (better INP). It is far easier to keep ten well-chosen plugins patched and tested than to babysit forty — and the security data says the plugins are exactly where the risk lives.
Keep, replace, or remove? A decision matrix
Once a plugin is sorted into a bucket, this is how to decide its fate.
| Situation | Verdict | Why |
|---|---|---|
| Maintained + used + no overlap | Keep and monitor | It earns its place; just keep it updated and tested. |
| Two plugins doing the same job | Consolidate to one | Overlap doubles the attack surface and the conflict risk. |
| Abandoned (no recent updates) | Replace urgently | Unpatched plugins are the top WordPress vulnerability source. |
| Feature now native to WordPress/theme | Remove | Native code is fewer moving parts to maintain. |
| Installed but deactivated | Delete, don’t just deactivate | Deactivated plugin files can still be exploited if left on the server. |
Plugin-audit mistakes that bite later
- Counting plugins instead of judging them — a low number of abandoned plugins is worse than more well-maintained ones.
- Deactivating risky plugins but leaving the files installed, where they can still be exploited.
- Deleting a plugin live without a backup or staging test, then discovering it powered a customer path.
- Keeping a second page builder or popup plugin “just in case,” doubling the script weight.
- Auditing once and never again — new plugins and abandoned ones accumulate constantly.
How we run plugin audits on managed sites
On the sites we manage under a WordPress care plan, the plugin list is something we keep deliberately small and deliberately current, because it is the cheapest insurance against the most common WordPress incident. The rule of thumb: if a plugin is not maintained, not used, or duplicated, it goes — after a backup and a staging check, never as a live guess.
- Back up and test plugin removals on staging before touching the live site.
- Delete deactivated plugins rather than leaving dormant code on the server.
- Prioritise replacing any abandoned plugin, since unpatched plugins are the biggest risk.
- Re-audit on a schedule so the list does not silently grow back.
Frequently asked questions.
How many WordPress plugins is too many?
There is no magic number. Ten poorly maintained plugins can be far riskier than thirty well-maintained ones. Judge by quality, overlap, maintenance status, and genuine business need — not the count.
Should I delete inactive plugins?
Yes, after confirming they are not needed. Deactivating a plugin leaves its files on the server, where a known vulnerability can still be exploited. Deleting unused plugins removes that risk entirely.
Are plugins really the main WordPress security risk?
Yes. Patchstack’s 2025 report found 96% of newly disclosed WordPress vulnerabilities were in plugins, versus 4% in themes and under 1% in core. Keeping plugins few, current, and maintained is the highest-impact security habit.
Will removing plugins speed up my site?
Often, yes — especially if you remove plugins that load scripts on every page. But speed gains come from cutting the heavy, script-laden plugins specifically, not just lowering the number, so audit by impact.
Research sources.
This guide was checked against current platform and search documentation before publication.