Knowledge Graph або смерть без скандалу: як зникнути з ринку за квартал, нічого поганого не зробивши

Author: Дністер
Published: 2026-06-15T03:01:08.000Z
Language: uk-UA
URL: https://neurodrift.org/blog/knowledge-graph-abo-smert-bez-skandalu/
Tags: ai-search, knowledge-graph, wikidata, entity-seo, brand-survival, llm-citation

У червні 2025-го Google за тиждень видалив >3 млрд сутностей зі свого графа — і нікого не попередив. Бренди в 2026-му гинуть не у вибуху скандалу, а в JSON-тиші: одного ранку AI Overviews описує тебе чужими словами, ChatGPT каже про твого фаундера «I don't have reliable information», а quarter ago все було «ок». Це не пост про SEO. Це аудит того, чи існуєш ти для машини.

-----
«Ринок не оголосить твою смерть. Не буде заголовків "X закрилась", не буде LinkedIn-постів "дякуємо за роки". Буде тиша — спершу в AI Overviews, потім в inbound'і, потім у воронці. До моменту, коли стане боляче, у графа вже буде твоя версія — оптимізована для конкурентів.»

 Партнер дослідження — Wikibusines. Команда, що будує саме той entity-шар, про який цей текст: від Wikidata та knowledge-graph SEO до аудиту notability для Wikipedia. Усі цифри, кейси й 60-хвилинний аудит нижче — незалежні; партнерство — у тому, щоб перетворити діагноз на дію.

I. Київ, 11:40, березень 2026 — або як виглядає JSON-тиша

