Формат на основе JSON для связанных структурированных данных. Его обычно встраивают в элемент script, чтобы страница описывала сущности и связи, не меняя видимый HTML.
Решение и его границы
JSON-LD — способ записать связанные данные в JSON. На веб-страницах его часто встраивают в элемент script и используют словарь Schema.org, чтобы описать сущности, которые видит читатель: статью, товар, организацию, хлебные крошки или событие. Это формат представления, а не обещание расширенного результата. Граф должен быть синтаксически корректным и соответствовать видимым и актуальным фактам страницы.
Что проверять
Соберите HTML после рендеринга, а не предполагайте, что исходный шаблон дошёл до продакшена без изменений. Разберите JSON-LD, найдите каждый узел и его идентификаторы, сравните важные свойства с видимой страницей. Проверьте, что URL ведут на рабочие ресурсы, ссылки указывают на нужные сущности, а даты, цены, наличие, автор и изображение не устарели. Предупреждения валидатора оценивайте в контексте: сообщение валидатора — повод проверить, а не дефект по умолчанию.
Практический путь внедрения
Выберите самый маленький подходящий тип Schema.org, сначала опишите главную сущность и добавляйте связанные сущности только тогда, когда страница показывает их факты. По возможности берите значения из того же структурированного источника, что и видимый шаблон. После релиза проверьте репрезентативную отрисованную страницу, а для шаблонов, которые создают много страниц, добавьте регрессионные проверки. Проверки sitemap, canonical и robots ведите отдельно от валидации JSON-LD.
Ошибки и границы замеров
Главная опасность — «schema theater», то есть разметка ради вида: добавлять словарь, который страница не поддерживает, в надежде пробить функцию поиска. Скрытые, выдуманные или противоречивые свойства создают риск поддержки и делают граф менее надёжным. Сначала я проверяю разметку по видимой странице, потом изучаю граф. Исправляю реальные ошибки словаря или ссылок, а не то, что просто убирает сообщение валидатора.
Пример реализации. Для редакционной статьи начните с видимой записи: заголовок, автор, дата публикации, главное изображение, канонический URL и издатель. Опишите статью в JSON-LD на основе тех же полей контента, которые выводят страницу. Задайте статье один стабильный идентификатор, а издателя и изображение связывайте только тогда, когда эти сущности реальны и доступны по своим адресам. Если автора, даты или изображения нет на видимой странице, не добавляйте их в граф ради валидатора.
Критерии проверки. После выкладки получите HTML после рендеринга, извлеките каждый блок JSON-LD и разберите каждый граф. Сравните заголовок, дату, изображение, URL и автора с тем, что видит человек на странице. Убедитесь, что идентификаторы и URL ведут к нужным ресурсам, а статья случайно не описывает другую сущность шаблона. Запустите подходящий тест структурированных данных, но разделяйте находки: ошибка разбора, несовпадение словаря, пропущенная необязательная рекомендация и заметка о соответствии требованиям функции поиска — это разные вещи.
Частые ошибки. Не вставляйте один и тот же общий блок разметки на все страницы и не делайте услугу, категорию и товар одной и той же главной сущностью. Не используйте JSON-LD, чтобы скрыть цены, рейтинги, наличие, отзывы или авторов, которых пользователь не видит. Тест расширенных результатов не проверит canonical, robots, sitemap и достоверность контента, поэтому эти проверки тоже должны быть в чек-листе перед релизом. JSON-LD помогает описать страницу, но не компенсирует недоступную или бесполезную страницу.