The Critical Role of Entities & Knowledge Graphs in AI Search Optimization [AEO/GEO]

Entity SEO is the practice of clarifying what a company is, how its products, categories, customers, and capabilities connect, and how consistently those relationships are supported across the web, so search engines and AI models can identify the company and retrieve it for relevant questions. We increasingly treat entity relationships as part of the retrieval layer itself, which makes them a critical component of AI search optimization (AEO / GEO).

Ask a language model the same question more than once, and the final list will often change, yet some associations stay stable: Salesforce keeps appearing in answers about enterprise CRM, Stripe in answers about payments infrastructure, and Volvo in answers about safe cars.

A model's output is probabilistic, sampled from a distribution of plausible continuations, which is why identical prompts produce different results.

Still, some relationships carry far less variance because years of products, customers, publications, reviews, partners, databases, and search results have repeatedly connected the same entities to the same categories.

In effect, AI search works on two layers:

• Generative: the wording, the order and the exact list change from one answer to the next.
• Grounding: which companies belong to which categories, built from those entity relationships, changes far more slowly.

Another thing to consider is that, according to Google, the average AI Mode query is roughly three times longer than a traditional search, and AI Mode has passed a billion monthly users. Longer queries mean more conditions per question, and more conditions mean more relationships that have to be true about a company at once before it can be part of an answer.

That is where many B2B companies fail, including those that rank well on Google:

• Across the 11,000+ domains and more than a billion AI citations we track at Omnius, only around 8–12% of the pages cited in AI answers also appear in Google's top ten for the corresponding searches. Ahrefs, testing 15,000 prompts across ChatGPT, Gemini and Copilot, found a comparable figure of roughly 12%.

Being relevant is not the same as being retrievable, and being retrieved is not the same as being recommended. This guide covers what entities and knowledge graphs are, how AI engines use them, where company representation breaks, and what to fix first.

Key Takeaways

• AI search visibility starts with being understood as an entity.
  If engines cannot clearly connect a company to the right category, audience, use case, or market, it may never enter the candidate pool.
• Entity SEO focuses on what the company is, not just what a page says.
  Products, capabilities, people, customers, integrations, and categories need to form a clear and consistent company model.
• Independent corroboration strengthens important associations.
  Customers, partners, regulators, review platforms, and publications provide stronger evidence than repeating the same claims across owned pages.
• Depth matters more than breadth.
  A small set of commercially valuable associations, supported consistently across owned and third-party sources, is more useful than trying to appear relevant to every category.
• The goal is to make the company easy to identify, connect, and retrieve.
  Strong entity representation improves the likelihood of being considered across a wider range of AI-generated answers.

Entities Decide Who Enters the Answer

Most AI search advice starts at comparison: how to be chosen among the vendors an answer names. However, before deciding which prompts to track, which pages to create, which articles to write or which publications to pursue, there is a more basic question: Does what is published about the company make it sufficiently clear what the company is, what it does, who it serves, where it belongs, and which evidence supports those relationships?

Before an engine can compare or recommend anyone, retrieval has to find enough reason to connect a specific company to the category, problem, capability, buyer, industry, or use case in question. When those connections are missing or weak, the company never enters the candidate pool, and ranking never happens.

Queries themselves now carry more structure. "Payroll software" is a keyword, but "which payroll platforms suit a 300-person European software company employing people across ten countries and consolidating EOR and global payroll?" is a small graph of six requirements at once: industry, company size, geography, category, use case, and operating model.

A company can match the first relationship and fail on the next five, as the engine also needs a reason to connect specific companies to Europe, to multi-country employment, to that size of business, and to whatever else the buyer specified.

Exclusion is not a single event either. A company may reach the candidate pool and fail reranking because nothing connects it contextually to the specific prompt.

It can also survive both and still be left out of the final answer because the relationship lacks corroboration or strong enough entity signals.

Each possibility is a different diagnosis with a different fix.

Context decides which pool a company competes in. Ask for the best AI search optimization agencies as a SaaS or fintech founder, and Omnius tends to appear in the prompts we track; ask the identical question as a founder in a traditional offline industry, and it usually does not, because that context resolves to a different set of entities and expands into different retrievals.

Nothing about the pages differs between those two answers; only the candidate set does.

This failure mode is invisible from the inside. A ranking drop produces a chart someone argues about in a meeting, but exclusion from a consideration set produces nothing, and from the company's perspective, it looks identical to an absence of demand.

