One of those audits is a service. The other is a document.
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 comes from what gets measured first, not from how thick the deliverable ends up looking.
[callout type=”insight” title=”Key Takeaways”]
– A real audit measures user-facing impact first and technical surface second.
– Twelve specific checks cover about 90% of what affects rankings and conversion on a typical service-business WordPress site.
– The priority framework is “highest revenue impact for lowest effort,” not “every red mark in the report.”
– Most audits surface the same three problems: plugin overhead, image pipeline, and a service page with no clear ask.
– A 15-minute self-audit catches more than half of what most paid audits surface.
[/callout]
Quick answer
A WordPress site audit should answer four questions in plain language: where the site is losing leads, where it’s losing search visibility, where it’s losing speed, and where it’s accumulating technical risk that hasn’t bitten yet. Findings that don’t ladder back to one of those four are curiosities rather than work.
The deliverable is a prioritized list. The reason is practical: forty findings on a page produces inertia, and twelve produces a week of work that actually gets shipped.
What a real audit measures first
Most audits go wrong because the auditor opens the toolbox before opening the analytics. The toolbox finds things. The analytics decides which of those things matter. Start by pulling four numbers, and they will tell you what kind of audit this is going to be before a single finding gets written down.
The first number is Core Web Vitals at p75, the 75th-percentile experience, from Search Console, filtered to mobile and segmented by URL group. p75 is the right reference because it captures what your typical bad visit looks like rather than your average visit. The three metrics, Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS), sit in Search Console waiting to be read, and most teams have not opened the report since the day the property was added. The second is the top ten organic landing pages over the last 90 days with bounce rate, pulled from Google Analytics 4 (GA4) or whichever analytics platform the site uses. Pages that draw traffic but do not convert are where the audit work actually happens.
The third is form submissions per visitor on the top two or three conversion pages. If you only have time to track one number while running the audit, this is the one. The fourth is the plugin list with the last-updated date for each entry. A plugin that has not been touched in twelve months is either abandoned or maintained by someone who has lost interest, and you find out which after the next WordPress release breaks something.
Those four numbers tell you whether you’re walking into a performance audit, a conversion audit, a content audit, or a technical-risk audit. Most “this site needs an audit” conversations turn out to be about one of the four. The audit that follows is shorter and better when you know which one you’re doing before you start.
The 12 checks I run on every audit
Those four numbers told you what kind of audit this is. The twelve checks below are what you actually run, in roughly this order. That list is the same regardless of which audit type you landed on. What changes is how much depth you give each item.
- Core Web Vitals at p75 mobile. Pull from Search Console, last 28 days, segmented by URL group.
- Plugin audit: count, last-updated date, and anything contributing more than 50 milliseconds to render time.
- Object cache present and serving. Redis or Memcached connected and actively storing data.
- Image pipeline. WebP or AVIF served where supported, properly sized variants, the LCP image preloaded rather than lazy-loaded, lazy-loading applied correctly below the fold.
- Service-page calls-to-action (CTAs). Primary CTA above the fold, alternative path visible, both linking to working forms with timezone-correct calendars.
- Internal-link gravity. Top conversion pages should have at least three inbound internal links from related posts, with anchor diversity rather than all exact-match.
- Schema validity. Organization, Service, BreadcrumbList, and Article markup all firing without warnings in the Rich Results Test.
- Sitemap and robots. Sitemap submitted, last-modified timestamps current, robots.txt not accidentally blocking the conversion paths.
- Canonical tags and redirect chains. Every page has one canonical, redirect chains no longer than a single hop.
- Mobile usability. Tap targets at the minimum size, viewport meta correct, reading width comfortable, no hover-only interactions that fail on touch.
- Form delivery. Submit to a test address, confirm receipt, check spam-folder routing, verify the autoresponder fires.
- Backup and recovery. Last successful backup confirmed, off-site copy verified, restore-tested in the last 90 days.
That’s the list. Anything past it is either deeper work on one of those twelve, or it’s curiosity work that doesn’t connect back to revenue.
How to prioritize fixes without wasting a month
Findings without prioritization pile up and don’t get fixed. The framework that turns a list of findings into a week of actual work:
Highest revenue impact for lowest effort goes first, always. A broken contact form on a top conversion page is a one-hour fix worth thousands of dollars; a schema warning on a low-traffic page is a one-hour fix worth almost nothing in measurable terms. Group the work by template, because a CTA problem fixed once at the service-page template level beats fixing it page by page. Then ship one fix per week and measure, a cadence that keeps the work honest: when a fix does not move a number, the next question is why this fix did not work, before moving on to the next one. Cosmetic findings get deferred to a separate quarterly pass, where they can accumulate without competing with revenue work for the same hour of attention.
Highest revenue impact for lowest effort goes first, always.
A practical example from a service site
A 12-page services site, roughly 8,000 organic visitors per month, contact-form completion stuck around 1.2%. The audit findings, in priority order:
The top finding was p75 LCP at 4.1 seconds on mobile: the hero image was loaded with loading="lazy" and was not preloaded. Removing the lazy attribute and adding a preload link tag dropped p75 LCP to 1.8 seconds within a week. The plugin audit came second, where three plugins were running on every page but were only needed on /contact/ and /book-a-call/; scoping them to those two routes cut average page weight by 180 kilobytes. Third, six of the eight service pages required a scroll before the first “book a call” button appeared, so the CTA moved into the hero block at the template level, and form completion rose to 2.6% within 30 days. Fourth, the object cache was connected but empty. A misconfigured persistent cache meant WordPress was hitting the database for every option lookup; the fix took 20 minutes, and Time to First Byte (TTFB) on uncached requests dropped by 280 milliseconds.
The first three fixes alone moved the form-completion rate from 1.2% to 2.6%. On 8,000 visitors a month, that works out to roughly 112 additional inquiries a year. None of the four findings were exotic. They were ranked correctly, which is the part most audits skip.
Common audit mistakes that slow growth
The most common mistake is auditing the homepage instead of the service pages. The homepage gets the traffic and the service pages do the converting, so an audit that only looks at the homepage misses what actually pays the bills. Close behind it is optimizing for Lighthouse instead of for users: a site can score perfectly in Lighthouse and still be slow in field measurements, because Lighthouse is a synthetic test running on a fast machine and your visitors are on whatever device they happen to have. The Core Web Vitals field data in Search Console reflects what your visitors actually experience.
Two quieter mistakes cost more over time. Treating the audit as a one-time event ignores that plugins update, content drifts, and performance regresses; a quarterly cadence catches the drift before it shows up in the rankings. And skipping the backup-and-recovery check leaves the biggest risk untested. Every audit should include an actual restore test of the most recent backup, because a backup that has never been restored is a backup you do not actually have.
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 the exercise on one other template, such as your blog index, your contact page, or your homepage.
If the slowest items are the same across both templates, the problem is sitewide, usually cache, theme, or font loading. If they’re different, the problem is template-specific: a plugin scoped to one template, or a unique third-party script. That ten-minute diagnosis is what tells you whether the next round of work is theme-level or page-level, before you commit to either.
When to bring in someone outside
Most of the work in this post is genuinely do-it-yourself. Run the 15-minute DevTools check, pull the four anchor numbers, work through the 12-check list, and you’ve done what a typical paid audit does. Specialists are worth bringing in for narrower reasons than the marketing suggests:
The first is when you have done the obvious passes and the numbers have not moved, which is usually a server-level or persistent-cache misconfiguration that needs host-level access rather than another scan. The second is scale: one team owns content, another owns infrastructure, and the audit findings cut across both, so someone has to coordinate the work across those lines. The third is decision paralysis, where two days of audit work has produced a prioritized list of thirty items and the team cannot agree on what to ship first. An outside read, the kind a structured site audit is built around, forces a four-item version of the same list.
When I run an audit for a client, the tools I use are all free and on this page. What clients are paying for is the practice of ranking findings against revenue impact, learned across enough sites to know which findings on the long list are the ones worth shipping this quarter.
Common questions about WordPress site audits
How long should a WordPress site audit take? Done well, about a day, and it surfaces three to five issues that are quietly costing you leads. The thickness of the deliverable is not the measure. A prioritized list of twelve findings ships more work than a forty-page report nobody reads.
Can I run this audit myself? Most of it, yes. Run the 15-minute DevTools check, pull the four anchor numbers, and work through the 12-check list, and you have done what a typical paid audit does. A structured site audit is worth bringing in when the obvious passes have not moved the numbers, when the findings cut across teams, or when the list is too long to agree on what to ship first.
How often should I audit? Once is not enough, because plugins update, content drifts, and performance regresses. A quarterly cadence catches the drift before it shows up in the rankings. If you would rather not track that yourself, ongoing site maintenance is one way to keep the checks on a schedule, and you can always get in touch to talk through where your site is losing leads.
Leave a reply