Микроразметка Schema.org для интернет-магазина на 1С-Битрикс

Два одинаковых магазина на 1С-Битрикс продают один и тот же товар и стоят в выдаче рядом. Но у одного в сниппете видна цена, «в наличии», четыре с половиной звезды и число отзывов, а у второго — просто синяя ссылка и обрывок текста. Первый заберёт большую часть кликов, хотя позиция у них почти одинаковая. Разница — в микроразметке Schema.org: структурированных данных, которые объясняют поисковику, что цена — это цена, наличие — это наличие, а рейтинг — это рейтинг.

Эта статья — практический разбор того, как внедрить микроразметку Schema.org в интернет-магазин на 1С-Битрикс: какие типы нужны каталогу (Product, Offer, отзывы, хлебные крошки), в каком формате их отдавать, как сформировать JSON-LD из свойств товара в шаблоне компонента и как проверить результат в валидаторах Яндекса и Google. Материал опирается на нашу практику проектирования SEO-структуры магазинов — без обещаний «гарантированного ТОПа» и выдуманных цифр.

Зачем интернет-магазину микроразметка Schema.org

Поисковик видит страницу не так, как человек. Мы понимаем, что «2 490 ₽» — это цена, а «★★★★☆» — рейтинг, потому что так подсказывает вёрстка и контекст. Робот же получает поток текста и тегов, в котором «2490» может быть ценой, артикулом, весом или годом. Микроразметка Schema.org убирает эту неоднозначность: она прямо помечает, что вот это — цена товара, вот это — валюта, вот это — статус наличия, а вот это — средняя оценка по стольким-то отзывам.

Когда данные размечены, поисковик может собрать из них расширенный сниппет (rich snippet) — блок в выдаче, где под заголовком видны цена, наличие, рейтинг со звёздами, иногда — быстрые ссылки и поле поиска по сайту. Для интернет-магазина это прямое конкурентное преимущество: такой сниппет заметнее, честнее отвечает на запрос ещё до клика и собирает больше переходов при той же позиции.

Что разметка даёт магазину

• Цена и наличие в выдаче. Пользователь видит стоимость и статус «в наличии» ещё до перехода — на карточку приходят более тёплые, готовые к покупке посетители.
• Звёзды рейтинга. Оценка и число отзывов рядом с заголовком повышают доверие и кликабельность — при условии, что отзывы настоящие.
• Понятные хлебные крошки. Вместо длинного URL в сниппете показывается аккуратный путь «Каталог → Категория → Товар».
• Окно поиска по сайту. Для бренда в выдаче может появиться строка поиска прямо в сниппете (sitelinks searchbox).
• Корректное понимание контента. Поисковик точнее считывает, что перед ним товар, организация, статья или список — это помогает и в ранжировании, и в формировании выдачи.

Структурированные данные и rich snippets простыми словами

Разложим термины, чтобы дальше говорить на одном языке. Schema.org — это общий словарь типов и свойств, которым описывают сущности на страницах: товар (Product), предложение (Offer), организация (Organization), статья (Article) и сотни других. Словарь поддерживают крупнейшие поисковики, поэтому одна и та же разметка понятна и Яндексу, и Google.

Структурированные данные — это конкретная разметка на вашей странице, сделанная по словарю Schema.org. Она не видна пользователю: живёт либо отдельным блоком кода (JSON-LD), либо атрибутами внутри HTML (микроданные, RDFa). Её задача — дать машине однозначную опись содержимого.

Rich snippet (расширенный сниппет) — это уже результат: то, как поисковик показывает вашу страницу в выдаче, используя структурированные данные. Цепочка простая: страница с разметкой → поисковик прочитал структурированные данные → при желании собрал из них расширенный сниппет. Последнее звено — на усмотрение алгоритма: разметка даёт возможность, но не обязывает показать rich snippet.

Форматы разметки: JSON-LD, микроданные, RDFa

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

