Чому ваші товари не ранжуються у Google Shopping: 25 критичних проблем Merchant Center та product data

Такі помилки можуть заважати товарам з’являтися у Google, потрапляти за релевантними запитами та приносити продажі. Тому оптимізацію Google Merchant Center варто починати з перевірки каталогу, фіда, structured data та продуктових сторінок (PDP).

Ми склали докладний гайд, який допоможе вам розв’язати більшість проблеми із ранжуванням товарів у Google Shopping. Ви можете використовувати його як чекліст під час перевірки Merchant Center, товарного фіда й сторінок товарів, щоб проводити швидку діагностику й виправляти помилки.

Чому Google Shopping visibility залежить від якості product data

Google Shopping дає товарам платну й органічну видимість. Вони можуть безкоштовно з’являтися в Google Search, Maps, Gemini, YouTube, вкладці Shopping, Google Images і Lens.

Щоб показати релевантну пропозицію, Google має визначити конкретний товар, його категорію, характеристики, варіант, ціну, наявність та умови покупки. Для цього система використовує Merchant Center, товарний фід, PDP, Product/Offer schema та зображення.

Помилка в обов’язковому полі здатна заблокувати показ товару. Неповні характеристики звужують кількість релевантних запитів, а розбіжності між джерелами заважають підтвердити актуальність пропозиції. Навіть схвалений товар може отримувати мало кліків через слабкий title, невдале зображення або неконкурентні умови продажу.

Системний Google Shopping SEO охоплює весь шлях товарних даних: від внутрішнього каталогу до Merchant Center, результату видачі та покупки на сайті. Це однаково важливо для великих магазинів на Shopify, Magento та інших eCommerce-платформах.

Як Google оцінює товари: Merchant Center, feed, PDP і structured data

Google Merchant Center — це система, через яку магазин передає Google інформацію про товари, ціни, залишки, зображення, доставку та інші умови продажу.

У цій екосистемі кожне джерело виконує окрему функцію:

• фід передає структуровані дані для великої кількості SKU;
• PDP, або сторінка товару, показує користувачеві характеристики й умови покупки;
• Product і Offer schema допомагають виділити з коду сторінки ціну, валюту, наявність, рейтинг та ідентифікатори;
• Merchant Center обробляє каталог і повідомляє про проблеми з товарними даними;
• Search Console допомагає контролювати structured data, індексацію та результати сторінок у пошуку.

Найкраще поєднувати Merchant Center із Product structured data: фід оновлює каталог, а розмітка підтверджує інформацію на PDP. У Search Console звіт Merchant listings охоплює сторінки з можливістю покупки, а Product snippets — огляди та інші сторінки з товарною інформацією без пропозиції продавця.

25 критичних причин, чому товари не отримують Shopping visibility

1. Відсутній або некоректний GTIN

GTIN допомагає Google визначити конкретний серійний товар і зіставити його з відповідними даними у Shopping Graph. Для продукції, якій виробник присвоїв GTIN, потрібно передавати саме цей код. Внутрішній SKU, артикул постачальника або код схожої моделі його не замінюють.

Почніть із товарів, для яких Merchant Center показує проблеми з ідентифікаторами. Звірте GTIN із пакованням, офіційним каталогом виробника або базою GS1. Неправильне значення виправляйте у головному джерелі даних — CMS, ERP або PIM, а потім повторно передайте фід.

Якщо виробник не присвоював товару GTIN, вигадувати код не потрібно. Передайте brand і MPN, якщо вони існують. identifier_exists=false використовуйте лише тоді, коли товар не має ані GTIN, ані коректної зв’язки brand + MPN.

2. Invalid GTIN або дубльовані identifiers

GTIN може мати правильний формат, але належати іншій моделі, комплектації, кількості товарів в упаковці або варіанту. Інша поширена помилка — повторне використання одного коду для різних товарів.

Через це Google може неправильно групувати пропозиції, пов’язувати товар із чужою карткою або показувати помилки Incorrect GTIN і Duplicate GTIN. Така позиція гірше зіставляється із запитами, а в окремих випадках втрачає допуск до показів.

