Fair question. There are roughly sixty thousand plugins in the WordPress repository, and every one of them can already show you a list of what’s installed. WordPress itself does it for free, on the Plugins page, out of the box.
So why spend the time building another one?
Because a list isn’t an audit. I kept running into the same wall on client work, and eventually the honest answer was that the thing I needed didn’t exist. Here’s the reasoning, section by section.
Because the plugins page tells you nothing
Most of the WordPress sites I get handed have been through multiple hands. A developer in 2019, a nephew in 2021, a marketing agency in 2023, and now me. Nobody removed anything. Everybody added something.
What that produces is a site where nobody can tell you what’s actually running or why. The plugins page shows you forty-seven rows. It does not tell you which of them matter, which are dead weight, which are quietly fighting each other, or which one is the reason the site got slow last spring.
Everything expensive on that site is hiding in plain sight on a page everyone scrolls past. I wanted something that reads the page the way I do.
Because doing it by hand cost me an afternoon, every time
This is the real origin. Nothing in this post is impossible without a tool — I did it manually for years.
Here’s what manual actually looks like. Screenshot the plugins page, then the inactive tab, then themes. Paste it all into a doc. Google each plugin one at a time, because you’ve never heard of half of them — open the repository listing, check when it was last updated, work out what it even does, decide whether the client needs it. Do that thirty or forty times. Then hold all of it in your head at once, because that’s the only way you’ll notice that plugin number six and plugin number twenty-nine are both handling caching. Then sort the themes, figure out which are parents and which are children, and work out what’s actually in use.
Then comes the part nobody budgets for: making it presentable. Headings, spacing, a table that doesn’t break across pages, your logo, the client’s name in the right places. An hour of formatting on top of the research, and it still comes out looking a little different from the last one you sent.
Then do it again next quarter. And on the next client. And try explaining to a junior how to produce one that matches yours.
Two to three hours per audit, most of it clerical, with quality that depended on how tired I was. That’s what I was actually trying to kill. Not the thinking — the typing, the googling, and the formatting around the thinking.
Because the overlap is where the money is
This is the finding that pays for the whole exercise on the first site.
Pull up almost any inherited install and you’ll find duplication. Two caching plugins arguing with each other. A security plugin the client pays for annually plus a free one doing the same scanning. Three separate ways to add a contact form, because each new person brought their favorite. Two backup solutions, one of which quietly stopped running eighteen months ago.
Spotting that manually means holding forty plugins in working memory simultaneously. So I built the detection in: it flags plugins that genuinely do the same job, and it tells you why it matched them, so you’re not guessing from the name. That distinction was the whole design problem. “These two both say SEO” is noise. “These two both register a caching layer” is a finding you can act on.
Then you walk into the meeting and say: you’re paying four vendors to do two jobs, and two of them are actively conflicting. That isn’t a technical conversation, it’s a budget conversation — and it’s the fastest way I know to establish you’re worth listening to. Cancelling redundant licenses often covers a chunk of your fee before you’ve touched a line of code.
Because “deactivated” isn’t “gone”
Every site has them. Plugins somebody switched off instead of deleting, sitting there for years.
Clients assume deactivated means removed. It doesn’t. The code is still on the server, still unmaintained, and it’s a category of exposure that never comes up in conversation because nobody’s looking at the inactive tab.
So the scan covers active and inactive both, flags what’s sitting on an old version, and surfaces what’s been abandoned. That turns a vague “you should keep things updated” into a specific list with names on it. Specific gets approved. Vague gets deferred to next quarter, every quarter.
Because a conversation doesn’t get approved, a document does
I can tell a client their site is a mess. They’ll nod, and nothing will happen.
Hand them a PDF with their company name on it, their project name, the audit date, everything organized by active and inactive, each item written in language they actually understand with a note from me about what I’d do — that gets forwarded. It gets shown to a partner. It sits in an inbox as a thing that needs a decision.
That’s the real function of the report, and it’s why the tool has a customer information section and an export instead of stopping at a screen full of results. It isn’t a deliverable, it’s leverage.
Two things make it work, and both are edit features rather than scan features. First, I rewrite the descriptions. The stock plugin description is written for developers browsing a repository and means nothing to the person signing the check. “This handles your contact forms” lands. So does “this hasn’t been updated since 2019 and does nothing.” Second, I cut what doesn’t matter — every install has a dozen items that are noise for the client’s purposes, and leaving them in buries the three things I need a yes on. A ten-item report someone reads beats a sixty-item report they skim.
The PDF generates on the server, on demand, with no third-party library in the chain. Nothing to configure and no external service touching client data.
Because the second audit shouldn’t cost what the first one did
This is the design decision I’m happiest about, and the one I didn’t fully appreciate until I’d been running it a while.
Your edited descriptions and your notes are remembered between scans. Items you removed stay removed, and can be restored if you change your mind. So the second audit on a site isn’t the first audit again — it’s your own annotated version of that site, in your own language, and all you’re really reviewing is what changed.
Do the math. First audit takes real effort. Every one after is a fraction of it. Across a dozen retainer clients on quarterly reviews, that’s the difference between a service you dread and a service with margin in it. Most tooling gets more tedious the longer you use it. This one gets cheaper.
Because I didn’t want to defend it later
Worth saying plainly, since we’ve all been burned: it creates no database tables. It doesn’t sprawl into the install or leave residue you’ll be explaining to the next developer.
I have to justify every plugin on the sites I manage. I wasn’t going to build something I’d have to make excuses for.
Where it actually pays off
Three places, all of them revenue:
Winning the work
An audit of a prospect’s own site, with their own specifics in it, outsells any capabilities deck. You’re not describing what you’d find — you’re showing them what you found.
Scoping the work
You price accurately because you know what’s there before you commit, instead of discovering the conflicting caching plugins in week two.
Keeping the work
Quarterly re-scans are cheap to produce and make a retainer feel like something rather than a line item.
Try it on your worst site
Don’t test it on a clean build. Run it on the ugliest inherited mess you’ve got — the one with forty-some plugins and no documentation — and look at what comes back as overlapping. That’s usually the moment it clicks, because you’ll find something you’d have missed and you’ll be able to put a number on it.
You can see the tool and grab it here: WordPress Website Audit.
If you use it on real client work and something’s missing that you need, tell me. Most of what’s in there came from exactly that.