Для интернет-магазина на 1С-Битрикс рабочая рекомендация — JSON-LD. Он лежит отдельным блоком в коде страницы, не пересекается с классами и структурой вёрстки, легко формируется из свойств товара в шаблоне компонента и так же легко проверяется в валидаторах. Если завтра дизайнер переверстает карточку, JSON-LD останется на месте — а вот микроданные, вшитые в теги, при переверстке нередко «разъезжаются».

Так выглядит скелет JSON-LD-блока, который вставляется в код карточки товара (обратите внимание: это script с особым типом, браузер его не отображает):

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Название товара"
}
</script>

Здесь @context сообщает, что мы используем словарь Schema.org, @type задаёт тип сущности (в примере — товар), а дальше идут свойства. Фигурные скобки { и } ограничивают объект, значения — в двойных кавычках. Это обычный JSON, поэтому его удобно собирать программно из данных товара.

Ключевые типы Schema.org для магазина

Словарь Schema.org огромен, но интернет-магазину в повседневной работе нужен ограниченный, вполне обозримый набор типов. Держите его как карту: где какой тип уместен и что он даёт в выдаче.

Дальше разберём главные для магазина типы по отдельности, с примерами JSON-LD. Начнём с ядра карточки товара — связки Product и Offer, ради которой микроразметку чаще всего и внедряют.

Product — центр карточки товара

Тип Product описывает товар как сущность: его название, изображение, описание, бренд, идентификаторы. Это контейнер, внутри которого живут предложение (Offer с ценой и наличием) и оценки (AggregateRating, Review). Именно из корректно заполненного Product поисковик собирает товарный расширенный сниппет.

Минимально осмысленный, но уже рабочий пример разметки товара выглядит так:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Смартфон Alpha X 128 ГБ",
  "image": "https://example.ru/upload/iblock/alpha-x.jpg",
  "description": "Смартфон Alpha X с экраном 6,5 дюйма и памятью 128 ГБ.",
  "sku": "ALPHA-X-128",
  "brand": {
    "@type": "Brand",
    "name": "Alpha"
  }
}
</script>

Разберём поля построчно, потому что от их корректности зависит, распознает ли поисковик товар:

• name — название товара ровно то, что видит пользователь в заголовке карточки.
• image — абсолютный URL основного изображения (лучше — качественного и без водяных знаков поверх товара).
• description — краткое описание; не дублируйте сюда весь SEO-текст, достаточно сути.
• sku — артикул или внутренний код товара; помогает поисковику отличать позиции.
• brand — вложенный объект Brand с названием производителя.

По желанию к Product добавляют gtin/mpn (глобальные и производственные идентификаторы), category, color, material и другие свойства. Но сердце товарного сниппета — не эти поля, а вложенное предложение Offer с ценой и наличием. К нему и переходим.

Offer: цена, валюта, наличие, SKU

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Смартфон Alpha X 128 ГБ",
  "sku": "ALPHA-X-128",
  "offers": {
    "@type": "Offer",
    "price": "24990",
    "priceCurrency": "RUB",
    "availability": "https://schema.org/InStock",
    "url": "https://example.ru/catalog/smartfony/alpha-x/",
    "priceValidUntil": "2026-12-31"
  }
}
</script>

Ключевые поля предложения:

• price — цена без пробелов и символа валюты, точка как разделитель дробной части. «24990», а не «24 990 ₽».
• priceCurrency — валюта в формате ISO 4217: для рубля это «RUB».
• availability — статус наличия ссылкой на значение Schema.org (см. таблицу ниже).
• url — адрес страницы товара (полезно, но не всегда обязательно).
• priceValidUntil — до какой даты действует цена; часть поисковых систем ожидает это поле.

Статус наличия задаётся не произвольным текстом, а конкретным значением словаря. Основные:

Если у товара несколько торговых предложений (SKU) с разными ценами — например, разные объёмы памяти или цвета, — вместо одиночного Offer используют AggregateOffer с диапазоном цен:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Смартфон Alpha X",
  "offers": {
    "@type": "AggregateOffer",
    "priceCurrency": "RUB",
    "lowPrice": "24990",
    "highPrice": "34990",
    "offerCount": "4",
    "availability": "https://schema.org/InStock"
  }
}
</script>