Вивантажте id, gtin, mpn, brand, item_group_id і назву товару. Знайдіть повтори й перевірте, чи справді вони стосуються ідентичного продукту. Різні моделі, набори й варіанти повинні мати окремі GTIN, якщо виробник призначив їм різні коди. Внутрішній id також має залишатися унікальним і стабільним після кожного завантаження.

3. Слабкі product titles

Title — один із головних атрибутів, за якими Google і користувач розуміють товар. Загальні назви на кшталт «Жіноча сукня» або «Ноутбук 15 дюймів» містять замало інформації для точного зіставлення із запитом.

Створіть окремий шаблон title для кожної великої категорії. Назва зазвичай має містити бренд, тип товару, модель і характеристики, які впливають на вибір. Для ноутбука це можуть бути серія, діагональ, процесор і пам’ять; для взуття — бренд, тип, стать, колір і розмір. Наприклад:

• ASUS Vivobook 15 X1504VA 15,6″, Intel Core i5, 16/512 ГБ

• Жіночі кросівки Nike Pegasus 41, чорні, розмір 38

• Зволожувальний крем CeraVe для сухої шкіри, 177 мл

Найважливіші слова ставте ближче до початку. Приберіть рекламні фрази, зайві великі літери, повтори ключів і характеристики, яких немає на PDP. Після оновлення порівняйте CTR тестової групи з попереднім періодом. Вказуйте також властивості товару у відповідних атрибутах фіда, щоб мінімізувати ймовірність помилок.

4. Duplicate product titles

Однакові назви не показують різницю між кольорами, розмірами, об’ємами, моделями або комплектаціями. Через це Google гірше розрізняє SKU всередині товарної групи, а користувач бачить кілька майже однакових пропозицій.

Вивантажте id, title, item_group_id і характеристики варіантів. Знайдіть повні дублікати всередині кожної групи та визначте, якою властивістю відрізняються товари.

Додайте до назви колір, розмір, об’єм пам’яті, розмір пакування або іншу важливу характеристику конкретного SKU. Оновлений title має збігатися з PDP, фідом і зображенням. Для зовні та функціонально однакових товарів штучно створювати різні назви не потрібно.

Google також підтримує item_group_title для спільної назви батьківської товарної групи. Індивідуальні title варіантів мають містити відмінні властивості, а групова назва — описувати модель без кольору, розміру чи іншої конкретної опції.

Наприклад, групова назва «Жіночі кросівки Nike Pegasus 41» об’єднує окремі title: «Жіночі кросівки Nike Pegasus 41, чорні, розмір 38» і «Жіночі кросівки Nike Pegasus 41, білі, розмір 39».

5. Missing attributes у фіді

Атрибути допомагають Google знаходити товар за конкретними long-tail запитами. Без color, size, material, gender, age_group, pattern, capacity або compatibility система бачить загальний тип продукту, але не розуміє його властивостей.

Для кожної категорії створіть матрицю обов’язкових і рекомендованих полів. Порахуйте відсоток заповнення та порівняйте його з характеристиками, які покупці використовують у фільтрах, пошуку й консультаціях.

Першими додайте атрибути, що визначають варіант або часто входять до запитів. Налаштуйте їх автоматичне передавання з CMS, ERP або PIM. Значення у фіді повинні збігатися з PDP: якщо на сайті колір називається «Графітовий», у Merchant Center також потрібно передавати «Графітовий», а не «Сірий».

Google використовує товарні дані для зіставлення продуктів із релевантними запитами, тому повнота атрибутів безпосередньо впливає на те, наскільки точно система розуміє пропозицію.

6. Неправильна Google Product Category

Google автоматично визначає категорію товару, але продавець може передати точніше значення через google_product_category. Надто широка або помилкова категорія послаблює класифікацію та може активувати невідповідні вимоги до атрибутів.

Виберіть товари з низькою видимістю, великою кількістю попереджень або показами за нерелевантними запитами. Порівняйте призначену категорію з актуальною таксономією Google — офіційною системою категорій, за якою товари розподіляються від загальних розділів до конкретних типів.

