Микроразметка товаров Яндекс: что проверить кроме валидности

Магазин добавил Product и Offer. Валидатор доволен: ошибок нет, задача закрыта. Через некоторое время маркетолог открывает поиск и не видит ни цены, ни ожидаемого товарного оформления. А команда снова идёт править JSON-LD, добавляя всё новые поля.

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

Микроразметка помогает поисковым системам и другим программным системам понять, что находится на странице и какое предложение описывает товар. Но при её приёмке нужно ответить сразу на три разных вопроса:

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

Если свести всё к пункту «Schema.org внедрена», получится красивый отчёт, но непонятно, почему результат так и не появился.

Ниже — практический порядок проверки для SEO-специалиста, руководителя маркетинга и владельца магазина. Рекомендации опираются на документацию, проверенную 31 октября 2026 года. Примеры условные: это не описание клиентского эксперимента.

Сначала определите, что именно должно измениться

Фраза «добавить микроразметку» сама по себе не является нормальной задачей. У неё нет критерия успеха.

Лучше сразу описать:

• какой тип страницы меняется;
• какую систему вы хотите заинтересовать;
• какое представление рассчитываете получить;
• по какому наблюдаемому признаку поймёте, что работа принята.

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

У Google, например, отдельно описаны сценарии Product snippets и Merchant listings. Первый применяется, в частности, к страницам о товаре, где непосредственно купить его нельзя, включая редакционные обзоры. Второй рассчитан на страницы продавцов, где товар можно приобрести. У этих сценариев отличаются требования и доступные возможности.

Поэтому нельзя брать пример разметки для обзора и автоматически переносить его на магазин только потому, что в обоих случаях используется Product.

Перед разработкой достаточно зафиксировать четыре пункта:

1. тип страницы;
2. целевую систему и функцию;
3. ожидаемый вид результата;
4. критерий приёмки.

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

Schema.org — это словарь, а не гарантия поискового результата

Product в Schema.org описывает сущность товара и её свойства. Но сам факт существования свойства в словаре не означает, что конкретная поисковая система использует его в нужном вам представлении.

Поэтому внедрение лучше начинать не с полного перечня полей Schema.org, а с документации выбранной поисковой функции. Словарь нужен затем — чтобы проверить, что сущности и значения описаны по смыслу и в подходящем формате.

То же касается JSON-LD. Google поддерживает несколько форматов структурированных данных и обычно рекомендует JSON-LD за удобство сопровождения. Но это способ записи, а не отдельный SEO-бонус. Поддерживаемые и технически корректные форматы могут решать одну и ту же задачу.

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

Приёмку удобно разделить на три уровня:

• Данные. Сущность определена правильно, а значения соответствуют реальному предложению.
• Право участия. Выполнены требования выбранной поисковой функции, а страница доступна для обработки.
• Эффект. Меняются показы, переходы или коммерческие действия, которые можно обоснованно связать с внедрением.

Зелёная отметка закрывает только первый уровень — и то не всегда полностью. Отсутствие заметного эффекта, в свою очередь, ещё не доказывает, что разметка сломана.

Самая опасная ошибка: правильный JSON и неправильная цена

Представим карточку настольной лампы. На странице покупатель видит 4 990 рублей, в структурированных данных указано 5 490, а в товарном фиде ещё действует вчерашняя акция.

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

Для Merchant listings Google описывает передачу текущей цены и валюты через Offer, в том числе вариант с priceSpecification. В этом сценарии цена должна быть больше нуля. Но из этого не следует, что достаточно просто заполнить пару полей: полный набор условий нужно сверять с документацией конкретного сценария.

Поэтому до внедрения полезно составить простую карту происхождения данных. Например:

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

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

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

Представьте магазин, где скидка меняется в учётной системе мгновенно, страница обновляется сразу, а JSON-LD собирает ночная задача. В такой ситуации проблема не в том, что «в JSON не хватает ещё одного поля». Она в расписании и источнике генерации.

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

При приёмке полезно проверять переходы между состояниями:

• обычная цена → акция;
• товар в наличии → закончился;
• стандартный вариант → более дорогой вариант.

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

Отдельный риск — кеш. Если HTML уже обновился, а встроенная разметка осталась старой, фиксируйте время проверки и слой, где возникло расхождение. Разработчику нужна воспроизводимая последовательность действий, а не сообщение «Google неправильно видит цену».

