The AI Engines Your Buyers Actually Use, and How Each One Retrieves

“AI search” is a category name, not a system. Behind the ten product names sit far fewer independent retrieval stacks, and the differences between those stacks decide whether your problem is crawler access, evidence density, or something you cannot change at all this quarter.

This page groups them by how they get their information rather than by vendor, because the vendor grouping tells you almost nothing operationally.

What are the three families?

Three ways an engine can know about you

1

Live web search

Fetches pages at query time through its own crawler and index.

Fails you when

Its crawler is blocked, or your pages do not survive chunking.

Responds in

Days, once recrawled.

2

Grounded index

Draws on an existing search index rather than a purpose-built crawl.

Fails you when

You are not indexed or not snippet-eligible in the parent search engine.

Responds in

Whatever your existing SEO cycle already is.

3

Training-data recall

Answers largely from what the model learned, with little or no live lookup.

Fails you when

You did not exist, or looked different, before the training cutoff.

Responds in

Model generations. Not this quarter.

Most real products blend families depending on how a question is asked. An assistant may answer a well-known factual question from memory and search the web for a current one, which is why the same engine can be accurate about you on Monday and wrong on Tuesday.

Which engines sit where?

Documented behaviour only. Where a vendor publishes nothing about its crawling or retrieval, this page says so rather than inferring, because a confident claim about an undocumented system is exactly the kind of thing this site exists to argue against.

“Not published” means we could not find vendor documentation describing how the engine retrieves. It is a statement about the documentation, not about the product.

Do engines stay in one family?

No, and this is the detail that makes single-run testing so misleading.

A live-search assistant does not search on every question. Asked something stable and widely known, it may answer from memory because that is faster and usually correct. Asked something current, specific, or unfamiliar, it goes and looks. The same product therefore behaves like family one on some prompts and family three on others, and you have limited insight into which mode you triggered.

Likely answered from memory “What is CRM software?”

Stable, general, unchanged for years. Nothing about your last quarter reaches an answer like this.

Likely searched “Best CRM for a 12-person field service team in 2026”

Specific, current, constrained. This is the question shape your evidence work can actually influence.

The practical instruction is to write prompts the way a buyer with a real constraint writes them. Specific, current and situated. Those are the questions that trigger retrieval, and retrieval is the only part of the system this quarter’s work can reach.

How do the families differ on citations?

Substantially, and it changes what you are able to measure on each.

The live-search family attaches sources because it just fetched them. Anthropic documents this explicitly for its web search tool: “citations are always enabled”, and each carries the URL, the title, and up to 150 characters of the text actually used. That gives you a citation rate to measure.

The grounded family cites too, drawing on links from the parent index. The recall family may name you with no source at all, because there is no fetched document to point at. That is a real mention with nothing for a link-based tool to count, and it is invisible to anything measuring citations alone.

Live search

Dense citations. Both mention rate and citation rate are measurable, and the gap between them is informative.

Grounded index

Cites links from the parent index. Citation rate here is close to a measure of your existing search performance.

Recall

Often no sources at all. Mention rate is the only number available, and citation rate is not a meaningful concept.

Why does the family matter more than the product?

Because it tells you which lever exists.

For the live-search family, the lever is access. OpenAI’s crawler documentation states that a webmaster “can allow OAI-SearchBot in order to appear in search results while disallowing GPTBot”, and that the settings are independent of each other. Perplexity documents the same split. That means a single robots.txt line decides whether you are eligible at all, and it is a line many sites wrote in a hurry.

For the grounded family, the lever is your existing SEO. Google states there are “no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary”, and that a page qualifies as a supporting link if it is “indexed and eligible to be shown in Google Search with a snippet”. There is no separate thing to do, which is good news that a lot of the category would rather you did not hear.

For the recall family, there is no lever this quarter. You can build evidence that reaches the next model generation, and that is the whole intervention.

One robots.txt decision, three different consequences

Live web search Blocking the answer crawler removes you outright. This is the family where a configuration mistake is total rather than partial. Decisive

Grounded index Governed by your existing search crawling. If Googlebot is fine, these surfaces are eligible. Already handled

Training-data recall Blocking the training crawler is a defensible choice with a long-dated cost: you are opting out of future models knowing you. Slow consequence

Why must Google’s three surfaces be counted separately?

They share an index and they do not share an answer. Gemini, AI Mode and AI Overviews can each say something different about you on the same day, because each retrieves to a different depth and each is triggered by different questions.

