Помилка в Merchant Center зазвичай є не причиною, а останнім видимим симптомом: каталог, фід, картка товару, структуровані дані й checkout показують Google різні факти. Ручне виправлення одного товару може прибрати попередження сьогодні, але наступна синхронізація поверне його завтра.
Вивантажте всі проблеми, об’єднайте їх за спільною причиною, звірте кілька типових SKU на кожному етапі та виправте систему, яка володіє неправильним значенням. Правила фіда й автоматичні оновлення доречні як запобіжники, але не як постійна заміна коректного каталогу.
Чому фід Merchant Center варто перевірити у 2026 році
14 квітня 2026 року Google оновив специфікацію товарних даних. З’явилися нові поля доставки на рівні товару, зокрема handling_cutoff_time і minimum_order_value. Для video_link перевірка правил і якості та можливість показу почали діяти 30 червня. Водночас Merchant Center уже попереджає про зображення менші за 500 × 500 пікселів: нова мінімальна роздільна здатність набуде чинності 31 січня 2027 року.
Не треба поспіхом додавати всі нові атрибути. Потрібно знати, звідки береться кожне значення, хто за нього відповідає і як воно змінюється. Google використовує товарні дані не лише в платній рекламі: вони можуть підтримувати розширені результати Пошуку, Google Зображення, Lens, безкоштовні оголошення та вкладку Shopping. У звіті McKinsey про європейський retail за червень 2026 року також описано рух каталогів у канали пошуку товарів за допомогою ШІ. Суперечливе поле тепер шкодить одразу кільком точкам контакту.
Україномовна видача має чіткий практичний намір: люди шукають «помилки Merchant Center», «товари відхилено», «вимоги до фіда», розбіжності ціни та наявності. Тому нижче не словник атрибутів, а спосіб знайти й прибрати системну причину.
Намалюйте шлях товару до Google
Для однієї пропозиції зафіксуйте весь ланцюжок. Навіть невеликий магазин зазвичай має п’ять різних представлень того самого товару:
| Рівень | За що відповідає | Типовий збій |
|---|---|---|
| Джерело каталогу | SKU, варіант, бренд, GTIN, базові характеристики | Неповні дані або неясний власник |
| Комерційний стан | Ціна продажу, залишок, країна, податок, акція | Системи оновлюються в різний час |
| Перетворення у фід | Атрибути Google, виключення, мітки, формат | Правило обрізає, округлює чи підмінює значення |
| Картка товару | Видима пропозиція, URL і можливість купити | Інший варіант, валюта, редирект або блокування |
| Product schema | Машиночитні Product і Offer | Розмітка не збігається зі сторінкою чи фідом |
Merchant Center спостерігає за цим ланцюжком, але не завжди є джерелом даних. Розбіжність ціни може виникнути в ERP, модулі акцій, конвертації валюти, кеші, темі магазину, генераторі JSON-LD, регіональному URL або розкладі експорту. Для кожного рівня запишіть власника й частоту оновлення. Інакше маркетолог виправить число в кабінеті, а інтеграція знову завантажить старе.
Ідентифікатор пропозиції має бути стабільним. Якщо один і той самий варіант отримує новий id після кожного імпорту, ви втрачаєте зрозумілу історію діагностики. Але один id не можна повторно використовувати для різних розмірів чи комплектацій. Товарна модель, конкретна пропозиція та залишок на складі — не одне й те саме.
Сортуйте не за кольором попередження, а за наслідком
Відкрийте розділ «Потрібна дія» та експортуйте повний перелік. Google розрізняє попередження і відхилення: товар із попередженням ще може показуватися, але його ефективність може бути обмежена; відхилена позиція не показується. Проблема рівня облікового запису здатна зачепити весь асортимент. Збережіть назву проблеми, країну, програму, дату першої появи, приклади ID та кількість позицій.
Черга робіт має бути такою:
- Ризик для акаунта й правил: усе, що може зупинити весь каталог або вводить покупця в оману.
- Втрачений попит: відхилені товари, які є в наявності, мають маржу й отримували б переходи.
- Масова причина: один шаблон чи трансформація ламає цілу категорію.
- Майбутнє обов’язкове правило: наприклад, 500 × 500 для зображень, поки є час перезняти чи перевивантажити матеріали.
- Збагачення: корисні необов’язкові поля після відновлення базової придатності.
Одна назва помилки не означає одну причину. Сотня розбіжностей ціни може складатися з простроченої акції, URL у неправильній валюті, затриманого cron-завдання та різного показу ПДВ. Формуйте кластери за фактичним походженням.
Зробіть таблицю істини для п’яти SKU
Візьміть 5–10 проблемних пропозицій: різні категорії, варіанти, країни й сценарії оновлення. Одночасно зніміть значення з усіх рівнів. Перевіряйте саме той URL, який отримує Google, разом із мовою, валютою та параметрами.
ID пропозиції: ua-shoe-482-black-42
Час перевірки: 2026-09-14T08:10:00Z
Поле Каталог Фід Сторінка JSON-LD Checkout
ціна 2899 грн 2899 грн 2699 грн 2699 грн 2699 грн
наявність є є є є є
GTIN 0482... 0482... 0482... 0482... —
варіант чорн./42 чорн./42 чорн./42 чорн./42 чорн./42
власник pricing feed job storefront SEO app commerceУ прикладі акційна ціна дійшла до сайту, але не до експорту, з якого формується фід. Правильне місце ремонту — синхронізація ціни. Ручна зміна в Merchant Center лише приховає дефект.
Перевірте сторінку як неавторизований бот: фінальний HTTP-статус, ланцюг редиректів, canonical, дозвіл на індексацію, видиму ціну, обраний варіант, валюту, залишок, зображення, Product schema, доставку та повернення. У документації про товарні результати Google попереджає, що динамічна JavaScript-розмітка може бути менш надійною для ціни й наявності, які часто змінюються. Критичні дані краще віддавати в початковому HTML, якщо архітектура це дозволяє.
Шість причин, які варто виправляти в джерелі
1. Ціна та час дії акції
Визначте один сервіс або запис, який є джерелом ціни продажу для кожного ринку. Узгодьте валюту, ПДВ, ціну для учасників програми, мінімальну кількість і початок та завершення акції з часовим поясом. Подана ціна має бути реально доступна на цільовій сторінці без прихованого промокоду, входу чи перемикання на інший варіант, якщо відповідний атрибут і правила Google не передбачають інше.
2. Запізнення наявності
Виміряйте час від зміни залишку до оновлення сайту, фіда й надсилання в Google. Для дефіцитного товару нічний файл не є правдивим джерелом о 14:00. Потрібні частіші або подієві оновлення. Автоматичне виправлення даних Google може зменшити тимчасову розбіжність, коли Google бачить інше значення на сторінці. Воно не усуває оверселінг і не ремонтує складську інтеграцію.
3. GTIN, бренд і варіанти
Вказуйте код, присвоєний саме цій торговій одиниці. Не вигадуйте GTIN, не копіюйте код сусіднього розміру й не позначайте брендований товар як індивідуальний лише заради проходження перевірки. GS1 пояснює, що маркетплейси використовують Verified by GS1 для перевірки ідентифікаторів і боротьби з дублями. Колір, розмір, кількість у наборі та модель мають однаково описуватися в назві, URL варіанта, фіді й розмітці.
4. Зображення
Перевіряйте вихідний файл, а не лише мініатюру в темі. Приберіть рекламні написи, заглушки, прострочені CDN-підписи та блокування для Google. Уже зараз сформуйте список усіх основних і додаткових зображень менших за 500 × 500: нове обмеження Google почне діяти 31 січня 2027 року. Автоматична оптимізація Google — страховка, а не процес виробництва контенту.
5. Доставка, повернення та країна продажу
Для кожної країни звірте налаштування акаунта, винятки товару, обіцянку на сторінці та реальний checkout. Час приймання замовлень, мінімальну суму, перевізника, строк обробки, вікно повернення й виключення слід зберігати з власником і датою дії. Не додавайте новий атрибут 2026 року, якщо джерело не вміє підтримувати його актуальним.
6. Сторінка, сканування та правила
URL із фіда має вести на конкретну пропозицію, яку можна купити. Виправте редиректи на категорію чи іншу країну, випадкову авторизацію, robots-блокування, недоступні ресурси, текст-заповнювач і суперечливі реквізити бізнесу. Технічно валідний фід не скасовує правил Shopping. Спершу зрозумійте й усуньте порушення, а вже потім надсилайте запит на повторну перевірку.
Поставте перевірку перед публікацією
Опишіть контракт придатної до продажу пропозиції й перевіряйте його до вивантаження:
- унікальний стабільний ID та однозначне зіставлення варіанта;
- робочі публічні URL сторінки й зображень;
- узгоджені валюта, округлення, податок, залишок і дати акції;
- справжні обов’язкові ідентифікатори без вигаданих значень;
- однакові ціна й наявність у фіді, видимій сторінці та JSON-LD;
- доставка й повернення, які checkout справді виконує;
- очікувана кількість товарів і безпечний обсяг змін.
Матеріальна помилка має зупиняти реліз. Якщо можливо, ізолюйте лише проблемну групу, щоб один зламаний експорт категорії не прибрав увесь асортимент. Для кожного запуску зберігайте готовий фід, версію джерела, звіт валідації та версію правил. Сповіщайте про різку зміну кількості товарів, частки відхилень, розподілу цін, відсутніх фото й віку останнього оновлення.
Додаткові фіди та правила доречні для свідомого збагачення каналу — наприклад, міток кампаній. Не маскуйте ними хибні GTIN, ціну, залишок або базові характеристики. Кожне правило повинно мати власника, пояснення, тест і дату перегляду.
План відновлення фіда на сім днів
Зробіть знімок «до». Випускайте по одній групі причин і чекайте результату обробки, а не змінюйте безладно інші поля. Google вказує, що формальна перевірка товарів часто триває 3–5 робочих днів, іноді довше; для окремих повторних сканувань у довідці наведено орієнтир 24–48 годин. Це поточна підказка інтерфейсу, а не гарантований SLA.
Вимірюйте здоров’я каталогу, а не лише статус «Схвалено»
Стежте за часткою придатних і схвалених пропозицій за країною та програмою; відхиленнями й попередженнями за причиною; кількістю важливих для виторгу товарів під впливом; свіжістю фіда; власною часткою розбіжностей сторінка/фід; часом виявлення, ремонту, надсилання й відновлення; повтором дефекту за 30 днів; часткою виправлень у системі-власнику, а не вручну.
Схвалений товар усе одно може бути неякісним. Вибірково перевіряйте назви, фото, варіанти, доставку та цільові сторінки. Порівнюйте кліки й конверсію після контрольованих змін, але не приписуйте весь рух одному полю: впливають ставки, конкуренція, сезонність, попит, сайт і правила показу.
Поширені питання
Чому Google Merchant Center відхиляє товари?
Через відсутні або некоректні атрибути, розбіжність ціни чи наявності, неправильні ідентифікатори, недоступну сторінку, проблеми із зображеннями, налаштування країни або порушення правил Shopping. Спершу визначте точний масштаб.
Чи можна виправити помилку прямо в Merchant Center?
Так, якщо Merchant Center свідомо є джерелом цього поля. В інших випадках виправляйте CMS, ERP, PIM, модуль ціни, генератор фіда або шаблон сторінки — ручне значення можуть перезаписати.
Чи замінюють автоматичні оновлення правильний фід?
Ні. Вони можуть тимчасово узгодити ціну або наявність із сайтом, але не ремонтують каталог, checkout, інші канали, ідентифікатори та порушення правил.
Як часто оновлювати товарний фід?
Достатньо часто для найдинамічнішого критичного поля. Стабільному каталогу може вистачити щоденного файлу; дефіцитному товару й частим акціям потрібні подієві або API-оновлення з моніторингом.
Що змінилося у специфікації Merchant Center 2026?
Google додав поля доставки й відео, 30 червня почав показ і перевірку якості відео та ввів попередження перед мінімальним розміром зображення 500 × 500, який стане обов’язковим 31 січня 2027 року.
Джерела та дата перевірки
Перевірено 14 вересня 2026 року за офіційними матеріалами Google: оновлення специфікації Merchant Center 2026, довідка про проблеми Merchant Center, специфікація товарних даних і документація Google Search для ecommerce; матеріалом GS1 про перевірку ідентифікаторів на маркетплейсах; звітом McKinsey про європейський retail у червні 2026 року. Вимоги, назви розділів, строки перевірки й доступність функцій змінюються — звірте поточні підказки свого акаунта.
Rendframe може простежити дані від ERP або CMS до фіда, сторінки, schema й checkout, виправити інтеграцію та додати тести проти повторних помилок. Перегляньте систему синхронізації залишків, пройдіть аудит готовності до AI-покупців або надішліть знеособлений експорт проблем і одну картку товару.