What a real WordPress technical-debt audit actually finds.

Most WordPress audits read the same. Plugin count, PHP version, image sizes, an SEO checklist. None of those are wrong, but none of them are where the real cost lives. The audit findings that actually change what to do next are about the choices the original build made — the data model, the editor experience, the integration shape. Here's what shows up when you look in the right place.

The standard WordPress audit deliverable is a list of about 30 findings, mostly catalogued from automated tools. Plugin count, last update dates, PHP and WordPress version compatibility, image dimensions exceeding their containers, Core Web Vitals scores, an SEO checklist. It looks thorough. The client signs it. The recommendations get half-implemented. The site is, six months later, in roughly the same shape it was.

The reason: those findings are real, but they’re symptoms, not the disease. The disease is upstream: in the architectural decisions made during the original build that the audit didn’t look at, because looking at them requires reading the code and asking why instead of running a scanner.

What the scanners catch.

Most automated WordPress audits surface a known set of issues:

• Plugins that haven’t been updated in 12+ months
• PHP version older than supported
• Images served at native dimensions far larger than display size
• Core Web Vitals scores below threshold
• Missing SEO meta on certain page types
• Mixed-content warnings, HTTPS issues
• Database tables that should have been cleaned up

These are valid findings. They should be fixed. They are also, in most cases, easy to fix — an afternoon of work each. The reason the site is in trouble is rarely any of them individually. It’s that the structural choices made when the site was built two or four or seven years ago no longer fit how the business actually operates, and every individual fix gets undone over time because the underlying pressure that caused the problem hasn’t gone away.

What the scanners miss.

The audit findings that change what to do next are the ones a tool can’t surface:

• The data model that doesn’t fit anymore. Custom post types and taxonomies designed for the business as it was three years ago, now being used in ways they weren’t designed for. ACF flex blocks that started as a clean “build any page” system and are now 47 layout options with no clear ones to recommend. The audit needs to look at how editors actually use the system, not just whether the system runs.
• The plugin doing too much. A page-builder plugin installed for one landing page now powering thirty pages, none of which the engineering team can refactor without breaking. A form plugin chosen for one form now handling six different workflows. The plugin itself isn’t broken — the sprawl around it is the finding.
• The integration that’s quietly drifting. A CRM connector still functioning but with a field map that references three properties that no longer exist on the CRM side. An email automation triggered by a webhook that fires for a condition that hasn’t been true in eighteen months. These don’t show up as errors — they show up as “why are we sending leads to a list that nobody monitors.”
• The theme that became the application. Functionality that should have lived in a plugin (or in a proper architecture layer) instead living in functions.php or scattered through theme template files, because someone needed to ship a feature fast. Now changing the theme means rewriting the application.
• The editor experience that’s making the team avoid the CMS. The most expensive finding on most WordPress sites is “the marketing team stopped updating it because the admin is painful.” That’s not in any scanner.

How to read for the upstream issues.

Three places I look first, in order:

• The custom code in the theme. Open functions.php and the inc/ directory. Count how many distinct things the theme is doing. Anything beyond pure presentation logic is a candidate for “this should have been a plugin” or “this should be a custom post type.” The more application logic is in the theme, the more brittle the system is.
• The post-meta proliferation. Query wp_postmeta for the count of distinct meta_key values. A healthy custom site has hundreds. A site in trouble has thousands to tens of thousands — including hundreds of keys nobody’s writing to anymore. Each one was a field a plugin or theme created and never cleaned up.
• The interview with the editor. Ask the person who uses the admin daily: “What’s the most painful thing you do in this CMS?” That’s almost always the highest-leverage finding, and no audit tool can tell you what it is. Sometimes the answer reveals that the site’s data model fundamentally doesn’t match how the team thinks about their content.

What a useful audit deliverable looks like.

A useful WordPress audit ends with two lists, not one. The first list is the scanner findings — standard, fixable, sequenced. That part is necessary. The second list is the architectural findings — the things that require a decision before they require a fix. “Your data model assumes case studies have one author; you now have three co-authored pieces. You need to decide whether to extend the model or work around it for the next thirty cases.”

The second list is what determines whether the site is on a sustainable path or just being maintained at a slow leak. Most audits skip it because it’s harder to scope, harder to deliver, and harder to sell. It’s also the part that earns its keep. See legacy modernization for what happens after the audit is done.