Entity disambiguation in the LLM era
Your brand is an entity. Your competitor is an entity. How AI retrieval differentiates between them is now a foundational SEO concern, and the work to disambiguate properly is structural, not promotional.
For most of search history, the unit of competition was the keyword. You ranked for “project management software” or you didn’t. The query was the abstraction, and the system’s job was to match queries to pages.
That model is increasingly wrong. The newer unit of competition is the entity, a specific thing in the world that retrieval systems can identify, distinguish from similar things, and reason about. Your brand is an entity. Your product is an entity. Your category is an entity. So is your competitor.
The work of making sure retrieval systems can correctly identify which entity your content is about, that’s entity disambiguation. And it’s now structural infrastructure, not a metadata afterthought.
Why entities matter now, in a way they didn’t before
LLMs operate on entity-level abstractions natively. When you ask ChatGPT about “Linear”, it doesn’t pattern-match the string “Linear” against indexed pages, it identifies which Linear you’re asking about (the project management tool, the mathematical concept, the algebra subfield, the name?), retrieves content known to be about that specific entity, and generates a response.
The disambiguation happens upstream of retrieval. If your content can’t be reliably tagged to the correct entity, it doesn’t enter the retrieval candidate set even if it would otherwise be a perfect match.
This is why entity disambiguation is now structurally upstream of traditional SEO. You can’t rank for queries about your brand if the system can’t reliably identify that your content is about your brand and not the homonym.
The pre-LLM era treated entity identification as a metadata enhancement. The current era treats it as a precondition for being retrievable at all.
Three failure modes I see constantly
Failure 1: Generic brand naming
Companies named after common nouns or adjectives have a built-in disambiguation problem. “Switch” the SaaS product competes with the verb “switch”, the Nintendo console, and a hundred other entities. The retrieval system has no way to know which one is meant without strong context signals.
The fix is partly editorial, always reference the company by full name on first occurrence (“Switch, the customer onboarding platform”) and partly structural, with schema.org markup, sameAs links to authoritative sources, and consistent disambiguating context across pages.
Failure 2: Product names that collide with category terms
A common pattern: a product named “Analytics” or “Dashboard” or “Reports”. The product page is about the named feature, but the retrieval system can’t distinguish the proper noun from the category. Result: the product page gets buried under generic category content.
The disambiguating move is using the product name always with a qualifier that signals it’s a proper noun, “[Company] Analytics”, “the Reports module in [Product]”. Repetition matters. Retrieval systems learn entity associations from co-occurrence patterns.
Failure 3: Treating “the company” and “the product” as the same entity
This one is subtle but expensive. Most SaaS companies use the same name for the company and the flagship product. Internally that’s fine; for retrieval, it produces ambiguity. A query like “is [Name] hiring?” is about the company; “does [Name] support webhooks?” is about the product.
The retrieval system can distinguish these contextually if your content does. If your pages don’t consistently signal whether they’re discussing the company-entity or the product-entity, you get cross-contaminated retrievals where product queries return company pages and vice versa.
The disambiguation stack
The work to fix this is layered. From cheapest to most expensive:
Layer 1: Editorial consistency
The cheapest, highest-leverage move: pick a canonical form for every important entity on your site and use it consistently. “Linear, Inc.”, not sometimes “Linear” and sometimes “Linear.app” and sometimes “the Linear team.” The retrieval system learns from co-occurrence; inconsistent naming dilutes the signal.
Layer 2: Schema.org markup
Mark up your primary entity with structured data: Organization, SoftwareApplication, Product, Person, whichever applies. Include sameAs links to authoritative sources where they exist (your LinkedIn, your Crunchbase, your Wikipedia entry if you have one).
This isn’t about ranking; it’s about giving the retrieval system explicit machine-readable signals about which entity your content is about. Schema is the cheapest possible disambiguation signal.
Layer 3: Knowledge graph integration
Higher-effort but increasingly important: getting your entity into the public knowledge graphs that LLMs train against. Wikipedia matters disproportionately here, but so do Wikidata, Crunchbase, Product Hunt, and specialized industry directories.
The presence of a Wikipedia article about your entity is one of the strongest disambiguation signals available. Whether you can get one is a separate question, Wikipedia’s notability standards are real, but if you qualify, this is the highest-leverage entity work available.
Layer 4: Consistent external context
The hardest layer: making sure how your entity is described across the web is consistent. Press coverage, podcast appearances, third-party reviews, conference bios, these all contribute to the entity’s context in retrieval models.
You don’t control these directly, but you can influence them by providing consistent canonical descriptions of yourself everywhere you have input. The bio you write for a podcast appearance is doing entity disambiguation work whether you think of it that way or not.
Operator note
If you do nothing else from this essay: standardise how you describe yourself and your company in one short canonical paragraph. Use it everywhere, bios, podcast intros, about pages, schema markup. Consistency at scale is more valuable than any single optimisation.
The competitor entity problem
Most SaaS sites have content that references competitors: comparison pages, alternative-to pages, integration discussions. This is where entity disambiguation gets tactically interesting.
When you write “alternative to [Competitor]”, the retrieval system needs to identify that you’re referring to the same entity the user is asking about. If the competitor name is ambiguous or your context is weak, you get filtered out of the candidate set even when your content is the most relevant.
The fix: when writing comparison content, always introduce the competitor with disambiguating context: “[Competitor], the [category] tool” at least on first occurrence. This applies even when “everyone knows” the competitor. Retrieval systems aren’t people; they need the explicit signal.
The long game
Entity disambiguation isn’t a one-time project. It’s an ongoing editorial discipline. Every new piece of content you publish either reinforces or weakens the entity signals your site has accumulated.
The teams who get this right treat their entity model as a living artifact, documented, audited, and updated as the company evolves. Most teams treat it as either nonexistent or implicit. The gap will widen.
The pre-LLM web treated entities as a metadata concern handled by a single SEO who configured schema once. The current web treats entities as a structural concern that touches editorial, design, distribution, and PR. If you’re only thinking about your entity model in the context of schema.org markup, you’re thinking too narrowly.
Operator note
If you’re a SaaS founder thinking about your acquisition system and want to talk this through, book a call – I take a small number of these per quarter.
-Yash