Запит, який зливає угоду

Покупець вбиває у Google “Manimama crypto license”. AI Overview видає три речення про Manimama Bakery у Львові — графік роботи, відгук на синабон, адреса пекарні. А юрфірма Manimama — українсько-литовська практика з крипто-ліцензування, на яку покупець збирався робити бриф — у панелі взагалі відсутня.

Цей запит щойно злив угоду. Не тому, що контент фірми поганий. Тому, що entity resolver обрав не ту Manimama.

Цей пост — про фікс. Він працює для будь-якого бренду, чия назва збігається з регуляторним акронімом (VASP, CASP, CMS, EMI, MSB), звичайним англійським словом або конкурентом, що відрізняється однією літерою.

Чому AI обирає не ту сутність

Entity resolution у LLM — це не матч за релевантністю. Це матч за вагою цитувань.

Коли запит містить рядок, що мапиться на кілька сутностей — модель обирає ту, у якої більше авторитетних зовнішніх згадок. Wikipedia, Wikidata, новини, schema.org markup, панелі knowledge graph. Якщо у пекарні є Google Business Profile з 400 відгуками, а у юрфірми — новий сайт без Wikidata-сутності, виграє пекарня. Навіть коли поряд з брендом стоїть “crypto license”.

Збіг за ключем теж важить — але лише як tiebreaker. Основний важіль — яку сутність knowledge graph від Google уже знає. AIO успадковує це рішення і витягує summary тієї сутності, що виграла resolution.

Тому робота — не “ранжуватись за ключем”. Робота — “зробити так, щоб у resolution виграла потрібна сутність”.

Три класи колізій — три різні фікси

Ми бачимо три патерни знов і знов. У кожного свій стартовий хід.

Клас 1: бренд = регуляторний акронім. Найважчий випадок. VASP у регуляції ЄС — це Virtual Asset Service Provider. Якщо твоя фірма називається VASP-щось — кожен запит “what is VASP” тягне регуляторний контент EBA, ESMA, центробанків. Не тебе. Фікс — ніколи не використовувати голий акронім як H1, і завжди парувати бренд з категорією у title-патерні. Сама сторінка про акронім стає disambiguator: “VASP — що це означає у крипто-регуляції ЄС, і як [наша фірма] допомагає ним стати”.

Клас 2: бренд = звичайне слово. Apple, Notion, Shopify, Discord — усі починали тут. Фікс — маса. Зрештою ти переважуєш старіше значення. Але поки маси немає, єдиний короткостроковий хід — парування з категорією у title і H1 плюс disambiguatingDescription на кожній сторінці.

Клас 3: бренд відрізняється однією літерою від конкурента. Тихий вбивця. Пошуки з помилками. Голосові асистенти неправильно чують. Фікс — явно володіти варіантом з помилкою. Окрема сторінка-варіант, на якій написано: “Якщо ти мав на увазі [конкурент] — вони тут [competitor.com]. Ми — [твій бренд], [категорія]”. Контрінтуїтивно. Але це зупиняє AI від злиття двох сутностей і забирає момент дисамбігуації собі.

Title і H1 — дисципліна

Це найдешевший фікс. І більшість команд його робить неправильно.

Ніколи не використовуй голий бренд як H1 на категорійно-колізійному запиті. Робочий патерн:

<Бренд> <Категорія> · <USP>

Для Manimama Law Firm title-патерн — “Manimama Law Firm — Crypto Licensing in Lithuania, Estonia, Czechia”. Не “Manimama”. Не “Manimama Crypto”. Слово-категорія — це частина, яка потрібна resolver-у.

Кожна сторінка сайту має слідувати патерну. Головна, about, послуги, блог. Бренд завжди парується зі словом-категорією у перших 60 символах title і у H1. Це коштує десять хвилин на правку шаблонів і їде на наступному краулі.

disambiguatingDescription — поле, яке всі пропускають

У schema.org є поле, буквально створене під цю проблему. Називається disambiguatingDescription і живе на Thing — тобто будь-яка Organization, Person, LocalBusiness, Product schema може його нести.

Більшість команд ніколи його не розгортала. Включно з командами, які платять агенціям реальні гроші за AEO-роботу.

Ось як виглядає на Organization-схемі:

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://manimama.eu/#org",
  "name": "Manimama Law Firm",
  "alternateName": "Manimama Legal",
  "disambiguatingDescription": "Manimama Law Firm — українсько-литовська юридична практика, що спеціалізується на крипто-ліцензуванні (VASP, CASP, MiCA). Не плутати з Manimama Bakery — окремим бізнесом у Львові.",
  "description": "Юрфірма з крипто-ліцензування. Допомагаємо крипто-бізнесам отримати VASP, CASP і MiCA ліцензії в ЄС.",
  "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"
  ]
}

Дві речі. Перша — disambiguatingDescription явно називає колізію: “не плутати з Manimama Bakery”. Це саме те, під що поле спроектовано. Друга — description і disambiguatingDescription це різні поля, і потрібні обидва. Description — маркетингова лінія. disambiguatingDescription — підказка для resolver-а.

Розгортай на Organization-схемі, на Person-схемі іменованих партнерів на головній і на будь-якій сторінці, де колізія брендової назви випливає у тестах.

Wikidata + sameAs — стійкий шар

