What the audit inspects

The technical audit checks observable website conditions such as public files, indexing directives, metadata, structured data, AI-related accessibility, discovery, and supported performance evidence. Normal audit checks are deterministic rather than an LLM inventing a site-health score. A technical pass does not prove that Google or an AI system ranks or recommends the shop.

Domain scope and access

The full workspace audit uses the configured website and supported verification or ownership workflow. Fetching an accessible public URL and verifying merchant control are different operations. The connected source and request constraints limit what can be fetched. A missing Google connection does not prevent every public HTTP check; unavailable PageSpeed evidence should not be replaced by fabricated performance data.

Check states and category scores

Applicable positive-weight findings contribute to category coverage. Verified findings contribute to the score: passed earns full weight, warning earns half weight, and other verified problem states earn zero. unable_to_verify remains outside the score denominator while lowering coverage. not_applicable is excluded. A category with no verified applicable weight has no score.

Example
Category calculation
verified weight = sum(weights of applicable known checks)
earned weight = sum(weight × outcome credit)
credits: passed 1; warning .5; other verified problems 0
category score = round(100 × earned / verified)
coverage = round(100 × verified / applicable weight)

Example: known weights 8, earned 6 -> score 75
If total applicable weight is 10 -> coverage 80%

Overall category weights and publication gates

The reviewed audit weights are files 20, indexing 25, metadata 15, schema 15, AI 10, performance 10, and discovery 5. The overall score weights categories with available scores. An incomplete audit or less than 50% coverage in any core category—files, indexing, or metadata—withholds the overall score. Incomplete total coverage caps an otherwise available score at 99. A critical failed finding caps it at 49. Coverage is shown separately so an inaccessible site cannot receive a misleading perfect score.

PageSpeed lab and real-user data

Where supported and configured, PageSpeed can supply Lighthouse lab results and available Chrome UX Report field evidence. Lab results describe a controlled test; field evidence describes eligible real-user observations over its reporting window. LCP, INP, and CLS are different metrics with different availability. Missing field coverage is common for sites without enough eligible observations and does not mean perfect performance or zero visitors. A mobile test and a desktop test are also different measurements.

Full audits versus targeted rechecks

A full audit is a versioned snapshot of a defined scope. A targeted recheck verifies an affected condition and should not be inserted as if it were another full-site trend point. A previously failing issue is resolved only when the relevant evidence is actually reverified; an inaccessible page cannot establish resolution. Opening the dashboard reads results rather than requiring a new scan each time.

Fixes, prioritisation, and limits

Open the finding, affected URLs, check date, evidence, and suggested remedy. Verify changes against the current site. Optional AI prioritisation, when available and explicitly used, interprets findings; it is not a substitute for a missing crawl or an automatic implementation. Keep technical health, search traffic, and AI recommendation outcomes as separate measures.

Search Console and interpreting search dataWeekly account synchronisation and background jobsCockpit periods, Search Console, and connector freshness