Якщо ви керуєте інтернет-магазином і хоч раз синхронізували товарний фід із Google, ви точно чули про Content API. Роками цей інструмент був стандартом для автоматизації роботи з Merchant Center. Але часи змінюються, і Google вирішив зробити крок уперед, запропонувавши новий інструмент — Merchant API. Перехід не добровільний у довгостроковій перспективі, тому варто розібратися, що конкретно міняється, чому це важливо для SEO та як не наламати дров при переналаштуванні інтеграцій.
Чому Google відмовляється від старого API
Content API for Shopping створювали ще в ту епоху, коли товарні оголошення Google були простішими, а функціонал Merchant Center обмежувався базовим завантаженням фідів. З роками до платформи додавали нові можливості: динамічний ремаркетинг, локальний інвентар, програми лояльності, автоматизовані знижки. Старий API просто не встигав охоплювати все це органічно, тому розробники патчили його додатковими ендпоінтами, і структура стала громіздкою.
Google офіційно оголосив про поступове виведення Content API for Shopping з експлуатації, встановивши конкретні терміни відключення. Це означає, що всі, хто досі використовує старі методи інтеграції, ризикують одного дня прокинутися з непрацюючим фідом і зупиненими рекламними кампаніями. Тому перехід на Google Merchant API замість Content API for Shopping — не питання «чи», а питання «коли ви це зробите: заздалегідь спокійно чи в паніці в останній момент».
Що таке Google Merchant API насправді
Новий API побудований за модульним принципом. Замість одного монолітного інтерфейсу Google розбив функціонал на окремі підмодулі: Products, Inventories, Promotions, Reports, Accounts, Conversions і так далі. Кожен модуль відповідає за свою частину роботи, і це дає розробникам можливість підключати лише те, що потрібно, без зайвого навантаження на систему.
Така архітектура нагадує конструктор: хочете керувати лише товарами й цінами — підключаєте Products API. Потрібна робота з локальним інвентарем у фізичних магазинах — додаєте Inventories. Це зручніше, ніж працювати з однією великою бібліотекою методів, де половина функцій вам ніколи не знадобиться.
Ще одна відмінність — покращена система звітності. Reports API дозволяє отримувати аналітику безпосередньо через запити, без необхідності експортувати дані вручну через інтерфейс Merchant Center. Для великих магазинів із тисячами товарних позицій це суттєво економить час на аналізі ефективності товарних оголошень Google.
Порівняння двох підходів
Щоб наочно побачити різницю, зведемо основні характеристики в таблицю. Це допоможе зрозуміти, чому перехід виправданий не лише через примусове відключення старого інструменту, а й через реальні технічні переваги.
| Параметр | Content API for Shopping | Google Merchant API |
|---|---|---|
| Архітектура | Монолітна | Модульна, розділена на сервіси |
| Формат даних | REST з обмеженою типізацією | Покращена типізація, підтримка gRPC |
| Звітність | Обмежена, потрібен ручний експорт | Вбудований Reports API |
| Підтримка | Поступово припиняється | Активний розвиток |
| Робота з локальним інвентарем | Через окремі складні виклики | Окремий зручний модуль |
Як бачите, різниця не косметична. Google не просто перейменував старий продукт, а фактично переписав його з урахуванням сучасних вимог до масштабованості й гнучкості.
Як налаштувати Merchant API: покроковий план
Багато власників магазинів бояться технічної складності переходу, і почасти це виправдано, якщо інтеграція була написана кілька років тому й ніхто до неї не торкався. Але сам процес налаштування логічний, якщо розбити його на етапи.
- Створіть новий проєкт у Google Cloud Console або використайте вже наявний, якщо ви раніше працювали з Google API.
- Увімкніть Merchant API у бібліотеці API, знайшовши його серед доступних сервісів Google.
- Налаштуйте автентифікацію через OAuth 2.0 або сервісний облік, залежно від того, як ваша система взаємодіє з Google.
- Оновіть код інтеграції, замінивши старі ендпоінти Content API на відповідні модулі Merchant API — зазвичай Products і Inventories покривають базові потреби більшості магазинів.
- Протестуйте синхронізацію на тестовому акаунті Merchant Center, перш ніж переносити зміни на робочий магазин.
- Перевірте, що звіти й статуси товарів коректно відображаються у панелі Merchant Center після оновлення.
Якщо ваш магазин працює на популярній CMS типу Shopify, WooCommerce чи Magento, велика ймовірність, що плагін для синхронизації з Google оновиться автоматично і вам не доведеться писати код руками. Але якщо у вас кастомна платформа або самописний фід, варто закладати кілька днів роботи розробника на цю задачу.
Що робити з існуючими фідами
Хороша новина: сам формат товарного фіда (атрибути товару, назва, ціна, наявність) залишається практично незмінним. Google не вимагає повністю переписувати структуру даних про товари. Змінюється спосіб передачі цих даних до системи, а не сама суть інформації.
Це важливо розуміти, бо частина панічних постів у форумах веброзробників виникає саме через нерозуміння цього моменту. Люди думають, що доведеться перебудовувати весь каталог товарів, хоча насправді змінюється лише транспортний рівень взаємодії з Google.
Типові помилки Google Merchant Center після переходу
Навіть при коректній технічній міграції власники магазинів часто стикаються з помилками, які лякають, але зазвичай мають прозаїчне пояснення. Розглянемо найпоширеніші випадки.
Перша й найчастіша проблема — розсинхронізація статусів товарів. Після переходу на новий API деякі товари можуть тимчасово відображатися як “disapproved”, хоча реально з ними все гаразд. Це відбувається через те, що система заново індексує дані через новий канал передачі, і потрібно від кількох годин до двох діб, щоб статуси стабілізувались.
Друга поширена помилка стосується автентифікації. Якщо сервісний облік не отримав правильних прав доступу до конкретного Merchant Center акаунту, API повертатиме помилки 403 forbidden. Перевірте, що облік додано саме як користувач із правами адміністратора в налаштуваннях акаунту, а не просто створено в Cloud Console.
Третя категорія проблем пов’язана з форматом атрибутів. Хоча основна структура фіда не змінилась, деякі поля в Merchant API мають трохи іншу назву або тип даних порівняно зі старим API. Наприклад, поля, пов’язані з ціною і валютою, тепер вимагають чіткішого дотримання формату числа з крапкою замість коми в деяких локалях.
| Помилка | Ймовірна причина | Рішення |
|---|---|---|
| 403 Forbidden | Немає прав доступу сервісного облікового запису | Додати облік як користувача в Merchant Center |
| Disapproved товари | Тимчасова розсинхронізація після міграції | Зачекати 24-48 годин, перевірити знову |
| Invalid attribute format | Різниця в типізації полів між API | Оновити структуру даних відповідно до нової документації |
Як перехід впливає на SEO для Google Merchant Center
Пряма зміна API не впливає на алгоритми ранжування в органічному пошуку. Але тут є нюанс, про який часто забувають: якщо через технічні проблеми при переході товари тимчасово випадають з фіда або отримують статус помилки, це негативно впливає на видимість у Google Shopping і, як наслідок, на трафік із товарних оголошень.
SEO інтернет-магазину Google завжди складається з двох частин: класична оптимізація сторінок товарів і коректна робота з фідом даних у Merchant Center. Ці частини взаємопов’язані. Якщо структуровані дані товар на сторінці не збігаються з даними, які передаються через API, Google може знизити довіру до фіда, і це проявляється у зменшенні показів у результатах пошуку товарів.
Особисто я стикався з ситуацією, коли клієнт скаржився на падіння трафіку з Google Shopping буквально через тиждень після того, як його підрядник поспішно перейшов на новий API, не перевіривши валідність структурованих даних на сторінках. Виявилося, що ціна в product schema на сайті відрізнялась від ціни у фіді через кешування сторінки. Google просто почав недовіряти джерелу і знизив пріоритетність показу товарів. Виправили розбіжність — трафік повернувся протягом двох тижнів.
Product schema для Google як частина довіри до фіда
Структуровані дані на сторінці товару — це не просто технічна формальність для розробників. Google активно порівнює інформацію з мікроданих schema.org на сторінці з тим, що надходить через фід Merchant Center. Якщо ці дані розходяться (різна ціна, різна наявність товару, різна назва), алгоритм може вважати фід менш надійним.
Тому при переході на новий API варто одночасно перевірити, чи коректно реалізована розмітка product schema на всіх картках товарів. Часто про це забувають, бо технічна команда фокусується суто на API-інтеграції, а маркетингова частина сайту залишається без уваги.
Товарні оголошення Google і нова архітектура API
Товарні оголошення Google працюють на основі даних із Merchant Center незалежно від того, який API використовується для завантаження цих даних. Тобто сама реклама не стає “кращою” чи “гіршою” через зміну API. Але швидкість і надійність оновлення даних безпосередньо впливає на релевантність оголошень.
Наприклад, якщо у вас акційні товари з обмеженим запасом, і фід оновлюється рідше через технічні обмеження старого Content API, є ризик показувати рекламу товару, якого вже немає в наявності. Новий Merchant API з модулем Inventories дозволяє оновлювати статус наявності частіше і точніше, що напряму покращує якість Google Shopping SEO та зменшує кількість відмов від покупки через відсутність товару.
Це особливо критично для магазинів одягу та електроніки, де залишки товарів змінюються буквально щогодини. Швидша й точніша синхронізація зменшує розчарування покупців і знижує показник відмов, що теж непрямо впливає на позиції в пошуку.
Практичні рекомендації перед переходом
Перш ніж кидатися переписувати весь код інтеграції, варто скласти невеликий план дій. Нижче наведу перелік кроків, які допоможуть уникнути хаосу під час переходу.
- Проведіть аудит поточної інтеграції та зафіксуйте, які саме методи Content API використовуються у вашій системі.
- Перевірте документацію Google щодо відповідності старих і нових ендпоінтів — багато методів мають прямі аналоги в новому API.
- Створіть тестовий Merchant Center акаунт для перевірки нової інтеграції без ризику для основного магазину.
- Синхронізуйте перевірку product schema на сайті з оновленням даних у фіді, щоб уникнути розбіжностей.
- Заплануйте перехід на період низького трафіку, наприклад, не напередодні великих розпродажів.
Такий підхід дозволяє мінімізувати ризики й уникнути ситуації, коли через технічну помилку магазин втрачає видимість у товарних оголошеннях у найважливіший для продажів період.
Що це означає для малого й середнього бізнесу
Власники невеликих інтернет-магазинів часто користуються готовими плагінами для CMS, і для них перехід буде майже непомітним — розробники платформ уже адаптували свої рішення під новий стандарт. Головне, стежити за оновленнями плагінів і не ігнорувати повідомлення про необхідність оновлення версії модуля.
А от для магазинів із кастомними рішеннями, написаними на замовлення кілька років тому, це серйозний сигнал звернутися до розробника завчасно. Краще витратити кілька годин на планову міграцію зараз, ніж екстрено гасити пожежу, коли старий API просто перестане відповідати на запити, а рекламні кампанії зупиняться без попередження.
У підсумку варто розуміти: заміна Google Merchant API замість Content API for Shopping — це не просто бюрократична вимога Google, а реальна модернізація інфраструктури, яка при правильному підході покращує швидкість оновлення даних, точність товарних оголошень і, як наслідок, ефективність усього процесу продажу через пошукову систему. Головне — підійти до переходу планово, перевірити всі супутні елементи на сайті, включно зі структурованими даними, і не залишати це на останній тиждень перед відключенням старого сервісу.
