Entity resolution: как я разводил сущность эксперта с однофамильцами в графе Google

Проблема была не в том, что поиск меня не знает. Проблема была в том, что имя «Станислав Кириченко» знают сразу несколько систем — и каждая понимает под ним разного человека.

Это кейс про entity resolution, разрешение сущности. Не про то, как «создать себя» в графе знаний, а про то, как отделить свою идентичность от чужих, которые уже под этим именем существуют. Я вёл эту работу на живом сайте, замерял её приборами и записывал не только то, что сработало, но и то, что нет. Ниже весь путь, с датами, запросами и честным разделением того, что я сделал, что реально увидел прибор и что из этого имею право заключить.

Пять Станиславов Кириченко

У неоднозначности имени две формы, и обе я наблюдал не в теории, а в конкретных ответах конкретных систем.

Форма первая, потенциальная неоднозначность. Google Knowledge Graph Search API, официальный интерфейс к графу знаний Google, по запросу «Stanislav Kirichenko» возвращает несколько узлов типа Person. Я снял этот замер 20 августа 2026 года.

ФАКТ. На 13 августа тех же узлов было четыре, на 20 августа стало пять, добавился /g/11zds4kh63. Напрашивается гипотеза, что пятый узел породил мой же элемент Wikidata, созданный как раз 13 августа. Я её проверил, и она не подтверждается тремя признаками. У элемента Wikidata нет свойства P2671 — идентификатора Google Knowledge Graph, то есть структурной связи с графом он не объявляет. У элемента ноль сайтлинков, статьи в Википедии нет, а без неё граф редко собирает описанный узел. И сам пятый узел, как остальные четыре, машинного типа /g/ и пустой. Подтяни граф мой элемент, я ждал бы узел с описанием «SEO specialist», а вижу ещё один безымянный.

НЕ ДОКАЗАНО. Прямой причиной Wikidata, скорее всего, не стала. Косвенную исключить не могу: пустой узел /g/ граф заводит, встретив имя как персону в новом веб-контенте, и таким контентом за неделю могли оказаться мои же свежие профили и ссылки, ещё не сведённые к основному узлу. Происхождение узел не раскрывает, доказать нельзя ни ту версию, ни другую.

Побочно вскрылось важное. За 92 дня мой элемент Wikidata так и не консолидировался в описанный узел графа — все пять остаются пустыми. Работа сделана, а Google её ещё не свёл. Без натяжки остаётся одно: пока идентичность не собрана, число претендентов на имя само по себе не падает.

ФАКТ. По состоянию на 20 августа Knowledge Graph Search API возвращает пять пустых узлов Person «Stanislav Kirichenko», все с resultScore 24. Чего этот замер не доказывает: он не измеряет наличие или отсутствие Knowledge Panel — блока о персоне в правой части выдачи Google. Панель — отдельный сигнал, и его этим API не проверить.

Форма вторая, реальная ошибка разрешения сущности. Это уже не «потенциально». Система прямо связала моё имя с чужим человеком. В научной базе OpenAlex под профилем, привязанным к моему ORCID, на 13 августа висела чужая работа — диссертация по истории 2021 года, к SEO отношения не имеющая. Я её не писал. Машина решила, что она моя, потому что имя совпало, а различающих признаков не хватило.

Вот это и есть самая наглядная демонстрация проблемы: конкретная чужая диссертация, приписанная мне научным агрегатором. Ровно то, что entity resolution должен предотвращать, и что абстрактные пустые узлы показывают куда бледнее.

Оговорю границу кейса сразу. Это история про персону-эксперта. Для товарного бренда или компании набор шагов похож, но веса другие, потому что основная сущность там Organization, а не Person, и часть идентификаторов вроде ORCID неприменима. К этому вернусь в конце.

Что я хотел проверить

Гипотеза формулировалась не как «попасть в Knowledge Graph». Панель в выдаче — следствие, на которое я напрямую повлиять не могу. Управляемая задача другая. Повысить однозначность машиночитаемой идентичности, то есть сделать так, чтобы системам было проще связать разрозненные сигналы в одну персону и труднее спутать её с тёзками.

