BlogProduct
AI visibility tracking: 3 of the 8 engines we ask cannot search the web
Read out of this repository on 29 August 2026, the answer engine registry Lantad ships carries 8 engines. Five are recorded as performing live retrieval and returning the sources they grounded in. Three are recorded as having no web access and no sources at all, and one of those three is the only engine a free run asks.
This post opens the registry that decides that for this product and counts it. Everything below about engines, tiers and plan coverage was read out of this repository on 29 August 2026, from core/src/engines.ts and core/src/config.ts, and computed by running the shipped functions rather than by reading the numbers off a page. Two further claims, about what OpenAI and Perplexity return in an API response, were read at those vendors' own documentation on the same day and are attributed where they appear. Nothing here is a scan result and no engine was queried for this post: this is a description of what a measurement asks, not a measurement. If you want the crawler half of the picture, whether a bot can fetch and read your pages at all, that is a different subject with its own glossary entry and its own failure modes.
In short
- AI visibility tracking is not one measurement: read out of core/src/engines.ts on 29 August 2026, 5 of the 8 engines in Lantad's registry are recorded as retrieving live and 3 are recorded as answering from prior knowledge with no web access, so a single averaged percentage would blend what a search index surfaced with what a model happens to remember.
- The retrieval split and the citation split are the same split in Lantad's registry on 29 August 2026: every one of the 5 engines marked as retrieving live is also marked as returning source URIs, and none of the 3 marked as having no retrieval returns any, so there is no engine that reads the web without saying what it read.
- Only 3 of the 8 engines are recorded as exposing the search queries they ran, so on 2 of the 5 retrieving engines a report can say which pages were cited and cannot say what was asked to find them.
- A Lantad free run asks exactly 1 engine, computed from PLAN_LIMITS and planSoldEngineCount on 29 August 2026, and that engine is the open-weight chain whose registry row records no retrieval and no citations, so a free run measures training data presence rather than live retrieval.
- OpenAI's own web search documentation, read on 29 August 2026, states that the sources field carries the URLs the model consulted and is often larger than the set shown as citations, so a citation count is a count of what was shown rather than of what was read.
| Engine row | Vendor | Retrieval | Returns sources | Returns queries | Tier |
|---|---|---|---|---|---|
| Open-weight models | Cloudflare | none | no | no | included |
| Gemini | live | yes | yes | free_tier | |
| DeepSeek | DeepSeek | none | no | no | paid |
| Grok | xAI | none | no | no | paid |
| Perplexity | Perplexity | live | yes | no | paid |
| ChatGPT | OpenAI | live | yes | yes | paid |
| Claude | Anthropic | live | yes | yes | paid |
| Google AI Overviews | Google via DataForSEO | live | yes | no | serp |
What does AI visibility tracking actually count?
It counts appearances in answers that a tool went and collected. That is the honest general description of every product in the category, and this site has already read ten of them at their own published pages. The interesting part is buried in the collecting. A run selects a set of prompts, sends each one to some number of engines, and reads the replies for a brand name and for source links. How many prompts, and how many times each, is a sampling question this site has already put figures on: a study of four AI search engines needed seven runs per prompt before a per brand visibility rate settled, and the arithmetic of how many prompts a run needs has its own post.
The question this post is about sits underneath the sampling and gets asked far less often, whether the work is filed under generative engine optimization or under answer engine optimization. Not how many times you asked, but what you asked. In this repository that is settled by a single exported array, ANSWER_ENGINES in core/src/engines.ts, which carries one row per engine with the model to call, the secret it needs, and three fields the module comment calls the honesty contract: retrieval, citations and fanout. Counted on 29 August 2026 the array holds 8 rows across 8 distinct vendor strings, and the three contract fields are what the rest of this post reads.
One thing those rows are not is a claim about consumer products. The registry carries two labels per engine on purpose, an operator facing one naming the model and its retrieval mode and a customer facing one naming the assistant, and the module comment is explicit that the customer facing name exists so a reader can tell two vendors apart rather than four models. Lantad calls each vendor's API. It does not drive chatgpt.com or the Gemini app, and a row labelled ChatGPT means the OpenAI API with a web search tool attached, not the product a person opens in a browser. That distinction is worth holding on to while reading every figure below, and it is the same distinction that makes a Gemini citation tool not an AI Overview tool.
Flow: Prompts selected to Registry rows the plan buys; Registry rows the plan buys (5 of 8) to Live retrieval engines; Registry rows the plan buys (3 of 8) to Prior knowledge engines; Live retrieval engines (sources) to Answers read for name and sources; Prior knowledge engines (no sources) to Answers read for name and sources.
Three of the eight engines never touch the web
The retrieval field takes one of two values. Read on 29 August 2026, 5 of the 8 rows carry live and 3 carry none. The three are the Cloudflare Workers AI open-weight chain, DeepSeek and Grok. The five are Gemini with Google Search grounding, Perplexity Sonar, the OpenAI model with a web search tool, the Anthropic model with a web search tool, and Google AI Overviews captured from a public results page through a SERP vendor.
None of that is an accident or an oversight, and the source file says why in its own comments. The DeepSeek row records that it has no web access and no sources by design, that it measures training data presence for an assistant enough people use that its absence from the table would be a question, and that report copy renders the phrase prior knowledge only from that field rather than making any search claim. The Grok row records the same posture and adds a reason that is about money rather than capability: xAI's live search bills per source used, which no flat per call booking can honestly cover, so it is deliberately not wired.
Those are decisions recorded in a source file. They are not findings about the engines, and it would be wrong to read the table above as evidence that Grok cannot search, because xAI sells a product that can and this repository has chosen not to buy it. What the table does establish is narrower and still worth knowing before reading any number this product prints: three eighths of the engine surface answers from memory. A brand that has never been indexed by anything can still be named by all three, and a brand that dominates live retrieval can be absent from all three because the training cut happened first. Blending both into one percentage without saying which is which produces a figure that moves for two unrelated reasons, which is the same failure this site described when nineteen counted brand mentions turned out to be about two.
5 rows: retrieval live
- Gemini, Perplexity, ChatGPT, Claude, Google AI Overviews
- A search pass runs before the answer is written
- Source URIs come back with the reply
- Moves when the live web moves
- Costs real money or a metered free allowance per call
3 rows: retrieval none
- Open-weight chain, DeepSeek, Grok
- No search pass, no tool attached
- No source URIs exist to return
- Moves only when the model is retrained
- Report copy renders prior knowledge only from this field
The engines that do search return less than they read
The citations field says whether a vendor hands back the source URIs it grounded an answer in, and it matters for a reason that sounds pedantic and is not. An absent list and an empty list are different facts. If a report cannot tell them apart it will print a zero that means we could not read the sources in the same shape as a zero that means there were none, and a reader has no way to know which they got. The registry uses the field to keep those separate, and the same reasoning drives the fanout field on the search queries.
Counted on 29 August 2026, citations is true on 5 rows and false on 3, and it is true on exactly the same 5 rows that carry live retrieval. Every retrieving engine reports its sources and no non retrieving engine reports any. That is a tidy result and it is the ceiling rather than the floor, because what a vendor returns is not the same as what a vendor used. OpenAI's web search documentation, read on 29 August 2026, names the inline annotation type url_citation carrying a url, a title and start and end indexes into the answer text, and separately describes a sources field holding the full list of URLs the model consulted, which that page says is often more than the set shown as citations. A citation count is therefore a count of what an engine chose to display, and the set it actually read is larger by an amount the response will tell you and a headline percentage will not.
Perplexity's reference makes a second point that a table of yes and no values cannot carry. The chat completions response, read on 29 August 2026, documents a citations array of source URLs and a search_results array whose entries carry a title, a url, a date and a snippet, and both fields are optional rather than guaranteed on every response. A registry row reading yes means the vendor returns sources when it has them, not that a source list arrives every time. This is the same distance between a mechanism and an outcome that separates a citation count from answer influence, and it is why the honest reading of any of these numbers stays close to what was actually observed on the day.
what comes back from a retrieving engine
- OpenAI: annotation type url_citation (url, title, start_index, end_index)
- OpenAI: full consulted set sources, often more than the citations shown
- OpenAI: queries actually run web_search_call.action, usually but not always present
- Perplexity: source URLs citations, optional on a response
- Perplexity: result detail search_results (title, url, date, snippet), optional
- Three registry rows with retrieval none no source field exists to return
Only three engines say which queries they ran
Fanout is the third contract field and the thinnest coverage of the three. It records whether a vendor exposes the search queries it issued on the way to an answer, and read on 29 August 2026 it is true on 3 of the 8 rows: Gemini, the OpenAI row and the Anthropic row. It is false on the other five, which includes two engines that do retrieve. Perplexity and Google AI Overviews return the sources they grounded in and do not return the questions they asked to find them.
That gap decides what a report can say about cause. With the queries in hand you can see that an answer about running shoes was assembled from a search for best trail running shoes 2026 and not from a search for your brand name, which is the difference between being retrieved for a category and being retrieved for yourself. Without them you have a list of cited URLs and an answer, and any account of how one produced the other is inference. Two of the five retrieving engines are permanently in that second position, and the OpenAI documentation cited above adds a caveat even where the field exists, saying the search action usually but not always includes the queries that were searched.
This is the sort of limit that decides how a finding should be worded rather than whether it can be published at all. It is also why the useful unit of analysis in this category tends to be the source list rather than the query list: source lists are what most retrieving engines return, which is why studies of AI search work with them, including the audit that found 16 percent of cited sources were themselves AI generated and the measurement of how often citations point at somebody else's domain. Building the headline metric on the field five engines out of eight do not return would have produced a prettier dashboard and a narrower one. It is also worth remembering how thin the downstream effect can be even when a citation does land: referral data this site has reported put ChatGPT citations at 6.8 percent of prompts with the visit arriving on the homepage, so the queries a report cannot see are not the only thing standing between a citation and a customer.
A free run asks one engine, and it cannot search
Engine coverage is sold, so the count a given account gets is a commercial decision rather than a technical one, and it is worth reading it as such. The function planSoldEngineCount in core/src/engines.ts derives the total from the registry tiers plus two plan columns, and running it against PLAN_LIMITS in core/src/config.ts on 29 August 2026 gives three distinct answers across the plan rows: 1 engine on the free and inactive rows, 5 on the pro_monitor, deep_audit and fix_sprint rows, and 8 on the pro, business and retainer rows.
The free case is the one worth stating plainly, because it is the run most people will ever see. A free run carries exactly one engine, and the config comment says why in one clause: free runs get the chain alone. That chain is the Workers AI open-weight row, whose registry entry records retrieval none, citations false and fanout false. So the number on a free run is a count of how often open-weight models name a brand from training data, with no live retrieval anywhere in it and no source list to inspect. It is a real measurement of a real thing. It is not a measurement of whether AI search surfaces you this week, and those two get called the same words in this category constantly.
The five engine case has a similar shape and is less obvious. Paid engines are taken in registry order, which the ladder in config.ts fixes as DeepSeek, Grok, Perplexity, then OpenAI, then Anthropic. A plan buying three paid engines therefore buys DeepSeek, Grok and Perplexity, and its five engine run is the open-weight chain, Gemini, DeepSeek, Grok and Perplexity. Two of those five retrieve. Three do not. Reading the plan tiers on the pricing page as a ladder of how much web you are looking at rather than how many engines you are buying gives a more accurate picture of what changes as you move up it, the prompt tracker is where the resulting answers are actually shown, and what AI says is the surface that puts an engine's own words in front of you rather than a score derived from them.
| Plan row | Paid engines bought | Engines asked | Of those, retrieving |
|---|---|---|---|
| free | 0 | 1 | 0 |
| inactive | 0 | 1 | 0 |
| pro_monitor | 3 | 5 | 2 |
| deep_audit | 3 | 5 | 2 |
| fix_sprint | 3 | 5 | 2 |
| pro | 5 | 8 | 5 |
| business | 5 | 8 | 5 |
| retainer | 5 | 8 | 5 |
What this count does not tell you
The limits here are wide enough that listing them is most of the value. No engine was queried for this post. Nothing below the registry was tested, no answer was collected, no brand was counted and no accuracy claim is being made about any vendor. Every figure in this article is a count of rows in two files in this repository, or a sentence quoted from a vendor's own reference page, and the dates on both are 29 August 2026.
The registry fields are also a record rather than an observation. A row reading citations true means somebody read a vendor's documentation and wrote down that the API returns source URIs. If a vendor changes that tomorrow, the row is wrong until a person edits it, and nothing in the build would notice. The same applies with more force to the retrieval field, which describes how this product calls an API rather than what a vendor is capable of: the Grok row records a deliberate decision not to buy live search, and reading it as a limitation of Grok would be a straightforward misreading of a comment that says the opposite.
What the count does support is a question to put to any tool in this category, including this one. Ask which engines it asks, how many of those engines retrieve, and whether the number it shows you separates the retrieving ones from the rest. The answer decides whether a moving line means the web moved or means a model was retrained. It is the same class of question as asking whether a crawler can reach your pages before believing a grade about them, which is why this site withholds a grade it cannot support and why the methodology page states what each number was computed from. If you are working the other end of this, the pages rather than the answers, prose parity and entity confidence are the two measurements that decide whether there is anything for a retrieving engine to find, and the platform guides for Perplexity and ChatGPT cover what each surface does with what it finds.
-
8 engines, 5 retrievingCounted in the repo Rows of ANSWER_ENGINES in core/src/engines.ts, read 29 August 2026. A record of how this product calls each API. -
1 engine on a free runComputed in the repo planSoldEngineCount run against PLAN_LIMITS in core/src/config.ts on 29 August 2026. A product decision, not a finding. -
url_citation and sourcesQuoted from OpenAI OpenAI's web search guide, read 29 August 2026. Reported, not tested: Lantad ran no request to confirm it. -
Optional citations arrayQuoted from Perplexity Perplexity's chat completions reference, read 29 August 2026. Reported, not tested. -
Any engine's real accuracyNot measured No engine was queried for this post. Nothing here says how well any of them answers or how often it names a brand correctly.
Lantad
Published .
Every tool in this category sells the same sentence: we will tell you whether AI mentions your brand. The sentence hides an engineering question that decides whether the number means anything, and it is not a question about sampling or about prompts. It is a question about which machine answered. Ask a model with a live search tool attached and you learn what a retrieval system surfaced this week. Ask the same model with no tool attached and you learn what its training data retained about you months ago. Both produce a confident paragraph naming brands. Only one of them is a statement about the web as it stands today, and nothing in the shape of the answer tells a reader which one they are holding.
Common questions
What is AI visibility tracking?
AI visibility tracking is the practice of asking AI answer engines a fixed set of questions on a schedule and counting how often a brand is named and which sources are cited. The figure it produces depends on which engines were asked: read from Lantad's own registry on 29 August 2026, 5 of its 8 engine rows perform live retrieval and 3 answer from training data with no web access, and those two things move for different reasons.
Does an AI visibility tool actually search the web?
It depends on the engine, and the answer is often mixed within one tool. In Lantad's registry, read on 29 August 2026, the Gemini, Perplexity, OpenAI, Anthropic and Google AI Overviews rows are recorded as retrieving live, while the Workers AI open-weight chain, DeepSeek and Grok rows are recorded as having no retrieval. An engine with no retrieval measures what a model retained from training rather than what a search index holds now.
Why does it matter whether an engine returns its sources?
Because without them a report cannot distinguish an engine that found nothing from an engine that never reports sources at all, and it cannot show you the pages behind an answer. In Lantad's registry on 29 August 2026 the 5 engines that retrieve are the same 5 that return source URIs. OpenAI's own documentation, read the same day, adds that its sources field is often larger than the citations it displays, so a citation count is a count of what was shown rather than of what was read.
How many engines does a free Lantad run ask?
One. Running planSoldEngineCount against PLAN_LIMITS on 29 August 2026 gives 1 engine for the free plan row, and the config comment states that free runs get the chain alone. That engine is the Workers AI open-weight row, whose registry entry records no retrieval and no citations, so a free run reports training data presence rather than live retrieval.
See what AI can read on your site
Run a free scan and get a graded report of exactly what AI crawlers can and cannot read, with ranked fixes.
AI visibility
AI visibility is whether AI systems can access, read, and faithfully represent your web pages, the prerequisite for being cited in an AI answer.
Generative Engine Optimization (GEO)
Generative Engine Optimization (GEO) is the practice of structuring and publishing content so that generative AI engines can fetch it, read it in full, and cite it when they answer a question.
How many prompts an AI visibility measurement needs
A study of 374,052 citations across Perplexity, OpenAI SearchGPT and Google Gemini found repeated runs of the same query share as little as 0.29 of their cited domains, and that a confidence interval five percentage points wide on citation share needs roughly 40 queries on one platform and 150 or more on another.
Nineteen counted brand mentions, and about two were the company
Lantad's prompt tracker reported a 12.6 percent brand mention rate on its first live run on 13 August 2026. The truth was near 1 percent: of the 19 counted mentions, eight were an engine defining a Tagalog adjective, three resolved the name to a different business, and six were engines saying they had never heard of it. A name in an answer is presence, and presence is not identity.
A Gemini citation tool is not an AI Overview tool
What actually comes back when a tool asks Gemini a grounded question, why the cited URI can be a Google redirect rather than a publisher, and which parts of a citation table survive that.
