sameAs — это «удостоверение личности» сущности для поисковых систем. Когда индексатор (Google, Яндекс, AI-сервис) встречает на сайте организацию или человека, он должен понять: это та же компания, которую он уже видел в Wikidata, или просто организация с похожим названием. sameAs даёт прямой ответ — указывает на канонические внешние страницы, однозначно относящиеся к этой же сущности.
Как это работает
sameAs — это свойство Schema.org со значением URL или массивом URL у объектов, наследующих от типа Thing: Organization, LocalBusiness, Person, Product, CreativeWork и других. В JSON-LD оба варианта валидны; одиночный URL используется, когда у сущности одно каноническое внешнее представление, массив — когда несколько.
Когда индексатор встречает sameAs, он переходит по указанным ссылкам и сверяет, что там действительно описана та же сущность. Подтверждённые упоминания могут связываться в общий узел knowledge graph. Google официально документирует использование sameAs для построения Knowledge Graph и Knowledge Panel; AI-системы (ChatGPT, Perplexity, Алиса AI, GigaChat) опираются на Wikidata и графы знаний поисковиков, поэтому получают пользу от sameAs опосредованно.
На практике приоритет ссылок выстраивается так: глобальные графы знаний (Wikidata, Wikipedia) → официальные отраслевые реестры (Росздравнадзор, ORCID, реестры регуляторов) → крупные карты и каталоги (Яндекс.Бизнес, Google Business Profile, 2ГИС) → официальные профили в соцсетях. Универсальной формулы «сколько весит каждый источник» поисковики не публикуют, но логика «авторитетный реестр сильнее агрегатора» подтверждается косвенно через документацию Google по Organization schema.
Какие ссылки давать в sameAs
Список зависит от типа сущности.
Для Organization / LocalBusiness:
- Wikidata Q-номер организации (если есть запись)
- Wikipedia (статья про компанию)
- Карточка на Яндекс.Бизнесе (
yandex.ru/maps/org/...) - Карточка Google Maps или профиль в Google Business Profile
- Карточка на 2ГИС
- Официальные профили в соцсетях: ВКонтакте, Telegram, YouTube, Дзен
- Профильные отраслевые реестры (для клиники — лицензия Росздравнадзора, для юриста — реестр адвокатов и т.д.)
Для Person (специалист, автор):
- Wikidata Q-номер человека (если есть)
- Профильные реестры (Росздравнадзор, ORCID для исследователей, реестры регуляторов профессии)
- Профили в профильных платформах (GitHub, Behance, Habr — там, где это релевантно для аудитории)
- Авторская страница на крупных СМИ или экспертных площадках
На практике sameAs обычно указывают на внешние канонические профили и справочные страницы, а не на внутренние страницы того же сайта.
Зачем это нужно
В классическом SEO sameAs не является фактором ранжирования. Представители Google (Джон Мюллер, Гэри Иллис) неоднократно публично подтверждали, что Schema.org-разметка, включая sameAs, в прямые факторы ранжирования не входит — но она помогает Google точнее сопоставить организацию с её внешними профилями и знаниями о ней.
В GEO sameAs становится важным техническим сигналом для entity disambiguation — различения и сопоставления одной сущности между разными источниками. AI-поисковики (ChatGPT, Perplexity, Алиса AI, GigaChat) при формировании фактологических ответов опираются на Wikidata и Google Knowledge Graph, а sameAs — один из механизмов, через который сайт может попасть в эти графы.
Практический эффект корректно прописанного sameAs:
- Поисковики и AI-сервисы реже путают организацию с тёзками и реже выбирают противоречивые контактные данные из разных источников
- NAP-консистентность подтверждается через внешние ресурсы, а не только декларируется на сайте
- Растёт точность представления бренда в Knowledge Panel Google и в фактологических ответах AI
- Создаётся техническая основа для попадания в AI-ответы: модели Claude, ChatGPT, Perplexity опираются на Wikidata при формировании фактологии, а sameAs — один из ключевых механизмов, через который сайт включается в эти графы
Пример
Анонимизированный фрагмент JSON-LD для медицинской клиники в Москве:
{
"@context": "https://schema.org",
"@type": "MedicalOrganization",
"name": "Клиника X",
"url": "https://klinika-x.ru/",
"telephone": "+7 495 ...",
"sameAs": [
"https://www.wikidata.org/wiki/Q123456789",
"https://ru.wikipedia.org/wiki/Клиника_X",
"https://yandex.ru/maps/org/klinika-x/.../",
"https://2gis.ru/moscow/firm/.../",
"https://t.me/klinika_x",
"https://vk.com/klinika_x"
]
}Эта связка позволяет поисковикам и AI-системам подтвердить: «клиника X из карточки Яндекс.Карт» = «клиника X со страницы Wikidata» = «организация по адресу из 2ГИС» — и реже дробить упоминания на несколько entity.
Частые ошибки
1. sameAs указывает на свой же сайт. Циклическая ссылка: пользы от неё нет. На практике sameAs указывают на внешние канонические профили.
2. Нерабочие или устаревшие URL. Каждая 404-ссылка снижает доверие поисковика к разметке в целом. Google официально рекомендует поддерживать все указанные в sameAs URL рабочими; нерабочая ссылка не сделает всю разметку невалидной, но отдельные сигналы потеряются.
3. Разные Wikidata Q-номера для одной организации. Конфликт сигналов. У одной сущности должна быть одна каноническая запись в Wikidata; при дублях — слить через merge-запрос в Wikidata.
4. sameAs только у главной страницы организации. Для каждого ключевого Person (специалиста, автора) нужны свои sameAs-связки, иначе авторитет персон не передаётся entity-сетке.
5. В sameAs помещают лендинги и партнёрские страницы. sameAs ожидает URL на каноническое описание сущности, а не на маркетинговую страницу. Партнёрки и лендинги для этого не подходят.
