01 · Діагностика замість припущень
Відхилення в Merchant Center: спочатку знайдіть причину
Повідомлення стає робочим завданням, коли є підтвердження
Коли Merchant Center відхиляє товари, безсистемне переписування фіду рідко допомагає. Спочатку визначте, чого саме стосується проблема: окремих пропозицій, певної країни, способу розміщення чи облікового запису. Потім перевірте ймовірну причину на тому самому варіанті товару та задокументуйте виправлення, результат якого можна перевірити повторно.
Цей посібник призначений для малих і середніх інтернет-магазинів у Німеччині з наявним обліковим записом Merchant Center. Він починається з конкретного повідомлення й через перевірку товарних даних, сайту, правил і стану облікового запису веде до відповідної повторної перевірки. Початкове налаштування та поліпшення вже коректних назв товарів залишаються окремими завданнями. Тут мета — відновити допуск після дослідження помилки, яку можна підтвердити.
Робочий інструмент — дерево діагностики Merchant Center з реєстром помилок. Воно поєднує симптом, відповідні пропозиції, підтвердження, відповідальність, виправлення та завершальну перевірку. Завдяки цьому іншим учасникам зрозумілі причина зміни й питання, які ще не розв’язано.
Підготуйте актуальний експорт товарів, доступ до оброблених атрибутів і сторінок магазину, яких стосується проблема. Для технічних помилок може знадобитися допомога фахівця з експорту або вебсервера. Документи облікового запису залишаються в уповноваженого представника компанії: їх не потрібно додавати до загальнодоступних файлів із прикладами.
Актуальність: 22 вересня 2026 року. Приклади та внутрішні критерії приймання — редакційна методика, а не обіцянка Google. Відновлення допуску, фактичний показ реклами й комерційний результат — різні підсумки.
02 · Статус і масштаб
Розрізняйте попередження, відхилення товару та блокування облікового запису
Подібні кольори інтерфейсу не означають однакових дій
Спочатку відкрийте повідомлення повністю. В огляді проблем Merchant Center Google розрізняє проблеми окремих товарів і всього облікового запису. Попередження не підтверджує схвалення, але й не означає автоматично повного блокування. За серйозних порушень обліковий запис можуть заблокувати без попередження. Наступний крок визначають конкретний статус і зазначена сфера дії.
| Спостереження | Рівень | Можливий наслідок | Перше підтвердження | Напрям роботи | Яких висновків не робити |
|---|---|---|---|---|---|
| Попередження щодо пропозиції | Товар | Обмеження або подальше відхилення | Повідомлення та спосіб розміщення | Дослідити причину | Заблоковано весь обліковий запис |
| Пропозицію відхилено | Товар | Немає допуску в зазначеному контексті | ID, країна та проблема | Виправити дані або сайт | Зачеплено всі варіанти |
| Повідомлення про налаштування | Обліковий запис | Не виконано передумову | Банер облікового запису та подробиці | Уточнити передумову | Причина в назві товару |
| Обліковий запис заблоковано | Обліковий запис | Масштабне виключення з показів | Правило та висновок перевірки | Опрацювати проблему повністю | Новий фід розв’яже все |
| Триває перевірка | Товар або обліковий запис | Рішення ще немає | Статус і дата запиту | Стежити за етапом перевірки | Доведено нову помилку |
Обов’язково записуйте країну та спосіб розміщення. Одну пропозицію можуть по-різному оцінювати в різних країнах або програмах. Загальний лічильник товарів здатний приховати ці відмінності. Тому з’ясовуйте не лише кількість відповідних позицій, а й конкретні пропозиції та умови, яких стосується проблема.
Також окремо рахуйте причини й товари. Кілька повідомлень можуть стосуватися одного артикула: їхня сума не обов’язково дорівнює кількості різних відхилених товарів. І навпаки, одна помилка в спільному шаблоні може вплинути на багато позицій. Це розмежування допомагає не применшувати проблему й не перебільшувати її масштаб.
Одна відповідальна особа має збирати результати, навіть якщо зміни виконують інші фахівці. Тоді виправлення фіду, зміну сайту та запит перевірки можна розташувати в часі, а не вгадувати їхній вплив після завершення роботи.
03 · Збереження підтверджень
Зафіксуйте проблему до зміни даних
Початковий стан, час і вибірку має бути можливо відновити
У розділі Needs attention доступні відповідні товари, фільтри, відомості про проблеми та історія статусів. Сторінка подробиць проблеми об’єднує додаткові відомості й можливі дії. Перевірте активні фільтри пріоритету: перегляд лише найважливіших проблем не обов’язково показує всі повідомлення. Оцінка потенційних кліків допомагає визначити черговість, але не є виміряним прогнозом виторгу.
Збережіть точне формулювання, час спостереження, країну, спосіб розміщення та кілька конкретних ID пропозицій. За можливості експортуйте перелік відповідних товарів. Додайте час останнього передавання даних і останнього достовірно правильного стану. Так можна перевірити, чи збіглася поява помилки з новим імпортом, зміною теми оформлення або ціновою акцією.
Збіг у часі спочатку залишається гіпотезою. Якщо відхилення з’явилися після оновлення застосунку, саме оновлення ще не доведено як причину. Шукайте відтворювану невідповідність: що раніше було правильним, що передається тепер і на якому етапі виникає різниця? Записуйте й результати, які суперечать першій версії.
Для вибірки візьміть один товар із проблемою та якомога подібніший товар без неї. Порівняйте спільний шаблон, джерело даних і цільовий ринок. Різний статус не утворює ідеального експерименту, але допомагає звузити пошук. Повний перелік відповідних пропозицій зберігайте окремо, щоб згодом не сприйняти вибірку як увесь масштаб проблеми.
Повноцінний початковий запис містить повідомлення, контекст, ID пропозиції, час і спостережене значення. Персональні дані покупців зазвичай не потрібні. Видаліть їх зі знімків екрана та експортів перед передаванням зовнішнім учасникам.
04 · Дерево діагностики
Пройдіть шість точок ухвалення рішення
Для кожної гілки потрібні підтвердження та наступний крок
Наведене дерево — самостійна робоча методика. Воно впорядковує дослідження, але не замінює конкретного повідомлення Google. Проходьте його для кожного окремого типу проблеми. Якщо виявлено кілька причин, створюйте окремі підзавдання в межах одного випадку, а не приховуйте їх за загальним формулюванням «полагодити фід».
- 1 · Проблему визначено однозначно?
Ні: доповніть повідомлення, країну, спосіб розміщення та ID; поки не запитуйте перевірку. Так: зафіксуйте відповідний обсяг і переходьте далі.
- 2 · Є проблема облікового запису?
Так: перевірте передумови й правила на рівні облікового запису; самі виправлення окремих товарів не закривають питання. Ні: продовжуйте роботу з відповідними пропозиціями.
- 3 · Отримано правильний запис даних?
Ні: виправте передавання, зіставлення й обробку. Так: порівняйте оброблені значення з конкретною цільовою сторінкою.
- 4 · Пропозиція відповідає сайту?
Ні: предметно дослідіть ціну, наявність, варіант, зображення або доступ. Так: перевірте назване правило та його застосовність.
- 5 · Причину підтверджено й усунуто?
Ні: отримайте профільне роз’яснення або зверніться до підтримки з підтвердженнями. Так: перевірте наступний регулярний цикл даних і відповідні сторінки.
- 6 · Передбачено повторну перевірку?
Так: виконайте передумови та скористайтеся зазначеним способом звернення. Ні: стежте за автоматичним повторним оцінюванням. В обох випадках завдання залишається відкритим до задокументованої перевірки статусу.
Така послідовність позбавляє зайвої роботи. Необроблений запис неможливо виправити вдалим кадруванням зображення. Правильна ціна у фіді, своєю чергою, не пояснює порушення правил на рівні облікового запису. Дерево розділяє технічне виправлення та рішення щодо допуску, не пропускаючи жодного завдання.
Зупиніть зміни, доки правильне значення не встановлено. Невідомі дані виробника, невизначені обіцянки доставки та суперечливі відомості про компанію спочатку потребують змістовного рішення. Технічний доступ його не замінює.
05 · Перевірка обробки
Порівняйте вихідні дані з фактично обробленою пропозицією
Успішне завантаження не означає схвалення змісту
Спочатку з’ясуйте, чи з’явився відповідний товар в очікуваному записі. Чи збігаються ID пропозиції, мова, джерело й ринок? Чи оброблено останній файл? Чи актуальне перевірюване значення, чи воно належить до попереднього циклу? Ці питання потрібно з’ясувати до оцінювання назви або тлумачення правил.
У специфікації товарних даних Google описано вимоги до формату та змісту. Обов’язкові атрибути залежать, зокрема, від товару й цільової країни. Перевірте конкретну вимогу, що стоїть за повідомленням. Вигаданий GTIN або масове позначення наявних ідентифікаторів як відсутніх не створюють обґрунтованого виправлення.
Простежте спірне поле в трьох точках: підтверджене початкове значення, передана версія та результат обробки. Експорт може виглядати правильно, тоді як правило або ручна зміна утворює інше значення. Можлива й протилежна ситуація: інтерфейс магазину правильний, але засіб експорту далі читає застаріле поле.
Якщо немає самої коректної базової структури, використайте посібник із налаштування Google Merchant Center. Потім у межах поточної помилки документуйте лише шлях даних, якого вона справді стосується. Зазвичай пояснення конкретного зіставлення корисніше за повне переналаштування без підтвердженої причини.
Після виправлення повторно перевірте той самий товар і збережіть його сталий ідентифікатор. Зникнення помилки після видалення пропозиції не доводить усунення причини. Зафіксуйте, що товар існує, залишається на потрібному ринку й справді отримав змінені значення.
06 · Невідповідність ціни
Порівнюйте одну ціну для одного варіанта товару
Сума, валюта й час розглядаються разом
У разі повідомлення про ціну важливі щонайменше оброблене значення, цільова сторінка та оформлення замовлення. Вимоги до атрибута price передбачають узгоджені відомості про пропонований товар. Не порівнюйте ціну варіанта із загальною ціною «від», а акційну ціну — зі значенням поза строком дії акції. Вартість доставки розглядається окремо.
| Точка перевірки | Пропозиція | Час | Спостереження | Можливе пояснення | Наступне підтвердження |
|---|---|---|---|---|---|
| Оброблені дані | Варіант A | Поточний цикл | 49,00 EUR | Попередня звичайна ціна | Початкове значення та правило |
| Сторінка товару | Варіант A | Той самий період перевірки | 44,00 EUR | Діє акція | Період акції |
| Структуровані дані | Варіант A | Те саме звернення до сторінки | 49,00 EUR | Застарілий шаблон | Виведені дані пропозиції |
| Кошик | Варіант A | Після прямого входу | 44,00 EUR | Спрацьовує акція магазину | Оформлення того самого варіанта |
| Після виправлення | Варіант A | Новий цикл даних | Значення відповідають акції | Можливо, причину усунуто | Статус і наступний цикл |
Таблиця показує умовне дослідження, а не реальний клієнтський випадок. Спочатку вона доводить лише розбіжність. До зміни джерела відповідальна особа має підтвердити, яка ціна й коли повинна діяти. Інакше можна пристосувати правильну ціну магазину до хибного експорту та створити нову комерційну помилку.
Для акцій перевірте також початок, завершення, часовий пояс і прив’язку до конкретного варіанта. Відкрийте переданий URL у новій сесії. Якщо потрібна ціна з’являється лише зі збереженим купоном або після участі в програмі лояльності, окремо вивчіть відповідні правила ціноутворення. Не сприймайте цю ситуацію як звичайну загальнодоступну ціну.
Закривайте завдання лише після нового порівняння відповідних точок. Зміненого знімка екрана недостатньо, якщо машинозчитувані відомості або наступний імпорт знову передають старе значення. У реєстрі опишіть установлену причину, а не лише результат, який тепер видно на екрані.
07 · Наявність товару
Перевірте можливість замовити й доставити конкретний варіант
Залишок на складі ще не пояснює переданий статус
Наявність товарної лінійки не означає, що доступні всі розміри й кольори. Почніть із варіанта, зазначеного в повідомленні, та пройдіть шлях покупки. Чи можна його справді замовити й чи відповідає цьому обіцянка доставки? Активна кнопка покупки для іншого розміру не відповідає на це запитання. Навіть наявного залишку може бути недостатньо без відповідного способу доставки.
Google у специфікації availability розрізняє, зокрема, in_stock, out_of_stock, preorder і backorder. Попереднє замовлення та замовлення з очікуванням поповнення мають різні умови; в обох випадках потрібне відповідне значення availability_date. Не ставте out_of_stock лише тому, що тимчасово не хочете рекламувати товар, який досі можна замовити. Керування рекламою та фактична наявність — різні завдання.
Дослідіть послідовність оновлення. Коли облікова система змінює залишок, коли магазин приймає новий статус і коли інформація потрапляє до Merchant Center? Зафіксуйте ці моменти для одного артикула. Це допоможе розрізнити постійно неправильне зіставлення та повторювані затримки, які створюють суперечливі стани.
Звірте також видиму обіцянку доставки й машинозчитувані відомості на тій самій сторінці. Формулювання «незабаром у наявності» може бути надто невизначеним для підтвердження переданого статусу. Доручіть відповідальному за склад і доставку встановити правильний зміст. Не замінюйте це уточнення налаштуванням, яке спричиняє менше червоних повідомлень.
Після виправлення перевірте звичайну зміну залишку. Потрібний варіант має передаватися правильно й після неї. Інакше ручна зміна може протриматися лише до наступного продажу.
08 · Цільова сторінка та варіант
Перевірте переданий URL під час нового входу
Правильна пропозиція має відкриватися без попередніх дій
Скопіюйте URL з обробленого запису, а не переходьте до товару через навігацію магазину, у якому ви вже авторизовані. Перевірте переспрямування, мову, валюту й варіант. Робоча головна сторінка або категорія не підтверджує правильності конкретного товарного посилання. Збережені налаштування здатні приховати помилки, які бачать нові відвідувачі та системи автоматичного сканування.
Офіційні вимоги до цільових сторінок товарів передбачають конкретну відповідну пропозицію з основними відомостями. Інформація має залишатися узгодженою під час завантаження; попередній вибір потрібного варіанта — важлива рекомендація. Назва й опис не зобов’язані дослівно повторювати фід, але мають описувати той самий товар. Загальної заборони JavaScript із цього не випливає.
Зафіксуйте початковий стан і стан після завантаження. Якщо спочатку вибирається стандартний розмір, а потім скрипт перемикає його на рекламований, саме цей перехід може мати значення. Те, що співробітник знайшов потрібну пропозицію після кількох натискань, не підтверджує правильності початкового входу.
Перевірте вхід із телефона й комп’ютера. Звертайте увагу на перекриту ціну, діалоги, які неможливо закрити, та поля вибору, що працюють лише за однієї ширини екрана. Не «виправляйте» вікно згоди вимкненням необхідної логіки згоди: усуньте конкретну проблему керування або відображення.
Збережіть результат із URL, варіантом, мовою, валютою та часом. Якщо поведінка виникає лише за певних умов, зазначте їх. Точне формулювання на кшталт «прямий вхід із телефона без збереженого вибору» дає змогу предметно виправити помилку й відтворити приймальну перевірку.
09 · Доступність для сканування
Розділяйте доступ, відображення та індексування
Ваш успішний перехід не доводить успішного сканування Google
За повідомлення про недоступність окремо перевірте сторінку товару й файл зображення. У поясненні неможливості перевірити якість і дотримання правил Google, зокрема, розглядає блокування роботів. Правило robots може закривати потрібний шлях; технічний захист або проблеми сервера також здатні ускладнювати перевірку. Важливо встановити фактичну помилку за зазначеною адресою.
Доручіть перевірити повний ланцюжок переспрямувань, код відповіді та отриманий вміст. Сторінка може формально відповідати, але видавати лише повідомлення про помилку, вхід до облікового запису або загальну пошукову сторінку. Тому код відповіді — окремий пункт перевірки, а не підтвердження правильності вмісту. Це стосується й зображення, видимого в браузері, якщо його початковий файл захищено інакше.
Для непостійних помилок корисні час виникнення та серверні журнали. Зіставте зареєстровані збої з відповідними URL і останніми змінами. Фраза «у мене магазин працює» мало допомагає, коли помилка виникає лише в нових сесіях, за певних звернень або під час регулярного підвищеного навантаження.
Змінюйте правила захисту та сканування цілеспрямовано. Не відкривайте про всяк випадок закриті розділи й не вимикайте всіх заходів безпеки. Технічне завдання — забезпечити надійний доступ до публічних товарних відомостей. Сама лише підстановка User-Agent не доводить успішності справжнього звернення Google.
Після виправлення технічний доступ і статус товару залишаються двома окремими точками контролю. Доступність не означає ні індексування, ні негайного допуску до Shopping. Дочекайтеся передбаченого для цієї помилки повторного оцінювання та додайте результат до наявного запису, замість того, щоб закривати завдання за власним успішним тестом.
10 · Проблеми із зображеннями
Перевіряйте переданий файл зображення, а не лише галерею магазину
Зображення, варіант товару та технічний доступ мають відповідати одне одному
Відкрийте саме той image_link, який було оброблено. Перевірте, чи повертає він придатний файл зображення потрібного варіанта, а не заглушку або HTML-сторінку помилки. Перше фото у великій галереї магазину може бути правильним, тоді як експорт використовує інше або застаріле зображення. Тому конкретна адреса файлу має входити до опису проблеми.
Офіційні вимоги до image_link охоплюють, зокрема, зображення товару, якість файлу та неприпустимі рекламні накладення. Доданий поверх фотографії напис про знижку оцінюється інакше, ніж марка, яка справді є частиною зображеного товару. Для зображень, створених за допомогою ШІ, потрібно зберігати передбачені метадані походження. Перевіряйте конкретну вимогу, замість того, щоб вважати помилкою будь-який видимий текст.
Визначте, хто відповідає за причину: неправильний вибір зображення в каталозі, помилкове зіставлення полів експорту, невідповідний файл чи недоступний шлях до медіафайлу. Ці причини потребують різних змін. Нова фотографія не усуне блокування доступу; відкриття файлу не виправить неправильний колір зображеного товару.
Коли замінюєте файл, зафіксуйте попередню й поточну прив’язку до товару. Перевірте також, що фактично віддається за збереженою адресою і чи не показує кеш стару версію. Узгодьте технічне оновлення з відповідальним за систему, замість того, щоб постійною зміною адрес ускладнювати відстеження.
Після цього перевірте і виправлені, і сусідні варіанти. Скориговане правило вибору зображення може випадково призначити однакове фото всім кольорам. Тому задокументуйте виправлений варіант і контрольну пропозицію, яка залишилася правильною.
11 · Правила й довіра
Виділіть введення в оману в окрему гілку перевірки
Проблему облікового запису не можна звести до одного тексту в підвалі сайту
Якщо повідомлення посилається на правило, прочитайте, на що саме воно поширюється. Правило щодо введення в оману стосується, зокрема, неправдивих відомостей про особу чи ділові зв’язки, оманливих пропозицій і відсутності суттєвих умов купівлі. Серйозні порушення можуть спричинити негайне блокування. Загальний список порад щодо дизайну не дозволяє надійно діагностувати таку проблему.
Натомість зіставте важливі відомості: хто продає, як зв’язатися з продавцем, що саме обіцяно і які умови діють? Порівняйте сайт, дані облікового запису та фактичний процес купівлі. Різне написання не означає автоматично обману; проте суперечливі по суті відомості про продавця потребують обґрунтованого пояснення.
Перевірте твердження про партнерство з брендами, авторизацію чи особливі властивості товарів за наявними доказами. Не додавайте вигаданих сертифікатів, відгуків або даних компанії для імітації довіри. Якщо твердження неможливо підтвердити, його потрібно належно уточнити або вилучити. Основою опису залишаються реальні обставини.
Інформацію про повернення, доставку та контакти має бути легко знайти й зрозуміти; вона повинна відповідати практиці. Доручіть відповідальним фахівцям підтвердити описані процеси. Скопійовані умови, яких компанія не дотримується, лише переносять проблему в інше місце.
Запишіть, які конкретні суперечності виявлено, а які пункти перевірено без зауважень. Повне пояснення фактів корисніше за заяву «все покращено». Якщо питання стосується юридичних обов’язків або тлумачення вимог, зверніться до профільного фахівця саме з цими пунктами; технічна перевірка Merchant Center не дає щодо них остаточного висновку.
12 · Доставка й умови купівлі
Перевіряйте фактичні умови аж до оформлення замовлення
Правильне налаштування облікового запису може бути перекрите товарними даними
Почніть із країни доставки, якої стосується проблема, та адреси, куди ви справді доставляєте. Який спосіб, вартість і заявлений строк доставки показано під час купівлі? Порівняйте їх із налаштуваннями саме цієї пропозиції. Загальна фраза «доставка до Німеччини» ще не пояснює відмінне правило для конкретного товару або регіону.
У документації атрибута shipping описано також перевизначення на рівні товару. Якщо передано його підатрибут ціни, відповідні налаштування служби доставки на рівні облікового запису для цього товару ігноруються; це стосується й пов’язаних строків доставки та мінімальної суми замовлення. Тому перевіряйте конфігурацію, яка фактично діє, а не лише останню відредаговану таблицю в обліковому записі.
Пройдіть конкретний приклад до кроку перед остаточним оформленням замовлення. Запишіть склад кошика, країну доставки, запропоновану службу та додаткові витрати. Технічна перевірка не повинна випадково створити платне замовлення. Якщо повне тестове замовлення необхідне, використовуйте погоджену процедуру з чіткою відповідальністю за оплату й скасування.
Для ширшої перевірки магазину скористайтеся чеклістом підготовки Shopify до Google Shopping. Для поточної помилки перенесіть із нього до свого реєстру лише потрібні дії. Запис має пояснювати, які відомості були неправильними і де виконано виправлення: у магазині, джерелі даних чи налаштуваннях облікового запису.
Повторіть тест для обґрунтовано обраного граничного випадку, наприклад іншого підтримуваного регіону або іншої суми кошика. Так ви виявите правила, які лише випадково спрацювали правильно під час першої перевірки. Не обіцяйте умов доставки, яких бізнес не може виконати, лише для усунення попередження в діагностиці.
13 · Автоматичні зміни
З’ясуйте, хто змінив кінцеве значення
Автоматична допомога не замінює усунення причини
Google описує автоматичне оновлення товарів, яке може виправляти виявлені розбіжності певних значень пропозиції. Воно не замінює регулярного передавання правильних даних. Якщо після автоматичної зміни ціна виглядає правильною, все ще потрібно з’ясувати, чому ваше джерело передало неправильну ціну. Перевірте походження кінцевого значення, перш ніж закривати випадок.
Відрізняйте такі оновлення від прийнятих пропозицій щодо атрибутів, постійних правил автоматичного виправлення та ручних змін товару. Вони можуть по-різному впливати на подальше передавання даних. Запишіть, яку саме функцію використано і де це видно. Загальної нотатки «Google виправив» недостатньо для перевірки наступного імпорту.
Для регулярного ведення ідентифікаторів, назв і класифікацій використовуйте реєстр якості фіду для оптимізації товарних даних. Реєстр помилок у цій статті доповнює його повідомленням, масштабом проблеми та перевіркою повторного допуску. Пов’яжіть обидва завдання через ті самі ідентифікатори пропозицій, замість того, щоб створювати суперечливі, не пов’язані між собою списки.
Перевірте, чи зберігається погоджене виправлення після нового регулярного передавання даних. Потім з’ясуйте, чи потрібне ще тимчасове перевизначення або його вже можна контрольовано прибрати. Прибирайте його лише тоді, коли основне джерело надійно дає правильний результат. Інакше ви можете відновити розбіжність, яку раніше вдавалося компенсувати.
Фіксуйте й корисні автоматичні втручання. Вони можуть пояснити, чому однакові вихідні значення давали різні результати. Такі записи позбавлять вас пошуку нібито випадкової поведінки під час наступного збою.
14 · Реєстр помилок
Поєднуйте симптом, доказ і критерій закриття в одному записі
Таблиця має допомагати ухвалювати рішення, а не лише збирати завдання
Використовуйте наведену структуру як реєстр для копіювання. Усі записи — умовні приклади. Для кожного випадку додайте в робочому файлі унікальний номер, ідентифікатори пропозицій, країну, спосіб розміщення, часові позначки та посилання на докази. Один рядок описує окрему причину; кілька відповідних товарів прив’язують до нього без дублювання пояснення причини.
| Симптом і масштаб | Доказ | Підтверджена причина | Виправлення та відповідальні | Повторна перевірка | Критерій закриття |
|---|---|---|---|---|---|
| Розбіжність ціни · сімейство варіантів | Експорт, сторінка й оформлення замовлення | В експорті немає правила акції | Змінити зіставлення · відповідальний за фід | Нове передавання даних і ті самі варіанти | Значення та статус узгоджені |
| Зображення недоступне · шлях до файлів | URL і технічна відповідь | Публічний файл заблоковано | Виправити доступ · вебкоманда | Отримання файлу й повторне оцінювання | Зображення доступне, проблему усунено |
| Неправильна наявність · окремий розмір | Вибраний варіант і журнал залишків | Помилково зіставлено варіант | Виправити прив’язку · команда магазину | Простежити зміну залишку | Правильний статус зберігається |
| Проблема облікового запису · відомості про продавця | Повідомлення й порівняння сторінок | Ще не підтверджено | З’ясувати обставини · компанія | Лише після документованого з’ясування | Без передчасного закриття |
| Помилка повертається після імпорту | Два передавання даних | Джерело перезаписує виправлення | Виправити головне поле · відповідальний за дані | Наступний імпорт і контрольний товар | Помилка не повторюється |
Відділяйте статус роботи від рішення Google. Позначка «технічно виправлено» може бути правдивою, коли «повторна перевірка триває» все ще актуально. Лише успішна перевірка статусу в потрібному контексті завершує завдання повторного допуску. Якщо після цього оголошення не показуються, починається окреме дослідження показів; не замінюйте закриту проблему іншим питанням.
Кожен відкритий рядок потребує наступної дії: для «очікування» вкажіть очікуваний етап перевірки й дату контролю, для «підтримки» — точне питання та докази. Так ви розрізнятимете відсутні відомості, поточні перевірки й ще не виконані зміни.
15 · Повторна перевірка
Надсилайте запит на перевірку після підтвердженого виправлення
Усунення проблеми та обґрунтоване оскарження — різні процедури
Офіційна інструкція щодо повторної перевірки розрізняє усунену проблему й незгоду з висновком. Використовуйте відповідну функцію, доступну в обліковому записі. У певних випадках спершу потрібні додаткові кроки, наприклад запитане підтвердження особи. Якщо кнопка недоступна, перевірте також поточні процедури, вимоги до джерела даних і можливий період очікування.
Перед запитом підготуйте коротке пояснення, яке можна перевірити: яке повідомлення розглядалось, що ви встановили, де усунули причину та з яким результатом повторили тест. Якщо ви оскаржуєте висновок, натомість поясніть, які підтверджувані факти, на вашу думку, роблять рішення неправильним. Непідкріплена незгода не посилює обґрунтування.
Google вказує строк перевірки до семи робочих днів; це не індивідуальна гарантія повторного допуску. Повторна перевірка також не тотожна початковій обробці даних чи окремому скануванню. Перенесіть до реєстру видимий в обліковому записі статус і дату запиту, замість того, щоб об’єднувати різні часові орієнтири в один гарантований строк.
Оскарження може бути доступне лише один раз. Після невдалих спроб можуть діяти й подовжуватися періоди очікування; підтримка Google не може їх скоротити. Використайте цей час для предметної повторної перевірки. Постійне натискання кнопки, новий обліковий запис або порожнє джерело даних не є надійною альтернативою передбаченій процедурі.
Під час перевірки зберігайте зрозумілу історію змін. Неправильні відомості, що потребують термінового виправлення, слід виправляти й надалі, проте повна одночасна перебудова сайту ускладнює оцінювання. Звертаючись по допомогу, передайте номер випадку, контекст і потрібні докази через передбачений захищений канал та поставте чітке питання щодо конкретної проблеми.
16 · Контроль повторного допуску
Закривайте випадок за тими самими пропозиціями
Менша кількість помилок може пояснюватися і зникненням товарів
Після обробки або перевірки порівняйте ті самі ідентифікатори пропозицій у тій самій країні й тому самому способі розміщення. Переконайтеся, що товари залишаються в запланованому асортименті. Зниження лічильника помилок недостатньо: воно може пояснюватися видаленням, іншим добором товарів або зміною фільтра. Окремо фіксуйте реальний стан справ і видимий стан системи.
| Контрольний пункт | Основа порівняння | Перевірку пройдено, якщо | Відкрити знову, якщо | Доказ |
|---|---|---|---|---|
| Значення в даних | Початково проблемні ідентифікатори | Оброблено правильне значення | Старе значення з’явилося знову | Експорт і час |
| Сайт | Той самий варіант і URL | Умови купівлі відповідають даним | Вибір або умова суперечать даним | Протокол перевірки |
| Статус товару | Та сама країна й спосіб розміщення | Відповідну проблему усунено | Відхилення збереглося або змінилося | Статус і повідомлення |
| Статус облікового запису | Та сама проблема облікового запису | Відповідне обмеження знято | Проблема облікового запису залишається | Рішення в обліковому записі |
| Наступне передавання даних | Подальший регулярний імпорт | Виправлення залишається стабільним | Помилка повертається | Версія та відповідальні |
Якщо відхилення зникло, але оголошення не показуються, розглядайте нове питання окремо: чи використовуються товари в потрібній кампанії та які обмеження діють у ній? Допуск у Merchant Center сам собою не гарантує ні показів, ні кліків. Не змінюйте знову перевірені товарні дані лише тому, що комерційного ефекту ще немає.
Після закриття погодьте належну процедуру контролю повторюваних причин. Виправлене зіставлення полів потрібно контролювати після змін конектора, цінову проблему — під час акцій, проблему сайту — після відповідних публікацій. Частота залежить від фактичних змін у бізнесі, а не від універсального обов’язкового щоденного розкладу.
17 · Поширені запитання
Відповіді на типові запитання під час усунення помилок
Чи означає попередження, що всі товари заблоковано?
Ні. Перевірте рівень проблеми, спосіб розміщення й відповідні пропозиції. Попередження потребує уваги, але не означає автоматично блокування облікового запису. Конкретне повідомлення визначає, що потрібно виправити.
Чому ціна в магазині правильна, а товар усе одно відхилено?
Можливо, порівнюється інший варіант, старий стан даних або відмінне машинозчитуване значення. Простежте той самий товар від обробленого запису до оформлення замовлення та зафіксуйте час перевірок.
Чи можна усунути проблеми GTIN вигаданими номерами?
Ні. Встановіть правильне маркування й застосовну вимогу до атрибута. Невідоме значення не тотожне ідентифікатору, який достовірно не присвоювався. Зафіксуйте відкриті питання до постачальника.
Чи достатньо видалити відхилені товари й створити їх знову?
Це не доводить усунення причини та перериває відстеження тієї самої пропозиції. Виправте реальну помилку й перевірте наявну прив’язку, якщо немає об’єктивної потреби змінювати структуру.
Чому кнопка перевірки неактивна?
Перевірте підказки щодо передумов, поточної перевірки або періоду очікування. Залежно від випадку можуть знадобитися додаткові докази. Визначальним є конкретний стан облікового запису; повторний запит не завжди можна подати одразу.
Чи доводить автоматичне виправлення, що фід справний?
Ні. Воно може компенсувати розбіжність, поки джерело й далі передає неправильні дані. Перевірте походження кінцевого значення та наступне регулярне передавання даних, перш ніж позначати причину як усунену.
Чи може агенція гарантувати повторний допуск?
Фахова діагностика дозволяє впорядкувати проблеми, виправити доведені помилки та підготуватися до перевірки. Рішення ухвалює Google. Без доступу до повідомлення й доказів неможливо навіть упевнено визначити конкретну причину.
Коли випадок вважається закритим?
Коли причину документовано усунено, відповідні пропозиції знову мають потрібний статус у правильному контексті, а наступний імпорт зберігає виправлення. Фактичний показ реклами після цього перевіряється окремо.
18 · Наступний крок
Почніть з одного задокументованого випадку
Зрозуміла діагностика створює основу для стабільного виправлення
Виберіть актуальне повідомлення та збережіть точний контекст. Пройдіть дерево діагностики, зіставте один проблемний варіант на всьому шляху даних і внесіть підтверджену причину до реєстру. Якщо причина ще не встановлена, сформулюйте відсутню інформацію як конкретне наступне завдання.
Потім внесіть виправлення у відповідне джерело або систему та повторно перевірте результат. Запитуйте перевірку лише через належну доступну процедуру й після виконання потрібних передумов. Закривайте випадок за початковими пропозиціями, а не за заспокійливим загальним числом. Так виконана робота залишатиметься зрозумілою і після наступного імпорту, і після зміни відповідальної особи.
Зв’язок між повідомленням, причиною та результатом залишається задокументованим: що було неправильним, що змінили та який доказ підтверджує усунення? На цій основі формується процедура перевірки, яку можна використати повторно.
Якщо ви хочете спільно перевірити товарні дані, магазин і проблеми облікового запису та послідовно підготувати наступні дії, Salestudia допоможе з налаштуванням і оптимізацією Google Merchant Center.