Помилки Google Merchant Center: як виправити без хаосу

Визначення

Google Merchant Center — кабінет, через який Google отримує товарні дані магазину для Shopping, Performance Max і безкоштовних показів.

Disapproval — відхилення товару або групи товарів через помилку в даних, сторінці товару, політиках чи вимогах Google.

Suspended account — блокування акаунта Merchant Center на рівні магазину, коли проблема виходить за межі окремого SKU.

feed.xml — файл або потік даних із товарами: id, назва, опис, ціна, наявність, посилання, фото, бренд, GTIN або MPN.

GTIN / MPN — товарні ідентифікатори, за якими Google звіряє товар із каталогами, виробниками й іншими продавцями.

identifier_exists=false — атрибут для товарів без стандартних ідентифікаторів; неправильне використання може спричинити масові відхилення.

Як Google Merchant Center вирішує, чи можна показувати товари в Shopping і Performance Max

Google Merchant Center — це не «місце, куди завантажили фід». Це проміжний шар між інтернет-магазином, Google Shopping, Performance Max і рекламним акаунтом. Тут Google перевіряє, чи збігаються товарні дані, сайт і умови покупки, перш ніж допустити товар до реклами.

Типова помилка українських магазинів звучить так: «У нас проблема у feed.xml, треба поправити один атрибут». Іноді так. Але частіше Merchant Center бачить не один зламаний рядок, а розрив між фідом і сайтом: у фіді одна ціна, на сторінці інша; у фіді товар in_stock, а на сайті «немає в наявності»; у фіді заявлена доставка, але на сайті немає зрозумілих умов оплати, повернення або контактів. Google описує проблеми в Merchant Center на кількох рівнях: товари, фід, обліковий запис і налаштування, а не тільки один рядок у даних: Google Merchant Center Help.

• Merchant Center перевіряє кілька рівнів одночасно:
• Рівень товару: title, description, price, availability, image_link, GTIN, MPN, brand, identifier_exists.
• Рівень фіда: структура feed.xml, стабільність id, коректні атрибути, валюта, мова, категорії.
• Рівень сторінки товару: ціна, наявність, кнопка покупки, фото, опис, варіації, мікророзмітка.
• Рівень магазину: доставка, оплата, повернення, контакти, юридична інформація, довіра до сайту.

Рівень акаунта: Merchant Center, Google Ads, домен, підтвердження сайту, історія порушень.

Google порівнює дані з фіда з тим, що бот бачить на сторінці товару. Якщо в feed.xml ціна 1299 грн, а на сайті 1399 грн після вибору кольору або розміру, це ризик. Якщо товар у фіді активний, але на сторінці немає можливості купити без дзвінка менеджеру, це теж сигнал. Окрема довідка Google про «помилку зіставлення» описує логіку порівняння поданих даних із даними на цільовій сторінці: Google Merchant Center Help.

Для українських Horoshop, Shopify, Tilda і WordPress-магазинів проблеми зазвичай починаються не з рідкісних атрибутів, а з базової неузгодженості:

• ціна у фіді не збігається з ціною на сайті;
• наявність оновлюється із затримкою;
• доставка описана в картці, але не винесена в окрему політику;
• контакти сховані або не збігаються з даними в Merchant Center;
• сторінки оплати, повернення й гарантій є, але їх важко знайти з товарної сторінки;
• варіації товару мають однаковий id або дублюють GTIN.

У нашій практиці фід не можна оцінювати окремо від сайту. Merchant Center перевіряє не таблицю товарів, а шлях користувача до покупки: що він бачить у рекламі, що відкривається на сторінці й чи може він зрозуміло купити товар. На 200+ підключеннях Merchant Center в UPLIFY ми бачимо, що 73% disapproval закриваються не редагуванням feed.xml, а виправленнями в товарних картках, політиках і довірчих блоках магазину. Тому порядок робіт має бути знизу вгору: спочатку прибрати розрив між даними й сторінкою, потім чистити атрибути, потім масштабувати Shopping і Performance Max.