Передайте одну найбільш конкретну категорію за основним призначенням продукту. Після повторної обробки перевірте статус товарів, нові попередження та релевантність запитів у звітах. Атрибут google_product_category дозволяє перевизначити автоматичну категоризацію Google у тих випадках, коли вона неточна.

7. Слабка власна product taxonomy

Внутрішня таксономія магазину визначає, як товари групуються в каталозі й передаються через product_type. Категорії «Хіти», «Акції» або «Новинки» описують маркетинговий статус товарів, але не пояснюють, до якого типу вони належать..

Хаотична структура ускладнює сегментацію рекламних кампаній, налаштування feed rules, аналіз категорій і масштабування каталогу. Атрибут product_type також передає Google точнішу структуру асортименту.

Побудуйте стабільну ієрархію від широкої групи до конкретного типу, наприклад: «Спорт > Біг > Взуття > Трейлові кросівки». Передайте її через product_type. Акційність, сезонність і маржу краще винести в custom labels або окремі добірки сайту.

8. Feed vs PDP mismatch

Feed vs PDP mismatch виникає, коли Merchant Center і сторінка товару показують різні назви, бренди, ціни, залишки, варіанти або зображення. Google отримує кілька версій однієї пропозиції, через що товар може отримати попередження, обмеження або відхилення.

Виберіть 20–30 проблемних SKU та порівняйте оброблені дані в Merchant Center, видимий контент PDP, Product/Offer schema й дані конкретного варіанта. Особливо уважно перевіряйте ціну, валюту, availability, URL і основне фото.

Визначте одне головне джерело для критичних полів. Воно має одночасно оновлювати сайт, structured data та фід. Після виправлення повторно завантажте джерело й перевірте контрольну вибірку.

9. Price conflicts

Price conflict або price mismatch — це різниця між ціною у фіді, на PDP, у structured data або під час оформлення покупки. Окремі проблеми виникають через неправильну валюту, sale price чи період дії знижки.

Відкрийте PDP без авторизації, персональних знижок і старих cookies. Перевірте звичайну та мобільну версії, конкретний варіант, акційну ціну й фінальну суму в кошику. Для міжнародного сайту окремо звірте валюту й регіональну версію сторінки.

Звичайну ціну передавайте через price, акційну — через sale_price, а період її дії — через sale_price_effective_date. Синхронізуйте фід із системою, яка формує ціну на PDP. Для частих змін використовуйте регулярне завантаження або API.

10. Availability conflicts

Availability conflict або availability mismatch виникає, коли фід передає in_stock, а PDP показує out_of_stock, або навпаки. Для товарів із різними варіантами проблема часто стосується конкретного кольору чи розміру, хоча сам продукт залишається доступним.

Звірте час оновлення ERP, CMS і фіда. Перевірте availability конкретного SKU у Merchant Center, видимому контенті PDP та schema. Окремо протестуйте товари, які швидко розпродаються або повертаються в наявність.

Передавайте статус із тієї самої системи, яка керує залишками на сайті, й оновлюйте Merchant Center після кожної зміни. Тимчасово відсутню PDP залишайте доступною та використовуйте out_of_stock. Автоматичні item updates можна застосовувати як додатковий захист від короткочасних розбіжностей.

Важливо: для товару, який остаточно зняли з продажу, немає одного універсального SEO-сценарію. Пропозицію потрібно прибрати з product data Merchant Center, але корисну PDP можна залишити доступною та передати у structured data schema.org/Discontinued. Якщо є справді рівноцінна заміна, доречний 301 redirect. Якщо сторінку та її контент вирішено повністю видалити, можна повернути 404 або 410.

11. Некоректна Product schema

Помилки Product schema обмежують можливість сторінки з’являтися в merchant listings і product snippets. Серед типових причин — невалідний JSON-LD, відсутній Offer, неправильні priceCurrency, availability або рейтинг.

Перевірте шаблон у Rich Results Test, а кілька живих сторінок — через URL Inspection. У Search Console відкрийте звіти Merchant listings і Product snippets, розділивши errors та warnings.

Масові структурні помилки виправляйте в шаблоні або генераторі schema. Якщо проблема стосується лише одного SKU — наприклад, неправильного GTIN, ціни, рейтингу чи availability, — змініть дані конкретного товару. Після оновлення перевірте live URL і запустіть validation у Search Console.

