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.
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.