Чому точкове виправлення одного атрибута рідко закриває проблему

У Merchant Center легко сприйняти помилку як окреме поле в таблиці: Google пише price mismatch — міняємо price; пише missing GTIN — додаємо GTIN; пише id already used — переписуємо id. Це швидко. Інколи навіть спрацьовує. Але для українських магазинів на Horoshop, Shopify, Tilda або WordPress такий підхід часто закриває симптом, а не причину.

Google розділяє проблеми в Merchant Center за рівнями: акаунт, фід, товари, політики. Тому одна помилка в Diagnostics може тягнутися не з одного атрибута, а зі зв’язки між фідом, сторінкою товару, доставкою, валютою, наявністю й довірою до сайту: https://support.google.com/merchants/answer/2948694?hl=en

price mismatch — простий приклад. Ззовні це різниця між ціною у feed.xml і ціною на сайті. На практиці причина часто лежить поруч:

• ціна на сторінці оновилась, а фід ще віддає старе значення;
• акційна ціна показується на сайті, але не передається в sale_price;
• сайт показує гривню, а фід або Merchant Center обробляє іншу валюту;
• ціна змінюється після вибору розміру, кольору або комплектації;
• кеш сторінки віддає Google стару версію картки товару.

Так само з missing GTIN. Не кожен товар має валідний GTIN. Якщо магазин продає кастомні, локальні або власні товари, механічно додати будь-який код гірше, ніж коректно налаштувати brand, MPN або identifier_exists=false там, де це доречно. У Product data specification Google описує вимоги до ідентифікаторів товарів: важлива не наявність будь-якого значення, а відповідність типу товару: https://support.google.com/merchants/answer/7052112?hl=en

Найскладніший сценарій — suspended account. Його майже ніколи не варто лікувати фідом. Якщо акаунт обмежений через недовіру до магазину або непрозорі умови покупки, атрибут title нічого не врятує. Тут треба дивитися на сайт: контакти, юридичну інформацію, сторінки доставки й повернення, способи оплати, HTTPS, умови покупки біля кнопки замовлення.

У нашій практиці в UPLIFY на 200+ підключеннях Merchant Center бачимо повторювану картину: 73% disapproval закриваються не у фіді, а в товарних картках і політиках сайту. Тому ми не починаємо з найдорожчих правок. Але й не робимо вигляд, що один атрибут вирішить системну проблему.

Починати треба з дешевих перевірок: атрибути фіда, мапінг категорій, дублікати id, доступність сторінок. Але виправлення краще планувати як систему. Merchant Center оцінює не таблицю з товарами окремо від сайту, а весь ланцюг покупки. Якщо він розірваний, косметична правка в одному полі дасть короткий ефект або не пройде повторну перевірку.

Як правильно діагностувати помилки Merchant Center перед правками

Погана діагностика в Merchant Center зазвичай виглядає так: маркетолог бачить червону помилку, відкриває фід, змінює один атрибут, чекає день і знову отримує той самий disapproval. Потім змінює ще щось. Через тиждень уже ніхто не розуміє, яка правка вплинула на статус товарів.

Починати треба не з правок, а з класифікації проблеми. У Merchant Center різні рівні помилок мають різну логіку виправлення: item-level disapproval стосується конкретних товарів, feed-level issues часто пов’язані з обробкою feed.xml, а account suspension зачіпає весь акаунт і майже завжди виходить за межі одного атрибута. Google розділяє проблеми за рівнями в Merchant Center, тому складати їх в одну чергу задач не варто ^[1].

Ці 5–10 SKU часто дають більше, ніж масове переписування каталогу на 3 000 товарів. Якщо у всіх проблемних товарах одна категорія, один бренд або один шаблон картки, причина найімовірніше системна. Наприклад, у Tilda може повторюватися слабка структура товарної сторінки, у WordPress — помилка плагіна фіда, у Horoshop — некоректна логіка для GTIN або identifier_exists=false. Це ще не відповідь, але нормальний напрямок для перевірки.