What an Entity Actually Is

An entity is a distinct thing a system can identify and connect to other concepts: a company, product, feature, capability, category, integration, customer, or person. Each carries attributes (name, location, size, founding date, owner) and relationships (what it contains, enables, solves, serves, integrates with, competes against).

A knowledge graph is the network those entities form: each entity is a node, each relationship is a labeled connection between two of them (Product → integrates with → Platform), and the attributes sit on the nodes.

A company is rarely the only entity that matters. Products carry their own attributes and evidence and are often what a buyer's question is about.

Founders and executives are entities in their own right, and their public record (talks, interviews, prior companies, published work) either reinforces or undermines what the company claims to be expert in.

Treating all of these as one undifferentiated brand is the most common modeling mistake we see.

Three terms are often used interchangeably and shouldn't be:

‍

Semantic SEO strengthens what a page means, Entity SEO strengthens what the company is, and schema describes an entity without manufacturing one.

Which Entity Are You? Disambiguation and Identifiers

Before an engine can decide whether a company belongs in an answer, it has to work out which company is being discussed.

That might sound trivial until you look at B2B naming: Omnius, Box, Square, Ramp, Linear, and Scale all share names or near-matches with common words, other businesses, or concepts unrelated to software.

Mentions that could belong to several entities are cheap to ignore and expensive to resolve, so they frequently contribute nothing.

Disambiguation depends on identifiers and context.

The identifier layer is the set of stable, machine-checkable records that let separate mentions resolve to one thing:

• Wikidata and Wikipedia, where the company meets their notability criteria
• Crunchbase, LinkedIn and Bloomberg-style profiles
• Official company registries such as Companies House or SEC filings
• Industry-specific registers like regulator databases and LEI records
• The sameAs links that connect your own pages to all of them

Knowledge Panels are assembled from this kind of corroborated record, which is why a panel is a useful diagnostic even if it is not the goal.

In terms of context, an ambiguous name resolves more reliably when it consistently appears beside the same category, product, location, and people.

Practical remedies:

• Use the full legal or product name in the places engines read most.
• Avoid a bare ambiguous token as the only identifier.
• Keep founder and headquarters details consistent.
• Make sure every profile points back to the same canonical domain.

What you should do: Claim and align the identifier records that exist for your company, add sameAs links from your own structured data to each one, and check what an engine currently returns for your name alone. If the answer describes something else, no amount of content about your category will reach the right entity.

Run the same check per market, since a company can be well resolved in English and still be ambiguous in another language where far fewer sources describe it.

From strings to things

Search has been moving toward this layer for more than a decade. When Google launched its Knowledge Graph in 2012, building on its acquisition of Metaweb and the Freebase dataset two years earlier, it described the shift as moving from strings to things. What this means is that a query is rarely about a sequence of characters; it’s about an object in the world with properties and connections to other objects.

Two decades of information retrieval had been spent finding and ranking documents. The graph was an attempt to represent what those documents were about. In 2020, Google said it held over 500 billion facts about five billion entities, and AI Mode can use Knowledge Graph information alongside web search and other sources.

How AI Engines Use Entities

Different engines implement retrieval differently, and no public documentation describes one universal pipeline across Google AI Mode, ChatGPT, Claude, Gemini, and Perplexity. The architectures differ; the constraint does not.

There are far too many companies, documents, facts, and possible relationships for any engine to weigh all of them equally every time someone asks a question, so the space has to be narrowed before an answer can be assembled.

Associations reach a model through two routes:

1. Learned associations: Models absorb patterns from large volumes of text during training, including which companies repeatedly appear alongside which categories, problems, customers, competitors, and capabilities.

2. Retrieved associations: At query time, retrieval brings in external sources that confirm, update, or contradict what was learned, which is how current information and long-tail companies enter answers at all.

Matching has not been purely lexical for years on either route. Google's search documentation describes language systems that recognize relevant concepts even when the query and the page do not share the same words, and in 2018 Google said one of them, neural matching, affected about 30% of queries.

Whichever route an association arrives through, it performs the same function: establishing what a company is with enough confidence for the rest of the answer to be about something else.

The two routes operate on very different clocks. Retrieval reflects the public record within days or weeks, so corrections and new evidence can change answers relatively quickly. Learned associations only change when a model is retrained, which happens on the provider's schedule, not yours.

