Микроразметка товаров в 1С-Битрикс: цена, наличие и варианты

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

Для магазина на 1С-Битрикс мало добавить тип Product. Цена и наличие в разметке должны совпадать с витриной, а размеры и цвета - быть связаны с конкретными торговыми предложениями. Иначе в коде может остаться старая цена или общее наличие для вариантов, которые уже закончились.

Корректная разметка не гарантирует расширенный результат в Яндексе или Google. Поисковая система сама решает, как оформить выдачу. Задача владельца магазина - убедиться, что робот получает те же данные, что и покупатель.

Что должен увидеть поисковик в карточке товара

Основа простой карточки - Product с вложенным Offer. Product описывает товар, а Offer - условия покупки: адрес страницы, цену, валюту и наличие. Набор обязательных полей зависит от поисковика. Например, Яндекс ожидает у товара название, бренд и изображение, а у предложения - цену, валюту и наличие. Описание товара у Яндекса необязательно.

Для размеров и цветов Google использует ещё один уровень. Родительскую модель описывают как ProductGroup, каждый вариант - как отдельный Product, а его цену и наличие - как Offer.

AggregateOffer описывает несколько предложений одного товара, например от разных продавцов. Для Google это не замена размерам и цветам: варианты нужно связывать через ProductGroup. Яндекс допускает AggregateOffer и цену «от», поэтому одну и ту же карточку важно проверять по требованиям обоих поисковиков.

Откуда берутся цена и наличие в 1С-Битрикс

В 1С-Битрикс разметку обычно формирует шаблон карточки или установленный модуль. Поэтому настройки в административной части сами по себе ничего не доказывают. Проверять нужно публичную страницу - именно её получает поисковый робот.

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

Здесь часто появляется расхождение. На экране Битрикс показывает цену выбранного SKU, а JSON-LD продолжает брать цену родительского товара или первого варианта. То же бывает с наличием: один размер закончился, другой доступен, а разметка сообщает одно состояние для всей карточки.

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

Как проверить микроразметку товара

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

1. Простой товар в наличии.
2. Товар со скидкой.
3. Товар, которого нет в наличии.
4. Товар с размерами или цветами.
5. Товар, у которого часть вариантов закончилась.

Для каждой страницы откройте тест расширенных результатов Google. Он покажет найденные сущности, ошибки и предупреждения по требованиям Google. Затем проверьте тот же адрес валидатором микроразметки Яндекс Вебмастера. Отсутствие ошибки в одном сервисе не заменяет проверку во втором.

После автоматической проверки сравните извлечённые данные с карточкой товара. Зелёной отметки недостаточно. Проверьте:

• название и основное изображение;
• цену и валюту;
• наличие;
• артикул или другой идентификатор;
• варианты и их отличия;
• адрес предложения.

Отдельно откройте исходный код страницы и найдите application/ld+json, Product или Offer. Исходный код показывает, что сервер отдал сразу. Инспектор браузера показывает уже изменённый JavaScript DOM, поэтому эти проверки отвечают на разные вопросы.

Google рекомендует передавать быстро меняющиеся товарные данные уже в начальном HTML. JSON-LD, добавленный JavaScript, допустим, но его обход и обновление могут быть менее надёжными, особенно для цены и наличия.

Как выглядит простой товар

Для простой карточки структура может выглядеть так:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Настольная лампа L1",
  "image": ["https://example.ru/upload/lamp-l1.jpg"],
  "description": "Лампа с металлическим плафоном",
  "sku": "L1-BLACK",
  "brand": {
    "@type": "Brand",
    "name": "Example"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.ru/catalog/lamp-l1/",
    "price": 7990,
    "priceCurrency": "RUB",
    "availability": "https://schema.org/InStock"
  }
}

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

Сверьте разметку с видимой частью страницы. Если в price указано 7990, покупатель должен видеть ту же доступную ему цену. Если товар нельзя положить в корзину, значение InStock противоречит фактическому состоянию карточки.

Как описать размеры и цвета

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

В модели Google родительский товар описывает ProductGroup. В variesBy перечисляют признаки различия, например color и size. В hasVariant передают отдельные Product. У каждого варианта должны быть свой идентификатор и Offer с фактическими ценой и наличием.

Яндекс перечисляет в требованиях к товарным данным Product, Offer и AggregateOffer, но отдельно не заявляет поддержку ProductGroup для товарного сниппета. Поэтому для Яндекса нужно отдельно проверить, какие Product и Offer он извлекает из публичной страницы.

Упрощённый пример для Google:

{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": "Футболка Base",
  "productGroupID": "BASE-01",
  "variesBy": [
    "https://schema.org/color",
    "https://schema.org/size"
  ],
  "hasVariant": [
    {
      "@type": "Product",
      "name": "Футболка Base, чёрная, M",
      "image": ["https://example.ru/upload/base-black-m.jpg"],
      "sku": "BASE-BLACK-M",
      "color": "чёрный",
      "size": "M",
      "offers": {
        "@type": "Offer",
        "price": 2490,
        "priceCurrency": "RUB",
        "availability": "https://schema.org/InStock",
        "url": "https://example.ru/catalog/base/?color=black&size=m"
      }
    },
    {
      "@type": "Product",
      "name": "Футболка Base, чёрная, L",
      "image": ["https://example.ru/upload/base-black-l.jpg"],
      "sku": "BASE-BLACK-L",
      "color": "чёрный",
      "size": "L",
      "offers": {
        "@type": "Offer",
        "price": 2490,
        "priceCurrency": "RUB",
        "availability": "https://schema.org/OutOfStock",
        "url": "https://example.ru/catalog/base/?color=black&size=l"
      }
    }
  ]
}

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

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

Как проверить цену

Цена в разметке должна отвечать на простой вопрос: за сколько обычный посетитель может купить выбранный товар сейчас.

1. Откройте карточку без авторизации и выберите вариант.
2. Запишите цену на странице.
3. Добавьте товар в корзину и проверьте цену там.
4. Сравните число с Offer.price, а валюту - с Offer.priceCurrency.
5. Повторите проверку для товара со скидкой и хотя бы ещё одного варианта.

Если на странице показано «от 2 490 ₽», не подставляйте 2490 как цену каждого размера. У конкретного Offer должна быть цена конкретного предложения. Диапазон уместен только там, где схема действительно описывает несколько предложений, и не заменяет данные вариантов.

В price передают сумму без пробелов, знака рубля и подписи «от», а в priceCurrency - код RUB. Видимая карточка может оформлять сумму привычным для покупателя способом.

Как проверить наличие

availability описывает возможность купить конкретное предложение. Для обычного магазина чаще всего подходят значения InStock, OutOfStock, PreOrder или BackOrder из Schema.org.

В Битриксе нельзя определять наличие только по остатку на складе. В базовом алгоритме товар или SKU недоступен, если одновременно включён количественный учёт, запрещена покупка при нулевом остатке и количество меньше либо равно нулю. Если продажа без остатка разрешена или количественный учёт выключен, нулевое количество само по себе не означает OutOfStock.

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

У товара с вариантами нельзя ставить одно InStock для всех размеров, если часть уже закончилась. Каждый Offer должен передавать состояние своего SKU. Если недоступны все варианты, родительская карточка не должна создавать впечатление, что товар можно купить.

После обмена с 1С снова откройте контрольную карточку. Обновление остатка в административной части - только половина проверки. Должны также измениться кнопка на витрине, JSON-LD и данные, которые извлекают валидаторы.

Какие ошибки встречаются чаще всего

Старая цена в JSON-LD. Шаблон берёт базовую цену и не учитывает скидку или выбранный тип цены.

Наличие всегда равно InStock. Значение прописано в шаблоне и не связано с состоянием конкретного товара или SKU.

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

Несколько блоков Product противоречат друг другу. Один добавляет шаблон, второй - SEO-модуль, третий - готовое решение. В итоге валидатор извлекает разные цены для одной карточки.

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

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

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

Что передать разработчику

Формулировка «починить микроразметку» слишком общая. Приложите к задаче таблицу с контрольными карточками и ожидаемым результатом.

В техническом задании попросите:

1. Найти все источники JSON-LD и устранить противоречащие друг другу блоки.
2. Связать поля Product и Offer с фактическими данными каталога.
3. Для торговых предложений брать цену, наличие, артикул и свойства из конкретного SKU.
4. Для Google описать варианты через ProductGroup, hasVariant и variesBy, если эта модель соответствует карточке.
5. Отдавать товарную разметку в начальном HTML.
6. Проверить простой товар, скидку, нулевой остаток и несколько вариантов.
7. Сохранить контрольные URL для повторной проверки после обменов с 1С.

Если расхождения затрагивают не одну карточку, а структуру каталога, проверьте sitemap.xml магазина и основные адреса товаров. Устройство вариантов лучше учитывать ещё при оценке разработки интернет-магазина на 1С-Битрикс: менять модель товара после запуска обычно сложнее и дороже.

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

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

Затем повторите проверку после ближайшего обмена с 1С. Если цена или остаток меняются в каталоге, но остаются прежними в разметке, задача ещё не решена.

Если нужна независимая проверка карточек, вариантов, индексации и других технических факторов, её можно включить в SEO-аудит и продвижение сайта на 1С-Битрикс.