Чтобы проверить структурированные данные, протестируйте разметку в валидаторе, сопоставьте её содержимое с видимым контентом страницы, а после публикации проверьте обработку URL и отчёты поисковой системы. Одного сообщения «ошибок нет» недостаточно: код может быть синтаксически корректным, но не соответствовать типу страницы или требованиям расширенного результата.
Ниже — последовательный чек-лист для проверки JSON-LD, Microdata и RDFa. Он поможет определить, распознаётся ли разметка, какие поля заполнены неправильно, видит ли её поисковый робот и сохранилась ли она после рендеринга страницы.
Что именно нужно проверить в структурированных данных
Структурированные данные — это машиночитаемое описание сущностей и содержания страницы по словарю Schema.org или другому поддерживаемому формату. Разметка помогает поисковой системе понять, что на странице представлены товар, организация, статья, рецепт, вакансия, событие или другая сущность.
Полноценная проверка включает несколько уровней:
- Синтаксис. В коде нет незакрытых кавычек, пропущенных запятых, неверной вложенности и других технических ошибок.
- Распознавание типа. Валидатор определяет заявленный тип сущности и её свойства.
- Обязательные и рекомендуемые поля. Заполнены свойства, необходимые для выбранного типа расширенного результата.
- Соответствие странице. Значения в разметке подтверждаются видимым пользователю контентом.
- Доступность для робота. Код присутствует в HTML или появляется после рендеринга и не скрыт из-за технической ошибки.
- Обработка поисковой системой. Опубликованный URL доступен для сканирования и отображается в профильных отчётах.
Валидная разметка не гарантирует расширенный сниппет. Поисковая система самостоятельно решает, использовать ли структурированные данные в выдаче, с учётом качества страницы, запроса, устройства, региона и других факторов.
Какие инструменты использовать для проверки
Разные инструменты отвечают на разные вопросы. Для надёжной диагностики желательно не ограничиваться одним тестом.
| Инструмент | Что показывает | Когда использовать |
|---|---|---|
| Google Rich Results Test | Определяет типы расширенных результатов, ошибки и предупреждения по поддерживаемой Google разметке | До публикации и после неё |
| Schema Markup Validator | Проверяет сущности и свойства по словарю Schema.org, включая типы, не связанные с расширенными результатами Google | Для контроля структуры и вложенности |
| Google Search Console | Показывает обработку опубликованных страниц, проблемы улучшений и примеры URL | После обхода страниц поисковым роботом |
| Проверка URL в Search Console | Позволяет сравнить индексированную и актуальную версии, проверить доступность страницы и отрендеренный HTML | При расхождении валидатора и отчётов |
| Исходный код и инструменты разработчика | Помогают выяснить, где находится разметка и появляется ли она после выполнения JavaScript | При динамической генерации данных |
Rich Results Test проверяет возможность использования поддерживаемых расширенных результатов, а Schema Markup Validator — корректность словаря и связей между сущностями. Поэтому ситуация, когда один инструмент показывает объект, а другой не считает его расширенным результатом, не всегда означает ошибку.
Как проверить структурированные данные: пошаговый чек-лист
- Определите назначение разметки. Зафиксируйте, какую сущность описывает страница и какой результат ожидается. Карточке товара обычно нужен тип Product, публикации — Article или более конкретный подтип, странице организации — Organization. Тип должен соответствовать основному содержанию, а не желаемому виду сниппета.
- Выберите способ тестирования. Если страница уже опубликована, вставьте её URL в валидатор. Для ещё не выпущенного шаблона используйте проверку кода. Тест кода удобен на этапе разработки, но не выявляет ограничения доступа к реальной странице.
- Проверьте загрузку страницы. При тестировании URL убедитесь, что сервис смог получить документ. Коды ответа 4xx или 5xx, обязательная авторизация, блокировка роботов и сетевые ошибки делают результат неполным.
- Изучите найденные сущности. Валидатор должен распознать ожидаемый тип. Если нужной сущности нет, проверьте наличие блока JSON-LD, атрибутов Microdata или RDFa, правильность MIME-типа и отсутствие повреждения кода шаблонизатором.
- Устраните критические ошибки. Откройте каждое сообщение, найдите указанное свойство и исправьте формат, значение либо вложенность. После изменения запустите тест заново, а не ориентируйтесь только на редактор кода.
- Разберите предупреждения. Рекомендуемые поля не всегда обязательны, но могут влиять на полноту описания. Добавляйте свойства только при наличии достоверных данных на странице.
- Сверьте разметку с видимым контентом. Название, автор, цена, валюта, наличие, рейтинг, даты и другие значимые сведения не должны противоречить тексту и интерфейсу страницы.
- Проверьте связи объектов. Убедитесь, что автор связан со статьёй, предложение — с товаром, адрес — с организацией. Для идентификации одной сущности в нескольких блоках полезно использовать согласованные значения @id.
- Протестируйте опубликованный URL. После релиза проверьте не фрагмент кода, а реальную страницу. Системы управления контентом, плагины, кеширование и JavaScript могут изменить или продублировать разметку.
- Проверьте страницу в Search Console. После доступности URL для обхода изучите данные об индексировании и профильные отчёты улучшений. Если поисковая система видит старую версию, при необходимости запросите повторный обход.
Проверять следует не только одну эталонную страницу. Для шаблонной разметки выберите несколько URL: с полным и минимальным набором данных, отсутствующим изображением, нулевой ценой, несколькими предложениями, архивным статусом или другими допустимыми сценариями проекта.
Как разбирать ошибки и предупреждения валидатора
Ошибка обычно означает, что сущность не отвечает обязательному условию инструмента или отдельное значение невозможно обработать. Причиной может быть отсутствующее поле, неподходящий тип данных, неверная вложенность или синтаксическая проблема.
Предупреждение сообщает о рекомендуемом свойстве или потенциально неполном описании. Страница может оставаться допустимой, однако предупреждение стоит оценить по смыслу. Не следует добавлять фиктивный рейтинг, автора, цену или изображение только ради зелёного статуса.
При диагностике удобно двигаться от общего к частному:
- сначала устранить ошибки JSON, Microdata или RDFa, из-за которых не читается весь блок;
- затем проверить тип главной сущности и обязательные свойства;
- после этого исправить форматы отдельных значений;
- в конце оценить рекомендуемые поля и качество описания.
Особое внимание требуется значениям со строгим форматом. Даты должны передаваться в машиночитаемом виде, URL — быть корректными и доступными, числовые свойства — не содержать лишний текст, а значения из перечислений — соответствовать ожидаемому словарю. Конкретные требования зависят от типа сущности и поисковой функции.
Если сообщение указывает на вложенный объект, исправлять нужно не только отмеченную строку. Например, проблема в Offer может быть связана с тем, что объект предложения вложен не в Product, содержит неправильную валюту или не имеет требуемого свойства. Контекст сущности важнее номера строки.
Типичные ошибки структурированной разметки
Разметка не соответствует содержанию страницы
Нельзя описывать товар на странице списка, если пользователь не видит полноценную информацию о конкретном товаре. Аналогично не стоит размечать обычный рекламный текст как отзыв или вопрос с ответом как пользовательский форум. Тип сущности выбирают по фактическому назначению страницы.
Данные в коде и интерфейсе расходятся
Цена в разметке должна совпадать с актуальной ценой на странице, а статус наличия — с возможностью заказа. Расхождения часто появляются из-за разных источников данных, задержек кеша или обновления только одного компонента шаблона.
На странице присутствуют дублирующиеся блоки
Разметку могут одновременно добавлять тема, SEO-модуль, товарный плагин и самописный шаблон. В результате появляются два объекта Product или Article с разными значениями. Нужно определить единый источник и удалить лишние блоки либо корректно связать сущности.
Неправильно задана вложенность
Свойство должно находиться внутри подходящей сущности. Например, данные предложения относятся к Offer, а Offer связывается с Product. Формально существующие поля не принесут пользы, если между объектами нарушены отношения.
Разметка генерируется только после действия пользователя
Если JSON-LD появляется после клика, прокрутки, выбора региона или другого события, поисковый робот может не получить блок при первоначальном рендеринге. Значимые структурированные данные лучше выводить при обычной загрузке страницы и обновлять синхронно с контентом.
Шаблон создаёт пустые или фиктивные значения
Поля с пустыми строками, заглушками, несуществующими изображениями и техническими названиями ухудшают качество разметки. Если достоверного значения нет и свойство не обязательно, поле лучше не выводить. Если свойство обязательно, нужно скорректировать данные страницы или отказаться от неподходящего типа разметки.
Что проверить после публикации
Успешный тест перед релизом подтверждает корректность кода, но не завершает проверку. На рабочем сайте могут действовать другие шаблоны, настройки кеширования, правила доступа и версии скриптов.
- Откройте опубликованный URL в тесте расширенных результатов.
- Сравните найденные значения с фактическими данными страницы.
- Проверьте HTTP-статус, canonical, запрет индексации и доступность ресурсов, необходимых для рендеринга.
- Убедитесь, что разметка присутствует в исходном или отрендеренном HTML.
- Проверьте несколько страниц каждого шаблона, а не только URL, на котором велась разработка.
- После обхода изучите динамику ошибок в Search Console и примеры затронутых страниц.
- Повторите проверку после изменений дизайна, CMS, модулей, каталога или источников данных.
Отсутствие отдельного отчёта в Search Console не доказывает, что код не читается. Отчёты доступны не для всех типов Schema.org и формируются только при наличии соответствующих данных. В такой ситуации ориентируйтесь на валидатор, проверку URL и фактический HTML.
Если ошибка затрагивает большое число страниц, сначала исправьте шаблон и протестируйте разные сценарии. Функцию подтверждения исправления в Search Console следует запускать после публикации изменений на всех или большинстве затронутых URL, иначе проверка может снова обнаружить проблему.
Частые вопросы
Как понять, что структурированные данные работают?
Валидатор распознаёт нужную сущность без критических ошибок, данные совпадают с контентом, а опубликованная страница доступна поисковому роботу. Появление расширенного результата не является обязательным подтверждением работы разметки.
Можно ли проверить структурированные данные до публикации?
Да. Код JSON-LD или HTML-фрагмент можно вставить в валидатор. После публикации необходимо отдельно протестировать URL, потому что рабочий шаблон и рендеринг могут изменить результат.
Почему валидатор Schema.org не показывает ошибок, а Google показывает?
Schema.org описывает словарь и допустимые связи, а Google предъявляет дополнительные требования к конкретным расширенным результатам. Код может быть корректен по словарю, но не содержать обязательных для поисковой функции свойств.
Нужно ли исправлять все предупреждения?
Нет. Предупреждения оценивают по доступности и достоверности данных. Рекомендуемое поле стоит добавить, если значение реально существует и подтверждается страницей. Выдумывать сведения ради прохождения теста нельзя.
Почему после исправления ошибка остаётся в Search Console?
Search Console может показывать данные последнего обхода. Убедитесь, что исправление доступно на рабочем URL, очистите кеш при необходимости и дождитесь повторного сканирования либо запросите проверку обновлённой страницы.
Как часто нужно проверять разметку?
Проверка нужна при внедрении, после изменений шаблона или CMS, при обновлении источников данных и при появлении новых ошибок в Search Console. Для крупных сайтов полезен регулярный автоматизированный контроль выборки URL.
Когда нужна комплексная техническая проверка
Отдельный валидатор не выявит все причины, по которым поисковая система не использует разметку. Проблема может находиться в индексации, canonical, дублировании страниц, JavaScript-рендеринге, качестве шаблона или несогласованности источников данных.
Если ошибки охватывают разные типы страниц или возвращаются после исправлений, разметку стоит проверять вместе с другими техническими факторами. В рамках SEO-продвижения сайта можно связать диагностику структурированных данных с аудитом индексации, шаблонов и технических ограничений, а затем определить приоритеты доработок.
