sameAs
Определение
Свойство Schema.org со значением URL, указывающее на канонические внешние страницы той же сущности (Wikidata, Wikipedia, профили, реестры). Помогает поисковикам и ИИ-сервисам различать тёзок и собирать сущности в единый узел графа знаний.
4 мин 272 Обновлено 19 октября
sameAs – это "удостоверение личности" сущности для поисковых систем. Когда индексатор (Google, Яндекс, ИИ-сервис) встречает на сайте организацию или человека, он должен понять: это та же компания, которую он уже видел в 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; ИИ-системы (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 – различения и сопоставления одной сущности между разными источниками. ИИ-поисковики (ChatGPT, Perplexity, Алиса AI, GigaChat) при формировании фактологических ответов опираются на Wikidata и Google Knowledge Graph, а sameAs – один из механизмов, через который сайт может попасть в эти графы.
Практический эффект корректно прописанного sameAs:
- Поисковики и ИИ-сервисы реже путают организацию с тёзками и реже выбирают противоречивые контактные данные из разных источников
- NAP-консистентность подтверждается через внешние ресурсы, а не только декларируется на сайте
- Растёт точность представления бренда в Knowledge Panel Google и в фактологических ответах ИИ
- Создаётся техническая основа для попадания в ИИ-ответы: модели 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"
]
}Эта связка позволяет поисковикам и ИИ-системам подтвердить: "клиника 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 на каноническое описание сущности, а не на маркетинговую страницу. Партнёрки и лендинги для этого не подходят.
Частые вопросы
Чем sameAs отличается от schema:identifier?
sameAs принимает URL – ссылки на канонические внешние страницы сущности. identifier – общее свойство Schema.org для идентификаторов вроде ISBN, GTIN, UUID, ИНН, ОГРН. Они не взаимозаменяемы: sameAs нужен для entity disambiguation и связи с knowledge graph, identifier – для машинно-читаемой идентификации. Пример: для клиники "sameAs": "https://yandex.ru/maps/org/..." ведёт на каноническую карточку, а "identifier": { "@type": "PropertyValue", "propertyID": "ИНН", "value": "7707083893" } фиксирует юридический идентификатор. Оба нужны, но решают разные задачи.
Можно ли использовать sameAs для физического лица?
Да, в объекте Person. Особенно полезно для авторов и экспертов: ссылки на ORCID, профильные реестры, авторские страницы на крупных площадках помогают ИИ-системам собрать E-E-A-T-сигналы (экспертность, авторитетность, надёжность) и связать публикации одного автора через разные ресурсы.
Что делать, если у организации нет ни Wikidata, ни Wikipedia?
Начните с того, что есть: карточки Яндекс.Бизнеса, Google Business Profile, 2ГИС, профильных реестров, соцсетей. Это уже минимальная entity-сетка. Параллельно – можно создать запись в Wikidata самостоятельно, требуется бесплатный аккаунт и подтверждение независимыми источниками.
Сколько ссылок оптимально в sameAs?
На практике для Organization обычно достаточно 5–10 качественных ссылок: Wikidata + Wikipedia (если есть) + основные карты + 3–5 ключевых соцсетей. Для Person – 3–6 ссылок. Schema.org и Google никаких числовых норм не публикуют – это практическая эвристика, а не правило. Принцип: ссылки должны быть авторитетными и рабочими, чем меньше "мусорных" URL, тем сильнее сигнал.
Влияет ли sameAs на позиции в Google и Яндексе?
Не напрямую. Представители Google (Джон Мюллер, Гэри Иллис) неоднократно публично подтверждали, что schema.org-разметка, включая sameAs, не входит в прямые факторы ранжирования. sameAs влияет на представление результатов (Knowledge Panel, расширенные сниппеты) и помогает Google точнее сопоставить организацию с внешними профилями. Это косвенно поддерживает релевантность по бренд-запросам и шансы попасть в ИИ-ответы.
Связанные термины
Материалы по теме
Что почитать дальше по этой теме
