Покупатель ищет "толстовка с логотипом". В выдаче он видит не все возможные варианты, а только какой то один без изображения, цены, статуса "В наличии". На сайтах с JS фреймворками (в моем случае это VUE) может возникать проблема с индексацией, как карточек товаров с торговыми предложениями, так и изображений, наличия, отзывов и так далее.

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

642 адреса на 228 товаров

Я взял все адреса каталога и прогнал через разбор структурированных данных. Получилась таблица.

Метрика	Значение
Всего адресов в каталоге	642
Из них реальных, канонических товаров	228 (~36%)
Страниц с разметкой товара	219
Из них без признака наличия	108 (49%)
Ошибок валидации всего	132
Ошибок, закрывающихся одним полем	108

Пояснение к таблице:

Первое. 642 адреса на 228 товаров. Разница – страницы размеров. Каждый размер жил отдельной страницей и закрывался каноническим адресом на основную. Для поисковика это шесть разных сущностей, между которыми нет объявленной связи.

Второе. 82% всех ошибок – одно отсутствующее поле. Не архитектурная катастрофа, не сложная логика. Просто в шаблоне не выводился признак наличия товара, потому что шаблон писали в те годы, когда Google этого ещё не требовал. Требование появилось, шаблон остался.

Третье. Из 219 страниц с разметкой Google считал валидными 45. Остальные не проходили проверку и не могли получить товарный сниппет.

Product и ProductGroup: в чём разница

Если вы работали с маркетплейсами, конструкция вам знакома. Одна карточка. Внутри переключатель размера или цвета. Один блок отзывов, один рейтинг, одна цена "от". Покупатель воспринимает это как один товар с вариантами, а не как шесть товаров.

ProductGroup позволяет сказать поисковику ровно то же самое.

	`Product`	`ProductGroup`
Что описывает	один товар	товар с вариантами
Варианты	нет	список внутри, у каждого своя цена, размер и наличие
Чем различаются варианты	—	объявляется явно: размер, цвет, объём
Отзывы и рейтинг	у товара	у группы целиком
Что видит покупатель	одна карточка	карточка + выбор варианта прямо в выдаче

Торговые предложения в CMS битрикс существуют очень давно, но Google поддерживает этот тип с февраля 2024 года. Яндекс прямо не поддерживает, но и не ругается когда прогоняешь разметку валидатором.

Раздел каталога и карточка товара: почему выбирать между Google и Яндексом не нужно

В прошлой версии текста в комментариях был задан вопрос: "Google и Яндекс рекомендуют для каталога разное, обычно приходится угождать кому-то одному — почему у вас другой выбор?"

Вопрос немного подменяет понятия раздела каталога – листинга и детальной карточки товара. В тексте речь о детальной карточке товара, а не о разделе каталога.

Раздел каталога и карточка товара — разные страницы. И типы разметки для них разные.

Никакого выбора на карточке товара не существует, потому что рекомендации двух систем относятся к разным уровням:

Тип страницы	Что рекомендует Google	Что рекомендует Яндекс
Раздел каталога (листинг)	ItemList со ссылками на карточки	OfferCatalog с вложенными Offer
Карточка товара	Product	Product с Offer или AggregateOffer
Карточка товара с вариантами	ProductGroup	отдельного типа нет

ProductGroup не конкурирует ни с ItemList, ни с OfferCatalog. Он живёт на другом URL. Ставить его на раздел каталога – ошибка, но к задаче с вариантами товара она отношения не имеет.

На разделе каталога выбирать тоже не обязательно. Мало кто об этом помнит, но ничто не мешает отдать на одной странице оба узла – Google свой, Яндексу свой. Единственное ограничение, о котором прямо пишет Яндекс это список, размеченный по OfferCatalog, на странице должен быть один и без вложенных списков.

Google давно предпочитает JSON-LD, а Яндекс формально надёжнее читает микроданные прямо в HTML. Но обе поисковые системы не гарантируют отображение расширенного сниппета в выдаче.

Я выбрал JSON-LD, и это осознанное решение. Причина в том, что поверх каталога у меня работает JS-фреймворк. Микроданные, расставленные атрибутами прямо в вёрстке, при перерисовке компонентов на клиенте теряются. В исходном коде страницы разметка есть, в живом DOM её нет. Или наоборот как повезёт с тем, какие узлы фреймворк успел перерисовать.

Так что ответ – я не выбирал, кому угодить. Я внедрил и измерил обе системы. Что из этого вышло – дальше, с цифрами.

В Google валидных карточек за месяц выросло с 45 до 287

Отчёты Search Console за 90 дней. Разметка проявляется характерными ступенями.

Дата	Валидных карточек	Ошибок
1 мая — 25 июня	37–48	4–8
26 июня	45 → 58	6
1 июля	60 → 71	6
3 июля	71	5
7 июля	65 → 124	3
13 июля	257	1
16 июля	295	0
29 июля	298	0

Лаг между выкаткой и отражением в отчётах составил от одного до девяти дней. Google переобходил карточки волнами.

Итог за месяц:

Метрика	25 июня	29 июля
Валидных карточек товара	45	298 (×6,6)
Валидных товарных предложений	45	340 (×7,6)
Ошибок валидации	6	0
Критических проблем	—	0

Увеличение индексации карточек товаров по данным GSC

Результат внедрения разметки на детальные страницы товаров по данным GSC на момент публикации

Ошибки обнулились 16 июля и с тех пор держатся на нуле.

Трафик. Показы упали на 12%, CTR вырос на 29%

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

