Разметка Schema.org под AI: сущности вместо ключей

Разметка Schema.org - код внутри страницы, который сообщает машинам, что за фрагмент перед ними: где название компании, где автор, где дата публикации, где цена. Прироста цитирований в AI-ответах она сама по себе не дает. Ее работа - убрать догадки при разборе: без нее краулер не отличит цену от номера телефона, а страницу компании в LinkedIn сочтет отдельной организацией.

Советы по разметке расходятся до противоположных. Одни источники называют ее обязательной для попадания в AI-ответы, другие приводят замеры, где эффект колеблется около нуля. Обе стороны опираются на цифры, и обе цифры сходятся, если посмотреть, каким сайтам разметка помогает. Она остается одним техническим куском работы над видимостью в AI-выдаче, причем не первым в очереди: сперва краулер должен хотя бы получить HTML страницы.

Что дает разметка и чего от нее ждать не стоит

Страница для человека и страница для машины - разные объекты. Человек видит заголовок, цену и телефон по расположению, размеру шрифта и привычке. Бот получает поток текста, в котором число 4900 может оказаться ценой, номером кабинета или площадью склада в квадратных метрах. JSON-LD снимает этот вопрос: цена лежит в поле `price`, телефон в `telephone`, название компании в `name`. Догадываться движку больше не нужно.

Ближе всего сюда аналогия с технической документацией на автомобиль. По фотографии две похожие модели одного завода не различить, по документации - за секунду. Google и AI-ассистенты не тратят ресурсы на полный разбор верстки, если суть страницы им отдали отдельным структурированным блоком. Страницы с разметкой краулеры обходят заметно быстрее, это наблюдение повторяется на разных проектах.

Словарь Schema.org собирали Google, Microsoft и Yandex вместе, поэтому один и тот же код читают все крупные движки, а следом за ними и генеративные. В мае 2025 Google обновил документацию и прописал требования к структурированным данным для своих AI-функций.

Дальше цифры, которые противоречат друг другу. Подтвержденных данных о том, что установка разметки сама по себе повышает шанс цитирования, нет. Ahrefs замерял эффект на своих страницах: после добавления разметки цитирования в AI Overviews просели на 4,6%, а в ChatGPT и AI Mode изменения оказались неотличимы от нуля. Вывод авторов замера: отдельно под AI-выдачу разметку внедрять смысла мало, но если она уже стоит ради поиска - пусть стоит.

Отраслевой отчет по локальному бизнесу дает картину наоборот. Компании с корректно собранной разметкой LocalBusiness, Service, FAQ, Article и WebSite попадают в цитаты AI Overviews до трех раз чаще, чем конкуренты без нее.

Разброс слишком велик, чтобы списать его на погрешность выборки.

Оба замера сходятся, если посмотреть на исходное состояние сайта. Ahrefs - крупный домен с выстроенной структурой, известным брендом и текстом, который движок разбирает без подсказок. Догадок там и так не было, добавлять нечего. Сервисная компания из Ташкента или Бишкека выглядит иначе: название встречается на сайте в трех вариантах написания, адрес спрятан в картинке, часы работы утоплены в абзаце, а страница услуги подписана как «Наши работы». Разметка закрывает эти пробелы, и разница в цитировании появляется.

Отсюда рабочая формулировка. Разметка снимает путаницу при разборе страницы. Позицию в выдаче она не поднимает, и выигрывает от нее тот, у кого путаницы много. Чем понятнее сайт был до внедрения, тем скромнее прирост.

В очереди технических задач разметка стоит не первой. Сперва контент важных страниц: услуги, товары, ответы на вопросы, с которыми люди приходят. Потом проверка, что боты Google и ChatGPT забирают этот контент без потерь. Разметка - третий шаг. На пустой странице она не работает, потому что описывать нечего.

Рядом стоит вопрос про llms.txt. Оба формата решают задачу машинного чтения, но с разных сторон: llms.txt отдает моделям карту сайта, а разметка описывает конкретную страницу изнутри. Одно другое не заменяет и не отменяет.

