Thirty plugins and one of them is abandoned: a plugin audit you can actually finish

There's a question we see again and again from companies that have run a WordPress site for a few years. It usually starts with a number. "We have around thirty plugins." Then comes the worry: one of them hasn't been updated in a long time, a recent update broke a form, and someone in the meeting asked whether it's time to move off WordPress altogether.

The same story turns up from the other side, too. Freelancers taking over clients from an agency that closed. Agencies cleaning up cheap sites that were assembled in a hurry. Site owners asking why everything crashes during a traffic spike when the server dashboard says there's plenty of headroom. Plugin makers asking how small plugins survive when so much of the market is shifting. And beginners asking who is even supposed to pay for the premium ones.

Underneath all of it is one practical gap: nobody has a clear picture of what the plugins are actually doing. So here's how we'd run an audit that a small team can finish in an afternoon or two, without turning it into a rebuild project.

Why "how many plugins is too many" is the wrong question

The count itself tells you very little. A site with forty small, well-maintained plugins can be calmer than a site with eight, if one of those eight is a huge all-in-one tool nobody understands. What matters is:

• What each plugin is responsible for. Forms, payments, logins, redirects and search matter far more than a widget that shows a quote of the day.
• Who still maintains it. Last update date, open support threads, whether the author still answers.
• How much it touches. Plugins that add database tables, rewrite URLs, hook into checkout or log in users are harder to remove than ones that only add a shortcode.
• Whether something else already does the same job. Themes, page builders and the core editor have absorbed a lot of what used to need a separate plugin.

The audit is about those four things, not the number.

The walkthrough

1. Start with a spreadsheet, not the plugins screen

Export or copy the plugin list into a sheet with these columns: name, what it does in one plain sentence, which pages or flows depend on it, last update, free or paid, who holds the licence, and a gut rating of how bad it would be if it vanished tomorrow.

The "one plain sentence" column is where most audits stall, and it's the most useful one. If nobody can explain what a plugin does, that's your first finding. Deactivate it on a staging copy and see what changes.

2. Mark the must-not-break flows

List the three to five things the site must never get wrong: the contact or quote form, checkout, member login, booking, the page sales links point to. Then mark which plugins sit in each of those paths.

This changes the conversation. Instead of "we have too many plugins", you get "our checkout depends on six plugins, two of which haven't been updated in ages." That's a problem a team can prioritise.

3. Sort into four buckets

Go down the sheet and put every plugin into one of four groups:

• Keep. Maintained, needed, does one job well.
• Merge. Duplicates something the theme, builder or another plugin already does. Two SEO plugins, three ways to add custom code, a slider nobody uses.
• Replace. Needed, but abandoned, risky or badly behaved. The abandoned plugin from the opening story lives here.
• Remove. Leftovers from an old campaign, a migration helper still active, a plugin installed to test something and forgotten.

In our experience the merge and remove buckets are where the quick wins are. Nobody argues about deleting a coming-soon plugin from a launch long past.

4. Replace one risky plugin at a time, on staging

For anything in the replace bucket, write down exactly what it does on this site, not what its feature list says. Then pick a replacement, set it up on a staging copy, and test the specific flows from step 2.

Do these one at a time. Swapping five plugins in one afternoon is how a small cleanup becomes a week of guessing which change broke the order emails.

If a plugin is abandoned but deeply tangled in the site, a short-term option is to keep it while you plan, check that nothing in it is known to be vulnerable, and set a date to finish the move. Abandoned isn't automatically an emergency. Abandoned and exposed to the public internet with a known issue is.

5. Change how updates happen

A lot of plugin pain is really update pain. A calmer routine usually looks like:

• Updates tested on staging first, at least for anything in a must-not-break path.
• Automatic updates left on for small, low-risk plugins and switched off for the critical few, which get updated by a person who then checks the flow.
• A backup taken right before updates, and a restore that someone has actually tried.
• PHP and server versions treated as part of the stack, not an afterthought. Several of the "it broke after an update" stories we read were really about the server, not the plugin.

6. Write it down and repeat it

Keep the sheet. Add a "last reviewed" date and a named owner. A quick review every few months catches new duplicates and newly abandoned plugins before they become an incident. If the site changes hands to a new freelancer or agency, the sheet is the most useful thing you can give them.

Where it goes wrong

• Treating the audit as a rebuild. The goal is a calmer site, not a new one. Big rewrites hide in "while we're at it".
• Ignoring performance. A site that falls over under traffic often has a few plugins doing heavy work on every page load, or no caching on logged-out pages. The audit sheet is a good place to note which plugins run on every request.
• Nobody owns the licences. Paid plugins bought on a former freelancer's account stop updating quietly when the licence lapses. Add the licence holder to the sheet and move licences into the business's name where you can.
• Blaming the platform for a stack problem. Moving off WordPress is a fair choice for some sites. But if the real problem is an unmaintained stack and no update routine, those habits tend to follow you to the next platform.

When moving really is the answer

Sometimes the audit shows the site is mostly a brochure held together by plugins that replicate what a simpler tool does out of the box. That's a fine outcome. The point is that you decide with a list in front of you, instead of because one plugin went quiet.

For most companies we talk to, though, the audit ends with fewer plugins, two or three replacements scheduled, and an update routine that doesn't depend on luck.

Your turn

• When you audit a plugin stack, what's the first column you fill in, and which one do you find hardest to fill?
• How do you decide when an abandoned plugin needs replacing this week versus next quarter?
• Do you leave automatic updates on for everything, nothing, or a mix? What made you settle on that?
• If you've moved a site off WordPress because of plugin fatigue, did the problems stay behind or come with you?