A scan report is a statement about one domain on one date under one version of the rubric. Everything on the page follows from that. The score is not an opinion about your site; it is the sum of 27 checks, each of which shows you what it captured and how many points it awarded.
This is a walk through the page from top to bottom, section by section, so that when you open your own report you know what you are looking at and what to do with it.
The header
Under the domain name is a single line that fixes the context of everything below it: the date of the scan, the rubric version it was scored under, and the site type it was scored as. The site type is one of e-commerce, SaaS, content or general, and it matters because check C5 (commerce actionability) only applies to commerce sites. For everyone else its four points are redistributed across C1 to C4, so a non-commerce site can still reach 100.
There is also a re-scan link. Results are cached for seven days, so if you have shipped a fix and want to see it reflected, re-scan rather than waiting.
The score and the four bars
On the right of the page is the score dial and, under it, four bars, one per pillar: discovery and access, understanding, actionability, and trust and freshness. Each pillar is worth 25 points, so a bar at full width means that pillar's checks all passed.
The bars are the quickest way to see the shape of a problem. A site with three full bars and an empty first bar is usually being blocked at the edge before anything else can be measured. A site with a full first bar and a weak second bar can be fetched but not understood. The total maps to a grade as follows.
| Grade | Score |
|---|---|
| A+ | 95–100 |
| A | 85–94 |
| B | 70–84 |
| C | 55–69 |
| D | 40–54 |
| F | 0–39 |
What to fix first
The first section in the main column is a numbered list of at most five items. It is the same list the scoring engine produces, and the ordering is part of the product rather than a presentation choice.
Only checks that failed or scored partial credit are eligible. They are sorted by impact first, from high to low, then by effort, from low to high, and any remaining ties go to whichever check has the most points still on the table. Impact is derived from the check's point weight rather than set by hand, so a five-point check always ranks above a two-point one. Effort is the rating published in the rubric: Low for something you can upload, Medium for template and schema work, High for rendering architecture, machine endpoints or checkout.
Each item shows the check id (linked to the methodology page), its name, its impact and effort, and a recommendation written for that specific result. If every applicable check passed, this section is replaced by a note saying there is nothing left to fix. We would rather say that than manufacture a list.
The practical rule is simple: work down the list. Anything marked high impact and low effort is a file you can publish this afternoon that moves the score immediately. The three tiers post goes into what each effort band involves.
Every check, with the evidence
Below the fix list is the full run, grouped under the four pillars. Each check is a card with five things on it.
The check id, which you can look up in the methodology to read exactly how it is evaluated. A status pill: Pass, Partial, Fail or Not applicable. The check's name. The points earned against the points possible, for example 2/4. And, if the status is anything other than Pass, the recommendation.
Partial is worth paying attention to. Several checks award points in pieces. A3 gives one point for the sitemap existing, one for it parsing with at least one URL, and one for it being referenced from robots.txt, so 2/3 tells you exactly which piece is missing. A2 is scored proportionally to how many of the six named AI crawlers are permitted, so 4/6 means two of them are being refused somewhere.
The evidence block
Every card carries a collapsed section labelled "What we captured". Open it and you get the raw evidence for that check as JSON: the URLs fetched, the status codes returned, the values parsed, the counts compared against the threshold.
This is the part of the page that makes the rest of it trustworthy. If A5 says a bot user agent received a 403, the evidence block shows the request and the response. If B4 says the meta description is too long, the block shows the description and its length. If you disagree with a result, this is where the argument starts, and it is where you should look before assuming the scanner is wrong. The most common surprise in these blocks is an edge or CDN layer answering AI crawlers with a challenge page while robots.txt says everything is allowed; the two fetches post covers the other common one.
The evidence block is also what you hand to whoever will make the fix. A recommendation says what to change; the evidence says what the crawler actually saw, which is what a developer needs.
The sidebar
The remaining cards on the right are about the report as an object rather than its contents.
"Keep this report" emails you the permanent link and the ranked fix list. The report is already public; the form adds to it rather than gating it, and it is one message, not a mailing list.
"Want this fixed?" links to the full audit and to a booking page. The automated scan is deliberately shallow, six pages and a fixed set of probes, and the audit is where the judgement comes in.
If the grade is B or better there is a badge card. It shows the SVG and the exact markup to copy, a plain image inside a link back to the report. The badge updates when the score does, and it links to the evidence rather than standing alone.
"Own this site?" explains that the report comes from a public crawl and lets you claim the domain by proving you control an email address on it. Once claimed, you can hide the report or publish it again yourself. If you would rather we did not scan at all, disallowing AgentFriendlyRankBot in robots.txt is honoured automatically, and the page for an opted-out domain says so plainly: no crawl, no score, no report. The bot page documents the crawler.
The last card offers a scan of your own site and a comparison view between this domain and another.
How to decide what to do first
Read the fix list, then open the evidence for each item. Three questions settle most of it.
Is anything in pillar A failing? If bots are blocked or the raw HTML is empty, nothing further down the page can be seen by an agent, and fixing understanding or trust first is wasted effort.
Which items are low effort? Those go first regardless of position, because they are hours of work and they move the score at once.
Which high-effort items are actually worth it for your site? Server-rendered parity (A7) is expensive and sometimes decisive. Machine endpoints (C4) is expensive and, for a lot of sites, the cheapest available differentiation because almost nobody has done it. Commerce actionability (C5) matters only if you sell. The report cannot make that call for you; it can only show you the evidence and the ranking.
Check your own site
Run a free scan, open the evidence blocks, and read them against the rubric. If the biggest item is in pillar A, start at /methodology#pillar-A; the fix is usually a file or a CDN setting, and it unlocks everything else.