The WordPress Site Audit Most Agencies Skip in 2026

One of those audits is a service. The other is a document.

From Sites I’ve Never Seen, Episode 2 — the podcast companion to this essay.

A WordPress site audit done well takes about a day and surfaces three to five issues that are quietly costing you leads. Done badly, it produces a 40-page PDF that nobody reads and changes nothing about the site. The difference is not in the depth of the analysis — it’s in what you measure first, how you sequence fixes, and whether the team running the audit has actually shipped sites under the same constraints.

Quick Answer

A WordPress site audit should answer four questions in plain language: where is the site losing leads, where is it losing search visibility, where is it losing speed, and where is it accumulating technical risk that hasn’t bitten yet. Anything that doesn’t ladder to one of those four is a curiosity, not a finding.

The deliverable is a prioritised list, not a comprehensive list. Twelve well-chosen checks beats forty exhaustive ones every time.

What a real audit should measure first

Before opening DevTools, get the four numbers that frame everything else:

• Search Console p75 LCP, INP, and CLS on mobile, segmented by URL group. The Core Web Vitals report is the most underused free tool in WordPress operations.
• Top 10 organic landing pages, last 90 days, with bounce rate. From GA4 or your analytics platform. The pages that draw traffic and convert poorly are where the audit lives.
• Form submissions per visitor on top conversion pages. The single number that tells you whether the site is doing its job.
• The plugin list with last-update date. Anything not updated in 12+ months is either abandoned or has a maintainer who’s lost interest. Both are problems.

Those four numbers tell you whether the audit is going to be about performance, conversion, content, or technical-risk — and most “this site needs an audit” conversations turn out to be about one of the four, not all of them.

The 12 checks I run on every audit

1. Core Web Vitals at p75 mobile — Search Console, last 28 days, by URL group.
2. Plugin audit — count, last update, hooks fired per request, anything contributing >50ms.
3. Object cache present and serving — Redis or Memcached connected and storing.
4. Image pipeline — WebP/AVIF served, properly sized variants, LCP image preloaded, lazy-loading correctly applied below the fold.
5. Service-page CTAs — primary above the fold, alternative path visible, both linking to working forms with timezone-correct calendars.
6. Internal-link gravity — top conversion pages have ≥3 inbound internal links from related posts, with anchor diversity (not all exact-match).
7. Schema validity — Organization, Service, BreadcrumbList, Article all firing without warnings in Search Console’s Rich Results Test.
8. Sitemap and robots — sitemap submitted, last-modified timestamps current, robots.txt not accidentally blocking conversion paths.
9. Canonical tags and redirect chains — every page has one canonical, redirect chains are no longer than 1 hop.
10. Mobile usability — tap targets, viewport meta, reading width, hover-only interactions that don’t work on touch.
11. Form delivery — submit to a test address, confirm receipt, check spam-folder routing, verify the autoresponder fires.
12. Backup and recovery — last successful backup, off-site copy verified, restore-tested in the last 90 days.

That’s the list. Anything past it is either depth on one of these twelve or a curiosity unrelated to revenue.

How to prioritise fixes without wasting a month

The audit produces findings; the prioritisation produces work. The framework that lands real wins:

• Highest revenue impact, lowest effort first. A broken contact form on a top conversion page is a one-hour fix worth thousands. A schema warning on a low-traffic page is a one-hour fix worth basically nothing.
• Group by template, not by page. If the service-page template has a CTA problem, fixing it once across the template beats fixing it page-by-page.
• Ship one fix per week and measure. The discipline that keeps the work honest. If a fix doesn’t move a number, the next conversation isn’t “what’s the next fix” — it’s “why didn’t this one work.”
• Defer cosmetic findings to a separate quarterly pass. They will compound; let them compound on someone else’s calendar.

A practical example from a service site

A 12-page services site, ~8,000 organic visitors per month, contact-form completion stuck around 1.2%. The audit findings, in priority order:

1. p75 LCP at 4.1s on mobile. Hero image loaded as loading="lazy" and not preloaded. Fixed: removed the lazy attribute, added a preload link tag. p75 LCP dropped to 1.8s within a week.
2. Plugin audit. Found three plugins running on every page that were only used on /contact/ and /book-a-call/. Scoped them to those routes. Average page weight dropped 180KB.
3. Service pages had no above-the-fold CTA. Six of the eight service pages required a scroll before the first “book a call” button. Added the CTA into the hero block at the template level. Form completion rose to 2.6% within 30 days.
4. Object cache was connected but empty. Misconfigured persistent cache; WordPress was hitting the database for every option lookup. Fix took 20 minutes; TTFB on uncached requests dropped by 280ms.

The first three fixes alone took the form-completion rate from 1.2% to 2.6%. On 8,000 visitors a month, that’s 112 additional inquiries a year — from four findings, not forty.

Common audit mistakes that slow growth

• Auditing the homepage instead of the service pages. Homepages get traffic; service pages convert it. Audit where the conversion happens.
• Optimising for Lighthouse instead of users. A perfect Lighthouse score and a slow real-user experience are a common combination. Use field data over lab data.
• Treating the audit as a one-time event. The site you audited last quarter is not the site you have today — plugins update, content drifts, performance regresses. Quarterly is the cadence that holds.
• Skipping the backup-and-recovery check. Every audit should test that the most recent backup actually restores. The first time you find out it doesn’t is the worst time.

A 15-minute quick win you can do today

Open Chrome DevTools, switch to the Network tab, set throttling to “Slow 4G” with 4× CPU slowdown. Hard reload your top-converting service page. Note the three slowest items by transfer size and the three slowest by load time. Repeat for one other template (your blog, your contact page, your homepage).

If the slowest items are the same across templates, the problem is sitewide (cache, theme, font loading). If they’re different, the problem is template-specific (plugin scoped to that template, unique third-party script). Ten minutes of diagnosis tells you where to spend the next ten hours.

What to read next

If your audit surfaces performance issues, the next read is the practical guide to real WordPress performance — what Lighthouse misses and what to measure instead. If it surfaces over-optimisation patterns (exact-match anchors, schema overload, header uniformity), the next read is the back-off pattern that recovers rankings without the rewrite reset. Both are linked from the closing of this post.

When to bring in someone outside

Most service-business WordPress audits are DIY-able. Where outside help saves real time:

• The findings cross multiple templates and the team can’t agree on a fix order — needs an independent prioritisation.
• Performance issues persist after the obvious fixes — usually a server-side or persistent-cache misconfiguration that needs host-level access.
• The site is at a scale where one team owns content and another owns infrastructure, and the audit findings cut across both — needs a coordinator who’s worked both sides.

If you’re spending more than two days on an audit and the prioritised list still has thirty items, the problem isn’t the site — it’s the audit. A specialist with WordPress delivery experience cuts the list to the four that matter and saves the rest of the quarter.

Last reviewed May 16, 2026.