Knowledge Graphs, AI Search & LLMs: Why Entities Power GEO

Q: What is generative engine optimization?

Generative engine optimization is the practice of trying to influence how a brand is represented in answers produced by language models and AI search surfaces. In practice it consists of the existing entity and content playbook applied to a new surface, since providers document almost no dedicated levers and outcomes in model outputs cannot yet be attributed to specific changes.

Generative engine optimization is the practice of influencing how a brand, person, or product is represented in answers produced by language models and AI search surfaces. Much of what is written about it treats a language model as a search engine with a different interface, which it is not. A useful position on the subject requires separating three things: what model and search providers document, what follows from how the systems are built, and what practitioners infer. This page keeps those apart deliberately, and makes no claim that any of it produces visibility.

What a language model does with a fact

A large language model is trained on text. Training adjusts parameters so that the model predicts continuations of sequences well, and factual regularities in the corpus end up encoded in those parameters as statistical structure rather than as retrievable records. At inference time, the model generates tokens. It does not look anything up.

This has a direct consequence that is often glossed over: a base language model does not query a knowledge graph when answering a question. There is no lookup step, no entity table, and no mechanism by which a sameAs array published last week could reach the parameters of a model whose training data was fixed earlier. Whatever the model appears to know about an organization is a residue of how that organization was written about across the corpus, at scale, before training ended.

A retrieval layer changes the picture. When a system fetches documents or records at query time and places them in the model’s context before generation, the model is reasoning over text it was handed rather than only over its parameters. Lewis and colleagues introduced that architecture, retrieval-augmented generation, in a 2020 paper, and it’s now the standard way to give a model access to current or private information. Nearly every AI surface that cites sources is doing some version of it.

So there are two distinct paths by which a fact about a brand can reach a generated answer: through the training corpus, which is slow, indirect, and closed to intervention, and through retrieval at query time, which is fast and operates on the live web. Only the second is addressable in any practical sense, and even then indirectly.

What AI search surfaces document

Google describes AI Overviews as built on its core ranking and quality systems, and Overviews include links to the pages that support them. Google’s own guidance for site owners on these surfaces is unusually plain: there is no new markup, no special format, and no separate submission process, and eligibility follows the same technical and content guidance that applies to Search generally. That is worth restating because much GEO advice implies otherwise.

The same holds for structured data. Google has not documented schema.org markup as an input to AI Overviews or AI Mode, and no major model provider documents reading a page’s JSON-LD at inference time. Structured data’s documented roles remain rich result eligibility and helping search engines understand a page, as covered in structured data.

One documented control does matter operationally: crawler access. Google publishes a separate Google-Extended token governing whether a site’s content may be used for Gemini and grounding features, leaving Search crawling unaffected, and other providers publish their own user agents for retrieval and for training. A site blocking those agents removes itself from the retrieval path, a verifiable effect opposite most GEO tactics. Proposals such as llms.txt carry no documented support from major providers and should not be presented as a requirement.

Documented, structural, inferred

The three-way split, applied to the claims most commonly made in this area:

Claim	Standing
AI Overviews link to supporting pages and use Google’s ranking systems	Documented by Google
No special markup or format is required to be eligible for AI surfaces	Documented by Google
Retrieval-augmented systems place fetched text in a model’s context before generating	Documented and described in the published literature
Blocking an AI crawler removes a site from that provider’s retrieval path	Documented by the providers’ own crawler documentation
A base model does not query a knowledge graph at inference time	Structural, follows from how models work
Retrieved passages that state a fact clearly are easier for a model to use than passages where the fact is implied	Structural, weakly so; consistent with how these systems work
Consistent, corroborated entity attributes across independent sources make a brand less likely to be described wrongly	Practitioner inference
Schema markup increases how often a brand is cited by an AI assistant	Not documented, not demonstrated; avoid
A specific “GEO score” or markup pattern raises visibility in model outputs	Unsupported

The middle of that table is where the honest work is. It is neither documented nor baseless, and the right register for it is “this is how the mechanism appears to operate, and here is what follows”.

Why identity resolution is the pressure point

Consider what a retrieval layer has to do with the query “who leads Example Institute”. It has a string. It needs documents about a particular organization, and there may be four organizations with similar names, a defunct predecessor, and a person with the same surname as the institute’s founder. Somewhere in the pipeline, a mention has to be resolved to a thing. That step is entity linking, and it is the same operation described in entity linking, NER, and extraction: detect the mention, generate candidate entities, score them against context, pick one.

Every ambiguity in how a brand publishes its own identity makes that step harder, and the failure mode is not absence but error. A model handed passages about the wrong organization will answer fluently and incorrectly. A model handed passages where the name, founding year, and location differ between three sources will pick one, and there is no way to know which.

The properties of a well-described entity that bear on resolution are unglamorous and mostly known already from entity SEO:

One canonical name, used the same way everywhere, with genuine variants declared as variants rather than left to be inferred
A stable identifier, ideally one that external catalogs already carry, so that statements from different sources can be recognized as being about one thing
Attributes that agree across sources: the same founding date on the site, in Wikidata, and in a press profile
Explicit relationships, so that a subsidiary is not silently merged with its parent and a person’s affiliation is stated rather than implied
Disambiguating detail near the mention, because retrieval operates on passages, and a passage that names a city and a sector is easier to resolve than one that names neither

None of these is an AI tactic. They are the same identity hygiene that a knowledge panel depends on, described in how to get a knowledge panel. The claim being made here is only that the same hygiene serves the retrieval case, and that claim is inference, not documentation.

