How many WordPress plugins is too many has no fixed number. A site running 40 well-built, maintained plugins can be faster and safer than one running 10 abandoned ones. Too many is any plugin you cannot name a job for, an owner for, or a recent update for.
The short answer
- WordPress sets no plugin limit. What slows or endangers a site is what each plugin does, not how many there are.
- Aim for one clearly owned solution per job. Remove unnecessary overlap, but check add-ons and dependencies before assuming that two related plugins are duplicates.
- Plugins carry most of the security risk in WordPress: 91% of new vulnerabilities found in 2025 were in plugins.
- Deactivated plugins still sit on your server, so remove what you do not use rather than switching it off.
Is there a maximum number of WordPress plugins?
There is no maximum number of WordPress plugins. WordPress itself sets no limit, and the old rules of thumb, such as “never more than 20” or “under 10 on shared hosting”, are rules of thumb, not limits. The real ceiling depends on how heavy each plugin is, how well it is coded and how much server capacity your hosting provides.
A plugin that adds one admin setting costs almost nothing. A plugin that loads scripts on every page, runs database queries on every request or schedules heavy background jobs can cost more than ten small plugins combined. Count tells you very little. Weight, overlap and maintenance tell you a lot.
Before removing a plugin, I want its job and dependencies written down. A form plugin can have add-ons, a template can depend on a shortcode, and a deployment may move code without changing which plugins are active. My team uses the WPO framework to turn that inventory into a tested change list. Record the activation, settings and removal steps for each environment, then verify them after release. Deleting a folder on a development copy is not a production clean-up.
After more than 20 years building on the web, I have stopped asking “how many?” and started asking three questions of every plugin. What job does it do? Who updates it? When was the plugin itself last updated by its developer? If any answer is blank, the plugin is a candidate for removal.
Why do too many WordPress plugins cause problems?
Too many WordPress plugins cause problems in four ways: slower pages, a larger security attack surface, conflicts between plugins that overlap, and an update workload nobody owns. Each extra plugin adds code to load, code to patch and code that can clash with a WordPress, PHP or theme update. The risk compounds with every unneeded addition.
Security is the part most owners underestimate. Patchstack’s State of WordPress Security in 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025. 91% were in plugins, 9% in themes, and only 6 were in WordPress core. 46% had no developer fix when they were publicly disclosed. For the subset of most heavily exploited vulnerabilities, Patchstack reports a weighted median of 5 hours from its protection rule going live to the first exploit attempt. That is the worst slice, not every bug, but it is the slice that matters when it lands on your plugin. Patchstack sells security services, so treat it as a vendor report, but every plugin you remove is one fewer item on that list.
Updates are the other half. Since WordPress 5.5, administrators can switch on automatic updates plugin by plugin. That helps with security, but uncontrolled auto-updates on a busy store are a gamble. At WP Creative we worked with an offroad gear retailer whose WooCommerce store was unstable, with security alerts and plugin auto-updates running unchecked. As part of a 60-day stabilisation sprint, auto-updates were switched off in favour of a controlled staging workflow. For a tile retailer on a care plan, the same routine meant a security vulnerability in its caching plugin was patched through a scheduled maintenance update.
Staging-first has one exception. When a plugin you run has a vulnerability that is being actively exploited, speed beats ceremony. If a patched version exists, take a backup, apply it to the live site the same day, check checkout and forms, then finish the full tests. If there is no patch yet, deactivate and remove the plugin, or block the vulnerable path with a firewall rule, until a fix ships. Ordinary updates go through staging; emergencies need a same-day path agreed in advance.
What are the signs your site has too many plugins?
The signs your site has too many plugins are practical, not numerical: pages getting slower with no new content, plugins nobody can explain, two plugins doing one job, frequent conflicts after updates, and plugins that have not been updated by their developers in over a year. Any two of these together justify a full plugin audit.
Signs your site has too many plugins:
- Page speed has drifted down over months while the content barely changed. Check with the tools in my list of free website speed testing tools.
- The plugins screen lists plugins nobody on your team can explain.
- Two plugins do the same job: two SEO plugins, two caching plugins, two page builders or two form builders.
- Updates regularly break something, so updates get delayed.
- Site Health under Tools lists inactive plugins.
- Some plugins have not been updated by their developer in over a year, or show “This plugin has been closed” on WordPress.org.
- Premium plugins came from somewhere other than the developer’s own site or WordPress.org.
- The admin area is slow even though visitor pages are cached.
How do you audit and remove WordPress plugins safely?
Auditing WordPress plugins safely means working on a staging copy with a fresh backup, listing every plugin with its job and owner, then deciding to keep, replace or remove each one. Remove plugins one at a time, test key pages and forms after each removal, and only then repeat the change on the live site.
| Finding | Decision | What to check first |
|---|---|---|
| Clear job, updated in the last few months, no overlap | Keep | Who owns its updates and licence renewal |
| Two plugins doing the same job | Keep the stronger one, remove the other | Settings, redirects or data the weaker plugin created |
| Does one small task, such as adding a tracking code | Replace with a few lines of code in a child theme or snippet manager | Whether a developer will maintain that code |
| Deactivated and not needed | Remove | Whether it left database tables or scheduled tasks behind |
| Closed on WordPress.org or not updated in over a year | Replace | A maintained alternative and a migration plan |
| Heavy front-end scripts on pages that do not use them | Keep, but limit where it loads, or replace | Speed before and after on key templates |
To find the heavy plugins, Query Monitor shows the database queries, scripts and errors each plugin adds on a page. Take a full WordPress backup before you remove anything, because some plugins delete their data on uninstall. If your pages only feel fast because of caching, my guide to WordPress caching explains what it does and does not cover.
This is ordinary maintenance work, the kind a WordPress care plan covers, and it pays off. For Tile Factory Outlet, a high-volume tile retailer, my team at WP Creative cleaned up the backend, removed unused plugins and optimised speed as part of a bi-weekly care plan. Quote requests rose 75.1% in the first six months of that plan, compared with the year before, a result of the whole programme rather than plugin removal alone. For Bidfood Australia, a national food distributor running a heavy Elementor build, trimming the plugin stack was one part of a performance rebuild that got all three Core Web Vitals passing on mobile and desktop, measured on real visitor data.
Should you use a plugin or custom code?
Use custom code instead of a plugin when the job is small and stable, such as adding a tracking script or a single redirect, and a developer will maintain it. Use a plugin when the job is complex, changes often or needs a settings screen your team will use. Custom code removes a plugin but still needs an owner.
Tracking codes are the classic example. You do not need a plugin purely to paste an analytics tag into the page header. On the other hand, replacing a well-maintained SEO or form plugin with home-grown code usually creates a bigger maintenance problem than it solves. If you are deciding which marketing plugins deserve a place at all, my list of WordPress marketing plugins works on the same one-plugin-per-job rule.
Moving a small feature into custom code does not make it automatically safer or faster. That code still needs an owner, review and a tested way to deploy and reverse changes. Check consent handling before moving an analytics tag, and keep business functionality in a maintained plugin where practical so a design/theme change does not silently remove it.
Do inactive plugins slow down or endanger your site?
Inactive plugins do not slow down your pages, because WordPress does not load a deactivated plugin’s code on normal requests. They can still endanger your site. The files remain on the server, they stop getting attention, and an attacker may be able to reach vulnerable files directly. Delete inactive plugins you do not plan to use.
WordPress agrees. The Site Health check built into core flags inactive plugins, and its source code carries the warning that inactive plugins are tempting targets for attackers. My team received a vulnerability notice for a disabled but still installed SEO plugin on a membership organisation’s site. Deactivated is not removed. Make deletion part of your regular WordPress maintenance.
What to do next
- Open Tools, then Site Health, and note any inactive plugins or outdated plugin warnings.
- Export your plugin list and write the job, owner and last developer update beside each one.
- Take a backup, then run the keep, replace or remove table on a staging copy.
- Move updates to a staging-first routine instead of unchecked auto-updates on revenue-critical sites, with a same-day path agreed for actively exploited vulnerabilities.
- If you want a second opinion on your plugin stack, book a free call with me and my team.
Frequently asked questions
Is 20 plugins too many for WordPress?
Not necessarily. Twenty lightweight, maintained plugins with distinct jobs can run well on decent hosting. Twenty plugins that include duplicates, abandoned code or heavy front-end scripts will not. Judge each plugin on its job, its weight and its update history rather than measuring the site against a round number.
How many plugins does a typical WooCommerce store need?
A WooCommerce store needs more plugins than a brochure site because payments, shipping, tax and marketing feeds each add a job. There is no typical number worth quoting. Apply the same rule: one maintained plugin per job, tested on staging before updates, with a named owner for every payment and shipping integration.
Does deleting a plugin remove its data?
It depends on the plugin. Some delete their settings and database tables when you uninstall them, and others leave everything behind in case you reinstall. Check the plugin’s documentation, take a backup first, and look for leftover tables or scheduled tasks after deletion if you want a fully clean database.
Should I turn on automatic plugin updates?
For a small brochure site with simple plugins, automatic updates are usually safer than no updates at all. For a store or a site with integrations that earn revenue, run updates through a staging copy first, then apply them to the live site within days. The exception is a vulnerability under active exploitation: patch the live site the same day, or remove the plugin until a fix exists, because the worst vulnerabilities are attacked within hours of disclosure.
Can caching fix a site with too many plugins?
Caching hides some of the cost for visitors by serving saved copies of pages, but it does not fix the admin area, logged-in users, checkout pages or the security risk of extra plugins. Use caching as well as a plugin clean-up, not instead of one. Caching is one layer of performance, never a substitute for a lean plugin stack.