Organization: с чего начинают

Работа начинается с одной страницы, которую делают единым источником правды о компании: почти всегда это раздел «О нас». На ней собирают полную Organization-разметку - название, логотип, чем компания занимается, год основания, контакты. Дальше этот же блок расходится по всем остальным страницам сайта.

Набор полей идентичности, который держат на всем сайте, невелик: WebSite, Organization, Person, ContactPoint, PostalAddress, Brand. Первые два отвечают на вопрос, что это за сайт и чья это компания. Остальные уточняют людей, адрес и способы связи. Organization с названием, логотипом и ссылками на профили питает панель знаний Google - карточку компании справа от выдачи.

Частая ошибка выглядит так: разметку поставили на главной и успокоились. Бот приходит на страницу услуги из AI-ответа, а не с главной, и получает документ, где о компании не сказано ничего. Правильный вариант - один и тот же блок Organization на каждой странице сайта, а на странице «О нас» дополнительно AboutPage.

Сложная структура компании путает даже модель. Головное юрлицо в Узбекистане, операционный офис в ОАЭ, отдельная сущность в ЕС для европейских клиентов: если связи между ними не описаны, движок читает три разные организации с похожими названиями. Поля `parentOrganization` и `subOrganization` показывают иерархию, а `legalName` отделяет юридическое название от бренда. Разговор с клиентом про то, как устроена группа компаний, дает структуру, которую потом переносят в код почти без правок.

Описанное в коде обязано совпадать с тем, что видно на странице. Прописали часы работы, которых на сайте нет, - получили конфликт между кодом и текстом. Выдуманные поля движки распознают, и работает это против сайта.

Локальному бизнесу нужен тип LocalBusiness с адресом, телефоном, часами работы и зоной обслуживания. Минимум обязательный, но недостаточный: карточка компании в Google Картах весит для локальной выдачи больше, чем поля в коде.

Дальше - пример на реквизитах HITZ Agency, GEO-агентства в Центральной Азии. Код рабочий, копируется и правится под свои данные.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://hitz.agency/#organization",
  "name": "HITZ Agency",
  "url": "https://hitz.agency",
  "description": "GEO-агентство в Центральной Азии: видимость бренда в AI-поиске и классической выдаче",
  "areaServed": [
    {"@type": "Country", "name": "Uzbekistan"},
    {"@type": "Country", "name": "Kazakhstan"},
    {"@type": "Country", "name": "Kyrgyzstan"}
  ],
  "knowsAbout": [
    "Generative Engine Optimization",
    "Search Engine Optimization",
    "Performance marketing"
  ]
}
</script>

Что делает каждое поле. `@id` - постоянный идентификатор компании внутри сайта, на него ссылаются остальные блоки разметки. `name` пишут в той же форме, в какой название стоит в тексте страниц и в профилях: разнобой написания размывает сущность. `url` указывает на домен, который считается основным. `description` пересказывает деятельность теми словами, которыми компанию описывают клиенты. `areaServed` перечисляет страны или города обслуживания, `knowsAbout` связывает компанию с темами, в которых она работает.

К этому набору добавляют `logo` со ссылкой на файл, `foundingDate` с годом основания, `contactPoint` с телефоном и почтой, `address` с юридическим адресом. Свойство `sameAs` идет туда же, но у него отдача другая, и разбирается оно ниже отдельно.

Article и FAQPage: разметка содержимого страниц

Тип разметки выбирают под то, что на странице лежит:

• статья или пост в блоге - Article, для блога чаще BlogPosting
• карточка товара - Product с вложенным Offer, разметка для магазина заслуживает отдельного разбора
• справочный раздел с вопросами - FAQPage
• пошаговая инструкция - HowTo
• страница с видео - VideoObject
• раздел «О нас» - AboutPage поверх Organization
• контакты - ContactPage
• услуга - Service со ссылкой на организацию-исполнителя

Список закрывает сайт средней сложности. Остальное - редкие случаи.