Окремо треба ловити розбіжності між джерелами даних. Merchant Center може бачити одну ціну у фіді, іншу на сторінці товару, а третю після знижки або валютної конвертації. Для таких випадків Google має окрему логіку проблем зіставлення: треба звіряти дані між фідом і цільовою сторінкою, а не шукати помилку тільки в одному полі ^[1].

У UPLIFY ми діагностуємо Merchant Center знизу вгору: конкретний SKU, шаблон картки, категорія, фід, політики сайту, акаунт. Це повільніше на старті, зате дешевше за хаотичні правки. Найгірший сценарій — переробити весь feed.xml, коли проблема була в тому, що сторінка товару не показувала умови повернення або мала нестабільну ціну після завантаження. Цього тижня достатньо взяти 5–10 проблемних SKU, звірити їх у трьох місцях і тільки після цього відкривати план правок.

Які помилки у фіді найчастіше блокують українські магазини

Фід варто перевіряти першим не тому, що він завжди винен у проблемах Merchant Center. Це найдешевший шар діагностики. Помилки в id, price, availability, link, image_link, GTIN або MPN часто можна знайти за 30-60 хвилин і без розробника. Google описує, що проблеми в Merchant Center можуть стосуватися окремих товарів або всього акаунта, тому статуси й причини треба дивитися в діагностиці, а не вгадувати по рекламній кампанії: Google Merchant Center Help.

• Найчастіше українські магазини блокуються на базових речах:
• нестабільний id: сьогодні товар має один ідентифікатор, після оновлення CMS або імпорту — інший;
• дублікати SKU, коли два різні товари отримують однаковий id;
• повторне використання старого id для нового товару;
• різниця між title у фіді та назвою на картці товару;
• ціна у фіді не збігається з ціною на сайті;
• availability показує in_stock, хоча товару немає в наявності;
• link веде на редирект, 404, мовну версію без товару або сторінку з іншим варіантом;
• image_link веде на закрите, занадто маленьке або замінене зображення.

Окрема зона ризику — товарні ідентифікатори. Для брендових товарів Google очікує коректні brand, GTIN і, коли потрібно, MPN. Для кастомних, handmade або товарів без глобального коду часто ставлять identifier_exists=false, але цим атрибутом легко зловжити. У нашій практиці були магазини на Horoshop, де identifier_exists=false стояв майже на всіх SKU, включно з брендовими товарами. У результаті діагностика сипалася не через один «поганий фід», а через неправильну логіку ідентифікації.

Ще один блок — категоризація та варіанти. google_product_category не завжди обов’язковий, але в частині ніш він допомагає Merchant Center правильно зрозуміти товар. Варіанти розміру, кольору, матеріалу або комплектності треба передавати стабільно. Якщо синій килимок, чорний килимок і комплект із 4 штук мають хаотичні назви, різні URL і спільний SKU, Merchant Center не буде сам відновлювати структуру каталогу.

Автоматичний фід у Horoshop, Shopify, Tilda або WordPress не дорівнює коректному фіду. Він лише показує, що система щось вивантажує. Після зміни шаблону товару, мовної версії, валюти, модуля доставки або SEO-плагіна фід може залишатися технічно доступним, але комерційно неправильним.

Тому ми починаємо з фіда, але не зупиняємося на ньому. Якщо після чистки атрибутів disapproval лишається, причина часто вже не в XML, а в картці товару, політиках магазину або сигналах довіри на сайті. На цьому етапі варто не «докручувати фід» ще тиждень, а перейти до перевірки сторінок товарів, умов доставки, повернення, контактів і збігу даних між сайтом та Merchant Center.

Чому товарні картки часто важливіші за сам фід

Фід може бути технічно валідним, але Merchant Center усе одно відхилить товар, якщо сторінка товару суперечить даним у feed.xml. Google звіряє атрибути фіда з тим, що покупець бачить на сторінці: ціну, валюту, наявність, варіанти, умови покупки, доставку й можливість оформити замовлення. Сам XML не рятує, якщо на сайті інша реальність.

