Главная / Руководства
Техническое SEO

Как проверить микроразметку Schema.org и JSON-LD

Микроразметка помогает поисковой системе интерпретировать сущности и свойства страницы. Но ошибочная или вымышленная разметка не делает контент качественнее и не гарантирует расширенный результат.
4

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

Как внедрять структурированные данные осмысленно

  1. Выберите тип исходя из реальной страницы

    Для редакционного материала чаще подходит Article или BlogPosting, для навигационной иерархии — BreadcrumbList. У справочного определения может быть уместен DefinedTerm, но наличие типа в Schema.org не означает поддержки отдельного расширенного результата Google. Сверяйтесь с документацией по конкретной поисковой функции, а не с общим перечнем типов.

  2. Соберите только подтверждённые значения

    Название, описание, дата, изображение и автор должны отражать видимое содержимое страницы. Если реального автора нет, не подставляйте случайное имя. Если нет подтверждённых отзывов, не добавляйте aggregateRating. Организация должна быть описана корректно, без вымышленных регистрационных данных и контактных сведений. Сопоставьте значения с HTML, Title и OG.

  3. Разместите JSON-LD в корректной форме

    Часто данные помещают в скрипт type="application/ld+json" в HTML-документ. Убедитесь, что JSON синтаксически корректен, ссылки абсолютные и даты имеют ожидаемый формат. В CMS-шаблоне проверьте, подставляются ли динамические поля для каждой записи; одна и та же дата или заголовок во всех статьях — сигнал ошибочной привязки.

  4. Выполните два вида тестов

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

  5. Проверяйте разметку после изменений шаблона

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

Пример: разметка статьи в CMS

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

Минимальный пример разметки

Для обычной статьи JSON-LD обычно содержит тип BlogPosting или Article, название, дату публикации и иные достоверные свойства. Пример структуры: {"@context":"https://schema.org","@type":"Article","headline":"Название материала"}. Это только учебный фрагмент, не универсальный готовый код: для конкретного расширенного результата могут понадобиться дополнительные поля. При генерации через CMS важно экранировать кавычки и символы, чтобы пользовательский заголовок не повреждал JSON.

Разница между проверкой Schema.org и Google

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

Как соотносить типы и страницы

ТипНазначениеОграничение
BlogPosting / ArticleРедакционная публикация.Данные должны совпадать с видимой статьёй.
BreadcrumbListРеальная навигационная цепочка.Порядок и URL должны соответствовать иерархии.
OrganizationДостоверные сведения об организации.Не выдумывать юрлицо и контакты.
FAQPageТолько при соответствии правилам и формату страницы.Не ожидать расширенный результат автоматически.

Что мешает корректной работе

  • Подстановка одинакового названия и даты во все CMS-страницы.
  • Размещение скрытых отзывов и рейтингов, которых посетитель не видит.
  • Использование неподдерживаемого типа ради предполагаемого SEO-бонуса.
  • Проверка только кода из редактора без осмотра опубликованной страницы.

Финальная проверка

  • JSON-LD синтаксически корректен.
  • Тип совпадает с назначением страницы.
  • Поля подтверждены видимым содержимым.
  • Проверены опубликованные URL с различными данными.
  • Ожидания от расширенного результата не выданы за гарантию.

Что делать после внедрения

Оценивайте структурированные данные как средство ясного описания содержания и возможной пригодности к определённым элементам выдачи. Если Google показывает обычный результат, это не обязательно ошибка. Главное — корректность, соответствие реальному контенту и отсутствие конфликтов с CMS-шаблоном.

Первоисточники и документация

Made on
Tilda