A WordPress plugin audit is a structured review of every installed plugin: what it does, whether another plugin already does it, whether it is maintained, whether it has had security issues, and what it costs in load time. The goal is a shorter, safer list of plugins you understand.
Most slow or hacked WordPress sites I am asked to fix have the same story: plugins added over years, each for a good reason, and none ever removed. This is the audit I run.
Why audit plugins at all?
Plugins are code from different authors running with full access to your site. Each one can add database queries, scripts, styles, cron jobs and admin notices. Unmaintained plugins are a common entry point for attacks, and overlapping plugins create conflicts that are hard to debug. An audit turns an accumulated mess back into deliberate choices.
Step 1: take a backup and work on staging
Before you touch anything, take a full backup of files and database, and if possible clone the site to staging. With WP-CLI:
wp db export ~/backups/pre-audit.sql
wp plugin list --fields=name,status,version,update --format=csv > plugins.csv
More useful commands are in my WP-CLI commands guide.
Step 2: build the inventory
For each plugin, add these columns to the spreadsheet:
| Column | What to record |
|---|---|
| Purpose | One sentence: why is it installed? |
| Used where | Front end, admin only, specific pages |
| Overlaps with | Other plugins doing similar things |
| Last updated | Date of the last release |
| Tested up to | WordPress version it declares |
| Active installs | From WordPress.org, as a rough signal |
| Security history | Known vulnerabilities and whether they were fixed |
| Licence | Free, premium, expired licence? |
If nobody can explain why a plugin exists, mark it for investigation.
Step 3: find overlap
Common overlaps I see:
- Two SEO plugins, or an SEO plugin plus a separate schema plugin plus a theme that also outputs schema.
- A caching plugin plus a host cache plus an optimisation plugin all minifying CSS.
- Several form plugins, each with its own scripts.
- Page builder add-on packs where only one widget is used.
- Security plugins doing the same firewall job as the host or Cloudflare.
Overlap is where conflicts and duplicate output come from. Duplicate structured data is a classic example; see schema markup.
Step 4: check maintenance and security
- Last updated more than a year ago? Treat it as a risk and look for an alternative.
- Closed on WordPress.org? Plugins can be closed for security or guideline reasons; find out why.
- Known vulnerabilities? Check vulnerability databases such as WPScan, Patchstack or Wordfence Intelligence, and confirm you run a fixed version.
- Nulled premium plugins? Remove them immediately. Pirated plugins are a well-known malware source.
Step 5: measure performance cost
Tools I use:
- Query Monitor to see database queries, hooks and HTTP calls per page, grouped by plugin.
- Browser DevTools network tab to list scripts and styles each plugin adds to the front end.
- Lighthouse before and after deactivating a suspect plugin on staging.
Look especially for plugins that load scripts on every page when they are only needed on one (sliders, forms, maps). Many slow Total Blocking Time problems trace back to this.
Step 6: decide for each plugin
Each plugin gets one of four outcomes:
- Keep – needed, maintained, reasonable cost.
- Configure – needed, but loading too much; restrict it to the pages that need it.
- Replace – needed function, but a better maintained or lighter option exists, or a few lines of code in a child theme or a small custom plugin will do.
- Remove – not needed.
Step 7: remove safely
- Change one plugin at a time on staging, then test.
- Read the plugin’s uninstall behaviour; some delete their data, which is good for cleanup but bad if you might need it.
- Check that shortcodes from the plugin are not left in content, showing as raw text.
- After deactivation, delete it. Deactivated code is still on disk.
- Check for leftover database tables or options if the plugin was large.
wp plugin deactivate old-slider
# test the site, then:
wp plugin delete old-slider
Step 8: test the critical paths
- Home, key landing pages, blog post.
- Forms send and arrive.
- For stores: add to cart, checkout with each payment method, order emails.
- Logged-in admin tasks the client actually does.
Step 9: document
Write a short plugins.md or a note in the admin: each plugin and why it is there. The next audit takes minutes instead of hours.
Audit checklist
- Backup and staging ready
- Inventory with purpose for every plugin
- Overlaps identified
- Maintenance and vulnerability status checked
- Performance cost measured
- Keep / configure / replace / remove decided
- Changes applied one at a time and tested
- Unused plugins deleted, not just deactivated
- Document saved
Common mistakes
- Removing plugins on the live site during business hours.
- Judging by plugin count instead of impact.
- Replacing a maintained plugin with custom code nobody will maintain.
- Forgetting must-use plugins in
wp-content/mu-plugins, which do not appear in the normal list.
How many plugins is too many?
There is no magic number. A site with forty well-maintained plugins can be faster and safer than one with eight badly written ones. What matters is what each plugin loads, how often it is updated and whether it duplicates something else. WordPress’s own guidance on optimisation points to reviewing plugins and removing ones you do not need as a basic step (WordPress Advanced Administration: Optimization). In practice, I judge a plugin on four questions: Is it used? Is it maintained? Is it the best tool for the job? What does it cost on every page?
A scoring sheet you can reuse
| Criterion | Green | Amber | Red |
|---|---|---|---|
| Last update | Within 6 months | 6–12 months | Over a year, or closed on WordPress.org |
| Tested with current WordPress | Yes | One major version behind | Several versions behind |
| Known vulnerabilities | None open | Fixed in a newer version you have not installed | Unpatched |
| Front-end assets | Only on pages that use it | Site-wide but small | Heavy scripts on every page |
| Business need | Critical | Nice to have | Nobody knows why it is there |
The “Tested up to” and “Last updated” fields come straight from each plugin’s WordPress.org page. A plugin that has been closed in the directory shows a notice there, and that alone is a reason to replace it (WordPress Plugin Directory). For vulnerability information, the major WordPress security vendors publish free databases; use one consistently rather than guessing.
Tools that speed up the audit
- WP-CLI for the inventory:
wp plugin list --fields=name,status,version,update,auto_updateexports everything in seconds. See the WP-CLI commands guide. - Query Monitor on staging to see database queries, hooks and HTTP calls per plugin on a given page (Query Monitor on WordPress.org).
- Browser DevTools coverage and network panels to spot CSS and JavaScript files loaded by plugins on pages where they are not used.
- Site Health for inactive plugins, outdated PHP and loopback problems (WordPress: Site Health).
What a typical audit finds
On client sites in Egypt and the Gulf, the same patterns come up again and again:
- Two or three plugins doing the same job: two SEO plugins, two caching plugins, a slider plugin and a page builder slider.
- A heavy page builder used for one landing page that could be rebuilt with the block editor.
- Nulled or “free premium” plugins downloaded from unofficial sites. These are a serious security risk and should be replaced with licensed copies immediately.
- Contact form, chat and popup plugins loading scripts on every page, including checkout.
- Old plugins from a previous developer that are deactivated but still on the server, where vulnerable files can still be reached.
Agree a policy with the client
An audit fixes today’s problems; a policy stops them coming back. I agree a simple rule set with the business: who may install plugins, a short approved list, licences owned by the business, and a monthly update window with a backup first. Pair it with the security checklist and a quarterly re-audit, which on a well-kept site takes under an hour.
A plugin audit is one of the cheapest ways to make a site faster and safer. It pairs naturally with the WordPress security checklist. If you would like me to run one on your site, contact me.
Frequently asked questions
How many plugins is too many?
There is no safe number. One badly written plugin can slow a site more than twenty lean ones. Judge plugins by what they load, how well they are maintained and whether you need them.
Are deactivated plugins a security risk?
Their files remain on the server and can still be reachable in some cases, so outdated deactivated plugins are a risk. Delete plugins you do not use.
How often should I audit plugins?
A light review every few months and a deeper audit before major changes, such as a redesign, migration or major WooCommerce update, works well for most sites.
