Проверка микроразметки: чем проверять и какие ошибки искать

Что такое проверка микроразметки и зачем она нужна?

Проверка микроразметки отвечает на три вопроса по очереди. Видит ли робот разметку вообще, читается ли она без синтаксических ошибок и подходит ли под правила конкретной поисковой системы. Это три разных вопроса, и каждый закрывает свой инструмент.

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

Выгоду от аккуратной разметки видно в цифрах. У клиента, интернет-магазина сантехники на готовом решении Аспро: Максимум, была низкая кликабельность страниц в поиске. Исполнители добавили микроразметку в код, и через месяц CTR страниц вырос на 50% в относительном значении. Это отчёт исполнителя о своём клиенте, поэтому цифру стоит читать как ориентир.

Форматов разметки три: JSON-LD, микроданные и RDFa. Google рекомендует JSON-LD, и проверять его проще всего: он лежит в одном блоке script. Микроданные, как отмечают авторы Кокоса, приходится вносить в HTML вручную тег за тегом, поэтому они встречаются реже и чаще ломаются при правках вёрстки.

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

Какой валидатор что проверяет

Универсального валидатора нет, у каждого свой вопрос. Sape разбирает пять способов: осмотр кода, Rich Results Test, Schema Markup Validator, Search Console и Яндекс Вебмастер. Их стоит сочетать.

Начните с исходного кода. Ctrl+U и поиск по «ld+json» покажут, есть ли JSON-LD, а атрибуты itemscope, itemtype и itemprop выдадут микроданные. Ошибок такой осмотр не найдёт, он отвечает только на вопрос «разметка есть или нет».

Rich Results Test проверяет, может ли страница получить расширенный результат. По документации Google, он быстро находит ошибки в разметке, а иногда показывает, как результат будет выглядеть в выдаче. Это проверка одной страницы за раз и только на пригодность для Google.

Schema Markup Validator сверяет синтаксис и словарь Schema.org для любого типа и не оглядывается на Google. Запускать стоит оба инструмента. Как замечает Патрик Стокс, прохождение одной проверки отвечает только на её собственный вопрос и ничего не говорит о другой.

Для рунета обязателен ещё один шаг. Справка Яндекс Вебмастера называет поддерживаемые форматы: микроформаты, Schema.org, Open Graph, HTML-микроданные и RDFa. Главное отличие: валидатор сверяется с требованиями сервисов Яндекса и знает типы и поля, которые компания добавила от себя. Минус в том, что проверка доступна только с аккаунтом Яндекса. О JSON-LD сказано в отдельной статье справки: правильность такой разметки можно проверить в валидаторе Вебмастера, а сами данные нужно помещать в тег script. Яндекс использует их в Почте, для навигационной цепочки в сниппетах и для вопросов и ответов в мобильной выдаче.

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

Как это работает на практике, показал индонезийский видеосервис Vidio. Команда добавила к каталогу разметку VideoObject, и убедилась в её успехе в разделе улучшений для видео в инструменте проверки URL. Для каждого файла задали постоянный адрес, доступный роботу Googlebot, чтобы он не спотыкался о битые ссылки в плейлистах. За год показы видео выросли примерно втрое, а переходы из Google удвоились. Ошибки по платформе искали и чинили через отчёты Search Console об индексировании и эффективности.

Какие ошибки встречаются чаще всего?

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

Цену синтаксической мелочи показал случай одной глобальной гостиничной группы. Она автоматизировала вывод схемы без участия SEO-специалиста, и пропущенная запятая в коде распространилась на страницы в нескольких странах. Нашёл её отчёт Search Console о нечитаемых структурированных данных. После правки число заблокированных элементов упало примерно с 5000 до 36, а позже до нуля. Эффекта в тот же день не случилось: Google заново обходит каждую страницу, и на это уходят недели.

Яндекс описывает свои сообщения подробно, и их удобно прочитать до первой проверки. В справке Вебмастера частые случаи такие:

• «Микроразметка не обнаружена»: у корневого элемента Schema.org пропущен атрибут itemscope.
• «Поле отсутствует или пусто»: у ImageObject не указан адрес картинки, то есть не хватает contentUrl.
• Значение поля некорректно: дата в Schema.org записывается по стандарту ISO 8601: год, месяц и день через дефисы.
• В свойстве content тега meta стоит ссылка: для адресов нужен тег link.
• Не выполнено условие для продуктовых сниппетов: Яндекс советует исправить это, если вы хотите получить структурированные сниппеты.

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

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

Почему разметка проходит проверку, а сниппета нет?

Валидатор проверяет форму, но не честность. Правила Google разделяют технические требования, которые находят автоматические инструменты, и рекомендации по качеству. Нарушения вторых нелегко поймать машиной, и они могут оставить синтаксически правильную разметку без расширенного результата.

Главное правило звучит просто: размечайте то, что видит читатель. Если в JSON-LD есть описание, тот же текст должен быть в HTML. Не пройдут и данные, не относящиеся к теме страницы. Пример из документации Google: инструкции по деревообработке на столярном ресурсе, помеченные как рецепты.

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

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