Период	Показы	Клики	CTR	Ср. позиция
Май	29 195	451	1,54%	8,0
Июнь	30 138	419	1,39%	7,8
Июль (норм.)	~26 533	~477	1,80%	7,7

Показы просели примерно на 12%. Позиция не изменилась. Клики выросли, CTR прибавил 29%.

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

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

Разметка вопросов на моем проекте даёт CTR 20%

Отдельная история – блок вопросов и ответов на карточке.

FAQ-сниппет в Google мёртв. Расширенные результаты по FAQ перестали показываться 7 мая 2026 года, а к середине июня документацию по ним удалили целиком. Почти все актуальные русскоязычные гайды по микроразметке до сих пор советуют внедрять FAQ. Совет протух.

Разметку вопросов я оставил как структурно корректную, но бесполезную для выдачи. Однако, я оставил её также для лучшего понимания ИИ краулерами контента страницы. Не могу однозначно измерить эффективность, но она была и пусть остается.

Что касается моих замеров карточек, которые были с этой разметкой ранее:

Вид в поиске	Клики	Показы	CTR	Позиция
Описания товара	1298	58 536	2,22%	11,5
Фрагмент отзыва	12	552	2,17%	7,0
Вопросы и ответы	2	10	20,0%	4,5

Объёмы мизерные, но если FAQ-фича умерла, а Q&A-фича жива, и разметка вопросов на карточке товара в неё попадает и при кликабельности в 20% на средней позиции 4,5 это лучший показатель среди всех моих типов расширенных результатов.

Блок вопросов (Q&A) на карточке стоит доводить не «для семантики», а как рабочий тип расширенного результата.

Тип ProductGroup Яндекс валидатору неизвестен

Google – половина картины, а для рунета скорее меньше половины. Я взял выгрузки из Вебмастера за тот же период и прогнал две карточки через валидатор товар с размерами и товар без вариантов.

Результаты разошлись сильнее, чем я ожидал.

Показатель	Google	Яндекс
Карточек товара в индексе	298	326
Адресов вариантов в выдаче	88 получают показы	0
Показов за ~3 месяца	~83 300	63 486
Кликов	~1300	1338
CTR	1,56%	2,11%
Доля небрендовых кликов	меньшая часть	84,7%

Количество проиндексированных карточек сопоставимо. В Яндексе разметка не мешает и не помогает индексации как таковой.

Дальше начинается интересное. Валидатор Вебмастера выдал предупреждение: тип ProductGroup неизвестен по спецификации schema.org. Хотя ProductGroup есть в словаре schema.org. Вероятнее всего устарел валидатор у Яндекса, так как на другие типы разметки он тоже ругается.

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

Карточка без вариантов при этом разбирается полностью и без замечаний.

Тип карточки	Google	Яндекс
Простой товар	валидно	валидно
Товар с размерами	валидно, попадает в ассортиментную выдачу	тип неизвестен

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

Отказываться от неё смысла нет. Рассчитывать на симметричный эффект в двух системах не стоит. Для Яндекса есть отдельный инструмент, который позволяет загружать все товарные предложения сайта с помощью фида и тем самым передавать данные о товарах и получать расширенные сниппеты в поиске.

Вывод

Разметка не является рычагом роста трафика. При этом она позволяет сайтам на фреймворках лучше индексироваться и точнее передавать данные о товарах.

Что разметка действительно даёт:

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

Она меняет не объём выдачи, а её внешний вид. Увеличение CTR на тех же позициях.

Что проверить в своём каталоге за 15 минут

Первые три пункта не требуют разработчика.

1. Посчитайте, сколько у вас адресов на один товар. Возьмите выгрузку из Search Console или Вебмастера. Если адресов заметно больше, чем товарных позиций, — у вас та же история, что была у меня. Каждый цвет и размер живёт отдельной страницей и конкурирует сам с собой.

2. Прогоните пять карточек через оба валидатора. Rich Results Test от Google и валидатор Вебмастера от Яндекса. Не один, а оба так как они ловят разные классы ошибок. Проверяйте по ссылке, а не вставкой кода. Редко кто это делает, но только так видно то, что зависит от заголовков запроса.

3. Откройте отчёт по расширенным результатам в Search Console. Сравните число валидных страниц с числом товаров в каталоге. Если валидных сильно меньше – у вас похожая проблема, что была у меня. ПС просто не может распарсить ваши страницы товаров.

4. Соберите эталон, с которым будете сравнивать.

Проще не описывать это словами, а собрать корректный JSON для одного своего товара с вариантами и прогнать через Rich Results Test сразу станет видно, каких полей не хватает именно вам.

Руками собирать hasVariant на шесть размеров утомительно, поэтому я сделал под эту задачу генератор схемы – заполняете поля товара и вариантов, на выходе готовый JSON-LD.

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

5. Задача разработчику. Просите в таком порядке:

Приоритет	Что	Зачем
1	Признак наличия в каждом товарном предложении	Понимают обе системы. Закрывает большинство ошибок валидации
2	Изображение, цена и валюта на каждом варианте	Самостоятельная сущность, поля от родителя не наследуются
3	Чистота адресов. Clean-param в robots, канонические адреса вариантов	Снимает дубли, которых вы не создавали
4	Разметка вопросов и ответов на карточке	Живой тип расширенного результата с высокой кликабельностью
5	ProductGroup с вариантами	Работает на Google, нейтрально для Яндекса

Итог

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

Микроразметка торговых предложений ProductGroup. Что показали Search Console и Вебмастер за месяц