Как раскладка выглядит на большом магазине, видно у Gymshark: на главной Organization и WebSite, на страницах категорий CollectionPage с ItemList, на карточках Product с Offer и отзывами, в блоге Article. Каждая страница описана тем типом, который отвечает ее содержимому, и лишнего сверху не навешано. На хабе инструменты та же связка CollectionPage и ItemList описывает список калькуляторов.

Со Schema.org соседствует другой формат структурированных данных - XML-фиды Яндекс.Вебмастера. Их около двенадцати под разные тематики: недвижимость, медицина, врачи, мероприятия. Фид дает расширенный сниппет с характеристиками объекта отдельным блоком выдачи, и зависимость там прямая: у медицинских сайтов отвалившийся фид роняет позиции, а после его включения трафик возвращается за два-три дня.

Article с датой публикации, автором и заголовком дает движку два сигнала: когда материал вышел и кто за ним стоит. Поле `dateModified` забывают чаще остальных, и статья, которую обновляли неделю назад, выглядит для машины трехлетней. Скучное, но рабочее правило: тронули текст - подвиньте дату.

Автора описывают отдельным блоком: имя, должность, ссылки на профили, короткая биография. Для тем, где важен опыт, это разница между безымянным текстом компании и текстом человека, которого можно проверить.

FAQPage требует оговорки. Google перестал показывать расширенные результаты по FAQ-разметке, и часть специалистов после этого сняла ее с сайтов. Ставить ее все равно стоит: формат вопрос-ответ модели разбирают охотно, а сами вопросы совпадают по формулировкам с тем, как люди пишут запросы ассистентам. Пока формат нужен хотя бы одному из двух каналов, его делают.

HowTo ставят на пошаговые инструкции. В отраслевых публикациях встречается наблюдение, что Perplexity цитирует страницы с HowTo втрое чаще обычных. Цифра пришла не из замера на собственных проектах, поэтому относиться к ней стоит как к ориентиру, а не как к обещанию.

Speakable размечает главную выжимку текста, VideoObject отдает моделям тайм-коды и описание ролика. Оба типа проходят по разряду эксперимента: подтверждений по ним меньше, чем по Organization, а работы столько же. Ставят их тогда, когда основные типы уже стоят и проверены.

Лишних типов не ставят. Разметка под форматы, которых на странице нет, дает работу без отдачи, а в худшем случае - расхождение с содержимым, которое движок посчитает попыткой обмануть.

sameAs и @id: как склеить разрозненное в одну сущность

Склейку делают в две стороны. Свойство `sameAs` связывает компанию с ее профилями за пределами сайта. Свойство `@id` связывает блоки разметки внутри одной страницы. Первое отвечает за то, чтобы вас не приняли за трех разных субъектов в интернете. Второе - за то, чтобы блоки кода на странице не читались как три независимых описания.

sameAs: собрать себя снаружи

Без `sameAs` сайт компании, ее страница в LinkedIn и профиль в соцсети выглядят для движка тремя отдельными организациями с похожими названиями. Свойство перечисляет адреса профилей и сообщает: это один и тот же субъект.

Профили в этом поле работают как поручители. Модель проверяет утверждение о компании по внешним источникам - примерно как человек, который перед сделкой спрашивает про подрядчика у знакомых. Сайт заявляет одно, LinkedIn показывает другое, в каталоге третье название - доверие к утверждению падает. При неуникальном названии `sameAs` снимает путаницу с однофамильцами и одноименными компаниями. Для агентства с распространенным словом в названии это первая по важности вещь после Organization.

В поле идут не только страницы в соцсетях. Ссылки на Wikidata и DBpedia указывают на сущности, которые движку уже известны: у них есть идентификаторы в графе знаний, и привязка к ним весит больше, чем еще один профиль. Рядом работает `knowsAbout` - поле, которое связывает компанию или автора с темами. Свойства `about`, `mentioned` и `alias` уточняют, что относится к сущности, а что нет. Часть из них Google напрямую не рекомендует, но на разбор они влияют.

