Your “AI Visibility Score” Is a Number Nobody Can Defend

Why I built an SEO/AEO/GEO tool that refuses to tell you how visible you are

Originally published by Mike Holownych on July 18, 2026. Nebula Components is now the canonical home for this article. The Medium version remains a syndicated distribution surface.

Here is a test you can run on any AI visibility tool on the market today.

Ask it one question: “Show me the evidence behind this score.”

Not the methodology page. Not the marketing explainer. The actual evidence. The captured robots.txt at the moment of the audit. The headers. The schema as extracted, not as intended. The specific prompt that was run, the specific answer that came back, the date it came back, and a checksum proving none of it was edited afterward.

Most tools cannot produce this. They produce a number. The number goes in a slide. The slide goes to a stakeholder. And when the stakeholder asks “why did we drop twelve points,” the honest answer is: nobody knows, because the score was never reconstructable in the first place.

I spent twenty-plus years in regulated infrastructure and incident response. In that world, a claim you cannot reconstruct is not a claim. It is a liability. So when I started auditing sites for search visibility, answer-engine citation, and generative representation, I built the tool the way I would build anything else that has to survive a dispute.

That tool is Citable. It is open source, Apache-2.0, and it does something almost nothing in this category does: it tells you, in writing, what it cannot know.

The category has an honesty problem

SEO, AEO, and GEO tooling has converged on a business model that rewards confident numbers over defensible ones. “Your AI visibility is 74.” Seventy-four of what? Measured how? Against which prompts, which engines, on which day, with which model version?

The uncomfortable truth is that nobody controls whether a generative engine cites you. Not the tool vendors, not the consultants, not you. What you control is eligibility: whether your site is technically crawlable, whether your claims are substantiated, whether your entity information is consistent, whether your evidence is current. Everything downstream of eligibility is probability.

A tool that sells you certainty about probability is not measuring anything. It is laundering guesswork through a dashboard.

So Citable’s first design decision was a refusal, stated in the README where nobody can miss it: nothing it produces guarantees crawling, indexing, ranking, citation, recommendation, inclusion, sentiment, or conversion. It manages eligibility, evidence, and probability. If that sentence costs it customers who want a magic number, good. Those customers are buying something that does not exist.

What “fail-closed” looks like in content governance

The core of Citable is not the detector count, though the current repository documents 181 detectors across 19 namespaces. The core is a claim governance model borrowed from how regulated systems handle authorization: fail closed.

A concrete scenario. Your marketing site says “trusted by 200+ enterprise customers.” In most content workflows, that sentence lives forever. Someone wrote it in 2024, it was roughly true then, and no process exists to challenge it. When an answer engine ingests your site and repeats the claim, you are now publishing an unverifiable statement through a channel you do not control, at a scale you cannot see.

In Citable’s model, that sentence is a claim, and claims are registry objects with rules:

• A claim cannot reach “verified” status without linked evidence. Not a note saying evidence exists. The evidence itself, registered, with provenance.
• Evidence expires. When it does, the claim’s verified status is invalidated automatically. Your 2024 customer count does not get to be true by inertia in 2026.
• If a detector needs a fact it does not have, it does not guess. It returns blocked with required_input and stops. Missing information is a halt condition, not a gap to paper over.
• Schema markup is never fabricated to satisfy a checklist. If the underlying fact is not established, the structured data does not get generated.

Every audit run produces an evidence package: manifest, findings, captured artifacts, checksums. Six months later, when someone asks why a decision was made, you replay the package. The audit is not a score. It is a record.

Documenting what the tool cannot do

The part of the repository I am proudest of is the one most vendors would delete: known-limitations.md.

It states, plainly: provider coverage is uneven. Google URL Inspection, GSC Search Analytics, GA4 Data API, and CrUX have live API paths, while Bing index evidence and consumer answer-product observations still require owner exports or disclosed adapters. An API adapter is not presumed equivalent to ChatGPT, Perplexity, Copilot, or another consumer mode.

Browser rendering is optional. When the required browser tooling is installed, Citable can capture desktop, mobile, JavaScript-disabled DOM, screenshots, failed requests, and bounded runtime evidence. That still does not prove semantic, retrieval, citation, marketing, or conversion impact. Core Web Vitals checks remain infrastructure-readiness checks, not proof of field performance.

Heuristic detectors are marked deterministic: false, carry documented false-positive conditions, cap their own confidence, and flag for human review rather than convicting. Citable also exposes composite measures such as Evidence Verifiability Score and Citation Alignment Score as formulas in report templates rather than computing them when the observation volume cannot support an honest number. The formula is real. The number would be theater. So you get the formula.

Publishing your limitations feels like a competitive disadvantage right up until your user hits one. Then it is the difference between a documented boundary and a silent lie.

Why this is an agent skill, not just a CLI

Citable installs as a skill into coding agents from one canonical source: npx @nebulacomponents/citable install. That distribution choice is not incidental.

