Микроразметка Product для интернет-магазина: пример и проверка

Микроразметка Product описывает товар для поисковых систем, а вложенный Offer — условия его продажи: цену, валюту и доступность для заказа. Для карточки интернет-магазина эти данные обычно формируют из той же системы, которая показывает покупателю товар и цену. Затем проверяют разметку отдельно в инструментах Google и Яндекса: у поисковиков различаются требования к расширенному показу.

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

Чем отличаются Product, Offer и формат JSON-LD

Schema.org — словарь типов и свойств. Product обозначает сам товар: например, зелёную керамическую кружку определённой модели. Offer описывает конкретное предложение продавца. Та же модель может продаваться у нескольких продавцов по разной цене, поэтому товар и коммерческие условия разделены.

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

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

С какой страницы начать внедрение

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

Разметка одного товара не превращает страницу категории с десятками разных моделей в карточку Product. И Google, и Яндекс предъявляют условия к страницам, на которых ожидается товарный показ. Начните с конкретного товара; разметку каталога рассматривайте как отдельную задачу.

Не добавляйте поля просто потому, что они встретились в примере. Внутренний артикул sku берут из каталога. GTIN — международный идентификатор торговой единицы, MPN — номер товара у производителя; их указывают только при наличии настоящих кодов. Случайная последовательность цифр не заменяет код производителя. Для рейтинга и отзывов нужны настоящие данные и соблюдение отдельных правил поисковика, поэтому в базовом примере их нет.

Пример Product с одним предложением