The corroboration you build today therefore works twice: It influences retrieval now, and it becomes part of the corpus that future training runs learn from. Companies that wait lose visibility today and are absent from the material the next generation of models will treat as settled.

Retrieval quality decides what the model ever sees

Anthropic's published Contextual Retrieval research quantifies how much the retrieval layer matters. Retrieval failures fell as each component was added:

‍

‍

‍

Two things follow for companies:

• First, generation happens after selection. If the evidence connecting a company to a question never survives retrieval, the model has nothing to compensate with, and it will still produce a fluent answer that leaves the company out.
• Second, lexical matching still contributes. Exact terminology and named entities matter alongside semantic relevance, which is why "keywords are dead" is the wrong conclusion. AI search depends less on exact keywords alone, not less on precision.

Structure improves retrieval, not just quality

Microsoft's GraphRAG research extracts entities, relationships, and claims into an explicit graph before retrieval. In its experiments, that approach beat conventional chunk-based retrieval on comprehensiveness and diversity at roughly a 70-80% win rate for broad questions, the kind where an answer must connect information spread across many documents.

Flat retrieval finds passages, while graph retrieval finds relationships. That matters commercially because a company is an entity represented by hundreds or thousands of passages across the web, and the engine must reconstruct the relationships between them.

Knowledge graphs reach AI answers in three ways:

• Google's Knowledge Graph feeds AI Mode alongside web search.
• Public graphs such as Wikidata give engines stable identifiers to resolve mentions against.
• Graph-based retrieval, as in GraphRAG, builds a graph from documents before retrieval.

A company shows up in all three only as clearly as its entities and relationships are stated and corroborated.

Confidently Wrong: The Problem Entities Help Solve

Language models can be confidently wrong: an answer can sound coherent and certain while resting on incomplete, ambiguous, or incorrect information, and a model will explain the wrong set of companies and relationships just as fluently as the right one. An answer is only as accurate as the entity relationships it is built on.

That makes the information available before generation decisive. Entity relationships reduce the uncertainty an engine has to resolve: The clearer it is what a company is, which category it belongs to, which capabilities it has, and who it serves, the less the engine has to infer from weak or conflicting evidence.

Independent corroboration is the most reliable check against this, because a dozen unrelated documents agreeing that a company operates in cross-border payments for marketplaces is a different evidence base from the company asserting it twelve times on its own domain.

Retrieved ≠ Cited ≠ Named ≠ Recommended

These are four different states with different conditions, and most measurement collapses them into one number.

‍

The gaps between them are measurable. In Semrush's 2026 analysis, 74.9% of appearances involved a citation while only 38.3% involved an explicit brand mention, and 61.7% were ghost citations where the source was used, but the brand was never named.

In their ChatGPT sample, the split widened to 87% domain citations against 20.7% brand mentions.

The same Semrush data shows the mirror case of ghost citations: In 25.1% of appearances, the brand is named with no citation and no link.

Two conclusions follow from the overlap data above:

• AI-search retrieval is not Google rankings rearranged into prose.
• A material share of brand visibility happens without producing any referral at all.

Citations are easy to celebrate because they are visible and countable, and sometimes they do mean the brand entered the answer. However, they can also mean the company supplied free evidence for an answer that recommended somebody else.

Twenty Years of Optimizing Pages While the Company Stayed Unresolved

Most companies have accumulated pages for years without maintaining a coherent information model underneath them, and the reason is organizational.

The product team has its taxonomy, and sales uses another. SEO creates categories from keyword demand, product marketing creates them from positioning, customer success speaks in use cases, engineering names features according to how they were built, partners invent their own descriptions, and databases classify the company however their own taxonomy allows. Old pages stay indexed long after the product has changed.

None of that was catastrophic when every query returned ten blue links, because engines could rank an individual page even when the company's wider representation was incoherent.

Answer-first search makes the contradictions more expensive, because the engine is being asked to do something closer to synthesis, and the answer draws on sources the company does not own.

The company already has a graph, whether it manages it or not. Products, people, categories, capabilities, customers, industries, integrations, locations, partners, use cases, and sources already exist as connected objects across the public web. Entity work is largely about making that graph less accidental.

Where Entity Representation Breaks

Fragmentation is usually accidental, and these are the patterns that appear in most entity audits:

‍

A person familiar with the market can read through all of this and infer what the business does. Retrieval algorithms cannot call the CMO to ask which description is current; they work with what was published, including the parts nobody remembered to update; where sources disagree, the algorithms resolve the conflict on their own.