Тому ми не віримо в підхід «підправимо price у фіді — і все поїде». Іноді це спрацьовує. Частіше проблема нижче: у шаблоні картки, модулі знижок, перемикачах розміру, прихованій передоплаті або доставці, яка з’являється тільки на етапі checkout.

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

• Найчастіше Merchant Center ламається не через «поганий XML», а через такі розсинхрони:
• ціна у фіді — 1 499 грн, а на сторінці товару — 1 699 грн до застосування промокоду;
• в availability стоїть in_stock, але на сайті кнопка «Повідомити про наявність»;
• у фіді один товар, а сторінка відкриває групу варіантів без вибраного кольору або розміру;
• доставка вказана в Merchant Center, але на сайті вона прихована до останнього кроку;
• мінімальне замовлення або передоплата є в тексті умов, але не відображені біля ціни й кнопки покупки;
• знижка діє на сайті, але не синхронізована з фідом, тому Merchant Center бачить іншу ціну.

Для Horoshop, Shopify, Tilda й WordPress це особливо видно на масових каталогах. Один модуль акцій може змінити видиму ціну на всіх товарах, але не передати її у feed.xml. Один плагін варіативних товарів може показувати «від 299 грн», тоді як у фіді йде конкретний варіант за 349 грн. Один шаблон кнопки покупки може ховати реальну доступність, хоча Merchant Center очікує чітку відповідність між сторінкою й даними товару.

Картка товару — це не місце для SEO-тексту на 2 000 символів, який ніхто не читає. Для Merchant Center важливіша операційна ясність: конкретна назва, актуальна ціна, зрозуміла наявність, фото саме цього товару, видимі умови купівлі, коректні варіанти. SEO-опис може допомогти органіці, але він не компенсує розрив між фідом і сторінкою.

У UPLIFY ми спершу шукаємо такі розриви на рівні шаблону. Це дешевше за ручне редагування SKU і точніше показує причину disapproval. Якщо виправити базову картку, Merchant Center часто «зеленіє» пакетно. Якщо крутити тільки атрибути у фіді, магазин може місяць бігати по колу: сьогодні закрили price mismatch, завтра отримали проблему з наявністю, післязавтра — з умовами покупки.

Цього тижня варто взяти кілька відхилених товарів із різних категорій і перевірити не тільки фід, а й сторінку товару очима покупця. Якщо проблема повторюється в шаблоні, фіксити треба шаблон. Інакше Merchant Center просто знайде той самий розрив на наступній групі товарів.

Як доставка, оплата, повернення і контакти впливають на модерацію

Google Merchant Center оцінює магазин не як таблицю з товарами, а як бізнес, який приймає оплату від покупця. Тому чистий feed.xml, коректні GTIN, ціни й наявність не врятують, якщо сайт виглядає непрозоро: немає зрозумілої доставки, повернення описане розмито, контакти схожі на заглушку, а умови оплати видно тільки на останньому кроці checkout.

Для нових або відновлених українських магазинів це особливо неприємний сценарій. Власник заходить у Diagnostics, бачить кілька товарних помилок і починає переписувати атрибути. А причина може бути на рівні акаунта: Google не довіряє сайту як продавцю. У довідці Merchant Center проблеми стосуються товарів, облікового запису й політик, які можуть блокувати показ усіх товарів у Shopping і Performance Max: https://support.google.com/merchants/answer/12153802?hl=uk

• Мінімальний набір сторінок має бути робочим, а не декоративним:
• доставка: терміни, служби, географія, вартість або правила її розрахунку;
• оплата: доступні способи, передоплата, післяплата, оплата карткою, комісії;
• повернення: строк, умови, винятки, хто платить за доставку назад;
• гарантія: що покривається, куди звертатися, які документи потрібні;
• контакти: телефон, email, месенджери, графік роботи, юридична або бізнес-інформація;
• конфіденційність: як магазин обробляє персональні дані покупця.

