What AI visibility tools actually measure
"AI visibility" gets used for two different things, and conflating them is where most buying mistakes start. One is mention visibility: whether an assistant brings you up when someone asks about your category. The other is retrieval visibility: whether an assistant that fetches your page can actually extract your facts from what your server returns.
Both matter, and they behave differently. Mention visibility is downstream of reputation, links, and whatever a vendor’s index happens to contain, so it moves slowly and you cannot inspect the mechanism. Retrieval visibility is decided by one HTTP response, which means it is measurable exactly, fixable this week, and the thing a tool can be held to.
The three layers, and why most tools only cover one
Every AI visibility stack draws from three layers. Almost no product spans more than one, which is why "best tool" is the wrong question and "which layer am I missing" is the right one.
| Layer | What it does | What it cannot do |
|---|---|---|
| Monitoring | Asks assistants questions on a schedule and records whether you were named | Tell you why, or give you a change to make. It observes an output, not a cause |
| Content | Shapes copy, headings and structured data so facts are extractable | Change what your server returns to a request that never renders your page |
| Serving | Changes the actual response: detection, content negotiation, clean structured text | Make an assistant like you. It removes the reason it could not read you |
The order matters more than the shortlist. A monitoring tool bought before the serving layer works reports a problem you already knew about, monthly, at a subscription price. Fix the response first, then monitor, and the monitoring has something to detect.
Eight questions to ask before you pay
Take these to any vendor in any of the three layers. The answers are more informative than the feature list, and several of them are answerable from a public page in under a minute.
- Is the methodology published? Not "proprietary algorithm". A document you can read, with a version on it, that says what is measured and how it is weighted. If a number is going to sit on your dashboard for a year, you should be able to argue with how it was calculated.
- Is the score reproducible? Same page, same version of the ruleset, same number. If a model is anywhere in the scoring path, it is not reproducible, and the trend line you are about to make decisions from contains its noise.
- Does it separate measured from inferred? Some checks read a fact directly out of a response. Others infer it. A tool that prints both as one number is telling you less than it appears to, and the mix should be visible on every result.
- Does it show its evidence? For each check, the bytes it scored from. Evidence turns a grade into a fix list, and it is the only way to tell a real failure from a fetch that went wrong.
- Can you run it yourself? A local or CLI path means you can check a staging build, a page behind auth, or a fix before deploying it. It also means you are not sending your URLs to a vendor to find out about your own site.
- What does it do with your data? Whether scans are published, whether your domain can be listed without your say-so, and whether removal is free. Ask specifically whether removal can be bought, because a vendor that sells removal has an incentive you do not want in its product.
- Are benchmarks gated? Peer comparison is only meaningful with enough independent sites in a bucket to keep any single one unidentifiable. Ask for the floor. We use 25 independent sites, and it is not a setting.
- What happens at the end of the trial? Specifically: do you keep the fix list. A report you cannot export is a rental of your own site’s facts.
What to measure free, before buying anything
Three checks cost nothing and will tell you whether you have a serving problem, which is the one worth fixing first. Run them before you shortlist.
- Fetch a page as an agent.
curl -H 'Accept: text/markdown' https://your-site/pagenext to a plain fetch. If both return the same theme HTML, agents are spending their context budget on your navigation, and no monitoring subscription will change that. - Score a URL against a published spec. The free scanner needs no account and shows the evidence behind every check. Take the baseline before you change anything, because a number taken afterwards proves nothing.
- Look at your own request log. Agent fetches run no JavaScript, so page-view analytics never saw them and no script ever will. Counting agent requests by platform, and how many your site answered, is first-party data you already generate and probably discard. The script-visible remainder, AI-referred visitors and browser-driving agents, is what the free Rebilder Tag counts; it complements the log rather than replacing it.
That third one is the underrated step. The most valuable list in this whole discipline is the set of URLs agents asked for that your site could not answer. It needs no vendor’s index and no other customer’s data to be useful, which is why it is worth having on day one.
What fixing the serving layer is worth
Two reference captures measure the same change against two kinds of page. Both are deterministic, built from committed fixtures with no live network, and re-verified on every build.
| Capture | Before | After |
|---|---|---|
| Commerce product page | 91,226 bytes | 1,315 bytes (−98.6%) |
| Clinic services page | 13,581 bytes | 1,412 bytes (−89.6%) |
The two are quoted separately and never averaged: a product page and a services page carry different amounts of chrome, and a figure invented between them would describe nothing. What both captures share is the ordering change. In the clinic page the opening hours move from character offset 10,152 of the HTML to line 8 of the response, and the fee list, absent from the page’s own structured data entirely, arrives complete.
- Content negotiation vs llms.txt, accurate retrieval
- ~4.2x
- 300k-domain study, mid-2026
- Conversion lift, AI-referred visitors vs search
- ~38%
- Cyber Week 2025 retail data
Where we fit, stated plainly
Rebilder builds a serving-layer tool, which is layer three above. That is a conflicting interest in a guide about how to choose one, so here is what we do about it: the criteria in this page are the ones we would want applied to us, the spec our score comes from is published and versioned, the scoring path contains no model and no randomness, and we do not rank products we have not run.
- The gateway is free and has no tier concept. It detects agents, answers
Accept: text/markdownwith text rendered from your own data, and passes humans and search crawlers straight through. Nothing about your site’s serving is metered. - The scanner and the spec are public. Any URL, no account, every check showing the evidence it scored from, against a ruleset with a version and a conformance corpus.
- Scanning is not publication. No domain is listed, ranked or badged without verified owner opt-in, and removal is free, self-serve and permanent. It cannot be purchased, in either direction.
- Benchmarks are k-gated at 25 independent sites. Below that floor, nothing renders rather than something approximate.