A company can call itself a treasury platform while most independent sources still describe it as payments software, claim to serve enterprises while almost every visible customer is an SMB, or publish ten pages around an industry without a single customer, partner, or publication connecting it to that market.

The Four Layers of Entity Work

Marketing naturally expands: more categories, more industries, more use cases, more landing pages, more phrases the company wants to be known for.

Entity work starts from a narrower question: which relationships matter enough to make unambiguous? What follows from that question is closer to data engineering than to marketing. Search engines, LLMs and agents weigh information differently, but all of them depend on the same four layers lining up.

1. Reality

What is true: products, capabilities, the problems they solve, audiences, categories, the people behind the company, the legal entity it operates as, and the claims it can support.

What you should do: Build a single company record, which we call a Company Information Model, and mark every fact as confirmed, inferred, or still open, keeping a claim register for anything the company asserts that nothing else supports yet. The gap between what a company knows and what it can evidence is what determines retrieval.

2. Representation

How that reality is expressed on owned surfaces: product and use-case pages, documentation, information architecture, internal links and structured data.

What you should do: Give each priority entity one page that owns it, consolidate competing pages, and make relationships explicit through content and internal linking rather than leaving them implied.

Representation also has to be machine-accessible, and this is where the cheapest failures happen.

Content rendered client-side may be visible to a visitor and invisible to a crawler.

Blocked AI user agents remove a company from live retrieval entirely without producing any error anyone will notice, and pages excluded from indexing cannot support any relationship at all.

What you should do:

• Verify that AI crawlers are allowed.
• Check that priority pages are served as static or server-rendered HTML.
• Confirm indexation of the pages that carry your most important relationships.
• Check how engines currently describe the company in Knowledge Panels, company profiles and official registries.

3. Corroboration

How independent sources confirm the claims and relationships that matter: customers, partners, reviews, publications, analysts, databases and official registries.

What you should do: Produce an External Corroboration Map.

1. List the relationships with commercial weight.
2. Identify which currently rest only on owned claims.
3. Name the specific customers, partners, publications, analysts, databases, or registries best placed to confirm each one.
4. Weight the gaps by commercial value rather than by how easy they are to close.
5. Compare your coverage against the competitors appearing in the same answers.

4. Retrieval

How engines find, connect, and weigh what exists, which varies by model, prompt, context, and time.

What you should do: Track how engines describe the company against fixed prompts and dated baselines, and treat any single answer as a sample rather than a verdict. What is published about the company matters more than any individual response.

Rebrands, Acquisitions, and Parent Companies

The hardest entity problems are structural rather than editorial. A rebrand leaves the old name attached to years of accumulated evidence that keeps being retrieved, while the new name inherits almost none of it.

An acquisition creates the opposite problem: A subsidiary and its parent get conflated, and answers attribute the parent's scale or the subsidiary's specialization to whichever entity the available sources describe more clearly.

Resolving this requires:

• Explicitly connecting old and new names wherever the company controls the record
• Adding redirects and canonicals that make the succession unambiguous
• Updating registry and profile entries
• Deliberately reviewing third-party sources that still describe the previous structure

Maintenance, because entities drift

Products get renamed, positioning changes, a category the company abandoned two years ago keeps circulating in databases that copy each other, and a model that was accurate last year eventually stops describing the company it was built for.

Correction is a distribution job as much as a content one. The records worth keeping current are the company's own profiles on Crunchbase, LinkedIn and review platforms, registry entries, partner directories, and the publications still carrying outdated descriptions.

Entity Work Is Information Architecture for the Company, Not Metadata for the Page

Done properly, this process starts before schema and before any page is created, with a set of questions whose answers are usually unwritten:

• What exactly does the company sell?
• Which product names are canonical?
• Which capabilities belong to which product?
• Which categories are primary and which are merely adjacent?
• Which use cases matter commercially?
• Which customers prove those relationships?
• Which integrations are live?
• Which relationships are confirmed, which are inferred, and which are still assumptions?
• Where does public information conflict?
• Which important claims appear only on the company's own domain?

And the question that reframes all the others: What would an engine currently infer about this company if it had to reconcile everything publicly available without asking us?

The output is the Company Information Model, and once it exists, ordinary SEO decisions start being made for different reasons. A category earns its own page because a real product relationship, customer evidence, demand, and external corroboration back it up.

Relationship Models by Vertical

