The query that loses the deal

A buyer types “Manimama crypto license” into Google. The AI Overview returns three sentences about Manimama Bakery in Lviv — opening hours, a cinnamon-roll review, the bakery’s address. The actual Manimama Law Firm — a Ukrainian crypto-licensing practice your buyer was about to brief — is not in the panel.

That query just lost the deal. Not because the firm’s content is bad. Because the entity resolver picked the wrong Manimama.

This post is the fix. It works for any brand whose name collides with a regulated acronym (VASP, CASP, CMS, EMI, MSB), a generic English word, or a competitor that’s one letter different.

Why AI extractors pick the wrong entity

Entity resolution in LLMs is not a relevance match. It is a citation-weight match.

When a query contains a string that maps to multiple entities, the model picks the entity with the most authoritative external mentions — Wikipedia, Wikidata, news, schema.org markup, knowledge-graph panels. If the bakery has a Google Business Profile with 400 reviews and the law firm has a brand-new site with no Wikidata entity, the bakery wins. Even when the user typed “crypto license” right next to the brand name.

Keyword match still matters — but only as a tiebreaker. The primary lever is which entity Google’s knowledge graph already knows. AIO inherits that judgment and extracts a summary of whichever entity won the resolution step.

So the work is not “rank for the keyword”. The work is “make sure the right entity wins resolution”.

Three collision classes — different fixes

We see three patterns repeatedly. Each has a different starting move.

Class 1: brand name equals a regulated acronym. This is the worst case. VASP means Virtual Asset Service Provider in EU regulation. If your firm is named VASP-something, every “what is VASP” query pulls regulatory definition content from EBA, ESMA, central-bank portals — not your firm. The fix is to never use the bare acronym as your H1, and to always pair brand with category in the title pattern. The acronym page itself becomes a disambiguator: “VASP — what it means in EU crypto regulation, and how [our firm] helps you become one.”

Class 2: brand name equals a generic word. Apple, Notion, Shopify, Discord all started here. The fix is mass — eventually you outweigh the older meaning. Until you have that mass, the only short-term move is the category pairing in title and H1, plus disambiguatingDescription on every page.

Class 3: brand name is one letter off a competitor. This is the silent killer. Searches misspell. Voice assistants mishear. The fix is owning the misspelling explicitly — a redirect-friendly variant page that says “If you meant [competitor], they are at [competitor.com]. We are [your brand], [category].” Counterintuitive, but it stops AI from conflating the two and steals the disambiguation moment for itself.

Title and H1 — the discipline

This is the cheapest fix and most teams get it wrong.

Never use the bare brand as your H1 on a category-collision query. The pattern that works:

<Brand> <Category> · <USP>

For Manimama Law Firm, the title pattern is “Manimama Law Firm — Crypto Licensing in Lithuania, Estonia, Czechia”. Not “Manimama”. Not “Manimama Crypto”. The category word is the part the resolver needs.

Every page on the site should follow the pattern. Homepage, about, services, blog. The brand is always paired with a category word in the first 60 characters of the title and the H1. This costs ten minutes per template change and ships on the next crawl.

disambiguatingDescription — the field everyone skips

schema.org has a field literally built for this problem. It is called disambiguatingDescription and it lives on Thing, which means every Organization, Person, LocalBusiness, Product schema can carry it.

Most teams have never deployed it. Including teams paying agencies real money for AEO work.

Here is how it looks on an Organization schema:

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://manimama.eu/#org",
  "name": "Manimama Law Firm",
  "alternateName": "Manimama Legal",
  "disambiguatingDescription": "Manimama Law Firm is a Ukrainian-Lithuanian legal practice specialising in crypto-asset licensing (VASP, CASP, MiCA). Not to be confused with Manimama Bakery, a separate business operating in Lviv, Ukraine.",
  "description": "Crypto-licensing law firm helping crypto businesses obtain VASP, CASP and MiCA licences across the EU.",
  "url": "https://manimama.eu",
  "sameAs": [
    "https://www.linkedin.com/company/manimama-legal",
    "https://www.wikidata.org/wiki/Q123456789"
  ],
  "knowsAbout": [
    "VASP licensing",
    "CASP licensing",
    "MiCA regulation",
    "EU crypto compliance"
  ]
}

Two things to note. First, the disambiguatingDescription explicitly names the collision — “not to be confused with Manimama Bakery”. This is exactly what the spec was designed for. Second, the description and disambiguatingDescription are different fields and you need both. Description is the marketing line. disambiguatingDescription is the resolver hint.