Collapsing them into one “Google” number hides the only interesting part. Appearing in AI Overviews but not in AI Mode is a signal about how deep the retrieval went for that question. Averaged away, it becomes noise; kept separate, it is a diagnosis.

Three products, one index, three answers. A tool that reports a single Google figure is telling you the average of three things you would have acted on differently.

Which ones should you actually track?

All of them if you can, and if you cannot, choose by family rather than by popularity.

Coverage, in the order it buys you information

1

One from live web searchChatGPT or Perplexity. This is where access problems show up first and most clearly, and where a fix is visible fastest.

2

One grounded surfaceAn AI Overviews or AI Mode reading tells you whether your existing SEO is carrying you into answers, which is a different question from whether you rank.

3

A second live-search engineTwo engines in the same family disagreeing tells you your evidence is thin rather than absent. One engine cannot show you that.

4

The undocumented ones, lastWorth measuring because your buyers use them, and worth measuring precisely because nobody can tell you how they work.

What should you actually change per family?

The work divides more cleanly than the vendor names suggest.

One programme, three targets

1

For live web search, fix access and structure

Allow the answer crawlers explicitly rather than relying on a wildcard rule, then make every section answer its own heading so a retrieved passage stands alone.

Both are cheap, and this is the family where a fix shows up fastest.

2

For the grounded family, keep doing SEO

Indexed and snippet-eligible is the stated requirement. Nothing separate is needed, and dismantling your search work removes you from these surfaces too.

The cheapest family to serve, because you are already paying for it.

3

For recall, build evidence and wait

Independent sources describing you consistently is the only input, and it reaches these engines on a model-release timescale rather than a campaign one.

Measure it, report it honestly, and do not promise a quarter-end result.

Two details are worth carrying into the robots.txt work, because the rules are specified rather than conventional. RFC 9309 defines that the most specific matching rule wins and that an allow beats an equivalent disallow. And robots.txt is not a hiding mechanism at all: Google states it “is not a mechanism for keeping a web page out of Google”, since a disallowed page can still be indexed when other sites link to it.

Does any of this change how you write?

Only in one respect, and it applies across all three families for the same underlying reason.

Retrieval scores passages rather than documents, and modern retrieval matches on meaning rather than shared words: Karpukhin et al. measured dense retrieval beating a strong term-matching baseline by 9 to 19 points on top-20 passage accuracy. So a section that can be lifted out and still make sense is a candidate for every engine that looks anything up, and repeating a target phrase buys less than it did.

Everything else that matters is off your site. Google’s own helpful content guidance still asks whether it is self-evident who authored your content, which is the one attribution signal entirely within your control, and after that the corpus decides.

What does the split mean for measurement?

Two things, and both are reasons to keep per-engine figures visible rather than rolled up.

First, engines in different families should be expected to disagree, so a single blended score averages across systems that had different information available. Second, they respond on different clocks: an access fix lands on the live-search family within days of a recrawl, reaches the grounded family on your normal indexing cycle, and does not reach the recall family at all until a future model. A blended number moving slowly could be three numbers moving at three speeds.

The engines we track, and which of them need browser automation rather than an API, are listed in the engine reference. Why retrieval and generation fail differently is in the RAG explainer, and if you want to know which of your own engines is failing you, the no-budget audit covers running the same prompt set across several of them properly.

Does the number of engines matter, or the mix?

The mix, and the distinction is worth arguing about before you buy anything.

Vendors compete on engine count because it is the easiest number to put on a pricing page. But four engines from one family tell you one thing four times, and they fail together for the same reason. Two engines from different families tell you two independent things, and when they disagree the disagreement is itself a diagnosis: retrievable here and not there means your evidence is thin rather than absent, and that is a different problem from being invisible everywhere.

There is a second reason the mix matters more, which is that the families move on different clocks. If your coverage is entirely live-search, every number you have responds within days and you will conclude the whole discipline is fast. If it is entirely grounded, everything tracks your SEO and you will conclude AEO is just SEO. Both conclusions are artefacts of the sample rather than findings about the world.

Buy coverage that spans the failure modes. If a tool offers a long engine list but all of its cheap tiers are one family, the headline number is not describing what you would actually learn.

One closing caution about this page specifically. Product behaviour in this category changes faster than documentation does, and three of the ten publish nothing at all. Treat the family assignments as current best reading rather than settled fact, and re-check before you build a strategy on any single row.