A while ago I logged into a client’s WooCommerce shop to fix a small checkout problem and opened the Plugins screen. There were 34 plugins installed. Fourteen were active. The other twenty were switched off, some of them for years.
When I asked about them, the answer was the one I hear most weeks: “I didn’t want to delete them, just in case.”
(That shop is a composite of several I’ve worked on, but the numbers are close to what I see.)
I understand the instinct completely. Deleting feels permanent. Deactivating feels safe. But a plugin graveyard isn’t as harmless as it looks, and clearing it out is one of the easiest bits of tidying a shop owner can ask for.
Why deactivated plugins still matter
Switching a plugin off stops it running on your pages. It doesn’t remove it. The files are still sitting on your server, and that has a few knock-on effects.
The code is still there. A deactivated plugin’s files are still on the server, and some of them can still be reached directly. If one of those plugins has a security hole, being switched off doesn’t always protect you. And because nobody’s using it, nobody’s updating it either.
They stop getting updated. Most people only update the plugins they’re actively using. The switched-off ones fall further and further behind, and some of them get abandoned by their authors altogether. Old, unmaintained code on a server is exactly what you don’t want.
They make every job slower. When something breaks, the Plugins screen is one of the first places I look. Twenty dead entries make it harder to see what’s actually running, and harder for the shop owner to tell me what they changed. Backups are bigger too, and updates take longer to review.
They leave settings and data behind. Many plugins store their settings in the database, and some create their own tables. That stays put after you deactivate, and often after you delete as well. It’s rarely dangerous, but it’s clutter, and it can confuse things if you ever reactivate an old plugin by mistake.
They tempt someone to switch them back on. I’ve seen a well-meaning staff member reactivate an old shipping or payment plugin “to see what it did”, on a live shop, on a busy afternoon. Things that aren’t there can’t be switched back on.
Why people keep them
It’s worth saying the reasons out loud, because they’re usually fair:
- “We might need it again.” Sometimes true, but if you do, you can reinstall it in a minute.
- “I don’t know what it does.” This is the big one. Nobody remembers who installed it or why.
- “I’m worried something will break.” Reasonable. Deleting the wrong thing can remove settings you wanted.
- “A developer put it there.” So it feels like it belongs to someone else.
None of those are reasons to keep a plugin forever. They’re reasons to take ten minutes and check before you remove it.
How I clear out a plugin graveyard safely
This is roughly how I do it for clients. It isn’t complicated, but the order matters.
1. Take a full backup first. Files and database, and make sure you know how to restore it. If you’ve got a staging copy, do the work there first.
2. List every deactivated plugin. For each one I write down its name, when it was last updated, and whether I can tell what it was for. A spreadsheet is fine. So is the back of an envelope.
3. Work out what each one was for. I check the plugin’s description, look for its settings page, and ask the client what they remember. Quite often the answer is “we tried it and went with something else”, which is easy.
4. Look for anything worth keeping. This is the step people skip. Some plugins hold things you might want later: old form entries, redirect lists, custom code snippets, a set of shipping rules. If there’s anything like that, I export it or copy it somewhere safe before the plugin goes.
5. Check whether it cleans up after itself. Some plugins have a setting that removes all their data when you delete them. That’s great if you’re sure, and a nasty surprise if you’re not. I check before I press the button.
6. Delete, don’t just deactivate. Once I’m happy, I delete the plugin properly from the Plugins screen. Then I check the shop: the homepage, a product page, the basket, checkout and a test order.
7. Note what went. I keep a short list of what I removed and why, with the client. If anyone ever asks “where did that plugin go?”, the answer is written down.
A few rules of thumb
- If a plugin has been switched off for more than a few months and nobody can say why, it’s a strong candidate to go.
- If you’re testing a plugin and decide against it, delete it the same day while you still remember what it was.
- Keep one of each job. Two SEO plugins, two caching plugins or two shipping plugins, even with one switched off, is asking for trouble.
- Fewer plugins isn’t the goal on its own. A shop with forty well-chosen, updated plugins is fine. A shop with twenty forgotten ones isn’t.
What it feels like afterwards
The first thing clients usually say is that the Plugins screen finally makes sense. They can see what’s running, they can see what needs updating, and when something goes wrong they can tell me what’s changed. It’s a small job, but it makes the next fix quicker and the next update less nerve-racking.
If your Plugins screen has a long tail of switched-off entries and you’re not sure which ones are safe to remove, book a quick call with me. We’ll look at what you’ve got and I’ll tell you what I’d keep, what I’d export, and what can go.
Written by Connie, an AI, from Neil Matthews’ notes, archive, and direction. Neil directed and edited this piece. He did not write these words. Augmented publishing by Neil Matthews.