Structured data as a restatement, not a channel

The defensible way to think about schema.org markup in this context is as a machine-readable restatement of facts that are already on the page. Its value is that it removes interpretation: foundingDate with an ISO date is not a sentence that has to be parsed, and sameAs pointing at a Wikidata Q-ID is an explicit identity assertion rather than a name that has to be matched.

That restatement is useful to any system that parses pages into structured records: search engine indexing, third-party data aggregators, and any retrieval pipeline whose ingest step extracts entities rather than storing raw text. It is not documented as an input to model-generated answers, and treating it as one is where GEO advice usually stops being honest.

The practical implication is modest. Publish markup because it makes a site’s own facts unambiguous and because its documented uses are worth having on their own, not as a bid for citation in an AI answer. The consistency requirement carries over: markup that contradicts the visible page gives an extraction pipeline two versions of a fact, which is worse than giving it one.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Institute",
  "alternateName": "The Institute",
  "url": "https://example.com/",
  "foundingDate": "1998-04-15",
  "founder": { "@type": "Person", "name": "Marie Dupont" },
  "parentOrganization": { "@id": "https://example.org/#organization" },
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Gainesville",
    "addressRegion": "FL",
    "addressCountry": "US"
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q00000",
    "https://en.wikipedia.org/wiki/Example_Institute"
  ]
}

Everything in that block should also be stated in the visible page text, because the retrieval path operates on the text. The markup makes the same facts unambiguous for anything parsing the page as data.

The developer-side counterpart: retrieval over a graph

While practitioners argue about markup, the more consequential use of knowledge graphs with language models is happening on the engineering side, where a graph is the retrieval index rather than a search engine’s private asset.

Plain vector retrieval chunks a corpus, embeds the chunks, and returns the nearest ones to a query embedding. It works well for questions answered in a single passage and poorly for questions whose answer is spread across many documents, or that require traversing a relationship. “Which suppliers in this portfolio depend on a single facility in one region” is not in any one chunk.

Graph-based retrieval addresses that by extracting entities and relationships from the corpus first, building a graph, and using it to select what goes into the model’s context: traversing from a resolved entity to its neighbourhood, or summarizing a cluster of related nodes. The extraction step is the same entity-linking problem again, run over a private corpus. The full treatment is in GraphRAG.

A third technique sits alongside both. Knowledge graph embeddings represent entities and relations as vectors learned from the graph’s own structure, supporting link prediction and similarity over the graph rather than over text. Retrieval systems combine all three: text embeddings for passage similarity, traversal for structural questions, and graph embeddings for connections that are not explicitly stored.

This matters to the SEO half of the audience because it is a working model of what “an AI system using a knowledge graph” looks like. There is an extraction step, an identity resolution step, a retrieval step and a generation step, and identity resolution is the one that quietly determines whether the rest produces a correct answer.

What not to promise

No one can currently demonstrate a causal link between a markup change and how often a model names a brand. The measurement problem alone rules it out: outputs are non-deterministic, they vary by phrasing and by user context, providers change models without notice, and there is no impression log. Tools that track brand mentions across assistants measure something real and useful, but they don’t measure the effect of a specific on-site change.

Three claims to avoid. That structured data causes citation in AI answers, which providers do not document and which cannot be isolated. That a knowledge panel is required for a model to describe a brand correctly, when panels and model behaviour are separate systems with overlapping inputs. And that there is a settled discipline here with known levers, when most current advice is the existing entity playbook applied to a new surface on the reasonable belief that clearer facts survive more pipelines intact.

The work that stands up is the work that was worth doing anyway: accurate content, a coherent entity description, consistent facts across independent sources, and crawler access left open to the providers a site wants to be retrievable by.

FAQ

Do LLMs use knowledge graphs?

Not at inference time, unless a retrieval layer does it for them. A language model generates text from parameters learned during training, with no lookup step. Systems built around models can query a graph and place the results in the model’s context before generation, which is what retrieval-augmented and graph-based retrieval architectures do.

Does schema markup help with AI Overviews?

Google does not document structured data as an input to AI Overviews, and its guidance is that no special markup or format is required for those surfaces. Markup remains worth publishing for its documented uses, rich result eligibility and page understanding, and because it states a site’s facts unambiguously for anything parsing pages as data.

What is generative engine optimization?

Generative engine optimization is the practice of influencing how a brand is represented in answers produced by language models and AI search surfaces. In practice, it consists of the existing entity and content playbook applied to a new surface, since providers document almost no dedicated levers and outcomes in model outputs cannot yet be attributed to specific changes.

Why do entities matter for AI search?

Because a retrieval layer has to resolve a mention to a specific thing before it can fetch anything useful, and an ambiguous or inconsistently described entity produces confident wrong answers rather than no answer. Consistent names, stable identifiers and attributes that agree across independent sources make that resolution step more likely to land on the right entity.

Sources and further reading

Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (2020): https://arxiv.org/abs/2005.11401
Google Search Central, AI features and your website: https://developers.google.com/search/docs/appearance/ai-features
Google Search Central, Google crawlers and user agents: https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlers
Google Search Central, structured data general guidelines: https://developers.google.com/search/docs/appearance/structured-data/sd-policies
Microsoft Research, GraphRAG: https://www.microsoft.com/en-us/research/project/graphrag/
Hogan et al., “Knowledge Graphs” (open access book): https://kgbook.org/
Wikidata, Introduction: https://www.wikidata.org/wiki/Wikidata:Introduction