Проверка микроразметки: где искать ошибки и что чинить первым

Проверка микроразметки почти всегда заканчивается одинаково: валидатор Яндекса пишет «ошибок не найдено», отчёт Google по расширенным результатам показывает восемнадцать ошибок на тех же страницах, а сниппет в выдаче каким был, таким и остался. Мистики тут нет: инструменты отвечают на разные вопросы, и пока не понимаешь, на какой именно, правки идут вслепую.

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

Чем валидатор Яндекса отличается от инструментов Google

Инструментов три, и они не заменяют друг друга. Первый — валидатор микроразметки в Яндекс.Вебмастере, раздел «Инструменты». Он принимает URL или кусок кода и работает как парсер: показывает дерево распознанных сущностей и отдельно список ошибок и предупреждений. Понимает не только schema.org, но и Open Graph, микроформаты и RDFa. Сильная сторона — именно дерево: видно, что робот реально вытащил со страницы, а не что вы имели в виду.

Второй — Rich Results Test у Google. Он проверяет не всю разметку, а только типы, под которые у Google есть визуальная фича в выдаче. Разметили страницу типом Service — инструмент честно скажет, что подходящих расширенных результатов не найдено, и это не дефект кода, это отсутствие фичи. Здесь же главная ловушка: ошибка означает «элемент не попадёт в расширенные результаты», предупреждение — «попадёт, но с меньшим набором данных». Люди массово чинят предупреждения и не трогают ошибки.

Третий — Schema Markup Validator на validator.schema.org: проверка по словарю schema.org без привязки к чьим-либо фичам. Он отвечает, существует ли такое свойство у этого типа и не подсунули ли строку туда, где ждут вложенный объект.

Отсюда вывод, который экономит недели: валидность по schema.org и пригодность для расширенного сниппета — разные состояния. Разметка бывает безупречной по словарю и бесполезной, потому что фичи под этот тип нет, — и наоборот, с предупреждениями по словарю, но с крошками и ценой в выдаче.

Отдельно от разовых проверок стоят отчёт «Расширенные результаты» в Search Console и мониторинг страниц в Вебмастере: они показывают накопленную картину по сайту, а не одну страницу. Если ошибка вылезла на трёх тысячах URL, это дефект шаблона, и чинить надо шаблон.

Последнее по этому разделу: проверять надо отрендеренную страницу, а не только ответ сервера. JSON-LD часто вставляется скриптом — так работают конструкторы и диспетчеры тегов. В Search Console это видно через «Проверка URL» → «Изучить страницу» → вкладка HTML: если application/ld+json есть там, но нет в исходном коде, разметка доставляется скриптом. Для Google это обычно работает с задержкой на рендер, для Яндекса — заметно хуже, и товарную разметку лучше отдавать сервером.

Три уровня ошибок и какой из них разбирать первым

Первый — ошибки парсинга. Блок JSON-LD не читается целиком: лишняя запятая перед закрывающей скобкой, незакрытая кавычка, типографские «ёлочки» вместо прямых, неэкранированные кавычки внутри значения (описание товара с дюймами — классика). Результат: вся разметка страницы для поисковика отсутствует, включая идеально составленную часть. Валидатор Яндекса покажет обрубок, Google — синтаксическую ошибку с номером символа.

Второй — отсутствующие обязательные поля. Тип распознан, но нет свойства, без которого фича не собирается: у Product нет offers, у BreadcrumbList нет position, у Article нет headline. В Rich Results Test это красная ошибка.

Третий — предупреждения. Нет рекомендованных полей: brand, sku, dateModified. Фича работает, набор данных беднее. Чинится последним и не всегда стоит усилий.

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

Обязательные и необязательные поля: что реально ломает сниппет

Почти весь список ошибок на сайтах сводится к десятку одинаковых пунктов.

Тип	Поля, без которых фича не собирается	Типичная ошибка	Что происходит в выдаче
Product	name, offers (price, priceCurrency, availability), image	price записан как «12 900 ₽» вместо 12900; валюта внутри цены; availability словом вместо ссылки https://schema.org/InStock	Цена и наличие не показываются, товарные блоки недоступны
BreadcrumbList	itemListElement, position, name, item	position начинается с нуля или идёт вразнобой; item указывает относительный адрес	Крошки не заменяют URL, показывается обычный адрес
Article / NewsArticle	headline, image, datePublished	headline длиннее 110 символов; дата не в ISO 8601 (нужно 2026-09-05 или 2026-09-05T10:00:00+03:00)	Материал не попадает в новостные и мультимедийные блоки
Organization / LocalBusiness	name, url, logo, address для LocalBusiness	Логотип битый или меньше 112 пикселей по меньшей стороне; адрес строкой вместо PostalAddress	Не собирается карточка организации
Review / AggregateRating	itemReviewed, ratingValue, reviewCount или ratingCount	Рейтинг без объекта отзыва; ratingValue выше bestRating; отзывы о себе на своём сайте	Звёзды не показываются, при системном нарушении — ручные меры
VideoObject	name, description, thumbnailUrl, uploadDate	thumbnailUrl ведёт на страницу, а не на файл изображения; дата загрузки в будущем	Превью видео в выдаче не появляется

