How to audit your WordPress plugins in 5 steps

Introduction: an audit that does not end in a deletion is not an audit

Most "plugin audits" produce a spreadsheet. The spreadsheet is read once, found interesting, then filed. Six months later the same spreadsheet gets rebuilt, with the same rows and one more.

A useful audit has one non-negotiable property: it ends in dated deletions. Everything else — the counting, the sorting, the colour-coding — is only a way of getting there.

This protocol runs to five steps and half a day for one site, less per site across a fleet. It needs no paid tool. What it needs is accepting that the right answer is often "remove it", including for a plugin that works perfectly.

Step 1 — Inventory, with the only column that matters

List every plugin: active and inactive. An inactive plugin is not neutral — its code stays on disk and sometimes stays reachable.

For each one, four columns are enough:

the name and the installed version;
the date of the author's last commit, not the install date and not the rating. This is the only column that predicts the future: it tells you whether anyone will fix the next flaw;
active or inactive;
who installed it, and why. If nobody knows, write that down — it is information, not a blank.

⚠ The trap here is doing it from memory. You think you know your site; the inventory almost always says otherwise. Build the list before forming an opinion.

Step 2 — Measure real usage, not assumed usage

This is the step everyone skips, and the one that decides.

For each plugin the question is not "what is it for?" but "when did it last do something?". Three ways to answer, in order of reliability:

a trace — an order placed, a form submitted, a page generated. That is proof;
a page visibly using it, found on the public site. That is a strong indication;
someone asserting it. That is a hypothesis, and it gets verified by 1 or 2.

Then sort into three piles only: used · never seen in use · installed "just in case". The third pile is the largest on almost every site, and it is the one costing you most for what it returns.

Step 3 — Measure what each one costs

Three costs, and the third is the only one visible over time.

Page cost. A plugin loading its scripts on every page when it only serves one is common and easy to spot: compare the weight of a simple content page with and without it.

Database cost. Plugins that write on every visit — statistics, logs, counters — grow the database silently. The symptom is not a slow page, it is a backup that gets longer month after month.

Maintenance cost. This is the real one. Each plugin adds an update to watch, a compatibility to check, a potential breakage after every version bump. This cost is linear in the number of plugins and it never goes down on its own.

The performance side is covered in our 10-minute security audit, which runs the same measurements from the risk angle.

Step 4 — Measure risk, in three questions

Is it abandoned? A last commit more than a year old, with no response to reports, is the strongest signal on the list. An abandoned plugin is more dangerous than a vulnerable one, because no fix will ever come.

What can it reach? A plugin that writes files, runs scheduled tasks, opens a public endpoint or handles payments does not have the profile of a display plugin. The install count says nothing about this.

Does it duplicate something? Two plugins doing the same thing means twice the surface for one function — and it is surprisingly common on a site that has been running for years.

On what these measurements actually protect, see proactive protection against zero-day threats.

Step 5 — Decide, and execute in this order

This is the step that turns a spreadsheet into a result. Three rules.

Delete, do not deactivate. Deactivating leaves the code on disk, so the surface, so the update to track. It is the comfort of a decision not taken. If you do not dare delete, step 2 is not finished.

One at a time, with a tested backup first. A bulk removal that breaks something leaves you not knowing which one did it. One by one is slower once and far faster every time after.

In this precise order, because it runs from certain gain to arguable gain:

the inactive ones — no risk, immediate gain on surface and on the update list
the abandoned ones whose function is no longer used
the duplicates, keeping the maintained one, not the familiar one
the "just in case" pile from step 2 — this is where the argument is hardest and the gain largest
the abandoned but still used: these need a replacement first, not a plain deletion

Then, and only then: write down the date and the remaining count. That figure, compared in six months, is what tells you whether the audit served or was one more spreadsheet.

What this audit does not do

It does not judge a plugin's code quality — that takes reading, not inventorying. It says nothing about the compliance of what they collect. And it does not replace continuous monitoring: an audit is a photograph, and a photograph goes stale.

Conclusion

Going from thirty plugins to fifteen halves the attack surface, halves the maintenance load, and costs no additional software. It is the highest-return measure in all of WordPress site management, and the only free one.

The difficulty is never technical. It is in step 2: accepting to measure real usage rather than trusting the intention you had when installing. A plugin kept "just in case" is a certain cost against a hypothetical benefit — the opposite of what keeping it feels like.

If the inventory showed you a fragmented stack, the next step is migrating a fragmented WordPress stack, and the full diagnosis is in plugin hell. To replace several tools with one coherent set, see how our ecosystem automates site management. Our premium plugins come with a full refund within 14 days: see the catalogue.