Карточка товара может успешно проходить проверку после рендеринга, но передавать Google Shopping ненадёжные данные о цене, наличии или выбранном варианте. Причина часто не в синтаксисе JSON-LD, а в моменте появления разметки.
Критичные данные Product и Offer нужно формировать из той же торговой записи, что и видимую карточку, и отдавать уже в исходном HTML. Затем отдельно проверять ответ сервера, результат рендеринга, смену варианта и отчёты Search Console. Google Search умеет обрабатывать разметку, созданную JavaScript, но для Shopping Google теперь прямо рекомендует исходный HTML, а сопоставление в Merchant Center требует серверной разметки.
Что Google уточнил в сентябре 2026 года
8 сентября 2026 года Google добавил в документацию две практические рекомендации для Product: размещать структурированные данные в исходном HTML для лучшего результата и убедиться, что сервер выдержит дополнительный трафик, если разметка создаётся с участием JavaScript. Отдельное предупреждение касается Shopping: динамическая Product-разметка может привести к более редкому и менее надёжному сканированию быстро меняющихся данных, включая цену и наличие.
Это не означает, что любой JSON-LD, добавленный в браузере, невидим. Общая инструкция Google по JavaScript говорит, что Search может обработать структурированные данные, присутствующие в DOM во время рендеринга. Но официальная справка Merchant Center задаёт более строгое условие для сопоставления товара с посадочной страницей: разметка должна находиться в HTML, который вернул веб-сервер, а не создаваться после загрузки.
Вывод практический: «Google умеет рендерить» не означает, что все торговые системы Google одинаково быстро и стабильно получат данные. Один успешный Rich Results Test не подтверждает ни сопоставление с фидом, ни актуальность при высокой нагрузке. Исходный HTML должен быть надёжной основой, клиентский код — дополнением.
Проверьте три разных состояния карточки
Обычный аудит останавливается на готовом DOM или вставляет JSON в валидатор. Так находятся синтаксические ошибки и отсутствующие свойства, но не задержки и расхождения между состояниями. Выберите репрезентативные URL и зафиксируйте три версии страницы в один момент.
| Состояние | Как проверить | Что показывает |
|---|---|---|
| Ответ сервера | Запросить URL без выполнения JavaScript; сохранить статус, заголовки и HTML | Что получает потребитель исходного документа |
| DOM после рендеринга | Открыть страницу в браузере или проверить URL через Rich Results Test | Что появилось после скриптов, API, consent и hydration |
| Состояние после действия | Сменить размер, цвет, рынок, валюту или количество | Согласованы ли страница, URL, canonical, JSON-LD и checkout |
Не путайте исходный код с вкладкой Elements в DevTools: она обычно показывает живой DOM после работы скриптов. Первичный ответ нужно получить отдельным HTTP-запросом. Затем извлеките объекты Product, ProductGroup и Offer и сравните критичные поля.
URL: /products/wool-coat?color=blue&size=m
Проверено: 2026-09-18T08:30:00Z
Поле HTML сервера DOM браузера Карточка Checkout
sku COAT-BLU-M COAT-BLU-M COAT-BLU-M COAT-BLU-M
price 129.00 EUR 109.00 EUR 109.00 EUR 109.00 EUR
availability InStock InStock В наличии В наличии
canonical /wool-coat /wool-coat — —Здесь акционная цена приходит только клиентским запросом. Оба JSON-LD могут быть формально корректными, однако сервер выдаёт устаревшее предложение. Исправлять нужно общий путь цены, а не отдельную строку в SEO-шаблоне.
Создайте один контракт для карточки и машинных данных
Надёжная реализация не считывает цену из готового текста страницы и не ведёт отдельную SEO-базу. Она получает нормализованную запись предложения и из неё в одном ответе строит блок покупки и JSON-LD. Для каждого поля определите источник, владельца и допустимую задержку:
- стабильные идентификаторы товара и варианта: внутренний ID, SKU, настоящий GTIN или MPN, бренд;
- название, основное изображение, канонический URL предложения, состояние товара и выбранный вариант;
- цена, которую покупатель действительно может заплатить, валюта ISO 4217 и срок акции;
- наличие с учётом возможности продать товар, а не только физический остаток на складе;
- доставка и возврат лишь тогда, когда соответствующие правила поддерживаются операционной системой;
- количество и средняя оценка только для реальных отзывов, доступных пользователю на странице.
Merchant Center требует совпадения структурированных значений с видимыми. Для автоматического обновления товаров его документация отдельно называет price, priceCurrency, availability и condition. При этом валидная разметка лишь делает страницу потенциально подходящей для расширенного представления — Google не гарантирует показ.
Частоту обновления диктует риск. Ночной сборки может хватать каталогу под заказ со стабильными ценами. Для краткой распродажи или дефицитного остатка этого мало. Если серверный HTML кешируется, настройте явную инвалидацию при изменении цены и возможности продажи. Устаревший SSR не лучше свежих данных в браузере.
Описывайте варианты как отдельные предложения для продажи
Самые опасные ошибки появляются с размерами, цветами и комплектациями. Покупатель видит синий размер M, а JSON-LD описывает самый дешёвый размер или первый доступный цвет. Проверяйте вариант по умолчанию, каждый вариант с отдельным URL, недоступные комбинации и переключение без перезагрузки.
Google поддерживает ProductGroup со свойствами variesBy, productGroupID и связями между вариантами. Конкретная модель зависит от того, находятся ли варианты на одной странице, имеют отдельные URL или используют гибридную схему. В любом случае должны однозначно совпадать URL, SKU или GTIN, изображение, характеристики, цена, наличие и вложенный Offer.
Не размечайте каталог как один товар. Не назначайте всем комбинациям InStock, если в наличии только часть размеров. Не переключайте валюту по IP, сохраняя один canonical и неизменное предложение. Для разных валют Google рекомендует отдельные URL, а Merchant Center предостерегает от изменения посадочной страницы по IP или типу браузера.
Выберите наименее хрупкую реализацию с нужной свежестью
| Подход | Когда подходит | Главный контроль |
|---|---|---|
| Статическая генерация | Стабильный каталог и запланированные изменения цен | Пересборка или сброс кеша до вступления изменения в силу |
| Серверный рендеринг | Динамические предложения и контекст рынка в запросе | Таймауты, кеш, нагрузка и детерминированный fallback |
| Edge или fragment rendering | Большой каталог с отдельным кешем данных предложения | Версионированный контракт и наблюдаемый возраст кеша |
| Только клиентская вставка | Некритичное дополнение к полной серверной основе | Не зависеть от неё для цены, остатка, ID и варианта |
React, Vue и другой SPA-фреймворк не требует клиентской микроразметки. Критичный JSON-LD можно сформировать при SSR или статической генерации. Сериализованные данные нужно безопасно экранировать, чтобы текст товара не мог закрыть тег script. Не дублируйте цену и наличие в Google Tag Manager: документация Google предупреждает, что копии значений в GTM повышают риск расхождений.
Если архитектуру нельзя изменить сразу, добавьте минимальный серверный Product/Offer из авторитетного источника, а в браузере обогащайте только второстепенные свойства. Зафиксируйте этот компромисс как временный и проверьте, что базовую разметку видят все нужные потребители.
Превратите аудит в матрицу релизных тестов
Одного популярного SKU недостаточно. Включите обычную и акционную цену, OutOfStock, предзаказ, товар без GTIN, несколько вариантов, несколько валют, анонимного посетителя, мобильный user agent, холодный кеш и отказ товарного API. Для каждого сценария автоматически проверяйте:
- HTTP 200, индексируемость и правильный canonical;
- один корректный Product или связный граф ProductGroup в исходном ответе;
- ожидаемые SKU/GTIN, цену, валюту, состояние, наличие и URL;
- полное совпадение с видимой карточкой и итогом в checkout;
- отсутствие противоречивых Product-блоков от темы, плагина, приложения и GTM;
- те же критичные значения после hydration и переключения варианта;
- соответствие требованиям поддерживаемого расширенного представления в Rich Results Test.
Разделяйте синтаксис, бизнес-истину и доставку. Schema.org Validator проверяет словарь и структуру графа. Rich Results Test — требования функций Google и отрендерированный URL. Собственный HTTP-тест — исходный ответ. Пробная покупка — соответствие checkout. Эти проверки дополняют друг друга.
Отслеживайте расхождения после релиза
Google рекомендует проверять Search Console после первого внедрения и изменений шаблонов. Следите за двумя отчётами: Merchant listings для страниц покупки и Product snippets для других страниц о товарах. Важные сигналы — рост невалидных элементов, необъяснимое падение валидных и изменение показов. Учитывайте задержку повторного сканирования и индексации.
Добавьте ежедневную собственную выборку по категориям, рынкам и состояниям склада. Храните хеш исходного и отрендеренного документа, извлечённые поля, время ответа, возраст кеша и версию источника. Основные метрики: доля расхождений, страницы без Product в ответе сервера, дубли графов, возраст устаревшего предложения и время исправления.
План исправления на семь дней
Сначала исправляйте страницы с заметным спросом и частыми изменениями цены или остатка. Выпускайте по шаблону или категории, а не на весь каталог. Сохраняйте ответы до и после как доказательство. Если число валидных элементов падает или расхождения растут, откатите именно способ доставки разметки, не затрагивая прочие обновления каталога.
Частые вопросы
Видит ли Google Product schema, добавленную через JavaScript?
Google Search может обработать структурированные данные в отрендеренном DOM. Но для надёжности Shopping Google рекомендует исходный HTML, а Merchant Center требует серверную разметку для сопоставления с товарными данными.
Повышает ли Product schema позиции?
Структурированные данные помогают понять товар и могут дать право на товарные представления. Они не гарантируют ни rich result, ни рост позиций.
Как проверить микроразметку в исходном HTML?
Запросите публичный URL без выполнения JavaScript и найдите в ответе блок application/ld+json с Product или ProductGroup. Затем сравните его с DOM и видимым предложением.
Нужна ли отдельная schema для каждого варианта?
Каждый продаваемый вариант должен быть описан однозначно. Google поддерживает связи ProductGroup; конкретный способ зависит от того, общий URL у вариантов или отдельные.
Достаточно ли Rich Results Test?
Нет. Дополнительно проверяйте HTML сервера, видимую карточку, checkout, переключение вариантов, дубли разметки, работу под нагрузкой и динамику Search Console.
Источники и дата проверки
Проверено 18 сентября 2026 года по журналу обновлений Google Search, документации о структурированных данных Product, Merchant listings, вариантах товаров, генерации разметки через JavaScript и требованиям Merchant Center. Правила и доступность функций меняются — сверяйтесь с текущей документацией перед релизом.
Rendframe может сопоставить исходные и отрендеренные данные, перестроить рендеринг витрины и добавить тесты, которые удерживают цену, остаток, варианты, фиды и checkout в согласованном состоянии. Начните с аудита фида Merchant Center, посмотрите аудит производительности или пришлите нам URL одной типичной карточки.