Title і disambiguatingDescription — миттєвий фікс. Починають працювати на наступному краулі. Але вони живуть на твоєму сайті. А resolver важить зовнішні джерела сильніше.

Стійкий фікс — Wikidata.

Wikidata Q-number з правильною disambiguation-нотаткою (“Q123456789: Manimama Law, українсько-литовська юрфірма з крипто-ліцензування — окремо від Manimama Bakery”) стає entity ID, до якого AI-екстрактори анкоряться. Як тільки він існує і реферується через sameAs з твоєї schema — у resolver-а зʼявляється чистий зовнішній сигнал, який знімає колізію.

Механіку Wikidata ми розбирали у Wikidata і Knowledge Graph. Дисамбігуаційно-специфічне доповнення — поле “description” у Wikidata. Зроби так, щоб воно явно відрізняло сутність від колізійної цілі. Не пиши “law firm in Ukraine”. Пиши “Ukrainian-Lithuanian crypto-licensing law firm; not to be confused with Manimama Bakery (Lviv)”.

Цей опис показується на кожному реферансі Wikidata. Включно з рефенсами, які AI-моделі використовують при складанні training corpus.

Дисципліна анкорів у outreach

Коли інші лінкують на тебе — анкор-текст є частиною сигналу entity resolution.

Голий “Manimama” — голий бренд — активно посилює колізію. Кожен бекленк з анкором “Manimama” каже resolver-у: “ця сутність — це штука, що зветься Manimama, і таких у нас багато”. Марно.

“Manimama crypto license” або “Manimama Law Firm” — анкор зі словом-категорією — це версія, яка допомагає. Кожна outreach-кампанія, кожна гостьова публікація, кожна заявка у каталог має використовувати парну форму.

Брифуй свою outreach-команду або агенцію. Кидай їм title-патерн і кажи, що голий бренд в анкорі заборонено. Це 5-хвилинний бриф, і більшість outreach-команд його ніколи не отримувала.

Як протестувати сьогодні

Відкрий ChatGPT, Perplexity і Gemini. Введи пʼять промптів, де є тільки бренд — без категорії, без кваліфікатора. Приклади:

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

Читай, що повертається. Зафіксуй, де платформа показує не ту сутність, а де вже все правильно. Цей розподіл — твій геп.

ChatGPT і Perplexity оновлюються швидше за Gemini. Gemini і Google AIO консервативніші — вони сильніше анкоряться на knowledge graph, тому повільніше перемикаються, але стабільніше тримають результат після перемикання.

Перезапускай ті ж пʼять промптів після кожного шару дисамбігуації. Ти побачиш, що title і disambiguatingDescription перемикають ChatGPT і Perplexity за дні. Gemini і AIO рухаються по таймеру Wikidata — тижні.

Таймлайн відновлення

Реальний графік після старту відправлення сигналів:

  • День 0–7 — title-патерн, H1-патерн, disambiguatingDescription на кожній сторінці. ChatGPT і Perplexity починають перемикатися на відомих “бренд+категорія” промптах.
  • День 7–21 — sameAs розгорнуто на LinkedIn, офіційних соцмережах, реєстрових профілях, конференційних сторінках. Resolver отримує зовнішнє підтвердження. AIO починає перемикатися на прямих брендових запитах.
  • День 21–60 — Wikidata Q-number створено з явною disambiguation-нотаткою. Q-number зреференсовано з schema sameAs. Knowledge graph панель починає спалахувати на брендових запитах.
  • День 60–90 — повний ефект. AI Overview і Gemini стабілізуються на правильній сутності на пріоритетному наборі промптів.

Можна скоротити, якщо бренд уже має notability у Wikipedia або встановлені сигнали Knowledge Graph. Можна розтягнути, якщо колізійна ціль — великий бренд зі своєю Wikipedia-статтею. Тоді Wikidata сам не витягне, і потрібен буде стійкий приріст цитувань, щоб переважити старшу сутність.

Чого ми робити не будемо

  • Редагувати Wikipedia за клієнта. Community policy. Бренд платить ціну, коли спіймають.
  • Подавати Wikidata-сутність, що не відповідає notability.
  • Купувати bulk-анкори. Навіть з правильним анкором — платні лінки видно.
  • Обіцяти конкретну дату, коли AI перемкнеться. Імовірність висока. Дата — недетерміністична.

Непопулярна думка

Якщо твій prospect телефонує і каже “я загуглив тебе, а воно показало щось інше” — це не контент-аудит. Це entity-аудит. Різні практики.

Більшість агенцій з AEO-retainer ніколи не розгортали disambiguatingDescription на жодній сторінці. Вони пишуть контент, шиплять schema-шаблони, моніторять citation rate. Це все не торкається entity resolution. Коли вузьке місце — колізія брендової назви, більше контенту лише погіршує. Кожна нова сторінка — це ще одна анонімна згадка, що додає шуму до resolver-а.

Фікс — це ідентичність, не обʼєм. Title-патерн, disambiguatingDescription, sameAs, Wikidata, дисципліна анкорів. Пʼять шарів, шістдесят днів, реальний entity-authority. Після цього контент компаундиться. До цього — контент марнується.

Ми вшиваємо entity-аудит у Starter audit, коли колізія брендової назви випливає на фазі тестування промптів. Якщо ти не знаєш, чи маєш колізію — тест із цього посту займає десять хвилин. Зроби його перед наступним контент-спринтом, а не після.