Aggregate Rating потрібно передавати лише тоді, коли рейтинг доступний користувачеві й справді стосується цього товару.

12. Schema не збігається з Merchant Center

Навіть валідна Product schema може передавати іншу версію товарної інформації. Таке трапляється, коли фід працює з ERP, PDP — із кешованої бази, а JSON-LD генерує окремий плагін.

Для контрольного SKU порівняйте name, SKU, GTIN, MPN, brand, price, priceCurrency, availability, URL і зображення. Потім визначте систему, яка формує кожне поле.

Основну увагу приділіть технічній причині розбіжності: застарілому кешу, дубльованому модулю, неправильному мапінгу атрибутів або окремому генератору JSON-LD. Після синхронізації повторно протестуйте schema та оброблені дані в Merchant Center.

13. Thin PDP content

Бідна продуктова сторінка або thin PDP містить лише фото, ціну, короткий опис і кнопку «Купити». Вона не відповідає на питання про сумісність, комплектацію, розміри, матеріал чи умови використання.

Перевірте, чи PDP пояснює, що це за товар, кому він підходить, чим відрізняється від інших моделей і на яких умовах його можна придбати. Набір інформації має відповідати категорії: для ноутбука важливі дисплей, продуктивність і порти, а для косметики — склад, тип шкіри та спосіб застосування.

Створіть окремі PDP-шаблони для основних товарних груп. Додайте характеристики, сумісність, комплектацію, доставку, повернення, FAQ та мультимедіа там, де вони допомагають вибору. Перевірте, чи відповідає текст на практичні питання потенційного клієнта.

14. Дубльовані supplier descriptions

Стандартний опис постачальника часто повторюється на десятках сайтів і містить лише базову специфікацію. Саме дублювання не означає автоматичного покарання, але така PDP майже не пояснює унікальні властивості товару й конкретної пропозиції магазину.

Порівняйте текст із сайтом виробника та сторінками конкурентів. Визначте, яких відомостей бракує: сумісності, комплектації, сценаріїв застосування, порівняння моделей, доставки або відповідей на питання клієнтів.

Збережіть точні технічні дані й доповніть їх власними практичними блоками. Починайте з SKU, які мають найбільше показів, дохід або потенціал конверсії. Нові характеристики передавайте також у відповідних полях фіда, якщо Google підтримує такі атрибути.

15. Немає сценаріїв використання товару

Характеристики пояснюють, із чого складається товар, але не завжди показують, для яких задач він підходить. Це особливо важливо для long-tail та AI Shopping, де користувач може описувати потребу замість конкретної моделі.

Зберіть питання з внутрішнього пошуку, чатів, консультацій і відділу продажів. Перевірте, чи PDP відповідає на запити «для кого», «для чого», «з чим сумісний» і «чим відрізняється».

Додайте короткі сценарії застосування, підтверджені характеристиками продукту. Наприклад: «підходить для індукційної плити» або «сумісний із MacBook Pro M3». Уникайте загальних рекламних обіцянок, які неможливо перевірити.

16. Відсутня оптимізація варіантів

Колір, розмір, матеріал, об’єм і комплектація можуть впливати на ціну, наявність, URL та зображення. Якщо варіанти неправильно пов’язані або не мають окремих SKU, Google може плутати їхні характеристики й показувати неточну пропозицію.

Скопіюйте URL конкретного варіанта та відкрийте його в іншому браузері. Потрібний колір, розмір або комплектація мають завантажитися автоматично. Також звірте id, item_group_id, title, variant attributes, price, availability, link та image_link.

Кожному SKU призначте унікальний id, а варіантам однієї моделі — спільний item_group_id. Передавайте точні URL, фото, ціни й залишки. У structured data використовуйте ProductGroup, variesBy, hasVariant і productGroupID, якщо шаблон сайту підтримує таку логіку.

Зверніть увагу: із травня 2026 року Google також підтримує variant_option, який дозволяє явно назвати властивості, за якими відрізняється конкретний варіант, та item_group_title для спільної назви всієї групи. Вони особливо корисні для нестандартних варіантів, які не повністю описуються color, size, material або pattern. 