Relationships carry the meaning, and they differ by market more than generic frameworks admit. These are the connections worth making explicit and corroborating first.

SaaS

‍

Fintech

‍

AI

‍

Enterprise software

‍

What Counts as Evidence

Not all support for a claim is equally valuable. What matters is who is making the statement.

‍

Twenty claims on your own domain are still one company talking about itself. The useful question is “what relationship does each source reinforce?” For example:

• A customer page corroborates a customer relationship
• A partner corroborates an ecosystem relationship
• A regulator's record corroborates a license
• A third-party review corroborates how the product is used

Evidence density inside the content matters as well. The original generative engine optimization research, evaluated across 10,000 queries, reported visibility improvements of up to 40% from methods including adding citations, quotations, and statistics, a result consistent with engines preferring claims that can be checked.

The quantitative version of the corroboration point comes from Ahrefs' study of 75,000 brands, which found branded web mentions correlating with AI visibility at roughly 0.66–0.71 and YouTube mentions slightly higher, while page count correlated at about 0.19.

What others say about a company appears to matter much more than how much the company publishes about itself.

Where Category Membership Is Actually Won

For vendor questions, most of the material an engine retrieves was not published by the vendors. Muck Rack's May 2026 analysis of more than 25 million links cited by ChatGPT, Claude and Gemini found that 84% came from earned media. It is third-party category content: "best X for Y" lists, comparison and alternatives pages, review-platform categories, directories, analyst and media coverage, and community threads where practitioners argue about tools.

Those pages exist to answer the question the buyer is asking, which makes them closely matched to the prompt and influential over which companies are considered.

Two things follow:

1. Category membership is largely conferred by other people. A company can describe itself as an enterprise CRM on every page it owns and still be absent from the fifteen comparison pages an engine is most likely to pull, in which case the association never accumulates where it counts.
2. Co-occurrence is itself the signal: Being named alongside the companies buyers already associate with a category is how a newer entity gets attached to it, and being named alongside the wrong set is how a company ends up in the wrong pool.

Review platforms deserve particular attention because their taxonomies are explicit. A category assignment on G2 or Capterra is a structured, machine-readable statement that a company belongs to a category, made by a third party, and it tends to propagate into directories and comparison content that engines then retrieve.

What you should do: Inventory the third-party pages that already rank or are cited for your priority questions, check whether you appear on them and how you are described, and treat inclusion and correction on those surfaces as a distinct workstream from publishing your own content. Track which competitors appear beside you, since that set is a faster indicator of category membership than your own rankings.

Depth Beats Breadth: Association Equity

Associations concentrate: some relationships become much stronger than others because evidence accumulates around them, and that accumulation does not distribute evenly across the companies competing for the same ground.

Volvo is associated with many attributes, but safety has been reinforced for decades through product decisions, crash testing, advertising, customers, reviews, and public discussion. In a 2001 survey Volvo itself reported, 20% of US consumers named Volvo unaided as the brand they most associate with safety, rising to 41% when prompted, well beyond its market share.

Eventually the association becomes bigger than any individual advertisement, and it survives campaigns, rebrands, and marketing budgets. We call the accumulated value of a relationship like that association equity.

Kevin Lane Keller's brand-equity work described the human version decades ago. Brands become valuable through strong, favorable, and unique associations held in memory. AI retrieval adds a second audience for the same asset, because engines must also decide whether a company belongs to the category, problem, buyer, or use case in a question.

The dynamic has a second-order effect that matters for budgets: When competitors advertise safety, they largely reinforce Volvo, because the category grows, and the company that owns the association captures a disproportionate share of that growth. Generic category content published by a company that does not own the category tends to work the same way.

Advantage in this system compounds, in the way network science describes as preferential attachment and sociology as the Matthew effect. Once a company is strongly associated with a category, each new piece of evidence arrives beside evidence that already exists.

Semrush's 2026 study of 283,215 domain-category citation observations and 76,493 brand mentions across 1,458 brands found the same asymmetry:

• In categories close to a brand's established expertise, brands were cited in 74% of appearances, named in 44%, and both cited and named in 34%.
• In categories distant from that expertise, the same figures fell to 50%, 25%, and 9%.
• Shallow presence across many categories did not compensate for weak depth; appearing once across twenty categories was not associated with stronger brand-mention share.

A company can still become a source outside its core market, but the probability of the brand itself being part of the answer drops far more sharply.