Небольшой компании есть смысл собрать в `sameAs` то, что уже подтверждено: страницу в LinkedIn, профиль основателя, карточку в отраслевом каталоге, канал в мессенджере, аккаунт в соцсети с контентом. Профилей два или три - начинают с них, остальное добавляют по мере появления. Пустое поле лучше ссылки на заброшенный аккаунт с логотипом пятилетней давности.

Структура блока при этом не меняется, меняются только адреса.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://vash-sayt.com/#organization",
  "name": "Название компании",
  "url": "https://vash-sayt.com",
  "sameAs": [
    "https://www.linkedin.com/company/nazvanie-kompanii",
    "https://t.me/nazvanie_kompanii",
    "https://2gis.uz/tashkent/firm/00000000000000000",
    "https://www.wikidata.org/wiki/Q12345678"
  ],
  "knowsAbout": [
    "тема, в которой работаете",
    "вторая тема"
  ]
}
</script>

Последняя строка в `sameAs` - пример ссылки на Wikidata. Если у компании или основателя там есть карточка, ставят ее: у такой записи в графе знаний уже есть идентификатор, и привязка к нему стоит дороже, чем ссылка на свежесозданный профиль. Карточки нет - строку убирают, выдумывать номер бессмысленно.

Связь заявляет код, а доказывает ее подтвержденный профиль. Поэтому параллельно с разметкой аккаунты верифицируют в самих сервисах, а упоминания бренда набирают на внешних площадках: там сущность подтверждают со стороны.

@id: собрать себя внутри

На странице лежит несколько блоков разметки сразу: Organization, WebSite, Article, BreadcrumbList. Без явных связей движок читает их как отдельные описания. Организация сама по себе, статья сама по себе, и то, что статью выпустила эта компания, нигде не сказано.

Главной сущности присваивают `@id` - чаще адрес страницы с якорем вида `#organization`. Остальные блоки ссылаются на этот идентификатор через `publisher`, `author` или `about`.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://hitz.agency/#organization",
      "name": "HITZ Agency",
      "url": "https://hitz.agency"
    },
    {
      "@type": "WebSite",
      "@id": "https://hitz.agency/#website",
      "url": "https://hitz.agency",
      "name": "HITZ Agency",
      "publisher": {"@id": "https://hitz.agency/#organization"}
    }
  ]
}
</script>

Строка `publisher` здесь важнее всего остального. Без нее WebSite остается описанием сайта без владельца, а Article - текстом без издателя: два объекта на одной странице, между которыми движок связи не видит. С ней получается граф, где у сайта есть владелец, у статьи издатель и автор, а у автора профили.

Проверяют связи глазами по отчету валидатора: инструмент Schema.org показывает граф целиком, и сразу видно, висит блок отдельно или подцеплен к остальным. Если система управления сайтом вырезает скрипт из настроек страницы, разметку ставят прямо в тело - разбор со связями на примере нескольких страниц вынесен отдельно.

Сущности против ключевых слов

Сущность в понимании движка - человек, место, компания или предмет с машинным идентификатором. Движок присваивает идентификатор и накапливает вокруг него факты из разных источников. Цель работы с AI-выдачей формулируется через это: стать для модели узнаваемой сущностью с подтвержденными фактами, а не набором страниц с повторяющейся фразой.

Сведения в графе знаний хранятся тройками вида субъект - действие - объект. «HITZ Agency работает в Узбекистане», «HITZ Agency занимается GEO», «Марат Аксанов основал HITZ Agency» - такие утверждения движок складывает в граф и потом использует при сборке ответа. Текст, где нужная фраза встречается пятнадцать раз, но проверяемых утверждений нет, для машины пустой. Ключи он посчитает, а класть в граф ему нечего.

Движок хранит утверждения. Хранить количество вхождений фразы ему незачем.

На письме это выглядит как конкретика в названиях. «Google Keyword Planner показывает частотность запросов» работает лучше, чем «этот инструмент помогает с семантикой»: в первом варианте названы два объекта и связь между ними, во втором нет ни одного. Чем больше в тексте названных сущностей - продуктов, компаний, городов, людей, - тем больше материала для разбора.

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

