SiteGuard4 ноября 202616 мин чтения

Микроразметка Schema.org: как добавить и проверить структурированные данные

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

Рабочая последовательность выглядит так: выбрать подходящий тип, взять данные из реального содержимого, встроить разметку в шаблон и проверить опубликованный результат. Ниже — практический порядок внедрения Schema.org с примерами, таблицей ошибок и критериями приёмки. Адреса на example.com, названия, даты и изображения в примерах учебные: перед публикацией их нужно заменить сведениями своего проекта.

Что такое микроразметка сайта и как устроена Schema.org

Микроразметка — машиночитаемое описание сущностей и их свойств на странице. Schema.org предоставляет словарь: например, Article обозначает статью, headline — её заголовок, а author — автора. Значением свойства может быть текст, адрес, число или другой объект. Поэтому автора можно описать не строкой «редакция», а отдельной организацией с именем и ссылкой.

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

Разметка не заменяет основной текст, заголовок страницы и описание для посетителя. Она также не равна Open Graph: эти метаданные решают свою задачу представления ссылки в поддерживающих их сервисах. Наличие красивой карточки при отправке URL в мессенджер не подтверждает правильность Schema.org или пригодность страницы для расширенного результата Google.

JSON-LD, Microdata и RDFa

Словарь можно записать разными способами. JSON-LD размещает описание отдельным блоком данных; Microdata и RDFa связывают свойства с HTML через атрибуты. В руководстве Google поддерживаются все три формата, а JSON-LD рекомендуется, когда устройство сайта позволяет его использовать. Его часто удобнее формировать и поддерживать в шаблоне.

Это не повод заменять исправную существующую разметку без задачи. Сначала выясните, какие данные уже получает поисковик и где они управляются. Одновременное использование форматов само по себе не делает страницу неправильной; проблема возникает, когда описания расходятся или относятся к разным сущностям вместо одной.

Что микроразметка даёт SEO и чего от неё не стоит ожидать

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

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

Наличие типа в Schema.org тоже не означает отдельный поисковый эффект. Список поддерживаемых функций меняется. Например, Google прекратил показ FAQ rich results с 7 мая 2026 года; изменение отражено в официальном журнале обновлений. Старый пример FAQPage из плагина или статьи не подтверждает действующую возможность такого оформления.

Для пошаговых инструкций действует отдельное ограничение: Google прекратил показ HowTo rich results с 13 сентября 2023 года, как указано в обновлении Search Central. Сам тип HowTo остаётся в Schema.org, поэтому его наличие в коде не означает ошибку. Однако внедрять его исключительно ради отдельного расширенного результата Google нецелесообразно.

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

Как выбрать тип Schema.org под назначение страницы

Начинайте с вопроса «что здесь получает человек?», а не с поиска самого заметного сниппета. На странице могут сосуществовать статья, сведения об издателе и хлебные крошки. Они описывают разные объекты и дополняют друг друга. Не нужно превращать весь сайт в Product или Article только потому, что модуль позволяет включить этот переключатель глобально.

Содержимое	Подходящий тип	Что проверить до настройки
Редакционный материал или публикация блога	Article, BlogPosting; для новостей — NewsArticle	Заголовок, авторство, даты и изображение относятся к этому материалу
Навигационная цепочка	BreadcrumbList	Элементы отражают понятный путь к странице, а ссылки ведут в нужные разделы
Сведения об организации	Organization или соответствующий подтип	Название, сайт и другие сведения принадлежат реальной организации
Конкретный товар и условия его предложения	Product и связанный Offer	Совпадают товар, цена, валюта, доступность и условия на странице
Местная организация с реальным местом работы	Подходящий подтип LocalBusiness	Выбранный тип, адрес и режим работы соответствуют действительности

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

Для товаров отдельно определите сценарий: обзор или страница, где у вас можно купить товар. Google различает product snippets и merchant listings; требования к ним не одинаковы. Краткий общий пример Product не заменяет проектирование товарных вариантов, предложений и обновления остатков. Начинайте с одного понятного типа карточек, затем расширяйте охват.

Для звёзд в поиске отдельно проверьте правила Google для Review и AggregateRating. Нужны поддерживаемый тип объекта и реальные отзывы или оценки, доступные посетителю на этой странице. Отзывы об организации на её собственном сайте не дают права на звёздный результат для Organization, LocalBusiness и их подтипов; это относится и к встроенному виджету стороннего сервиса. Наличие настоящих отзывов и валидного кода само по себе не снимает это ограничение. Отзывы можно сохранить на странице для посетителей; не меняйте тип организации на Product ради звёзд.

Для каждой выбранной функции заведите карточку решения: тип страницы, тип разметки, ссылка на текущую документацию, необходимые поля и источник каждого значения. Это делает оценку работ предметной. Формулировка «добавить Schema.org на сайт» не показывает, какие шаблоны меняются и что считается готовым результатом.

Что проверить перед добавлением новой разметки

