How many WordPress plugins is too many? A way to audit yours
There is no safe number. What matters is what each plugin loads, who maintains it and whether you use it. A method to audit yours in about an hour.
By Sohail Hussain4 November 20265 min read
There is no safe number. A site with 30 small, well-maintained plugins can be faster and safer than one with eight, if one of the eight is a bloated page builder and another has not been updated in two years. Judge each plugin on four things: what it adds to every page, whether it is still maintained, whether something else already does the same job, and whether anyone uses it. As a guide, a company website rarely needs more than 10 to 15 plugins, and more than 25 on a brochure site almost always means overlap and forgotten experiments.
If you would rather hand the audit to someone, it is part of the first month of our website care and maintenance work. The method below is the one we use, and you can run it yourself.
Why is the plugin count the wrong measure?
Because plugins differ wildly in what they do on each request. Some run only in the admin area: a redirect manager or a backup tool adds nothing to the page a visitor loads. Others add stylesheets, scripts and database queries to every page on the site, whether that page uses them or not.
Quality matters more than quantity. One plugin that runs a slow database query on every page load costs more than ten that do nothing until called. Security risk also sits with individual plugins. Most WordPress vulnerabilities published each year are in plugins, not core, and one out-of-date plugin is enough.
The count does matter in one way. Each plugin is a separate update, a separate vendor and a separate thing that can conflict with the others. Thirty plugins means thirty changelogs to watch. That is a maintenance cost even when the speed cost is zero.
What does each plugin cost you?
| Cost | What to check | Where to look |
|---|---|---|
| Page weight | CSS and JavaScript it loads on pages that do not need them | Browser DevTools, Network tab |
| Server time | Database queries and slow hooks it adds | Query Monitor plugin, on staging |
| Security | Last update, known vulnerabilities, whether it is still listed | The plugin's WordPress.org page, the vendor's changelog |
| Maintenance | How often updates break things, how fast fixes arrive | Support forum, changelog |
| Licence | Yearly renewal fee for premium plugins | Vendor account |
| Lock-in | What happens to your content if you remove it | Shortcodes or custom blocks left in posts |
Lock-in is the one people forget. A plugin that stores content in its own shortcodes leaves [gallery_pro id="12"] scattered across your pages when you remove it. Before installing anything that touches content, ask how you would get rid of it.
To see what the plugins add up to on a page, list each CSS and JavaScript file with its size and total them in our page weight calculator.
How do you audit the plugins you already have?
Set aside an hour and a staging copy of the site.
List everything. The Plugins screen shows each plugin and its version. With WP-CLI, one command also shows whether each is still listed on WordPress.org and when it was last updated there:
wp plugin list --fields=name,status,version,update_version,wporg_status,wporg_last_updated
The available fields are in the plugin list command reference.
Delete what is inactive. Deactivated plugins do not run, but their files stay on the server. If you are not using a plugin, delete it.
Flag what is abandoned. A plugin that has not been updated in a year, or has been closed on WordPress.org, needs a replacement plan. Closed plugins stop receiving fixes, including security fixes.
Find the overlaps. Two SEO plugins. A security plugin, a firewall plugin and the host's own firewall. Three different ways of adding analytics. Keep one of each job.
Check what each one loads. Open three typical pages with DevTools and note which folders under /wp-content/plugins/ appear. A plugin that loads files on pages where it does nothing is a candidate for a setting change, a lighter alternative or removal.
Ask who uses it. Some plugins were installed for a campaign two years ago. If nobody can say why one is there, deactivate it on staging, check the site, and remove it.
Which plugins does a company website actually need?
Most company sites need these, and little else:
| Job | Usually needed? | Notes |
|---|---|---|
| SEO (titles, sitemaps, schema) | Yes | One plugin. Core already makes a basic sitemap; the plugin adds control. |
| Forms | Yes | One form plugin for every form on the site. |
| Page caching | Only if the host does not cache | Never two caching plugins. |
| Backups | Yes, off-site | Host backups alone are not enough. |
| Security or firewall | Usually | Skip it if the host provides a firewall and login protection. |
| Redirects | When URLs change | Often included in the SEO plugin. |
| Custom fields | For structured content | For example Advanced Custom Fields. |
| Multilingual | Only for multilingual sites | One per site. |
That is six to eight. Add the plugins for the site's real features, such as events, bookings or a store, and you reach 10 to 15.
Some jobs do not need a plugin at all. An analytics tag is one line in the theme or a tag manager. Turning off comments is a setting. A site icon is a WordPress setting. Each of these as a plugin is one more thing to update.
When is a plugin better than custom code?
More often than developers admit. A well-maintained plugin with a large user base gets security fixes from a team that knows the code. A custom snippet written by a freelancer three years ago gets fixes from nobody. Replacing a mature forms plugin with custom code just to lower the count is a bad trade.
Custom code wins when the job is small and stable, like registering a post type, adding a header tag or changing a label. It also wins when the only plugin available ships ten features you do not need around the one you do. Put that code in a small site-specific plugin, not the theme's functions.php, so it survives a theme change.
Never use "nulled" (pirated) premium plugins. They are a common source of malware, and they never get updates.
What should you do after the audit?
Turn the result into a short document: each plugin, why it is there, who holds the licence and when it renews. Review it every quarter as part of your monthly WordPress maintenance.
Before adding a new plugin, check four things: the last update date, the number of active installs, whether support questions get answered, and whether a plugin you already have does the job. That habit keeps the list short without anyone having to count.
If removing plugins changes your speed, how to speed up a WordPress site covers what to fix next. For the plugin list we start every build with, see WordPress for business websites.
Was this guide useful?