В графе знаний Google порядка 500 млрд фактов о 5 млрд сущностей. Для текстов отсюда следуют две привычки. Первая: определять термины при первом употреблении, потому что модель не обязана знать вашу внутреннюю лексику. Вторая: держать одну терминологию по всему сайту. Если на одной странице стоит «GEO», на другой «оптимизация под нейросети», на третьей «AI SEO», для человека это синонимы, а для машины - три разные темы, между которыми связь еще надо доказать.

Как выглядит размытая сущность на практике, видно на примере двух B2B-платформ. Demandbase позиционирует себя как платформу с искусственным интеллектом. Модели описывают ее иначе - как ABM-платформу, а на вопрос про решения с AI называют конкурента, 6sense. Причина лежит в контенте: у Demandbase нет ни отдельного оффера под эту тему, ни раздела, где она раскрыта, ни материалов, где компания и тема упоминались бы вместе. Модель описывает компанию по тому, что нашла, а не по тому, как компания себя называет. Разметка такой разрыв не закроет - тут нужны страницы и упоминания.

Свой сайт проверяют похожим способом. Берете текст главной или страницы услуги, прогоняете через инструмент разбора контента и смотрите, какие сущности собираются вокруг бренда глазами машины. Темы, которую вы считаете своей, в этом наборе нет - значит, под нее на сайте нет ни оффера, ни раздела, ни текста, и никакая разметка ее туда не добавит.

Разметка и текст на странице работают вместе

Заголовки, списки и таблицы работают вместе с разметкой, а не вместо нее. Движок опирается на три вещи сразу: структурированные данные, качество содержимого и соответствие запросу. Слабый текст код не вытянет, потому что описывать в нем нечего.

Без блока вопросов на странице разметка FAQPage бессмысленна и читается движком как конфликт. Обратный случай проще: блок вопросов без кода машина разберет сама, если он оформлен по-человечески - вопрос заголовком, ответ первым абзацем под ним, без разгона на три абзаца.

Отсюда порядок работы. Сначала текст, потом его описание в коде. Как писать так, чтобы фрагменты забирали в ответы, - тема отдельная, и по очередности она идет раньше разметки.

Проверка и частые ошибки

Формат по умолчанию - JSON-LD: отдельный блок в коде страницы, не перемешанный с версткой. Микроданные встречаются в старых проектах, новые собирают на JSON-LD.

Проверяют двумя инструментами. Валидатор Schema.org ловит ошибки синтаксиса, несуществующие поля и показывает граф связей. Google Rich Results Test показывает, что из разметки Google готов использовать в выдаче. Инструменты ловят разное, поэтому прогоняют оба и сверяют отчеты.

Обновляют код вместе с содержимым страницы. Поменяли цену, часы работы или автора - поправили и разметку. Иначе разрыв копится незаметно, а всплывает через полгода, когда сайт отдает движку устаревшие факты. У Bing на этом построена отдельная механика: получив сигнал IndexNow, он сверяется со структурированными данными, чтобы понять, что на странице поменялось.

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

Часть систем ставит разметку сама. WordPress с SEO-плагином, Ghost, Webflow собирают Organization и Article без участия человека, а добавленный сверху ручной блок дает на странице два описания одной компании с разными полями. Перед внедрением открывают исходный код страницы и смотрят, что система выдает без вас. Дальше выбирают: либо чистят автогенерацию и ведут разметку руками, либо достраивают то, что система не умеет.

Перед работой полезно прогнать через Rich Results Test два-три сайта конкурентов из первой десятки и посмотреть, какие типы у них подтверждаются. Список того, что Google показывает сейчас, лежит в его галерее результатов поиска - сверяться стоит с ней, а не со статьями трехлетней давности.