Соберите по нескольку страниц каждого шаблона: обычную статью, материал без изображения, карточку без наличия, страницу организации и вложенный раздел. Посмотрите опубликованный HTML и результат выполнения JavaScript. Разметку уже могут создавать CMS, тема, SEO-плагин, модуль магазина или отдельный скрипт. Запишите, кто формирует каждый блок и где меняются значения.

Затем сопоставьте данные с видимой страницей. Если в шаблоне указан один автор для всех материалов, выясните, соответствует ли это реальному авторству. Если цена выводится из каталога, а Offer хранится в ручном поле, обновление товара может создать расхождение. Для каждого свойства выберите основной источник данных и ответственного за его актуальность.

Несколько блоков и идентификаторы @id

Несколько блоков JSON-LD допустимы: число блоков само по себе не является ошибкой. Проверьте, не описана ли одна организация под разными случайными идентификаторами и не получает ли один товар противоречивые свойства. Полезно заранее согласовать устойчивые идентификаторы, например https://example.com/#organization, и повторно ссылаться на них там, где речь о той же сущности.

Ключ @id идентифицирует объект в модели JSON-LD; принцип описан в спецификации W3C. Это не замена canonical и не команда индексирования. У объекта статьи и у организации должны быть разные идентификаторы, даже если сведения о них находятся на одной странице. Не создавайте новые @id при каждом открытии URL.

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

Примеры JSON-LD: хлебные крошки и статья

Разберём условную публикацию https://example.com/blog/site-check/. На ней видна цепочка «Главная → Блог → Проверка сайта», опубликован материал с указанным заголовком, а автором выступает учебная редакция Example. Примеры показывают структуру данных; это не готовая разметка SiteGuard и не подтверждение существования приведённых страниц или файлов.

BreadcrumbList для навигационной цепочки

Для Google цепочка содержит не менее двух элементов ListItem. У каждого указывают порядок и название; адрес элемента нужен по правилам выбранного представления, при этом для последнего Google допускает отсутствие item. Здесь адреса заданы явно, чтобы связь была понятна. Требования приведены в документации BreadcrumbList.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "@id": "https://example.com/blog/site-check/#breadcrumbs",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Главная",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Блог",
      "item": "https://example.com/blog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Проверка сайта",
      "item": "https://example.com/blog/site-check/"
    }
  ]
}
</script>

Порядок задаётся свойством position. Не подставляйте в name набор ключевых слов: название должно представлять соответствующий раздел или страницу. Цепочка описывает разумный путь пользователя, а не обязана механически повторять все части URL. Перед внедрением проверьте, что каждый адрес ведёт на нужный материал и согласуется с принятой структурой сайта.

BlogPosting для того же материала

Во втором блоке используем тип публикации блога. Заголовок, редакция, даты и изображение должны иметь реальное основание на странице. Для Google Article сейчас нет общего списка обязательных свойств: документация перечисляет рекомендованные, которые следует добавлять, если они применимы. Не переносите требования другого типа на статью.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/site-check/#article",
  "url": "https://example.com/blog/site-check/",
  "headline": "Как проверить сайт перед публикацией",
  "inLanguage": "ru",
  "datePublished": "2026-10-01T10:00:00+03:00",
  "dateModified": "2026-10-15T14:30:00+03:00",
  "image": "https://example.com/images/site-check.jpg",
  "author": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Редакция Example",
    "url": "https://example.com/about/"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/site-check/"
  }
}
</script>

Замените весь учебный набор: адрес материала, @id, заголовок, язык, даты, изображение и сведения об авторе. Даты записаны в ISO 8601 с часовым поясом; dateModified должна отражать действительное обновление, а не время каждого визита. Изображение должно представлять статью и быть доступно поиску. Применимые свойства описаны в руководстве Google для Article.

В рабочий шаблон вставляют настоящий блок script с типом application/ld+json. В этой статье код экранирован, чтобы его можно было прочитать: не переносите в исходный HTML буквальные записи <script как разметку. Обычная вставка примера в визуальный редактор может показать текст посетителю, но не создать данные для поисковика. Способ вставки зависит от CMS.

Как внедрить микроразметку в CMS и шаблоны

Для WordPress, другой CMS или конструктора используйте предусмотренный системой способ: настройку модуля, поле для кода или доработку шаблона. До установки нового расширения проверьте, не решает ли задачу существующий компонент. Важно, чтобы значения формировались из актуальных полей материала, а не из вручную скопированного примера.

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

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

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

Проверка микроразметки: какой инструмент что подтверждает

Проверяйте сначала подготовленный код, затем опубликованный URL. Первый режим удобен для исправления структуры; второй позволяет обнаружить различия между образцом и реальным сайтом. Если данные создаются JavaScript, проверка только вставленного фрагмента не воспроизводит все условия загрузки страницы.

