What "a check did not run" means

A Website Audit runs on one of three paths, and not every check can be produced by every path. When the path that ran cannot answer a check, RankX AI reports it as not assessed, which is a real verdict: it is not a pass, it is not a failure, and it moves the score in neither direction.

This exists because the alternative was measured and it was bad. Seven checks were rendering confident green assurances, "canonical tags are present", "no duplicate content detected", "HSTS is enabled", for checks that had never run at all.

The three paths

They are genuinely different instruments. The crawl reads what a plain fetch returns. The instant path renders the page, so it sees things that only exist after the browser has done its work. The sitemap pass is not a page fetch at all.

Why the same check is not available everywhere

Three shapes of gap, and each has a different meaning:

The crawl has no equivalent. Some checks need a site-wide summary the crawl produces and the single-page path does not: whether a sitemap exists, whether robots.txt exists, whether a 404 page behaves, whether the certificate is expiring. Those are crawl-only, because the instant path looks at pages rather than at a site.

The browser sees something a fetch cannot. Layout shift is the clearest example. The value a plain crawl returns for it is structurally zero, which is exactly what an unrendered page reports whether or not the real page shifts. Reporting "layout shift is fine" from that number would assert a pass nobody measured, so it stays honestly not assessed on a crawl.

Nothing can answer it. Three checks have no field on any path. They stay in the taxonomy reported as not assessed on any path, rather than being deleted, because a visible gap records something a silent absence loses. Before this table existed, all three read as green ticks.

Reading a not-assessed list

It is not a list of problems. It is a list of questions this audit did not answer.

It usually has one cause. A large not-assessed count on a crawl is normally the checks that need the browser. A large count on an instant check is normally the site-wide checks that need a crawl.

The remedy is a different audit, not a fix. If a check you care about is not assessed, run the path that can answer it: specific pages for the rendered checks, a full crawl for the site-wide ones.

Do not report it as coverage of your site. In a client report, a not-assessed row means "we did not look", and presenting it as anything else is the failure this whole design exists to prevent.

The same principle, in three other places

This is one instance of a rule that runs through the whole product, and recognising it makes the rest of RankX AI easier to read:

• AI Readiness withholds a score entirely below a coverage floor, and never renders one without its coverage fraction.
• AI Visibility divides rates by checks with a known verdict, and reports a blank rather than 0% when none has one.
• Traffic refuses to report a figure at all when a Google connection is in any state but ready.

The single sentence behind all four: RankX AI distinguishes "we did not measure this" from "we measured this and found nothing", and never renders the first as the second. See null is not zero.

Which path assesses which check

Every check, with the paths that can produce a verdict for it, is in the issue reference. That page is generated from the product's own taxonomy, so it cannot claim coverage the audit does not have.

Where to go next

• The issue reference, for the per-check coverage.
• Page selection and cost, for choosing the path.
• Null is not zero, for the rule in full.