Running and reading a site audit

When a crawl runs

Automatically, on a schedule set by your plan, and on demand from the site's audit page. The first crawl starts as soon as a site is added.

What the crawl spends

The page budget is per site per crawl: 250 on Free, then 2,500, 10,000, 25,000 and 50,000 as the plans go up. Crawls on demand are counted separately, per account over a rolling seven days, and the scheduled crawl never counts against them. A shop with a filter set can spend more of that than expected, which is exactly why the audit counts filter URLs and reports the number rather than quietly consuming the budget.

The four categories

Technical covers status codes, redirect chains, canonicals pointing elsewhere, sitemap disagreements, noindex tags where they should not be, and duplicate titles and descriptions.

Content quality scores every page with the Yoast and Rank Math emulators: title length and pixel width, description length, keyphrase placement, subheading distribution, image alt text, link counts, sentence length and passive voice.

Core Web Vitals are sampled through PageSpeed Insights on mobile and desktop, so a slow template appears as a pattern rather than as one unlucky reading.

WooCommerce covers product schema, price and stock disagreements between the schema and the page, and filter URLs.

Audit read 2 hours ago, 1,204 pages Sample data

Site audit, down 3 since last month17 findings open across four categories. Two of them are worth doing first.

Technical6 Content5 Web Vitals2 WooCommerce4

• High 3 pages Canonical points to another page /pricing/?plan=agent-plus canonical is /pricing/
• High 2 pages Redirect chain of 3 hops /features/reporting to /client-reports to /reports/
• Medium 4 pages Duplicate title "SEO Tools Australia" on 4 documentation pages
• Low 1 page In sitemap, answers 404 /news/2025-beta/

Reading a finding

Every finding carries three things: what it is, why it matters, and how to fix it. They come from one catalogue, so the audit screen, the WordPress plugin and the documentation all say the same sentence about the same rule.

Muting one

A finding you have decided not to act on can be muted, and it stays muted across crawls. Muting changes the health score, which is the point: a score that counts something you have deliberately chosen is not measuring your site.

Working through a first audit

The first audit of a site that has never had one is usually long, and it is usually short. Long as a list, short as a set of causes.

Read the URLs before you read the counts. Forty findings of the same code on forty pages is one template. This is the single most useful habit, and it is how we found that ten of the fifteen problems on our own site were not problems at all.

Sort by weight. The catalogue carries a weight per rule, which is how much the fault stands in front of rather than how broken it is. One canonical pointing at a redirect on your best page outranks forty images with no alt text.

Fix the cause, then re-crawl. Do not fix forty pages by hand when one template produced them.

Mute what is intentional, with the reason, so the next person does not undo it.

What a finding does after you fix it

It resolves on the next crawl that no longer sees it, and the resolution is recorded against that crawl. You can answer "did we fix that, and when" without remembering.

On a paired WordPress site, a fix applied through the plugin re-reads the page immediately and resolves the finding in seconds. What the plugin reports is what it read back, not what it meant to write.