Окрема зона ризику — контакти. Магазин без адреси, графіка, зрозумілого email і живих каналів підтримки виглядає як тимчасова вітрина. Для покупця це питання довіри. Для Merchant Center — відповідності. Google прямо описує, що проблеми в Merchant Center треба виправляти за рекомендаціями в акаунті, бо частина з них блокує показ товарів або потребує перевірки після змін: https://support.google.com/merchants/answer/2948694?hl=en

У практиці UPLIFY на 200+ підключеннях Merchant Center ми часто бачимо одну й ту саму картину: фід уже довели до прийнятного стану, але акаунт не виходить у стабільний зелений статус. У 73% disapproval, які ми закривали, вирішальна правка була не в одному атрибуті, а в товарних картках і політиках сайту. Тому ми йдемо знизу вгору: спочатку перевіряємо, чи сайт виглядає як продавець, якому можна платити, і тільки потім поліруємо фід.

Для українських магазинів це часто дешевший фікс, ніж перезбирати весь каталог. Якщо сайт не пояснює покупцю, як він платить, отримує товар і повертає його назад, Merchant Center не має причин довіряти навіть ідеальному feed.xml. Цього тижня достатньо пройти політики, checkout і 10–15 карток товарів одним маршрутом покупця. Саме там зазвичай видно розриви, які не показує фід.

Як вибудувати порядок виправлень від фіда до довіри до магазину

Хаотичні правки в Merchant Center майже завжди обходяться дорожче, ніж нормальна діагностика. Магазин виправляє GTIN, чекає повторної перевірки, отримує новий disapproval через ціну, потім лізе в шаблон картки. Наприкінці виявляється, що Google не бачить сторінку повернення або контакти. Так минають не дні, а тижні.

У UPLIFY ми йдемо знизу вгору: спочатку перевіряємо те, що можна виправити швидко й дешево, потім переходимо до CMS, шаблонів і бізнес-процесів. Це не красива методологія для презентації. Це спосіб не витрачати бюджет на дорогі зміни, поки в магазині залишаються базові помилки в даних, картках і політиках.

• Почніть із фіда й товарних атрибутів:
• id, title, description, price, availability, link, image_link;
• збіг ціни та наявності між фідом і сторінкою товару;
• коректність GTIN, MPN, brand, identifier_exists=false;
• відкриття посилань без редиректів, 404 і блокування для Google.
• Потім переходьте до товарних карток:
• чи є однакова логіка для всіх категорій;
• чи не губляться варіанти розміру, кольору, комплектації;
• чи не дублюються товари з різними id;
• чи видно ціну, наявність, доставку й умови покупки без зайвих кліків.
• Після цього перевірте магазин як бізнес-сторінку:
• доставка;
• оплата;
• повернення;
• контакти;
• політика конфіденційності;
• реальні реквізити або зрозумілий спосіб зв’язку.

Google розділяє проблеми Merchant Center за рівнями: товарні дані, акаунт, сайт. Тому виправлення тільки feed.xml не гарантує зелений статус у Merchant Center. Специфікація товарних даних також задає вимоги до ключових атрибутів, які мають збігатися з інформацією на посадковій сторінці.

Найдорожчі зміни залишайте на кінець. TLS, перебудова меню, нові блоки довіри, переробка сторінок політик або редизайн checkout інколи потрібні. Але якщо в 300 товарах не збігається availability, а у 120 SKU повторюється id, редизайн не закриє проблему.

Мета цієї послідовності не в одному прибраному червоному рядку в діагностиці. Треба зробити магазин зрозумілим для Google: дані у фіді збігаються з картками, картки пояснюють товар, політики підтверджують умови покупки, а сайт має ознаки відповідального продавця. Тоді Merchant Center перестає бути разовою проблемою запуску й стає робочою інфраструктурою для Google Ads. Почніть цього тижня з фіда, карток і політик, а дорогі зміни відкладайте до моменту, коли базові помилки вже закриті.

Погляд UPLIFY

Ми бачимо це на 200+ підключеннях Merchant Center в UPLIFY: 73% disapproval закриваються не правками у фіді, а виправленнями в товарних картках і політиках сайту. Тому ми не починаємо з повної перегенерації feed.xml, якщо магазин не пройшов базову перевірку сторінок: ціна збігається, наявність видима, доставка й повернення описані, контакти не сховані, HTTPS працює на ключових URL.