Specialization produces evidence as a by-product of real work (customers, integrations, independent references, citations), which is why narrow companies often out-retrieve larger ones in their category.

There is a suggestive parallel in associative-memory research, where the fan effect describes how retrieving one association becomes slower and weaker as more competing associations attach to the same concept.

Language models do not work like human memory, and we would not claim they exhibit that effect, but the intuition behind it is hard to dismiss: Being connected to everything is not the same as being connected to something, and the worst position is being associated with nothing in particular.

Associations are easier to reinforce once they already exist, which is the hard part for anyone starting late. A company beginning today is competing with ten years of customers, articles, reviews, partnerships, databases, and references connecting that rival to the category.

A company can publish pages for twenty industries and describe itself through fifty use cases, but publishing a relationship is not the same as accumulating evidence for it. A company surrounded by years of mutually reinforcing evidence gives an engine far more reason to connect it to a question.

Both may be equally relevant in reality, but only one has accumulated the association equity. That does not mean incumbents are safe, though; new categories get created constantly, and established companies routinely get trapped in associations they have outgrown.

If association is the asset, the strategy that follows is narrow rather than broad. A small set of relations, stated consistently on everything a company controls and confirmed by partners, customers, registries and publications, is worth more than a wide set asserted only by the company itself.

Choosing Which Associations to Own

"Pick the categories you intend to own" is easy to say and rarely operationalized. The choice has three inputs, and a candidate association has to survive all of them.

The first is demand: Which questions buyers ask, in the language they use, at the stage where a vendor gets shortlisted. Prompt and query research gives the raw set (categories, problems, integrations, jurisdictions, buyer types), and most of it will not be worth owning.

The second is commercial value. An association that appears in hundreds of prompts but attracts buyers the company cannot serve is worth less than a narrow one that appears in twenty prompts at the point of purchase. Weight each candidate by the revenue attached to the buyers who ask those questions, not by how often the phrase appears.

The third is evidence feasibility: whether the company can realistically accumulate support for the claim. If it has three customers in a vertical, no partner confirmations and no independent coverage, an association with that vertical is a two-year project rather than a content brief, and the right call may be to defer it. Where the evidence already exists but has never been made explicit is usually the best place to start, because the work is resolution rather than creation.

What you should do: Score candidate associations against demand, commercial value, and evidence feasibility, then commit to the smallest set the company can support with evidence, and defend that list against the pressure to add one more industry page every quarter.

Schema's Actual Role

Structured data is where most teams begin, and it is useful once a model exists to express. It cannot decide what the company is or produce independent evidence for a claim nobody else makes.

Used well, schema should express one connected organization, with stable identifiers, links to official profiles, and the same facts that appear on the page:

• Organization with sameAs links to official profiles and registries
• Product or Software Application for each priority product entity
• Article + Person for editorial content, with real author credentials
• FAQ page where genuine questions are answered
• Consistent identifiers across pages, so people, products, and pages resolve to one company

Serialization is downstream of resolution, and resolution is downstream of reality. Structured data around an unresolved company publishes the same contradictions in machine-readable form.

How to Measure Entity Representation

There is no native reporting for any of this, so measurement has to be assembled.

1. Entity and relationship coverage

Which of the relationships you decided to own are explicit on your own surfaces, and which are only implied.

How to measure: Inventory priority entities and relationships, then check page ownership, internal links, and structured data for each. Report coverage as a percentage of priority relationships explicitly represented.

2. Corroboration coverage

Which important claims currently rest only on owned sources.

How to measure:  For each priority relationship, record the independent sources confirming it. Track the share with zero external confirmation: that list is your evidence backlog.

3. Citation share versus mention share

Whether your content feeds answers that name you, or answers that name someone else.

How to measure: Track citations and brand mentions separately across a fixed prompt set, per cluster. The gap between them is the ghost-citation problem in your own market.

4. Conflict detection

Where public sources disagree about your products, categories, or company facts.

How to measure: Audit owned pages, databases, profiles, registries, and review platforms against your company record. Log every conflict with its source, and prioritize the ones affecting commercially important relationships.

5. Entity accuracy

Whether engines describe the company correctly, and how quickly factual errors get caught.

How to measure: Compare the attributes engines state (category, size, location, ownership, product names, key customers) against your company record, and log every discrepancy with the source that most likely caused it. Track time-to-detection separately, because an uncorrected error is repeated across thousands of answers before anyone notices it.

