🏷️Organization и Person schema для GEO: разбор на живых сущностях

Почему без Organization-разметки ChatGPT и AI Overviews не понимают, кто вы — и как через sameAs и @id связать бренд с автором в единый граф.

редакция seodb#schema.org#geo#ai-поиск#entity

Открываешь view-source сайта, у которого 300 тысяч визитов в месяц, ищешь Organization — а там LocalBusiness, воткнутый плагином в 2021-м, с полем name: "Главная" и пустым sameAs: []. И это не заброшенный проект, это живой бизнес, который потом удивляется, почему в ответе Perplexity про их нишу цитируют кого угодно, только не их.

Я это вижу постоянно. Из последней волны аудитов — 18 сайтов за июнь, средних, не мусорных — корректная Organization была ровно у четырёх. У остальных либо ничего, либо разметка, которая машине скорее вредит, чем помогает. И вот это уже не «мелочь для SEO». Это причина, по которой AI-движок не может однозначно понять, кто вы такие, и на всякий случай не берёт вас в ответ.

Что это вообще за штука — на пальцах

Organization schema — это блок <script type="application/ld+json"> в <head>, где вы машинными полями сообщаете: вот сущность, её зовут так, живёт по такому URL, вот логотип, вот контакт, а вот — и это главное — ссылки на её же профили в других местах. Тип из schema.org/Organization, формат — JSON-LD, потому что и Google, и Яндекс давно рекомендуют именно его, а не microdata в атрибутах.

Технически это пять–пятнадцать строк. Смысл — не декоративный. Вы не «размечаете страницу», вы объявляете узел в графе сущностей и подтверждаете его существование внешними источниками. Разница примерно как между «человек представился на словах» и «человек показал паспорт, а вы сверили его с тремя реестрами».

Почему это про GEO, а не про ранжирование

Тут надо сразу убить одно ожидание. Organization schema не поднимает позиции. Google это проговаривал годами — и Мюллер повторял неоднократно, что структурированные данные не дают generic ranking boost, их задача — включать rich-фичи в выдаче, а не двигать сайт вверх (SEO Roundtable). Если вам продают Organization-разметку под соусом «выведем в топ-10» — вам продают не то.

Работает она в другой плоскости. И вот тут интересно.

Есть три потребителя этой разметки, которым по-настоящему не всё равно. Первый — Knowledge Panel и, что важнее в 2026-м, AI Overviews: они строятся на Knowledge Graph, а Organization + sameAs это один из входов, по которым сущность в граф попадает и получает уверенность. Второй — генеративные движки, ChatGPT и Perplexity, которым при ответе «расскажи про компанию X» надо на что-то опереться, и структурированный, само-подтверждённый факт они предпочитают вычитанному из простыни текста. Третий, про который в РФ забывают, — Яндекс: он использует Organization-разметку для сниппетов и в связке с сигналами формирует быстрые ссылки, это прямо в доках Вебмастера.

Разница между «есть Organization» и «нет» на выходе выглядит так. Когда её нет — модель собирает вас из обрывков: title, случайный абзац из «О нас», чей-то пересказ на VC. И часто путает с тёзкой. Когда она есть и подтверждена через sameAs — модель берёт каноничное название, каноничное описание, привязывает к Wikidata и отвечает про вас, а не про однофамильца.

Предположу — и тут я могу ошибаться, данных мало и они шумные, — что для B2B и SaaS с неуникальным названием это вообще решающий фактор попадания в AI-ответ. По моим наблюдениям на клиентских проектах, чётче всего эффект виден там, где бренд легко спутать: как только появлялась связка Organization → sameAs → Wikidata, «слепая зона» модели по бренду закрывалась.

sameAs — тот самый критический элемент

Если из всей Organization оставить одно поле, я бы оставил sameAs. Всё остальное — украшение, а sameAs — это подтверждение личности.

Смысл поля простой: вы перечисляете URL, которые указывают на ту же самую сущность в других системах. И чем авторитетнее источник, тем сильнее сигнал. Wikidata тут в особом положении — это прямой вход в Knowledge Graph Google, и связка с записью Wikidata даёт машине идентификатор, по которому она уверенно вас узнаёт. Дальше по убыванию — Wikipedia, LinkedIn, Crunchbase, GitHub (для tech-компаний критично), YouTube-канал, отраслевые реестры.

Покажу на живой сущности, которую можно проверить руками прямо сейчас. У Anthropic есть запись в Wikidata — Q116758847. Есть Wikipedia (en.wikipedia.org/wiki/Anthropic), LinkedIn (/company/anthropicresearch), Crunchbase (/organization/anthropic). Собранный из этих подтверждённых профилей блок sameAs выглядит так:

"sameAs": [
  "https://www.wikidata.org/wiki/Q116758847",
  "https://en.wikipedia.org/wiki/Anthropic",
  "https://www.linkedin.com/company/anthropicresearch",
  "https://www.crunchbase.com/organization/anthropic"
]