Отдельная строка — связи между сущностями. Когда на странице несколько объектов, их принято связывать через @id: у организации постоянный идентификатор, статья ссылается на него в publisher. Без этого поисковик получает не граф, а набор разрозненных объектов. Ошибкой это не считается, но склейка сущностей по сайту не работает.

И вторая мелочь с большими последствиями: в свойствах url, item, image, thumbnailUrl нужен абсолютный адрес со схемой и доменом. Относительный путь Яндекс иногда достраивает сам, Google — не всегда. После смены домена разметку надо перепроверять целиком: абсолютные адреса продолжат тянуть на старый хост, и валидатор об этом не скажет ни слова. Общий порядок такой ревизии описан в материале Технический аудит сайта.

Разметка, которая не совпадает с содержимым страницы

Единственный класс ошибок, за который прилетает не «отсутствие фичи», а санкция. Требование сформулировано прямо: структурированные данные описывают то, что видит пользователь на этой странице. Нарушение проходит по разделу спама в структурированных данных, наказание — ручные меры, снимающие расширенные результаты со всего сайта. Восстановление идёт через запрос на перепроверку и занимает недели.

• AggregateRating без отзывов. На странице нет ни одной оценки, а в разметке 4.9 из 87 голосов — число подставил плагин по умолчанию. Правило: не видно глазами на странице — не должно быть в коде.
• Отзывы о самом себе. Оценки бизнеса, размещённые самим бизнесом, в расширенных результатах не показываются. В Яндексе рейтинг организации подтягивается из карточки в Яндекс.Бизнесе, а не из кода сайта. Из чего вообще собирается результат в выдаче, разобрано в статье Как формируется сниппет сайта.
• Product на странице раздела. Категория с сеткой из сорока товаров размечена одним Product с ценой «от», не соответствующей ни одной позиции.
• FAQPage с вопросами, которых нет в тексте. Плагин даёт заполнить вопросы в поле админки, на странице они не выводятся — для читателя их не существует. Заодно: показ FAQ-блоков в выдаче Google с 2023 года сильно ограничен, так что смысла мало даже при честном заполнении.
• Раздутое описание. В разметке текст богаче, чем на странице, с ключевыми фразами, которых в тексте нет. Это тот же приём, что скрытый текст, и отношение к нему такое же.

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

Конфликт разметки темы и плагина

Самая частая техническая проблема на любой CMS с готовым шаблоном: разметку выводят два источника сразу. Тема отдаёт микроданные атрибутами itemscope и itemprop прямо в вёрстке, SEO-плагин добавляет свой блок JSON-LD. На странице оказывается два Article, две Organization, два BreadcrumbList.

В инструментах это видно так. Валидатор Яндекса покажет два независимых дерева одного типа — самый наглядный признак. Rich Results Test покажет два обнаруженных элемента, и если у одного не хватает обязательных полей, вы получите одновременно «действительный элемент» и ошибку. В Search Console ошибка будет висеть на URL, который при ручной проверке выглядит нормально, — потому что робот выбрал не тот объект.

Диагностика занимает минуту: открываете исходный код и считаете вхождения application/ld+json, затем ищете itemscope в шапке, крошках и заголовке записи. Дальше решаете, кто остаётся. Обычно логичнее оставить плагин: его вывод настраивается, а тему при обновлении перезапишут. В теме микроданные вычищаются правкой шаблонов и только в дочерней. Если SEO-плагинов несколько, лишние надо удалять, а не отключать: деактивированный оставляет в базе настройки, которые подхватывает следующий. Сравнение плагинов есть в обзоре Лучшие SEO плагины для wordpress.

Отдельный подвид — дубли хлебных крошек: их выводит тема, плагин и модуль каталога. Три BreadcrumbList означают, что поисковик выберет любой, в том числе тот, где позиции перепутаны. Как крошки устроены, описано в статье Хлебные крошки на сайте что это.

Какие типы разметки реально дают расширенный сниппет

Словарь schema.org огромен, а список типов, которые что-то меняют в выдаче, короткий. Остальные не вредят, но и не окупают работу.