Инструмент	Для чего применять	Чего результат не доказывает
Schema Markup Validator	Увидеть распознанные сущности Schema.org и ошибки структуры	Соответствие всем требованиям конкретного оформления Google
Google Rich Results Test	Проверить поддерживаемые Google типы и связанные требования	Гарантированный показ расширенного результата
Валидатор Яндекс Вебмастера	Проверить распознавание и применимые требования сервисов Яндекса	Автоматическое использование всех свойств в выдаче
Проверка URL в Search Console	Сопоставить известную Google версию и текущую опубликованную страницу	Мгновенное обновление индекса после исправления

Проверка словаря и структуры

Schema Markup Validator полезен, когда нужно проверить именно Schema.org, включая типы без отдельной функции Google. Официальное описание валидатора перечисляет извлечение JSON-LD, Microdata и RDFa и поиск синтаксических ошибок. Просмотрите распознанные объекты и их свойства: отсутствие красного сообщения ещё не подтверждает правильность смысла.

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

Google Rich Results Test

Используйте проверку расширенных результатов Google для выбранной поддерживаемой функции. Откройте найденный объект и разберите каждое сообщение: к какому свойству оно относится и мешает ли пригодности объекта. Различие Google-проверки и общей проверки Schema.org описано на странице инструментов Search Central.

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

Яндекс и текущая опубликованная страница

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

После публикации в Search Console сравните данные известной Google версии с текущей проверкой URL. Справка инструмента различает эти режимы. Если сохранённые данные относятся к обходу до исправления, сначала учитывайте эту дату. Успешный live-тест не означает, что индекс уже обновлён или оформление появилось в поиске.

Типичные ошибки и что исправлять в первую очередь

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

Проблема	Вероятная причина	Что проверить и исправить
JSON не читается	Лишняя запятая, неверные кавычки, повреждённая строка	Сериализацию и значение, на котором ломается блок
Тип или свойство не распознаны	Опечатка, неверный регистр, неподходящий словарь	Название термина и его назначение в документации
Нет обязательного свойства функции	Неполная модель или пустое поле CMS	Требование конкретного типа и реальный источник значения
Цена, автор или даты расходятся с контентом	Ручная копия данных либо старый кэш	Основной источник, обновление и итоговый ответ страницы
Два описания одного объекта противоречат друг другу	Тема и плагин независимо формируют данные	Ответственность компонентов, идентификаторы и согласованность свойств
Код проходит тест, но оформления нет	Обработка ещё не обновилась, функция неприменима или не выбрана системой	Доступность, даты обхода, действующие правила и соответствие контенту

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

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

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

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

Сверьте сведения с контентом. Заголовок, автор, предложение и даты должны относиться к выбранной странице.
Проверьте все источники разметки. Убедитесь, что после внедрения не остался второй компонент с противоречивыми значениями.
Оцените доступность. Публичная страница и нужные изображения должны загружаться; ограничения индексирования проверяются отдельно.
Проверьте код и опубликованный URL. Устраните критические ошибки, а неприменимые рекомендованные поля зафиксируйте с объяснением.
Повторите проверку после обновления данных. Измените учебный пример на тестовой среде или проверьте согласованное штатное обновление: новое значение должно появиться и в видимом блоке, и в разметке.

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

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

Как поддерживать разметку после запуска

Сохраните карту «шаблон → тип → источник данных → ответственный». Она особенно полезна после смены темы, миграции CMS, подключения магазина и переработки авторских профилей. Когда данные формируются из общего источника, редактору не приходится помнить о второй ручной копии; однако это нужно подтвердить проверкой обновления.

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

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

Ответы на частые вопросы

Можно ли добавить микроразметку без программиста?

Часто CMS позволяет настроить тип и основные поля через модуль. Но после сохранения всё равно нужно проверить опубликованную страницу, соответствие данных и возможные конфликты с темой. Для сложных товарных вариантов или собственной модели данных может потребоваться разработчик.

Нужна ли микроразметка каждой странице?

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

Можно ли просто скопировать разметку конкурента?

Чужой пример может подсказать структуру, но содержит сведения другой организации, другие предложения и идентификаторы. Используйте первичную документацию и свои данные. Копирование чужих рейтингов или контактов создаёт ложное описание, даже если JSON проходит проверку.

Почему Schema Markup Validator видит данные, а Google-тест нет?

Инструменты решают разные задачи. Общий валидатор разбирает Schema.org, а Google-тест проверяет поддерживаемые функции. Уточните тип, формат, фактическую страницу и режим проверки; отсутствие конкретного rich result не равно отсутствию любых структурированных данных.

Нужно ли заполнять все рекомендованные свойства?

Добавляйте достоверные и применимые сведения. Рекомендация не разрешает выдумывать значение. Обязательные условия проверяйте в документации выбранной функции: единого списка для всех типов Schema.org нет.

Когда появится расширенный результат?

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

После внедрения микроразметки закрепите за командой проверку шаблонов и актуальности данных при обновлении контента. Регулярный контроль работы и доступности сайта дополнит этот процесс; оцените SiteGuard как сервис мониторинга для вашего проекта.