Agents are increasingly the ones touching production content: rewriting pages, generating schema, adjusting metadata. An ungoverned agent optimizing for “SEO improvement” will happily fabricate structured data and inflate claims, because that is what the objective function rewards. Putting the governance layer inside the agent’s operating context means the fail-closed rules apply at the point where content is created, not in a quarterly audit after the damage is indexed.

The current repository includes an AGENT namespace for checking whether sites are legible to agents, including crawler rules, llms.txt, MCP server-card discovery, A2A agent cards, and content-signal headers. The sites being read and the agents doing the reading are converging on the same discovery surface, and it deserves the same audit rigor as classic crawlability.

Even the installer follows the doctrine. Managed installs carry a manifest with SHA-256 hashes. Updates compare the complete managed tree. Uninstall removes only managed files. Modified installs are refused without an explicit --force. If a tool preaches evidence and integrity, its own installation had better be verifiable.

The bet

The bet behind Citable is simple: as generative engines become a primary discovery channel, organizations will stop asking “what is our AI visibility score” and start asking “can we prove what we published, when, and on what basis.” The first question has no defensible answer. The second one is an engineering problem, and engineering problems can be solved.

If you answer for what your organization publishes, the repository is at github.com/mikeholownych/citable. Read the known-limitations document first. That is not a disclaimer. It is the product working as designed.

If you want to inspect how Nebula applies evidence-bounded thinking to public pages, start with the [Citable project surface](/resources/citable) or read the [landing-page conversion leaks guide](/learning-centre/topic-guides/landing-page-conversion-leaks).

How to use an evidence boundary in practice

The useful question is not whether a score feels sophisticated. The useful question is what decision the score is supposed to support. If the decision is whether to rewrite a page, change an entity description, or investigate a visibility loss, begin with the observation that can be checked by another person.

Start by writing the claim in ordinary language. Avoid a label such as “low AI visibility” until you can say what low means. A stronger working claim might be: “On 16 September 2026, the captured page exposed no Organization schema with an official name.” That statement has a URL, a date, an observation, and a bounded condition. It can be reviewed. It does not pretend to predict what a model will say.

Then separate the diagnosis from the recommendation. The missing schema may be a useful eligibility finding. The recommendation to add it is an interpretation based on the page purpose and the information available. Neither statement proves that a search engine or answer engine will use the change. Keeping those steps separate makes the resulting work easier to challenge and easier to improve.

A practical review can follow five steps:

1. Define the decision the analysis is meant to inform.
2. Write each important claim as a statement that another person could inspect.
3. Attach the captured source, retrieval time, and relevant excerpt or field.
4. Mark the claim as supported, unverified, contradicted, or interpretive.
5. Recheck the evidence when the page, source, or validity period changes.

This process is slower than copying a headline score into a slide, but it gives a team something better than false precision. It gives them a trail from observation to action.

What a defensible visibility review should contain

A useful report should let a reader answer four questions without a private explanation from the analyst. What was inspected? What was found? What does the finding establish? What does it not establish?

For example, a robots.txt capture can establish what that file returned at a particular time. It cannot establish that every crawler obeyed it, that a page was indexed, or that a model cited the organization. A schema capture can establish which structured data was present in the rendered representation. It cannot establish that the markup was interpreted correctly or that it changed a ranking outcome.

This distinction matters when a team chooses what to fix first. Technical eligibility findings are often actionable because they describe a condition the organization controls. Retrieval and citation outcomes are observations of an external system. They can be measured when an appropriate observation exists, but they should not be promised as a direct consequence of a markup change.

Use a short evidence table for consequential claims:

The boundary column is the part most often omitted. It prevents a narrow observation from quietly becoming a universal statement. It also tells the next person what must be captured if the question changes.

Questions to ask before trusting a number

When a tool reports a composite score, ask what its components are and whether those components are observations or assumptions. Ask whether the same inputs would produce the same result later. Ask which provider, prompt, model version, URL, and retrieval date were involved. Ask what happens when an input is unavailable.

A trustworthy system can answer those questions or clearly state that it cannot. It should not replace an unavailable source with a plausible value. It should not turn a heuristic into a fact by displaying it with two decimal places. It should not hide uncertainty because uncertainty makes a dashboard less impressive.

The practical payoff is not merely defensive. Evidence-bounded analysis improves prioritization. A team can fix a known inconsistency, preserve the before state, and then decide what observation would show whether the change mattered. That is a more useful learning loop than treating a score movement as proof of causation.

A small operating checklist

Before accepting a visibility finding, check that the source is identified, the retrieval time is recorded, the claim is stated narrowly, and the evidence is still available. Check that interpretation is labeled as interpretation. Check that a missing input produces an explicit unknown or hold state instead of a guessed result. Finally, record the next observation that would change the decision.

The goal is not to remove judgment from SEO, AEO, or GEO work. Judgment is necessary. The goal is to make judgment visible, bounded, and reviewable. When an organization can show what it observed, what it inferred, and what remains unknown, it can improve its content without building its strategy on a number nobody can defend.