Микроразметка помогает поисковой системе не просто прочитать текст страницы, а распознать сущности и связи: где находится название организации, кто автор статьи, какой товар продаётся, сколько он стоит и какое место страница занимает в навигационной цепочке. Для этого сведения записывают в стандартизированном виде, чаще всего с помощью словаря Schema.org и формата JSON-LD.
Но микроразметка работает не по принципу «добавили код — получили звёзды и больше трафика». Валидный синтаксис является только первым условием. Данные должны соответствовать видимому содержанию, тип страницы — поддерживаемой поисковой функции, обязательные свойства — требованиям конкретной системы, а сама страница — быть доступной для обхода и индексации. Поэтому правильная задача состоит не в установке «плагина Schema», а в построении согласованной модели данных сайта.
Рабочая модель SEO Papa: страница → сущность → свойства → формат → требования поисковика → проверка → наблюдение. Сначала определяем, что реально находится на странице, затем описываем это подходящей схемой и только после этого оцениваем возможное представление в выдаче.
Что такое микроразметка сайта
В русскоязычном SEO словом «микроразметка» часто называют любые структурированные данные на странице. Технически Microdata — только один из форматов наряду с JSON-LD и RDFa, но в практической речи термин стал шире. В этой статье под микроразметкой понимается весь слой машиночитаемых сведений, описывающих содержание документа.
Schema.org — словарь типов и свойств. Он содержит понятия Organization, Person, Article, Product, Offer, BreadcrumbList и многие другие. Формат отвечает на другой вопрос: как записать выбранные понятия в коде страницы. Один и тот же объект можно описать с помощью JSON-LD, Microdata или RDFa.
Структурированные данные не заменяют обычный HTML. Пользователь по-прежнему должен видеть название, цену, автора, дату и другую важную информацию на странице. Разметка создаёт дополнительный машиночитаемый слой, а не скрытую параллельную версию контента.
Зачем поисковым системам структурированные данные
Обычный текст допускает неоднозначность. Строка «Минск, 25 октября, 150 рублей» может относиться к событию, доставке или цене услуги. Разметка связывает значения с определённой сущностью и свойствами: местом проведения, датой начала и стоимостью предложения.
Google объясняет, что использует структурированные данные для понимания содержания и формирования поддерживаемых расширенных результатов. Яндекс также обрабатывает Schema.org для отдельных представлений и сервисов. Это особенно полезно там, где на странице есть повторяемые поля: товары, события, рецепты, вакансии, статьи, организации и навигационные цепочки.
Польза есть и внутри проекта. Единая модель заставляет команду определить источник цены, статуса наличия, даты обновления и данных автора. При аудите быстро обнаруживаются противоречия: на странице одна цена, в JSON-LD другая, а в товарном фиде третья.
Чего микроразметка не гарантирует
Корректная разметка не гарантирует расширенный результат, рост позиции или увеличение CTR. Google прямо указывает, что даже валидные структурированные данные лишь делают страницу потенциально подходящей для определённого вида выдачи. Алгоритм может оставить обычный сниппет в зависимости от запроса, устройства, качества страницы и других факторов. Правила описаны в общих рекомендациях Google.
Микроразметка не исправляет слабое содержание и не открывает закрытую страницу. Если URL запрещён для робота, содержит noindex, возвращает ошибку или не имеет внутренних ссылок, поисковик может не обработать добавленный код. Сначала нужно решить проблему индексации сайта.
Наконец, Schema.org не является каталогом гарантированных поисковых функций. Словарь значительно шире перечня разметки, которую конкретный поисковик использует в выдаче. Наличие типа в Schema.org означает, что им можно описать сущность, но не обещает специальный сниппет.
Четыре уровня, которые нельзя смешивать
Большинство ошибок возникает, когда словарь, формат и поисковую функцию считают одним и тем же. На практике это четыре разных уровня.
| Уровень | Пример | Главный вопрос |
|---|---|---|
| Содержимое страницы | Статья, товар, компания, событие | Что реально видит пользователь? |
| Словарь | Schema.org: Article, Product, Organization | Какими типами и свойствами описать сущность? |
| Формат записи | JSON-LD, Microdata, RDFa | Как поместить данные в HTML? |
| Требования поисковика | Google Search Gallery, схемы Яндекса | Может ли система использовать разметку для особого представления? |
Например, тип Product берётся из Schema.org, записывается в JSON-LD и может соответствовать требованиям Google к товарному результату. Но для этого страница должна действительно описывать товар, а объект — содержать необходимые для выбранной функции свойства.
JSON-LD, Microdata и RDFa: какой формат выбрать
Google поддерживает три формата: JSON-LD, Microdata и RDFa, при этом рекомендует JSON-LD, если платформа позволяет его использовать. JSON-LD размещается отдельным блоком <script type="application/ld+json"> и не требует добавлять атрибуты к каждому видимому HTML-элементу. Поэтому его проще поддерживать и обновлять по шаблону.
Microdata внедряется прямо в разметку видимых элементов через itemscope, itemtype и itemprop. Такой вариант бывает удобен, когда CMS уже генерирует его, но при сложном шаблоне код становится громоздким. RDFa решает похожую задачу набором HTML-атрибутов и чаще встречается в существующих системах, чем в новых SEO-внедрениях.
Не нужно одновременно размечать один объект тремя форматами. Дублирование повышает риск расхождений: один модуль обновит цену в JSON-LD, а старый шаблон оставит другое значение в Microdata. Для нового проекта обычно рационально выбрать JSON-LD как основной формат и удалить конфликтующие генераторы.
Модель «страница → сущность → свойства → проверка»
Начните с роли страницы. Главная страница представляет организацию, статья — публикацию, карточка — товар или услугу, а страница события — конкретное мероприятие. Затем выберите основную сущность и перечень фактов, которые реально присутствуют в интерфейсе.
После этого определите источник каждого свойства. Название может поступать из H1, изображение — из поля записи, дата — из базы, автор — из профиля, цена и наличие — из товарной системы. Если источник не определён, разметка быстро устареет.
Только затем выбирайте тип Schema.org и проверяйте документацию поисковиков. В результате получается не случайный фрагмент кода, а воспроизводимое правило для целого шаблона страниц.
Проведите инвентаризацию до внедрения
Составьте список типов страниц: главная, услуги, категории, товары, статьи, авторы, контакты, события и служебные разделы. Для каждого типа укажите основную сущность, доступные поля, количество URL и действующие источники разметки.
Проверьте исходный код и отрисованный HTML. Плагин темы, SEO-плагин, модуль интернет-магазина и конструктор страниц могут независимо генерировать Organization, WebSite, Article или BreadcrumbList. Визуально это незаметно, но валидатор покажет несколько объектов с разными значениями.
Такую инвентаризацию удобно включать в технический SEO-аудит: она выявляет не только синтаксические ошибки, но и отсутствие владельца данных, дублирующие плагины и шаблоны, где один тип разметки ошибочно применяется ко всем URL.
Результат инвентаризации лучше оформить как таблицу требований для разработчика: шаблон, основной объект, обязательные поля, источник каждого значения, ответственный модуль и контрольный URL. Тогда задача «добавить Schema» превращается в проверяемое техническое задание. В нём отдельно фиксируют поведение при пустом поле: например, если у статьи нет изображения, система не должна подставлять чужой файл или публиковать пустой image.
Как выбрать главную сущность страницы
Основная сущность должна совпадать с назначением URL. Если страница посвящена одной статье, главным объектом будет Article или более точный подтип. Если пользователь выбирает товар и видит предложение, логичен Product с Offer. Если страница рассказывает о компании, основным объектом может быть Organization или подходящий подтип.
Не выбирайте тип по желаемому сниппету. Добавление Product на информационную статью ради цены или Event на обычную страницу услуги не меняет реальную природу документа и может рассматриваться как вводящее в заблуждение.
У страницы могут быть вспомогательные сущности: автор, издатель, хлебные крошки, изображение, видео. Их следует связать с главным объектом, а не публиковать как случайный набор независимых блоков.
Разметка Organization
Organization описывает компанию: название, официальный URL, логотип, контактные сведения и проверяемые профили. Google рекомендует размещать организационные данные на главной странице или на одной странице, подробно описывающей организацию, а не создавать полный дубль на каждом URL.
Выберите один устойчивый идентификатор @id, например https://example.com/#organization, и используйте его при ссылках на издателя статей или владельца сайта. Это помогает соединять сведения из разных объектов в один граф.
Разметка должна отражать фактическую компанию. Не добавляйте категории, награды, телефоны или профили, которых нет либо которые невозможно подтвердить. Для региональных филиалов и разных юридических лиц сначала определите архитектуру данных, иначе несколько блоков будут конкурировать за роль основной организации.
Разметка Article и BlogPosting
Для публикации обычно используют Article, BlogPosting или более точный тип, если он соответствует содержанию. В объект включают заголовок, основное изображение, даты публикации и изменения, автора, издателя и канонический URL страницы.
Дата изменения должна обновляться только при содержательном редактировании, а не при каждом техническом сохранении WordPress. Имя автора должно вести к реальному человеку или организации, которые отвечают за материал. Если на сайте есть авторские страницы, они помогают связать публикации с профилями.
Не подменяйте разметкой видимые элементы. Читатель должен видеть автора и даты, если вы передаёте их поисковику. Связь статей между собой и с тематическими разделами дополнительно укрепляет внутренняя перелинковка.
BreadcrumbList и навигационные цепочки
BreadcrumbList описывает путь пользователя от более общего раздела к текущей странице. Каждый элемент получает позицию, название и URL. Разметка должна соответствовать видимым хлебным крошкам и логике сайта, а не автоматически повторять физические папки адреса.
Убедитесь, что все промежуточные страницы доступны, отвечают 200 и являются каноническими. Не включайте параметры, редиректы или несуществующие рубрики. Правила структуры адресов подробнее разобраны в материале о ЧПУ-ссылках.
Хлебные крошки полезны не только поисковику: они дают посетителю понятный маршрут и создают дополнительные внутренние ссылки. Поэтому сначала внедряют корректную навигацию, затем описывают её структурированными данными.
Product, Offer и товарные страницы
Product описывает товар, а вложенный Offer — конкретное предложение: цену, валюту, наличие, продавца и URL. Если вариантов или продавцов несколько, может потребоваться другая модель, например AggregateOffer. Выбор зависит от фактического интерфейса и официальных требований поисковой функции.
Цена и наличие особенно чувствительны к устареванию. JSON-LD должен получать их из того же источника, что и видимый блок покупки. Нельзя оставлять InStock, когда товар закончился, или передавать рекламную цену, которой нет на странице.
Для интернет-магазина микроразметка является только одним каналом данных. Товарные фиды и кабинеты продавца могут дополнять её, но значения должны быть согласованы. Несовпадение создаёт ошибки и снижает доверие к источнику.
LocalBusiness и страницы услуг
LocalBusiness и его подтипы подходят организации с реальным локальным присутствием: адресом, графиком работы, телефоном и зоной обслуживания. Это один из элементов локального SEO, где сведения на сайте, в профилях компании и во внешних источниках должны подтверждать друг друга. Не следует создавать отдельный объект для каждого города, если компания работает удалённо и не имеет самостоятельных филиалов.
Страница отдельной услуги не превращается в отдельную организацию. На ней можно связать предложение с основной компанией, но тип и свойства должны отражать фактическую модель бизнеса. Не дублируйте полный адрес и набор профилей в нескольких противоречивых объектах.
Если услуга имеет фиксированную цену, условия и доступность, выбирайте схему по документации конкретной поисковой системы. Не стоит маркировать услугу как товар только ради попытки получить товарный сниппет.
Какие типы выбирать для разных страниц
Ниже приведена карта решений, а не универсальный список обязательной разметки. Перед внедрением проверяйте актуальную галерею структурированных данных Google и перечень поддерживаемых схем Яндекса.
| Страница | Основная сущность | Частые связанные объекты |
|---|---|---|
| Главная компании | Organization или LocalBusiness | WebSite, логотип, контакты |
| Статья блога | Article или BlogPosting | Person, Organization, ImageObject, BreadcrumbList |
| Карточка товара | Product | Offer, AggregateRating, Review при наличии оснований |
| Страница события | Event | Place, Offer, Organization |
| Профиль автора | ProfilePage и Person | Публикации, проверяемые профили |
| Внутренняя страница | Сущность по содержанию | BreadcrumbList |
Не каждая строка должна быть внедрена на каждом проекте. Минимальный качественный набор лучше десятка пустых или неподдерживаемых объектов.
Общие типы WebSite и WebPage могут помогать связывать элементы графа, но не создают самостоятельный расширенный результат только из-за своего присутствия. Их добавляют как часть последовательной модели, а не для увеличения количества найденных валидатором объектов.
Отзывы и рейтинги: зона повышенного риска
Review и AggregateRating должны описывать реальные отзывы о той сущности, которой посвящена страница. Оценка должна быть видна пользователю, получена понятным способом и соответствовать представленному набору отзывов. Нельзя придумывать средний рейтинг, переносить оценки между услугами или размечать только удобную часть данных.
Проверка синтаксиса не определяет достоверность. Код с пятью звёздами может быть технически валидным и одновременно нарушать требования качества. Поэтому ответственность за источник и актуальность рейтинга нельзя перекладывать на плагин.
Перед внедрением проверьте правила выбранного поисковиком типа: возможность отображения звёзд зависит от сущности и контекста. Если специальное представление не поддерживается, не нужно менять тип страницы или создавать искусственный объект.
FAQPage и другие популярные схемы
Разметка FAQ не является универсальным способом расширить сниппет коммерческого сайта. Google ограничивает показ FAQ rich results известными авторитетными государственными и медицинскими сайтами. Поэтому обычному бизнесу не стоит создавать десятки вопросов только ради ожидаемого блока в выдаче.
Это не запрещает делать полезный видимый FAQ для посетителей. Но решение о содержании принимается по потребностям аудитории, а не ради разметки. Если FAQPage используется, вопросы и ответы должны быть полностью доступны на странице и соответствовать официальным требованиям.
Тот же принцип относится к HowTo, VideoObject, Event и другим популярным типам: сначала реальный формат контента, затем актуальная документация поисковика, после — код.
Как связать несколько сущностей через @id
На одной странице могут находиться статья, автор, издатель, изображение, веб-страница и навигационная цепочка. Вместо копирования одних и тех же данных каждому объекту назначают стабильный @id и связывают ссылками.
Например, статья указывает publisher на https://example.com/#organization, а mainEntityOfPage — на канонический URL с идентификатором #webpage. Это позволяет обновлять описание организации централизованно и сохранять понятный граф.
@id не обязан открываться как отдельная страница после фрагмента, но его основная URL-часть должна быть стабильной. Не генерируйте новый идентификатор при каждом запросе и не используйте разные @id для одной компании в разных шаблонах.
Обязательные и рекомендуемые свойства
Schema.org показывает допустимые свойства типа, а поисковая документация разделяет их на обязательные и рекомендуемые для конкретного представления. Отсутствие обязательного поля обычно делает объект непригодным для соответствующего rich result. Отсутствие рекомендуемого может ограничить полноту результата, но не всегда является критической ошибкой.
Добавляйте только свойства, для которых есть достоверные значения. Пустое поле, фиктивная цена или изображение-заглушка хуже честно отсутствующего необязательного свойства. Не копируйте максимальный пример из документации, если половина его данных не относится к странице.
После изменений требований обновляйте шаблоны централизованно. Разметка является частью продукта, а не одноразовой SEO-вставкой.
Актуальность динамических данных
Товары, события и вакансии меняются быстрее статей. Цена, наличие, дата окончания, место, статус регистрации и срок действия предложения должны обновляться одновременно с видимым интерфейсом. Иначе поисковая система получает устаревшее обещание.
Определите источник истины для каждого поля и частоту обновления. Если страница кэшируется, убедитесь, что HTML и JSON-LD очищаются вместе. При загрузке разметки через JavaScript проверьте отрисованную версию в инструменте инспекции URL, а не только исходный код браузера.
Удалённую сущность нельзя сохранять в разметке страницы 404. После окончания события или вакансии действуйте по правилам конкретного типа: обновите статус, оставьте архив с корректной информацией или удалите страницу и обработайте URL.
Как внедрять микроразметку в WordPress и CMS
Сначала выясните, что уже создают тема, SEO-плагин, WooCommerce и конструктор. Затем назначьте один источник каждому типу объекта. Например, SEO-плагин отвечает за Organization и Article, магазин — за Product, а тема — только за видимые хлебные крошки.
Не устанавливайте второй плагин исключительно потому, что в его названии есть Schema. Два генератора часто создают дубли. Если стандартный модуль не позволяет передавать нужные поля, его можно расширить фильтрами, шаблоном или отдельным контролируемым JSON-LD-блоком.
После обновления плагинов повторно тестируйте несколько шаблонов. Изменение разметки может произойти без заметного изменения дизайна. Такие проверки входят в системную техническую оптимизацию сайта.
Пример JSON-LD для статьи
Ниже — учебный каркас, а не готовый фрагмент для слепого копирования. Все URL, даты, изображения и автор должны формироваться из реальных данных конкретной публикации.
{"@context":"https://schema.org","@type":"Article","@id":"https://example.com/blog/article/#article","headline":"Заголовок статьи","datePublished":"2026-10-11","dateModified":"2026-10-11","image":["https://example.com/images/article.webp"],"author":{"@type":"Person","name":"Имя автора","url":"https://example.com/author/"},"publisher":{"@id":"https://example.com/#organization"},"mainEntityOfPage":{"@id":"https://example.com/blog/article/#webpage"}}Блок вставляют в <head> или <body> внутри <script type="application/ld+json">. Кавычки, запятые и типы значений должны оставаться корректными. Дата передаётся в понятном машинном формате, а изображение и канонический адрес — абсолютными URL.
Как проверить микроразметку до публикации
Одного валидатора недостаточно, потому что инструменты отвечают на разные вопросы. Проверку удобнее проводить по цепочке.
Schema Markup Validator
Валидатор Schema.org показывает найденные типы, свойства и ошибки словаря. Он полезен для общей структуры, включая типы, которым Google не обещает отдельного rich result.
Rich Results Test Google
Проверка расширенных результатов определяет, распознаёт ли Google поддерживаемый тип и какие критические или некритические проблемы видит. Отсутствие ошибки означает техническую пригодность, а не гарантию показа.
Валидатор Яндекса
Яндекс Вебмастер предоставляет валидатор для Schema.org, микроформатов, Open Graph, Microdata и RDFa. Проверяйте как фрагмент кода, так и опубликованный URL; перечень инструментов описан в справке Яндекса.
Проверка отрисованной страницы
После публикации используйте инспекцию URL, чтобы увидеть доступную роботу версию. Это особенно важно при JavaScript, кэшировании, геозависимых данных и разметке, которая появляется только после согласия на cookie.
Запускайте разметку на контрольной группе
Для крупного сайта не меняйте все шаблоны одновременно. Выберите несколько типичных страниц каждого типа, добавьте разметку, проверьте исходный и отрисованный HTML, коды ответа, canonical и доступность для робота.
После индексации оцените отчёты и только затем расширяйте внедрение. Такой пилот обнаруживает системные ошибки до того, как они появятся на тысячах URL: неверную валюту, пустое изображение, конфликт типов или устаревший кэш.
Если внедрение сопровождается публикацией новых страниц или изменением канонических адресов, обновите Sitemap.xml. Простое добавление JSON-LD не требует создавать новый URL или отдельную XML-карту: поисковику нужна актуальная каноническая страница, а не специальный файл с микроразметкой.
Для сравнения зафиксируйте дату релиза и список тестовых страниц. Но не обещайте рост кликов только из-за микроразметки: выдача и набор поддерживаемых функций меняются, а расширенный результат может появляться не по каждому запросу.
Как контролировать результат после внедрения
В Search Console следите за отчётами улучшений для тех типов, для которых они доступны, и за разделом неразбираемых структурированных данных. Новые ошибки сопоставляйте с датами релизов темы, плагинов и шаблонов. Google позволяет наблюдать поддерживаемые rich results через отчёты Search Console.
В Яндекс Вебмастере проверяйте сообщения валидатора и изменения представления страниц. Одновременно контролируйте индексирование: разметка бесполезна, если робот не может получить канонический URL. Не закрывайте страницу или необходимые ресурсы необдуманным правилом robots.txt.
Сравнивайте показы, клики и CTR только на достаточном периоде и с учётом изменений запросов, позиций и сезона. Расширенное представление может влиять на заметность, но причинность нужно подтверждать данными, а не одним красивым скриншотом.
Чек-лист внедрения Schema.org
Чек-лист следует применять к каждому шаблону, а не к одной удачной странице. Карточка без ошибок не подтверждает, что тысяча товаров получает корректные цены и изображения.
Типичные ошибки микроразметки
Самая частая ошибка — описывать желаемый объект вместо реального содержимого. За ней следуют дубли от нескольких плагинов, несовпадение видимых и размеченных данных, неверная вложенность и устаревшие цены. Технически корректный JSON не спасает модель, которая вводит в заблуждение.
Другие проблемы: относительные или закрытые изображения, неканонические URL, дата изменения при каждом открытии страницы, автор без профиля, разные @id одной организации и разметка на странице с noindex. Иногда разработчик проверяет только исходный HTML, хотя JavaScript удаляет или заменяет блок после загрузки.
Ошибки нужно исправлять по приоритету.
| Сигнал | Пример | Действие |
|---|---|---|
| Критическая ошибка | Нет обязательного свойства, неверный тип значения | Исправить до массового запуска |
| Предупреждение | Отсутствует полезное рекомендуемое поле | Оценить наличие достоверных данных и дополнить |
| Несоответствие контенту | В коде есть цена или рейтинг, которых нет на странице | Удалить или синхронизировать немедленно |
| Дублирование | Два объекта описывают одну компанию по-разному | Оставить один источник и связанный граф |
| Нет rich result при валидном коде | Страница подходит технически, но функция не показана | Проверить правила, индексирование и данные; не считать это автоматической ошибкой |
Частые вопросы о микроразметке
Влияет ли Schema.org напрямую на позиции?
Поисковики не обещают повышение позиции за сам факт разметки. Она помогает понять сущности и может сделать страницу подходящей для поддерживаемого расширенного представления, но содержание и остальные сигналы SEO остаются определяющими.
Обязательно ли использовать JSON-LD?
Нет. Google поддерживает JSON-LD, Microdata и RDFa, но рекомендует JSON-LD как более удобный для внедрения и масштабного сопровождения. Если существующая Microdata корректна и поддерживается, срочная миграция не обязательна.
Нужно ли размечать каждую страницу?
Нет. Размечайте фактические сущности на подходящих шаблонах. Служебная страница или простой список может не требовать отдельного основного объекта помимо базовой архитектуры сайта.
Можно ли поставить несколько типов на одну страницу?
Да, если на странице действительно есть несколько связанных сущностей. Важно определить главную, связать остальные через свойства и @id и не создавать противоречащие дубли.
Почему валидатор не показывает ошибок, но расширенного результата нет?
Валидатор проверяет техническую пригодность и часть правил. Показ не гарантирован и зависит от поддержки типа, качества страницы, соответствия контенту, индексации и решения алгоритма для конкретного запроса.
Нужна ли микроразметка для Яндекса и Google одновременно?
Единый словарь Schema.org позволяет использовать общую основу, но требования и поддерживаемые представления различаются. Проверяйте один код инструментами обеих систем и не предполагайте, что результат будет одинаковым.
Как часто проверять разметку?
Проверяйте после внедрения, изменения шаблона, обновления плагинов и появления сообщений в поисковых кабинетах. Для магазина и событий полезен регулярный автоматический контроль динамических полей.
Итог: размечайте данные, а не ожидания
Хорошая микроразметка начинается с правдивой модели страницы. Schema.org предоставляет словарь, JSON-LD — удобный формат, а Google и Яндекс определяют собственные поисковые функции и требования. Эти уровни нужно связывать, но нельзя подменять один другим.
Сначала проведите инвентаризацию и устраните дубли, затем выберите главные сущности, подключите реальные источники данных, проверьте пилотные URL и настройте наблюдение. Расширенный результат считайте возможностью, а не обещанным эффектом.
Если на сайте уже работают несколько плагинов, товарные фиды и динамические шаблоны, микроразметку разумно внедрять в рамках системного SEO-продвижения в Google: так код, индексирование, содержание и измерение результата останутся частью одной стратегии.
