The two halves of AI visibility
Every conversation about AI visibility mixes two questions that behave completely differently. Separating them is the first useful thing you can do, because one has a deterministic answer you can act on today and the other does not have an answer at all.
| Retrievability | Mention | |
|---|---|---|
| The question | Can an assistant read your page? | Will it name you in an answer? |
| Where it lives | Your server | Somebody else’s model |
| Is it deterministic | Yes. Same request, same response | No. Same prompt, different answers |
| Can you change it | Directly, today | Only indirectly, over time |
| How you measure it | Request it and look | Sample prompts and hope the sample holds |
Most tools sold as AI visibility platforms measure the right-hand column. That is a real thing to want to know, but it is a lagging indicator of the left-hand column, and a site that fails the left cannot be fixed by watching the right more closely.
What actually makes a site invisible
In the scans we run, invisibility is almost never subtle. It is one of four things, and they fail in this order, with the earlier ones making the later ones irrelevant.
- The fetch never lands. A
robots.txtline, a CDN bot rule, or a challenge page written years ago against scrapers. Nothing on your side logs an error, because from your side nothing happened. - The response needs a browser. Prices, hours or fees that appear only after JavaScript runs are absent from what the agent receives, because the fetch runs no JavaScript.
- The facts are too expensive to reach. The agent reads under a token budget. A first substantive fact sitting behind tens of thousands of characters of navigation may be summarised badly or skipped for a shorter source.
- The facts disagree with each other. Your prose says one thing, your structured data says another. The assistant picks one, confidently, and you do not get to choose which.
How to measure the half you own
Three instruments, none of which is a dashboard of somebody else’s model output. Each answers a question about your own infrastructure, so each has a definite answer.
- A readability score against a published spec. Deterministic and rebuildable: the same page scores the same today and next month unless the page changed. The spec is public so you can check the arithmetic.
- Your own request log, by agent. Which platforms fetched you, how often, and what you served each one. This is impressions for the agent era, and it comes from your server rather than a sample.
- The miss log. The URLs agents asked for and did not get. It is the highest-value document in the whole project, because it names your next fix in the order the market is asking for it.
The fix is smaller than the category suggests
The serving-layer work is a one-time change rather than an ongoing programme, which is the part the market gets wrong. You answer Accept: text/markdown with the same facts in a cheaper format, and you keep serving browsers and search crawlers exactly what you served them before.
import { gateway } from '@rebilder/gateway'
export default gateway({
source: { kind: 'document', resolve: myPages },
})That is the whole intervention for most sites. The free tier covers 1,000 agent visits a month, the SDK is open and self-hostable, and nothing about it is metered at the edge.