Картка товару може успішно пройти перевірку після рендерингу, але передавати Google Shopping ненадійні дані про ціну, наявність або вибраний варіант. Причина часто не в синтаксисі JSON-LD, а в тому, коли саме розмітка з’являється на сторінці.
Критичні дані Product і Offer варто формувати з того самого запису, що й видиму картку, та віддавати вже в початковій HTML-відповіді. Окремо перевіряйте сирий HTML, результат рендерингу, перемикання варіантів і звіти Search Console. Google Search уміє обробляти розмітку, яку створює JavaScript, але для Shopping Google тепер прямо радить початковий HTML, а зіставлення в Merchant Center вимагає розмітки у відповіді сервера.
Що Google уточнив у вересні 2026 року
8 вересня 2026 року Google додав до документації дві практичні поради щодо Product: для найкращого результату розміщувати структуровані дані в початковому HTML і перевірити, чи витримає сервер додатковий трафік, якщо розмітка формується за участю JavaScript. Окреме застереження стосується Shopping: динамічно створена розмітка може призводити до рідшого й менш надійного сканування даних, що швидко змінюються, зокрема ціни та наявності.
Це не означає, що будь-який JSON-LD, доданий у браузері, невидимий. Загальна інструкція Google для JavaScript пояснює: Search може обробити структуровані дані, які є в DOM під час рендерингу. Водночас офіційна довідка Merchant Center встановлює суворішу умову для зіставлення товару з посадковою сторінкою: розмітка має бути в HTML, який повернув вебсервер, а не створюватися після завантаження.
Отже, фрази «Google рендерить JavaScript» недостатньо для технічного рішення. Search і торгові системи споживають дані за різними сценаріями. Один успішний Rich Results Test не доводить, що Merchant Center отримає актуальну ціну, а сторінка стабільно відрендериться під навантаженням. Початковий 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 кешується, потрібне прогнозоване скидання кешу при зміні ціни й можливості продажу. Застарілий server-side rendering не кращий за свіжі дані в браузері.
Описуйте варіанти як окремі пропозиції для продажу
Найнебезпечніші помилки виникають із розмірами, кольорами й комплектаціями. Покупець бачить синій розмір M, а JSON-LD описує найдешевший розмір або перший колір у наявності. Перевіряйте початковий варіант, кожен варіант з окремим URL, недоступні комбінації й перемикання без перезавантаження.
Google підтримує ProductGroup із властивостями variesBy, productGroupID і зв’язками між варіантами. Конкретна схема залежить від того, чи всі варіанти живуть на одній сторінці, мають окремі URL або використовують гібридну модель. У будь-якому разі мають однозначно збігатися URL, SKU чи GTIN, зображення, характеристики, ціна, наявність і вкладений Offer.
Не перетворюйте сторінку категорії на один Product. Не ставте всім комбінаціям 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, додану через 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 однієї типової картки.