Entity SEO: как построить сущность в графе знаний

Коротко, если скроллить некогда: ИИ-движки цитируют не страницы под ключ, а сущности — вещи с именем и набором фактов, которые граф знаний умеет назвать. Стать такой вещью можно за четыре шага (одно имя везде, sameAs на Wikidata и Wikipedia, непротиворечивые факты, снятие неоднозначности), но подтверждается она снаружи, и это самая долгая часть.

Наткнулся на это, когда пробивал один небольшой бренд по ответам Perplexity: страницы у него были заметно сильнее конкурентов, а в ответах его не было вовсе, зато конкурент с посредственным текстом цитировался стабильно. Почему так? Полез смотреть, чем они отличаются, и разница оказалась не в тексте: у конкурента была запись в Wikidata и одно написание имени везде, а у моего героя — три варианта названия и ни одной внешней ссылки.

Строка против вещи

Разница тут простая, но с далеко идущими последствиями для всей работы: ключевое слово — это строка символов, а сущность — это вещь, у которой есть имя и набор фактов.

После сдвига Google 2012 года под индексом текста появился второй слой — граф сущностей, где у людей, компаний, продуктов и мест есть стабильный идентификатор и список свойств. Слой этот с тех пор только рос, а мы, кажется, до сих пор оптимизируем тексты так, будто его нет!

Когда человек или модель задаёт вопрос, первым делом происходит распознавание: запрос «лучший eSIM для Японии» раскладывается на сущность eSIM, место Япония и намерение, и только потом движок ищет источники, связанные с этими сущностями.

Страница под ключевое слово надеется совпасть со словами запроса, а сущность — это то, о чём запрос вообще идёт. В этом весь разрыв: триплеты строят факт, а кластер согласованных фактов об одном субъекте строит сущность, которую граф может назвать по имени.

Почему сущность выигрывает за цитирование

Ось	Ключевое слово	Сущность
Единица	строка символов	вещь с именем
Сопоставляется по	близости слов или векторов	распознаванию в узел графа
Неоднозначность	«apple» — фрукт или компания?	снимается идентификатором
Выигрыш	ссылка в выдаче	цитата внутри ответа
Устойчивость	колеблется с каждым обновлением	копится по мере подтверждений
Переносимость	выдача одного движка	любой движок, читающий граф

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

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

Как стать узлом

Четыре шага, и я расставил их по убыванию отдачи.

Одно имя везде

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

«Acme», «Acme Inc.» и «ACME Technologies» читаются как три слабо связанных кандидата, а не как одна сильная сущность, и именно согласованность обычно и позволяет графу свести упоминания в единый узел. Мой герой из завязки жил ровно с тремя вариантами!

Ссылки на хабы

Свойство sameAs — это способ сказать каждому движку: все эти аккаунты — это я. Направь разметку организации или человека на авторитетные хабы: Wikidata, Wikipedia при наличии статьи, LinkedIn, Crunchbase, GitHub, официальные профили в соцсетях.

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

"sameAs": [
  "https://www.wikidata.org/wiki/Q…",
  "https://en.wikipedia.org/wiki/…",
  "https://www.linkedin.com/company/…"
]

Факты, которые не спорят между собой

Граф доверяет фактам, которые согласуются сами с собой: год основания, основатели, адрес, категория и названия продуктов должны читаться одинаково на странице о компании, в разметке, в записи Wikidata и в профиле LinkedIn.

Что происходит при расхождении? Одно противоречие — скажем, другая дата основания в Crunchbase — и движок снижает доверие ко всем фактам сразу, а не только к спорному, что довольно жестоко, но логично. Выбери каноническое значение один раз и разнеси его по всем площадкам.

Устранение неоднозначности

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

Работают четыре вещи: точное описание, конкретный тип в разметке, факты про категорию и место, отдельная запись в Wikidata. Чем яснее различающие факты, тем меньше шанс, что запрос уедет к другому «apple».

Что делает движок до первого слова ответа

Пройду по конвейеру, который выполняется прежде, чем ответ вообще начнёт писаться.

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

Следом идёт атрибуция: предпочтение источникам, которые можно назвать признанными сущностями, потому что именованный источник — более безопасная цитата, и только в конце составляется сам ответ.

Обрати внимание на то, где именно выпадает страница, сделанная только под ключ: она выпадает на распознавании. Если ничто не связывает её с именованным узлом, конкуренция идёт лишь по близости слов, и в момент, когда движок рассуждает о вещи, а не о словах, такой страницы для него нет — совсем нет!

Чек-лист

• Одно каноническое имя дословно на сайте, в разметке и в каждом профиле.
• Разметка организации или человека со ссылками на Wikidata, Wikipedia и LinkedIn.
• Запись в Wikidata существует и ссылается обратно на твой сайт.
• Год основания, основатели, адрес и категория идентичны везде, без противоречий.
• Точное описание и конкретный тип для устранения неоднозначности.
• Ключевые факты выражены чистыми связками субъект, предикат, объект.
• Внешние упоминания описывают тебя так же, как твоя собственная разметка.

Прогони проверку, чтобы увидеть, какие страницы граф уже распознаёт как именованную сущность, а какие читаются как безымянная строка.

Распознаётся как именованная сущность 100%

Совпадает только по ключевому слову 0%

источник: внутренние аудиты, 2026

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

Три частых вопроса

Работает ли это для маленькой компании? Работает, хотя и медленнее: у крупного бренда упоминания появляются сами, а маленькому их приходится добывать — выступления, публикации в отраслевых изданиях, участие в списках и рейтингах. Ничего волшебного тут нет, просто дольше.

Обязательна ли запись в Wikidata? Не обязательна, но она даёт больше всех прочих ссылок вместе взятых, потому что на неё смотрят остальные базы, и её стоит делать первой, как только появится хотя бы пара независимых упоминаний.

Что делать, если о компании пишут неверно? Править источник, а не только свою страницу, потому что пока в чужой базе висит старый адрес или другое имя, граф видит противоречие и снижает доверие ко всему набору фактов. Это скучная работа по переписке, и обойти её нечем (я пробовал — не обходится).

Сколько это занимает

Скажу честно про сроки, потому что тут любят обещать быстрый результат.

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

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

С чего начать прямо сейчас

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

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

Потом собери в одном файле пять фактов: имя, год, город, вид дела и главный продукт. Это и будет канон, к которому сводится всё остальное, и спорить с ним потом не придётся.

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

Коротко

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

Строится сущность через единое имя и ссылки на Wikidata, Wikipedia и LinkedIn, а каждый факт держится идентичным по всей сети, потому что одно противоречие снижает доверие ко всем остальным.

Главное отличие от позиций: сущность копится и переносится между движками, а место в выдаче обнуляется с каждым обновлением.

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

Источники

• Google, «Introducing the Knowledge Graph: things, not strings» (2012) — сдвиг от сопоставления строк к пониманию через сущности.
• Schema.org — sameAs — свойство, связывающее профили в одну сущность.
• Wikidata — открытый хаб сверки, на который ссылаются другие базы знаний.
• Google Knowledge Graph Search API — как сущности запрашиваются по машиночитаемому идентификатору.
• Aggarwal et al., «GEO», KDD ‘24 — arXiv:2311.09735: цитирование зависит от того, является ли источник узнаваемой и извлекаемой сущностью.