Критерии успеха я задал до того, как появились результаты, иначе любой исход можно объявить победой задним числом. Уровней три.

Дальше по тексту я держусь этой шкалы: каждый результат отношу к своему уровню и не выдаю минимальный успех за сильный сигнал.

Исходная точка

Сайт sk-seo.ru работает с марта 2026 года. Базовый гайд по entity-профилю я опубликовал 20 мая и от этой даты считаю окно наблюдения. К 13 августа, когда я снял первый развёрнутый замер идентичности, картина была такой. Knowledge Panel по имени не находилась ни в одном написании, элемента Wikidata не существовало, а OpenAlex связывал имя с чужой диссертацией.

То есть на старте машиночитаемая идентичность либо отсутствовала, либо была ошибочной. Это и есть точка отсчёта, против которой читаются все дальнейшие изменения.

Что изменилось за 92 дня

Сначала результат, потом механика. Ниже таблица за окно с 20 мая по 20 августа. Одна важная оговорка про даты. 92 дня — это возраст базового гайда, от которого я считаю всё окно. А развёрнутый замер «было» я снял только 13 августа, поэтому в колонке «Было» стоит именно эта дата, и измеренная дельта «было и стало» покрывает не 92 дня, а неделю между 13 и 20 августа. Всё, что происходило раньше, я в цифрах не фиксировал и за рост не выдаю.

Я развёл в таблице два принципиально разных типа строк. Артефакт — то, что создал я сам. Внешний сигнал — то, как отреагировали системы вне моего контроля. Это разделение и есть нерв всего кейса, потому что за первое я отвечаю, а второе только наблюдаю.

Пара строк намеренно оставлена в статусе «не измерялся» — там, где нулевого замера на старте я не делал. Выдавать отсутствие baseline за «было ноль» — значит рисовать рост, которого не проверял. Где baseline есть, он назван с датой.

Теперь — что было сделано между этими двумя точками, почему именно так и что при этом ломалось.

Как я уменьшал неоднозначность

Работа шла слоями, снизу вверх. Сначала собственный сайт как точка правды, потом внешние точки сверки, потом связывание всего этого в один узел. Каждый слой разбираю по одной схеме, а именно проблема, что сделал, почему так, что могло пойти не так, чем проверил.

Слой 1. Сайт как Entity Home

Проблема. Сайт заявляет, кто я, но для машины он остаётся self-asserted source, то есть источником, который сам о себе свидетельствует. Доверия к нему меньше, чем к внешнему подтверждению, зато именно он задаёт опорную версию фактов.

Что сделал. На страницах / и /about.html развернул полную разметку Person со свойствами birthDate, birthPlace, homeLocation, единым @id и массивом sameAs из четырнадцати внешних профилей.

Почему именно так. Дата и место рождения работают не на тщеславие, а на дисамбигуацию. Против пяти однофамильцев нужны признаки, которых у них нет и которые их разведут. Владелец сознательно пошёл на публикацию даты рождения (2 мая 1986) и места (Сумы) именно с этой целью, чтобы дать машине различающий атрибут. Единый @id нужен, чтобы разметка на разных страницах ссылалась на один узел, а не плодила новые.

Что могло пойти не так. Межстраничный @id не «склеивается» автоматически. Если сущность полно описана только на двух страницах, а на остальных стоит короткая ссылка-референс, легко получить пустые узлы. Поэтому полное описание Person живёт ровно на двух страницах, а дальше идёт только референс с именем и url.

Чем проверил. Собственным валидатором разметки по всем 44 страницам сайта, ноль ошибок. Это артефакт. Я отвечаю за то, что разметка корректна, но не за то, как её прочитает Google.

Слой 2. Идентификаторы вне собственного домена

Проблема. Сайт свидетельствует сам о себе. Нужны точки сверки за его пределами, в системах, которые я не контролирую целиком.

