Чтобы проверить микроразметку, протестируйте адрес страницы в Schema Markup Validator, затем в Google Rich Results Test и, если продвигаетесь в Яндексе, в валидаторе Яндекс Вебмастера. Сверьте найденные данные с содержимым страницы и повторите проверку после исправлений. Если код создаётся через JavaScript, дополнительно изучите результат рендеринга. Успешная проверка подтверждает корректность в пределах конкретного теста; расширенный сниппет и рост позиций она не гарантирует.
Микроразметка, или структурированные данные, описывает сущности страницы: статью, товар, организацию, рецепт. Schema.org задаёт словарь типов и свойств. JSON-LD, Microdata и RDFa — способы записать эти сведения в коде. Поисковые системы используют поддерживаемые данные для понимания страницы и отдельных функций выдачи.
Что подготовить перед проверкой
Выберите конкретную страницу: статью, карточку товара, контакты или другой документ, разметку которого хотите проверить. Проверка главной страницы не охватывает остальные шаблоны сайта.
Понадобятся:
- полный URL с протоколом, например
https://example.com/blog/article/; - ожидаемый тип разметки:
BlogPosting,Product,BreadcrumbListили другой; - доступ к исходному HTML либо код, который планируете внедрить;
- возможность изменить шаблон, настройки плагина или данные CMS;
- доступ к ресурсу в Google Search Console для контроля после публикации.
Откройте страницу без авторизации. Проверьте, что адрес ведёт на нужный документ, а изображения и другие связанные ресурсы доступны. Если вместо страницы загружается форма входа, заглушка защиты или ошибка сервера, сначала разберитесь с доступом. Исправление запятых в JSON-LD не устранит проблему загрузки.
Для нового шаблона заранее определите, какие сведения должны попасть в разметку. У статьи это заголовок, автор, даты и изображение; у товарного предложения — цена, валюта и наличие. Так вы заметите потерянные данные, даже если валидатор не выдаёт ошибку.
Как выбрать валидатор микроразметки
Инструменты отвечают на разные вопросы. Для рабочей проверки полезно пройти три уровня: распознавание данных, требования нужной поисковой системы и соответствие содержимому страницы.
| Инструмент | Что помогает проверить | Ограничение |
|---|---|---|
| Schema Markup Validator | Какие сущности Schema.org извлечены из URL или кода; синтаксис и структуру разметки | Не определяет пригодность для конкретного расширенного результата Google и не проверяет все правила поисковых систем |
| Google Rich Results Test | Поддерживаемые Google типы, критичные ошибки и некритичные замечания; обработанный HTML | Не охватывает весь словарь Schema.org; успешный тест и доступное превью не гарантируют показ |
| Валидатор Яндекс Вебмастера | Распознавание метаданных и соответствие требованиям сервисов Яндекса | Поддержка и использование данных зависят от формата, типа и конкретного сервиса |
| Google Search Console | Что Google обнаружил при обходе; проблемы поддерживаемых типов на проиндексированных страницах | Отчёты обновляются после обработки данных, охватывают не все типы и показывают неполный список примеров |
Schema Markup Validator работает с JSON-LD, Microdata и RDFa. Google также поддерживает эти форматы и рекомендует JSON-LD. Валидатор Яндекса проверяет, в частности, Schema.org, Open Graph и микроформаты. При этом корректная карточка ссылки для соцсетей через Open Graph не подтверждает корректность Product или Article.
Как проверить страницу по URL
Проверка в Schema Markup Validator
- Откройте инструмент и выберите проверку по URL.
- Вставьте полный адрес нужной страницы и запустите тест.
- Посмотрите список найденных сущностей и раскройте основной объект.
- Проверьте его тип, свойства и вложенные объекты.
- Исправьте ошибки в источнике разметки и повторите проверку.
Смотрите на сами значения. Для карточки товара должно определиться описание этого товара, для статьи — данные этой статьи. Если на всех страницах повторяются один заголовок, цена или дата, вероятна ошибка шаблона.
Раскройте вложенные элементы: автора, предложение Offer, адрес PostalAddress. При неверной вложенности свойство может относиться к другому объекту или оказаться вне нужной сущности.
Если нужный объект не найден, найдите его в коде страницы. Для JSON-LD ищите application/ld+json, для Microdata — itemscope, itemtype и itemprop. Отсутствие объекта в отчёте может означать отсутствие разметки, ошибку её записи или проблему получения страницы.
Проверка в Google Rich Results Test
- Выберите вкладку URL, вставьте тот же адрес и запустите тест.
- Изучите сведения о загрузке и роботе, который проверял страницу. При необходимости сравните мобильную и настольную обработку.
- Откройте обнаруженный тип структурированных данных.
- Разберите ошибки и некритичные замечания по каждому элементу.
- Просмотрите обработанный HTML и убедитесь, что там присутствует нужный блок с актуальными значениями.
Сообщение о допустимости расширенного результата означает, что найденный объект прошёл проверяемые технические требования. Качественные правила, соответствие контенту и окончательное решение о показе требуют отдельного внимания.
Если Google ничего не обнаружил, а Schema Markup Validator показывает объект, проверьте поддержку этого типа в Google. Например, существование типа Service в словаре Schema.org само по себе не создаёт отдельный расширенный результат. Затем сравните обработанный HTML: оба теста могли получить разные версии страницы.
Для некоторых типов доступен предварительный просмотр. Используйте его для оценки возможного представления данных. Реальный вид результата зависит в том числе от запроса и условий поиска.
Проверка в Яндекс Вебмастере
Введите адрес в поле URL документа или вставьте HTML-код, затем нажмите «Проверить». В результатах изучите распознанные данные и сообщения по каждому объекту.
Проверьте не только наличие названия типа. Для нужного сервиса могут потребоваться дополнительные поля. Предупреждение иногда означает, что данные извлечены, но пока не подходят для использования в этом сервисе.
В справке валидатора Яндекса разобраны ошибки загрузки, отсутствующие поля, некорректная принадлежность свойств и предупреждения о значениях. Например, дату следует записывать в формате ISO 8601, а свойства Microdata — внутри соответствующего объекта.
Если JSON-LD распознаётся в других инструментах, но результат Яндекса отличается, изучите поддержку выбранного типа и формата в нужном сервисе Яндекса. Не переносите требования Google на Яндекс автоматически.
Как проверить код до публикации
В режиме проверки кода можно протестировать фрагмент, когда страница ещё не опубликована или закрыта паролем. Для JSON-LD используйте валидный JSON: двойные кавычки, корректные запятые, без комментариев. Если проверяете Microdata или RDFa, вставляйте HTML с контейнерами и вложенностью, а не отдельное свойство.
Ниже — учебный пример для статьи на вымышленном сайте. Все адреса, автора и даты нужно заменить реальными сведениями. В HTML такой JSON размещают внутри элемента script с типом application/ld+json.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://example.com/blog/check-schema/#article",
"mainEntityOfPage": "https://example.com/blog/check-schema/",
"headline": "Как проверить микроразметку сайта",
"description": "Инструкция по проверке структурированных данных страницы.",
"image": "https://example.com/images/check-schema.jpg",
"datePublished": "2026-10-13T10:00:00+03:00",
"dateModified": "2026-10-13T10:00:00+03:00",
"author": {
"@type": "Organization",
"name": "Редакция Пример",
"url": "https://example.com/about/"
}
}@context задаёт словарь, @type — тип сущности, а @id — её идентификатор. В примере автор — организация; для конкретного человека используйте подходящий тип Person. Изображение должно относиться к статье и быть доступно для обхода.
Последовательность проверки:
- Проверьте JSON и распознанный объект в Schema Markup Validator.
- Протестируйте фрагмент в Google Rich Results Test.
- После внедрения повторите тест по URL опубликованной страницы.
Правила обязательных полей зависят от поисковой функции. У Article в текущем руководстве Google перечислены рекомендуемые свойства без общего списка обязательных. У товарных результатов требования другие. Не заполняйте отсутствующие сведения выдуманными значениями ради зелёного статуса.
Проверка фрагмента не подтверждает, что CMS вывела его на странице, что робот может загрузить адрес или что другие блоки не противоречат ему.
Как проверить разметку, которую создаёт JavaScript
У страницы есть исходный HTML, полученный от сервера, и DOM — структура документа после выполнения JavaScript. Если разметку добавляет приложение или Google Tag Manager, в исходнике её может не быть, а в DOM она появится.
Проверьте оба состояния:
- Откройте исходный код страницы в браузере и найдите блок разметки.
- Откройте инструменты разработчика, вкладку Elements, и повторите поиск после загрузки.
- Запустите Google Rich Results Test по URL и найдите данные в обработанном HTML.
- Сравните значения во всех доступных версиях.
Google может обрабатывать JSON-LD, добавленный JavaScript. Для такого внедрения предпочтительна проверка по URL: вставка кода имеет ограничения, в том числе при загрузке ресурсов с других доменов. Schema Markup Validator также умеет извлекать данные, внедрённые JavaScript; поведение остальных проверяющих сервисов нужно уточнять отдельно.
Если блок виден у вас, но отсутствует в обработанном HTML теста, проверьте ошибки JavaScript, доступ к API и скриптам, условия запуска тега, ожидание авторизации или действий пользователя. Сохранённые cookies и локальные данные браузера могут скрывать проблему.
Для товаров особенно важны быстро меняющиеся цена и наличие. Динамическая генерация Product может сделать обработку данных для Google Shopping менее надёжной. Когда архитектура позволяет, рассмотрите вывод актуальной разметки сразу в серверном HTML и обязательно проверяйте опубликованный результат.
Как исправить ошибки и предупреждения
Ошибка обычно мешает обработке объекта или его использованию для конкретной функции. Некритичное замечание в Google-тесте может указывать на рекомендуемое поле. В Яндексе предупреждение также может сообщать об ограничении использования данных сервисом. Оценивайте сообщение вместе с типом и требованиями инструмента.
| Симптом | Что проверить и исправить |
|---|---|
| Страница не загружается | URL, перенаправления, ответ сервера, авторизацию, защиту от роботов и доступ к ресурсам |
| Ошибка разбора JSON-LD | Пропущенную или лишнюю запятую, кавычки, незакрытые скобки, комментарии, экранирование текста из CMS |
| Неизвестный тип или свойство | Написание и регистр названия, наличие в Schema.org, поддержку конкретным потребителем |
| Отсутствует обязательное поле | Требования нужного поискового формата и реальное наличие этих сведений на странице |
| Некорректная дата или цена | Формат ISO 8601; числовое значение цены без текста «руб.»; валюту в предназначенном для неё поле |
| Свойство относится не к тому объекту | Вложенность JSON-LD; контейнеры itemscope и расположение itemprop для Microdata |
| Найдены конфликтующие объекты | Разметку темы, SEO-плагина, модуля отзывов и менеджера тегов; источник противоречащих значений |
| Нет ожидаемого изображения | URL файла, его доступность для робота, соответствие странице и требования выбранного типа |
Исправляйте источник проблемы. Если цену неверно формирует шаблон, ручное изменение одного документа оставит ошибку на остальных товарах. Если в коде указана старая дата, проверьте данные CMS и кэш.
Отдельно сравните разметку с тем, что видит посетитель:
- совпадают ли название, цена, валюта и наличие товара;
- относится ли рейтинг к нужной сущности и основан ли на реальных отзывах;
- соответствуют ли автор и даты статье;
- не описывает ли каждая страница один и тот же чужой объект;
- не остаются ли в разметке сведения об удалённом контенте.
Валидатор не заменяет такую сверку. JSON может успешно разбираться и при этом содержать вчерашнюю цену или сведения о другом товаре.
Какие типы и шаблоны проверить на сайте
Для сайта из многих страниц составьте выборку по шаблонам и состояниям данных. Начните с типового документа, затем добавьте случаи, в которых необязательные сведения отсутствуют или содержание меняется.
| Страница и тип | На что смотреть | Какие варианты добавить в выборку |
|---|---|---|
Статья: Article, BlogPosting, NewsArticle | Заголовок, автор, даты, изображение и связь с текущим документом | Обновлённая статья, несколько авторов, нестандартное изображение |
Товар: Product и связанное предложение | Название товара, предложение, цена, валюта, наличие; требования product snippet и merchant listing отдельно | Скидка, нет в наличии, варианты товара, отсутствие отзывов |
Хлебные крошки: BreadcrumbList | Порядок position, подписи name, адреса item | Глубокий раздел, короткая цепочка, другая структура категории |
Организация: Organization, подходящий подтип LocalBusiness | Название, адрес, контакты и соответствие конкретной организации или филиалу | Несколько филиалов, разные часы работы, отдельные страницы контактов |
Рецепт или мероприятие: Recipe, Event | Данные подходящего типа, даты, место или параметры рецепта | Изменённое событие, отсутствующие необязательные сведения |
У последней хлебной крошки Google допускает отсутствие item. Ошибку следует оценивать по требованиям выбранного формата, а не по правилу «в каждой строке обязательно нужен URL».
Несколько связанных типов на странице допустимы: например, статья, её автор и хлебные крошки. Проблема возникает, когда блоки описывают одну сущность противоречиво. Сопоставьте их значения и идентификаторы, затем устраните конфликт в шаблонах.
На большом сайте используйте SEO-краулер для инвентаризации типов и массового поиска проблем. Уточните, анализирует ли он исходный HTML или выполняет JavaScript. Критичные примеры перепроверьте официальными инструментами. Одной выборки недостаточно, чтобы объявить корректными все страницы каталога.
Как проверить результат после публикации
После сохранения кода откройте публичный URL и повторите тесты. Убедитесь, что изменение действительно появилось в HTML после обновления кэша, а данные не ограничены тестовой средой.
Затем выполните контроль:
- Проверьте доступность документа и отсутствие случайного запрета индексации. Ответ HTTP 200 сам по себе не подтверждает возможность появления в поиске.
- В Search Console используйте проверку URL: изучите опубликованную страницу и сравните её с проиндексированной версией, включая дату последнего обхода.
- При необходимости запросите повторное индексирование ключевых исправленных страниц. Для большого объёма поддерживайте актуальную XML-карту сайта.
- После обработки следите за отчётами поддерживаемых расширенных результатов. Для уже зафиксированной проблемы используйте проверку исправления, когда изменения внесены на затронутых страницах.
- Проверьте контрольную выборку шаблонов в Яндексе и наблюдайте за данными Вебмастера после обхода.
Сохраните дату теста, URL, типы, найденную проблему и результат повторной проверки. Это поможет связать новую ошибку с обновлением CMS, темы или плагина. Повторяйте контроль после изменений шаблонов и правил генерации данных.
Зелёный тест по текущему URL может соседствовать со старой ошибкой в Search Console: отчёт ещё отражает предыдущий обход. Отсутствие ошибки и отсутствие сниппета тоже совместимы. Поисковая система решает, использовать ли данные для конкретного запроса; фиксированного срока и гарантии показа нет.
FAQ
Почему Schema.org находит разметку, а Google ничего не показывает?
В Google-тесте представлены поддерживаемые поисковые функции, а словарь Schema.org шире. Проверьте тип, наличие блока в обработанном HTML и доступность страницы. Отсутствие расширенного результата в выдаче после успешного теста само по себе не доказывает ошибку кода.
Можно ли проверить localhost или страницу под паролем?
Скопируйте HTML или JSON-LD в режим проверки кода. Так можно проверить структуру до публикации. После открытия страницы для роботов обязательно выполните тест по URL: локальная проверка не подтверждает доступность документа и ресурсов.
Нужно ли устранять все предупреждения?
Прочитайте причину каждого предупреждения. Добавляйте рекомендуемые сведения, если они существуют и соответствуют странице. Не создавайте фиктивный рейтинг, автора или изображение. Некоторые предупреждения Яндекса связаны с условиями конкретного сервиса и требуют отдельной проверки.
Почему в Search Console нет отчёта о моей разметке?
Отчёт появляется для поддерживаемых типов, обнаруженных Google на ресурсе; отдельный отчёт есть не для каждого типа. Проверьте URL, индексацию и дату обхода. Список примеров в доступном отчёте также может быть неполным.
Можно ли оставлять несколько блоков JSON-LD?
Да, несколько блоков и типов допустимы. Проверьте, что они описывают реальные связанные сущности, не противоречат друг другу и используют понятные идентификаторы. Два блока с разной ценой одного товара требуют исправления источников данных.
Работают ли FAQPage и HowTo для расширенных результатов Google?
По состоянию на 13 октября 2026 года Google не показывает FAQ rich results: функция прекращена с 7 мая 2026 года. Изменение зафиксировано в журнале обновлений Google Search. Расширенные результаты HowTo прекращены ранее. Типы могут оставаться в словаре Schema.org, однако корректная разметка этих типов не возвращает отменённую поисковую функцию.
Достаточно ли обычного HTML-валидатора?
HTML-валидатор полезен для проверки вёрстки, но не заменяет проверку словаря Schema.org и требований расширенных результатов. Если ошибка HTML нарушает вложенность Microdata, исправьте её, затем повторите тест структурированных данных.