Микроразметка карточки товара: Product и JSON-LD

Для интернет-магазина карточка товара — не просто URL с названием и ценой. На одной странице могут быть варианты, остатки, разные цены, способы доставки, отзывы и ограничения покупки. Разметка Product помогает структурировать эти сведения, но быстро становится источником ошибок, если JSON-LD расходится с тем, что пользователь реально видит и может купить.

Product snippets и Merchant listings — два сценария

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

Рабочий пример Product + Offer

Все значения условные, URL и идентификаторы вымышленные. В реальном HTML значения берутся из одной актуальной товарной сущности, а не из нескольких разрозненных модулей CMS.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.ru/catalog/lamp-100/#product",
  "name": "Настольная лампа L100",
  "image": ["https://example.ru/media/lamp-100.webp"],
  "description": "Настольная лампа с регулировкой яркости",
  "sku": "L100-BK",
  "brand": {"@type": "Brand", "name": "Пример"},
  "offers": {
    "@type": "Offer",
    "url": "https://example.ru/catalog/lamp-100/",
    "priceCurrency": "RUB",
    "price": "3490.00",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

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

Варианты товара: размер, цвет, комплектация

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

У каждого варианта должны быть стабильные идентификаторы. Если пользователь открыл адрес «чёрный, 42 размер», HTML, фото, цена, состояние наличия и структурированные данные должны соответствовать выбранной версии. Нельзя подставлять для всех страниц GTIN базовой модели и считать результаты корректными.

Отсутствующий товар — не повод подменять сущность

Временное отсутствие товара часто совместимо с Offer.availability=OutOfStock при условии, что страница продолжает приносить пользу и реально отражает статус. Если товар снят с производства, решение по URL отдельное: оставить информативную страницу с заменами, перенаправить на настоящего преемника, вернуть 404/410 либо сохранить архив. Нельзя автоматически назначать canonical на «похожий товар», если страницы описывают разные объекты.

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

Отзывы, агрегированные рейтинги и достоверность

aggregateRating или review добавляйте только там, где есть настоящие отзывы по этому товару и данные доступны пользователю. Не подставляйте рейтинг бренда всем моделям, не генерируйте случайное число отзывов, не переносите оценки с чужого маркетплейса без прав и соответствия объекту. Программатическая валидация JSON не означает, что отзывы отвечают правилам поисковых систем.

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

Проверка в интернет-магазине: не один URL, а выборка

• Товар в наличии и товар с нулевым остатком.
• Товар с акцией, зачёркнутой ценой и действующей ценой.
• Товар с одним SKU и товар с несколькими вариантами.
• Товар без отзывов и товар с реальными отзывами.
• Региональная версия цены и карточка с индивидуальным предложением.
• Ошибка загрузки JS, антибот-страница и ответ сервера для Googlebot.

Сравните данные серверного HTML, DOM после JS и фактической корзины. Особенно опасен сценарий, когда антибот отдаёт поисковику JSON-LD товара, а посетителю — заглушку «Загрузка…». Такой вариант нельзя считать готовым внедрением.

Автоматизация контроля качества

После каждого обновления каталога можно проверять расхождения SKU, валют, состояний InStock/OutOfStock, URL канонической страницы, изображения, цены и фактической покупательской доступности. Настройте журнал изменений, чтобы понимать, когда испортился JSON-LD. Для массовых магазинов полезна контрольная выборка карточек каждого типа, а не только главного товара.

Пример ошибок, которые Rich Results Test не заменит

Тест успешно распознал Product и Offer, но сайт показывает цену в рублях только в Москве, а для Санкт-Петербурга значение другое; в JSON-LD у всех регионов остаётся один московский Offer. Синтаксис верен, но фактическое предложение для пользователей различается. Нужно определить, являются ли региональные URL самостоятельными, как определяется валюта и цена и какую версию видит робот без геолокационной cookie.

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

Какие поля хранить в CMS и как их проверять

Обычно целесообразно вести SKU, бренд, GTIN при наличии, валюту, цену, остаток, изображение и URL как единый набор атрибутов товарной сущности. Варианты товара с разными артикулами должны храниться как отдельные варианты, а не несколько несвязанных строк в HTML. Если модуль SEO получает цену из TV, а корзина — из API склада, приёмка должна проверять их согласованность.

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

Первоисточники

Google Product structured data, Merchant listing, варианты ProductGroup. Связано с Article JSON-LD.

Связаться в Telegram

Следующие страницы вас также могут заинтересовать:

• Робототехника
• SEO-продвижение образовательного сайта: 7 лет — от старого HTML до AI Search
• Паллетирование: что это такое, технологии, оборудование и роботизация
• Промышленные роботы: что это, виды, устройство и применение
• Кейс по SEO-продвижению медицинского центра ударно-волновой терапии

Обновлено: 11.10.2026