-
Данные
Артикул, цена и остаток
-
Разметка
Product связан с Offer
-
Сверка
Карточка, JSON-LD и фид
-
Обновление
Проверка обмена и кеша
Product описывает товар, а Offer — условия его продажи: цену, валюту, наличие и другие параметры предложения. Для интернет-магазина разметку нужно собирать из тех же данных, что выводятся покупателю. Если в карточке цена уже изменилась, а JSON-LD остался прежним, проблема находится в обновлении данных, а не в количестве заполненных свойств.
Ниже — пример для условного товара, схема подключения к CMS и план проверки. Он подойдёт для задания разработчику и приёмки результата. Перед запуском выберите конкретное поисковое представление: требования к товарному сниппету и торговому предложению различаются. Google объясняет выбор в обзоре разметки Product.
Где заканчивается Product и начинается Offer
Название, изображение, описание, бренд и артикул относятся к самому товару. Цена и доступность зависят от продавца и условий продажи. Одна модель может продаваться в нескольких магазинах, поэтому товар и предложение нельзя считать взаимозаменяемыми сущностями. В собственном магазине начните с текущего предложения на конкретной карточке.
Составьте таблицу полей до написания кода. Для каждого свойства укажите источник: справочник номенклатуры, прайс, остатки, описание или настройки доставки. Затем определите владельца данных. Это особенно важно, когда цену меняет менеджер в 1С, наличие приходит со склада, а редактор вручную поддерживает JSON в CMS.
| Свойство | Источник в магазине | Проверка |
|---|---|---|
| name, sku | Карточка номенклатуры | Совпадают модель и артикул |
| image | Основной снимок варианта | Файл доступен и показывает этот товар |
| price, priceCurrency | Действующее предложение | Та же цена доступна покупателю |
| availability | Правило продажи и остатки | Можно ли оформить именно такой заказ |
| shippingDetails | Условия доставки | Учтены направление и исключения |
Обратите внимание на смысл наличия. Нулевой остаток на одном складе не всегда означает отсутствие возможности купить товар. Бывает предзаказ, поставка под заказ или остаток у другого подразделения. Правило должен подтвердить бизнес; SEO-специалист не должен угадывать его по числу в выгрузке.
Пример JSON-LD для товара с одним предложением
Это учебный фрагмент для настольной лампы. Он показывает связь сущностей, а не копирует реальный магазин. На сайте JSON размещают внутри элемента script с типом application/ld+json. В статье код выведен как текст: сама статья не является карточкой продаваемой лампы.
{
"@context": "https://schema.org",
"@type": "Product",
"@id": "https://example.com/catalog/luma-42/#product",
"name": "Настольная лампа Luma 42, зелёная",
"image": "https://example.com/images/luma-42-green.webp",
"description": "Настольная лампа с керамическим основанием и льняным абажуром.",
"sku": "L42-GREEN",
"brand": {"@type": "Brand", "name": "Luma"},
"offers": {
"@type": "Offer",
"url": "https://example.com/catalog/luma-42/",
"price": "6490.00",
"priceCurrency": "RUB",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}Не подставляйте вымышленные GTIN, отзывы или среднюю оценку ради заполненного валидатора. Если у товара нет подтверждённых данных, сначала решите вопрос с их источником. Отсутствующий необязательный параметр и неверное утверждение о товаре — разные проблемы; вторую нельзя исправить хорошей формой JSON.
Для цены используйте числовое значение без знака рубля и разделителей тысяч, валюту передавайте отдельно. Если срок цены действительно установлен, можно добавить соответствующее поле. Не продлевайте вымышленную дату каждый день, чтобы предупреждение исчезло из отчёта. Условия в данных должны следовать реальному предложению.
Доставка, возврат и несколько вариантов товара
Условия доставки описывают через свойства предложения, а правила возврата — через подходящие типы и свойства Schema.org. Структуру и требования для торговых представлений сверяйте с документацией merchant listings. Здесь важно не перечислить максимальное число полей, а передать доступные покупателю условия.
Например, магазин доставляет лампу бесплатно только в пределах одного города. Нельзя записать нулевую стоимость доставки для всей страны. Если тариф зависит от адреса, веса или перевозчика, сначала выясните, какие условия можно выразить точно и как они показаны на странице. Сложные исключения лучше разобрать до внедрения общего шаблона.
Размеры и цвета требуют отдельной проверки. У каждой продаваемой комбинации могут быть собственные артикул, цена и остаток. Не привязывайте фотографию зелёной лампы к цене самой дешёвой белой версии, если посетитель попадает на другой выбор. Для структуры каталога используйте разбор вариантов товара.
Как связать разметку с CMS и фидом
Надёжная схема — общий источник для видимой карточки, структурированных данных и товарного фида. Разработчику нужно передать не просьбу «добавить Schema», а набор состояний. Минимальная выборка: обычная цена, скидка, предзаказ, закончившийся товар и вариант с другой стоимостью. По каждому состоянию заранее опишите ожидаемый результат.
Проверьте кеширование. После изменения цены обновиться должны HTML и JSON-LD, а не только число, которое браузер дорисовывает из API. Зафиксируйте допустимую задержку обмена внутри проекта и способ её обнаружить. Когда у каждой системы собственный расписанный импорт, одинаковые значения в момент ручной проверки ещё не доказывают согласованность в течение дня.
Особое внимание уделите персональным ценам. Участник программы лояльности может видеть сумму, недоступную обычному посетителю. Разметка публичного предложения должна соответствовать условиям его получения. Проверьте страницу без входа, в другом регионе доставки и после очистки cookies, чтобы случайно не опубликовать цену только для одного сегмента.
Если проблема заметна и в рекламе, начните с сверки карточки и YML-фида. Исправление общего источника выгоднее, чем ручное редактирование трёх копий одного значения. В журнале обмена сохраняйте идентификатор товара и время изменения: они помогают быстро найти потерянное обновление.
Проверка до и после публикации
Сначала проверьте синтаксис JSON, затем соответствие словарю Product и Offer. После этого используйте Rich Results Test для конкретного сценария Google. Успешная проверка означает соответствие проверяемым требованиям; внешний вид результата в выдаче выбирает поисковая система.
На тестовом товаре измените цену, переведите его в предзаказ и верните прежнее состояние. На каждом шаге сравните видимую карточку, исходный ответ сервера, итоговый HTML и фид. Такая проверка полезнее одного снимка валидатора сразу после установки модуля. Она показывает, работает ли интеграция при обычных действиях менеджера.
После выпуска сохраните несколько контрольных URL и список ожидаемых свойств. При обновлении шаблона или SEO-модуля повторяйте тест: второй модуль иногда добавляет ещё один Product с устаревшей ценой. В итоге на странице оказываются два противоречащих предложения, хотя каждое по отдельности синтаксически корректно.
Отчёт для владельца магазина должен быть коротким: какие шаблоны исправлены, какие состояния проверены, откуда теперь берутся данные и кто отвечает за ошибки обмена. Поисковые показы товарных представлений отслеживайте отдельно от технической приёмки. Так команда понимает и качество внедрения, и его дальнейший эффект.
