Микроразметка и Schema.org для AI-видимости

Зачем разметка нужна именно ИИ

Когда нейросеть формирует ответ, она извлекает из страниц факты и сопоставляет их между источниками (подробно — в материале «Как нейросети формируют ответы»). Простой текст приходится «парсить» и угадывать смысл: где здесь название компании, где цена, а где просто число в абзаце. Микроразметка снимает эту неопределённость — она прямо сообщает: name — это название, price — это цена, FAQPage — это блок вопросов и ответов. Для модели это сигнал достоверности и удобный «контейнер», из которого легко вырезать готовый фрагмент в ответ или AI-сводку.

Разметка не гарантирует попадания в ответ, но снижает риск, что ИИ неправильно поймёт или проигнорирует факт. Это техническая страховка от искажений.

Важно: Schema.org — это не «секретный буст», а гигиена. Она помогает там, где контент уже сильный: даёт машине однозначно прочитать то, что человек и так видит. Размечать пустую или противоречивую страницу бессмысленно — сначала единый источник фактов, потом разметка.

Какие типы Schema.org важны

Для AI-видимости приоритетны несколько типов. Не нужно размечать всё подряд — нужно закрыть ключевые сущности.

Связывание сущностей через @id (когда Article ссылается на Organization как издателя, а Product — на бренд) помогает ИИ понять, что всё это один бренд. Это сближает разметку с логикой графа знаний — см. раздел про связь бренда как сущности в материале «Контент, который цитируют нейросети».

JSON-LD: как внедрять правильно

Schema.org можно описывать тремя синтаксисами — Microdata, RDFa и JSON-LD. Для современных сайтов рекомендуется JSON-LD: разметка лежит отдельным блоком <script type="application/ld+json"> и не вмешивается в вёрстку. Её проще поддерживать, генерировать на бэкенде и не сломать при редизайне.

Несколько технических правил:

• Данные в разметке = данные на странице. Размечать то, чего нет в видимом контенте, — нарушение и риск игнорирования.
• Один источник правды. Цена и условия в JSON-LD должны совпадать с тем, что видит пользователь и что лежит в единой базе фактов.
• Учитывайте рендеринг. Если разметку вставляет JavaScript, убедитесь, что краулеры видят итоговый DOM, а не пустую заготовку.
• Не дублируйте сущности. Один Organization на сайт, связанный по @id, а не повторённый по-разному на каждой странице.

Примеры разметки с кодом

Базовый блок Organization — ставится глобально и описывает бренд как сущность:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.ru/#org",
  "name": "Бренд",
  "url": "https://example.ru/",
  "logo": "https://example.ru/logo.png",
  "sameAs": [
    "https://t.me/brand",
    "https://vk.com/brand"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "sales",
    "availableLanguage": "Russian"
  }
}
</script>

Блок FAQPage — превращает вопросы и ответы в машинно-понятную структуру, которую ИИ легко вырезает в ответ:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Сколько стоит услуга?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Подписка от 120 000 ₽ в месяц, демо — бесплатно."
    }
  }]
}
</script>

Аналогично размечаются Product (с вложенным Offer — цена, валюта, наличие), Article (заголовок, автор, дата) и BreadcrumbList (позиции навигации). Главное — держать значения синхронными с видимым контентом.

8 частых ошибок разметки

1. Разметка не совпадает с контентом. В JSON-LD одна цена, на странице — другая. ИИ теряет доверие к источнику.
2. Размечено то, чего нет на странице. «Скрытая» разметка ради эффекта — прямое нарушение.
3. Дубли Organization. На каждой странице свой вариант имени/лого без единого @id.
4. Невалидный JSON. Лишняя запятая, незакрытая скобка — и весь блок игнорируется.
5. Разметка только в JS без рендеринга. Краулер видит пустой <script>.
6. Неправильные типы. price строкой с символом валюты вместо числа + отдельного priceCurrency.
7. Отсутствие связей. Article без publisher, Product без привязки к бренду.
8. Устаревшие данные. Разметку поставили один раз и забыли; цена/условия давно изменились.

Как проверить разметку

Проверка — обязательный этап, а не «по желанию». Базовый процесс:

• Валидаторы разметки. Schema Markup Validator и инструменты проверки расширенных результатов показывают, распознан ли тип и нет ли ошибок синтаксиса.
• Проверка отрендеренного DOM. Смотрите итоговый HTML после выполнения JS (через инструменты разработчика), а не только исходник.
• Сверка значений. Цена/условия в разметке = на странице = в единой базе фактов.
• Кросс-модельный замер после внедрения. Через несколько недель проверьте, изменилась ли точность фактов о бренде в ответах ИИ — это и есть практический критерий пользы. Стартовый срез даёт демо-аналитика.

Аудит-чек-лист готовности

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

Гарантирует ли разметка попадание в ответ ИИ?

Нет. Это техническая гигиена, которая снижает риск искажений и упрощает извлечение фактов. Попадание в ответ зависит ещё от качества контента, авторитетности и согласованности данных.

Какой синтаксис выбрать — JSON-LD или Microdata?

Для большинства сайтов JSON-LD: он отделён от вёрстки, проще поддерживается и не ломается при редизайне. Microdata оправдан реже, в основном на легаси-проектах.

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

Не «чем больше, тем лучше», а ровно те, что описывают ключевые сущности: организация, товары, FAQ, статьи, навигация. Разметка ради разметки пользы не даёт.

Что важнее — разметка или единый источник фактов?

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

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