Deploy it on the Organization schema, the homepage Person schema for named partners, and any page where the brand-name collision shows up in tests.

Wikidata + sameAs — the durable layer

Title and disambiguatingDescription are the instant fix. They start working on the next crawl. But they live on your site, which the resolver weights less than external sources.

The durable fix is Wikidata.

A Wikidata Q-number with the right disambiguation note (“Q123456789: Manimama Law, a Ukrainian-Lithuanian crypto-licensing law firm — distinct from Manimama Bakery”) becomes the entity ID that AI extractors anchor to. Once it exists and is referenced via sameAs from your schema, the resolver has a clean external signal that resolves the collision.

We covered the Wikidata mechanics in Wikidata and the Knowledge Graph. The disambiguation-specific addition is the Wikidata “description” field — make sure it explicitly differentiates the entity from the collision target. Don’t write “law firm in Ukraine”. Write “Ukrainian-Lithuanian crypto-licensing law firm; not to be confused with Manimama Bakery (Lviv)”.

That description shows up on every Wikidata reference. Including the references AI models use during training corpus assembly.

Anchor-text discipline on outreach

When other people link to you, the anchor text is part of the entity-resolution signal.

“Manimama” alone — the bare brand — actively reinforces the collision. Every backlink with anchor “Manimama” tells the resolver “this entity is a thing called Manimama, and we have lots of those”. Useless.

“Manimama crypto license” or “Manimama Law Firm” — anchor with category word — is the version that helps. Every outreach campaign, every guest-post placement, every directory submission needs to use the paired form.

Brief your outreach team or your agency. Send them the title pattern and tell them the bare brand is banned in anchor text. This is a five-minute brief and most outreach teams have never had it.

How to test today

Open ChatGPT, Perplexity and Gemini. Type five prompts using only your brand name — no category, no qualifier. Examples:

  • “What is [brand]?”
  • “Tell me about [brand]”
  • “Who founded [brand]?”
  • “What does [brand] do?”
  • “Where is [brand] based?”

Read what comes back. Note which platform surfaces the wrong entity, and which already gets it right. That distribution is your gap.

ChatGPT and Perplexity tend to update faster than Gemini. Gemini and Google AIO tend to be more conservative — they lean harder on knowledge-graph anchoring, so they’re slower to flip but stickier once they do.

Re-run the same five prompts after each disambiguation layer ships. You’ll see the title and disambiguatingDescription move ChatGPT and Perplexity within days. Gemini and AIO move on the Wikidata clock — weeks.

Recovery timeline

Realistic schedule once you start shipping signals:

  • Day 0–7 — title pattern, H1 pattern, disambiguatingDescription on every page. ChatGPT and Perplexity start flipping for known brand+category prompts.
  • Day 7–21 — sameAs deployed across LinkedIn, official social, registry profile, conference pages. Resolver gets external corroboration. AIO starts to flip on direct-brand queries.
  • Day 21–60 — Wikidata Q-number created with explicit disambiguation note. Q-number referenced from schema sameAs. Knowledge-graph panel starts to fire on branded queries.
  • Day 60–90 — full effect. AI Overviews and Gemini stabilise on the right entity for the priority prompt set.

You can compress this if the brand already has Wikipedia notability or established Knowledge Graph signals. You can stretch it if the collision target is a major brand with Wikipedia coverage of its own — then Wikidata alone won’t be enough and you’ll need sustained citation lift to outweigh the older entity.

What we will not do

  • Edit Wikipedia for a client (community policy; brand pays the cost when caught)
  • Submit a Wikidata entity that does not meet notability
  • Buy bulk anchor text — even with the right anchor, paid links are detectable
  • Promise a specific date when AI flips. The probability is high; the date is not deterministic

The unpopular opinion

If your prospect calls and says “I googled you and it showed something else”, the fix isn’t a content audit. It’s an entity audit. Different practice.

Most agencies running an AEO retainer have never deployed disambiguatingDescription on a single page. They write content, ship schema templates, monitor citation rate. None of that touches entity resolution. When the brand-name collision is the bottleneck, more content makes the problem worse — every new page is one more anonymous mention adding noise to the resolver.

The fix is identity, not volume. Title pattern, disambiguatingDescription, sameAs, Wikidata, anchor discipline. Five layers, sixty days, real entity authority. After that, the content compounds. Before that, the content is wasted.

We bake the entity audit into the Starter audit when the brand-name collision shows up in the prompt-test phase. If you don’t know whether you have a collision, the test in this post takes ten minutes. Do it before the next content sprint, not after.