Проверить микроразметку - значит ответить на два отдельных вопроса. Первый: корректен ли синтаксис и соответствует ли структура словарю Schema.org, то есть сможет ли поисковик вообще прочитать блок JSON-LD. Второй: поддерживает ли конкретная поисковая система этот тип разметки и способна ли собрать из него расширенный результат. Один валидатор не закроет оба вопроса, поэтому на практике работают с набором инструментов.
Рабочий порядок выглядит так. Сначала убеждаемся, что страница доступна и попадает в индекс. Затем проверяем словарь и синтаксис через Schema Markup Validator или официальный валидатор Schema.org. После этого смотрим применимость разметки для расширенного результата: Google Rich Results Test для Google и отчёты Яндекс.Вебмастера для Яндекса. Если проверять разметку на странице, которой нет в индексе, выводы будут ложными, а время потрачено зря.
Зачем вообще проверять микроразметку и что именно мы проверяем
Микроразметка входит в блок технического аудита, который идёт после проверки доступности и индексации. В одном чек-листе с ней стоят метатеги и то, как сайт выглядит в выдаче: сначала фиксируют доступность сайта, потом индекс, и только затем переходят к метатегам, микроразметке и виду в выдаче. Технический SEO-аудит: 7 ошибок, которые мешают продвижению описывает именно такую последовательность по приоритету.
Проверка нужна по трём причинам. Сломанный JSON-LD поисковик просто не прочитает, и разметка не сработает. Разметка с ошибкой в словаре не даст расширенного результата даже там, где он поддерживается. А расхождения между валидаторами легко принять за реальную проблему и потратить день на правку того, что и так работает.
Два уровня проверки: словарь и поисковая система
Schema Markup Validator и официальный валидатор Schema.org отвечают на вопрос «правильно ли написана разметка». Они проверяют синтаксис и соответствие словарю: корректны ли типы, свойства, вложенность. Про требования Google или Яндекса к расширенным результатам они не знают ничего.
Google Rich Results Test и отчёты Яндекс.Вебмастера отвечают на другой вопрос: соберёт ли конкретная поисковая система расширенный результат из этой разметки. Здесь важны поддерживаемые типы и обязательные поля, которые поисковик устанавливает сам.
Простой пример. Разметка Product может быть безупречной по словарю Schema.org, но не дать расширенного результата в текущей конфигурации Google, если для нужного подтипа не хватает обязательных по версии поисковика полей. Словарный валидатор такое не покажет, а Rich Results Test покажет. Наборы поддерживаемых типов меняются, поэтому их сверяют в актуальной документации поисковой системы, а не по памяти.
Когда проверка разметки бессмысленна
Если до страницы не достучаться (код ответа 403 или закрытие в robots.txt), в индекс она нормально не попадёт, и проверять на ней разметку рано. Сначала устраняют причину недоступности. Дальше проверяют индексацию: какие нужные страницы не попали в индекс и какие лишние туда попали. Микроразметка идёт в чек-листе уже после этого. Источник, на который здесь опираемся, отдельно подчёркивает этот порядок. Чек-лист технического аудита с такой последовательностью позволяет не проверять разметку вслепую.
Чтобы быстро оценить масштаб проблемы с индексацией до работы с разметкой, пригодится разбор типичных причин, по которым страницы не попадают в индекс. Проверка индексации: как выявить и исправить невидимые для поиска страницы даёт пошаговый план аудита и помогает отсеять случаи, где дело не в разметке.
Валидатор микроразметки Яндекс.Вебмастера: что он показывает
Яндекс.Вебмастер - панель, где по проиндексированным страницам видно состояние разметки и появляются новые параметры проверок. Практическая ценность в масштабе: панель показывает картину по сайту, а не по одной вставленной в валидатор странице. Ограничение тоже понятное: для отладки конкретного блока JSON-LD панель не подходит, её отчёты строятся по проиндексированным URL и не заменяют ручную проверку кода.
Яндекс и Google поддерживают разные наборы типов разметки и по-разному формулируют требования к обязательным полям. Выводы одного поисковика нельзя механически переносить на другой: то, что прошло у Google, у Яндекса может не дать расширенного результата, и наоборот.
Как посмотреть статус разметки на проиндексированных страницах
Логика такая. Сайт добавляют в панель, дожидаются индексации страниц, затем открывают раздел с отчётами по разметке и сверяют список типов и ошибок с тем, что реально размечено на сайте. Свежеопубликованный URL появится в отчёте не сразу, потому что отчёт строится по проиндексированным страницам.
Если по странице данных нет, это не ошибка разметки. Это вопрос индексации: страница либо ещё не обойдена, либо закрыта от обхода. Проверяем код ответа, robots.txt, canonical и наличие URL в индексе, и только потом возвращаемся к разметке.
Что делать с новыми параметрами в панели
Панели вебмастеров обновляются. Когда в Яндекс.Вебмастере появляется новый параметр, его стоит добавить в свой чек-лист аудита, чтобы проверка оставалась воспроизводимой и не зависела от памяти специалиста. В рабочем чек-листе полезно вести поля: наличие проблемы, дата проверки, подсказки, описание фактора, цветовое выделение блоков, приоритет, ответственный и статус решения. Пример ведения такого чек-листа показывает, зачем нужны все эти поля сразу.
Google Rich Results Test: проверка на возможность расширенного результата
Rich Results Test показывает, может ли Google сформировать расширенный результат из разметки на странице. Он проверяет синтаксис и применимость типа разметки к поддерживаемым rich results. Из этого следует важный вывод: отсутствие ошибок в Rich Results Test не доказывает, что разметка корректна по словарю Schema.org, и наоборот. Два разных уровня, две разные проверки.
Список поддерживаемых типов и требования к обязательным полям Google периодически меняет. Сверяйте их в актуальной документации Google, а не по статье годичной давности: разметка, которая работала раньше, может перестать давать расширенный результат без единой ошибки в коде.
Проверка по URL и по коду: когда что использовать
Режим по URL проверяет то, что реально отдаёт сервер: учитываются доступность страницы и то, как она рендерится. Этот режим ближе к реальности, потому что показывает страницу глазами робота.
Режим по коду проверяет фрагмент JSON-LD до публикации. Он удобен для отладки: вставляете блок, правите, проверяете, не трогая сайт.
Результаты двух режимов могут расходиться. Типичная причина: разметка добавляется скриптом и не попадает в отрендеренный HTML, который видит проверка по URL. Тогда по коду всё чисто, а по URL разметки нет. Если это ваш случай, сначала добейтесь, чтобы разметка присутствовала в HTML, который отдаёт сервер, и только потом ищите ошибки в самом JSON-LD.
Schema Markup Validator и официальный валидатор Schema.org: проверка словаря
Schema Markup Validator проверяет синтаксис и соответствие словарю Schema.org. Он работает с JSON-LD, Microdata и RDFa, поэтому подходит и для тех случаев, когда разметка размечена прямо в HTML, а не отдельным блоком скрипта.
Официальный валидатор Schema.org используют как эталон при проверке корректности самого словаря и синтаксиса. Когда нужно понять, правильно ли вы выбрали тип и свойства без оглядки на требования поисковиков, это основной ориентир.
Оба инструмента не знают о требованиях конкретных поисковых систем к расширенным результатам. Зелёный результат здесь - необходимое условие, но не достаточное: он говорит, что разметку можно прочитать, и ничего не говорит о том, покажет ли поисковик расширенный сниппет.
Что считается ошибкой, а что - предупреждением
Критичные ошибки ломают парсинг. К ним относятся невалидный JSON, лишние запятые, незакрытые кавычки и скобки, некорректное экранирование символов. Пока это не исправлено, разметка не читается вообще, и обсуждать расширенные результаты бессмысленно.
Предупреждения касаются необязательных полей. Словарь рекомендует свойство, но не требует его. Отсутствие такого поля не мешает прочитать разметку. Решение добавлять его или нет зависит от цели: если поле влияет на формирование расширенного результата в вашей поисковой системе, его стоит добавить; если нет, можно оставить как есть.
Правило простое: сначала устраняем всё, что ломает парсинг, потом решаем, добавлять ли необязательные поля под конкретную поисковую систему. Не стоит добавлять свойства на всякий случай: разметка раздувается, а поддерживать её становится сложнее.
Почему результаты проверок расходятся и какому источнику верить
Расхождения между валидаторами - норма, а не признак поломки. Причины у них разные, и почти всегда понятно, почему один инструмент говорит «ок», а второй молчит.
- Разные наборы поддерживаемых типов у Яндекса и Google.
- Разные версии словаря Schema.org, на которые ориентируются валидаторы: словарь развивается, и поддержка типов приходит с задержкой.
- Разный рендеринг: разметка, добавленная JavaScript, может не попасть в проверку по URL, хотя в исходном коде она есть.
- Разные требования к обязательным полям для конкретных rich results у поисковой системы, которых нет в словаре.
Правило приоритета в спорной ситуации
Алгоритм такой. Сначала убеждаемся, что JSON-LD парсится: официальный валидатор Schema.org и Schema Markup Validator. Затем проверяем, поддерживается ли тип разметки в целевой поисковой системе: Rich Results Test для Google, отчёты Яндекс.Вебмастера для Яндекса. Если инструменты расходятся по необязательным полям, ориентируемся на требования той поисковой системы, для которой размечена страница.
В спорной ситуации источник истины - тот, чьи требования вы пытаетесь выполнить. Если вы оптимизируете страницу под Google, решающим будет вердикт инструментов Google, даже когда словарный валидатор показывает предупреждение. Если под Яндекс, решающими будут отчёты Яндекс.Вебмастера и его документация.
Типичные причины ложных расхождений
Часть расхождений вызвана не разметкой, а способом проверки. Разметка добавлена через JavaScript и не видна при проверке по URL: отдавайте разметку на сервере или уберите динамику. Страница отдаёт 403 или закрыта в robots.txt: сначала откройте доступ, потом проверяйте. Страница ещё не проиндексирована: отчёты панели по ней пусты, дождитесь обхода. Валидатор показывает закэшированную версию: перепроверьте после обновления кэша или по коду.
Панель вебмастера строит отчёт по проиндексированным страницам, поэтому свежие правки в разметке там видны не сразу. Отсутствие данных и наличие ошибки - разные вещи, и путать их не нужно.
Пошаговый разбор типичных ошибок: от предупреждений до критичного JSON-LD
Когда ошибки уже видны в отчёте, помогает фиксированная последовательность. Сначала фиксируем проблему в чек-листе: наличие проблемы, дата проверки, описание фактора, приоритет, ответственный, статус. Затем классифицируем причину: синтаксис, словарь или требования поисковой системы. Дальше исправляем критичное, затем предупреждения. Перепроверяем тем же инструментом, который нашёл ошибку. После публикации смотрим результат в панели вебмастера на проиндексированной странице.
Одно важное правило: не меняйте сразу несколько вещей. Иначе непонятно, что именно помогло и не сломало ли что-то ещё.
Критичные ошибки синтаксиса JSON-LD
Частые причины, по которым блок не парсится:
- невалидный JSON: лишние запятые, одинарные кавычки вместо двойных, незакрытые скобки;
- ошибка внутри тега script с типом application/ld+json;
- конфликт нескольких блоков JSON-LD на странице, из-за которого данные перекрывают друг друга;
- некорректное экранирование спецсимволов в строках.
Порядок действий: скопируйте блок в валидатор в режиме проверки по коду, изолируйте проблемный фрагмент, исправьте, верните на страницу. Не правьте весь блок целиком, если можно сузить поиск до одной строки.
Предупреждения о необязательных полях
Предупреждение означает, что словарь рекомендует поле, но не требует его. Прежде чем бежать добавлять свойство, ответьте на вопрос: влияет ли оно на то, как нужная вам поисковая система формирует расширенный результат. Если влияет, поле стоит добавить. Если нет, тратить время смысла мало. Раздутая разметка сложнее в поддержке, и ошибки в ней появляются чаще.
Ошибки, связанные с требованиями конкретной поисковой системы
Бывает так: словарный валидатор молчит, а Rich Results Test показывает ошибку. Это не противоречие. Поисковая система может требовать обязательные поля для конкретного типа rich result, которых нет в словаре Schema.org. В этом случае источник истины - документация поисковой системы, а не словарный валидатор.
Логика простая: сначала проверяем словарь, потом требования поисковика. Уровни не смешиваем: ошибка словаря чинится правкой типов и свойств, ошибка поисковика - добавлением полей, которые он требует.
Проверка разметки на уже проиндексированных страницах
Панели вебмастеров показывают состояние разметки по проиндексированным страницам. Это единственный способ увидеть картину в масштабе, а не по одной странице, вставленной в валидатор. Порядок: убедиться, что страницы в индексе; открыть отчёты по разметке в панели; сверить типы разметки и ошибки; для проблемных URL сделать точечную проверку через валидаторы. Ограничение то же: панель не заменяет валидатор для отладки конкретного JSON-LD.
Что делать, если страница не в индексе
Проверка разметки на такой странице не даст результата до устранения причины. Порядок аудита не меняется: сначала доступность, потом индексация, и только затем разметка. Чек-лист для быстрой диагностики: код ответа, robots.txt, canonical, наличие URL в индексе.
Если страницы массово не попадают в индекс, сначала разберитесь с технической базой. Настройка индексации для Яндекса и Google разбирает robots.txt, sitemap.xml и канонические страницы, которые чаще всего и создают проблему. Пока доступ и индексация не налажены, проверять микроразметку рано.
Как не потерять результаты проверок
Проверка превращается в разовую акцию, если её результаты нигде не зафиксированы. Ведите чек-лист с полями: наличие проблемы, дата проверки, подсказки, описание фактора, цветовое выделение блоков, приоритет, ответственный, статус решения. Обновляйте его, когда в панелях вебмастеров появляются новые параметры. Так проверка становится воспроизводимой, а вы видите, что уже исправлено, а что нет.
Как встроить проверку микроразметки в регулярный процесс
Соберём всё в короткий алгоритм. Доступность: код ответа, robots.txt. Индексация: какие нужные страницы не попали в индекс, какие лишние попали. Метатеги, микроразметка, вид в выдаче. Для разметки отдельно: словарный валидатор для синтаксиса и словаря, валидатор поисковой системы для расширенного результата, панель вебмастера для картины по проиндексированным страницам.
Периодичность зависит от темпа публикаций. Если вы выпускаете десятки страниц в месяц, разовая проверка каждой страницы не масштабируется, и разметку проверяют по шаблонам: один раз настроили шаблон карточки или статьи, проверили его всеми валидаторами, а дальше контролируете отчёты панели на проиндексированных URL. При таком подходе словарный валидатор запускают точечно, когда меняется шаблон или добавляется новое поле.
При масштабном производстве контента проверка разметки входит в список повторяющихся операций, которые имеет смысл стандартизировать. SerpJet помогает организовать повторяемый процесс производства и обновления контента: генерацию статей с учётом семантики и контекста бизнеса, согласование, публикацию и последующее улучшение материалов. Проверка микроразметки при этом остаётся частью технического контроля качества на стороне специалиста: платформа не проверяет разметку автоматически, и подменять ею валидаторы не стоит.
Практический минимум на выходе: чек-лист с полями фиксации, два словарных валидатора для синтаксиса, валидатор целевой поисковой системы для расширенных результатов и отчёты панели вебмастера по проиндексированным страницам. Этого достаточно, чтобы отделять реальные проблемы разметки от ложных расхождений и не тратить время на правки того, что и так работает.