Как проверить микроразметку: от ошибки в коде до страницы в поиске

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

Начните с цели: какие сведения и о какой сущности вы хотите передать. Например, Organization описывает организацию, BreadcrumbList — навигационную цепочку, Product — товар. Нельзя исправить выбор неподходящего типа простым добавлением полей, которые просит другой отчёт.

Подготовьте страницу и ожидаемые данные

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

Найдите блоки JSON-LD, Microdata или RDFa в исходном HTML и, если данные создаёт JavaScript, в отрендеренной странице. JSON-LD — формат связанных данных на основе JSON; он часто размещается в блоке script с типом application/ld+json. Наличие такого блока ещё не означает правильного содержания.

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

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

Инструмент	Что можно проверить	Чего результат не подтверждает
Schema.org Validator	Извлечение сущностей, структуру и использование словаря Schema.org	Выполнение всех правил конкретной функции Google или Яндекса
Google Rich Results Test	Поддерживаемые Google расширенные результаты и связанные ошибки	Поддержку всех типов Schema.org и обязательный показ в выдаче
Валидатор Яндекс Вебмастера	Распознавание переданных данных и сообщения проверки Яндекса	Выполнение всех дополнительных условий сервисов и будущий сниппет
Проверка URL в поисковой панели	Доступные сведения о проверенной или индексированной версии страницы	Мгновенное обновление поискового результата после исправления

Проверка фрагмента удобна до публикации: вы контролируете код и находите локальную ошибку. Проверка URL нужна после изменения шаблона: она показывает данные, которые инструмент смог получить со страницы. Эти режимы нельзя считать взаимозаменяемыми.

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

Учебный пример: одна запятая ломает извлечение

Условная организация называется «Север». Домен shop.example.test служит только обозначением вымышленного сайта и не предназначен для проверки публичного URL. Минимальный фрагмент ниже показывает диагностику формата; это не полный шаблон данных организации и не набор полей для гарантированного результата поиска.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Север",
  "url": "https://shop.example.test/"
}
</script>

Сначала можно проверить внутренний JSON обычным JSON-парсером, затем вставить весь HTML-фрагмент в режим проверки кода Schema.org Validator. В выполненной учебной проверке инструмент извлёк одну сущность Organization с name и url, без ошибок и предупреждений. Проверялись именно эти строки кода, а не существующий магазин.

Теперь удалим запятую между свойствами name и url:

"name": "Север"
"url": "https://shop.example.test/"

При проверке полного фрагмента с таким дефектом инструмент показал «Ничего не обнаружено» и одну ошибку в разделе «Прочие ошибки». Причина находится на уровне синтаксиса: свойства JSON не разделены запятой. Исправление — вернуть запятую после строки с названием, затем повторить тест того же фрагмента. Формулировки и расположение сообщений интерфейса могут меняться; ориентируйтесь на найденную причину и извлечённые поля.

Следующая проверка уже смысловая. Если в корректном коде оставить чужое название, JSON останется разбираемым. Валидность формата не доказывает, что организация действительно так называется. Поэтому после устранения синтаксиса сравните данные с подтверждёнными сведениями и видимым содержимым сайта.

Как пройти проверку опубликованного URL

После исправления шаблона откройте опубликованную страницу заново и передайте её URL в нужные инструменты. В Schema.org Validator проверьте извлечённый тип и значения. В Google Rich Results Test смотрите конкретную поддерживаемую функцию и её сообщения; если ожидаемый тип там не показан, сначала выясните, поддерживается ли он этим тестом и выбранной функцией.

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

Проверку Яндекса выполняйте отдельно. Успех Google не подтверждает требования другого поисковика, а распознанный граф Schema.org — требования всех его сервисов. Подробную настройку товарного типа объясняет статья о Product для интернет-магазина, навигационного — материал о хлебных крошках.

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

Где искать причину по результату проверки

Наблюдение	Следующая проверка	Что исправлять или фиксировать
Ошибка разбора, сущность не извлечена	Синтаксис и границы блока	Запятую, кавычки, повреждённый JSON или неверное размещение
Сущность есть, поле неизвестно или неуместно	Тип и свойство в словаре	Название свойства или модель данных, а не случайный новый тип
Данные корректны, но ожидаемой функции нет в тесте Google	Поддержку типа и правила функции	Различить ограничение теста и ошибку реализации
В коде и на странице разные сведения	Источник данных и обновление шаблона	Единую актуальную информацию, включая выбранный вариант
Фрагмент проходит, URL не читается	Доступ, ответ страницы и рендеринг	Проблему получения страницы, а не только JSON
Живой тест видит исправление, индексированная версия старая	Дату обхода и доступные данные панели	Переобход и последующую проверку версии
Ошибок нет, расширенного результата нет	Правила качества и пригодность функции	Оставшиеся ограничения; показ выбирает поисковая система

После публикации используйте доступные владельцу сайта инструменты Google Search Console и Яндекс Вебмастера. Уточняйте, смотрите ли вы живую проверку или данные последнего обхода. Исправление в браузере не означает, что поисковая система уже обработала новую версию.

При проблеме доступа проверьте ответ страницы и ограничения обхода. Основы описаны в статье о robots.txt. Повторная отправка на обход не исправляет закрытый доступ или недостоверное содержимое.

Что передать разработчику и как принять исправление

Задание «исправить микроразметку» слишком широко. Передайте минимальный воспроизводимый случай и уровень ошибки. Например, синтаксический дефект шаблона может затрагивать все страницы, а устаревшее значение — только отдельный источник данных.

URL и шаблон страницы:
Тип сущности и цель разметки:
Видимое и подтверждённое значение:
Фактически извлечённое значение или ошибка:
Инструмент, режим «код/URL», время проверки:
Минимальный фрагмент, воспроизводящий проблему:
Ожидаемое исправление в шаблоне или источнике:
Страницы и состояния для повторного теста:
Критерий приёмки и недоступные проверки:

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

Техническую задачу можно принять, когда нужные достоверные данные видны на странице, правильно извлекаются из опубликованного URL и не содержат ошибок применимой проверки. Если доступ к подтверждённому поисковому кабинету отсутствует, отметьте индексированную версию как отдельную незавершённую проверку. Условный код выше не проходил проверку реального домена, Google или Яндекса; его результат подтверждает только описанный тест синтаксиса и извлечения в Schema.org.

Чек-лист диагностики микроразметки

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