What you receive, and how to read it

The audit produces one page: a score out of 100, a ranked fix list, and a plain account of what the engine could not see. This is what each part means, and how much weight to put on it.

The score, and what is behind it

The number at the top is out of 100, and it is a weighted mean rather than a flat average. Performance, SEO and Security carry a weight of 1.4; Social and Reputation carries 0.6, Code Quality 0.7. A technically sound site should not be dragged down by a thin social presence, and a weak one should not be rescued by it.

Deductions saturate instead of stacking. Each further issue removes a share of the headroom that is left, so one critical costs 25 points, three cost 50 and ten cost 77 — always lower, never quite zero. The reasoning in the code is blunt: the fifteenth missing security header does less marginal harm than the first, because the site is already exposed. And nothing is ever scored 0. A page that loads at all is not zero out of 100.

Three severities, one weight table

Every finding is critical, warning or info, and every analyzer deducts from the same table: 20 points for a critical, 8 for a warning, 3 for an info. That table exists because the engine was once inconsistent — each analyzer used its own weights, so the same critical was worth a different number of points depending on which check raised it.

In plain terms: critical means a page is removed from search, or a visitor cannot do the thing the page exists for. Warning means it is costing you rather than stopping you. Info is low consequence or low confidence, and the ranking caps info findings on purpose, so a cosmetic one can never open your report however alarming the wording.

The three worth fixing first

Three findings sit above the category breakdown, and they are not the three most severe. "No H2 heading" and "noindex on the pricing page" can both be tagged warning, and only one is losing money. The order multiplies three measured signals: where the finding sits (a pricing or checkout page weighs 1.6, a contact page 1.4, the homepage 1.3, a terms page 0.5), what it blocks (stopping a page being found at all 3.0, exposing data 2.6, blocking a conversion 2.4, tidiness 0.7), and severity.

Each one prints the reasoning that placed it, in the engine's own words: critical that stops the page being found or reached at all; on a money page (URL segment "pricing"). You can argue with that, which is the point. The order is also stable — the same audit of the same site produces the same three.

Every finding names its page

The homepage tells you a site exists. The pricing page and the contact page tell you whether it sells. So the audit fetches up to three further pages, chosen from your own navigation or from sitemap.xml when the navigation is thin, and attributes each finding to the page it came from: "No form on the contact page — contact page (/contact)". The standard set in the code is a finding you can verify in ten seconds.

That pass is bounded and unhurried by design: three extra pages at most, fifteen seconds each, three seconds between requests. Hammering a host is what earns a block, and a page we were refused would then look like a page that is broken.

What could not be measured

Some checks cannot run — the headless browser fails to load the site, or the business has no physical premises, so a Local SEO score would be meaningless. Each is dropped out of the overall score and printed with the reason: not measured, excluded from the overall score rather than counted as zero. Real-user speed data follows the same rule. It comes from Google's Chrome UX Report, and where Google holds no field data for your site the report says so rather than substituting a lab number.

Two further lists sit outside the score: checks that need access nobody has from the public internet, and hardening work almost no site of your size has done yet. Both are shown for completeness. Neither counts against the score, and neither pads the issue count in the header.

It is easier to see than to describe. /sample-report is this engine run against this website — scores, findings and recommendations read straight out of the run, including eighteen findings a person overruled with the reason beside each, and thirteen checks that could not be measured. It carries the engine build that produced it, a fingerprint of the scoring and analyzer code, so a stale score is visible as stale.

What the engine checks here

Each of these is a rule in the code, not a category heading.

• Overall scoreA weighted mean of the categories that were actually measured. Performance, SEO and Security weigh 1.4; Accessibility, Content, UX and Trust 1.0; Privacy 0.9; Analytics 0.8; Code Quality 0.7; Social 0.6. Categories that could not run are removed from the calculation, not counted as zero.
• Severity weightsOne shared table used by every analyzer: critical costs 20, warning 8, info 3. It exists because analyzers used to hand-roll their own weights, so an identical severity was worth different points depending on which check raised it.
• Saturating deductionEach additional issue removes a share of the remaining headroom rather than a fixed amount, so scores stay distinguishable at the bad end: one critical costs 25 points, three cost 50, ten cost 77. Exactly 0 is never used.
• Impact ranking, with its reasoning shownThe top three multiply page role (money 1.6, contact 1.4, homepage 1.3, legal 0.5), issue class (blocks traffic 3.0, exposes data 2.6, blocks conversion 2.4, hygiene 0.7) and severity. Each prints the signals that placed it, so the order can be checked rather than taken on trust.
• Page attribution on every findingFindings discovered on the pricing or contact page carry that page's URL and are labelled with it — "pricing/product page (/pricing)". A finding with no page named is a finding you cannot check yourself.
• Unmeasured, with the causeA check that could not complete is recorded as unmeasured with the reason — HTTP status, request failure, no headless browser, no physical premises, no field data — and excluded from the score. It never becomes a defect and never becomes a zero.
• Not assessed remotely, and hardeningChecks needing access we do not have from the public site, and hardening steps almost no small site has taken yet, are listed in their own sections. Neither is scored, and neither is added to the issue count in the report header.
• Engine build fingerprintEvery report is stamped with a hash of the scoring and analyzer source that produced it. If that logic changes, the fingerprint changes, so an old score can be identified as stale instead of quietly trusted.

Questions

Is the score comparable to a score from another tool?

No. Different tools weight different things, and a number out of 100 only means something inside the system that produced it. Ours is comparable across our own runs — same weights, same severity table — and the report carries the engine build, so you can tell whether two scores came from the same logic.

Why does a category show a dash instead of a number?

Because that check could not run, and the reason is printed beside it. It is not a zero, and it is left out of the overall score entirely. If the check needs something we did not have — a live domain, a page that loads in a headless browser — say so and we can run it again.

Can I see a real report before I buy one?

Yes. /sample-report is this engine pointed at this website and published unedited, including the findings that are not flattering. No client report is published anywhere on this site, and yours would not be either.

Sources

Public and checkable. Nothing here rests on a number we cannot point at.

• Google — defining the Core Web Vitals metrics thresholds
• Chrome UX Report API — real-user field data