Absence from AI answers has two causes that look identical from the outside and cost about ten times different to fix. Either your material never reaches the model, which is a retrieval problem, or it reaches the model and loses, which is a reputation problem.
Nearly every wasted AEO budget we have seen comes from treating one as the other. A company with a blocked crawler buys a twelve month content retainer. A company that is perfectly crawlable and simply unknown buys another forty blog posts on its own domain. Both spend a year on the wrong thing.
Four tests separate them in an afternoon.
Test one: did a crawler actually arrive
Pull thirty days of server logs and count hits by user agent. You are looking for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot and Google-Extended. Not your robots.txt. The logs.
This distinction catches people constantly. Your robots file records what you intended to permit. The logs record what happened. A firewall rule, a bot management setting or a security plugin default can refuse a crawler that robots.txt welcomes, and nobody is notified. The protocol itself is standardised in RFC 9309, which is worth skimming once because it makes clear how much is advisory rather than enforced.
Zero hits from a given crawler over thirty days is a retrieval problem and you can stop testing. Nothing else matters until that is fixed, and it is usually fixed in an afternoon by somebody in operations.
The finding that ends most of these investigations early
Roughly a third of the sites we look at are blocking or throttling at least one major AI crawler, and in almost every case it was nobody’s decision. It arrived with a bot rule, a plugin default, or an attempt to cut server load during an unrelated incident.
The log read is the first thing in our free AI visibility check for that reason. It is binary, it is verifiable, and it decides whether the rest of the conversation is worth having.
Test two: can it describe you when you name yourself
Ask four engines, logged out, what your company is. This tests whether anything about you exists in either the model or the index.
Three outcomes and they mean different things. A correct description means you are present and readable, so your problem is further down. A description of a different company means entity resolution is failing and you have a disambiguation problem, which is its own category. Nothing at all, or a refusal, means you are absent from both training and index, which points back at test one.
The outcome people misread is the fourth one, which is a description that is correct but generic enough to fit any company in your category. That is not success. It means you were absorbed but nothing distinguishing survived, and it behaves like a reputation problem even though the pages are fine.
Test three: does it name you without prompting
Ask a category question without mentioning yourself. This is the commercially important test and the one that most cleanly separates the two causes when combined with test two.
If test two passed and test three fails, your pages are readable and nothing outside them vouches for you. That is the textbook reputation problem. The engine knows who you are when asked directly and has no reason to volunteer you, because volunteering requires corroboration from sources that are not you.
Test four: the question only you can answer
This one is the most diagnostic and the least run. Ask a question whose answer exists on your site and almost nowhere else. A specific integration behaviour, a documented limit, an unusual feature, a number from your own research.
If the engine answers it correctly and cites you, retrieval works end to end. Your pages are crawled, chunked, retrieved and quoted. Whatever is wrong is not retrieval, and no amount of on-site work will fix it.
If it cannot answer a question only your site answers, retrieval is broken somewhere between the crawler and the index, even if test one showed crawler hits. That usually means rendering, or passages that cannot be extracted, which is the territory covered in answer-first writing.
| Log hits | Describes you by name | Names you unprompted | Answers your unique question | Diagnosis |
|---|---|---|---|---|
| No | Any | Any | Any | Retrieval. Access. Fix before anything else |
| Yes | No | No | No | Retrieval. Rendering or extractability |
| Yes | Yes | No | Yes | Reputation. Readable, uncorroborated |
| Yes | Yes | No | No | Both. Fix extractability first, then corroboration |
| Yes | Wrong company | No | No | Entity resolution. Neither of the two. Fix identity |
| Yes | Yes | Yes | Yes | Working. Move to freshness and accuracy |
Why this is really differential diagnosis
The structure here is borrowed rather than invented. Clinical practice has a well developed method for separating conditions that present identically, and the core of it is choosing tests by how much they change your belief rather than by how easy they are to run. The reasoning is set out plainly in the standard clinical reference on differential diagnosis, and two ideas transfer directly.
The first is that a test is only worth running if its result would change what you do next. Most AI visibility reporting fails this. A visibility score that goes from 31 to 34 changes nothing about anybody’s plan, which means measuring it was decorative.
The second is that you rule out the cheap, high-impact cause before investigating the expensive one. Test one costs an afternoon and eliminates the most common cause outright. Running a content audit before checking the logs is the equivalent of ordering an expensive scan before taking a history.
Order matters more than sophistication. Run the four tests in the order given. Each one is cheap, and the early ones make the later ones unnecessary surprisingly often. Teams that start at test three because it is the commercially interesting one end up with a finding they cannot act on.
The bias you have to design around
You are diagnosing your own company, which makes you the worst available observer. The failure is predictable and it has a name. Once you suspect a cause you will read ambiguous evidence as supporting it, a pattern documented across decades of psychological research on how people evaluate evidence for conclusions they already hold.
Two cheap defences. Write down what each test result would mean before you run it, so the interpretation is fixed in advance. And have the scoring done by somebody who does not own the outcome, which in practice means not the person whose objectives include the number.
This matters more here than in most measurement, because the two diagnoses have such different implications for budget and headcount. Somebody who has already argued internally for a content programme will find the reputation diagnosis. Somebody who has argued that the site needs rebuilding will find the retrieval one.
The diagnosis is worth buying separately from whatever fixes it.
It is bounded, it takes days rather than quarters, and the answer changes the cost of everything downstream by roughly an order of magnitude. It is also the one part of this that an interested party should not be producing for you, which is an awkward thing for an agency to write and true anyway.
Ours is free and you keep the output whatever happens next. Book an audit call and take the findings to two other firms if you want a real comparison rather than a pitch.
What each diagnosis commits you to
Be clear-eyed about this before you pick a direction, because the two are not comparable purchases.
| Retrieval problem | Reputation problem | |
|---|---|---|
| Nature of work | Configuration and editing | Publishing, research and relationships |
| Who does it | Ops and whoever owns the CMS | Comms, founders, a specialist |
| Time to first signal | Days to six weeks | One to three quarters |
| Verifiable mid-flight | Yes, at every step | Barely. Mostly leading indicators |
| Can it be bought | Yes, and cheaply | Not directly. Paying for it removes what made it work |
| Risk of doing nothing | Compounding. Everything else is blocked | Slow erosion as competitors accumulate |
If you have both, and a fair number of companies do, sequence them rather than running them together. Retrieval first, because it is fast and because corroboration built while your pages are unreadable sends traffic and citations to pages that cannot convert them. The staged version of this is in indexed, retrieved, cited.
Run it quarterly, not continuously
These four tests are a diagnostic, not a monitor. Running them weekly will show you noise, because engines vary between identical queries and you will read variance as movement.
Quarterly is right, with the fixed twenty prompt set running monthly alongside for tracking. The two do different jobs. The prompt set in the twenty prompt test tells you whether things are changing. These four tests tell you why, and you only need the why when the what has moved or stubbornly refused to.
Related reading
- Why your SaaS is not showing up in ChatGPT. The longer diagnostic tree, with the specific failure modes behind each branch.
- A free way to check if AI has heard of you. Test two on its own, in more detail.
- Training data versus live retrieval. The other axis this sits on, and why it changes the timeline.
- How Perplexity chooses its sources. Why the same company can pass these tests on one engine and fail on another.
Start with the logs. Genuinely, before anything else.
It is the only test here with a binary answer, it takes an afternoon, and it eliminates the most common cause outright. Companies that run it first save themselves an average of one wrong quarter, which is worth more than any tactic on this site.
If you cannot get at your logs easily, or you want the four tests run properly at sample, send us the domain for a free visibility check. You get the crawler read, the transcripts and one named constraint, and we will tell you plainly when the answer is that nothing needs buying.
Shaban runs answer engine optimisation for B2B SaaS companies at Uncited Brands. He works the unglamorous end of the problem, mostly crawler access, retrieval diagnostics and measurement baselines, and publishes the tests that do not go his way alongside the ones that do.