Стоит смотреть, какие типы поисковики показывают сейчас. Типы, снятые с показа, оценивают по остаточной пользе: полезны моделям - оставляют, стоят ради галочки в отчете - убирают. Закрытым от индексации и служебным страницам разметка не нужна вовсе.

Сгенерировать разметку моделью можно, порог входа низкий. Результат проверяют валидатором и глазами: модели охотно придумывают поля, которых в словаре Schema.org нет, и подставляют факты, которых нет на сайте.

Ошибки, которые встречаются чаще остальных:

• блок Organization стоит на главной, а на страницах услуг его нет
• `dateModified` не заполнен или не обновляется годами
• название компании в разметке и в тексте написано по-разному
• `sameAs` ведет на профили, которых больше нет
• тип описывает содержимое, которого на странице нет
• система сгенерировала свой блок, а сверху добавили ручной - на странице два Organization
• блоки не связаны через `@id` и читаются по отдельности

Коротко

• Микроразметка сообщает машине, что на странице лежит. Позиции она не двигает, зато убирает догадки при разборе.
• Замеры дают разный результат по понятной причине: прозрачному сайту прирост маленький, запутанному заметный.
• Первый шаг - Organization по всему сайту. Второй - список подтвержденных профилей в `sameAs`.
• Без `@id` блоки на странице читаются вразнобой, со связями - как одно описание компании.
• Типы ставят под содержимое: Article для статей, FAQPage для вопросов, Product для товаров, HowTo для инструкций.
• Валидаторов два, и прогоняют оба. После правок текста разметку правят следом.

Частые вопросы

Влияет ли schema-разметка на цитирование в ChatGPT?

Прямых подтверждений нет. У Ahrefs после внедрения доля цитат в AI Overviews снизилась на 4,6%, а по ChatGPT замер сдвига не показал. Отчет по локальным компаниям говорит обратное: там у бизнеса с собранной разметкой цитат втрое больше. Противоречие снимается просто - выигрывают сайты, которые движок до этого разбирал с трудом.

Какие типы разметки ставить в первую очередь небольшому сайту?

Organization на всех страницах, WebSite на главной, ContactPoint и PostalAddress на контактах. Локальному бизнесу добавляют LocalBusiness: адрес, телефон, часы работы, зона обслуживания. Дальше по содержимому - Article на статьи, FAQPage на разделы с вопросами, Service на страницы услуг. Остальное подключают после того, как этот минимум прошел валидатор.

Что такое sameAs в schema и зачем оно нужно?

Свойство `sameAs` перечисляет адреса профилей компании или человека за пределами сайта: LinkedIn, соцсети, каталоги, страницы в Wikidata. Без него движок читает сайт и профили как разные субъекты с похожими названиями. С ним - собирает их в одну сущность и проверяет по этим источникам то, что сайт о себе заявляет. Профили при этом стоит верифицировать в самих сервисах.

Нужна ли FAQ-разметка, если Google перестал показывать по ней расширенные результаты?

Ставить стоит. Расширенные результаты по ней Google убрал, но модели разбирают пары вопрос-ответ охотно, а сами вопросы по формулировкам близки к тому, что люди пишут в чате. Одному из двух каналов формат нужен, и работа окупается. Условие одно: блок вопросов должен быть на странице, код без видимого содержимого дает конфликт.

Зачем в JSON-LD нужен @id и что будет без него?

`@id` - постоянный идентификатор сущности, адрес страницы с якорем вроде `#organization`. Через него один блок кода ссылается на другой: у статьи появляется издатель, у сайта владелец. Без идентификаторов Organization, WebSite и Article на одной странице выглядят тремя независимыми объектами, и связь между компанией и ее материалами движку приходится достраивать самому.

Чем проверить разметку после установки?

Валидатор Schema.org и Google Rich Results Test. Первый проверяет синтаксис, ищет поля вне словаря и рисует граф целиком. Второй отвечает на другой вопрос: что поисковик готов вывести в выдаче. Находки у них не совпадают, поэтому гоняют оба. Каждая правка текста тянет за собой новую проверку, иначе код и страница разъезжаются.