Self-audit — this site scores 100 on its own scanner

What was measured, and when?

The subject is this site’s homepage at /: the HTML next build wrote for it, which is what a crawler receives, together with the site’s robots.txt, llms.txt and sitemap.xml. The analyser is the same one the public /api/scan endpoint runs; no part of the page was scored by hand. The measurement was taken on 9 November 2026 and written to lib/self-audit.json, the file this page and the homepage both read.

One URL, not a site. The free scan reads a single page, so the figure describes the homepage and says nothing about the pages linked from it — the guides, the rule reference, the study. A homepage is also the hardest page on a site to score well on: it is short, navigational, and carries less of the evidence an answer needs than an article does. That is a reason to read the number as a measurement rather than as a summary of the whole site.

What did the measurement find?

The record reads 100 out of 100, grade A — excellent readiness — the page has what a citation needs. Of the checks that applied, 40 of 40 passed, which is 100% of the applicable set; 0 rules were excluded and 0 checks failed. The record, field by field:

The table is generated from the record, so it is not a second copy of the numbers that could disagree with the first. The record itself is published in the repository as lib/self-audit.json, in exactly the shape above.

Which rules were marked not applicable?

None on this measurement: every rule in the catalogue could judge this page, so the denominator is the full catalogue and nothing was excluded.

The rule that used to be excluded here is hreflang: it now passes, because the homepage and the pricing page are published in five additional languages and declare the full language matrix. What changed, and when, is on the method changelog.

Which checks failed?

None on 9 November 2026: the record's failure list is empty, so 0 of the 40 applicable checks failed. The empty list is rendered here rather than the section being removed, because a report that deletes its empty sections cannot be told apart from one that never had them.

A failure is a claim about the page at the moment it was measured, not a permanent verdict. The live report shows whether a check still fails now, with the evidence the analyser saw; this page keeps the dated record, because an undated claim about a failing check is a memory rather than a measurement.

Why is there a page for this, when the live report already exists?

The homepage presents its own score as evidence and links the live report for the detail — and that link is a dead end for a crawler. The report at /report/ is the tool, not the document. It generates a result for whatever ?domain= it is given, with the 12 dimension scores and the evidence behind every check. That is exactly why it cannot be the evidence in an index: its output is user-specific, its URL space is unbounded, and it is deliberately excluded from both systems a crawler uses. The route’s own layout marks it noindex, and public/robots.txt disallows /report/ — and a disallowed URL is never fetched, so the noindex tag is never even read. The API has the same treatment: /api/ is disallowed as well.

That is why this page exists. It is the stable, indexable statement of the same measurement: one URL, the date, the result, the exclusion, the failures, the method and the limits. It does not reproduce the report — the report shows today’s evidence, and this page publishes the record of one measurement — but a crawler, and a reader who does not want to run a tool, can now see the claim the homepage makes without being asked to trust a route they are not allowed to open.

How is the number produced?

Step by step, all of it in the repository rather than in a spreadsheet:

1. The build writes the homepage. next build renders this site to static HTML; the homepage is the file at .next/server/app/index.html.
2. The record is measured, not typed. scripts/self-audit.mts (npm run self-audit) reads that HTML and the site’s robots.txt, llms.txt and sitemap.xml, runs the same analyze() the public endpoint runs, and writes lib/self-audit.json.
3. A gate keeps the page and the record in step. scripts/check-built-pages.mts (npm run check:built) scores the built homepage and fails when its score, grade, check counts or the id lists disagree with the record. The measurement date is deliberately not compared: it records when the measurement was taken, not a property of the page. A page edit that changes the score therefore fails the build until the record is re-measured.
4. A scheduled workflow refreshes it. .github/workflows/self-audit.yml rebuilds the site on a weekly schedule, re-measures, and commits the record only when it changed; a failed measurement leaves the last good record in place rather than publishing a number produced from a broken page. The deploy is then re-dispatched from the commit that contains the refreshed record, so the date printed here is the date of the last measurement and not the last edit.

The homepage imports the same record through lib/home-content.ts, so the two pages cannot quote different numbers, and the machine-readable twin at /markdown/ reads the same values again.

How can I re-run this measurement?

You do not have to take the number on trust. Both of these re-measure the page as it is at the moment you ask, and both are free:

• In a browser: /report/?domain=llmention-geo.com shows the 12 dimension scores and the evidence behind every check.
• As JSON: the public endpoint returns the headline numbers — score, grade, checks run and passed, page type, and how many checks did not apply — and adds the full dimension and issue list when brief=1 is omitted. It needs no key and makes no browser do the work.

curl "https://llmention-geo.com/api/scan?brief=1&domain=llmention-geo.com"

A re-run is a new measurement, not a lookup of this record. The page, its robots.txt and the rules can all have moved since 9 November 2026, so a different number would be a finding rather than a contradiction — which is why the date is printed next to the score. The endpoint is rate-limited per address, and the brief form exists so a study over many domains does not pull the full report from each one; the public study over large homepages is the example of that use.

What does a perfect score actually mean?

100 out of 100 is not the fraction of checks that passed. Each check is worth a fixed number of points inside its dimension, a dimension is scored as the share of its own points that were earned, and the 12 dimensions are combined by weight — AI crawler access alone carries 16% of the total. The result is a percentage of what could be assessed for this page, which is why the denominator above is 40 rather than 40.

Grade A begins at 90% of the scale and this record clears it. But a perfect score says exactly one thing: nothing that applied to this page failed. It does not say that every rule in the catalogue passed — 0 rules were excluded — and it is not a claim that the method is finished. It is a claim that this page, under this revision of the rules, on this date, had no applicable gap the analyser could see. That is a narrower and more useful sentence than a score having reached its maximum.

What does the number not tell you?

The limits are part of the measurement, not a footnote to it.

• It reads one homepage. An interior page can be failing checks the homepage passes, and this number would not move. The guides, the rule pages and the study are outside this figure.
• It does not ask any AI engine about this site. Nothing here measures whether ChatGPT, Claude, Perplexity or Google’s AI surfaces mention LLMention or cite these pages. It measures readiness — whether the page is in a state where being cited is possible. Mention tracking is a different measurement with a different data source, set out in the comparison with mention tracking.
• It is a snapshot. Markup, robots rules and content change; the record is dated for that reason, and the weekly workflow exists because a measurement nobody refreshes becomes a memory of a measurement.
• The method moves. Rules change when a measurement error is found, and every change that can move a score is recorded with its date in the method changelog. A score is only comparable with another score produced under the same rules.
• It is self-measurement. The same team writes the rules and the page, which is a conflict a number cannot resolve. What answers it is not a better claim but the published method, the record file, the build gate and the public endpoint — each of which a reader can check against this page. If a number here looks wrong, that is a bug report rather than a debating point: the contact page is the place to send it, and the about page says who is accountable for the record.