## 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)** — інструмент діагнозу, який оцінює шанси твого бренду пережити наступну машинну чистку. П'ять осей, кожна — окрема відмова, що може окремо тебе вбити: 1. **Presence** — чи присвоєно тобі Q-ID у Wikidata? Чи бачить тебе глобальна адресна книга як окрему сутність? 2. **Consistency** — чи 5+ незалежних авторитетних джерел називають однакові name / founder / category / foundingDate? Чи не виглядаєш ти як троє різних компаній на одну тінь? 3. **Reconciliation** — чи замикаються `sameAs`-зв'язки між Wikidata ↔ Wikipedia ↔ LinkedIn ↔ Crunchbase ↔ official site коректно й циркулярно? Чи бачить машина одну тебе, а не двох? 4. **Freshness** — чи був осмислений edit твого вузла за останні 12 місяців? Чи доглядає за тобою хоч хтось — нехай навіть алгоритмічно? 5. **Panel-Trigger** — чи перетнуто емпіричний поріг сигналів (Wikipedia entry + Wikidata Q-item + бездоганна schema.org-розмітка + приблизно 7+ статей на high-authority доменах + узгоджені соц-профілі), який практики (Kalicube, instantpress.co, theStacc) описують як необхідний для появи Knowledge Panel у SERP? Розклад далі — це по осі на розділ. Кожен — діагноз, конкретика і те, де саме найчастіше ламається. Жоден з цих п'яти параметрів не вилікує всі інші. Зате будь-який з них, провалений, окремо опускає тебе у вікно ризику в наступну чистку.  *Бирка-«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](https://www.wikibusines.net/wikidata-seo-knowledge-graph): створення й супровід 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` ведуть в обидва боки і що твердження не суперечать одне одному. Інакше через певний час машина вирішить це за тебе — і ти не сподобаєшся її рішенню. ## 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](https://www.wikibusines.net/wikipedia-notability-audit), який партнер цього тексту, 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 < 12 міс? | History tab кожного з трьох | 8 хв | ___ | **Скоринг:** 7/7 — ESI-A («Граф тебе любить — підтримуй freshness і не ламай»). 4–6/7 — ESI-B («Quarter-to-fix: реконсиляція + одна-дві свіжі сильні згадки виправлять»). 2–3/7 — ESI-C («Не банкрут, але близько; 90-day playbook обов'язково»). 0–1/7 — ESI-D («Entity bankruptcy de facto: ти існуєш для клієнтів, не існуєш для машини»). Це не сертифікація. Це швидке самообстеження, після якого або видихаєш і повертаєшся до роботи, або стає зрозуміло, що один із пріоритетів наступного кварталу буде entity-аудит з конкретним owner'ом.  *Бланк, який банк не пришле: сім чекбоксів проти твоєї сутності в графі. Жовта качечка на стетоскопі — той самий доглядач, який лишився після того, як усі агенції здали зміну.* ## XIII. 90-денний reconciliation playbook (якщо ESI-B чи нижче) Без агенцій. Без retainer'у. Один owner всередині команди (head of marketing / head of growth / head of brand) + 4–6 годин на тиждень + готовність комунікувати з юридичним відділом щодо публічних змін. Розбито по чотиритижневих спринтах. **Тиждень 1: Audit і фіксація стартової позиції.** Прохід по 7-крокового self-audit, фіксація скрін-шотами кожного провалу: AI Overview без твого бренду, ChatGPT-відповідь з «no reliable info», порожнє місце там, де мала б бути Knowledge Panel. Це baseline для measurement через 90 днів. **Тиждень 2: Primary source cleanup.** Перевір schema.org Organization-розмітку на офіційному сайті. Має включати: `name`, `legalName`, `url`, `logo`, `description`, `foundingDate`, `founder` (з under-objects), `address`, `contactPoint`, `numberOfEmployees`, `industry` і — критично — `sameAs`-array з посиланнями на LinkedIn-сторінку компанії, Crunchbase, X-акаунт, GitHub-org, Facebook-сторінку, Wikipedia (якщо є), Wikidata Q-item (якщо є). Це найважливіша одиниця роботи усього playbook'а: твій primary source повинен бути джерелом істини, з якого все інше реконсиліюється. **Тиждень 3–4: Mirror sync.** Прохід по всіх дзеркалах: LinkedIn (Founded, Industry, Specialties, Founder credits, About blurb), Crunchbase (Founded Date, Founders, Categories, Headquarters), GitHub-org (про-блок, посилання, founder accounts), X-bio. Вирівняти foundingDate (включно з місяцем і днем, якщо знаєш), назву (з повним legal suffix або без — обери одну форму і тримай), категорію (один консистентний primary tag), founder credits (повний список засновників з консистентним порядком), офіційну штаб-квартиру. Кожна зміна — з тим самим source-of-truth-сайтом як reference. **Тиждень 5–8: Wikidata Q-item.** Якщо Q-item не існує — створити (через wikidata.org → новий item, з відповідними statements і обов'язково з джерелами під кожне твердження). Якщо існує — доповнити: instance of (company / startup / corporation), inception (з джерелом), founder (з Q-ID для кожного), industry (з Q-ID), country, headquarters location, official website, all relevant external IDs (Crunchbase ID, LinkedIn ID, GitHub-org ID, X ID), social media followers (якщо релевантно). Усе строго NPOV: жодних маркетингових формулювань, жодних superlative'ів, жодних просувань. **Якщо ти співробітник компанії — обов'язково оголоси Conflict of Interest на user-page.** Без disclosure це шлях до бану. **Тиждень 9–12: Earned-media loop.** Запусти content-pattern, який природно генерує 3–5 високоякісних згадок: контрибуція до галузевих звітів (Gartner / Forrester / IDC коментарі), data-stories з власною оригінальною аналітикою, помітні product launches з PR-плейбуком, гостьові експертні матеріали у tier-1 виданнях твоєї ніші. Кожна така згадка — паливо для реконсиляції: коли журналіст пише «AcmeCo, заснована у 2019 двома фаундерами X та Y», цей semantic triple узгоджується з твоїм Q-item і primary source — і модель бачить це як ще один confirming signal. **День 90: Re-audit.** Той самий 7-кроковий self-audit. Очікувана метрика: ESI підіймається на ≥2 рівні (з C до A або з D до B). Knowledge Panel — у вікні появи 6–12 місяців, тобто може ще не з'явитись на день 90, але всі попередні умови виконані. AI-citation rate — починає рости від другого місяця, помітно — від третього. Це playbook не магічний. Це **дисципліна**, яка вимагає чотирьох годин на тиждень одного owner'а протягом кварталу — і вирішує проблему, яка інакше через два роки коштує тобі частку ринку. ## XIV. Hard kicker Ринок не оголосить твою смерть. Не буде заголовків «X закрилась», не буде LinkedIn-постів «дякуємо за роки роботи», не буде press release про banкrupсtсvo. Буде тиша — спершу в AI Overviews, потім в inbound'і, потім у воронці, потім у виручці. До моменту, коли стане боляче в P&L, у графа вже буде твоя версія, оптимізована для конкурентів, які про entity layer почали думати на два квартали раніше. Питання, яке має повисіти. У наступну чистку Knowledge Graph — а вона буде, бо для роботи AI Mode і Gemini корпоративні моделі потребують ще чистішої основи, — твою компанію залишать як сутність з п'ятьма консистентними дзеркалами або як третій варіант entity, який Google не зміг впевнено розпізнати? У 2026-му існувати на ринку — це **обслуговувати свій вузол у графі** так само свідомо, як кеш у банку, контракти у legal-папці і код у репозиторії. Граф не лояльний, не злий, не упереджений; він холодний. Йому потрібен консистентний сигнал. Якщо в тебе його нема, він обере того, у кого є — без жалю, без алерту, без рахунку на пошту. Ти просто одного ранку зрозумієш, що тебе більше не цитують. Quarter ago все було «ок».«Ринок не оголосить твою смерть. Не буде заголовків "X закрилась", не буде LinkedIn-постів "дякуємо за роки". Буде тиша — спершу в AI Overviews, потім в inbound'і, потім у воронці. До моменту, коли стане боляче, у графа вже буде твоя версія — оптимізована для конкурентів.»
Граф не лояльний, не злий, не упереджений. Він холодний. Йому потрібен консистентний сигнал. Якщо в тебе його нема — він обере того, у кого є. Без жалю. Без алерту. Без рахунку на пошту.