Methodology
This page describes how a finding is produced, in enough detail that you could disagree with us on specifics. If a method is not written here, it is not a method we use.
Each section below is marked Live, Built, or Planned. Live means it runs today, in the free check you can execute on this site right now. Built means the code, the schema and the tests exist and pass, and the site is deployed — what is missing is configuration, so no customer can use it yet. Planned means it is written down as method and not yet built. Three states rather than two, because collapsing the middle one either under-reports what exists or over-promises what you can use — and this page exists so you can tell which half you can run.
Written and reviewed by Vitor Barbosa · Editor
Responsible for the editorial standard of this site and for the methodology published on it. Reviews every page that makes a technical claim before it is published.
- Published
01
How evidence is collected
Live
We request pages over HTTP as an identified client, following redirects up to a declared limit and recording every hop. A subset of pages is also rendered in a real browser so that what the server sends can be compared with what a browser ends up with. We store the response headers, the raw HTML, the rendered DOM and a hash of each artefact, so any finding can be traced back to the exact bytes it came from. We read only: no form is submitted, no session is created, no state is changed.
02
Normative rules and our own heuristics
Live
Some rules restate a documented requirement — a status code, a valid structured-data type, a reciprocal hreflang. Those carry a link to the primary source. Others encode our judgement about what usually causes problems in practice. Those are labelled as heuristics, in the interface and in the report, and they are never described as official requirements. The distinction is visible on every finding because collapsing it is the most common way this industry misleads people.
03
What the language model is allowed to do
Built, not yet switched on
Deterministic rules run first, over evidence that was actually collected. A model never decides whether something was observed and never creates a finding. It is given an already-approved finding and its evidence, and it writes the explanation and the remediation in plain language. It must cite the evidence it was given, and it must return an explicit "insufficient evidence" result rather than fill a gap. Output that fails schema validation is discarded, not published.
04
How confidence is set
Live
Confidence expresses how sure we are that the observation is correct, not how important it is. A directly observed HTTP fact is near-certain. An inference about intent is not, and is scored accordingly. Confidence is shown on every finding, and no rule is published below our threshold at all — a check we could only make at lower confidence than that is not built, rather than built and shown with a caveat.
05
What we cannot see
Live
From outside your site we cannot see which queries you actually rank for, how often a page is crawled, what your users do after they arrive, or anything behind a login. We do not connect to those sources, so we do not report on them at all. What we will never do is estimate those numbers and present the estimate as measurement — a category that is left blank is more useful than one that is filled in with a guess.
06
How a fix is confirmed
Built, not yet switched on
A re-verification is a new audit, not an edit of the old one. It runs the same rules over the same URLs — the address is copied from the first run, never chosen again — and the two reports are compared rule by rule. The first report stays exactly as it was, so you can go back and read what it said. That is what makes a status change mean something: it changed because a rule ran and passed, not because a field was set. One thing it will never do is call a finding fixed when we simply stopped being able to measure it; a rule that went from failing to unmeasurable is reported as no longer comparable, which is bad news rather than good.
07
How to contest a finding
Built, not yet switched on
Every finding can be marked incorrect or not applicable, with a reason. Those go to a review queue, not to a void: a contested finding is emailed to the person who reviews them, and you get a copy of what you wrote. When a rule turns out to be wrong we deprecate it with an explicit reason, and reports that relied on it are flagged rather than silently left standing. Corrections are part of the method, not an admission that the method failed.