Reading the site audit

The Site audit screen is one crawl, read several ways. It opens on Overview: the health score, the pages by the answer each gave, the issues that matter most, the checks by category and the facts about the whole site. Then Issues, every check the crawl ran; Crawled pages, the pages themselves, filtered by answer or by issue; Links, the redirect chains, the broken links and the shape of your internal linking; Core Web Vitals, a lab sample of how fast a few pages are; Structured data; and Compare, any two recent crawls side by side.

The health score counts pages, and the split beside it counts findings

The score is the share of crawled pages with no critical finding, rounded down — so a site with one bad page out of a hundred is ninety-nine rather than a hundred. The three numbers beside it are findings rather than pages, which is why a critical count can be larger than the number of pages the score was taken over: one page can fail several checks. Every figure on the card says which of the two it is.

The same score, from the same definition, is printed on Home and on the project Dashboard, and all three screens read the count of pages carrying a critical finding through one query rather than working it out twice. When a crawl ran more checks than the crawl before it, none of the three prints a change: each says from which day the audit checks more, and the change counts from the next crawl.

Three severities, and they are our judgement

A check is critical, a warning or a notice, and which is which is a property of the check rather than of your page — it is this product’s opinion about what matters, applied the same way to every site. It is derived when the screen is drawn rather than stored, so changing that opinion does not rewrite what older crawls recorded.

Every check is listed, and a fixed one reads zero

The Issues tab lists every check the crawl ran with how many pages each found, the ones that found nothing included, so a check you fixed reads zero pages and its Fixed column counts the pages that no longer carry it. New and Fixed compare two crawls that ran the same checks, so a first crawl has no such count and they read a dash — four issues on a first crawl are four issues, not four new ones.

Three ways a list can be empty

• No crawl has finished, so nobody has looked.
• A crawl finished and fetched no pages, which is a failure rather than a clean site.
• A crawl looked and found nothing wrong, which is the only one of the three that is good news.

The screen says which of those happened rather than printing one “no issues found” over all three. The same care applies to the structural counts: a crawl from before this product recorded page rows has no orphan count and says so, rather than reporting that it found none, and so does a crawl of a site with no sitemap, because the crawler finds a page nothing links to only through one. A check that could not be counted on a crawl reads as a dash, not as zero pages.

Comparing two crawls

Compare puts any two of the recent crawls side by side: their scores, their pages by answer, their broken links and redirect chains, and every check with both counts and the change between them. A check one of the two did not run reads as not checked, and when the two ran different sets of checks the change in the score is not printed — a crawl that asked more questions is not a worse site.

The thinly linked list needs Search Console

The Links tab’s card of thinly linked pages that already earn clicks lists the pages few others on the site link to that Search Console says earn search clicks, most clicks first — the ones most worth linking to. It needs a Search Console connection to know which of them earn anything. Without one it says how many thinly linked pages the crawl found and that their clicks are not known, rather than reporting an empty list as though none of them earned anything.