Зміст статті 7
Призупинення акаунта Merchant Center за Misrepresentation зазвичай вимагає перевірки всього шляху покупця та ідентичності бізнесу, а не лише переписування описів товарів. У політиці Google прямо сказано, що під час оцінки можуть переглядатися промо-матеріали, вебсайт, акаунти та сторонні джерела (Misrepresentation). Тому аудит варто будувати ширше: хто ви як компанія, чи збігаються контактні дані, чи розкрито повну вартість і умови оплати, чи легко знайти правила доставки, повернення й відшкодування. Дані про товар лишаються частиною картини, бо назва та опис мають точно описувати товар і відповідати посадковій сторінці (специфікація даних), проте самі по собі не охоплюють усі перевірки рівня акаунта.
Що Google описує під назвою Misrepresentation
Політика формулює очікування досить широко: пропозиції мають бути точними, реалістичними, правдивими, а суттєва інформація має розкриватися до того, як користувач бере на себе зобов'язання (Misrepresentation). Це не вимога до окремого поля у фіді, а вимога до цілісності того, що покупець бачить і на що погоджується.
Серед прикладів, які Google наводить як заборонені, є хибна ідентичність бізнесу або неправдиві контактні дані, введення в оману щодо афіліації, недоступні пропозиції, приховування повної вартості чи умов оплати, а також нечіткі або складні для пошуку умови доставки, повернення й відшкодування (Misrepresentation). Кожен із цих пунктів має цілком конкретне відображення на сайті, і саме там аудит дає найбільше матеріалу.
Рекомендаційна частина політики так само предметна. Google радить тримати контактну інформацію актуальною, чітко описувати бізнес, використовувати власний брендинг, прозоро позначати партнерський статус, віддавати покупцям те, за що вони заплатили, і подавати ретельну та точну апеляцію (Misrepresentation). Формулювання «власний брендинг» і «партнерський статус» особливо важливі для дропшипінгу та реселерських моделей, де магазин фактично працює з чужим асортиментом.
Як взаємодіють сайт, фід, акаунт і бізнес-сигнали
Довідка Google розділяє проблеми на рівень товару та рівень акаунта. Проблеми рівня товару можуть виникати через розбіжність між надісланими даними та вмістом сайту, порушення специфікації або політик, тоді як проблеми рівня акаунта впливають на всі товари (проблеми в Merchant Center). Для власника магазину це означає просту річ: якщо статус стосується акаунта, перебирання окремих SKU навряд чи змінить картину, доки не перевірено загальні сигнали.
До проблем із вебсайтом Google відносить, зокрема, текст-заповнювач, биті посилання, відсутню або неузгоджену інформацію, неточні описи, заблоковане сканування, недоступні сторінки та загальні редиректи (проблеми в Merchant Center). Частина цього переліку виглядає технічною, але сприймається як питання довіри: сторінка, що редиректить на головну замість картки товару, і сторінка з демонстраційним текстом з коробки CMS однаково руйнують відповідність між обіцянкою у фіді та реальністю.
Специфікація додає ще один шар. Дані мають бути точними та коректно відформатованими, назва й опис мають описувати товар і збігатися з посадковою сторінкою, а посилання має вести на підтверджений домен без проміжної сторінки, якщо вона не вимагається законом (специфікація даних). Спливні вікна вибору мови чи регіону, вікна згоди, які перекривають картку, або перехід через трекінговий домен варто перевірити саме в цьому контексті.
Рівень акаунта проти рівня товару
Практичний висновок такий: спершу визначте, на якому рівні зафіксовано проблему, і лише потім обирайте обсяг робіт. Google описує, що проблеми рівня акаунта видно через розділи Products, Needs attention та перегляд налаштувань і політик (запит на перевірку), а розділ Needs attention загалом слугує місцем, де проблеми стають видимими (проблеми в Merchant Center).
| Сигнал | Де дивитися | На що звертати увагу |
|---|---|---|
| Ідентичність бізнесу | Сайт, сторінки «Про нас» і контактів | Назва юрособи, адреса, робочі канали зв'язку, відповідність даним акаунта (політика) |
| Умови угоди | Картка товару, кошик, чекаут | Повна вартість, умови оплати, доставка, повернення, відшкодування до моменту зобов'язання (політика) |
| Відповідність фіда сайту | Фід і посадкові сторінки | Збіг назви та опису з товаром на сторінці, підтверджений домен у link (специфікація) |
| Доступність сторінок | Логи, вибіркова перевірка URL | Биті посилання, недоступні сторінки, загальні редиректи, заблоковане сканування (проблеми) |
| Готовність акаунта | Налаштування Merchant Center | Доставка там, де потрібна, фід для цільової країни, підтверджений і заявлений URL, підтверджена адреса (проблеми) |
Що перевірити до запиту на перевірку
Google перелічує передумови для перевірки: налаштована доставка там, де вона застосовна, фід для цільової країни, заявлений і підтверджений URL, підтверджена адреса бізнесу (проблеми в Merchant Center). Окремо зазначено, що фід не повинен бути порожнім, а в деяких випадках може знадобитися підтвердження особи (запит на перевірку).
Ці пункти варто закрити до того, як ви натиснете кнопку запиту, а не паралельно з нею. Логіка проста: якщо базові умови не виконані, аудит змісту сайту не встигає стати релевантним.
Перед основним проходом відкрийте магазин як новий покупець у браузері без авторизації. Перевірте мобільну й десктопну версії, змініть регіон доставки та додайте товар у кошик. Це редакційний метод перевірки, а не окрема вимога Google. Він допомагає побачити розбіжності, які власник магазину пропускає у звичній сесії: автоматичну валюту, прихований обов'язковий платіж, недоступний спосіб доставки або політику, що з'являється лише після входу. Записуйте не враження, а URL, крок і фактичний текст на екрані. Так простіше відтворити проблему після виправлення.
Покроковий аудит
Послідовність нижче є методом аудиту, а не офіційною процедурою Google. Вона впорядковує ті перевірки, які випливають із наведених довідкових сторінок.
- Зафіксуйте вихідний стан. Випишіть, які саме проблеми показує акаунт і на якому вони рівні, використовуючи Products, Needs attention та перегляд налаштувань і політик (запит на перевірку). Скріншоти й дати згодяться пізніше для опису виправлень.
- Перевірте дані бізнесу у Merchant Center і публічні контакти окремо. Підтверджена адреса бізнесу є передумовою перевірки в акаунті (проблеми в Merchant Center), але це не означає, що фізичну чи юридичну адресу завжди потрібно публікувати на сайті. На сайті перевірте точність назви й тих способів зв'язку, які магазин фактично заявляє: політика прямо згадує хибну ідентичність і неправдиві контактні дані серед заборонених прикладів (Misrepresentation).
- Опишіть, чим займається бізнес. Google радить чіткий опис бізнесу та власний брендинг (Misrepresentation). Якщо сайт зібрано на шаблоні з чужими логотипами або залишками демо-контенту, це варто усунути. Унікальність описів, отриманих від постачальника, перевіряйте окремо як редакційну та SEO-рекомендацію, а не подавайте саме дублювання тексту як порушення Misrepresentation.
- Розкрийте партнерський статус. Якщо ви продаєте чужий асортимент, працюєте як реселер або маєте афілійовані зв'язки, політика очікує ясності щодо цього (Misrepresentation).
- Пройдіть шлях покупця до кінця. Від картки товару до підтвердження замовлення подивіться, коли покупець уперше бачить повну вартість і умови оплати. Приховані комісії або пізнє розкриття витрат входять до переліку прикладів у політиці (Misrepresentation).
- Перевірте видимість умов доставки, повернення та відшкодування. Політика згадує нечіткі або важкодоступні умови окремим прикладом (Misrepresentation). Метод аудиту тут такий: спробуйте знайти ці сторінки з картки товару за мінімальну кількість кліків і без пошуку по сайту.
- Звірте фід із сайтом на вибірці. Візьміть репрезентативний набір товарів і зіставте назву, опис і посилання з тим, що бачить користувач. Назва та опис мають відповідати товару та посадковій сторінці, а link має вести на підтверджений домен без проміжної сторінки, крім законодавчо необхідних випадків (специфікація).
- Перевірте наявність і доступність пропозицій. Недоступні пропозиції названі серед заборонених прикладів (Misrepresentation), а недоступні сторінки та загальні редиректи згадані серед проблем із сайтом (проблеми в Merchant Center).
- Приберіть технічні бар'єри. Заблоковане сканування та биті посилання входять до того самого переліку (проблеми в Merchant Center), тож перевірте
robots.txt, доступність карток для сканера та коректність кодів відповіді. - Окремо опрацюйте якість даних. Для відхилень, пов'язаних саме з якістю даних про товари, Google веде окрему довідку з усунення таких проблем (усунення відхилень за якістю даних).
- Закрийте передумови перевірки. Доставка, фід для цільової країни, заявлений і підтверджений URL, підтверджена адреса (проблеми в Merchant Center), непорожній фід і готовність до підтвердження особи, якщо його запитають (запит на перевірку).
Масштабна діагностика через API
Якщо асортимент великий, ручна вибірка може пропускати системні розбіжності. Merchant API дає змогу отримувати дані про товари разом із переліком проблем і фільтрувати відхилені товари програмно (Merchant API). Це опційний спосіб пришвидшити діагностику, а не обов'язкова умова відновлення акаунта. Практична цінність у тому, що ви бачите розподіл проблем за категоріями, брендами чи типами сторінок і можете виправляти причину, а не окремі картки.
Що робити після виправлень
Google описує, що опція перевірки може з'являтися в деталях товару або в проблемах акаунта, і продавець може обрати варіант «I fixed the issue» або «I disagree with the issue» (запит на перевірку). Вибір між ними варто робити свідомо. Перший означає, що зміни вже впроваджені й видимі публічно. Другий доречний, коли ви вважаєте оцінку помилковою, і в такому разі Google може попросити причину апеляції або документи (запит на перевірку).
Політика рекомендує подавати ретельну й точну апеляцію (Misrepresentation). Метод, який полегшує це завдання: підготуйте короткий перелік того, що саме змінилося, з посиланнями на конкретні сторінки, і переконайтеся, що всі зміни вже опубліковані, а не заплановані. Опис на кшталт «ми оновили сайт» дає перевіряльнику менше матеріалу, ніж перелік розділів із конкретними URL.
Після подання запиту не варто починати нові структурні зміни сайту, бо стан, який ви описали, і стан, який буде переглянуто, можуть розійтися. Якщо потрібні подальші правки, фіксуйте їх окремо. Результат перевірки може бути різним, і формулювання на кшталт «виправлення такого-то пункту поверне акаунт» не має підтвердження в довідці: Google описує критерії оцінки, а конкретний висновок залежить від стану всього акаунта.
Окремо тримайте в полі зору те, що акаунт може мати кілька проблем одночасно. Проблеми рівня акаунта впливають на всі товари, тоді як частина розбіжностей стосується лише окремих позицій (проблеми в Merchant Center). Закриття однієї категорії не знімає іншу автоматично.
Чеклист перед запитом на перевірку
- Адресу бізнесу підтверджено в Merchant Center там, де цього вимагає перевірка акаунта (проблеми); назва й публічні способи зв'язку, які магазин заявляє на сайті, точні та робочі (політика).
- На сайті є зрозумілий опис бізнесу, використано власний брендинг, партнерський або реселерський статус розкрито (політика).
- Повна вартість, комісії та умови оплати видно до моменту, коли покупець бере на себе зобов'язання (політика).
- Умови доставки, повернення та відшкодування сформульовані чітко й доступні з картки товару (політика).
- Назви та описи у фіді відповідають товарам і посадковим сторінкам, посилання ведуть на підтверджений домен без зайвих проміжних сторінок (специфікація).
- Немає тексту-заповнювача, битих посилань, недоступних сторінок, загальних редиректів і заблокованого сканування (проблеми).
- Відхилення за якістю даних опрацьовані за профільною довідкою (усунення відхилень).
- Доставка налаштована там, де застосовна, фід відповідає цільовій країні, URL заявлено й підтверджено, адресу бізнесу підтверджено (проблеми).
- Фід не порожній, готовність до підтвердження особи забезпечена (запит на перевірку).
- Опис виправлень підготовлено з конкретними сторінками, усі зміни опубліковані до подання запиту (запит на перевірку).