Что сделал. Завёл ORCID 0009-0001-2914-9541, препринт с DOI на Zenodo, профиль about.me и элемент Wikidata. Все они попадают в sameAs и связываются с сайтом обратными ссылками.

Про степень независимости честно. «Внешний» не значит «независимый». ORCID и about.me я веду сам, депозит на Zenodo тоже создаёт автор, так что это self-managed записи, просто на чужой площадке. Wikidata ближе к независимости, её модерирует сообщество и элемент без оснований удалят, но и она не «подтверждает факт» автоматически. Ценность этих точек не в том, что кто-то верифицировал факты, а в том, что они дают графу перекрёстные ссылки на один узел из разных мест.

Чем проверил. Живыми URL и валидностью каждой записи. Про то, что здесь ломалось, идёт отдельный раздел ниже, потому что ломалось много.

Слой 3. Контентный узел

Проблема. Идентичность без содержания остаётся пустым паспортом. Нужен контент, который привязывает имя к нише «entity SEO и AI-видимость», а не просто к строке «SEO-специалист».

Что сделал. Базовый гайд по entity-профилю стал узлом тематического кокона, и недавно я досшил внутренние связи между статьями об AI-видимости. Ссылка на гайд идёт по закреплённому смыслу, «профиль бренда». Тема «как строить» остаётся за ним, а этот кейс отвечает на другой вопрос, «что вышло на живом сайте».

Что пришлось переделывать

Самый честный раздел кейса. Внешние системы описывали меня не так, как я ожидал, — и каждую ошибку пришлось ловить руками. Четыре случая, каждый по схеме «ожидал → получил → почему это проблема → исправление → статус».

Что показали измерения

Теперь — внешние сигналы, то есть реакция систем. Здесь я особенно строго держу разделение факта, сигнала и недоказуемого, потому что именно тут проще всего соврать себе.

Цитирование в Быстром ответе Алисы

Методика. Я взял десять запросов из своего же AI-пласта, тех, по которым Яндекс уже давал сайту клики, и прогнал их через поиск ya.ru в браузере с обходом антибота. Для каждого фиксировал, есть ли блок «Быстрый ответ Алисы» и попадает ли sk-seo.ru в источники именно этого блока, а не в обычную выдачу ниже. Блок определял по структуре страницы, чтобы не спутать с органикой.

ФАКТ. 20 августа sk-seo.ru присутствовал среди источников Быстрого ответа Алисы по 2 из 4 успешно проверенных запросов. Первый — «оптимизация сайта под llm», где источником шёл мой разбор по LLM в B2B. Второй — «entity seo для ai» с гайдом по entity-профилю. Про знаменатель важно оговориться. Из десяти запросов шесть я снять не смог, капча заблокировала сессию. Так что «2 из 4» означает два из четырёх фактически проверенных, а не из десяти.

СИГНАЛ. На замере за это окно entity-запросы дают заметный трафик. По маске, заданной до просмотра кликов (entity | entities | сущност | knowledge graph), пул собрал 7 кликов на 65 показах за месяц — на шести запросах, то есть больше клика на запрос. Это высокая плотность для сайта, где у большинства тематических групп клик приходится на десятки показов. Сразу оговорюсь про масштаб: семь кликов — крохотная выборка, и любое «место в рейтинге пулов» на ней неустойчиво, поэтому я не называю entity «первым пулом сайта» — это было бы натяжкой. Достаточно факта: направление внимания в эту тему у сайта есть, и оно измеримо.

ФАКТ. По запросу «entity seo для ai» на живом снимке 20 августа сайт стоял на 3-й позиции в Яндексе, при средней за месяц 6,6. Выше держались trigub.ru и pr-cy.ru, ниже стоял isakov.work на 8-й. Это редкая выдача, где вообще ранжируются личные сайты экспертов, а не только агрегаторы.

НЕ ДОКАЗАНО. Нельзя утверждать, что цитирование Алисой вызвано Wikidata, схемой или каким-то конкретным изменением. Я внёс несколько изменений одновременно, контрольной группы нет, а за 92 дня менялись и другие вещи. Совпадение по времени причинностью не является.

