A wordpress plugin audit checklist walks through every plugin on your site, one row at a time, so you only keep what actually earns its place. In under an hour you can pull the full plugin list, check which ones are current, decide keep-retire-delete for each, and remove the rest without breaking your pages. Set a timer, back up first, then work the list below column by column. This describes current WordPress core-version behavior, read 2026-09-18; menu paths and screens do shift between core releases, so confirm against your own dashboard if you're reading this later.
Why this takes an hour, not a weekend
Most sites don't need a forensic security review every quarter. They need someone to look at the Installed Plugins screen with fresh eyes and ask, of every single row, "do I still need this, and is it still maintained." That's the whole job. The reason it balloons into a weekend project is usually that nobody's looked at the list in a year, so there are twenty plugins to think about instead of three. Fewer active plugins also means fewer things that can conflict with each other after a core update, which is usually the exact moment an audit gets skipped: everyone's too busy fixing what broke to also clean up what caused it. Do this every quarter and each pass gets faster, because you're only re-checking what changed since the last one.
Step 0: Back up before you touch anything
Deactivating a plugin is reversible in seconds. Deleting one, or a bad interaction between two plugins during testing, is not always something you can undo by clicking a button. Before you change plugin status on a live site, take a full backup of the files and the database, not just one or the other. If you don't already have a standing backup routine, follow The Five-Minute Ritual Before Any Risky WordPress Edit so you have a real restore point before the audit starts, not a hope that you'll remember what you changed if something breaks.
Step 1: Pull the full plugin inventory
Go to Plugins > Installed Plugins and resist the urge to start deleting immediately. First just look. Note which plugins are active, which are already inactive (someone turned them off and forgot to remove them), and how many total you're carrying. Click "View details" on anything you don't recognize by name alone; the details panel shows the plugin's description, its last updated date, and its "Tested up to" WordPress version. The Plugin Handbook on WordPress Developer Resources, read 2026-09-18, documents that this "Tested up to" field is set by the plugin's own author in its readme file, and it's the fastest signal you have of whether a developer is still actively supporting the plugin against current WordPress releases.
Some of what's on your list isn't there because you installed it. Many hosts bundle their own caching, security, or analytics plugins into every new WordPress install, and a fair number of those never get configured or even opened. If you don't recognize a plugin's name and it doesn't match anything you or a past contractor set up on purpose, check your hosting dashboard before deleting it; some host-bundled plugins are tied to a feature you're already paying for as part of your hosting plan, so confirm rather than guess.
Step 2: Sort each plugin into keep, retire, or delete
For every row, ask three questions:
- Is it active and doing something you can point to? If you can't say in one sentence what it does for the site right now, that's a flag, not necessarily a death sentence.
- Is it current? A plugin last updated two or three years ago, with a "Tested up to" field several major versions behind, is running unmaintained code on your live site. That doesn't automatically mean it's broken, but it does mean nobody is checking that it still works correctly with today's WordPress.
- Is it duplicating something else on the list? Two SEO plugins, two caching plugins, or two contact-form plugins installed side by side is a common leftover from switching tools without cleaning up the old one. Only one should be active.
Anything that fails more than one of these questions goes on your delete list. Anything you're unsure about goes on a "retire" list: deactivate now, revisit in a month, delete if nothing on the site visibly changed. If you inherited the site from someone else and genuinely don't know why a plugin is there, that's fine; note it as unsure and move it to the retire pile rather than guessing either way.
Step 3: Check whether core already does the job
This is the step most audits skip, and it's the one that actually shrinks your plugin count instead of just tidying it. WordPress core absorbs features that used to require a plugin, release after release, and a plugin you installed years ago for a specific job might now be redundant. A clear current example: the WordPress Font Library: Appearance > Fonts on Any Theme gives you native font installation and management without a dedicated custom-fonts plugin, for themes that support it. The Block Editor Handbook on WordPress.org's Developer Resources, read 2026-09-18, documents the Font Library as part of the site editor's built-in typography tools. Before you keep renewing or updating a plugin that adds a feature like this, check Appearance in your own dashboard first. You may find you're paying maintenance attention, and sometimes a license fee, for something core now does on its own.
Step 4: Understand what deleting actually removes
Not every plugin is safe to simply delete once deactivated. Deactivating stops the plugin's code from running, but any data it left behind, custom database tables, options rows, or content it inserted directly into your pages, usually stays until you deal with it separately. This matters most for plugins that touch content directly: page builders, form plugins, and anything that uses shortcodes. If a plugin added shortcodes to your posts and you delete it, those shortcodes don't get cleaned up; they just stop rendering and start showing as raw bracketed text on the live page. Read What Happens to Your Content When You Delete the Plugin before you delete anything that touched your published content, so you're not discovering broken shortcodes after the fact.
Step 5: Remove what's left, in the right order
Once you've confirmed a plugin is safe to remove, don't just hit delete from the plugins list and move on. There's a sequence that avoids leftover clutter and avoids taking down a live page mid-edit: deactivate first, confirm nothing on the front end changed, check for anything the plugin left in the database, and only then delete the files. How to Safely Remove a Plugin That Has Run for Years walks through that order in detail, which matters more the longer a plugin has been running and the more deeply it's likely to have embedded itself in your content and settings.
Step 6: Set your next recheck date
An audit that happens once and never repeats just delays the same cleanup job by a year. Put a recurring quarterly reminder on your calendar, not a vague intention to "check on it sometime." A quick way to make the next round faster is to save today's list before you close this one out; a screenshot or exported inventory of what's active right now gives you a real baseline to compare against three months from now, instead of relying on memory. Each quarter the list should take less time to review than the last, because you're only evaluating what's new or changed since the previous pass, not starting from zero.
The one-hour checklist, in order
- Back up files and database.
- Open Plugins > Installed Plugins and list every plugin: active, inactive, last updated, "Tested up to."
- Sort each into keep, retire, or delete using the three questions above.
- Check Appearance and Settings for anything core now handles natively before keeping a legacy plugin for that job.
- For anything marked delete, check what it inserted into your content before removing it.
- Deactivate, verify the front end, check for leftover database tables, then delete the files.
- Save today's active-plugin list and set a calendar reminder for next quarter.
FAQ
How often should I audit my WordPress plugins?
A quarterly review is a reasonable baseline for most sites. If your site processes payments or stores visitor personal data, check more often, since those sites have more to lose from an unmaintained plugin sitting active for months.
Is it safe to just deactivate a plugin instead of deleting it?
Deactivating is the safer first move and it's fully reversible. It stops the plugin's code from running while leaving its settings and any database tables in place, so you can reactivate it later if something on the site needs it after all. Delete only once you've confirmed, over time, that nothing broke.
Will deleting a plugin remove content it added to my pages?
Not automatically, and not cleanly. Shortcodes, custom fields, and blocks a plugin inserted usually stay in your content but stop working once the plugin is gone, which can show up as broken formatting or raw shortcode text on live pages. Check what the plugin touched before deleting it.
Do I need a security plugin to do this kind of audit?
No. This checklist uses only the Installed Plugins screen and the plugin details panel that ship with WordPress core. A security plugin can add extra scanning and logging, but the keep-or-remove decision itself doesn't require one.
What if I'm not sure whether a plugin is still needed?
Deactivate it and watch the site for a few weeks rather than deleting it outright. If nothing visibly changes on the front end or in your workflow, it's a strong candidate for the delete list on your next pass.