Это не абстракция — каждый URL реальный, каждый ведёт на ту же сущность, и Wikidata-ID (Q116758847) для машины дороже остальных трёх вместе взятых, потому что это уже узел графа, а не просто страница. У OpenAI, для сравнения, свой узел — Q21708200. Крупные компании тем и отличаются, что у них Organization обвешана десятком таких подтверждений плюс contactPoint с телефоном саппорта и типом контакта — модель получает не только «кто», но и «как связаться».

А теперь то, что бесит.

Самая частая ошибка на средних сайтах — sameAs есть, но пустой. Просто "sameAs": [], оставленный генератором разметки «на потом». Это как паспорт без единой страницы: формально документ, толку ноль. Вторая по частоте — name в разметке не совпадает с брендом: в шапке «Студия Ромашка», в JSON-LD name: "romashka-studio.ru" или вообще домен. Машина видит два разных имени и не склеивает их в одну сущность. И третья, самая коварная — два-три конфликтующих Organization-блока на одной странице: один от темы, один от SEO-плагина, один от кого-то ещё, с разными name и url. Краулер получает противоречие и разумно решает не доверять никому.

Я сначала думал, что пустой sameAs — это просто недоработка, которую легко закрыть. Потом до меня дошло: проблема глубже. У многих этих компаний нечего класть в sameAs — у них нет ни Wikidata, ни нормального LinkedIn, ни Crunchbase. То есть дело не в разметке, а в том, что сущности как таковой во внешнем мире не существует. И вот это чинится не строчкой JSON, а месяцами работы над присутствием.

Person schema — связываем автора, статью и компанию

С организацией разобрались, но для GEO есть второй слой, который почти все пропускают, — авторы.

Логика та же, что с брендом: AI-движку и Google для оценки экспертности (то самое E-E-A-T) надо понимать, кто написал текст и почему ему можно верить. Не «аноним под ником Admin», а конкретный человек с профилями, должностью и областью компетенции. И связывается это в цепочку через @id: Article ссылается на автора → автор это Person → Person worksFor вашу Organization. Три узла, сшитые идентификаторами.

Ключевые поля у Person — те же sameAs (LinkedIn, GitHub, личный сайт, профиль на Хабре), плюс jobTitle и knowsAbout — список тем, в которых человек разбирается. knowsAbout — недооценённое поле: именно по нему движок понимает, что автор статьи про JSON-LD действительно спец по технической разметке, а не копирайтер, которому дали тему. Схема простая — Article → author (Person) → worksFor (Organization), и везде совпадающие @id.

Микро-деталь, на которой спотыкаются: @id должен быть одинаковый во всех местах, где сущность упоминается. Если на странице статьи автор #/person/ivanov, а на странице «Команда» тот же Иванов вдруг #author-2 — для машины это два разных человека. Сущность размывается, экспертность не накапливается. Один человек — один @id на весь сайт, без исключений.

Минимальный рабочий шаблон

Не надо сразу лепить пятнадцать полей. Начните с того, что реально считывается и подтверждается. Вот скелет, который можно вставить в <head> главной и дальше наращивать:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://ваш-домен.ru/#organization",
  "name": "Точное имя бренда — как в шапке",
  "url": "https://ваш-домен.ru/",
  "logo": "https://ваш-домен.ru/logo.png",
  "description": "Одно честное предложение о том, что вы делаете.",
  "sameAs": [
    "https://www.linkedin.com/company/ваш-профиль",
    "https://www.crunchbase.com/organization/ваш-профиль",
    "https://www.wikidata.org/wiki/QXXXXXXX"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer support",
    "email": "hello@ваш-домен.ru"
  }
}
</script>

Два правила, без которых шаблон не работает. name — буква в букву как бренд на сайте, никаких доменов и слоганов. И sameAs — только те профили, которые реально существуют и реально ваши; один живой LinkedIn лучше, чем пять выдуманных ссылок. Официальную спецификацию полей держите под рукой — Google Search Central про Organization описывает, что движок реально читает.

Если хотите закрыть тему AI-цитируемости целиком — Organization это фундамент, но не всё. Про соседний по важности файл я уже писал: llms.txt как минимум, он работает в паре с разметкой.

Что сделать в ближайшие полчаса. Открой view-source своей главной, найди Ctrl+F → application/ld+json. Если блока нет — возьми шаблон выше и вставь, это уже больше, чем у половины конкурентов. Если блок есть — проверь три вещи: совпадает ли name с брендом дословно, не пустой ли sameAs, и не сидит ли на странице второй Organization с другими данными. Нашёл пустой sameAs — иди заводить Wikidata и LinkedIn, это тот случай, когда одна запись в реестре стоит дороже сотни правок в коде.