Отдельно назову слепое пятно. Весь entity-пул виден только в Яндексе. Google Search Console за тот же период не отдала ни одного entity-запроса. Так что «сигнал» здесь относится к одной поисковой системе, а не к поиску вообще.

Ограничения эксперимента

Это раздел про методологию, а не про провалы — их я вынесу отдельно. Здесь то, что мешает делать из наблюдений сильные выводы, даже когда наблюдения положительные.

Последний пункт — главный аргумент против соблазна написать «сделал Wikidata → получил третью позицию». Возраст и накопленный контент объясняют часть роста и без всякой сущности.

Отрицательные результаты

А это уже не ограничения метода, а наблюдаемые факты того, что на 20 августа ещё не сошлось. Разница принципиальная: выше было «не могу доказать», здесь «проверил, пока не сложилось».

Ни один из этих пунктов я не заклеиваю формулировкой «зато». Сильного сигнала из моей же шкалы — панели в графе — я пока не достиг, и это честная часть результата. Но слово «пока» здесь несёт вес: консолидация сущности в графе идёт неделями и месяцами, а замер снят на 92-й день. Отсутствие панели на этой отметке говорит о скорости Google, а не о том, что работа сделана зря.

Что бы я делал сейчас с нуля

Дальше — не универсальный рецепт, а порядок, который сложился в моём случае. Специально не оформляю его как «сделай раз-два-три и получишь панель»: панели я как раз не получил.

Последовательность была такой: сначала Entity Home на своём сайте с полной и непротиворечивой Person-разметкой; затем внешние точки сверки — те, что уместны конкретному человеку; затем связывание их в sameAs; и только потом — измерение, повторяемое во времени. Wikidata в этой цепочке стоит поздно и с оговоркой.

И главное — что из этого вообще применимо не мне, а вам. Набор сигналов зависит от того, кто сущность: человек, эксперт без публикаций или компания.

Таблица не про «можно / нельзя», а про то, что уместно как основная сущность. Эксперт может одновременно вести и Person, и Organization своей практики через worksFor; компания — размечать Person для основателей и авторов. Взаимоисключения тут нет, есть вопрос, что у сущности главное.

Если свести весь кейс к одной мысли, она такая. Я могу доказать, что создал элемент Wikidata. Я могу доказать, что Алиса цитировала сайт. Я не могу доказать, что первое вызвало второе. И вот это разделение — между тем, что ты сделал, что увидел прибор и что имеешь право заключить, — по-моему, и отличает entity-работу от веры в микроразметку.

Частые вопросы

Что здесь на самом деле измерено

За 92 дня я сделал три вещи, каждую с приборами на руках. Развёл свою идентичность с чужой, убрав приписанную мне диссертацию из научного профиля — это была прямая ошибка разрешения сущности. Собрал из пустоты согласованную машиночитаемую личность: элемент Wikidata, ORCID, схема без противоречий, четырнадцать связанных профилей. И зафиксировал внешний отклик — на 20 августа как минимум одна AI-система цитирует сайт по моим темам. Сайту меньше года, так что это цитирование само по себе событие этого года, а не давний фон.

Панели в Google по имени пока нет. Но это не итог работы, а её медленная часть. Граф собирает сущность на своих часах: мой элемент Wikidata за 92 дня в описанный узел он ещё не свёл, и это состояние Google, а не дефект разметки. Консолидация идёт неделями и месяцами, а не за неделю замера. Единственное, чего я не приписываю себе: что цитирование дала именно entity-работа, а не тот факт, что статья вышла и её проиндексировали. По этим запросам до неё Алису я не замерял.

Честный итог такой. Набор entity-сигналов построен, отклик внешних систем измерен, а причинную связь между отдельным действием и этим откликом на одном сайте без контрольной группы установить нельзя — и я её не выдаю. Дальше идёт серия повторных замеров по тем же запросам. Если нужно так же разобрать сущность вашего бренда или сайта, это тема для SEO-консультации.