Open the Plugins page on a WordPress site that’s been running for a year or two and you’ll usually find more than you expected. A contact form plugin swapped out for a different one, a page builder trialled once and abandoned, a theme installed just to test a demo. None of it gets used, but all of it still sits on the server, loading files, checking for updates, and quietly widening the attack surface of the site.
In most of the sites I audit, this is one of the first things I check, and it’s rarely a five-minute job the owner expected. This guide walks through how to find genuinely unused plugins and themes, tell them apart from ones that only look inactive, and remove them without breaking anything.
Quick Answer
Go to Plugins → Installed Plugins and Appearance → Themes, deactivate anything you don’t recognise or actively use, wait a couple of weeks to confirm nothing on the site breaks, then delete the deactivated items completely. Never delete an active plugin or theme without deactivating it first, and always take a full backup before you start.
Why This Matters
Every plugin and theme installed on a WordPress site, active or not, is code sitting in wp-content. Deactivating a plugin stops it from running on the front end, but the files remain on the server, and vulnerabilities in those files can still be exploited directly if an attacker knows the file path. Security scans I’ve run on client sites regularly flag a vulnerability in a plugin nobody remembers installing, deactivated years ago but never deleted.
There’s a performance cost too. Even deactivated plugins add clutter that slows down admin screens, and active-but-unused plugins are worse — every one still loads its scripts, styles, and database queries on every page load, whether a visitor ever touches the feature or not. I’ve seen sites carrying five separate SEO or caching plugins from past experiments, each fighting the others for the same job. Trimming that list down is one of the more reliable ways to speed up a slow admin dashboard, and it also shrinks the number of things that can go wrong during a WordPress core update, since fewer plugins means fewer compatibility conflicts to troubleshoot.
Step-by-Step Instructions
Work through this slowly rather than all in one sitting. Rushing the removal step is the single most common way this goes wrong.
1. Back Up the Site Before Touching Anything
Take a full backup, files and database, before deactivating or deleting a single item. If your host offers one-click backups or you’re running a backup plugin already, trigger a manual backup now rather than relying on the last scheduled one — you want a copy from right before you start, not from three days ago. This step takes two minutes and it’s the difference between a five-minute rollback and a stressful afternoon if something you didn’t expect turns out to depend on a plugin you removed.
If backups on this site are more of an occasional habit than a real routine, it’s worth fixing that first — see how to create a website backup schedule for a proper setup you won’t need to think about each time.
2. List Every Installed Plugin and Theme
Go to Plugins → Installed Plugins and note which are active and which are already deactivated. Do the same at Appearance → Themes — WordPress keeps every theme you’ve ever installed unless you remove it, so it’s common to find three or four old themes sitting alongside the one actually in use. Write this list down somewhere, even just a quick text file, so you have a record of what existed before you started removing things.
3. Check When Each Plugin Was Last Updated
Click “View details” on each plugin to see its last update date and whether it’s still marked compatible with your WordPress version. A plugin that hasn’t been updated in two or three years is either genuinely finished (some simple utility plugins never need another release) or abandoned by its developer — worth flagging either way, since abandoned plugins won’t get security patches if a vulnerability is found later.
4. Deactivate One at a Time and Watch for Breakage
For anything you suspect is unused but aren’t fully sure of, deactivate it on its own — not in a batch with others — and check the site immediately afterwards. Load the homepage, a blog post, and any page that uses a form or a special layout. If a shortcode suddenly shows as raw text on the page, or a section of a page goes blank, that’s the plugin you just deactivated. Reactivate it and move to the next candidate instead. This one-at-a-time approach is slower than deactivating everything in bulk, but it’s the only reliable way to know which specific plugin was actually responsible if something breaks.
5. Leave Deactivated Items Alone for Two Weeks
Don’t delete immediately after deactivating. Some plugin features only run on a schedule — a weekly report email, a monthly cleanup task — and won’t show a problem until that schedule comes around. Leaving deactivated plugins in place for a week or two, with nothing reported broken, is good confirmation before the irreversible step of deleting them.
6. Delete Through the WordPress Admin, Not FTP
Once you’re confident a deactivated plugin or unused theme is safe to remove, delete it from inside Plugins → Installed Plugins or Appearance → Themes rather than deleting the folder manually over FTP. The admin screen runs the plugin’s own uninstall routine first, which cleans up any database tables or options the plugin created — deleting the folder directly skips that step and leaves orphaned data behind in the database.
Practical Tips
- Keep at least one default WordPress theme (like Twenty Twenty-Five) installed even if unused — it acts as a safe fallback if your active theme ever breaks.
- If a plugin’s purpose is unclear from its name, check its “View details” description before assuming it’s safe to remove — some maintenance or security plugins run quietly in the background with no visible front-end feature.
- Keep your written list from Step 2 for a few months. If a client or colleague later asks “where did the pop-up feature go”, you’ll have a record of exactly what was removed and when.
Common Mistakes
- Deleting an active plugin directly. WordPress will stop you from deleting an active plugin through the admin screen, but deleting the files via FTP while it’s still active can bring the site down instantly.
- Batch-deactivating everything at once. This makes it far harder to identify which single plugin caused a problem if the site breaks.
- Assuming an inactive theme is harmless. Inactive themes are rarely a security risk on their own, but they still take up server storage and occasionally show up in vulnerability scans if genuinely outdated.
When to Use This vs Alternatives
A manual audit like this is the right approach for most small to medium sites, and it doubles as a useful WordPress security audit at the same time, since unused plugins are one of the most common findings in that process. On a larger site with dozens of plugins, a plugin conflict detection tool can help narrow down which plugin is causing a specific issue, which is worth reading about in more detail if you’re regularly troubleshooting plugin conflicts rather than doing a one-off cleanup.
If your main concern is that the admin area itself feels sluggish rather than security, it’s worth checking whether that’s actually plugin bloat or something else — a slow WordPress admin dashboard can have several other causes worth ruling out first. For the official reference on installing, updating, and removing plugins correctly, WordPress.org’s own plugin management documentation is a good source to bookmark.
Doing this kind of cleanup regularly is easier if it’s part of a documented process rather than something you remember to do occasionally — pairing it with the step-by-step guide to building a WordPress website gives you a fuller picture of where ongoing maintenance like this fits alongside the rest of the site’s upkeep.
Conclusion
An unused plugin or theme costs you nothing until it does — a missed vulnerability, a slower dashboard, or database clutter nobody remembers creating. Back up, deactivate one at a time, wait, then delete through the admin screen rather than FTP.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.