17. Низька якість зображень

Зображення займає значну частину товарного лістингу у видачі й впливає на CTR. Розмите, занадто маленьке або невиразне фото зазвичай програє конкурентам.

Перегляньте основні зображення в мобільному форматі. Перевірте роздільну здатність, розмір товару в кадрі, фон, сторонній текст, водяні знаки та доступність URL для Google.

Замініть проблемні файли на чіткі фото конкретного товару. Основне зображення має показувати продукт без реклами і placeholder. Додаткові ракурси, деталі та сценарії використання передавайте через additional_image_link.

URL також має залишатися стабільним і доступним для сканування. Якщо robots.txt блокує зображення, товар із часом може втратити схвалення.

18. Немає variant-specific images

Однакове фото для всіх кольорів, моделей або комплектацій створює конфлікт між title, атрибутами варіанта й зображенням. Це послаблює візуальне зіставлення та знижує довіру після переходу.

Відкрийте товарну групу й послідовно перегляньте кожен SKU. Title, color, image_link, URL і вибраний стан PDP повинні описувати той самий варіант.

Для кожного варіанта потрібно передати унікальний URL через image_link, навіть якщо окремі варіанти виглядають однаково й відрізняються лише розміром. Сам візуальний контент у таких випадках може бути однаковим, але URL зображення повинен бути окремим. Для кольору, дизайну, набору чи комплектації потрібне також фактично відповідне фото. Після оновлення перевірте оброблені дані в Merchant Center і переконайтеся, що кожен SKU отримав правильне зображення.

19. Merchant Center warnings і disapprovals ігноруються

Disapproval блокує показ товару в конкретному форматі, а warning вказує на неповні дані або проблему, яка потребує перевірки. Якщо команда реагує лише на повні відхилення, частина каталогу може поступово втрачати охоплення.

Відкрийте Products — Needs attention (актуальна назва розділу, який раніше називався Diagnostics) і розділіть проблеми на рівень акаунта та окремих товарів. Зафіксуйте disapproved SKU, limited visibility і warnings із найбільшим охопленням.

Спочатку усуньте ризики акаунта й відхилення. Потім переходьте до масових попереджень. Завантажте список проблемних SKU, знайдіть спільне джерело помилки та виправте CMS, ERP, фід або правило трансформації замість ручного редагування кожного товару.

20. Немає системного feed QA

Feed QA — це регулярний контроль фіда після кожного завантаження та зміни каталогу. Без нього команда може не помітити, що частина SKU зникла, атрибути стали порожніми, ID дублюються, а ціни чи залишки перестали оновлюватися.

Після кожного імпорту перевіряйте статус обробки, кількість отриманих товарів, частку відхилень, missing attributes і контрольну вибірку PDP. Порівнюйте кількість SKU з попереднім завантаженням.

Налаштуйте регулярний процес: щодня контролюйте processing errors, price та availability, а щотижня — GTIN coverage, title, images і taxonomy. Для великого каталогу варто автоматизувати сповіщення про різке скорочення кількості товарів або масову появу помилок.

21. Не використовуються supplemental feeds або feed rules

Без supplemental data sources і attribute rules у фіді можуть залишатися пропущені атрибути, різні формати значень і слабка сегментація товарів. У результаті команда виправляє одні й ті самі проблеми вручну або залишає частину каталогу з неповними даними.

Визначте поля, які потрібно масово додати чи виправити: product type, custom labels, title, колір або інші атрибути. Перевірте доступність функцій supplemental sources і attribute rules через Advanced Data Source Management у Merchant Center.

Supplemental data sources, або додаткові джерела даних, оновлюють чи доповнюють атрибути вже наявних товарів за їхнім id. Attribute rules допомагають трансформувати, нормалізувати та об’єднувати значення.

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

22. Слабкий review ecosystem

Відсутність свіжих і коректно прив’язаних відгуків послаблює довіру до товару й може знижувати CTR. Покупець також не отримує практичної інформації про посадку, фактичний колір, зручність або тривале використання.

Звірте відгуки на PDP, Review/AggregateRating schema та Product Ratings. Рейтинг має стосуватися конкретного SKU або коректно сформованої товарної групи й бути доступним користувачу.

