Entity-сборка – фундаментальная задача GEO. Когда AI-система или поисковик получает запрос «телефон клиники X», он должен в индексе найти одну сущность «клиника X», а не пять разных карточек с похожим названием. Качество entity-сборки определяет, появитесь ли вы в фактологических ответах AI и какую именно информацию о вас процитирует система.
Как это работает
Поисковики (Google, Яндекс) и AI-сервисы строят knowledge graph – граф связанных сущностей: организаций, людей, мест, продуктов, событий. Каждая сущность – узел графа, связи между узлами – отношения (Person → worksFor → Organization, Organization → location → Place).
Когда система индексирует ваш сайт, карточку на Яндекс.Картах, статью в Wikipedia, профиль в соцсетях – для каждого упоминания нужно решить: это та же сущность, что уже есть в графе, или новая?. Если ответ «та же» – упоминание добавляется к существующему узлу, усиливая сигналы о нём. Если ответ «новая» – создаётся новый узел, а старая связь рвётся.
Сигналы для entity-сборки
Явные:
- sameAs-связки в Schema.org-разметке – прямое указание «эта организация = эта запись в Wikidata»
identifierв Schema.org – идентификаторы ИНН, ОГРН, ISBN, GTIN- Идентификаторы в knowledge graphs – Q-номер Wikidata, ORCID для исследователей, отраслевые реестры некоммерческих организаций и фондов
Неявные:
- NAP-консистентность – совпадение названия, адреса, телефона по всем источникам
- E-E-A-T-сигналы – авторство, экспертность, ссылки на первоисточники, реестры
- Совпадение Schema.org-типов (Organization, MedicalOrganization, Person)
- Ссылочный профиль – какие сайты ссылаются на вас и в каком контексте
Зачем это нужно
- Корректное представление в knowledge panel Google. Google показывает справа от выдачи карточку с фотографией, контактами, отзывами – это срез из knowledge graph. Без entity-сборки карточки нет или она с устаревшими/чужими данными
- Точные фактологические ответы AI. Когда пользователь спрашивает у Алисы AI «адрес клиники X», система обращается к knowledge graph. Если entity собран – ответ точный. Если нет – AI «галлюцинирует» или выдаёт случайные данные
- Защита бренда от тёзок. В Москве 50 клиник «Здоровье», в РФ – тысячи организаций «Стройинвест». Entity-сборка отделяет именно вашу организацию от тёзок
- Передача авторитета внутри entity-сетки. Когда статью на крупной площадке индексирует поисковик, и автор подтверждён через sameAs/ORCID – авторитет статьи передаётся вашему профилю в knowledge graph
Пример из аудита
В аудите медицинской клиники в Москве entity-сборка была сломана: организация существовала в индексе AI-сервисов как минимум как 6 разных сущностей с похожим названием. Признаки разрыва:
- 6 разных номеров телефона в индексе AI
- 3 версии адреса (старый юр.адрес, фактический, ошибочный в карточке 2ГИС)
- Отсутствие sameAs-связок в Schema.org-разметке сайта
- Отсутствие записи в Wikidata
- Отсутствие подтверждённого профиля в Яндекс.Бизнесе (карточка создана третьей стороной)
Когда пользователь спрашивал Алису AI «телефон клиники X», AI выбирал один из шести номеров – иногда действующий, иногда устаревший. После починки entity-сборки (NAP-сверка, добавление sameAs, верификация карточек) AI стабилизировался на одной правильной сущности.
Как настроить entity-сборку
- Сделать инвентаризацию упоминаний организации в индексе (Google «название», Яндекс «название», ChatGPT «расскажи о X»)
- Сверить NAP-данные по всем найденным источникам – собственный сайт, карты, справочники, отзовики, соцсети
- Привести NAP-данные к единому формату на всех площадках
- Добавить корректную Schema.org-разметку Organization/LocalBusiness/MedicalOrganization на сайт
- В Schema.org прописать sameAs-связки на канонические внешние профили
- При возможности – создать запись в Wikidata с подтверждением независимыми источниками
- Через 30–60 дней – переиндексация в AI-сервисах, повторный замер entity-связности
Частые ошибки
1. Думают, что sameAs – это вся entity-сборка. sameAs – один из сильных сигналов, но без NAP-консистентности и подтверждения через внешние источники одного sameAs мало.
2. Не следят за дублями карточек. Старая карточка Яндекс.Бизнеса, неудалённая после смены адреса, продолжает жить в индексе и конкурирует с новой за статус «канонической». Дубли нужно удалять или сливать.
3. Игнорируют партнёрские и третьесторонние карточки. Если карточку в 2ГИС создал партнёр с устаревшими данными, и эта карточка проиндексирована – она входит в entity-сетку. Нужно либо удалить, либо синхронизировать.
4. Меняют название организации без обновления entity-сетки. Ребрендинг с «ООО Здоровье» на «Клиника Меридиан» требует полного обновления Schema.org, Wikidata, всех карточек. Иначе в индексе сосуществуют две сущности – старая и новая, и AI смешивает их данные.
5. Считают entity-сборку разовой задачей. Это постоянный процесс – появляются новые карточки, ссылки, упоминания. Раз в полгода нужно делать аудит entity-сетки и проверять, что новые упоминания подхватываются в правильный узел.