Тип разметки	Что даёт в Google	Что даёт в Яндексе	Стоит ли внедрять
BreadcrumbList	Путь разделов вместо URL в сниппете	Путь разделов в сниппете	Да, первым делом — работает почти везде
Product + Offer	Цена, наличие, участие в товарных блоках	Данные для товарных карточек, цена в сниппете	Да, для магазинов обязательно
Organization / LocalBusiness	Карточка знаний, логотип, контакты	Данные организации, связка с картами	Да, один раз на главной
VideoObject	Превью видео, метки моментов	Видео в результатах поиска	Да, если видео на страницах есть
Recipe, Event, JobPosting	Блоки с фото, датами, вакансиями	Частично, для событий и вакансий	Да, но строго по профилю сайта
Article / NewsArticle	Помогает попасть в новостные и мультимедийные блоки	Влияет на разбор материала, видимого расширения не даёт	Да, но изменений в обычном сниппете не ждите
FAQPage, HowTo	HowTo отключён, FAQ показывается крайне ограниченно	Может использоваться для быстрых ответов	Скорее нет — риск не окупается
Service, WebPage, ImageObject	Визуальной фичи нет	Визуальной фичи нет	Нет, кроме случая связки графа

И второе: валидная разметка не обязывает поисковик показывать расширенный сниппет. Это возможность, а не гарантия — решение принимается по запросу, устройству и конкурентной выдаче. Поэтому штатная картина такая: элемент числится действительным, а расширения по части запросов нет. Чинить тут нечего. Что влияет на итоговый вид результата, разобрано в материале Расширенные сниппеты.

Порядок починки: что делать первым

1. Синтаксис. Все страницы, где блок JSON-LD не парсится. Пока он не читается, остальные правки не увидят.
2. Дубли сущностей. Убрать второй источник разметки, иначе вы правите один объект, а робот берёт другой.
3. Несоответствие содержимому. Удалить рейтинги без отзывов, вопросы без ответов на странице, чужие цены. Делается до того, как что-либо добавлять.
4. Обязательные поля у типов из верхней части таблицы. Крошки, товары, организация, видео. Здесь появляется видимый результат.
5. Связывание через @id. Один постоянный идентификатор организации и сайта, ссылки на него из статей и товаров.
6. Рекомендованные поля. brand, sku, dateModified, aggregateRating при реальных отзывах. Отдача небольшая, очередь последняя.

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

Когда проверять и чинить микроразметку не нужно

Страницы не в индексе. Раздел закрыт в robots, отдаёт 404, склеен канониклом или не проиндексирован — разметка на нём не работает по определению. Сначала индексация, потом разметка.

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

Сайт без товаров, событий, рецептов и видео. Информационный проект получает крошки и корректный разбор материалов, остальное — работа ради строчки в отчёте.

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

Сайт под фильтром или ручными мерами. Пока не снята основная проблема, расширенные результаты не вернутся, сколько полей ни добавь.

Частые вопросы

Валидатор Яндекса ошибок не нашёл, Google показывает ошибки. Кому верить?
Обоим: они проверяют разное. Яндекс разбирает разметку как парсер и сообщает о структурных проблемах, Google требует свой набор обязательных полей под конкретную фичу. Расхождение штатное и означает, что синтаксис в порядке, а полей для расширенного результата не хватает.

Что важнее исправить: ошибку или предупреждение?
Ошибку. Предупреждение означает «фича работает, данных меньше», ошибка — «фича не работает». Исключение одно: предупреждение про дубль сущности разбирают сразу, оно влияет на то, какой объект вообще прочитает робот.

Микроразметка поднимает позиции?
Напрямую нет, фактором ранжирования она не является. Косвенно влияет через кликабельность: сниппет с крошками, ценой и наличием собирает больше переходов.

Можно ли размечать рейтинг, если отзывы лежат на отдельной странице?
На той странице, где отзывы физически выводятся, — да. На карточке, где их нет, — нет. Хотите рейтинг на карточке товара — выводите на ней блок с оценками и количеством отзывов.

Через сколько после правок изменится сниппет?
Сначала робот переобходит страницу: от суток до нескольких недель в зависимости от частоты визитов. Затем поисковик решает, показывать ли расширение. Реалистичный горизонт оценки — две-четыре недели после переобхода. Нет изменений через месяц — причина не в разметке.

Нужно ли перепроверять разметку после обновления CMS?
Обязательно: обновление темы или плагина — самая частая причина, по которой рабочая разметка ломается или задваивается. Достаточно прогнать по одной странице каждого типа.

Коротко

• Валидатор Яндекса проверяет структуру, Rich Results Test — пригодность для фичи Google, validator.schema.org — соответствие словарю. Выводы у них разные по определению.
• Порядок починки жёсткий: синтаксис, дубли сущностей, несоответствие содержимому, обязательные поля, связка через @id.
• Разметка, описывающая то, чего нет на странице, — повод для ручных мер, снимающих расширенные результаты со всего сайта.
• Два источника разметки (тема плюс плагин) дают дубли: считайте вхождения application/ld+json и ищите itemscope в шаблоне.
• Отдачу дают крошки, товары с ценой и наличием, организация и видео. Service, WebPage и FAQ работу не окупают.
• Валидная разметка не гарантирует расширенный сниппет: это возможность, а не обязательство поисковика.

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