Проверка структурированных данных

Вторая копия страницы, написанная для машин

Покажите человеку страницу товара, и он сразу поймёт, где цена, а где остаток на складе. Программа видит просто текст. Структурированные данные избавляют её от догадок. Рядом с видимой страницей вы публикуете те же факты в виде размеченных полей, используя названия из общего словаря schema.org. Эта вещь является Product, её name такое-то, её offers содержат price 49.00 в USD.

Записать это можно тремя способами. JSON-LD помещает всё в один тег script, отдельно от вёрстки, и именно эту форму рекомендует Google. Микроданные и RDFa распределяют метки по HTML-тегам в виде атрибутов.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How tides work",
  "datePublished": "2026-03-14T09:30:00+00:00",
  "author": { "@type": "Person", "name": "Jane Doe" }
}
</script>

Поисковые системы используют эти поля, чтобы рисовать более богатые сниппеты: звёзды отзывов, цену, фото рецепта или дату события. Их называют расширенными результатами (rich results).

Что читает эта проверка

Наш сервер загружает страницу один раз, до 3 MB, и не выполняет её скрипты. Затем работа идёт в четыре шага.

1. Синтаксис. Каждый блок JSON-LD проходит через строгий JSON-парсер. На первой же ошибке он сообщает строку, символ и вероятную причину: запятая перед закрывающей скобкой, неэкранированная кавычка внутри текста, «умные» кавычки, вставленные из текстового редактора, HTML-комментарий, голый перевод строки. Одной ошибки достаточно, чтобы парсер отбросил весь блок.
2. Элементы. Списки @graph раскрываются, чтобы каждый элемент показывался отдельно, со своим типом и структурой свойств. Свойство, которое ссылается на другой элемент через @id, отслеживается, если цель есть на странице.
3. Свойства. Для типов, которые дают расширенный результат, элемент сравнивается со списком обязательных и рекомендуемых свойств из документации Google.
4. Значения. В каждом элементе адреса должны быть абсолютными, даты и длительности должны следовать ISO 8601, @context должен быть schema.org, а каждая ссылка @id должна куда-то вести.

Микроданные (itemscope, itemtype) и RDFa (typeof) подсчитываются и называются по типу. Их свойства не проверяются.

Какие типы мы сравниваем и что им нужно

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

Как исправить то, что показывает отчёт

Синтаксическая ошибка

Блоки, написанные вручную, ломаются на запятых и кавычках. Генерируйте блок JSON-кодировщиком (json_encode в PHP, JSON.stringify в JavaScript), и всё это семейство ошибок исчезнет. В CMS вставляйте JSON-LD в поле для кода. Никогда не используйте для этого визуальный редактор: он превращает кавычки в типографские.

Не хватает обязательного свойства

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

Относительный адрес

Пишите https://www.example.com/img/cover.jpg полностью, а не /img/cover.jpg.

Дата не в формате ISO 8601

Сначала год, затем T, затем время и смещение от UTC: 2026-03-14T09:30:00+00:00. Один только день, 2026-03-14, тоже допустим.

Ссылка в никуда

"author": {"@id": "…/#jane"} работает, только если элемент с точно таким @id есть на той же странице. Добавьте этот элемент или запишите автора прямо на месте.

Чего эта проверка не скажет

Она читает HTML в том виде, в каком он отдаётся. Структурированные данные, добавленные позже через JavaScript или менеджер тегов, здесь не видны, хотя Google может увидеть их после рендеринга. Изображения не загружаются, поэтому битая или слишком маленькая картинка останется незамеченной. Списки свойств охватывают распространённые типы результатов. Они не охватывают все типы и все необязательные поля.