Структурированные данные Schema.org для ИИ

Что это и зачем

Schema.org задаёт общий словарь типов и свойств для описания сущностей на веб-странице. Разметка может быть опубликована в JSON-LD, Microdata или RDFa; наличие нескольких форматов одновременно само по себе не делает страницу лучше.

Для AI Readiness ценность разметки в том, что название сущности, её тип, свойства и связи доступны в явной структуре, а не только подразумеваются из визуального текста. Это уменьшает неоднозначность машинного чтения, но не является гарантией использования данных конкретной ИИ-системой.

Что проверяет AI Web Check

Проверка ищет читаемую Schema.org-разметку в поддерживаемых форматах и отдельно показывает обнаруженные JSON-LD, Microdata и RDFa. Основной критерий считается выполненным, когда на странице есть хотя бы один пригодный машиночитаемый формат.

Сервис не требует дублировать одну сущность во всех форматах и не загружает удалённые JSON-LD contexts. Проверяется техническая читаемость и базовая структура, а не полный бизнес-смысл каждой схемы.

Минимальный практический пример

JSON-LD удобен тем, что отделяет машиночитаемое описание от HTML-разметки. Важно, чтобы значения соответствовали реально видимому содержимому страницы и не описывали несуществующие свойства.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Руководство по Schema.org",
  "description": "Практическая страница о машиночитаемой разметке",
  "url": "https://example.com/guides/schema"
}
</script>

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

Не ограничивайтесь проверкой наличия тега script. Сначала сохраните исходный HTML, затем убедитесь, что нужный блок действительно присутствует в серверном ответе, и только после этого разбирайте JSON и сопоставляйте значения с видимым содержимым страницы. Так легче отделить проблему доставки HTML от ошибки самой разметки.

Минимальная ручная проверка ниже не заменяет валидатор Schema.org, но помогает воспроизвести факт: разметка присутствует в исходном документе именно по проверяемому URL. Если блок создаётся только клиентским JavaScript, это уже другой диагностический сценарий.

curl -fsSL https://example.com/page -o page.html
grep -n 'application/ld+json' page.html

Три разных сбоя — три разных действия

Например, запятая после последнего свойства делает JSON недопустимым, хотя тег JSON-LD присутствует. После исправления синтаксиса результат становится воспроизводимо отличим от ситуации, когда разметки нет совсем.

• Поддерживаемой Schema.org-разметки нет вообще: добавьте один подходящий формат для реальной сущности страницы. JSON-LD, Microdata и RDFa — альтернативы; публиковать все три не требуется.
• JSON-LD найден, но JSON синтаксически повреждён: сначала исправьте JSON-синтаксис. Добавление новых типов и свойств до этого не делает блок читаемым.
• Разметка читается, но расходится с видимым содержимым: сравните имя сущности, URL и проверяемые свойства с тем, что действительно опубликовано для пользователя. Для товарных страниц отдельные однозначные поля можно проверять ещё строже.

До:    { "@context": "https://schema.org", "@type": "WebPage", }
После: { "@context": "https://schema.org", "@type": "WebPage" }

Типичные ошибки

• JSON-LD синтаксически повреждён или обрывается.
• Тип сущности не соответствует содержимому страницы.
• Разметка содержит данные, которых пользователь не видит и которые нельзя подтвердить страницей.
• Несколько форматов описывают одну сущность противоречиво.
• Разработчик добавляет разметку ради самого факта наличия Schema.org, а не ради точного описания сущностей.

Как исправлять

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

Не используйте Schema.org как скрытый второй текст страницы. Машиночитаемое представление должно уточнять структуру уже существующего контента, а не создавать альтернативную реальность для роботов.