AggregateRating и Review: рейтинг и отзывы

Звёзды рейтинга в выдаче — один из самых заметных элементов расширенного сниппета. За них отвечают два типа: AggregateRating (усреднённая оценка по всем отзывам) и Review (отдельный отзыв). Оба вкладываются в Product. Пример товара с рейтингом и одним отзывом:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Смартфон Alpha X 128 ГБ",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": {
    "@type": "Review",
    "author": {
      "@type": "Person",
      "name": "Иван П."
    },
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "5",
      "bestRating": "5"
    },
    "reviewBody": "Отличный смартфон, батарея держит два дня."
  }
}
</script>

Поля AggregateRating:

• ratingValue — средняя оценка (например, 4.6). Разделитель — точка.
• reviewCount — сколько всего отзывов учтено. Иногда используют ratingCount — число выставленных оценок.
• bestRating / worstRating — границы шкалы; по умолчанию 5 и 1, но лучше указывать явно.

Отдельная тонкость — тип сущности, к которой относится отзыв. Отзыв должен относиться к товару (Product), а не к организации, если речь о конкретной позиции. И наоборот: общие отзывы о магазине уместнее размечать на Organization, а не подмешивать в каждую карточку. Не «перевешивайте» рейтинг магазина на все товары подряд — это ещё одна распространённая причина, по которой звёзды не появляются в выдаче.

BreadcrumbList: хлебные крошки в выдаче

BreadcrumbList размечает навигационную цепочку «Главная → Каталог → Категория → Товар». В выдаче она превращается в аккуратный путь вместо длинного технического URL, помогает пользователю понять, куда он попадёт, и заодно подсказывает поисковику структуру сайта. Для интернет-магазина хлебные крошки — обязательный минимум разметки на всех страницах каталога.

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Главная",
      "item": "https://example.ru/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Каталог",
      "item": "https://example.ru/catalog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Смартфоны",
      "item": "https://example.ru/catalog/smartfony/"
    },
    {
      "@type": "ListItem",
      "position": 4,
      "name": "Смартфон Alpha X 128 ГБ"
    }
  ]
}
</script>

На что обратить внимание в этой разметке:

• position идёт по порядку — 1, 2, 3, 4 — от корня к текущей странице.
• item — абсолютный URL уровня; у последнего элемента (текущей страницы) ссылку можно не указывать.
• Крошки в разметке должны совпадать с видимыми крошками на странице — тот же путь, те же названия.

В 1С-Битрикс хлебные крошки формирует шаблон сайта (функция построения навигационной цепочки), поэтому логично собирать BreadcrumbList ровно из тех же данных, что и видимая цепочка. Так вы гарантируете совпадение и не заведёте два разных «пути» — видимый и размеченный.

Organization и LocalBusiness

Пока Product описывает товары, тип Organization описывает сам магазин как компанию: название, логотип, сайт, контакты, ссылки на соцсети. Эта разметка помогает поисковику сформировать «знание» о бренде и корректно показать логотип и контакты по брендовым запросам. Размечают её обычно на главной странице или в подвале сайта — один раз на весь ресурс.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Магазин Example",
  "url": "https://example.ru/",
  "logo": "https://example.ru/logo.png",
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+7-495-000-00-00",
    "contactType": "customer service"
  },
  "sameAs": [
    "https://vk.com/example",
    "https://t.me/example"
  ]
}
</script>

Если у магазина есть физические точки — салоны, пункты выдачи, шоурумы, — вместо (или в дополнение к) Organization используют более конкретный тип LocalBusiness (или Store). Он добавляет адрес, часы работы, гео-координаты — то, что важно для локального поиска и карт:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "Магазин Example на Тверской",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ул. Тверская, 1",
    "addressLocality": "Москва",
    "postalCode": "125009",
    "addressCountry": "RU"
  },
  "openingHours": "Mo-Su 10:00-21:00",
  "telephone": "+7-495-000-00-00"
}
</script>

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