Есть и третий случай, когда ошибки вовсе нет. Разметка FAQPage остаётся валидной, но Google больше не показывает расширенные результаты с часто задаваемыми вопросами, а документацию по ним удалил. По разбору Стокса, вместе с документацией пропали поддержка в Rich Results Test и отчёт в Search Console, однако FAQPage остаётся допустимым типом Schema.org, и Google по-прежнему его разбирает. Срочно вырезать такую разметку не требуется: вреда она не приносит, но и сниппета не даёт. До FAQ Google снял с десктопа HowTo, а одним пакетом отключил показ семи нишевых типов, среди них Estimated Salary и Vehicle Listing. Во всех этих историях тип Schema.org остался допустимым, а отображение прекратилось. Не тратьте часы на поиск несуществующей ошибки.

Как проверить разметку, которую создаёт JavaScript?

Если JSON-LD добавляет скрипт или менеджер тегов, в ответе сервера его нет. Осмотр по Ctrl+U пуст, хотя в браузере всё работает. Проверять приходится уже отрисованную версию страницы.

Google, как сказано в руководстве по структурированным данным с JavaScript, распознаёт данные, доступные в DOM при отрисовке страницы. Значит, проверять нужно отрисованный результат. Есть три способа:

• Откройте DevTools, вкладку Elements, и найдите script с JSON-LD: так советует Sape.
• Прогоните страницу через Schema Markup Validator: по словам Sape, он загружает HTML и обрабатывает JavaScript.
• Для страниц, которых нет в отчётах, воспользуйтесь инструментом проверки URL в Search Console.

Если разметку выводит менеджер тегов, берите значения через переменные, а не переписывайте в теге: при дублировании растёт риск расхождения между текстом страницы и разметкой. Тот же документ Google подсказывает пример с переменной recipe_name, которая берёт заголовок страницы. А серверная отрисовка снимает вопрос целиком: структурированные данные можно включить прямо в обработанный код.

Что даёт разметка без ошибок

Сам Google собрал в документации несколько историй, и все они выглядят одинаково: чистая разметка, расширенный результат, рост кликов. Rotten Tomatoes внедрил структурированные данные на 100 000 уникальных страниц и получил рост CTR на 25%.

У Food Network масштаб другой: после того как структурированными данными снабдили 80% страниц, посещаемость выросла на 35%. Для издателя с большим архивом это означает, что разметку выгоднее ставить через шаблон, а проверять выборочно по типам страниц.

Компания Rakuten измерял поведение: пользователи проводят в 1,5 раза больше времени на страницах со структурированными данными. А Nestlé сравнила сами сниппеты: у страниц с расширенными результатами CTR на 82% выше, чем у обычных ссылок.

Vimeo решал другую задачу. Раньше издателям приходилось самим внедрять поисковую оптимизацию видео: разметку, карты сайта и Indexing API. Сервис перенёс работу на сторону плеера: добавил VideoObject и правило indexifembedded, и встроенные ролики из библиотеки в более чем 750 миллионов видео стали индексироваться без разметки у издателя. Эпизоды помечены свойством Clip, чтобы Google показывал ключевые моменты. Алекс Черни, старший директор по продукту Vimeo, объясняет цель так:

помочь каждому издателю добиться широкого охвата без технического образования

Алекс Черни, старший директор по продукту в Vimeo, в материале Google

Все эти цифры компании приводят о себе, и они не доказывают, что рост даёт одна разметка. Но направление стабильное: пока разметка читается и совпадает со страницей, она работает на кликабельность.

С чего начать проверку у себя?

Удобнее всего собрать короткий маршрут и ходить им при каждом релизе.

1. Откройте исходный код и убедитесь, что разметка вообще есть.
2. Прогоните шаблоны разных типов страниц (главная, карточка товара, статья) через Rich Results Test.
3. Сверьте словарь в Schema Markup Validator.
4. Для рунета откройте валидатор Яндекс Вебмастера.
5. Зайдите в отчёты Search Console, исправьте ошибки раньше предупреждений и проверьте исправление.
6. Сравните текст в разметке с тем, что видит читатель.

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

Отчёту тоже нельзя верить вслепую: ошибался и сам Google. Из-за сбоя в Search Console часть предупреждений попала в таблицу критических ошибок, и владельцы сайтов видели «ошибки» там, где ничего не блокировалось. Google вернул записи в таблицу предупреждений и пояснил, что дело только в отчётности, а показ расширенного результата это не затрагивало, как пересказывает Стокс. Поэтому сомнительный пункт сверяйте с Rich Results Test, а не с одним отчётом.

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

Закрепите проверку в процессе. В гостиничной группе из истории выше консультант после исправления запятой написал для команды разработки свод правил по структурированным данным, чтобы ошибка не вернулась. К тому моменту нечитаемых элементов оставалось 36 из примерно 5000. Хватит и короткой памятки: тестируйте шаблон до релиза. Разметка входит в общий список технической оптимизации, который описан в нашем руководстве по SEO.

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