Most WordPress sites don’t get slow and vulnerable all at once. They get there one plugin at a time — a contact form here, a slider there, a “just try it” analytics add-on that never got removed, an SEO tool you replaced but never deleted. Two years later you’re running forty plugins, half of them haven’t been updated since the last presidential election, and nobody remembers what three of them actually do.
That pile isn’t harmless. Every active plugin runs its own PHP on every page load, and every plugin still sitting on disk is code an attacker can probe. The last cleanup we did started exactly here: an abandoned plugin nobody had touched in years, a known hole in it, and an IndoXploit webshell dropped through it that was quietly serving spam pages to Google. The owner’s plugin list looked “normal.” It was also the front door.
A plugin audit is the unglamorous habit that prevents that story. You don’t need a tool or a subscription — just an afternoon, a short checklist, and the willingness to actually delete things. Here’s how to do it properly.
Why Plugin Count Is a Performance Tax
A plugin isn’t a feature you switch on and forget. It’s live code that WordPress loads and executes on requests, and the cost compounds as the list grows.
Every active plugin runs on every request
When someone loads a page, WordPress reads its list of active plugins and includes each one’s main file, wiring up whatever hooks, filters, and admin screens it registers. A well-written plugin adds a millisecond or two. A heavy one loads its own CSS and JavaScript on every page — even pages that don’t use it — fires extra database queries, and phones home to a licensing server. Forty of those, and the overhead stops being theoretical.
The autoloaded-options trap
Here’s the part people miss. Many plugins store settings in the wp_options table with the autoload flag set to “yes,” which means WordPress loads that data into memory on every single request, whether the page needs it or not. Deactivate a sloppy plugin and its autoloaded rows often stay behind. Do that a dozen times and your autoloaded options balloon.
WordPress core noticed this problem too. Since version 6.6 (July 2024), the built-in Site Health tool flags your autoloaded options as an issue once they cross 800KB, because that bloat measurably slows things down. If you’ve never checked that number, it’s often the cheapest speed win on the whole site.
Conflicts and duplicated work
Run two caching plugins, or two SEO plugins, and they don’t cooperate — they fight. You get duplicated schema markup, conflicting rewrite rules, and mystery bugs that only appear when a specific pair is active. Even without a hard conflict, three plugins that each load their own copy of a JavaScript library are three times the download for one job.
Plugins are the single largest source of WordPress security problems. According to security firm Patchstack, the overwhelming majority of newly disclosed WordPress vulnerabilities each year are found in plugins — not in WordPress core. Every plugin you keep installed is code that can carry the next disclosed hole, so a shorter list is a smaller target.
Every Plugin Is Attack Surface
Performance is the reason people start an audit. Security is the reason it matters. A plugin is a piece of third-party software running with deep access to your site, and you’re trusting its author to keep it patched and free of holes.
Abandoned plugins are the real danger
The scariest plugin on most sites isn’t a badly-written one — it’s an unmaintained one. When an author stops shipping updates, any vulnerability discovered later never gets fixed. Attackers scan the web for exactly these known-vulnerable, abandoned plugins because they’re reliable ways in. WordPress.org even shows a warning when a plugin hasn’t been tested against recent releases, which is your cue to look for a maintained alternative.
Deactivated is not the same as deleted
Deactivating a plugin stops its code from running on normal page loads, but the files still sit in wp-content/plugins/. Some of those files can be requested directly by URL, and a vulnerability in that code can sometimes be triggered without the plugin ever being active. If you’re not going to use a plugin, don’t just switch it off — delete it. Fewer files on disk is less to scan, less to exploit, and less to forget about.
Never, ever run nulled plugins
“Nulled” plugins are pirated copies of premium software with the license check removed, handed out free on sketchy sites. The people distributing them aren’t charities. A large share of nulled plugins ship with a backdoor baked in — the webshell I mentioned at the top is the same class of thing — and installing one is inviting an attacker onto your server voluntarily. If a premium plugin is worth running, it’s worth paying for. If it isn’t, delete it.
How to Actually Run the Audit
An audit is a short, repeatable process. You can do the whole thing from the WordPress admin, but if you have WP-CLI access it’s faster from the command line. Take a backup first, and if the site is anything but trivial, do the risky steps on a staging copy.
Step 1: Inventory everything you have
List every plugin, its status, and its version so you can see the whole board at once. From WP-CLI:
wp plugin list --fields=name,status,update,versionIn the admin, the Plugins screen does the same job — note anything marked “inactive,” anything with an available update, and anything you don’t recognize.
Step 2: Ask three questions about each one
Go down the list and put every plugin into one of three buckets. Do I still use this? Is it actively maintained (updated in roughly the last year)? Is there a lighter or more trustworthy way to get the same result? Anything you don’t use goes on the delete pile immediately. Anything abandoned goes on the “find a replacement” pile.
Step 3: Check what the inactive ones are hiding
Inactive plugins are pure liability — no benefit, all risk. Delete them. From WP-CLI you can clear them out in one move:
wp plugin delete $(wp plugin list --status=inactive --field=name)Deleting through WordPress (rather than yanking the folder over FTP) lets a well-behaved plugin run its uninstall routine and clean up its own database rows.
Step 4: Check your autoloaded options
See how heavy your autoloaded options have gotten — this is where dead plugins leave their mess:
wp option list --autoload=on --format=countThen open Tools → Site Health in the admin and read what it flags. If autoloaded options are over 800KB, hunt down the leftover rows from plugins you’ve already removed. When in doubt about a stray option, back up the database before you touch it.
Step 5: Update what survives, then re-test
Everything left on the keep pile should be current. Update it, then click through the site’s key pages and forms to confirm nothing broke. Updating on staging first turns “the site is down” into “the staging site is down,” which is a far better Tuesday.
Keep — you use it, it’s maintained, and there’s no lighter option. Update it and move on.
Replace — you need what it does, but it’s abandoned, heavy, or overlaps another plugin. Find a maintained, lighter tool and migrate.
Delete — you don’t use it, it’s inactive, it’s nulled, or nobody can say what it’s for. Remove it through WordPress so it cleans up after itself.
Consolidate: Fewer Plugins Doing More
The best way to keep a plugin list short is to stop it from growing in the first place. Before installing anything, check whether a plugin you already run can do the job, or whether a snippet in your theme’s functions file would be simpler than a whole plugin loaded on every request. Not every small tweak needs its own plugin.
Consolidation also means favoring suites over one-trick add-ons where it makes sense. If you’re running separate plugins for schema, SEO meta, security scanning, cookie consent, alt text, and a static cache, that’s six updates to track, six changelogs to read, and six chances for an author to walk away. One well-maintained suite that covers the same ground is a single thing to keep current.
That’s the thinking behind our own amplifi.plugins — an AI-powered, MIT-licensed WordPress suite where schema, SEO meta, security scanning, translation, alt text, cookie consent, and a static cache all live under one menu and update together. You turn on only the features you need, so the footprint stays lean instead of turning into six separate plugins with six separate maintenance stories.
amplifi.plugins is free and MIT licensed — one install, one update, every tool, and only the features you enable actually load. The full source is on GitHub, so you can read exactly what runs on your site.
View on GitHubMake It a Habit, Not a Rescue Mission
The sites that stay fast and clean don’t audit once — they audit on a schedule. Put a recurring reminder on the calendar, quarterly is plenty for most sites, and run the same five steps each time: inventory, sort, delete the dead weight, check autoloaded options, update the survivors. It takes twenty minutes when you do it regularly, versus a full day of forensic cleanup when you don’t.
The plugin ecosystem is one of the best things about WordPress. It’s also the part most likely to hurt you if you never look back at what you’ve accumulated. An audit is just the discipline of occasionally asking, for every piece of code on your server, “do I still need you, and are you still safe?”
Frequently Asked Questions
A shorter plugin list is a faster, safer, more predictable site. If your own list has crept past the point where you can name every plugin on it, consolidating into one lean, open-source suite is a good place to start.
Built by amplifi.studio — see also our WordPress security hardening guide.