Зміст статті 11
Помилки 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, податки й умови, за яких покупець реально отримує заявлену ціну.
Якщо проблема стосується акаунта або політики, звірте додаткові кроки у гайді про Misrepresentation. Це не загальний гайд із початкового налаштування фіду.
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. Інформація має точно описувати пропозицію, без тимчасових заглушок, промоматеріалів у зображенні там, де це заборонено, або категорії, що суперечить товару.
Для старих інтеграцій перевірте перехід на Merchant API. Content API досяг sunset 18 серпня 2026; Google описує поступові збої без наданого Google продовження строку (extension), а не одночасне вимкнення всіх запитів. Звірте поточний графік і відповідальність постачальника інтеграції.
Google: Content API lifecycle ↗
Google оголосив мінімум 500×500 для всіх товарних фото з 31 січня 2027 та рекомендує 1500×1500. Перевіряйте актуальну специфікацію image_link. Для застосовних AI-зображень зберігайте метадані джерела й точний вигляд товару.
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. Орієнтуйтеся на підказки у власному акаунті.
Подавати 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.
Питання перед виправленням
Чи треба міняти id товару після disapproval?
Зазвичай ні. ID має стабільно представляти ту саму пропозицію. Зміна не виправить ціну, наявність, політику або сторінку. Спочатку усуньте причину; змінюйте схему ідентифікації лише з перевіркою наслідків для історії та інтеграцій.
Ціна у фіді правильна, але Google бачить іншу. Що перевірити?
Звірте default variant, sale_price, валюту, розмітку, кеш, mobile rendering і checkout. URL та дані повинні описувати конкретну пропозицію. Перевірте час обробки джерела й увесь зачеплений кластер, а не лише одну картку.
Постачальник не дав GTIN. Можна ставити identifier_exists=no?
Спершу перевірте, чи ідентифікатор справді не призначений виробником. Порожня таблиця постачальника цього не доводить. Не вигадуйте GTIN; передавайте достовірні brand/MPN за застосовними вимогами. Не використовуйте identifier_exists=no для обходу правил.
Проблема зникла у частини товарів. Вже запитувати review?
Перевірте весь affected cluster, усі джерела та варіанти. Кілька схвалених прикладів не доводять, що усунено системну причину. Для account-level issue окремо перевірте бізнес-дані, політики й checkout.
Реєстрація покупця завжди заборонена Merchant Center?
Ні. Документація допускає безкоштовне створення акаунта без додаткових бар’єрів і описує guest checkout або перевірку через одноразовий код. Не вимагайте платного доступу, завантаження застосунку чи зміни пристрою. Звірте доступність покупки й застосовні правила країни та програми.
Content API вже повністю вимкнений?
Sunset настав 18 серпня 2026, але це не тотожне одночасному вимкненню всіх запитів. Google описує поступові збої з 1 вересня без наданого Google продовження строку (extension). Повне виведення планується на початок 2027; графік може змінитися. Звірте актуальний статус і перехід інтеграції на Merchant API.
Джерела та межі висновків
Вимоги звірено з Google. Діагностичний порядок є методикою UPLIFY, не гарантією відновлення або поясненням кожного рішення reviewer.
- Google: Review workflow ↗
- Google: Misrepresentation ↗
- Google: Landing-page requirements ↗
- Google: Checkout requirements ↗
- Google: GTIN ↗
- Google: Image link ↗
- Google: Content API lifecycle ↗
- Google: Merchant API updates ↗
Що перевірити далі
- Гайд про Misrepresentation
- Склад аудиту готовності до Merchant Center
- Демонстраційний звіт на синтетичних даних
- Google Shopping і PMax після стабілізації даних
Розберемо помилки вашого магазину
Надішліть адресу магазину й назву issue без паролів або документів. Узгодимо перевірку, доступи та обсяг робіт; рішення Google не гарантуємо.