Більшість гайдів радить іти зверху вниз, від фіда до сайту. Для українських магазинів це часто затягує роботу: команда тижнями чистить атрибути, а Merchant Center усе одно не довіряє картці товару або політикам. Ми йдемо навпаки. Спочатку прибираємо дешеві помилки в атрибутах, потім швидко переходимо до карток, політик і довіри. Цього тижня варто відкрити 10 проблемних SKU й перевірити їх як покупець: чи збігаються ціна, наявність, доставка, повернення, контакти й захищене з’єднання.

Чек-лист дій

• Перевірте id у фіді.
• Google не має бачити дублікати, повторне використання старих id або випадкову зміну ідентифікаторів між оновленнями.
• Звірте price і availability між фідом і сторінкою товару.
• Розбіжність у ціні чи наявності швидко дає price mismatch або product data mismatch.
• Перевірте обов’язкові атрибути: title, description, link, image_link, brand.
• Без базових полів Google не може коректно зіставити товар із запитом і політиками.
• Виправте GTIN, MPN і identifier_exists=false.
• Масове identifier_exists=false для брендованих товарів часто створює більше проблем, ніж відсутній код.
• Протестуйте 5-10 SKU перед масовою перегенерацією фіда.
• Малий тест показує, чи причина в атрибутах, чи Merchant Center далі блокує сайт.
• Перевірте картку товару вручну з мобільного.
• Модерація оцінює не тільки фід, а й сторінку, яку бачить покупець після кліку.
• Синхронізуйте ціну, акції, варіанти й валюту.
• Якщо в фіді одна ціна, а на сайті інша після вибору кольору чи розміру, ризик відхилення зростає.
• Винесіть умови доставки й оплати в окремі видимі сторінки.
• Google має швидко знайти правила покупки, а не збирати їх із футера, банера й FAQ.
• Додайте сторінку повернення та обміну.
• Відсутність зрозумілої політики повернення б’є по довірі до магазину сильніше, ніж здається.
• Перевірте контакти, юридичну інформацію і збіг даних.
• Телефон, email, адреса, назва продавця й дані в Merchant Center не мають конфліктувати.
• Пройдіть сайт на HTTPS і технічні редиректи.
• Помилки TLS, змішаного контенту або редиректів можуть зламати модерацію навіть при чистому фіді.
• Надішліть товари на повторну перевірку тільки після повного циклу правок.
• Передчасний review часто повертає той самий статус і затягує відновлення акаунта.

FAQ

Джерела

• [1]Проблеми в Merchant Center — Google Merchant Center Help, tier 1
• [2]Issues in Merchant Center — Google Merchant Center Help, tier 1
• [3]Як вирішити проблему «Помилка зіставлення» — Google Merchant Center Help, tier 1
• [4]Як вирішити проблему «Ідентифікатор товару вже використовується» — Google Merchant Center Help, tier 1
• [5]Product data specification — Google Merchant Center Help, tier 1
• [6]Fix Google Merchant Center Errors | Troubleshooting Guide — Northrule SEO, tier 2
• [7]How-to: 39 Google Merchant Center Errors You Need to Fix — Store Growers, tier 2
• [8]The Most Common Feed Errors in Google Merchant Center (and How to Fix Them) — Adnan Agic, tier 2
• [9]Common Google Merchant Center Errors in 2026 Explained — Trusted Web E-Services, tier 2

Потрібна допомога?

Якщо Merchant Center блокує Shopping або Performance Max, UPLIFY може пройти діагностику фіда, карток, політик і Google Ads без хаотичних правок. Дивіться напрями google_merchant_center, google_ads та internet_shop.

Читайте далі

• Налаштування Google Merchant Center для інтернет-магазину
• Запуск Performance Max з нуля
• Як підготувати інтернет-магазин до Google Shopping
• Аудит фіда товарів для реклами
• Відновлення заблокованого Merchant Center