Микроразметка товара Product и Offer: что передать и как проверить

Что описывают Product, Offer и AggregateOffer

Product описывает сам товар: название, изображение, описание, идентификаторы и другие свойства. Offer описывает конкретное коммерческое предложение: URL, цену, валюту, наличие и состояние. AggregateOffer используют, когда на странице действительно представлено несколько предложений или диапазон цен.

Яндекс рекомендует размечать товарные страницы по схеме Product со вложенным offers, соответствующим Offer или AggregateOffer. Google также различает представление товара и предложения продавца. Синтаксис может быть JSON-LD или встроенной разметкой; важнее корректная структура и совпадение с видимым содержанием.

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

Один источник правды для страницы, фида и микроразметки

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

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

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

<offer id="123" available="true">
  <url>https://example.ru/catalog/item-123/</url>
  <price>45900</price>
  <currencyId>RUR</currencyId>
  <categoryId>12</categoryId>
  <name>Название товара и ключевой параметр</name>
</offer>

Пример JSON-LD для одного товара и одного предложения

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Название товара",
  "image": ["https://example.ru/img/item.webp"],
  "description": "Краткое описание конкретного товара",
  "sku": "sku-1042",
  "offers": {
    "@type": "Offer",
    "url": "https://example.ru/catalog/item/",
    "priceCurrency": "RUB",
    "price": "25900",
    "availability": "https://schema.org/InStock"
  }
}
</script>

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

Варианты товара и диапазон цен: когда нужен AggregateOffer

Если страница показывает один выбранный вариант с одной ценой и возможностью заказа, обычно используется Offer. Если на странице действительно доступно несколько предложений с диапазоном цен, AggregateOffer может описывать минимальную, максимальную цену и количество предложений.

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

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

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

Проверка: синтаксис, поддержка и соответствие странице

Проверку проводят в три этапа. Сначала валидатор читает код и показывает распознанные сущности, ошибки структуры и отсутствующие свойства. Затем специалист вручную сравнивает извлечённые данные с видимой карточкой. После публикации URL проверяют инструментами поисковых систем, чтобы увидеть страницу так, как её получил робот.

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

Полезные первоисточники: требования Яндекса к товарам ↗, валидатор Яндекс Вебмастера ↗ и документация Google по Product ↗.

Мониторинг после внедрения: разметка ломается вместе с шаблоном

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

Добавьте автоматическую сверку ключевых полей. Скрипт может сравнивать видимую цену, данные JSON-LD и фид; фиксировать пустой Product, неверную валюту, недоступное изображение или неизвестное значение availability. После обновления CMS запускайте проверку повторно.