Київ, середа, 11:40. B2B-фаундер на 80 людей у штаті кричить на свою маркетингову агенцію через Zoom і ділиться екраном так, ніби це доказ у суді. На екрані — Google Search, запит за категорією, у якій його компанія три роки була top-of-mind. AI Overview ввічливо переказує його ринок «згідно з кількома джерелами»; у кружечках цитат — два конкуренти й один аналітичний блог, якого він уперше бачить. Він перемикає вкладку, заходить у ChatGPT, набирає «who is [його ім'я і прізвище]». Модель чесно відповідає: I don't have reliable information about this person. Quarter ago все було «ок»: 14 тисяч органічного трафіку на місяць, дві угоди з тижневого inbound'у, інвойси сходяться. Жоден email від Google не приходив. Жоден alert не світився. Просто одного ранку він зрозумів, що в шести з десяти найдорожчих контекстів його компанія більше не існує — а попередньої ночі ще існувала.

Це не його одного історія. У червні 2025-го, за оцінкою Search Engine Land, Google за один тиждень виконав найбільший в історії свого Knowledge Graph «anti-hoarding cleanup»: дві хвилі деіндексації — 13 і 20 червня — стиснули граф на ~6,26%, видаливши орієнтовно понад 3 мільярди сутностей; категорія «event» була зрізана на 76,91%, тип «thing» — приблизно на 15%, окремий follow-up прийшов 11 серпня. Власники цих сутностей у переважній більшості дізналися постфактум — по падінню AI-цитувань, потім по падінню inbound'у, потім по запитанню фінансового директора «а чому ми не в шорт-лісті в N?». Жодне з цих видалень не супроводжувалось офіційним повідомленням. Це не санкція. Це не покарання. Це гігієна графа, у якій звичайна компанія — побічний шум.

Щоб зрозуміти, як таке стало можливим у 2026-му, потрібно усвідомити одну неприємну річ: машини більше не читають твій сайт прозу. Вони читають твій вузол у графі. Якщо тебе там нема, або тебе там троє, або твій вузол стиснули у червневій чистці — для LLM ти не існуєш, навіть коли клієнти ще пам'ятають твоє ім'я. У цьому тексті ми розбираємо новий шар видимості — entity layer — і вводимо інструмент діагнозу під назвою Entity Survival Index (ESI): п'ять осей, на яких твоя компанія або тримається в графі, або осідає в JSON-тишу. Це не теорія платформ. Це виписка по другому рахунку, якого більшість фаундерів ніколи не відкривала, але по якому давно платить.

II. Чому саме зараз: чотири події, що переписали правила за рік

Якщо хтось два роки тому казав «треба думати про Wikidata», на нього дивились як на esoteric SEO. У 2026-му ця сама порада звучить як «треба думати про бухгалтерію» — тобто нудно, обов'язково й передбачувано. Між цими двома станами вмістилось чотири події, кожна з яких окремо була новиною на день, а разом вони поміняли механіку видимості.

Перше: граф вибухнув у розмірі. У травні 2024-го Google офіційно (за переказом Search Engine Land і зведеннями на Wikipedia) називав цифру понад 1,6 трильйона фактів про близько 54 мільярдів сутностей у своєму Knowledge Graph. У 2020-му ці ж самі числа звучали як 500 мільярдів фактів про 5 мільярдів сутностей. Приріст приблизно 11x за чотири роки, у тому числі понад 10 мільярдів доданих сутностей у липні 2023-го і ще 4 мільярди за один день у березні 2024-го. Це вже не «база фактів про знаменитостей». Це адресна книга цивілізації.

Друге: граф уперше масово видалив. Після експоненційного зростання прийшов перший зворотний рух — і він був не косметичним. Червень 2025-го, той самий «anti-hoarding cleanup»: −6,26% за тиждень, понад 3 мільярди сутностей знесено двома хвилями, без оголошень. Категорія «event» — мінус 76,91%. Сутності типу «thing» (загальне відро для всього, що Google не зміг точніше класифікувати) — мінус приблизно 15%. У серпні — follow-up. Паралельно частка «unityped» сутностей-персон зросла з ~70,16% до ~76,78% — тобто Google активно унifікував дублі осіб у єдиний вузол. Сигнал ринку був недвозначний: просто бути в графі більше недостатньо. Треба бути в ньому переконливо.

 Просто бути в графі більше недостатньо. Треба бути в ньому переконливо — настільки, щоб у наступну чистку машина обрала об'єднати дублі під твоїм вузлом, а не під вузлом конкурента, який підготувався краще.

Третє: змінилася сторона запиту. AI Overviews, ChatGPT Search, Perplexity, Bing Copilot перестали бути іграшками для гіків. За даними згрупованих індустріальних звітів 2025–2026, помітна частина B2B-покупців у tech, SaaS і профеcійних послугах робить перший дотик до вендора саме в AI-інтерфейсі, а не в класичному Google. Це принципово інша механіка вибірки: класичний пошук показує десять синіх посилань, і ти можеш проскролити вниз, аж поки знайдеш свого героя. AI-інтерфейс називає три імені — або не називає твого. Між «бути на третій сторінці» і «не бути в графі» — раніше була кількісна різниця в трафіку. Тепер — якісна різниця в існуванні.

Четверте: захисний шар не наростив. За оцінкою агрегованих звітів про адопцію розмітки (зведення W3C, amraandelma, WP Newsify за 2024–2025) станом на кінець 2024-го з приблизно 362,3 мільйона зареєстрованих доменів лише близько 12,4% (близько 45 мільйонів) використовують хоч якусь structured data; водночас понад 87% сайтів у топ-3 органіки за конкурентними запитами користуються JSON-LD коректно й консистентно. Іншими словами: переможці вийшли на новий рівень бронежилета, а основна маса — досі в футболці. Поріг видимості різко зріс; більшість компаній не озброєна навіть першим шаром розмітки. У це вікно й провалюються.

Сума цих чотирьох рухів — і є «why now». Раніше можна було робити SEO, як це робили в 2018-му, і пожинати «нормальні» результати. Зараз база ринку рухається на іншу площину видимості — entity layer, — а більшість бізнесів про це дізнається в той момент, коли AI Overviews починає переказувати їхню категорію без них.

III. Що таке entity layer (і чому твій сайт — лист у пляшці)

Зайдемо в основу акуратно, бо тут плутаються поняття, які не можна плутати. Сайт — це HTML-сторінки про тебе, які можна прочитати очима. Профіль — це твій представницький запис на чужій платформі (LinkedIn, Crunchbase, X). Entity — це не «текст» і не «профіль». Це запис у машинному реєстрі сутностей, у якого є стабільний унікальний ідентифікатор, набір тверджень (claims) у форматі Subject–Predicate–Object, і мережа посилань на інші сутності того ж реєстру.

Аналогія-скальпель, до якої ми будемо повертатися протягом усього тексту. Твій сайт — це лист у пляшці, який ти кинув у океан і сподіваєшся, що його хтось знайде. Граф — це адресна книга, у якій або є твоя адреса, або немає. Якщо нема — лист дійде тільки до того, хто вже знає твою пляшку в обличчя. Сторінка про твій бренд може бути блискучою; якщо в адресній книзі немає рядка «AcmeCo → ось ця пляшка → ось ці три факти про неї → ось її дзеркала на LinkedIn, Wikipedia, Crunchbase», машина проходить повз. У 2016-му це було незручно; у 2026-му це смертний вирок повільної дії.

Wikidata тут — окремий герой. Це публічна, безкоштовна, machine-readable база сутностей, керована спільнотою; станом на 2025-й рік вона тримає понад 120,9 мільйона Q-items (унікальних сутностей), 1,65 мільярда statements (тверджень про ці сутності) і 13 515 P-properties (типів відношень між сутностями), при загальній кумулятивній історії в 2,476 мільярда правок і приблизно 41 987 активних редакторів — за даними самого Wikidata:Statistics. Кожен Q-item — це не «профіль» і не «сторінка». Це первинний ключ: стабільний унікальний ідентифікатор сутності у глобальній адресній книзі машин. Google Knowledge Graph, Bing Satori, OpenAI training corpora, Perplexity index, корпоративні LLM-системи — усі вони, прямо чи опосередковано, звіряються з цією таблицею множення. Якщо в тебе нема Q-ID, твої згадки в новинах нікуди прив'язати: для машини це шматки тексту, що згадують щось імена, які можуть бути про тебе, можуть про когось іншого, а можуть взагалі ні про кого реального.

І тут ми вводимо інструмент, заради якого написаний цей пост.

Entity Survival Index (ESI) — інструмент діагнозу, який оцінює шанси твого бренду пережити наступну машинну чистку. П'ять осей, кожна — окрема відмова, що може окремо тебе вбити:

Presence — чи присвоєно тобі Q-ID у Wikidata? Чи бачить тебе глобальна адресна книга як окрему сутність?
Consistency — чи 5+ незалежних авторитетних джерел називають однакові name / founder / category / foundingDate? Чи не виглядаєш ти як троє різних компаній на одну тінь?
Reconciliation — чи замикаються sameAs-зв'язки між Wikidata ↔ Wikipedia ↔ LinkedIn ↔ Crunchbase ↔ official site коректно й циркулярно? Чи бачить машина одну тебе, а не двох?
Freshness — чи був осмислений edit твого вузла за останні 12 місяців? Чи доглядає за тобою хоч хтось — нехай навіть алгоритмічно?
Panel-Trigger — чи перетнуто емпіричний поріг сигналів (Wikipedia entry + Wikidata Q-item + бездоганна schema.org-розмітка + приблизно 7+ статей на high-authority доменах + узгоджені соц-профілі), який практики (Kalicube, instantpress.co, theStacc) описують як необхідний для появи Knowledge Panel у SERP?

Розклад далі — це по осі на розділ. Кожен — діагноз, конкретика і те, де саме найчастіше ламається. Жоден з цих п'яти параметрів не вилікує всі інші. Зате будь-який з них, провалений, окремо опускає тебе у вікно ризику в наступну чистку.

!Темна серверна стійка з білою бирою-«toe tag» на дротяному решітті — на бирі лише QR-код замість тексту; поряд лежить розкладена паперова стрічка з виписаними Q-ID, частина яких перекреслена червоним; у кутку — маленька жовта гумова качечка з мініатюрним стетоскопом, прикладеним до решітки.

Бирка-«toe tag» на серверній стійці — без імені, з QR-кодом замість тексту. Бо в моргу графа тебе теж ідентифікують не за прізвищем, а за Q-ID. Качечка зі стетоскопом — єдиний доглядач, який лишився на зміні.

IV. Вісь 1: Presence — є Q-ID чи нема

Лютий 2026, нарада з підготовки бюджету в midmarket SaaS-компанії 120 людей. CMO відкриває звіт, у якому вперше окремою колонкою — частка lead'ів з AI-каналів. Цифра незручна: 38% демо-запитів за останній квартал прийшли від людей, які перед тим, як заповнити форму, провели в ChatGPT або Perplexity діалог типу «what are the leading tools for X». Колонка по компанії, що сидить навпроти, — 41%. Колонка по самій компанії — 4%. CMO не розуміє, чому. Конкурент не більший. Конкурент не молодший. Конкурент не голосніший у PR. CMO відкриває Wikidata, шукає свою компанію. Нічого. Шукає конкурента — є Q-item, акуратний, з 23 statements, дев'ятьма зовнішніми ідентифікаторами і трьома редагуваннями за останні шість місяців. Це і є ось вона, осі 1, прірва.

Без Q-ID ти існуєш для людей. Не існуєш для машини. Точніше: існуєш у вигляді розсипу текстових згадок, які машина не може звести в одну сутність, бо нема первинного ключа. Уяви бухгалтерію, у якій кожна транзакція описана прозою, а не прив'язана до коду рахунку. Технічно інформація є; практично її не можна порахувати. Wikidata Q-ID — це і є той код рахунку для тебе як сутності в графі цивілізації.

Чорний гумор тут жорсткий: це як вийти на ринок без ІПН. Формально існуєш, на тебе кричать клієнти, ти платиш зарплати, у тебе є печатка. Але держава не знає, кому виставляти податок, твою компанію не можна перевірити по реєстру, твоїх контрактів не можна валідувати. Тільки тут держава — це не податкова, а Google. І замість штрафу вона виставляє тобі покарання тонше: вона просто не цитує тебе, коли мав би.

Технічно Q-item — це невелика структура. Унікальний ідентифікатор виду Q123456789. Label (основна назва) однією або багатьма мовами. Description (одне речення, що відрізняє цю сутність від однойменних). Aliases (як ще тебе можуть називати). Statements — твердження у форматі property-value, кожне з посиланням на джерело: instance of → company, country → Ukraine, inception → 2019, founded by → [Q-ID конкретної людини], official website → https://…, industry → [Q-ID конкретної галузі], Crunchbase company ID → …, LinkedIn company ID → …, legal form → [Q-ID конкретного типу]. У середній здоровій компанії-сутності — від 15 до 40 statements з джерелами; саме ця сітка тверджень і робить тебе для машини «впізнаваним обличчям», а не «згадкою, яку важко зматчити».

Найчастіше Q-ID немає не тому, що його хтось зловмисно стер. Його просто ніхто не створив. У Wikidata спільнота переважно автоматично «підтягує» сутності, про які є стаття у Wikipedia, плюс додає вручну за потребою. Якщо твоя компанія не має статті в Wikipedia (а більшість компаній на 20–500 людей її не має), Q-item, скоріше за все, ніколи не з'явиться сам собою — і відсутність сама себе підтверджуватиме: машина не цитує → менше джерел → менше шансів, що хтось створить, → менше цитувань. Це класичний від'ємний цикл, у якому пасивна стратегія приречена.

Розірвати цей цикл — це рівно те, що робить партнер цього розбору, Wikibusines: створення й супровід Q-item у Wikidata з джерелом під кожне твердження та замкненим sameAs-контуром, щоб граф бачив тебе як одну впізнавану сутність, а не розсип згадок без первинного ключа.

V. Вісь 2: Consistency — чи всі п'ять дзеркал показують одне обличчя

Барселона, серпень 2025, переговорна кімната агентства цифрового маркетингу. На дошці прокреслено три рядки про одну компанію-клієнта, узяті з трьох різних джерел.

| Поле | Офіційний сайт | LinkedIn | Crunchbase |
| --- | --- | --- | --- |
| Назва | AcmeCo Inc. | Acme Co. | Acme.co |
| Засновано | 2019 | 2020 | 2018 |
| Категорія | Sales intelligence | B2B SaaS | Marketing analytics |
| Засновники | Two named co-founders | One named | Three named |

Для людини це очевидно одна компанія, у якій маркетинг трохи розслабився з консистентністю. Для машини це три різних кандидати на одну згадку. І коли LLM зустрічає у статті в TechCrunch фразу «Acme has raised $4M», у моделі вмикається не «обрати найбільш правильну версію», а anti-hallucination logic: при конфліктних semantic triples (Subject–Predicate–Object) щодо одного й того ж референта модель отримує сигнал «висока невпевненість» і обирає не цитувати, або цитувати з hedge, або підставити сусідній бренд, у якого ці ж триплети узгоджені. Це не маркетинг-фільтр. Це базова поведінка, прописана у пост-RLHF-моделей, щоб не вибльовувати «1,3 мільярда смертей під час пандемії» з конфліктних джерел.

Тобто механіка ось така: чим більше у тебе джерел, тим гірше, якщо ці джерела не узгоджені. Десять консистентних статей про тебе підіймають ймовірність цитування в рази; десять неконсистентних статей про тебе обнуляють її ефективніше, ніж нуль статей, бо тепер модель має активний сигнал «тут плутанина — мовчи». Це парадокс, який топить багато ad-hoc-PR-стратегій: робили 30 публікацій за рік, з них 17 під злегка різні написання назви, з різними роками заснування й різними тегами категорії — і дивуються, чому в AI Overview сидить конкурент з трьома статтями, у яких усе акуратно вкладено в один semantic stack.

Ремитування цього через спостереження аналітичних кейсів (semai.ai, Discovered Labs, aruntastic): сутності з сильними циркулярними sameAs-зв'язками між Wikidata ↔ Wikipedia ↔ LinkedIn ↔ Crunchbase ↔ official site отримують у відповідях AI вагу цитування приблизно у 2–3 рази вищу, ніж сутності без таких зв'язків. Це грубий порядок, а не точне число, але паттерн стабільний: те, що машина може пов'язати в єдиний вузол, вона довіряє; те, що розсипається в плутанину, вона обходить. Counter-pressure до цього розділу: «а може, просто треба, щоб журналісти писали правильно?» — частково так, але джерело правди — твій primary source, тобто твій офіційний сайт із бездоганною Organization-розміткою. Якщо в тебе там foundingDate 2019-04-12, а на LinkedIn Founded 2020, винна не TechCrunch — винна ти, бо не зачинив контур.

!Темна офісна дошка вночі: маркером проведено три горизонтальні рядки, кожен описує одну компанію, але всі рядки трошки різні — різні дати, різні назви; червоним маркером обведено три розбіжності; у кутку дошки кнопками пришпилена маленька жовта гумова качечка, на грудях у неї три різні бейджі з трьома різними іменами одночасно.

Машина не «обирає правильну версію». При конфлікті вона мовчить — це anti-hallucination, не злість. Качечка з трьома бейджами знає, як це: коли тебе впізнають за фото, але не можуть впевнено представити.

VI. Вісь 3: Reconciliation — чи замикається коло sameAs

Найкращий публічний кейс, який показує цю вісь у динаміці, — історія Келлі Шеппард (засновниця The Structured Data Company), яку вона сама задокументувала на блозі structureddata.co.uk у тексті «How I Lost My Knowledge Panel». Коротка версія: Шеппард, верифіковано-claimed Knowledge Panel якої існувала роками, лишила попередню роль (Sleeping Giant Media), почала нову компанію, оновила афіліацію в усіх своїх профілях, — і панель зникла за ніч, заміщена placeholder'ом, який Шеппард описала як «риболовецький монстр» (Google підтягнув якогось випадкового однойменного субʼєкта, що мав слабші дані, але не страждав на «розрив контексту»). Реальна причина: для Google вона на коротку мить виглядала як двоє різних людей — стара афіліація ще тримала вузол, нова афіліація створювала новий, а реконсиляція через sameAs не встигла замкнутися. Відновлення зайняло місяці — через явні kgmid-вказівки у structured data, циркулярні sameAs-посилання Wikipedia ↔ Wikidata ↔ LinkedIn ↔ особистий сайт, і робота з unlinked mentions у незалежних джерелах.

Це кейс із світу профі — людини, яка буквально побудувала бізнес на тому, що навчає інших не втрачати такі панелі. І її панель упала на місяці. Питання: який шанс, що у звичайної компанії на 80 людей, у якої немає виділеного entity-маршала, при ребрендингу / M&A / зміні founder credits станеться те саме? Відповідь, яку нелегко сказати вголос: дуже високий. Більшість M&A-комунікацій 2023–2025 років не мали чек-листа «оновити Wikidata Q-item покупця і ціль, проставити replaced by / replaces properties, підтвердити нові sameAs в обидва боки». Це означає, що в кожному другому злитті ринку народжується «двоє тебе» в графі — а потім один з них тихо помирає, забравши з собою половину твого AI-share.

Reconciliation — це не одноразова дія. Це архітектурна звичка, рівноцінна регулярному резервному копіюванню. Коли в тебе змінюється що-небудь з топ-10 атрибутів (назва, юр. форма, фаундер, CEO, штаб-квартира, ключова категорія, продуктовий фокус, ключові ідентифікатори у Crunchbase / LinkedIn / GitHub-org / Twitter), ти зобов'язаний пройти контуром усі дзеркала і впевнитись, що зв'язки sameAs ведуть в обидва боки і що твердження не суперечать одне одному. Інакше через певний час машина вирішить це за тебе — і ти не сподобаєшся її рішенню.

 Reconciliation — це не «зробив раз». Це адресна книга, яку треба тримати акуратною — інакше одного ранку в ній буде «двоє тебе», і одного з них Google тихо викреслить як дублікат.

VII. Вісь 4: Freshness — як працює entity drift

Третій місяць тиші. Twitter / X-акаунт компанії останній раз постив у березні 2024-го; LinkedIn-сторінка компанії має нерухомий заголовок з 2022 року; Wikidata Q-item, якщо існує, не редагований 23 місяці; Wikipedia-стаття (якщо є) теж стоїть з тими ж параграфами, що були при створенні. Усе працює — клієнти приходять, продукт оновлюється, наймають людей. У внутрішньому світі компанії все живе. У графі — сутність дрейфує.

Це називається entity drift: розбіжність між реальним станом сутності й тим, як машинні системи її «бачать», що накопичується мовчки і не має алерту. Червнева чистка 2025-го випукло продемонструвала, як це працює в гіршому випадку. Один з найбільш агресивних зрізів був по категорії «event»: -76,91%. Це переважно артефакти пандемії (онлайн-конференції 2020–2021, скасовані івенти, тимчасові ініціативи), які формально існували у графі, але роками не редагувалися й не отримували нових сигналів життя. Машина сказала: «це або вже неактуально, або не було реальним → видалити». Та сама логіка вдарила в thing-сутності (-15,27%): загальне відро для всього, що Google не зумів класифікувати точніше. Сигнал ясний: stale = candidate for cleanup.

Перенесемо це на компанію. Якщо ти запустив бренд у 2019-му, набрав ранніх згадок у пресі, потім стартанув, виріс, поміняв CEO, додав три продукти, вийшов на новий ринок — а Wikidata Q-item у тебе залишився з трьома statements 2019 року, без apply нового CEO, без додавання нових продуктів, без жодного edit'у за останні 18 місяців, — для машини твій вузол виглядає не «активною компанією», а «компанією, яка існувала у 2019 і, можливо, померла». При наступній чистці, якщо ще буде проводитись агресивне об'єднання дублів і відсікання слабких сигналів, твій вузол може опинитись у списку кандидатів на «merge under more active competitor» або просто «remove as low-confidence entity». І ти не дізнаєшся про це наперед.

Freshness — це не «постити в Wikidata щомісяця». Це регулярний цикл синхронізації: коли в реальному світі змінюється атрибут (CEO, штаб-квартира, продуктова лінійка, ключове партнерство, фінансовий раунд) — він має дзеркало у графі протягом розумного вікна (тижня — місяця). Не для естетики. Для того, щоб машина бачила вузол як операційний, а не як архівний.

VIII. Вісь 5: Panel-Trigger — невидимий бар, який треба перетнути

Тут починається найбільш контрверсійна територія. Google офіційно ніколи не публікував порогу появи Knowledge Panel. Це чорна скринька. Але практики, які роками працюють у entity-SEO (Jason Barnard / Kalicube, instantpress.co, theStacc), емпірично виводять рецепт, що з високою повторюваністю спрацьовує:

| Сигнал | Емпіричне мінімальне значення |
| --- | --- |
| Wikipedia entry | Бажано, не критично; різко підвищує ймовірність |
| Wikidata Q-item з 15+ statements і джерелами | Майже обов'язково |
| Schema.org Organization-розмітка з sameAs-array | Обов'язково на офсайті |
| Незалежні статті на high-authority доменах (DA 80+) | ~7+ за стійкий поріг |
| Крос-платформенні соц-профілі з консистентними фактами | LinkedIn, Crunchbase, X, GitHub-org мінімум |
| Час від першої згадки до появи панелі | Типове вікно 6–12 місяців |

Це emergent threshold, виведений практиками з тисяч кейсів, не публічний Google-стандарт. Малий локальний бізнес з трьома згадками панель не отримує практично ніколи (попри коректну схему). Mid-size з 30+ незалежними згадками + Wikipedia + чистою розміткою зазвичай отримує — у вікні 6–12 місяців після того, як останній з потрібних сигналів став на місце. Інколи це 4 місяці, інколи 14, але паттерн стабільний.

Panel — це не «бейджик у пошуку». Це сертифікат, що машина впевнена в тобі понад поріг F1-score. Без панелі AI має юридично-нейтральне право скіпати тебе, бо не може довести, що ти — це ти, з достатньою впевненістю. З панеллю — машина має офіційне підтвердження від найбільшого графа на планеті, що твоя сутність визнана, унікальна й верифікована. Це не SEO-косметика. Це структурний прохідний бал у ринок 2026 року.

Counter-pressure до цієї осі — і найбільша спокуса, з якої починається половина катастроф у цій сфері: «а якщо я просто заплачу комусь, хто намалює мені Wikipedia-сторінку за тиждень, і Q-item за два — і так і вийду на поріг?» Це не план. Це міна. Чому — у наступному розділі.

IX. Counter-pressure: «просто куплю Wikipedia за $300/міс» — і чому це backfires

Це найжорсткіший контраргумент, який треба чесно пройти. Якщо все, що нам треба — це Wikipedia + Wikidata + 7 статей на DA 80+, то на ринку повно агенцій, які обіцяють зробити це за один retainer. У Fiverr і Upwork в категорії «Wikipedia article creation» — тисячі пропозицій по $200–$2000. Розіслати прес-релізи через PR-сервіси — ще тисяча на місяць. Зібрати JSON-LD з шаблону — година роботи. Чому б це не спрацювало?

Тому що Wikidata і Wikipedia — це не corporate listing-сервіси. Це спільноти волонтерів-редакторів з консервативними правилами щодо notability, neutrality (NPOV), conflict of interest і paid editing. Особливо Wikipedia після 2014 року веде явну й кодифіковану війну з оплачуваним редагуванням: політика Wikipedia:Conflict of interest вимагає обов'язкового публічного розкриття будь-якого paid editing, плюс Wikimedia Terms of Use окремо роз'яснюють, що paid contributions без disclosure порушують ToU. Wikipedia:Notability (organizations and companies) встановлює досить високий бар: "significant coverage in multiple independent reliable secondary sources" — і реклама/прес-релізи/sponsored content явно виключені як неприйнятні джерела. Спроби обійти ці правила відстежуються давно — і не лише на рівні окремих сторінок. Wikipedia ввела окремий критерій швидкого видалення G11 (unambiguous advertising), який дозволяє адмінам зносити статтю без обговорення, якщо вона виглядає як рекламний матеріал; CSD G11 застосовується тисячі разів на місяць.

Що буде з компанією, яка зайде в цю гру через найдешевший вхід:

Шлях 1: paid editor без disclosure. Стаття створюється, тримається тиждень-два, потрапляє на патрульний радар, тегується як COI/paid editing/advertising, видаляється; редактор-замовник банить акаунт. Часто з паралельним розслідуванням, чи це частина sockpuppet-мережі (виявлення яких — окрема дисципліна). У важких випадках компанія потрапляє у явний blacklist через WP:COIN (Conflict of interest noticeboard), що означає: будь-яка майбутня спроба створити сторінку буде відхилена з відсилкою до історії порушень. Це — репутаційний минус назавжди на платформі, яка є кореневим джерелом для всіх інших графів.

Шлях 2: накручені «згадки» на тіньових медіа. PR-агенція розміщує 30 «статей» на сітці сайтів, які приймають все, що приходить з оплатою. Google це бачить миттєво — давно існують класифікатори low-quality / press-release-mill / link-farm доменів, які системно знижують вагу або взагалі виключають домени з ranking-сигналів. Більше того, у червневій чистці 2025-го одним з заявлених фокусів був саме «anti-hoarding» — видалення сутностей із слабкими або підозрілими сигналами. Тобто накручення не просто не дає панелі; воно активно підвищує ризик потрапляння у наступну хвилю видалень.

Шлях 3: NPOV-порушення з самого початку. Стаття створена у формулюваннях типу «AcmeCo is a leading provider of innovative solutions» — це miss notability bar з першого читання. Tagged for deletion, AfD-голосування, видалення. Часто разом із Wikidata Q-item, який автоматично закривається як «article about non-notable entity».

Що насправді працює — і це нудно: спочатку чистий primary source. Твій офіційний сайт із бездоганною schema.org Organization-розміткою (включаючи sameAs-array, founder, foundingDate, legalName, numberOfEmployees, address, contactPoint, ідентифікатори в Crunchbase / LinkedIn / X / GitHub). Далі — природне earned media: справжні цікаві історії, які роблять журналістам життя простішим, а не складнішим. Далі — час: 6–18 місяців, у які незалежні редактори Wikipedia / Wikidata мають можливість самі підхопити сутність на основі сторонніх джерел. Далі — легке guidance через Talk-сторінки з повним disclosure, якщо ти бачиш фактичні помилки у вже існуючій сторінці. Це не швидко. Це не агенційно. Це не $300/міс. Це довгий шлях, який не масштабується по людях, бо вимагає реального бренду, що генерує реальні згадки.

І перш ніж узагалі заходити в цю гру, чесніше почати з холодної відповіді на питання «а я взагалі проходжу notability-бар?». Це окремий аудит notability для Wikipedia, який партнер цього тексту, Wikibusines, робить до того, як ти витратиш квартал і бюджет на сторінку, що її адмін знесе за G11 — а заразом скаже, чи твій кейс узагалі проходить, чи спершу треба напрацювати джерела.

У 2026-му видимість на ринку — це не сайт і не SEO. Це machine-readable вузол у графі. Усе інше — лист у пляшці, який ти кинув в океан і сподіваєшся, що його хтось знайде.

X. Розподіл ризику: хто найбільш голий, а хто — резистентний

Розподіл ризику не однаковий — і це найголовніша операційна частина для будь-кого, хто читає цей текст. Деякі категорії компаній і людей сидять у графі майже непробивно. Деякі — голі.

Найбільш голі (Entity-fragile):

D2C-бренди з родовими назвами. Компанія з назвою «Coastal», «Bloom», «Forge», «Reform», «Method» приречена на омонімну плутанину. У Wikidata вже є десятки Q-items з такими label'ами. Якщо ти ще й нечітко відрізняєшся за описом, при першій же спробі реконсиляції машина тебе або зливає з кимось чужим, або взагалі залишає поза сіткою. У 2026-му випустити D2C-бренд з родовою назвою — це operational malpractice: ти оплатив маркетинг, який упреться в entity-стелю.
Single-founder-консультанти й agencies-of-one. Якщо ти і твоя компанія — це одна сутність із непрозорою межею (особистий бренд + LLC + проєктний сайт), для машини це класична плутанина «people vs organization». Одна з найбільш дорогих помилок — однакова назва людини і компанії без явного sameAs / founder of контуру, тобто Google вирішує сам, кого зробити канонічним, і зазвичай не на твою користь.
Стартапи, що змінили назву після раунду. Класична схема: підняли посівний на одному імені, ребрендингували на серії A. Якщо replaces / replaced by properties у Wikidata не проставлені, у наступну чистку «попередня» сутність часто залишається як «активна» (бо в неї є більше згадок), а нова — як низько-довірча. Це особливо боляче у YC-cohort'ах, де ребрендинги часті.
B2B-вертикалі без свого Wikipedia-coverage. Якщо у твоїй ніші немає журналіста-ентузіаста, який пише про неї регулярно у Wikipedia (а в нішових B2B такого, як правило, нема), то навіть бездоганна твоя кампанія не отримує природного entity-pickup'у. Доводиться будувати все вручну, через primary source + чисту PR-роботу.

Найбільш резистентні (Entity-resilient):

Іменовані особистості з академічними цитаціями. Якщо ти — людина, у якої є ORCID, Google Scholar profile з кількома цитаціями, h-index хоч би 5, авторство в peer-reviewed журналах, твоя сутність-персона у графі майже непробивна. Академічні бази (Crossref, OpenAlex, Semantic Scholar) забезпечують структуровані machine-readable сигнали, які Google проковтує і прив'язує до твого Q-item автоматично. Це найдешевший «entity hedge», що існує — і його випадково створили десятки тисяч науковців, які про це не думали.
Бренди з PR-історією до 2020-го. Якщо твоя компанія була на TechCrunch у 2014-му, Forbes у 2016-му, Bloomberg у 2018-му, у тебе вже накопичено десятки «старих» high-quality згадок, які машина читає як baseline trust. Це не панацея — їх треба підтримувати, — але стартова позиція принципово вища.
Видимі публічні компанії з тікером на біржі. Структуровані фінансові ідентифікатори (CIK, ISIN, тікер, EDGAR-філінги) — це найсильніший entity-anchor, що можна мати. Машина не сумнівається, що Apple Inc. — це Apple Inc., тому що SEC цю сутність явно прив'язала до унікальних кодів.
Бренди з географічним або нумерованим розрізненням. «Bloom of Brooklyn», «Forge Industries Cleveland», «Method 47» — навіть якщо родовий складник заплутаний, додатковий disambiguating token (місто, номер, домейн-категорія) різко знижує omonym-risk.

Висновок розділу простий: візьми список вище і чесно подивись, у якій колонці ти. Якщо ти у першій — твій ESI з високою ймовірністю провалюється на 2–3 осях одночасно, і твій 90-day playbook починається з reconciliation, а не з content. Якщо ти у другій — твоя задача не «починати з нуля», а захищати наявний капітал від випадкових ребрендингів і ентропії.

XI. JSON-тиша: як виглядає смерть без скандалу

Червень 2025-го. Понад 3 мільярди сутностей деіндексовано за тиждень. Серед них — компанії, які не порушували нічого. Просто Google за внутрішніми metrics перестав бути впевненим, що вони — окремі реальні entity. Що бачив фаундер однієї з таких компаній?

Спочатку — анормальний просід AI-share. Якщо раніше з 100 запитів за категорією AI Overview згадував бренд у 12 — то починаючи з третього тижня червня цифра спала до 4. Інструменти на кшталт Profound, Otterly, Goodie дозволяють це бачити в реальному часі, але треба було їх мати підключеними; більшість не мала.

Далі — місяць затишшя, бо більшість inbound-каналів інерційні: ремаркетинг, прямі переходи з старих публікацій, листи. Потім — поступове сповзання: cold-lead'ів стає менше, CTR на бренд-запити падає на 8–14%, частка демо-запитів з опитувальною графою «де ви про нас почули?» зміщується до «знайомий рекомендував» від «ChatGPT / Perplexity». Один з ключових B2B-deal'ів зривається тому, що procurement-команда зробила vendor-check у ChatGPT, отримала «no reliable information» і обрала більш прозоро описаного конкурента.

Через три місяці фінансовий директор приходить на квартальну нараду з графіком: pipeline -19% YoY, inbound -27%, cost-per-acquired-lead +34%. Маркетинг шукає причину в SEO; SEO нормальне. Шукає в content; content нормальний. Шукає в performance; performance стабільний. І ніхто не дивиться в entity layer, бо там нема dashboard'у. Через шість місяців пишеться «death certificate»: ось ця компанія в графі вже не вузол, а footnote у статтях, де її згадують у тіні конкурента, який зайняв її сторінку результатів.

| Brand X (death certificate) | Значення |
| --- | --- |
| Status | Deindexed from KG (June 2025 cleanup wave 2) |
| Cause | Insufficient cross-source confidence |
| Notice given | 0 |
| Detected | +12 weeks (via AI citation drop) |
| Symptoms before | Inbound -27%, lost 2 procurement deals, CPL +34% |
| Recovery window | 6–14 months (rebuild from scratch) |
| Avoidable | Yes, with quarterly ESI audit |

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

XII. 60-хвилинний DIY-аудит Entity Survival Index

Без агенцій, без $5k retainer'ів, без «спочатку треба провести місячний strategic discovery». Сім кроків, один таймер на 60 хвилин, чесна оцінка. Це не повний аудит — це тест на життєздатність, який має зробити кожен фаундер або CMO раз на квартал. Як вимірювання пульсу: занадто просто, щоб не робити, і занадто важливо, щоб робити раз на рік.

| # | Крок | Як перевірити | Time | Pass/Fail |
| --- | --- | --- | --- | --- |
| 1 | Presence: Q-ID існує? | wikidata.org → search → твоя компанія → є Q123…? | 5 хв | _ |
| 2 | Consistency: name / founder / foundingDate / category однакові на 5 джерелах? | Звір official site / LinkedIn / Crunchbase / Wikipedia / Wikidata | 15 хв | |
| 3 | Reconciliation: Organization JSON-LD з sameAs-array валідний? | search.google.com/test/rich-results → твій URL → перевір schema + sameAs | 10 хв | |
| 4 | Panel: branded search показує Knowledge Panel? | google.com → твоя точна назва → справа панель є чи нема? | 2 хв | |
| 5 | AI citation: ChatGPT відповідає конкретно чи hedge? | chat.openai.com → «who is [твоя компанія]» і «who is [founder name]» | 5 хв | |
| 6 | AI citation #2: Perplexity цитує твій домен? | perplexity.ai → запит за твоєю категорією → є твій домен у цитаціях? | 5 хв | _ |
| 7 | Freshness: дата останнього edit'у на Wikipedia / Wikidata / LinkedIn 
 Граф не лояльний, не злий, не упереджений. Він холодний. Йому потрібен консистентний сигнал. Якщо в тебе його нема — він обере того, у кого є. Без жалю. Без алерту. Без рахунку на пошту.

 Джерела & контекст
 
 «Google Knowledge Graph: >1,6 трлн фактів про 54 млрд сутностей (травень 2024)» — Wikipedia summary on Google Knowledge Graph; Search Engine Land's 2024 E-E-A-T cleanup unpack; Jason Barnard аналіз KG volatility (вторинні джерела, base figures з Google blog statements 2020 і 2024) — Wikipedia: Knowledge Graph (Google); Search Engine Land.
 «Червень 2025: −6,26%, >3 млрд сутностей видалено за тиждень» — Search Engine Land «Google's great clarity cleanup» (single primary analyst source, дві хвилі 13 і 20 червня, follow-up 11 серпня; категорія «event» −76,91%, «thing» ≈ −15,27%; person-entity unification 70,16% → 76,78% «unityped») — Search Engine Land.
 «Wikidata: 120,9 млн Q-items, 1,65 млрд statements, 13,5K P-properties (2025)» — Wikidata:Statistics; Wikidata:List of properties; snapshot редагується щохвилини, тому числа — порядок, а не котирування дня; кумулятивно ~2,476 млрд edits, ~41 987 активних редакторів — Wikidata:Statistics.
 «Knowledge Panel trigger threshold (емпіричний рецепт практиків)» — instantpress.co, theStacc, Kalicube (Jason Barnard): Wikipedia entry + Wikidata + schema.org Organization markup + ~7+ статей на high-authority доменах + крос-платформенні соц-профілі з консистентними фактами; типове вікно появи 6–12 міс; це emergent threshold, не публічна Google-планка — Kalicube; instantpress.co.
 «AI-citation logic: anti-hallucination, не маркетинг-фільтр» — semai.ai «Why Your Brand Gets Cited in Perplexity But Not ChatGPT»; Discovered Labs «AI Citation Patterns»; aruntastic «The sameAs Property». Sources з сильними sameAs-зв'язками отримують орієнтовно у 2–3 рази вищу вагу — це порядок, не точне число — semai.ai.
 «Schema.org / JSON-LD adoption (2024)» — agregated reports from amraandelma «Top Schema Markup Statistics 2025», WP Newsify «JSON-LD at Scale 2025», W3C structured data adoption tracking. Із ~362,3 млн зареєстрованих доменів лише ~12,4% (~45 млн) використовують будь-яку structured data; >87% сайтів у топ-3 органіки користуються JSON-LD коректно; CTR-lift до 20–30% для structured pages — amraandelma.
 «Реальний кейс: Kelly Sheppard втратила Knowledge Panel» — structureddata.co.uk «How I Lost My Knowledge Panel». Залишивши Sleeping Giant Media, втратила claimed-панель: Google розцінив як двоє різних людей, panel замінено placeholder'ом, відновлення — місяці через kgmids у structured data + циркулярні sameAs Wikipedia / Wikidata / LinkedIn + unlinked mentions — structureddata.co.uk.
 «Wikipedia notability and paid editing policy» — Wikipedia:Notability (organizations and companies) requires significant coverage in multiple independent reliable secondary sources, excludes press releases / sponsored content; Wikipedia:Conflict of interest вимагає disclosure paid editing; Wikimedia Terms of Use окремо роз'яснюють обов'язкове розкриття. CSD G11 (unambiguous advertising) дозволяє швидке видалення без обговорення — WP:NORG; WP:COI; Wikimedia ToU.
 «Reddit threads on lost Knowledge Panels» — r/SEO, r/bigseo, r/TechSEO мають десятки тредів типу «my Knowledge Panel disappeared after rebrand», «Google merged my entity with competitor», «entity bankruptcy after pivot» — ground-truth scenes (не статистика, а ілюстративні сценарії) — r/TechSEO.
 «Knowledge graph completion and entity reconciliation (academic)» — Hogan et al., «Knowledge Graphs» (ACM Computing Surveys, 2021); Bordes et al., «Translating Embeddings for Modeling Multi-relational Data» (NeurIPS 2013); Ji et al., «A Survey on Knowledge Graphs: Representation, Acquisition, and Applications» (IEEE TNNLS 2022) — academic baseline для розуміння, як працює entity reconciliation і named-entity recognition у LLM — Hogan et al. 2021.
 NeuroDrift trust-серія (related reading):
 «Praegustator Principle» — Wikipedia як свідок достовірності для AI;
 «Death by Summary» — як AI summarization layer переписує бренди коротко й несприятливо.
 Цей пост — третій у трикутнику: існування → переказ → довіра. Усі три діагнози читаються разом.