WebSite и SearchAction: окно поиска в сниппете

Тип WebSite с вложенным SearchAction сообщает поисковику, что на сайте есть внутренний поиск и по какому адресу он принимает запросы. Для узнаваемого бренда это может дать в выдаче строку поиска прямо в сниппете (так называемый sitelinks searchbox) — пользователь ищет по вашему каталогу, не заходя на сайт через промежуточную страницу.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Магазин Example",
  "url": "https://example.ru/",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://example.ru/search/?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}
</script>

Здесь target — шаблон URL вашего поиска, где {search_term_string} — плейсхолдер, на место которого поисковик подставит запрос пользователя. Убедитесь, что этот адрес реально работает: перейдите по нему вручную с любым словом вместо плейсхолдера и проверьте, что страница поиска отдаёт результаты. Разметка поиска, ведущая в никуда, бесполезна.

ItemList для листингов каталога

Страницы категорий и результатов фильтра — это списки товаров. Тип ItemList помогает поисковику понять, что перед ним именно перечень позиций, и в каком они порядке. Для карусельных и товарных списков это бывает полезно, хотя приоритет у листингов ниже, чем у карточек: главный товарный сниппет собирается всё-таки из Product на детальной странице.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "url": "https://example.ru/catalog/smartfony/alpha-x/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "url": "https://example.ru/catalog/smartfony/beta-y/"
    }
  ]
}
</script>

Практический совет: не гонитесь за тем, чтобы разметить абсолютно всё. На листингах в первую очередь важны BreadcrumbList (путь навигации) и корректные метатеги — их удобно генерировать по шаблону, как мы описывали в статье про SEO-шаблоны метатегов для умного фильтра. А ItemList — приятное дополнение. Куда важнее не наплодить дубли и не размечать «мусорные» комбинации фильтра — этот вопрос мы подробно разбирали в материале про robots.txt и sitemap.xml для большого магазина и в статье про умный фильтр в 1С-Битрикс.

FAQPage, Article и BlogPosting для контента

Микроразметка полезна не только каталогу. У магазина обычно есть блог, страницы услуг, разделы помощи — и для них Schema.org тоже предлагает подходящие типы.

FAQPage — блок вопросов и ответов

Если на странице есть настоящий блок «Частые вопросы», его размечают типом FAQPage. В выдаче такие вопросы иногда показываются раскрывающимся списком под сниппетом. Условие то же — вопросы и ответы должны быть реально видны на странице, а не спрятаны только в разметке:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Есть ли доставка по всей России?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Да, мы доставляем заказы по всей России курьерскими службами и почтой."
      }
    }
  ]
}
</script>

Article и BlogPosting — статьи блога

Материалы блога размечают типом Article или его подтипом BlogPosting. Разметка передаёт заголовок, дату публикации и обновления, автора и главное изображение — это помогает поисковику показать статью с корректной датой и авторством:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Микроразметка Schema.org для интернет-магазина",
  "image": "https://example.ru/assets/img/blog/cover-seo.webp",
  "datePublished": "2026-07-01",
  "dateModified": "2026-07-01",
  "author": {
    "@type": "Organization",
    "name": "Редакция B2Bsite"
  }
}
</script>

Кстати, именно так размечена и эта статья: в шаблоне детальной страницы блога вызывается хелпер, который собирает BlogPosting из данных статьи, а рядом — FAQPage из блока вопросов внизу. Это тот же принцип, что и в каталоге: разметка формируется из данных автоматически, а не проставляется руками у каждого материала.

Граф сущностей: как связать Product, Offer, Brand и Review

Когда типов на странице несколько, важно понимать, что они не разрозненны, а образуют граф — дерево вложенных и связанных сущностей. У карточки товара в центре стоит Product, а к нему «подвешены» предложение, бренд и отзывы. Именно из этого графа поисковик и собирает единую картину товара.

