Зміст статті 10
Помилки Google Merchant Center варто діагностувати від рівня проблеми: окремий товар, шаблон картки, категорія, джерело даних, політики сайту або весь акаунт. Спочатку відкрийте конкретний issue у Needs attention і звірте feed, landing page, structured data та checkout. Для account-level suspension перевіряйте також бізнес-дані, доставку, повернення, контакти й можливість завершити покупку. Одна правка атрибута не є універсальним рішенням, а запит review до повного аудиту може лише ускладнити наступну спробу.
Product issue і account issue — різні задачі
Merchant Center розділяє проблеми на рівень товару та акаунта. Product-level disapproval стосується окремої пропозиції або групи пропозицій. Account-level warning чи suspension впливає на весь каталог і часто потребує перевірки не лише фіду, а й сайту та бізнес-налаштувань.
Починайте з тексту issue та прикладів affected products у Merchant Center. Не намагайтеся вгадати причину за загальною назвою. Однаковий ярлик може проявлятися через різні розбіжності, а Merchant Center показує контекст, доступний саме для вашого акаунта.
| Рівень | Що зачеплено | Де шукати причину | Перший контрольний крок |
|---|---|---|---|
| SKU | один товар або варіант | атрибути feed, сторінка, Offer/Product schema | порівняти id, price, availability, link та identifiers |
| шаблон | товари одного типу сторінки | тема, CMS, structured data, checkout | відкрити кілька affected і approved сторінок того самого шаблону |
| категорія | група схожих товарів | правила імпорту, category mapping, обов’язкові атрибути | знайти спільне поле або джерело даних |
| data source | значна частина каталогу | XML/CSV/API, розклад, правила трансформації | перевірити сирий запис до імпорту й результат у Merchant Center |
| policy/account | весь магазин | прозорість бізнесу, політики, домен, оплата, доставка | пройти шлях покупця та звірити бізнес-дані у всіх системах |
Діагностична драбина: від SKU до акаунта
1. Зафіксуйте issue до змін
Збережіть назву, country/program, affected item IDs, приклади й дату. Завантажте список товарів, якщо Merchant Center це дозволяє. Без baseline складно зрозуміти, чи виправлення прибрало причину, чи просто змінився набір прикладів.
2. Знайдіть найнижчий спільний рівень
Якщо проблема у одного SKU, перевіряйте його дані. Якщо вона повторюється на всіх варіантах певного шаблону, не виправляйте товари вручну один за одним — шукайте помилку теми або інтеграції. Коли affected items приходять з одного data source, перевірте правила експорту.
3. Порівняйте чотири представлення
Для товарного issue зіставте:
- запис у сирому feed або API;
- нормалізовані дані в Merchant Center;
- видиму landing page та Product/Offer structured data;
- checkout після вибору потрібного варіанта.
Price й availability мають збігатися не лише на першому екрані. Google вимагає узгодженості з landing page, structured data та checkout. Перевірте currency, sale price, мінімальну кількість, variant selection, податки й умови, за яких покупець реально отримує заявлену ціну.
Якщо data source ще не стабілізований, спочатку пройдіть налаштування Google Merchant Center від фіду до зв’язку з рекламним акаунтом.
4. Перевірте можливість купити товар
Відкрийте сторінку зі смартфона у приватному режимі. Оберіть варіант, додайте його в кошик, перейдіть до checkout і перевірте доставку та оплату. Якщо шлях не працює у вашому тесті, це важливий сигнал, але не доказ того, яку саме дію виконав або не виконав reviewer Google.
5. Виправте першоджерело
Ручна правка в Merchant Center може зникнути після наступного імпорту. Змініть CMS, ERP, feed rule або integration, яка створює невірне значення. Потім переконайтеся, що оновлений запис справді дійшов до Merchant Center.
Матриця «симптом → перевірка → виправлення»
| Симптом | Що перевірити | Коректний напрямок виправлення | Чого не робити |
|---|---|---|---|
| price mismatch | currency, sale_price, variant, мінімальну кількість, checkout | синхронізувати джерело ціни та видимі дані | змінювати лише feed, залишаючи іншу ціну на сайті |
| availability mismatch | status у feed, сторінці, schema, checkout | оновити складський статус і частоту передачі | показувати активну кнопку для недоступного товару |
| invalid/missing GTIN | упаковку, дані виробника, category requirements | передати призначений GTIN або коректно описати його відсутність | вигадувати номер чи копіювати GTIN іншого SKU |
| landing page unavailable | status code, redirects, robots, mobile rendering | повернути стабільну товарну сторінку для конкретної пропозиції | вести всі товари на категорію або головну |
| policy/misrepresentation | business identity, contacts, policies, offers, third-party consistency | зробити умови й дані точними, доступними та послідовними | маскувати бізнес або подавати непідтверджені зв’язки з брендами |
Product data: поля, які перевіряють першими
id. Ідентифікатор має стабільно представляти той самий товар або варіант у межах data source. Його безсистемна заміна ускладнює історію пропозиції.
price та availability. Це часті джерела pre-emptive item disapproval, коли дані не збігаються з сайтом. Перевіряйте також structured data й checkout.
GTIN, MPN, brand та identifier_exists. Передавайте лише призначені виробником identifiers. Якщо GTIN існує, його відсутність може обмежувати видимість; неправильний GTIN здатний спричинити disapproval. identifier_exists=no не є способом обійти вимоги для товару, який має identifiers.
link та mobile experience. URL повинен відкривати конкретний товар, не вимагати входу й давати можливість завершити покупку відповідно до заявлених умов.
title, description, image та category. Інформація має точно описувати пропозицію, без тимчасових заглушок, промоматеріалів у зображенні там, де це заборонено, або категорії, що суперечить товару.
Account suspension і Misrepresentation
Misrepresentation не варто перекладати як «Google не довіряє сайту» — це надто розмите й антропоморфне пояснення. Політика стосується inaccurate, unrealistic або misleading представлення бізнесу чи пропозицій, приховування важливої інформації та інших практик, які можуть вводити покупця в оману. Google зазначає, що може перевіряти promotion, website, accounts і third-party sources.
Перед review звірте:
- юридичну або торгову назву бізнесу, адресу, телефон та email;
- claimed/verified domain і коректність бізнес-профілю;
- сторінки доставки, оплати, повернення й refund;
- наявність зрозумілих контактів у доступному місці;
- фактичні строки, обмеження та вартість доставки;
- відповідність акцій, цін і наявності реальній можливості купити;
- відсутність неправдивих сертифікацій, партнерств або зв’язків із брендами.
Структурований перелік цих поверхонь є на сторінці аудиту готовності до Merchant Center, а формат результату можна подивитися у зразку такого аудиту.
Відсутність одного з цих елементів не дозволяє автоматично встановити причину suspension. Це перелік поверхонь, які офіційна документація рекомендує перевіряти комплексно.
Коли запитувати review
Google дозволяє для доступних issues обрати «I fixed the issue» або «I disagree with the issue» та подати request review. Перед цим можуть знадобитися identity verification та інші дії, вказані в Needs attention. Якщо фід порожній і через це review недоступний, офіційна інструкція радить вручну додати щонайменше один товар; орієнтуйтеся на підказки у власному акаунті.
Подавати review варто, коли:
- виправлення вже доступні на live-сайті й у data source;
- Merchant Center отримав оновлені дані;
- перевірено кілька affected items і шлях до checkout;
- account-level business data та policies узгоджені;
- команда може коротко пояснити, що було причиною і що саме змінилося.
Не обіцяйте фіксований строк відновлення. Тривалість і доступні кнопки залежать від issue, verification та історії review. Орієнтуйтеся на статус і повідомлення у власному акаунті.
Підхід UPLIFY
Як робочу методику UPLIFY рекомендує починати з issue registry та діагностичної драбини. Масове редагування фіду до локалізації причини лише змішує гіпотези. Для кожного кластера фіксують affected IDs, спільний шаблон або source, проведену перевірку та live-доказ виправлення. Цей процес не гарантує approval, проте зменшує ризик подати review із частково виправленою системною помилкою.
Що можна виправити самостійно
Самостійна робота доречна, коли issue чітко локалізований, команда контролює CMS/feed і може перевірити результат: помилка price, availability, GTIN, link, image або data-source mapping. Ведіть журнал змін і не змішуйте десятки гіпотез в один реліз. Після відновлення фіду перевірте, як ці дані використовують Google Shopping і Performance Max.
Залучення спеціаліста виправдане, якщо suspension охоплює акаунт, кілька інтеграцій суперечать одна одній, checkout залежить від складної логіки, попередні review не пройшли або команда не може визначити першоджерело. Експерт теж не має чесної підстави гарантувати результат перевірки Google.
FAQ
Чи треба міняти id товару після disapproval?
Зазвичай ні. id має стабільно представляти ту саму пропозицію, а новий identifier не виправляє price, availability, policy або landing-page issue. Спочатку усуньте причину у першоджерелі. Зміна id може бути виправдана лише коли стара схема ідентифікації була помилковою і команда розуміє наслідки для історії та інтеграцій.
Що робити, якщо ціна правильна у feed, але Google бачить іншу?
Перевірте видимий default variant, sale price, currency, structured data, кеш, mobile rendering і checkout. Якщо сторінка змінює ціну після вибору варіанта, URL та markup повинні однозначно описувати конкретну пропозицію. Також перевірте час останнього оновлення data source. Не запускайте review, доки розбіжність відтворюється хоча б на одному шарі.
Чи можна ставити identifier_exists=no, коли постачальник не передав GTIN?
Спочатку з’ясуйте, чи GTIN справді не призначений виробником. Відсутність номера у вашій таблиці ще не означає, що товар його не має. Передайте available brand і MPN відповідно до вимог категорії. identifier_exists=no використовуйте лише для товару, у якого необхідні unique product identifiers об’єктивно відсутні.
Після виправлення issue зник у частини товарів. Чи подавати review?
Перевірте весь affected cluster. Перші приклади зі зміненим статусом не представляють автоматично всю групу. Вивантажте актуальний список, знайдіть спільні шаблони й переконайтеся, що оновлення дійшло до всіх data sources та storefront variants. Для account-level issue часткове очищення товарів не доводить, що виправлено політики або бізнес-дані сайту.
Чи може сайт пройти Merchant review, якщо checkout працює лише після реєстрації?
Оцінюйте це за поточними landing-page і checkout requirements для вашої країни та програми. Критично, щоб покупець бачив повну ціну, availability й умови та міг придбати заявлену пропозицію без прихованих обмежень. Якщо реєстрація змінює ціну або доступність, дані можуть не відповідати feed. Перевірте процес у приватному режимі.