6. Co-mention share

Which companies appear alongside you, and whether that set is the one you want to belong to.

How to measure: For each priority prompt cluster, record the other companies named in the answer. Rising co-mention with the recognized names in a category is usually the earliest sign that a new association is taking hold; appearing beside an unrelated set is an early warning that the wrong one is forming.

7. Engine representation over time

How Google and AI engines describe the company, and whether that description is drifting.

How to measure: Run a fixed prompt set against a dated baseline, recording category positioning, competitors named alongside you, and factual accuracy. Treat single answers as samples; watch the trend.

What Specialization Looks Like in Practice

We watched this happen with Omnius. Years of concentrating on search for B2B software, and later on AI search specifically, gradually produced enough customers, research, technology, case studies, citations, and external references around the same subject that the association started appearing independently of our own positioning.

Third-party websites, media, software platforms, other agencies, and eventually LLM answers themselves increasingly connected Omnius with AI search optimization (AI SEO/AEO/GEO) for B2B software companies.

We keep a live record of selected mentions on our Recognition page.

Narrowing produced a set of relationships that now describe the company without us:

Omnius → B2B software → SaaS / fintech / AI → SEO → AI search → GEO / AEO → search technology.

Across the highest-intent fintech AI-search prompts we currently track, Omnius represents roughly 9% of AI visibility and 26% of citation share across the measured market.

That association spread because the work kept generating new proof points for others to repeat, much like product-led growth turns the product into part of the distribution.

Ask an AI system for agencies specializing in AI search optimization for SaaS or fintech, and those are the relationships available to retrieval.

Ask for the best marketing agency for a traditional offline consumer business, and we should not appear, because we have deliberately built almost no association equity there.

A company does not need to be relevant to every candidate pool, only to the ones that matter.

That is also why we eventually formalized entity work as its own part of what we do. The objective is to resolve and strengthen the associations a business has earned.

Website architecture, internal linking, structured data, and external corroboration then follow from that model.

What Most AI Search Programs Skip

Keywords, links, content quality, and technical accessibility still matter. Traditional search infrastructure does not disappear because a chat interface sits on top of it.

What has changed is that exact words are no longer sufficient to describe the optimization problem, because the company itself has to make sense as a connected object.

That is the step most AI search programs skip. They track thousands of prompts, publish more content, watch citations move up and down, and try to optimize individual answers without first resolving the information those answers are assembled from.

The result is a sophisticated measurement system sitting on top of a company the model still does not understand.

A clear, consistent, corroborated record of what the company is and what it connects to has to come first. Content, pages and prompt tracking come after it; otherwise all of that activity rests on relationships the engine cannot confirm.

Prompt tracking also misses a large part of how buyers see answers.

A tracked prompt runs in a clean session, while real buyers ask inside accounts that remember them: ChatGPT and other assistants draw on saved memories and earlier conversations, a deeper layer of personalization than Google search ever had.

The SaaS-founder example earlier shows the effect, since the same question returns a different candidate pool once the engine knows the asker's industry, and that context is resolved through entities.

It also records only the last step, the answer itself.

The chain behind it (how the engine resolves the company, which sources it retrieves and how it weighs them) decides the outcome, and that chain is where entity work has its effect.

A tracking report shows where a company appears; the entity layer explains why, across every personalized version of the question that no prompt set will contain.

We built Atomic, our AI search analytics platform, with these limits in mind: it is designed to be more objective and to report fewer false positives, and its entity coverage and performance analysis show which relationships sit behind a company's visibility.

Optimizing a distribution, not an answer

None of this makes AI search deterministic. A company can have strong entity representation and still vanish from a given answer, because models change, retrieval sources change, indexes change, prompts change, and personal context can send two similar questions down different retrieval paths.

That variability is why we don't optimize for one answer, but for the probability of favorable positioning across a distribution of answers. This is what entity work is suited to: It does not try to dictate a piece of generated text; it improves the inputs from which many different answers get constructed.

Make the company easier to identify and its important claims corroborated outside the domain, then keep the model current as the business changes.

Start with What a Machine Can Already Conclude

Entity work has an unusual property for a marketing discipline: Most of it is removing the ambiguity that keeps an engine from placing a company it would otherwise be right to recommend, and then getting the relationships that matter confirmed by entities other than the company itself.

Run the check before the strategy:

1. Ask a model what your company is known for.
2. Ask it to describe your three closest competitors.
3. Read the four answers side by side.