Налаштуйте збір відгуків після покупки та їх прив’язку до відповідного товару. Структуровані дані мають відтворювати рейтинг, який бачить користувач. Для Product Ratings можна використовувати прямий фід або схваленого агрегатора за умови відповідності вимогам програми.

Будьте уважні: product ratings використовуються для розширеного представлення товарів, а store ratings допомагають покупцям оцінювати якість взаємодії з продавцем.

23. Недостатні merchant trust signals

Неповні умови доставки, оплати й повернення знижують довіру покупців і ускладнюють перевірку інформації про продавця. Ця проблема критична для дорогих товарів та міжнародної торгівлі.

Перевірте сторінки About Us, контактів, оплати, доставки, повернення, обміну та гарантії. Відомості повинні відкриватися без авторизації, містити конкретні строки й вартість та збігатися з налаштуваннями Merchant Center.

Створіть окремі сторінки політик, а основні умови коротко покажіть на PDP і під час оформлення замовлення. Додайте актуальні контакти й юридичні дані. Для міжнародного продажу окремо опишіть регіональні умови доставки та повернення.

У Store Quality Google окремо оцінює shipping, returns, browsing і purchase experience. Зміни політик можуть відображатися у програмі не одразу, тому після оновлення варто повторно перевірити статус.

24. Повільні PDP і слабкий mobile UX

Повільна PDP знижує конверсію після кліку. На мобільному пристрої проблему посилюють зміщення елементів, незручний вибір варіанта та складний checkout.

Протестуйте сторінки у PageSpeed Insights і самостійно пройдіть мобільний сценарій: відкрийте галерею, виберіть варіант, перевірте ціну, додайте товар у кошик і почніть оформлення. PDP також потрібно відкрити без авторизації та перевірити на смартфоні.

Окремо проаналізуйте Core Web Vitals. Google рекомендує орієнтуватися на LCP до 2,5 секунди, INP до 200 мілісекунд і CLS до 0,1.

Оптимізуйте основні зображення, JavaScript і сторонні сервіси. Зафіксуйте місце для фото, ціни й кнопок, щоб уникнути зміщень. Спрощуйте вибір варіантів і checkout. Першими виправляйте проблеми, які стосуються всього PDP-шаблону, а потім — конкретні недоліки окремих сторінок.

25. Немає вимірювання Organic Shopping visibility

Без окремого вимірювання безкоштовні товарні покази змішуються з платними оголошеннями Google Ads, класичним SEO та іншими переходами. Команда не бачить, які SKU отримують impressions, де низький CTR і чи дали результат зміни фіда або PDP.

Для повної картини потрібно розділити діагностику й performance-метрики.

Звіти Merchant listings і Product snippets у Search Console показують warnings та errors у Product structured data. Для PDP інтернет-магазину основним зазвичай буде Merchant listings. Product snippets варто окремо перевіряти для оглядів, агрегаторів та інших сторінок без merchant offer.

Покази, кліки, CTR і середню позицію аналізуйте у Search Console Performance. Через фільтр Search appearance можна окремо переглядати Merchant listings, Product snippets та інші типи товарних результатів, якщо вони вже отримували покази. У Merchant Center аналізуйте Organic traffic і результати безкоштовних лістингів. Додатково налаштуйте SKU-level tracking у GA4, щоб пов’язувати переходи з покупками та доходом.

Розділіть товари на три групи:

• немає показів;
• є покази, але мало кліків;
• є кліки, але немає покупок.

Для кожного оновлення title, фіда або PDP фіксуйте дату й тестову групу. Порівнюйте однакові періоди з урахуванням сезонності, рекламних кампаній і змін асортименту.

Як провести Merchant Center audit: що перевірити в першу чергу

Merchant Center audit варто починати з проблем, які блокують або обмежують покази. Після цього можна переходити до title, контенту, зображень і підвищення CTR.

1. Перевірте Merchant Center

Відкрийте Products — Needs attention і зафіксуйте:

• проблеми на рівні акаунта;
• кількість відхилених товарів;
• SKU з обмеженою видимістю;
• warnings із найбільшим охопленням;
• формати показу, для яких виникла проблема.

