Entity-based keyword research: как собирать семантику не по словам, а по сущностям

Классический сбор семантического ядра выглядит привычно: парсим Wordstat или Key Collector, выгружаем тысячи фраз, кластеризуем по совпадению слов или по топу выдачи, распределяем по страницам. Этот подход работает уже двадцать лет, но за последнее десятилетие поиск изменился радикально — Google и Яндекс ранжируют не по совпадению слов, а по тому, насколько полно страница раскрывает тему через систему связанных сущностей.

Entity-based keyword research — это способ собирать семантику в логике поисковика: не «какие слова искать», а «какие сущности должны быть на странице, чтобы тема считалась раскрытой». В этой статье разберём, чем такой подход отличается от классического, как его выполнять руками и с помощью инструментов (InLinks, WordLift, Surfer SEO, MarketMuse, Google NLP API), и как встроить в реальный рабочий процесс.

Чем entity-based research отличается от классического

Классический сбор семантики отвечает на вопрос «по каким запросам люди ищут эту тему?». Результат — список фраз с частотностями, кластеризованный по семантической близости или по топу выдачи. Дальше под каждый кластер пишется страница с упором на вхождение ключей.

Entity-based research отвечает на другой вопрос — «какие сущности образуют эту тему, и как они связаны между собой?». Результат — карта сущностей с их типами, важностью и связями. Дальше страница пишется так, чтобы покрыть нужные сущности с правильной плотностью и связями.

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

Простой пример. Запрос «лучший CRM для малого бизнеса» в классическом подходе порождает кластер из 200 фраз: «топ CRM для малого бизнеса», «сравнение CRM 2026», «недорогая CRM» и так далее. В entity-based подходе главная сущность — концепт «CRM-система», а связанные сущности, которые обязательно должны быть на странице: AmoCRM, Bitrix24, HubSpot, Salesforce, воронка продаж, лиды, интеграция с телефонией, API, тарифные планы, малый бизнес как сегмент. Если на странице нет половины этих сущностей — она проиграет в выдаче конкурентам, у которых они есть, какие бы ключи в title ни стояли.

Логика подхода: что такое «тема, раскрытая через сущности»