• Product — корень. Всё остальное относится к нему.
• Offer вложен в Product через offers — отвечает за цену и наличие.
• Brand вложен в Product через brand — производитель товара.
• AggregateRating и Review вложены в Product через aggregateRating и review — оценки.

Плоско это можно представить так: один блок JSON-LD описывает Product, а внутри него как вложенные объекты лежат Offer, Brand, AggregateRating. Не нужно делать четыре отдельных блока и пытаться связать их вручную — вложенность в одном объекте и есть связь. Для более сложных случаев Schema.org поддерживает ссылки через @id, но для типовой карточки товара хватает обычной вложенности.

Как внедрить JSON-LD в шаблон catalog.element

Теория закончилась — переходим к тому, как это делается в 1С-Битрикс. Карточку товара выводит компонент bitrix:catalog.element (или catalog.section для списков). Разметку удобнее всего формировать в шаблоне компонента: там уже есть массив с данными товара — свойства, цены, картинки, — из которых собирается JSON-LD.

Логика внедрения такая:

1. Скопируйте системный шаблон компонента в свой. Никогда не правьте шаблоны в системной папке — их перезапишет обновление. Сделайте копию в шаблоне сайта и работайте с ней.
2. Найдите в шаблоне данные товара. В template.php доступен массив результата компонента: название, свойства, цены, изображения. Это ваш источник для разметки.
3. Соберите массив разметки в PHP. Постройте ассоциативный массив со структурой Product → Offer → рейтинг, подставляя реальные значения товара.
4. Выведите его как JSON. Оберните массив в script с типом application/ld+json и закодируйте функцией кодирования в JSON с флагами, которые не экранируют кириллицу и слэши.
5. Проверьте на реальной странице. Откройте карточку, посмотрите исходный код, найдите блок разметки и прогоните его через валидатор.

Концептуально код в шаблоне выглядит так (значения берутся из данных товара, а не пишутся вручную):

<?php
$ld = [
    "@context" => "https://schema.org",
    "@type"    => "Product",
    "name"     => $arResult["NAME"],
    "sku"      => $arResult["PROPERTIES"]["ARTICLE"]["VALUE"],
    "offers"   => [
        "@type"         => "Offer",
        "price"         => $price,
        "priceCurrency" => "RUB",
        "availability"  => $available
            ? "https://schema.org/InStock"
            : "https://schema.org/OutOfStock",
    ],
];
echo '<script type="application/ld+json">'
   . json_encode($ld, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)
   . '</script>';
?>

Ключевой момент — флаги кодирования: без JSON_UNESCAPED_UNICODE кириллица превратится в escape-последовательности (формально валидно, но нечитаемо), а JSON_UNESCAPED_SLASHES оставит URL в человеческом виде. Значения $price и $available вы получаете из данных о цене и остатке — об этом следующий раздел.

Где брать цену, наличие и рейтинг в Битриксе

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

Цена

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

Наличие

Статус наличия формируется из остатков и признака доступности товара. Логика простая: товар доступен к покупке — InStock, закончился — OutOfStock, принимается предзаказ — PreOrder, возится под заказ — BackOrder. Если каталог работает с остатками из 1С, значение наличия должно опираться на те же остатки, что и кнопка «Купить» на карточке. После обмена с 1С и сброса кэша разметка пересоберётся с новыми остатками автоматически.

Рейтинг и отзывы

Источник рейтинга — модуль отзывов или система оценок, которую вы используете. Средний балл и число отзывов берут из неё же, из тех данных, что показаны на карточке. Если отзывов у товара нет — блок AggregateRating просто не выводят (см. условие в коде: рейтинг добавляется, только если отзывы есть). Не подставляйте в разметку рейтинг «по умолчанию» или общий рейтинг магазина вместо оценок конкретного товара.

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

Штатная микроразметка в компонентах Битрикса