Rich Results Test не проверяет всё

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

Это конкретный сценарий, а не универсальное утверждение, что Google никогда не обрабатывает JavaScript.

Поэтому фраза «Rich Results Test всё увидел» ещё не означает, что вы проверили требования другого механизма.

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

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

• карточку товара;
• структурированные данные;
• соответствующую запись фида.

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

Не стоит и заполнять пропуски выдуманными значениями. Если реальный срок акции не определён, нельзя придумывать дату только ради заполненного поля. Если у товара нет отзывов, нельзя создавать рейтинг из воздуха.

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

Google и Яндекс нужно проверять отдельно

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

В справке Яндекса для товарных страниц указаны Product и offers с Offer либо AggregateOffer, а также собственный набор учитываемых полей. Там же отмечено, что структурированные сниппеты не формируются для страницы с разными товарами.

Значит, в чек-листе разумно завести отдельные проверки для Google и Яндекса. При этом сами бизнес-данные могут оставаться общими: отдельно контролируются именно правила их передачи и обработки.

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

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

В контрольную выборку полезно включить товары:

• со скидкой;
• без наличия;
• с вариантами;
• с неполными исходными данными.

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

Почему валидатор не обещает расширенный результат

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

Отсюда логичный порядок диагностики:

1. определить, какой объект система вообще обнаружила и есть ли ошибки;
2. проверить соответствие видимому предложению;
3. убедиться, что страница доступна и подходит под условия функции;
4. только после этого разбираться, почему фактического показа нет.

Бесконечно добавлять поля без такого диагноза — плохой способ тратить разработческие ресурсы.

Ещё одна важная деталь — различайте критические ошибки и рекомендации инструмента. Необязательное поле не нужно заполнять неподтверждённым значением только ради исчезновения предупреждения. Сначала решите, действительно ли эта информация нужна и сможете ли вы поддерживать её актуальность.

Для Product snippets Google рекомендует тестировать изменения, развёртывать их сначала на части страниц и затем проверять опубликованные URL. Такой подход хорошо работает и как организационная практика: сохранить результаты до изменения, внедрить ограниченную партию, проверить живые страницы и только потом масштабировать решение.

Что всё это значит для AEO и GEO

Термины AEO и GEO используются в отрасли с разными границами. В контексте товарных карточек речь обычно идёт о том, насколько хорошо информация подготовлена для ответных и генеративных интерфейсов поиска.

Но из этого не следует, что существует единая обязательная «разметка для нейросетей».

Google отдельно сообщает, что для AI Overviews и AI Mode специальная Schema.org-разметка не требуется. Это позиция конкретной платформы и она не описывает внутреннюю обработку данных всеми ИИ-системами.

Поэтому оценивать товарную разметку лучше через то, что можно проверить:

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

Обещание вроде «добавим Product, и ChatGPT начнёт рекомендовать магазин» требует отдельного доказательства. Валидатор таких выводов не даёт.

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

Совпадение по времени не доказывает причинность: одновременно могли измениться текст страницы, ассортимент или сам поисковый интерфейс.

Как поставить задачу разработке и потом измерить результат

Рабочее техническое задание можно собрать в семь пунктов:

• перечислить шаблоны и целевые функции Google и Яндекса со ссылками на требования;
• для каждого поля определить источник, владельца и правила обновления;
• описать идентификацию товара и предложения, валюту и поведение вариантов;
• предусмотреть сценарии скидки, отсутствия товара и неполных данных;
• проверить код, видимый контент и опубликованные URL, сохранив результаты и даты;
• зафиксировать дату релиза и список изменённых страниц;
• назначить ответственного за контроль после изменения цен, шаблона и плагинов.

Измерять эффект лучше слоями.

Сначала — техническое покрытие: на каких страницах данные обнаружены, сколько расхождений осталось и какие шаблоны исправлены.

Затем — поисковое представление и переходы.

И только после этого — полезные действия посетителей и выручка, если эти данные доступны в аналитике.

Это разные метрики. Они вполне могут двигаться в разные стороны.

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

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

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

Исправьте подтверждённые расхождения, снова проверьте опубликованные страницы и только после этого расширяйте внедрение.

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