Twice a year, put an hour in the calendar to look properly at your plugins. Not the quick glance you give the update count, but a sit-down review of every plugin on the site: what it does, whether you still need it, and who looks after it. It is an easy job to skip, and a skipped review is how a plugin list grows, one addition at a time, until nobody can explain half of it.
A WordPress plugin audit is not technical work. You need administrator access, a spreadsheet and a little patience. What follows is a routine you can repeat each time: how to collect the list, the questions to ask of each plugin, how to decide what stays, and how to remove things without upsetting the site. It is one of the regular checks in our WordPress site owner’s handbook.
Collect the full list first
Open Plugins → Installed Plugins. Above the list you will see filters such as All, Active, Inactive and, where they apply, Update Available, Must-Use and Drop-ins. Look at each one. Must-use plugins and drop-ins are easy to miss, because they cannot be switched off from this screen, but they run on every page.
For a list you can paste into a sheet, go to Tools → Site Health → Info and click Copy site info to clipboard. The copied text includes active and inactive plugins with their versions and authors, along with your WordPress and PHP versions. Paste it into a document and pull out the plugin lines.
What to record for each plugin
| Column | Why it matters |
|---|---|
| Name and version | Identifies it exactly, including for support requests |
| What it does on this site | In your own words, not the developer’s description |
| Active or inactive | Inactive plugins are the first candidates to go |
| Who installed it, and why | Tells you who to ask before changing it |
| Free or paid, and who holds the licence | Paid plugins need a renewal plan and an account you control |
| Last updated by its developer | A rough sign of whether it is still looked after |
| Automatic updates on or off | So you know which plugins change without anyone watching |
| Decision and date | Keep, replace or remove, and when you decided |
If you do not know what a plugin does, the post on how to find which plugin does what shows how to trace it from the page code and the dashboard. Do not guess; write “unknown” and come back to it.
Six questions to ask every plugin
Is it active?
An inactive plugin does nothing for visitors, but its files are still on the server, and a known flaw in those files can still be a problem. If you deactivated it to test something and never turned it back on, the site has managed without it. Delete it unless you have a specific reason to keep it. The difference between the two actions is explained in our post on deactivating versus deleting a plugin.
Is it still used?
Plugins outlive the reason they were installed. A countdown for a sale that ended, a coming-soon page from before launch, an import tool used once during a move, a slider on a page that was redesigned. Check whether the feature still appears anywhere. If it does not, the plugin can go.
Does something else already do this job?
Look for overlap. Two plugins doing the same site-wide job, such as SEO, caching, security or backups, often clash or duplicate work. Page builders frequently come with several add-on packs that each add a few widgets. WordPress itself has also absorbed features that once needed a plugin, including a basic XML sitemap, lazy loading of images and a site icon setting. Where two tools overlap, keep the one you rely on and plan to retire the other.
Is it still looked after?
For plugins from the WordPress.org directory, open each one’s directory page and copy two details into the sheet: the date of its latest release and the “Tested up to” version. A label that is a little behind is common; our post on a plugin not tested with your WordPress version explains why. Long gaps with no updates, unanswered support threads, or a notice that the plugin has been closed are the signs to act on.
Is it up to date on your site?
A plugin with an update waiting for months is a question to answer. Sometimes there is a good reason: a rollback after a bad release, or a paid licence that lapsed. Write the reason in the sheet. If there is no reason, schedule the update with a backup and a test.
Who is responsible for it?
For paid plugins, check which email address the licence is registered to and whether it belongs to the business or to a former developer. If the licence sits in someone else’s account, you may lose updates when it lapses. Our post on a WordPress plugin licence that has expired covers what to do then.
After the WordPress plugin audit: keep, replace or remove
Once each plugin has answers, the decision is usually obvious.
- Keep: it is active, used, looked after, up to date and nothing else does the same job.
- Replace: you still need what it does, but it is no longer maintained, overlaps with a better tool, or its licence is a problem. Our guide on how to swap one plugin for another safely walks through the move.
- Remove: it is inactive, unused, or does something WordPress or another plugin already handles.
- Investigate: nobody knows what it does. Leave it alone until you find out.
Removing plugins without surprises
- Take a full backup first, files and database.
- Remove one plugin at a time, not ten at once, so that if something changes you know which removal caused it.
- Deactivate first and check the site: home page, main service pages, forms, checkout if you have one.
- Wait a day or two for anything that only runs occasionally, such as scheduled emails or backups.
- Then delete it from the Plugins screen, so its own clean-up routine can run.
- Look for shortcodes it left in your pages and remove or replace them.
If your host offers a staging copy, doing the removals there first and repeating them on the live site is the calmer route.
What the plugin list does not show
A full review also glances at the parts of the site that behave like plugins but are not listed as ordinary ones:
- snippets stored in a code snippets plugin, each of which is a small piece of custom code
- features built into your theme or a companion plugin that came with it
- tools your host adds, often as must-use plugins
- outside scripts pasted into the header or footer, such as chat or tracking codes, which should be listed in the same sheet
Also check whether your security plugin or host reports any known vulnerabilities in the plugins you run. Those findings come before everything else in the sheet.
Make the review a habit
Save the sheet somewhere the business controls, not on one person’s laptop, and keep it for next time. The second review is much quicker than the first, because you only need to look at what changed. Besides the two dates a year, run through it whenever a developer hands the site over, when someone with admin access leaves, and before a redesign.
This review is about understanding and tidying what you run. If your worry is whether the number of plugins affects speed, that is a separate question, answered in our post on whether too many plugins slow down WordPress.
The WordPress plugins guide covers the rest of a plugin’s life on your site, from choosing it to taking it off.
Frequently asked questions
Why twice a year and not every month?
Monthly, it is worth a short look at pending updates and anything newly flagged. The full review, with the sheet and the six questions, takes longer and changes slowly, so twice a year catches most drift without becoming a chore. Run an extra review whenever the people working on the site change.
Should I keep inactive plugins in case I need them later?
Usually not. You can reinstall a directory plugin in a minute, and a paid plugin from your account with the vendor. Keeping inactive plugins on the server leaves code there that nobody is watching. If you want to keep its settings for a later return, note that in the sheet and delete it without using its delete-data option.
What if nobody can tell me why a plugin is installed?
Do not remove it on a hunch. Trace what it does first, on a staging copy if possible, by deactivating it and checking what changes. Ask any former developer or agency. Once you know, the usual questions apply. Until then, mark it in the sheet as unknown so it is not forgotten.
Should I tell my developer before removing plugins after a review?
Yes, if someone else maintains or built the site. They may know why a plugin is there, or that another plugin depends on it, and they can warn you about custom code that relies on it. Share the sheet, agree who removes what, and make sure any maintenance tool they use is not set to reinstall it.
The review itself is yours to run; nobody knows better than you which features the business still uses. The month-to-month side, meaning updates, backups and security checks, is what our WordPress monthly maintenance plan looks after.