Важно знать: часть штатных компонентов 1С-Битрикс уже выводит микроразметку из коробки — как правило, в формате микроданных. Например, компоненты каталога и хлебных крошек могут добавлять атрибуты itemtype/itemprop в HTML. Это удобно, но порождает две типичные ситуации.

• Разметка есть, но неполная. Штатные микроданные могут покрывать не все поля, которые вам нужны для расширенного сниппета (например, нет рейтинга или неполный Offer). Тогда её дополняют своим JSON-LD.
• Разметка дублируется и конфликтует. Если вы добавили свой JSON-LD, а компонент выводит те же данные микроданными, следите, чтобы значения совпадали. Разные цены в двух форматах на одной странице — прямой путь к недоверию поисковика.

Практичный подход: определитесь с одним основным форматом (для новых проектов — JSON-LD), проверьте, что именно выводят ваши компоненты, и приведите всё к единому непротиворечивому виду. Не нужно героически вычищать все штатные микроданные — достаточно, чтобы данные в них не спорили с вашим JSON-LD. А там, где штатной разметки нет или она бедна, вы добавляете собственную.

Валидация разметки: инструменты и порядок

Разметку нельзя «сделать и забыть» — её обязательно проверяют инструментами, потому что мелкая ошибка (лишняя запятая, неверный тип поля, несовпадение цены) обнуляет весь блок. Есть три опорных инструмента, и лучше пользоваться всеми.

Разумный порядок проверки:

1. Синтаксис в Schema Markup Validator. Сначала убедитесь, что JSON вообще валиден и типы/поля распознаются — это отсекает грубые ошибки.
2. Rich Results Test для Google. Проверьте, что Google видит нужный тип (Product, Breadcrumb, FAQ) и не ругается на обязательные поля.
3. Валидатор Яндекса. Прогоните ту же страницу через инструмент Яндекса — у него свои требования, и он подсветит свои предупреждения.
4. Проверка на «живой» странице. Валидируйте не черновик, а реальный URL: важно, чтобы разметка совпадала с видимым контентом именно в продакшене.
5. Мониторинг в панелях вебмастера. После индексации следите за отчётами по структурированным данным в Яндекс.Вебмастере и Google Search Console — там всплывают ошибки, которые не видны на одной странице.

Отдельно предупредим про частую ловушку: валидатор проверяет разметку, но не проверяет её соответствие видимому контенту. Валидатор скажет «всё хорошо», даже если в разметке цена 24 990, а на странице 27 990 — синтаксически-то верно. Соответствие данных вы контролируете сами. Именно на этом расхождении чаще всего и «сгорают» расширенные сниппеты.

Как разметка попадает в индекс и выдачу

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

1. Разметка добавлена в код страницы. JSON-LD выводится в HTML карточки и доступен в исходном коде.
2. Робот скачивает страницу. Поисковый бот получает HTML вместе с блоком разметки. Важно, чтобы страница была открыта для индексации, а разметка — в исходном коде, а не подгружалась скриптом позже.
3. Разметка распознаётся и проверяется. Поисковик разбирает структурированные данные, сверяет их с видимым контентом и своими правилами.
4. Страница индексируется. Товар попадает в индекс вместе с распознанными данными о цене, наличии, рейтинге.
5. Алгоритм решает про сниппет. При показе в выдаче поисковик сам выбирает, собрать ли расширенный сниппет и в каком виде — это зависит от запроса, доверия к сайту и региона.

Отсюда два практических следствия. Первое: разметка должна быть в исходном HTML, а не появляться только после выполнения JavaScript, — так надёжнее для распознавания. Второе: между внедрением разметки и появлением сниппетов проходит время — нужно, чтобы робот переобошёл страницы и переоценил их. Мгновенного эффекта ждать не стоит; это нормальный процесс индексации.

Частые ошибки микроразметки

Эти промахи повторяются из проекта в проект. Зная их заранее, вы избежите ситуации «разметка есть, а сниппета нет» и не нарветесь на санкции:

• Цена в разметке не совпадает с видимой. На карточке одна сумма, в JSON-LD другая (забыли учесть скидку или взяли базовую цену). Поисковик считает разметку недостоверной и цену в сниппете не показывает.
• Наличие «врёт». В разметке InStock, а товара нет в продаже. Это вводит пользователя в заблуждение и нарушает правила.
• Рейтинг без реальных отзывов. Проставили AggregateRating ради звёзд, хотя отзывов на странице нет. Прямое нарушение — звёзды не покажут, возможны санкции.
• Разметка не соответствует видимому контенту. В FAQPage вопросы, которых нет на странице; в Review отзывы, которых пользователь не видит. Скрытая разметка запрещена правилами.
• Синтаксическая ошибка в JSON. Лишняя или пропущенная запятая, незакрытая скобка — и весь блок игнорируется. Лечится сборкой через функцию кодирования, а не конкатенацией строк.
• Неверный формат значений. Цена с пробелами и знаком валюты («24 990 ₽»), валюта не по ISO, дата в произвольном формате. Значения должны быть машиночитаемыми.
• Дубли и конфликты форматов. Штатные микроданные и свой JSON-LD выводят разные значения одного поля. Приводите к единому непротиворечивому виду.
• Разметка только в JavaScript. Блок появляется в DOM после выполнения скрипта, а в исходном HTML его нет. Надёжнее отдавать разметку сразу в коде страницы.
• Рейтинг магазина на всех товарах. Общий рейтинг компании подставлен в каждую карточку как оценка товара. Отзывы о товаре и о магазине — разные сущности.
• Разметили «мусорные» страницы. JSON-LD Product навешен на страницы, закрытые от индексации, или на дубли комбинаций фильтра — работа впустую.

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

Короткий список, по которому удобно принять готовность микроразметки перед запуском:

1. Формат выбран. Для новых внедрений — JSON-LD; проверено, что штатные микроданные не конфликтуют с ним.
2. Product на всех карточках. Разметка формируется в шаблоне catalog.element автоматически из свойств товара.
3. Offer заполнен. Есть price, priceCurrency (RUB), availability из реальных остатков; значения совпадают с видимой ценой и наличием.
4. Рейтинг честный. AggregateRating выводится только при наличии реальных отзывов и синхронизирован с их числом и баллом.
5. Хлебные крошки размечены. BreadcrumbList на всех страницах каталога совпадает с видимой цепочкой.
6. Организация и сайт описаны. На главной есть Organization (или LocalBusiness) и WebSite с SearchAction.
7. Контент размечен. Статьи блога — BlogPosting, реальные блоки вопросов — FAQPage.
8. Значения машиночитаемы. Цена без пробелов и валюты, валюта по ISO, даты в корректном формате.
9. Проверено валидаторами. Страницы прошли Schema Markup Validator, Rich Results Test и Валидатор Яндекса без критических ошибок.
10. Разметка в исходном HTML. Блоки JSON-LD присутствуют в коде страницы до выполнения JavaScript.
11. Мониторинг настроен. Отчёты по структурированным данным в Вебмастере и Search Console на контроле.

Вывод

Микроразметка Schema.org — это язык, на котором интернет-магазин объясняет поисковику содержимое своих страниц: где цена, где наличие, где рейтинг, где путь навигации. Для каталога на 1С-Битрикс ядро — связка Product и Offer, дополненная отзывами, хлебными крошками и данными о компании. Формируется всё это один раз в шаблоне компонента из свойств товара, а не проставляется вручную у каждой позиции.

Главный принцип, вокруг которого держится вся работа, — честность разметки: значения обязаны совпадать с видимой страницей, рейтинг — опираться на реальные отзывы, наличие — на реальные остатки. Тогда разметка даёт то, ради чего затевается: расширенные сниппеты с ценой, наличием и звёздами, которые выделяют ваш магазин в выдаче и приводят более тёплый трафик. Внедрите ядро, проверьте страницы в валидаторах Яндекса и Google — и дайте поисковику время переобойти каталог. Больше практических разборов по технической оптимизации — в рубрике SEO и продвижение.