Учебная карточка продаёт зелёную кружку объёмом 350 мл за 1 490 ₽. Предположим, бренд указан на странице, товар новый и доступен к заказу. Ниже условные название бренда, артикул и адреса на example.com; они не относятся к реальному магазину и должны быть заменены данными вашей карточки.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Керамическая кружка, зелёная, 350 мл",
  "description": "Зелёная керамическая кружка объёмом 350 мл с ручкой.",
  "image": "https://example.com/media/mug-green.webp",
  "sku": "MUG-GREEN-350",
  "brand": {
    "@type": "Brand",
    "name": "Лён и дом"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/catalog/mug-green",
    "price": "1490.00",
    "priceCurrency": "RUB",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>

Это пример структуры, а не блок для одинаковой вставки во весь каталог. Шаблон должен подставлять данные открытого товара и безопасно сериализовать их в JSON. Ручная склейка строк может сломать запись, если в названии встретятся кавычки, переносы или специальные символы.

Поле	Что подставить	Как проверить
name, description	Название и описание текущего товара	Они относятся к тому же предмету и варианту, который виден на странице
image	Доступный абсолютный адрес основного фото	Файл открывается без входа, показывает нужный товар и цвет
brand	Настоящий бренд	Название не придумано ради заполнения поля
sku	Внутренний артикул при его наличии	Совпадает с учётной записью выбранного товара
offers.price	Текущая цена предложения	Нет символа ₽ и пробелов; десятичный разделитель — точка
priceCurrency	Код валюты, для рублей RUB	Цена действительно выражена в этой валюте
availability	Статус возможности заказа	Не обещает наличие, если заказать товар нельзя
url	Адрес соответствующего предложения	Открывает правильную карточку или вариант

Например, если на странице кружка стоит 1 290 ₽ по действующей общедоступной акции, оставлять в price старые 1 490 нельзя. Если её уже нельзя заказать из-за отсутствия, замените https://schema.org/InStock на https://schema.org/OutOfStock. Предзаказ — другое состояние: для него есть PreOrder, но указывать его следует только при реальной возможности предзаказа. Изменить только видимый текст и забыть разметку — значит оставить роботу другую версию предложения.

У Google есть разные способы товарного показа

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

Возможность Google	Для каких страниц предназначена	Базовые условия для Product
Product snippets, товарные расширенные результаты	В том числе страницы с информацией о товаре, где покупка не предусмотрена	name и хотя бы одно из offers, review, aggregateRating
Merchant listings, представление предложений продавца	Страницы, на которых покупатель может приобрести товар	name, image, offers типа Offer

В примере интернет-магазина есть настоящее предложение, поэтому не нужно придумывать отзывы, чтобы выполнить альтернативное требование для Product snippets. Для Merchant listings предложение должно содержать цену и валюту; цена должна быть больше нуля. Документация также описывает дополнительные рекомендуемые поля, включая сведения о доставке и возврате. Они помогают точнее описать предложение, но не оправдывают вымышленные сроки или условия.

Списки товаров и информационные статьи не становятся предложениями продавца только из-за наличия блока Offer. Выбирайте тип проверки по назначению страницы. В Google Rich Results Test смотрите, какие именно объекты и возможности найдены, а не только зелёный итог теста.

Когда нужен AggregateOffer и что делать с вариантами

AggregateOffer описывает совокупность предложений, например диапазон цен нескольких продавцов одного товара. В Google Product snippets он может применяться внутри offers, но не заменяет Offer для Merchant listings. Он также не служит универсальным решением для размеров и цветов.

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

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

Требования Яндекса проверяйте отдельно

Яндекс поддерживает JSON-LD, но успешный тест Google не подтверждает выполнение условий Яндекса. В справке Вебмастера для страницы отдельного товара перечислены Product с name, description, brand, image и вложенное предложение с доступностью, ценой и валютой. Для изображения ожидается адрес файла, а не объект ImageObject.

В справках Яндекс Вебмастера и Яндекс Товаров статус отдельных полей описан по-разному: например, Вебмастер относит описание к обязательным, а таблица Яндекс Товаров — к необязательным. Для общей карточки разумно передать настоящее описание и бренд, как в примере, и проверить результат для нужного сервиса. Тип бренда также описан неоднозначно: таблицы указывают Text, а официальный пример JSON-LD Яндекс Товаров использует вложенный Brand. В нашем коде выбран этот объект; отдельно проверьте, как его распознаёт Вебмастер.

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

Яндекс также указывает, что цена не отображается, если разметка сообщает об отсутствии товара. Это не повод оставлять ложное наличие. Решение о содержании самой недоступной карточки разобрано в материале о товаре, которого нет в наличии.

Семантическая разметка и товарный YML-фид — разные способы передачи информации. Проверка JSON-LD не означает автоматического подключения магазина к отдельной товарной программе, а добавление фида не освобождает от сверки видимой карточки и её данных.

Как проверить код и опубликованную страницу

Проверка состоит из нескольких шагов. Каждый отвечает на свой вопрос; один валидатор не подтверждает всё сразу.

1. Проверьте JSON: после копирования нет лишних запятых, незакрытых кавычек и пустых обязательных значений. Блок должен находиться в HTML карточки как application/ld+json, а не отображаться покупателю обычным текстом.
2. Проверьте словарь через Schema Markup Validator: найдены Product и вложенный Offer, свойства относятся к нужным типам. Этот тест проверяет Schema.org, а не право на конкретную поисковую функцию.
3. Выполните Google Rich Results Test по коду, затем по опубликованному адресу. Посмотрите распознанные товарные функции, ошибки и предупреждения; сравните цену и фото с карточкой.
4. Проверьте тот же адрес валидатором микроразметки Яндекс Вебмастера. Если он не может получить страницу или не распознаёт предложение, выясните причину отдельно от результата Google.
5. После обхода следите за отчётами поисковых панелей. В Google Search Console доступны отчёты о товарных структурированных данных и проверка URL; отсутствие мгновенного изменения сниппета не доказывает ошибку JSON.

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

Проверяйте состояния шаблона, а не только один товар

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

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

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

Частые вопросы

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

Не для базового примера с настоящим Offer. У Product snippets предложение является одной из альтернатив, а для Merchant listings нужны сведения о продаваемом товаре. Реальные отзывы можно добавить по отдельным правилам; заполнять рейтинг вымышленными оценками нельзя.

Почему валидатор не показывает ошибок, а сниппет не изменился?+

Корректность кода — только часть условий. Поисковик должен получить и обработать страницу, а затем решить, использовать ли расширенный показ. Проверьте доступность, распознанную функцию и соответствие данных; успешный тест не обещает сниппет в каждой выдаче.

Чек-лист внедрения Product

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