Research updated
Every site has two versions. Human mode renders JavaScript, loads images, fills in dynamic content. Agent mode sees what AI crawlers actually receive — often far less.
Scores for audited brands sit behind sign-in.
What does an AI visibility audit actually check?
It fetches your site the way an AI crawler does, then compares that with what a browser assembles for a person, and reports every place the two disagree. The checks fall into groups a technical team can act on separately: which AI user-agents your robots.txt admits or refuses and whether those rules are honoured; whether a machine can discover your content at all through sitemaps, feeds and canonical links; whether your structured data says what your page says; whether the machine-readable surfaces an agent looks for are served rather than redirected; how your content is organised for a system that lifts a passage rather than ranking a page; and what the wider web already says about your brand. Nothing is inferred from a CMS setting. Every verdict comes from what your server actually returned.
Why does robots.txt not stop AI crawlers?
Because it was never an access control, and the specification says so. RFC 9309 states plainly that the rules it defines are not a form of access authorisation. The line that actually decides compliance is not training versus search, which is how most coverage draws it, but automated versus user-initiated — and the operators document this themselves. Perplexity writes that because a user requested the fetch, Perplexity-User generally ignores robots.txt rules. OpenAI writes that robots.txt may not apply to ChatGPT-User for the same reason. Anthropic documents no such exception for any of its three crawlers. So a disallow line is a request a crawler may decline, which means a policy you have not tested against your own server logs is a policy you do not have. The test is cheap: request a disallowed URL with each crawler user-agent and read the status code your own edge returned.
How does this compare with a traditional SEO audit?
An SEO audit optimises for a ranked list of links that a person reads and clicks. This measures something different: whether a machine that will never render that list can find you, parse you, and quote you accurately to someone who asked it a question. The two diverge hardest at the render gap. Much of what a browser assembles with JavaScript is simply absent from the document a crawler receives, so a page that looks complete to you can arrive nearly empty to the system deciding whether to cite it. There are also whole categories a search audit has no reason to inspect — reuse licensing, agent-facing endpoints, per-crawler access policy, whether your structured data contradicts your visible text. Ranking well and being citable are related, and they are not the same measurement.
How often does this need re-running?
More often than a technical SEO audit, because the things it measures are changed by other people without telling you. Crawler operators revise their bot documentation and add new user-agents on their own schedule; a network sitting in front of a large share of the web changed its default for AI training and agent traffic in September, for domains onboarding after that date, while leaving existing settings alone. Your own deploys move the other half: a framework upgrade that shifts rendering from the server to the browser can empty the document a crawler receives without changing a single thing a person sees. A sensible rhythm is on every significant site change, and again whenever an operator you care about updates its policy. The number you measured last quarter describes a web that has already moved.