I was deep in thought about how much of a model hallucination is RLHF-based assumption in the absence of training data or context. Pretraining gives the model the ability to confabulate. Post-training often influences whether it chooses to confabulate rather than say "I don't know."
A base language model is trained to predict plausible continuations. If the evidence needed to answer is absent from its weights or context, there's no fundamental mechanism in next-token prediction that says "stop, evidence unavailable." It still has a probability distribution over tokens, so it generates the most plausible continuation. Hallucinations therefore exist without RLHF.
TruthfulQA demonstrated this with pre-RLHF base models such as GPT-3, GPT-2 and GPT-Neo/J: they confidently reproduced misconceptions learned from text, and the larger models were less truthful, not more.
But this is a slightly narrow point of view for web people like us. For us, when we think of hallucination we think of a model telling an untruth. Which the above is really a subset of.
Seen in the broader sense, hallucination decomposes like this:
I know what you're thinking, this is still narrow. We don't interact with bare models like this. We interact with fully fledged ecosystems with so many moving parts: model, system prompt, memory, retrieval, tools, planners, execution loop, verifiers, reward shaping, UI constraints, external state. What fancy people call harnesses.
In that environment an untrue response can arrive for a much wider variety of reasons:
Why even think about any of this? Well, because if you're to believe GEO is a real discipline, you have to believe you can impact some of these factors in a controlled way as an outsider. Otherwise there'll be nothing to optimise, right?
The important distinction is control over the model versus control over the evidence environment the model operates in.
Leverage is qualified the same way throughout: where a remediation requires you to operate a machine endpoint, the leverage is conditional on your doing so. Rows 4, 7 and 8 all carry that condition, and an earlier version of this table applied it only to row 4.
| # | Failure | Business leverage | Evidence | What the business can actually do |
|---|---|---|---|---|
| 1 | Base model invents a fact | Low | Strong that it happens; weak that businesses can fix weights | Improve the public factual corpus; correct authoritative third parties; allow training crawlers if you want to. Don't promise that publishing something changes model weights. |
| 2 | Wrong or stale retrieval | Very high | Strong | Crawlability, indexing, canonical URLs, freshness signals, authoritative pages, remove stale duplicates, correct third-party sources |
| 3 | Model misreads correct evidence | High | Strong to moderate | Make facts explicit, atomic, unambiguous, scoped, easy to extract. Reduce contradictory and verbose pages. |
| 4 | Wrong tool selected | High, if you expose tools | Strong and growing | MCP and API discovery, precise tool descriptions, narrow responsibilities, obvious capability names, good schemas |
| 5 | Planner invents assumption | Medium-high | Strong underlying evidence | Publish direct answers to likely ambiguous questions, and explicit negative facts, so retrieval resolves rather than infers |
| 6 | Incorrect memory | Low externally | Mixed | Make the current authoritative state easy to retrieve so live evidence can override memory. You can't normally edit another provider's memory. |
| 7 | Partial tool result treated as complete | Very high, if you expose tools | Engineering evidence stronger than GEO research | Design API and MCP responses with pagination, completeness, timestamps, status, errors, coverage boundaries |
| 8 | Provenance disappears | Medium-high, if you return machine-readable facts | Strong problem evidence | Attach source URLs, IDs, timestamps and claim provenance to every fact you return |
| 9 | Bad verifier | Low | Strong that verification design matters | Provide ground-truth endpoints a verifier could use. You don't control whether third parties use them. |
| 10 | Reward or system prompt encourages guessing | Very low | Strong phenomenon, outside business control | Almost nothing externally, except make uncertainty unnecessary by improving evidence availability |
| 11 | Agent trusts another agent's fabrication | Medium | Growing evidence | Provide provenance-rich primary evidence so downstream agents can check upstream claims |
| 12 | Final generator converts uncertainty into fact | Low-medium | Strong phenomenon | Make evidence decisive and machine-readable; you can't control another system's final-generation policy |
2, 3, 4, 5, 7 and 8. Those are the genuinely externally addressable hallucination surfaces. And this is much bigger than conventional GEO.
What follows adds something the argument didn't have when I first wrote it: measurements of how those six surfaces actually look across the web, rather than only arguments that they matter.
RAG exists precisely because supplying current external information reduces dependence on faulty parametric knowledge. Models frequently update an incorrect parametric belief when given correct external evidence, although strong priors can still cause resistance. Retrieval quality matters enormously: wrong, irrelevant and conflicting documents measurably degrade answer correctness.
A business can directly work on this. Suppose models incorrectly say "Lumar doesn't support JavaScript rendering." You want a canonical URL that states the fact plainly:
Does Lumar crawl JavaScript websites?
Yes. Lumar renders pages using Chromium and crawls content generated by client-side JavaScript.
rather than expecting the model to derive it from 1,800 words of marketing copy. Then make sure that page is crawlable, internally linked, canonical, indexed, current, server-rendered or otherwise trivially extractable, and not contradicted by three old documentation pages.
And here's the part I can now measure rather than just assert (Agentic readiness of the web, corpus scan). The retrieval substrate isn't in good shape. Of the 88,484 publishing hosts, 61,587 publish an XML sitemap and 21,448 of them break the format, about 35%. The single most common fault anywhere in the study is a sitemap sitting in a subfolder that lists URLs outside it: 14,176 sites, 23% of everyone with a sitemap. Google reads those URLs anyway if you submitted the file through Search Console, which is why so many teams have never seen it break. Hand the same file to anything that isn't Google and the out-of-scope entries are dropped.
The sitemap protocol was agreed in 2005. If the oldest, most boring piece of retrieval plumbing on the web is broken on a third of sites that bother to publish it, the idea that the evidence environment is already optimised and only model behaviour is left to tune doesn't survive contact with the data.
Basic freshness engineering matters too: Google [explicitly uses trustworthy lastmod values (https://developers.google.com/search/blog/2023/06/sitemaps-lastmod-ping) as a recrawling signal.
One correction worth making precisely, in an article about precision. For ChatGPT Search, OpenAI says that "sites that are opted out of OAI-SearchBot will not be shown in ChatGPT search answers, though can still appear as navigational links," and that they "recommend allowing OAI-SearchBot." That's narrower than "must be allowed to be eligible": you lose the answers, not the link. They separately state GPTBot "is used to crawl content that may be used in training our generative AI foundation models," which is the distinction that matters here.
It's also a decision very few sites have taken deliberately (corpus scan). 33,626 sites name at least one AI crawler in robots.txt, and only 4,289 of them name OAI-SearchBot at all, about one in eight. A caveat I won't skip:
naming a crawler isn't blocking it, and a crawl can't see which way a rule points. What the number shows is how few sites have made any explicit decision about the one bot that governs appearing in ChatGPT answers.
None of this is speculative "LLM SEO." It's improving the evidence retrieval systems have available.
This is where I'd invest substantially. Models do worse as irrelevant context increases, and evidence placement affects factual verification.
So stop asking "is this information somewhere on our site?" and start measuring:
Can a machine retrieve the smallest sufficient passage that answers the question without inference?
Those are very different standards.
Bad:
Our platform empowers modern enterprise teams through an advanced rendering infrastructure designed to help
organizations understand experiences across increasingly dynamic digital environments...
Good:
Does Lumar crawl JavaScript websites?
Yes. Lumar can render pages using Chromium and crawl content generated by client-side JavaScript.
This matters because you're reducing the amount of reasoning between evidence and claim. I'd call the metric something like inference distance: how many unsupported transformations are required to get from the source material to the desired factual answer. You want that close to zero.
This is where the agentic ecosystem gets interesting, and where I have the sharpest numbers.
MCP and tool-selection research shows measurable differences in models' susceptibility to misleading tool descriptions and overlapping capabilities. A 2026 study ran 8,640 agent runs and found substantial variation in wrong-tool susceptibility depending on tool design and model capability.
So if you expose:
{ "name": "query", "description": "Query the system" }
versus:
{
"name": "salesforce_get_account_by_id",
"description": "Authoritative source for Salesforce CRM account records. Returns the current
account owner, tier and renewal date for one account ID. Not for opportunities,
contacts or historical snapshots."
}
the latter makes epistemically correct tool selection much easier. You can't force an agent to pick your tool. But you can remove ambiguity from the decision.
And this is where the numbers get embarrassing (corpus scan). Across the 88,484 publishing hosts:
| Sites | |
|---|---|
| Publish an OpenAPI description | 497 |
| ...with a value whose type is never stated | 176 |
...with an operation that has no operationId |
112 |
...with two operations sharing one operationId |
66 |
| Publish an MCP server card | 368 |
| ...whose card doesn't say where the server is | 40 |
| ...whose endpoint doesn't speak MCP | 19 |
Look at row three again. 112 of 497 machine-readable API descriptions give an agent nothing stable to name a call by (corpus scan). That's not a theoretical concern about tool ontology. It's the concrete failure this section argues about, already present in 23% of the sites that have gone to the trouble of publishing a contract at all. And 40 server cards advertise an MCP server without saying where it is.
For businesses this suggests a new optimisation surface:
Don't merely expose an MCP server. Engineer its ontology so an agent can reliably determine when it is the > authoritative source.
Consider: "Why is Lumar more expensive than Screaming Frog?"
If neither company has published meaningful evidence, an agent will generate something plausible. Possibly complete fiction. A company can anticipate those inference gaps and publish the answer:
How does Lumar's pricing compare with Screaming Frog's?
They are priced for different jobs. Screaming Frog licenses a desktop crawler per seat. Lumar is billed on > crawl volume and retained history across a whole estate. A single-site audit is cheaper in Screaming Frog; > continuous monitoring of many domains is what Lumar is priced for.
Or, importantly, publish the negative:
Does Lumar offer a free tier?
No. Lumar does not offer a free or perpetually free plan.
Negative knowledge is particularly useful. Companies publish enormous amounts of X does Y and very little X does not do Y. False assumptions live precisely in that missing space.
Generative search research has repeatedly found provenance problems. Liu, Zhang and Liang's Evaluating Verifiability in Generative Search Engines
(Findings of EMNLP 2023) audited four engines by human evaluation and found only 51.5% of generated sentences fully supported by their citations, and only 74.5% of citations actually supporting the sentence they were attached to.
That study is worth citing carefully rather than waving at. It is from 2023, and it audited Bing Chat, NeevaAI, perplexity.ai and YouChat. NeevaAI no longer exists. It establishes that the problem is real and was severe; it doesn't describe 2026 systems, and I haven't found an equivalently rigorous replication since.
For a business-controlled machine endpoint, I'd therefore return facts more like:
{
"claim": "Lumar renders JavaScript using Chromium",
"value": true,
"source": "https://www.lumar.io/docs/crawler/javascript-rendering/",
"asOf": "2026-09-01",
"basis": "product documentation",
"supersedes": null
}
Not because the LLM necessarily needs every property. Because every downstream agent now has the opportunity to preserve provenance. That attacks #8 directly and helps #5, #9, #11 and #12 indirectly.
And the gap here is close to total (corpus scan). 73 sites publish an A2A agent card and 15 of them are valid; 58 are missing fields the card is required to carry. Of the 191 sites publishing MCP authorization metadata, 121 are valid. The machinery for machine-readable, attributable answers exists, it's barely deployed, and where it is deployed it's usually wrong.
This is where a lot of GEO marketing is bullshit. There's no good evidence that adding llms.txt, rewriting a page a certain way, adding some schema, or mentioning a fact five times reliably causes frontier model parametric knowledge to change.
A company doesn't control when the next model trains, its corpus, deduplication, weighting, filtering, synthetic-data pipeline or post-training. Allowing GPTBot means content may be used in training. It absolutely does not mean a factual correction will be absorbed.
Worth noting what the most-adopted intervention actually is (corpus scan): 13,730 sites publish llms.txt, making it the most widely adopted agent-facing file on the web after robots.txt and the sitemap. Ahrefs found 97% of the llms.txt files they tracked receive zero AI requests. The most popular lever is the one with the least
demonstrated demand behind it.
There's now quite a lot of GEO research. Controlled studies show altering page structure and content can increase citation visibility. But a review of 45 GEO studies concluded that the strongest evidence concerns what happens once content is already available to the generative system, and found no demonstrated stable, longitudinal, cross-platform causal method for improving organic discoverability.
That's an enormous distinction. That's how I'd communicate it to customers.
Not Generative Engine Optimization, and not make AI mention your brand more. Rather:
AI factual integrity for organizations.
The product asks models hundreds of questions about the organization. For every claim it identifies, it classifies the failure mode against the twelve above. And crucially it doesn't merely give a brand score. It says this error is addressable, and here is why:
"Three of four models say Lumar cannot crawl JavaScript. The claim is wrong. There is no canonical page > stating it plainly; the fact appears once, in the eleventh paragraph of a product page, alongside two > older documentation pages that contradict it. This is failure mode 2 and 3. Publish a canonical answer > page, retire the contradictions, and re-measure."
That is empirically testable. After the change, rerun the same experiment. Not once, because these systems are stochastic, but enough times to separate a real shift from sampling noise.
Now you're not selling snake-oil “AI visibility.” You are running something much closer to observability and remediation for how agents perceive an organization.
Diagnose all twelve. Sell remediation aggressively for 2, 3, 4, 5, 7 and 8, where the organization genuinely has meaningful control. For 1, 6, 9, 10, 11 and 12, report the problem and distinguish what can be mitigated from what belongs to the model or agent provider.
That distinction may be the strongest thing about the product, because it avoids pretending every wrong answer can be fixed with another fucking llms.txt file.
And it has a precedent in how we already report. In the same corpus scan, the one security-impact check the scanner carries, whether a site has published private key material in its public signing-key directory, fired zero times across 59 publishers (corpus scan). The honest way to report that isn't "the web is secure." It is: nobody in this sample did the dangerous thing, the sample is 59, and by the rule of three that's consistent with a true rate anywhere up to about 5%. A product that reports a null result that carefully is a product whose positive findings you can believe.