Тестирование и отладка структурированных данных: проверка в Rich Results Test и поиск ошибок
1. Как распределяются задачи между двумя инструментами
Многие команды считают, что достаточно добавить Schema на страницу, — а потом в GSC всё красное. Для отладки структурированных данных нужны два инструмента, и у каждого своя зона ответственности.
Rich Results Test проверяет отдельную страницу: вставьте URL или фрагмент кода и посмотрите, может ли эта страница дать расширенный результат. Schema Markup Validator проверяет, корректен ли сам JSON-LD.
| Инструмент | Что проверяет | Когда использовать | Ограничения |
|---|---|---|---|
| Тест расширенных результатов | Право на расширенный результат для отдельной страницы | Проверять каждую страницу перед запуском | Проверяет только ту страницу, которую вы вставили |
| Валидатор схем | Синтаксическая корректность JSON-LD | Проверять локально во время написания кода | Не гарантирует, что Google действительно покажет результат |
| Отчёт о расширенных результатах в GSC | Проверенные страницы всего сайта | Смотреть раз в неделю после запуска | Данные обновляются с задержкой 2–3 дня |
Как выбрать тип Schema и какие бывают поля — см.Структурированные данные Schema и Полный список Schema для структурированных данных. А здесь о том, как проверить готовую разметку и исправить ошибки.
Расхождения в отчётах трёх инструментов — это нормально: локальная проверка прошла, а в GSC результат может появиться только через 2–3 дня. Не делайте выводы только потому, что локально всё прошло.
2. Ошибки и предупреждения: что исправлять в первую очередь
К каждому сообщению в отчёте об отладке нужно подходить по уровню важности. Если исправлять предупреждения как ошибки, одно за другим, можно потерять несколько дней.
| Уровень | Значение | Влияет ли на расширенные результаты | Приоритет обработки |
|---|---|---|---|
| Ошибка Error | Отсутствует обязательное поле или неверный тип | Да, расширенный результат пропадает | Исправить немедленно |
| Предупреждение Warning | Отсутствует рекомендуемое поле | Нет, результат всё равно может показываться | Запланировать исправление |
| Информация Info | Рекомендация по необязательному полю | Нет | Дополнить, когда будет время |
Контринтуитивный вывод: 80% сообщений в отчёте — предупреждения. Google помечает жёлтым отсутствие автора, даты и других рекомендуемых полей, но страница всё равно может давать расширенный результат.
Расширенные результаты исчезают из-за ошибок: например, выбран тип Article, но не указан headline, или дата записана строкой, а не в формате ISO. Эти две категории нужно исправлять в первую очередь.
Пример из практики: GSC сообщает о 120 проблемных страницах на блоге, и сначала кажется, что всё пропало. После разделения по уровням выясняется, что на 110 страницах предупреждение об отсутствии image, и только на 10 — ошибка формата datePublished. Сначала исправляем 10 критических ошибок, через неделю расширенные результаты восстанавливаются на 80%, а страницы с предупреждениями как показывались, так и показываются.
Если ваша команда использует CMS-шаблоны, ошибки появляются целыми партиями. Исправляете поле в одном шаблоне — и после следующего сканирования все страницы восстанавливаются автоматически, вручную править каждую не нужно. Поэтому и стоит сначала браться за ошибки: одно изменение в шаблоне заменяет ручную правку десятков страниц.
Предупреждения, наоборот, обычно касаются отдельной страницы: нет автора, нет главного изображения — это постраничные проблемы, их придётся закрывать постепенно, по плану.
Как искать частые ошибки третьей и четвёртой категорий
На B2B-сайтах ошибки структурированных данных чаще всего относятся к четырём категориям. Ниже они расположены по частоте появления.
| Тип ошибки | Как это выглядит | Как искать | Как исправить |
|---|---|---|---|
| Неверный тип поля | Дата записана как 2026/10/08 | Проверьте, соответствует ли она ISO 8601 | Исправьте на 2026-10-08 |
| Неверный уровень вложенности | Review вне Product | Проверьте структуру @graph | Вложите Review в Product |
| Нет обязательного поля | В Article нет headline | Сверьтесь с официальной таблицей полей | Добавьте обязательное поле |
| Дублирование на нескольких URL | Article проставлен на каждой странице пагинации | Проверьте, куда указывает canonical | Оставьте разметку только на основной статье |
Формат даты — самая частая ошибка. Google требует ISO 8601, то есть 2026-10-08, а не 10/08/2026 и не Oct 8, 2026. Один слэш — и целая партия страниц теряет расширенные результаты.
Ещё одна незаметная ошибка — пагинация. Если на 2-й и 3-й страницах серии статей тоже стоит Article, Google посчитает их дублями и оставит только ту, на которую указывает canonical. На остальных страницах разметку нужно либо убрать, либо заменить на CollectionPage.
Как получить и поддерживать расширенные результаты, читайте в разделе Оптимизация расширенных результатов; о разметке сущностей — в разделе Разметка сущностей для графа знаний.
Как проверить, что после запуска всё действительно работает
Успешный локальный тест не значит, что изменения заработали в сети. У проверки структурированных данных есть свой цикл, и ждать нужно правильно.
| Этап | Срок | Что вы видите | Действие |
|---|---|---|---|
| Отправляете исправление | День 0 | В GSC нажимаете «Проверить исправление» | Не меняйте код повторно |
| Повторное сканирование | С 1-го по 7-й день | Статус в отчёте всё ещё «Исправление проверяется» | Ждите |
| Проверка завершена | С 1-й по 4-ю неделю | Число ошибок снижается | Сверьтесь с выдачей и проверьте расширенные результаты |
| Долгосрочный мониторинг | Ежемесячно | Автоматически ли индексируются новые страницы | Включите в технический аудит |
После нажатия «Проверить исправление» не меняйте код повторно. Каждая правка сбрасывает окно оценки Google: проверка, которая заняла бы 2 недели, растянется на 6.
Когда проверка завершится, поищите в Google целевые запросы и посмотрите глазами, появились ли в выдаче звёзды, раскрывающиеся блоки FAQ, хлебные крошки. То, что GSC считает разметку действительной, не значит, что пользователь её видит: некоторые типы показываются только по определённым запросам.
Если GSC показывает, что разметка действительна, а расширенных результатов в выдаче нет, сначала проверьте, вызывает ли их сам запрос. Некоторые типы появляются только по навигационным или информационным запросам, а по транзакционным могут не показываться. Поищите ещё несколько близких запросов.
Не забывайте и о долгосрочном мониторинге. После публикации новой страницы через неделю загляните в GSC и проверьте, распозналась ли она автоматически. Если нет — запросите проверку вручную через инструмент проверки URL.
Если вы собираете сайт на шаблоне, добавьте в процесс публикации одну проверку: перед выходом новой страницы прогоните её через Rich Results Test и публикуйте только после успешного прохождения. Это занимает минуту, зато спасает от массовой переделки уже после запуска.
Расширенные сниппеты — не самоцель, они лишь делают страницу заметнее в выдаче. На позиции влияют контент и внешние ссылки, а структурированные данные просто добавляют 10–20% кликов к уже хорошей странице.
Поэтому порядок не меняйте: сначала доведите контент до топ-20, а уже потом добавляйте структурированные данные, чтобы бороться за расширенный сниппет. Если сама страница не ранжируется, никакая разметка её не покажет.
Полный чек-лист технического SEO-аудита смотрите в Чек-лист технического SEO-аудита, структурированные данные — один из его пунктов; предполётная проверка перед запуском — в Чек-лист проверки сайта перед запуском.
Пять. Подводные камни: три самые частые ошибки на этапе отладки
В отладке структурированных данных есть три ловушки: наступишь — не только не получишь результата, но и рискуешь схлопотать ручную санкцию.
| Ошибка | Последствия | Правильный подход |
|---|---|---|
| Накрутка звёздного рейтинга | Нарушение правил о структурированных данных | Размечать только реальные отзывы |
| Исправлять все предупреждения как ошибки | Потеря нескольких дней без роста позиций | Сначала ошибки, предупреждения — по плану |
| Бесконечно править после локального прохождения | Сброс окна проверки | После отправки ждать 1–4 недели |
Хуже всего накрутка звёзд. За завышенные самооценки и фальшивые отзывы Google выдаёт ручные санкции: если попадёте, расширенные сниппеты снимут со всего сайта, а восстановление займёт месяцы. Размечайте только те отзывы, которые реально видны на странице.
Структурированные данные помогают и AI-краулерам, смотрите Техническая оптимизация для GEO. Они нужны не ради звёздочек, а чтобы и поисковики, и AI понимали сущности на странице.
FAQ: частые вопросы
Rich Results Test пройден, почему в выдаче всё равно нет расширенного сниппета?
Чем ошибки отличаются от предупреждений в отчёте о расширенных результатах GSC?
Какая ошибка в структурированных данных встречается чаще всего?
Сколько ждать результата после исправления ошибок в структурированных данных?
Можно ли добавить несколько хороших отзывов от себя, чтобы получить звёзды в выдаче?
Есть ли разница, писать JSON-LD в head или в body?
В заключение
В отладке структурированных данных проверяют не умение писать Schema, а терпение. Когда отчёт красный, сначала расставьте приоритеты: 80% — это предупреждения, с которыми спешить не нужно. После отправки исправлений ждите от 1 до 4 недель и не правьте код каждый день.
Три шага к результату: проверьте отдельную страницу в Rich Results Test; на уровне всего сайта в отчёте о расширенных результатах в GSC сначала исправьте только ошибки; после правок нажмите «Запросить проверку» и дождитесь переоценки Google, не переделывайте работу по ходу.
Запомните одну фразу: пройденный тест для структурированных данных — это лишь входной билет. Реально всё заработает только после трёх шагов: нажать проверку в GSC, выждать полные четыре недели и увидеть расширенные результаты в выдаче своими глазами.