Plugins accumulate the way gear accumulates in a garage: each one made sense on the day, and five years later you can’t close the door. Every plugin you carry is code to update, a possible security hole, and a little drag on every page load — so the cheapest maintenance win on most WordPress sites is owning less of it. This works from the admin alone, though WP-CLI makes the listing faster. Take a backup that restores before you start deleting.

List everything and what it claims to do

Get the full roster on paper — or in a spreadsheet, which is where this is headed. From Plugins in the admin, or:

wp plugin list --fields=name,status,version,update

One row per plugin, three columns: what it says it does, whether it’s active, and — next step — what job it actually has on your site. Inactive plugins go on the list too. Deactivated code still sits on the server, and a known hole in an inactive plugin is still a hole.

Match each plugin to a job on the site

Now the honest column. For each plugin, name the page, form, or feature that stops working without it. Plenty will be obvious — the contact form, the SEO plugin, the backup tool. The interesting ones are the rest: the slider for a design you replaced, three caching plugins fighting over the same job, the “coming soon” plugin from launch week. If nobody can say what a plugin does for the site today, it’s a candidate. Not a deletion yet — a candidate.

Check for abandonware

Even a plugin doing a real job is a liability if nobody maintains it anymore. Look up each keeper on wordpress.org and check three things: when it was last updated (past a year, get wary), whether it’s tested with your WordPress version, and whether support threads get answers. A plugin that’s been abandoned by its developer needs a replacement on your schedule, before it becomes a hole on an attacker’s schedule — the same logic as spotting an abandoned website, one layer down.

Deactivate candidates one at a time

Deactivating is reversible, which makes it the perfect test. One candidate at a time:

wp plugin deactivate PLUGIN_NAME

After each one, click the parts of the site a visitor uses: front page, a content page, the forms, search, checkout if you sell. Something broke? Reactivate, and that plugin just proved it has a job — update its row and move on. Nothing broke? Leave it off and let it sit.

Delete after a quiet week

A week of silence is the real test — some plugins only work on cron schedules, weekly digests, or that one form nobody submits on weekends. When a deactivated plugin has caused zero complaints for a week, delete it:

wp plugin delete PLUGIN_NAME

Delete, not just deactivate — deletion removes the code from the server, which is the actual security win. Most plugins leave some settings behind in the database, which is harmless clutter; if you want it gone too, that’s a job for the database cleanup tutorial.

Verify nothing missed it

Run the visitor loop one more time, end to end: pages render, forms send, search searches, orders complete. Then check the admin for surprises — no error notices, no broken settings screens. Your plugin list should now fit on one screen, every row should have a job you can name, and the next update round should be noticeably shorter. That’s the measurable proof: fewer plugins to update means fewer chances for an update to go sideways, and a smaller target for everything else. Put a quarterly reminder on the calendar — the garage fills back up if you let it.