If the only thing separating them is the name, more content will not fix it, because there is nothing consistent for a machine to retrieve.

The failure mode changes accordingly:

• The page is not ranking badly; the company was never retrieved.
• The website is cited while the brand stays invisible.
• The company claims a category the wider web does not corroborate.
• The graph is fragmented before schema ever touches it.
• Twenty technically competent pages explain twenty different versions of the same business.

Fixing another title tag does not resolve any of those, which is why we think of this work as retrieval architecture for a company rather than metadata for a page.

It has to become identifiable before it can be connected, connected before those relationships are retrievable, and supported before they are defensible. The goal was never to be associated with everything. It is to become the obvious association for something worth owning.

Working with Omnius

Most B2B software companies do not have the internal capacity to resolve a company model, rebuild site architecture around it, and run a corroboration program at the same time.

Our Entity SEO & Knowledge Graph Optimization work does that for SaaS, fintech, AI, and enterprise software companies: We resolve what the company is, map the relationships that matter commercially, turn that model into website and structured-data architecture, identify where independent evidence is missing, and monitor how engines represent the company over time.

It runs on our own technology, which treats brands, competitors, prompts, clusters, pages, citations, sources, engines, and answers as connected objects rather than separate reports.

Frequently Asked Questions

What is Entity SEO?

Entity SEO is the work of making the things that define a company (its products, capabilities, customers, categories, use cases, and people) clear, consistent, and connected across search engines and AI systems.

It focuses on relationships between those things rather than keywords on individual pages, and it includes basic company facts such as founders, locations, and the legal entity behind the brand.

Is Entity SEO the same as schema markup?

No. Schema expresses selected entities and relationships in a machine-readable format, but it cannot decide what the company is, resolve conflicting descriptions, determine which relationships matter commercially, or create independent evidence for a claim. Schema follows the company model; it does not replace it.

How is Entity SEO different from semantic SEO?

Semantic SEO improves the meaning, context, and topical depth of content. Entity SEO works at the company level, clarifying what the company, its products, customers, categories, and capabilities are and how they connect across the website and the wider web.

Can a company be invisible in AI search while ranking well on Google?

Yes, and it is common. Across the domains we track, only around 8–12% of pages cited in AI answers also appear in Google's top ten for the corresponding searches, a figure close to the ~12% Ahrefs reported across 15,000 prompts. Strong classical rankings do not guarantee inclusion in the candidate set an answer is assembled from.

Is prompt tracking enough to measure AI search?

No. Synthetic prompt tracking shows where a company appears, but not necessarily why, what the commercial value is, or what should happen next. It samples a simulation of the market using prompts you chose, so it is a directional signal rather than a number to plan a budget around.

Useful decisions need broader evidence: competitors, citations, technical accessibility, traditional search, website behavior, attribution, conversions, and revenue.

Our company name is ambiguous. Does that matter?

Yes, and it is more common in B2B software than teams expect, because product names collide with ordinary words and with other businesses. When a mention could plausibly refer to several things, it is cheap for an engine to discount.

The fixes are identifier-based: Claim and align registry and profile records, link to them with sameAs, use the full company or product name where engines read most, and keep the surrounding context (category, location, people, products) consistent across sources.

How long does entity work take to show results?

Representation changes, such as resolving conflicts, consolidating pages, and fixing structured data, can be implemented within weeks, while corroboration through customers, partners, publications, and databases accumulates over months. Engine representation then updates on its own cadence, which varies by model and by how often sources are recrawled.

Author's Disclaimers

This article describes mechanisms that are publicly documented, plus a reconstruction of how they fit together. The retrieval sequence described here is a reasonable conceptual model, not a confirmed map of any commercial engine: Google, Anthropic, OpenAI, and others do not publish ranking algorithms, signal weightings, or retrieval architectures in full, and they change them without announcement.

Where evidence is borrowed from research, the context differs from commercial AI search. Anthropic's retrieval figures come from knowledge-base retrieval experiments. Microsoft's GraphRAG results come from research comparisons rather than production engines. The Semrush and Ahrefs studies are observational, so they establish association rather than causation. The Volvo survey figures were reported by Volvo.

What is not in question is the underlying constraint: An engine can only retrieve and reason over the relationships available to it, and clear, connected, independently supported information gives it more to work with than contradictory or self-asserted claims. The specific numbers will age; the constraint will not.