Завантажте окремий список товарів для кожної масової помилки.

2. Перевірте фід

У Data sources перегляньте дату та частоту завантаження, processing errors, кількість отриманих товарів, primary і supplemental sources та attribute rules.

Різке зменшення кількості SKU часто вказує на проблему з експортом, фільтром або завантаженням. Порівнюйте кожен імпорт із попереднім.

3. Проаналізуйте product data

Перевірте GTIN coverage, дублікати ID, MPN, brand, структуру title, missing attributes, Google Product Category, product type, item_group_id, variant_option та item_group_title. Для кожної категорії потрібно сформувати власний набір обов’язкових і рекомендованих полів.

4. Звірте фід, PDP і schema

На контрольній вибірці порівняйте title, ціну, валюту, sale price, availability, бренд, GTIN, варіант, URL та основне зображення. Product/Offer schema протестуйте через Rich Results Test. PDP також потрібно відкрити без авторизації та перевірити на смартфоні.

5. Оцініть UX та аналітику

Розділіть товари на три групи:

• немає показів;
• є покази, але низький CTR;
• є кліки, але немає конверсій.

Для першої групи перевіряйте допуск до показів, Merchant Center, фід та зіставлення із запитами. Для другої — title, зображення, ціну й релевантність. Для третьої — PDP, доставку, довіру та мобільний UX.

Що має входити у сучасний Shopping SEO audit

Як Panem Agency допомагає знайти та виправити Shopping SEO problems

Наша команда проводить комплексний SEO аудит для Shopping і визначає, де саме каталог втрачає видимість: у Merchant Center, фіді, товарних атрибутах, structured data, PDP або аналітиці. Ми перевіряємо допуск товарів до показів, узгодженість даних, зіставлення із запитами та шлях користувача від лістингу до покупки.

Після аудиту ви отримуєте список проблемних SKU, перелік технічних і контентних помилок, оцінку їхнього масштабу та пріоритет виправлення. Для кожної проблеми ми вказуємо конкретну дію, відповідальну команду й спосіб повторної перевірки. Завдяки цьому SEO-, PPC-, development і merchandising-фахівці можуть одразу використовувати звіт як робочий план.

За потреби наша команда Panem Agency може виконати необхідні роботи: налаштувати фід, виправити Product schema, синхронізувати ціни й залишки, оптимізувати товарні атрибути, зображення та PDP. Після повторного завантаження ми перевіримо статус товарів і будемо відстежувати зміни в Organic Shopping impressions, CTR, конверсіях та доході.

Залиште заявку на Shopping SEO audit. Ми знайдемо причини втрати товарного трафіку, визначимо першочергові виправлення та допоможемо перетворити Merchant Center і каталог на керований канал органічної видимості та продажів.

Тарас Василишин. Co-founder Panem Agency

Безкоштовна консультація

FAQ

Чи впливає Merchant Center на органічну видимість товарів у Google?

Так. Дані Merchant Center використовуються для безкоштовних товарних лістингів та інших Shopping-форматів. Однак само по собі завантаження товару не гарантує показів: він також має відповідати вимогам Google і бути релевантним запиту.

Чому товари є в Merchant Center, але не отримують показів?

Перевірте статус товару, Needs attention, marketing methods, цільову країну, GTIN, title, категорію, ціну та availability. Схвалений статус означає можливість, але не гарантію показу.

Чим Merchant Center audit відрізняється від звичайного SEO-аудиту?

SEO-аудит перевіряє індексацію, структуру й контент сайту. Merchant Center audit додатково охоплює фіди, product identifiers, disapprovals, атрибути, варіанти та розбіжності між Merchant Center і PDP.

Що важливіше для Google Shopping SEO: фід чи сторінка товару?

Потрібні обидва джерела. Фід передає структуровані дані для каталогу, а PDP підтверджує пропозицію та допомагає користувачеві прийняти рішення.

Як часто потрібно перевіряти Merchant Center?

Needs attention варто контролювати щодня або через сповіщення. Після змін сайту чи фіда потрібна додаткова перевірка, а повний аудит доцільно проводити щомісяця та перед великими запусками.