Как проверить микроразметку сайта: типы Schema.org и ошибки JSON-LD

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

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

С чего начинается проблема

Одна страница нередко содержит несколько блоков разметки, созданных CMS, темой и отдельным модулем. В результате появляются две сущности Organization с разными адресами, повторяющиеся хлебные крошки или статья, у которой автор указан только в коде. Другая распространённая ситуация — шаблон технически корректен, но одинаково размечает разные страницы.

Ошибки удобно разделять на три уровня:

• Синтаксические: JSON нельзя разобрать из-за кавычки, запятой, комментария или неверной вложенности.
• Словарные: тип или свойство отсутствует в Schema.org либо используется не для той сущности.
• Содержательные: код валиден, но противоречит странице, скрывает важные условия или описывает сущность, которой в контенте нет.

Как выбрать тип Schema.org

Выбор начинают не с желаемого вида сниппета, а с основного назначения страницы. Тип должен описывать конкретную сущность, а не весь сайт «на всякий случай». Для одной страницы допустимо несколько связанных типов: например, Article, BreadcrumbList и сведения об издателе внутри статьи.

Не стоит подменять один формат другим. Open Graph управляет представлением ссылки в социальных интерфейсах, а Schema.org описывает сущности для машинной обработки. Эти наборы метаданных могут сосуществовать, но проверяются отдельно.

Диагностический алгоритм

1. Зафиксируйте проверяемый URL

Проверяйте публичный канонический адрес, а не фрагмент шаблона в CMS. Убедитесь, что страница доступна без авторизации, не перенаправляет на другой URL и отдаёт тот HTML, который должен получить робот. Если разметка добавляется JavaScript, сравните исходный и отрисованный документ.

2. Найдите все блоки структурированных данных

В исходном коде ищите application/ld+json, а также атрибуты itemscope, itemtype и itemprop, если применяются Microdata. Составьте список сущностей и отметьте, какой компонент добавляет каждую из них. Это помогает обнаружить дубли между темой и плагином.

3. Проверьте JSON как синтаксис

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

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Название видимой статьи",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.ru/article"
  }
}

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

4. Сопоставьте код с видимой страницей

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

5. Проверьте идентификаторы и связи

Для устойчивых сущностей полезен абсолютный @id, обычно URL с фрагментом: например, https://example.ru/#organization. Один и тот же объект должен иметь одинаковый идентификатор на связанных страницах. Поля со ссылками — url, image, logo, элементы хлебных крошек — лучше задавать абсолютными адресами.

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

6. Повторите проверку по шаблонам

Один корректный URL не подтверждает исправность всего сайта. Возьмите по несколько страниц каждого шаблона: публикации, категории, карточки, контакты. Добавьте крайние случаи — страницу без изображения, архивный материал и объект с неполным набором данных. Именно там чаще проявляются пустые строки, фиктивные значения и неверные типы.

Чек-лист проверяемых критериев

• На странице есть только обоснованные типы Schema.org.
• @context задан как https://schema.org, а названия типов и свойств написаны точно.
• JSON-LD разбирается без синтаксических ошибок.
• Обязательные для выбранного поискового сценария поля заполнены.
• Все значения подтверждаются видимым содержимым страницы.
• Даты имеют однозначный формат и, где требуется, часовой пояс.
• Цена является числом, а валюта передана отдельным стандартным кодом.
• URL абсолютные, открываются и не ведут через лишние перенаправления.
• Сущности не дублируются с конфликтующими свойствами.
• Разметка корректна на разных страницах одного шаблона.

Типовые ошибки JSON-LD

Неверная вложенность. Свойство author помещают рядом со статьёй как независимую строку либо передают объект без типа. Для вложенной сущности обычно нужен объект с собственным @type, именем и, при наличии, идентификатором.

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

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

Конфликт сущностей. Два блока описывают одну организацию, но используют разные названия, телефоны или URL. Объекты следует объединить либо связать единым @id, устранив расхождения в источнике данных.

Несоответствие каноническому адресу. mainEntityOfPage ссылается на тестовый домен, HTTP-версию или URL с метками. Ссылку необходимо сверять с фактическим canonical страницы.

Границы метода

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

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

Итог

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

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