Когда Google оценивает страницу, он не просто считает совпадения слов. Он строит модель ее содержания: какая главная сущность (и насколько она доминирует — это значимость сущности (entity salience), важность сущности на фоне остальных, какие связанные сущности упомянуты, как они соотносятся с уже известным графу знаний контекстом темы.

Эта модель сравнивается с моделями страниц в топе. Если у вас на странице про CRM нет упоминания AmoCRM, но он есть у всех в топе-10 — Google считает, что ваш материал неполный. Если у вас CRM упомянут один раз, а основная сущность страницы — на самом деле «малый бизнес» (что определяется по плотности и распределению упоминаний), то страница ранжируется по запросам про малый бизнес, а не про CRM.

Отсюда главная задача entity-based research — собрать референсный список сущностей для темы и обеспечить их корректное присутствие в контенте. Этот список собирается тремя путями: анализ топа конкурентов, анализ Knowledge Graph и связанных сущностей, анализ собственных данных через инструменты NER (Named Entity Recognition — распознавание именованных сущностей).

Шаг 1. Определение главной сущности темы

Перед тем как искать связанные сущности, нужно зафиксировать главную. Это звучит банально, но на практике 70% слабого SEO-контента страдает именно от размытой главной сущности.

Главная сущность — это объект, о котором страница в первую очередь. Не «тема» в широком смысле, а конкретная сущность с чётким идентификатором в Knowledge Graph или Wikidata. Если вы пишете про «контекстную рекламу», главная сущность — концепт Contextual advertising. Если про «Google Ads» — это уже другая сущность (Google Ads, Q1392478 в Wikidata), и страницы должны быть разными.

Проверка простая: введите название главной сущности в Google и посмотрите, появляется ли Knowledge Panel. Если да — у сущности есть однозначное представление в графе знаний, и вы строите контент вокруг неё. Если нет (например, для сложных концептов) — берите ближайшую релевантную сущность из Wikipedia/Wikidata.

Отдельный вопрос — entity ambiguity, или омонимия сущностей. Одно и то же слово может соответствовать нескольким разным сущностям в графе знаний, и без явного сигнала поисковик может выбрать не ту. «Apache» — это HTTP-сервер (Q11354), вертолёт AH-64, индейский народ и Apache Software Foundation одновременно. «Mercury» — это и планета, и химический элемент, и автомобильный бренд, и Фредди Меркьюри. «Java» — остров, язык программирования и сорт кофе. Если на странице не уточнить контекст, NER-движок и Google могут выбрать неправильную интерпретацию.

Способ снять неоднозначность — явная разметка главной сущности через Schema.org с привязкой к Wikidata. На уровне страницы используется конструкция about с указанием Q-идентификатора:

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

Дальше через Google NLP API можно проверить значимость уже написанного черновика: загружаете текст, получаете список сущностей с оценкой от 0 до 1. Главная сущность должна быть на первом месте с заметным отрывом — например, 0.45 при следующих 0.10–0.15. Если salience главной сущности 0.05 и она затерялась среди десяти других — текст не про то, о чём вы думали.

Шаг 2. Анализ конкурентов через extraction сущностей

Самый практичный способ собрать референсный список — извлечь сущности из топ-10 страниц по основному запросу.

Ручной процесс выглядит так. Введите главный запрос в Google и Яндекс, соберите URL топ-10 в каждом поисковике. Прогоните каждую страницу через инструмент извлечения сущностей. Сравните списки — сущности, которые встречаются у большинства конкурентов, обязательны для вашей страницы.

В качестве инструмента подойдёт Google Cloud Natural Language API. Это официальный сервис Google, использующий подход NER, концептуально близкий к тому, что применяется в поиске (тождество не подтверждено публично, но результаты на практике хорошо коррелируют с тем, как Google «видит» сущности). Бесплатный лимит — 5000 единиц в месяц, причем единица здесь не запрос, а unit размером 1000 символов: для длинной страницы один анализ может расходовать 5–10 единиц, и при работе над крупным проектом лимит выбирается быстрее, чем кажется. Интерфейс простой: вставляете текст или URL, получаете список entities с типом (PERSON, LOCATION, ORGANIZATION, EVENT, WORK_OF_ART, CONSUMER_GOOD, OTHER), оценкой salience и ссылкой на Wikipedia, если она есть.

Еще удобнее — TextRazor и Dandelion API. TextRazor возвращает не только сущности, но и их типы из DBpedia и Freebase, плюс показывает relevance score (показатель релевантности). Здесь нужна оговорка: Freebase официально закрыт в 2016 году и интегрирован в Wikidata, а DBpedia с тех пор обновляется нерегулярно. TextRazor продолжает использовать эти онтологии как наследие, но для современных проектов первичным справочником сущностей стоит считать Wikidata. Dandelion эмпирически работает с русским и белорусским языками лучше многих аналогов, но качество стоит проверять на собственных текстах перед выбором — у русскоязычного контента разная отраслевая специфика, и универсального лидера среди NER-сервисов для русского нет.

Прогоните 10 страниц из топа по своему запросу — получите 10 списков сущностей. Сведите их в таблицу: сущность по строкам, конкуренты по столбцам, на пересечении — упоминается / не упоминается и значимость (salience). Сущности, которые встречаются у 7+ конкурентов из 10, идут в обязательный список для вашей страницы. Сущности у 4–6 конкурентов — желательные. У 1–3 — опциональные, можно использовать для дифференциации.

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

Шаг 3. Расширение через граф знаний

Анализ конкурентов покажет то, что есть в топе. Но иногда стоит выйти за пределы топа — найти связанные сущности, которые конкуренты упустили, и использовать это как преимущество.

Главный инструмент здесь — сама Wikidata. У каждой сущности там есть свойства и связи, которые удобно использовать через P-номера: subclass of (P279), part of (P361), has part(s) (P527), uses (P2283), related category (P971), industry (P452), field of work (P101), practiced by (P3095). Через эти связи можно строить граф темы.

Например, для главной сущности «контент-маркетинг» (Q1192065) Wikidata через P361 (часть чего) показывает digital marketing, через P527 (включает в себя) — SEO, social media marketing, email marketing, через P2283 (использует) — content management system, analytics, через P3095 (практикуется кем) — связь с B2B и B2C marketing. Это и есть готовый каркас связанных сущностей.

Ручной обход Wikidata через веб-интерфейс работает, но на большом объёме тем удобнее использовать Wikidata Query Service (query.wikidata.org) — публичный SPARQL-эндпоинт, через который можно строить запросы вида «найди все сущности типа X, связанные с Y через свойство Z». Например, запрос «все методы цифрового маркетинга, являющиеся частью контент-маркетинга» возвращает структурированный список за секунды. Для системной работы с графом темы это незаменимый инструмент — он автоматизирует то, что вручную через клики по страницам Wikidata заняло бы часы.

Дополнительно используется Google Cloud Enterprise Knowledge Graph — официальный сервис, который позволяет искать сущности в графе Google и получать их связанные KGMID. Бесплатный для базового использования, требует API-ключа.

Третий источник — People Also Ask и Related Searches в Google. Это не сущности в строгом смысле, но они дают подсказки о темах, которые Google ассоциирует с вашим запросом, и часто содержат сущности, которых нет в топе.

Инструменты: InLinks, WordLift, Surfer SEO, MarketMuse

Делать всё вручную на крупном проекте неудобно. На рынке есть несколько специализированных инструментов, которые автоматизируют entity-based research. Разберём основные.

InLinks (inlinks.com) — пожалуй, самый «entity-нативный» SEO-инструмент. Подключаете сайт, инструмент сканирует страницы, извлекает сущности через собственный NLP-движок, строит граф темы и показывает: какие сущности у вас уже есть, какие сущности есть у конкурентов в топе, но отсутствуют у вас, какие связи между сущностями стоит усилить через внутреннюю перелинковку. У InLinks есть отдельная функция автоматической entity-based перелинковки — он расставляет внутренние ссылки по анкорам-сущностям. Из минусов — реальное ограничение для русскоязычных проектов: NLP-движок InLinks оптимизирован под английский, и на русском контенте entity-extraction дает менее точные результаты. Это не приговор, но фактор, который стоит учитывать при выборе.

WordLift (wordlift.io) — плагин и SaaS, ориентированный на построение собственного графа знаний сайта. Извлекает сущности из контента, автоматически генерирует Schema.org разметку (включая Article, Product, FAQ) с привязкой к сущностям через about и mentions, помогает создавать страницы-сущности (концептуальные хабы по темам) и строить топик-кластеры. WordLift хорошо интегрируется с WordPress, активно работает с Wikidata. Подходит для проектов, где важно не просто разово оптимизировать страницы, а построить долгосрочный entity-based фундамент.

Surfer SEO (surferseo.com) — наиболее массовый инструмент с entity-функциональностью. В режиме Content Editor показывает список сущностей и фраз (NLP terms — рекомендованные термины из NLP-анализа конкурентов), которые встречаются у конкурентов в топе по вашему запросу, и которые стоит использовать в тексте. Для каждой сущности указана рекомендованная частота упоминания. Surfer не строит полноценный граф знаний, но даёт быстрый практичный референс: что обязательно должно быть в тексте, чтобы конкурировать с топом. Подходит для оперативной работы при написании статей. Поддерживает русский язык.

MarketMuse (marketmuse.com) — корпоративный уровень. Анализирует темы целиком: оценивает Topic Authority (тематическую авторитетность сайта в нише), показывает gap-анализ (анализ пробелов) по сущностям и подтемам, рекомендует, какие материалы написать для усиления тематической авторитетности. Дороже Surfer и InLinks, но даёт стратегический слой работы с темами, а не отдельными страницами. Подходит крупным контентным проектам.

Frase (frase.io) — гибрид content brief и entity-анализа. По запросу собирает топ-20 страниц, извлекает их структуру (заголовки) и сущности, формирует бриф для копирайтера со списком обязательных сущностей и подтем. Дешевле Surfer, удобен для редакторов.

Clearscope — премиум-инструмент в духе Surfer, ориентирован на качественные англоязычные проекты. Очень аккуратный entity-анализ, но дорогой и без полноценной поддержки русского.

Для большинства русскоязычных проектов разумная связка — Surfer SEO для оперативной работы над страницами + Google NLP API для проверки salience + ручной анализ Wikidata через Wikidata Query Service для стратегических решений по темам. InLinks и WordLift подключаются, когда сайт вырастает до уровня, где ручная работа с графом нерентабельна.

Практический пример: entity-based research для статьи

Допустим, мы пишем для блога SEO-агентства статью на тему «On-page SEO: что это и как делать». Полный процесс:

Определение главной сущности. Главная сущность — On-page SEO (есть в Wikipedia как часть статьи Search Engine Optimization, в Wikidata пока без отдельной записи, но связана с Q180711). Для надёжности дублируем главную сущность в title, H1, первом абзаце, URL.

Анализ топа. Берём топ-10 Google по запросу «on-page SEO» и прогоняем через Google NLP API. После сведения данных получаем такую картину:

Это уже готовый каркас содержания.

Расширение через граф знаний. Идём в Wikidata, через Wikidata Query Service строим запрос на связанные сущности к Search Engine Optimization (Q180711). Находим: Search Engine Results Page (SERP), Web Crawler, Indexing, PageRank, Backlink, Off-page SEO, Technical SEO, Black hat SEO. Часть из них уже в нашем списке, часть (Off-page SEO, Technical SEO) полезно упомянуть для контраста — «on-page SEO работает в связке с off-page и technical SEO». Это уточняет позиционирование главной сущности.

Surfer SEO для финальной проверки. Создаём Content Editor в Surfer на запрос «on-page SEO», видим список рекомендованных терминов с целевой частотой. Сверяем с нашим списком — получаем финальный обязательный набор и пишем статью.

Проверка готового черновика. Прогоняем готовый текст через Google NLP API. Главная сущность On-page SEO имеет salience 0.42, следующая (SEO) — 0.18, дальше Page (0.08), Search Engine (0.07), и так далее. Структура нормальная: главная сущность доминирует, тема не размыта.

Как entity-based подход меняет планирование контента

Когда вы переходите от ключей к сущностям, меняется не только написание отдельных статей, но и структура контент-плана.

Вместо «под каждый кластер ключей — отдельная статья» появляется логика topic clusters (тематических статей) вокруг сущностей. Главная сущность ниши получает pillar (основную, гайд) страницу. Связанные сущности получают сателлитные страницы. Связи между сущностями реализуются через внутреннюю перелинковку с анкорами-сущностями — анкорами, которые дословно совпадают с названием целевой сущности (например, «контекстная реклама», «Schema.org разметка», «Core Web Vitals»), а не размытыми вариантами вроде «подробнее тут», «читать далее» или «по этой ссылке». Анкор-сущность работает как двойной сигнал: для пользователя как ясное обозначение содержания целевой страницы, для поисковика как явное указание, какую сущность раскрывает связанная страница.

Например, для SEO-агентства главная сущность «SEO» получает большой pillar. Связанные сущности — «On-page SEO», «Off-page SEO», «Technical SEO», «Local SEO», «Entity SEO», «E-E-A-T» — получают свои страницы. Каждая страница раскрывает свою сущность, ссылается на pillar и на смежные сущности через анкоры-сущности. Поисковик видит цельный граф темы на сайте, и тематическая авторитетность растет быстрее, чем при разрозненных статьях.

Параллельно меняется приоритизация. В классическом подходе мы пишем сначала про самые частотные ключи. В entity-based подходе — сначала про самые «связные» сущности, у которых много исходящих и входящих связей в графе темы. Они становятся хабами, на которые опирается остальной контент.

Entity gap analysis на уровне сайта

Помимо работы со сущностями отдельной страницы, существует стратегический слой — entity gap analysis на уровне всего сайта. Это вопрос не «каких сущностей не хватает на этой странице», а «каких сущностей-хабов нет вообще, хотя они должны быть для покрытия моей ниши».

Например, у SEO-агентства есть статьи про on-page SEO, технический аудит, ссылочное продвижение, но нет ни одной страницы про Entity SEO, E-E-A-T или Local SEO. С точки зрения topic clusters это значит, что половина графа темы не покрыта собственными хабами, и сайт ранжируется как «частичный авторитет» в нише, а не как полноценный.

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

Где entity-based подход незаменим

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

Подход максимально оправдан в сложных тематиках с большим количеством взаимосвязанных понятий: B2B-софт, медицина, финансы, юриспруденция, образование, технологии. Там, где Google активно использует Knowledge Graph для оценки экспертности. Также он критичен в YMYL-нишах, где E-E-A-T и точность фактов имеют повышенный вес.

Польза средняя в e-commerce: товары и категории — это уже сущности, и для них больше работает разметка Product, отзывы, цены, чем семантическое расширение. Хотя для категорийных и информационных страниц магазина entity-research снова становится полезным.

Эффект слабее в гиперлокальных и узкопродающих нишах («эвакуатор Минск 24 часа»), где главные факторы — локальные сигналы и прямой коммерческий интент. Там классический keyword research плюс LocalBusiness разметка решают почти всё.

Отдельно стоит выделить AI-поиск. ChatGPT Search, Perplexity, Google AI Overviews и Bing Copilot при формировании ответа опираются на сущности в исходных страницах еще сильнее, чем классическая выдача: LLM физически работает с эмбеддингами и сущностями, а не с TF-IDF и совпадениями фраз. Страница, плотно покрывающая нужные сущности с правильной salience главной, чаще попадает в число цитируемых источников AI-ответов и точнее интерпретируется моделью. В нишах, где значительная часть аудитории уже мигрирует с классического поиска на AI-ассистенты, entity-based подход перестает быть «продвинутой опцией» и становится базовым требованием видимости.

Типичные ошибки

Превращение сущностей в новые ключевые слова. Распространённая ошибка — взять список сущностей из Surfer и впихнуть их в текст с заданной частотой, не заботясь о связях. Получается тот же спам, только в новой обертке. Сущности должны быть встроены в смысл — через определения, контекст, связи с другими сущностями.

Игнорирование salience. Можно упомянуть все 50 нужных сущностей и при этом утопить главную. Если главная сущность по salience оказывается на третьем-четвёртом месте, страница ранжируется не по той теме. Регулярная проверка через Google NLP API — обязательная часть процесса.

Слепое копирование графа конкурентов. Если в топе три страницы низкого качества, у которых одинаковый набор сущностей — это не значит, что этот набор оптимален. Расширяйте его через Wikidata и собственное понимание темы.

Ставка только на инструменты. Surfer и InLinks показывают то, что уже есть в выдаче. Они плохо подсказывают, чего не хватает в индустрии в целом. Для стратегических решений нужны Wikidata, ручная аналитика и понимание предметной области.

Отсутствие синхронизации с разметкой. Если на странице упомянуты сущности, но нет соответствующей разметки Schema.org с about и mentions, поисковик всё равно их распознает — но менее уверенно. Для важных страниц имеет смысл явно размечать главные сущности через Schema.org, ссылаясь на их Wikidata Q-идентификаторы.

Игнорирование омонимии. Не уточнённая через Schema.org main entity омонимичная сущность (Apache, Mercury, Java) может быть распознана не той, что вы имели в виду. На технических и научных темах это особенно частая ошибка.

Как измерить результат

Entity-based research — это инвестиция времени, и без понимания, как измерить отдачу, легко потерять мотивацию через 2–3 месяца. Что смотреть.

Позиции по entity-related (связанных с сущностью) запросам, а не только по главным ключам. После проработки темы должны расти позиции не только по «контент-маркетинг», но и по связанным запросам: «контент-маркетинг для B2B», «инструменты контент-маркетинга», «contentmarketing и SEO» и так далее. Это сигнал, что Google расценил страницу как полноценное покрытие темы, а не узкий ответ на один запрос.

Попадание в AI-ответы. Регулярно проверяйте, цитирует ли страницу ChatGPT Search, Perplexity, Google AI Overviews по релевантным запросам. Рост цитирований — прямой эффект от плотного entity-покрытия.

Видимость в Knowledge Graph. Если страница про сущность бренда или продукта — следите за появлением и стабильностью Knowledge Panel, изменениями в составе sitelinks, появлением страницы в featured snippets.

Распределение трафика по long-tail. До entity-оптимизации страница обычно получает трафик с узкого пула запросов вокруг головного ключа. После — трафик размазывается по сотням длиннохвостых запросов, связанных через сущности. Резкий рост числа запросов в Search Console при том же или меньшем числе главных ключей — характерный признак сработавшего entity-подхода.

Изменение salience главной сущности после правок. Это микроуровневая метрика, но полезная для проверки гипотез. Прогон через Google NLP API до и после правок показывает, удалось ли усилить главную сущность относительно фоновых.

Горизонт измерения — 3–6 месяцев на крупных страницах, 1–3 месяца на быстро индексируемых нишах. Раньше делать выводы преждевременно: Google нужно время, чтобы переоценить страницу в новой entity-конфигурации.

Чек-лист внедрения

• Зафиксировать главную сущность темы и проверить её через Knowledge Panel в Google.
• Снять омонимию для неоднозначных сущностей через Schema.org about с указанием Wikidata Q-идентификатора.
• Определить минимум 3–5 ключевых конкурентов в топ-10 по основному запросу.
• Прогнать их страницы через Google NLP API или TextRazor, собрать сводный список сущностей с частотой встречаемости.
• Расширить список через Wikidata: связанные сущности, подтипы, родительские категории. На сложных темах использовать Wikidata Query Service.
• Проверить через Surfer SEO или MarketMuse соответствие текущим SERP-сигналам и получить рекомендации по плотности.
• Написать контент, обеспечив естественное упоминание обязательных сущностей и доминирование главной.
• Прогнать готовый текст через Google NLP API, убедиться, что главная сущность имеет наивысший salience.
• Внедрить Schema.org разметку с явным указанием главной сущности через about и связанных через mentions.
• Построить внутреннюю перелинковку с анкорами-сущностями между pillar и сателлитными страницами.
• Отследить через 3–6 месяцев изменения по entity-related запросам, AI-цитированиям и распределению long-tail трафика.
• Регулярно повторять entity-аудит для ключевых страниц — раз в 6–12 месяцев топ меняется, и набор обязательных сущностей вместе с ним.
• Раз в год проводить entity gap analysis на уровне сайта и закрывать недостающие хабы новыми страницами.

Заключение

Entity-based keyword research — не замена классическому подходу, а слой, который встраивается поверх него и приводит работу с семантикой в соответствие с реальной логикой современных поисковиков. Ключи отвечают, как пользователи спрашивают. Сущности отвечают, о чём страница должна быть, чтобы поисковик считал ответ исчерпывающим.

Освоение этого подхода требует одного нового мышления и нескольких инструментов — Google NLP API, Surfer SEO или Frase для оперативной работы, Wikidata и Wikidata Query Service для стратегического расширения, и опционально InLinks/WordLift для системного управления графом сайта. Времени на одну страницу уходит чуть больше, чем при классическом подходе, но в нишах со сложными темами и конкуренцией разница в результатах оправдывает вложение многократно.

Entity-based research — это работа с сущностями темы, направленная на то, чтобы страница максимально полно её раскрывала. Она хорошо стыкуется с двумя другими опорами Entity SEO: разметкой Schema.org Organization с sameAs (которая делает сам бренд цельной сущностью для поисковиков) и записью в Wikidata с Knowledge Panel (которая выводит бренд в глобальный граф знаний). Вместе эти три слоя — сущности темы, сущность бренда, сущность в графе знаний — образуют полный entity-стек современного SEO.

Главное — перестать думать «какие слова добавить, чтобы ранжироваться» и начать думать «какие сущности должны быть на странице, чтобы тема была раскрыта так же полно, как у лучших конкурентов, и желательно полнее». Это и есть переход от seo-оптимизации текстов к семантическому проектированию контента в логике Knowledge Graph.