Where every check comes from
Every one of Rubric's 44 scored checks traces to a real signal an AI engine uses to decide whether to quote a page. The checks are grouped into three pillars, Known, Findable and Trusted, and each check belongs to exactly one. Nothing is scored on taste: a check exists only where a measurable on-page signal changes citability.
- →Rubric scores 44 checks, each mapped to exactly one pillar: Known, Findable or Trusted.
- →Every check reflects an observable signal, entity clarity, a liftable answer, or a sourced fact, that affects whether an engine will quote the page.
- →The Issues tab shows the evidence behind each check, so a failing check points at the exact element that caused it.
- →llms.txt is checked and reported but not scored, so it never counts towards the 44.
How are the 44 checks organised?
The 44 checks are organised by pillar, and each check belongs to exactly one of Known, Findable or Trusted. Each pillar is a question an engine asks: Known is "do they know who you are?" (discovery), Findable is "can they find the answer?" (retrieval), and Trusted is "do they trust it enough to quote you?" (citation). Grouping the checks this way means a low pillar score points straight at the stage where an engine gets stuck, rather than at a wall of individual issues. Your report shows a score for each pillar, and the weakest one is where the work starts.
What sits behind each check?
Every check reflects a signal engines actually use, tied to one of the three jobs above. A Known check reflects something that helps an engine resolve who published the page. A Findable check reflects something that helps an engine locate a clean, liftable answer. A Trusted check reflects something that helps an engine stand behind quoting you. Because each check is grounded in an observable signal, the Issues tab can show every check as an error or a warning with the source behind it. That evidence line is what lets you trace a failing check to the exact element on the page, rather than guessing what a low score means.
A few checks and the signals behind them
The table below shows how a handful of checks map to the pillar they sit under and the signal each one reflects. It is a sample, not the full 44, chosen to show the range.
| Check | Pillar | The signal it reflects |
|---|---|---|
| Organization and Person schema with sameAs | Known | Lets an engine resolve and attribute the page to a clear entity |
| Unique, non-duplicated title and meta | Known | Distinct pages are easier to tell apart and attribute |
| Answer-first opener (40 to 70 words) | Findable | Gives an engine a liftable answer near the top; AI Overviews answers run about 67 words median (Pew, 2026) |
| Question or claim-shaped headings | Findable | Match how people and engines phrase the query |
| Schema readable without JavaScript | Findable | Keeps structured data visible to engines that do not render JS |
| Statistics that carry a source | Trusted | Sourced facts are quoted more; the Princeton GEO study found citing sources about +40% and statistics about +37% visibility |
| Named author with E-E-A-T attribution | Trusted | Gives an engine a source it can stand behind |
| Freshness (updated within twelve months) | Trusted | The large majority of AI-bot crawl activity is on recent content (Seer, 2025) |
How do the checks map to the way engines work?
The pillars are not an arbitrary filing system. They map onto the three things an AI engine does in order: discover who published a page, retrieve a liftable answer from it, then decide whether the evidence is strong enough to cite. This discovery, retrieval and citation sequence is the method Rubric was built to measure, and it is why a check always lands in one pillar and not another. The method comes from CITED, the book by Chris McCarron that Rubric is the companion auditor to, and each check traces back to a chapter of it. If an engine cannot discover who you are, a perfect answer never gets attributed; if it cannot retrieve a clean answer, strong evidence never gets read. Fixing in pillar order, Known first, then whichever of Findable or Trusted is lower, follows the same sequence the engine does.
Where does render parity fit in?
Render parity is the match between what a browser shows after running JavaScript and what an AI engine sees when it does not run JavaScript. It sits behind the Findable check for schema being readable without JavaScript. This check exists because ChatGPT, Perplexity and Claude do not run JavaScript, so any schema or content injected by a script is invisible to them even though it looks fine in your browser. The check reads what those engines read, from the served HTML, and fails when your structured data only appears after the page's scripts run.
Why isn't llms.txt one of the 44?
llms.txt is checked and reported but not scored, so it never counts towards the 44. Rubric reads the file if it is present and flags it in the report, because it is worth knowing whether you have one. It stays out of the scored set because it is informational: engines do not yet act on it reliably enough for its presence or absence to move a citability estimate. Treat the llms.txt line in your report as a note, not a check you have passed or failed.