Google Merchant API: a Content API leállt. Mi történik a termékfeededdel?

Ha Google Shopping-hirdetéseket futtatsz, 2026 nyarának egyik legfontosabb híre nem egy új AI-modell volt, hanem egy csendes infrastruktúra-csere a háttérben. A Google 2026. augusztus 18-án kivezette a Content API for Shoppingot, vagyis azt a programozási felületet, amelyen keresztül a webshopok éveken át automatikusan küldték a termékeiket, áraikat és készletadataikat a Google Merchant Centerbe. Az utód a Google Merchant API, szeptember 1-jétől pedig a régi felületre érkező kérések a Google fejlesztői dokumentációja szerint fokozatosan egyre gyakrabban hibára futnak. Aki nem állt át, annak a termékfeedje előbb csak akadozni kezd, aztán elavul, végül a termékek szépen lassan kikopnak a Shopping-hirdetésekből és az ingyenes terméklistázásokból.

A jó hír az, hogy aki fájlalapú feedet, platformalkalmazást vagy naprakész hivatalos bővítményt használ, annál a váltás külön teendő nélkül lezajlott, mert vagy nem is érintette, vagy a szoftver fejlesztője elvégezte helyette. A rossz hír az, hogy a kivételek pont azok a cégek, amelyeknek egyedi fejlesztésű szinkronjuk, régi bővítményük vagy egy évekkel ezelőtt beállított, azóta senki által nem gondozott integrációjuk van. A következő szakaszokban 2026. szeptember 22-i állapot szerint végigvesszük, mi változott pontosan, kit érint, milyen tünetekből ismered fel a bajt, mi a teendő WooCommerce, Shopify és egyedi rendszer esetén, végül hogyan ellenőrizheted, hogy tényleg minden terméked él.

Röviden

• A Google Merchant API a Google Merchant Center hivatalos programozási felülete és a Content API for Shopping utódja, amelynek v1 verziója 2025 júliusában lett általánosan elérhető.
• A Content API for Shopping 2026. augusztus 18-án elérte a kivezetés dátumát, szeptember 1-jétől pedig a Google hivatalos dokumentációja szerint a hozzá érkező kérések fokozatosan egyre több hibát adnak, hosszabbítást pedig csak külön űrlapon lehet kérni.
• Nem érint a változás, ha a termékeid XML- vagy CSV-fájlból, ütemezett letöltéssel, Google Táblázatból vagy kézi feltöltéssel jutnak a Merchant Centerbe, mert ezek az útvonalak nem használják a Content API-t.
• A Shopify Google & YouTube alkalmazását használó kereskedőknek a Google szerint nincs teendőjük, a Google for WooCommerce bővítmény fejlesztői pedig augusztus 12-én megerősítették, hogy a 3.8.1-es és újabb verzió már a Merchant API-t használja.
• Egyedi fejlesztésű integrációnál, ERP-szinkronnál vagy Content API-t hívó Google Ads-szkriptnél a migráció fejlesztői munka: új végpontok, adatforrás-kezelés, új termékazonosító-formátum és mikroegységben megadott árak.
• Az átállás után mindig ellenőrizd a Merchant Centerben a termékszámot, az utolsó frissítés dátumát és a diagnosztikát, mert egy félresikerült migráció ugyanúgy elviheti a Shopping-forgalmat, mint egy elmaradt.

Mi a Google Merchant API és miért váltja le a Content API-t?

A Google Merchant API a Google Merchant Center hivatalos programozási felülete, amelyen keresztül a webshopok, feedkezelő szolgáltatások és egyedi rendszerek termékadatot, készletet, árat és fiókbeállításokat küldenek a Google-nek. A Content API for Shopping utódja, amelynek v1 verziója a Google fejlesztői oldala szerint 2025 júliusában lett általánosan elérhető.

Kezdjük az alapokkal, mert a témát sok cégvezető csak annyiból ismeri, hogy „a feed valahogy megy”. A termékfeed a webshop termékeinek géppel olvasható listája: név, leírás, ár, készlet, kép, termékoldal-link és egyedi azonosító. Ebből építi fel a Google a Shopping-hirdetéseket, a Performance Max-kampányok termékes megjelenéseit és az ingyenes terméklistázásokat. A feed a Google Merchant Centerbe érkezik, amely olyan, mint egy raktári átvételi pont: itt ellenőrzik, hogy az adatok megfelelnek-e a szabályoknak, majd innen jutnak tovább a hirdetési rendszerbe.

Egy termékfeed háromféle úton juthat be a Merchant Centerbe. Az első a fájl: a webshop XML-, CSV- vagy TSV-fájlt állít elő, amelyet a Google meghatározott időközönként letölt (ez az ütemezett letöltés, angolul scheduled fetch), vagy valaki kézzel tölt fel. A második a Google Táblázatok, amely kisebb katalógusnál működik jól. A harmadik az API (Application Programming Interface), vagyis egy szabványos csatorna, amelyen két szoftver emberi kattintgatás nélkül beszélget egymással. Az API előnye a sebesség: egy árváltozás vagy egy elfogyott termék perceken belül eljuthat a Google-höz, nem kell megvárni a következő napi letöltést. Ezért épül rá jellemzően a platformalkalmazások, a feedkezelő szolgáltatások és az ERP-integrációk jelentős része.

Ez a harmadik út volt éveken át a Content API for Shopping, amelynek utolsó verziója a v2.1 volt. A Content API kiadási jegyzetei (release notes) szerint a Google 2025. augusztus 18-án jelentette be, hogy a felületet elavultnak tekinti és 2026 augusztusában leállítja. A Merchant API ekkor már elérhető volt: a Google Merchant API frissítéseit összegző oldal szerint a v1 verzió 2025 júliusában lett általánosan elérhető, a korábbi v1beta változatot pedig 2026. február 28-án vezették ki.

Miért nem lehetett egyszerűen megtartani a régit? A Google hivatalos migrációs útmutatója szerint a Merchant API modulárisan épül fel: külön al-API felel a fiókokért, a termékekért, a készletekért, a riportokért, az adatforrásokért, a promóciókért és az értesítésekért. Ez a fejlesztőknek átláthatóbb, ráadásul az új funkciók (például a termékértékelések kezelése, az értesítések vagy a visszaküldési szabályok) már csak itt érhetők el. A Google ezért a régi felület továbbfejlesztése helyett a kivezetés mellett döntött, a hirdetőknek pedig egyértelmű határidőt szabott.

Mi változott augusztus 18-án és szeptember 1-jén?

Augusztus 18-án a Content API for Shopping hivatalosan elérte a kivezetés dátumát, a Google azóta nem támogatja. Szeptember 1-jétől a Google fejlesztői dokumentációja szerint a hozzá érkező kérések fokozatosan egyre több hibát adnak, így egy át nem állított integráció előbb akadozik, majd gyakorlatilag használhatatlanná válik.

A két dátum közötti különbség nem apróság. Augusztus 18-a a hivatalos napnyugta volt: ettől kezdve a Google semmilyen garanciát nem vállal a régi felületre, hibajavítás és támogatás nincs. A tényleges fájdalom szeptember 1-jén kezdődött, amikor a Google a saját megfogalmazása szerint „progresszív hibákat” vezetett be. A Google dokumentációja nem részletezi, milyen ütemben nő a sikertelen kérések aránya, ezért nem lehet pontosan megmondani, hogy egy adott napon egy régi integráció kéréseinek hány százaléka megy még át. A gyakorlati következtetés viszont egyszerű: szeptember második felében már senki ne építsen arra, hogy a régi csatorna „még működik valahogy”.

A Numinix 2026. szeptember 1-jei összefoglalója konkrétabb: eszerint szeptember 1-jétől a jóváhagyott hosszabbítás nélküli Content API-integrációk kérései időnként HTTP 410 Gone válasszal hiúsulhatnak meg, vagyis a szerver azt üzeni, hogy a kért erőforrás véglegesen megszűnt. A Google hivatalos Content API-oldala mindeközben egy hosszabbítási kérelmet is említ: aki több időt igényel a migrációhoz, egy erre szolgáló űrlapon kérheti a régi felület meghosszabbított használatát. Határidőt a Google nyilvános dokumentációjában nem találtunk. A Simple Product Feeds nevű feedalkalmazás fejlesztője július 27-i írásában október 15-ig tartó hosszabbításról ír, továbbá azt állítja, hogy a kérelmet a kódot üzemeltető fél nyújthatja be a Google Cloud-projekt azonosítójával, nem maga a kereskedő. Ezt a dátumot érdemes a saját fejlesztőddel ellenőriztetni, mielőtt bármit rá építenél.

A következő idővonal összefoglalja a fontos dátumokat, hogy lásd, mennyi idő állt rendelkezésre a felkészülésre:

Ami nem változott, az legalább ilyen fontos. Az XML- vagy CSV-fájlból ütemezett letöltéssel érkező feedek, a Google Táblázatból táplált adatforrások és a kézi feltöltések nem a Content API-n keresztül működnek, ezért ezeket a leállás nem érinti. A Simple Product Feeds idézett írása szerint ezek pontosan úgy működnek tovább, mint eddig. Egy magyar KKV-nál ez azért lényeges, mert ha a webshop évek óta egyszerű XML-exporttal tölti fel a termékeit, akkor a hír nyugodtan olvasható hátradőlve.

Így derítsd ki, érint-e a Google Merchant API-váltás a webshopodat

Az érintettség kizárólag azon múlik, milyen úton jutnak a termékeid a Merchant Centerbe. Ha fájlból, ütemezett letöltéssel vagy Google Táblázatból, akkor nincs teendőd. Ha platformalkalmazás, bővítmény, feedkezelő szolgáltatás vagy saját fejlesztésű integráció küldi őket API-n keresztül, akkor ellenőrizned kell, hogy az adott megoldás már a Merchant API-t használja-e.

A legbiztosabb forrás maga a Google Merchant Center. Az adatforrások listája (az angol felületen Data sources) megmutatja, milyen csatornákon érkeznek a termékeid és melyik forrás hány terméket szolgáltat. Itt láthatod, hogy egy adatforrás fájlból, ütemezett letöltésből, Google Táblázatból vagy API-n keresztül érkezik, illetve azt is, hogy mikor frissült utoljára. Ha nem vagy biztos a dolgodban, készíts képernyőképet erről az oldalról és küldd el a fejlesztődnek vagy az ügynökségednek, mert nekik ebből egy perc alatt kiderül, mi a helyzet.

Vegyünk egy képzeletbeli kecskeméti kerékpárboltot, amelynek webshopját öt éve egy szabadúszó fejlesztő állította be, a Google Shopping-kampányokat pedig azóta egy másik ügynökség kezeli. A tulajdonos nem tudja, hogyan jut a feed a Google-höz, a kampánykezelő sem látott bele a webshop kódjába, a szabadúszó pedig időközben elköltözött. Pontosan az ilyen helyzetek szülik a legtöbb meglepetést, mert mindenki azt hiszi, hogy a másik figyel. Az adatforrás-lista öt perc alatt tisztázza a kérdést, utána már csak azt kell eldönteni, kinek a feladata a javítás.

A következő táblázat a leggyakoribb útvonalakat és a hozzájuk tartozó teendőket foglalja össze:

A harmadik fél feedkezelőknél a helyzet vegyes. A Simple Product Feeds július végi összesítése szerint a Channable július 1-jén automatikusan átállította az ügyfeleit, a Feedonomics ügyfeleinek pedig nincs teendőjük, több népszerű alkalmazás viszont akkor még nem tett közzé nyilvános nyilatkozatot a migrációról. Ha egy hazai bérelhető webshopplatformot használsz, amely a saját beépített moduljával küldi a termékeket a Google-nek, akkor a legegyszerűbb, ha írásban megkérdezed az ügyfélszolgálatot, hogy a modul a Merchant API-t használja-e. Ez egyetlen e-mail, amely megspórolhat egy nagyon kellemetlen októbert.

Ha a Merchant Centerben egyetlen adatforrás sem API-alapú, akkor ezt a cikket nyugodtan olvasd háttérolvasmányként. Ha viszont legalább egy API-s forrásod van, amelynek utolsó frissítése augusztus 18. és szeptember 1. körül megállt, akkor ma kell foglalkoznod vele.

Milyen tünetei vannak, ha a termékfeed nem állt át?

Egy át nem állított API-s feed jellemző tünete, hogy a Merchant Centerben megáll a termékek frissítése, az árak és a készletadatok elavulnak, a termékek egy része elutasított vagy korlátozott állapotba kerül, később pedig lejár és eltűnik. A hirdetési fiókban ez a Shopping- és a Performance Max-megjelenések fokozatos visszaesésében látszik.

A tünetek azért alattomosak, mert nem egyik napról a másikra jelentkeznek. Egy Content API-t hívó integráció nem feltétlenül küld riasztást a tulajdonosnak, a Merchant Centerben pedig a már bent lévő termékek egy ideig tovább élnek. A folyamat inkább egy lassú szivárgáshoz hasonlít, mint egy hirtelen áramszünethez, ezért érdemes pontosan tudni, mire figyelj.

Elavuló ár és készlet

Az első jel többnyire az, hogy a webshopban megváltoztatott ár vagy készletadat nem jelenik meg a Google-nél. Tegyük fel, hogy egy képzeletbeli debreceni kerti bútorokat árusító webshop szeptember 5-én 12 990 Ft-ról 14 490 Ft-ra emeli egy napernyő árát, a feed azonban már nem tudja továbbítani a változást. A Google a termékoldal feltérképezésekor észlelheti, hogy a hirdetésben szereplő ár nem egyezik a weboldalon láthatóval. Az ilyen eltérés a Merchant Center szabályai szerint a termék elutasításához vezethet, ami a hirdetés leállását jelenti. A fordított eset sem jobb: ha egy termék elfogy, de a Google-nél még készleten lévőként szerepel, akkor olyan kattintásokért fizetsz, amelyekből nem lehet vásárlás, a vevő pedig csalódottan távozik.

A Merchant Centerben elérhető automatikus termékfrissítés funkció részben tompíthatja ezt, mert a Google a termékoldal strukturált adatai alapján képes korrigálni az árat és az elérhetőséget. Ez azonban biztonsági háló, nem megoldás: nem minden termékre és nem minden mezőre működik, új terméket pedig egyáltalán nem hoz létre.

Eltűnő termékek

A Merchant Center régóta érvényes szabálya, hogy a 30 napja nem frissített termékek lejárnak. Egy API-s integráció a termékeket rendszeresen újraküldi, így azok soha nem érik el ezt a határt. Ha viszont augusztus végén megállt a szinkron, akkor a termékek szeptember második felétől, illetve októbertől kezdve csoportosan kezdenek lejárni, a Merchant Centerben pedig csökkenni kezd az aktív termékek száma. Az új termékek eközben egyáltalán nem kerülnek fel, vagyis az őszi szezonra beérkező kollekció már meg sem jelenik a Google Shoppingban. Az utolsó frissítés dátuma ezért az egyik legfontosabb diagnosztikai adat: ha a termékeid többségénél augusztus közepe vagy vége áll ott, az szinte biztos jel.

Hibaüzenetek és elutasított kérések

Ahol van naplózás, ott a hibák is megjelennek. Egy egyedi integráció naplójában ilyenkor sorban állnak a sikertelen kérések, egy WooCommerce-bővítmény felületén hibaüzenet vagy szinkronizálási figyelmeztetés látszik, egy feedkezelő szolgáltatás pedig jó esetben e-mailben szól. A Google a progresszív hibák ütemét nem részletezi, a Numinix szerint viszont a sikertelen kérések HTTP 410 Gone választ kaphatnak, vagyis a „véglegesen megszűnt” üzenetet. Ha ilyen bejegyzéseket látsz a naplóban, vagy azt látod, hogy augusztus 18., illetve szeptember 1. után megnőtt a sikertelen kérések aránya, akkor a diagnózis egyértelmű. Ha a rendszered csendben elnyeli a hibákat (sajnos ez sem ritka), akkor csak a Merchant Center adataiból fogod észrevenni a bajt.

Visszaeső hirdetési eredmények

A marketinges a hirdetési fiókban látja meg a következményt, gyakran egy-két héttel később, mint ahogy a probléma elindult. A Shopping- és Performance Max-kampányok megjelenései csökkennek, a termékcsoportok egy része kiürül, a hirdetési költés elmarad a tervezettől, miközben a kampánybeállításokban semmi nem változott. Sokan ilyenkor az algoritmust vagy a szezont hibáztatják, aztán hetekig licitekkel, költségkerettel és célzással kísérleteznek, holott a hiba a feed csatornájában van. Ha a Shopping-forgalmad szeptember elején megmagyarázhatatlanul visszaesett, első lépésként a Merchant Center termékszámát és diagnosztikáját nézd meg, ne a kampánybeállításokat.

Content API és Merchant API: a különbségek nem fejlesztőknek

A Google Merchant API ugyanazt a feladatot látja el, mint a Content API, csak másképp szervezi az adatokat. Megváltozott a termékazonosítók formátuma, az árak megadása, a beküldött és a feldolgozott termék külön kezelése, megszűnt a kötegelt kérés, a használathoz pedig a Google Cloud-projektet regisztrálni kell a Merchant Centerben.

Nem kell fejlesztőnek lenned ahhoz, hogy értsd, miért nem egy délutáni munka egy egyedi integráció átállítása. Gondolj úgy a két API-ra, mint két különböző nyomtatványra ugyanannál a hivatalnál: a kérdések nagyjából ugyanazok, de más a rovatok sorrendje és a mértékegység, bizonyos adatokat pedig mostantól egy másik ablaknál kell leadni. A következő táblázat a Google hivatalos migrációs útmutatója és a termékek migrációjáról szóló fejlesztői oldal alapján foglalja össze a legfontosabb eltéréseket:

Az ár megadása az a pont, ahol egy nem fejlesztő is megérti, miért kell odafigyelni. A Merchant API az összegeket mikroegységben kéri, ahol egymillió mikro egy egész pénzegységnek felel meg. Egy 12 990 Ft-os napernyő ára így a Merchant API-ban 12 990 000 000 mikro, a pénznem kódja pedig HUF. Ha a fejlesztő elfelejti az átváltást, akkor a Google-höz 0,01299 Ft-os ár érkezik, ami jó esetben azonnali elutasítást, rossz esetben furcsa hirdetéseket eredményez.

A beküldött és a feldolgozott termék szétválasztása elsőre bürokratikusnak tűnik, valójában nagyon logikus. A ProductInput az, amit te küldesz: a nyers adat egy adott adatforrásból. A Product pedig a Google fejlesztői oldala szerint az a végleges termék, amely azután születik meg, hogy a Google feldolgozta a beküldött adatokat, alkalmazta a szabályokat és összefésülte a kiegészítő adatforrásokból érkező információkkal. Ha például a webshopod küldi az alapadatokat, egy külön kiegészítő feed pedig az egyedi címkéket, akkor a Product mutatja meg, mi lett a kettő összegéből. A termék státusza, a jóváhagyási problémák és a célfelületenkénti állapot is itt, a productStatus mezőben található, mert a régi, külön státuszszolgáltatás megszűnt.

A regisztrációról könnyű megfeledkezni, mert a Content API-nál nem volt ilyen lépés. A Google útmutatója szerint a Merchant API használata előtt a Merchant Center-fiókot és a Google Cloud-projektet össze kell kapcsolni egy fejlesztői regisztrációval (developerRegistration), amelyet egyetlen API-hívással lehet elvégezni. Ha ez elmarad, akkor a kód lehet akármilyen szép, a kérések nem fognak átmenni.

Hogyan állj át WooCommerce, Shopify és egyedi rendszer esetén?

WooCommerce-nél a Google for WooCommerce bővítményt kell a 3.8.1-es vagy újabb verzióra frissíteni, Shopify-nál a Google & YouTube alkalmazás használóinak a Google szerint nincs teendőjük. Egyedi fejlesztésű webshopnál, ERP-integrációnál vagy Content API-t hívó szkriptnél viszont a kódot a fejlesztőnek kell átírnia a Merchant API-ra.

Ráfordításban óriási a különbség a három helyzet között. Egy platformalkalmazásnál vagy bővítménynél a migráció terhét a fejlesztő cég viseli, neked annyi a dolgod, hogy frissen tartsd a szoftvert és ellenőrizd az eredményt. Egyedi rendszernél viszont te vagy a fejlesztő cég, vagyis a migráció a te projekted, a te költségeddel és a te határidőddel.

WooCommerce: Google for WooCommerce bővítmény

WooCommerce-nél a hivatalos megoldás a Google for WooCommerce bővítmény, amelyet korábban Google Listings & Ads néven ismertek. A bővítmény WordPress.org-os támogatási fórumán a fejlesztők 2026. június 2-án azt írták, hogy a kereskedőknek nincs kézi teendőjük, mert a Content API-ról a Merchant API-ra való átállást a bővítmény frissítései automatikusan elvégzik, ígéretük szerint jóval az augusztus 18-i határidő előtt. Augusztus 12-én megerősítették, hogy a 3.8.1-es és újabb verzió már a Merchant API-t használja.

Ugyanebben a válaszban szerepel az a részlet is, amely sok tulajdonost megzavar: a meglévő kereskedőknél a Merchant Center adatforrás-listájában akkor is „Content API” felirat maradhat, ha a bővítmény már az új API-n keresztül küldi az adatokat. A fejlesztők szerint ilyenkor csak a forrás adatai nem frissültek a felületen, a háttérben működő API már az új. Ha tehát ezt a feliratot látod, ne ess pánikba, hanem nézd meg a bővítmény verziószámát a WordPress bővítménylistájában és azt, hogy a termékek utolsó frissítése friss-e.

A gyakorlati teendők WooCommerce-nél:

• Ellenőrizd a WordPress adminfelületén a Google for WooCommerce bővítmény verziószámát, ha pedig 3.8.1-nél régebbi, frissítsd.
• Nagyobb webshopnál a frissítést először tesztkörnyezetben (staging) próbáld ki, mert a bővítmény új verziója újabb WooCommerce- és WordPress-verziót is igényelhet.
• A frissítés után nézd meg a bővítmény termékszinkronizálási felületét, hogy a termékek állapota rendben van-e, illetve látható-e szinkronizálási hibaüzenet.
• Ha nem a hivatalos bővítményt, hanem egy XML-feedet generáló bővítményt használsz, amelyet a Google ütemezett letöltéssel olvas be, akkor a leállás nem érint.
• Ha egy harmadik féltől származó bővítmény közvetlenül API-n keresztül küldi a termékeket, akkor a fejlesztőjénél ellenőrizd, hogy a Merchant API-t használja-e.

A WooCommerce frissítési kérdései külön témát érdemelnek, hiszen a 2027 januárjára tervezett WooCommerce 11.5 már nem fogja támogatni a PHP 7.4-et és a 8.0-t, ezért aki évek óta halogatja a frissítéseket, annak a feedprobléma gyakran csak a jéghegy csúcsa.

Shopify: Google & YouTube alkalmazás

A Shopify-kereskedők a legkényelmesebb helyzetben vannak. A Google hivatalos migrációs útmutatója kifejezetten kimondja, hogy aki harmadik fél technológiai partnerrel szinkronizálja a termékadatait, például a Shopify Google & YouTube alkalmazásával, annak nincs teendője, mert a szolgáltató kezeli helyette az API-migrációt.

Egy dologra azért figyelj. A Simple Product Feeds július 27-i írása szerint a Google & YouTube alkalmazás eltávolítása és újratelepítése egy hiba miatt átírhatja a termékazonosítókat, ez pedig leválaszthatja a termékeket a kampányokról és elviheti a korábbi teljesítményadatokat. Ha tehát valami furcsát látsz a feedben, ne az újratelepítés legyen az első ötleted, inkább nézd meg a Merchant Center diagnosztikáját, szükség esetén pedig kérj segítséget a Shopify támogatásától. Ha harmadik fél feedalkalmazást használsz, ugyanaz a helyzet, mint WooCommerce-nél: írásos megerősítést kérj a szolgáltatótól a Merchant API-ra váltásról.

A Shopify egyébként a Winter ’26 kiadásában az úgynevezett agentic commerce (ügynöki kereskedelem) felé is nagyot lépett: az Agentic Storefronts révén a termékek közvetlenül az AI-beszélgetésekben jelenhetnek meg. Ez külön téma, itt csak annyit érdemes megjegyezni, hogy mindkét irány ugyanabból a forrásból táplálkozik: a pontos, géppel olvasható termékadatból.

Egyedi webshop, ERP és saját integráció

A legtöbb munka ott van, ahol a termékadatot saját fejlesztésű kód küldi a Google-nek. Ilyen lehet egy egyedi PHP- vagy Laravel-alapú webshop, egy Odoo- vagy más ERP-modul, amely a raktárkészletet közvetlenül szinkronizálja, vagy egy köztes szolgáltatás, amely több csatornát szolgál ki egyszerre. Ezeknél nincs bővítményfrissítés, amely megoldaná a gondot, a kódot a fejlesztőnek kell átírnia.

A ráfordítás erősen függ attól, mit csinált a régi integráció. Ha csak termékeket küldött és frissített, akkor a migráció viszonylag jól körülhatárolható, durva becslésünk szerint 16 és 40 fejlesztői óra közé esik a tesztelésével együtt. Ha a kód készletet, helyi üzletek adatait, promóciókat, riportokat és fiókbeállításokat is kezelt, akkor ennek többszöröse is lehet, mert minden érintett területet külön al-API-ra kell átültetni. A Google útmutatója a migrációt tíz lépésre bontja a hitelesítéstől a fiókkezelésen és a termékeken át a készletekig és a promóciókig, ami jól mutatja a feladat szerkezetét.

Aki most, szeptember második felében szembesül azzal, hogy az egyedi integrációja nem állt át, annak két párhuzamos teendője van. Az egyik a gyors áthidalás: amíg a migráció elkészül, a termékeket egy ideiglenes XML-feeddel is be lehet juttatni a Merchant Centerbe ütemezett letöltéssel, ha a webshop képes ilyet előállítani. Ennél ügyelni kell arra, hogy az ideiglenes feed ugyanazokat a termékazonosítókat használja, mint a régi, különben a Google új termékeknek tekinti őket. Azt is tudni kell, hogy ha egy termék ugyanazzal a kulccsal egy másik elsődleges adatforrásba érkezik, azt a Google a buktatóknál tárgyalt offer stealing esetének tekinti, ezért az áthidalást és a későbbi visszaállást a fejlesztővel együtt, tudatosan kell megtervezni. A másik a tényleges migráció, amely nem maradhat el, mert az ideiglenes fájlos megoldás lassabb frissítést és kevesebb funkciót jelent.

Google Ads-szkriptek

Ha a PPC-szakembered vagy az ügynökséged Google Ads-szkriptekkel dolgozik, kérdezz rá, hogy van-e olyan szkript, amely a régi Shopping Content szolgáltatást használja. A PPC Land szerint a Merchant API április 22-től haladó API-ként érhető el a szkriptszerkesztőben, a régi szolgáltatásra épülő szkripteket tehát erre érdemes átírni, hiszen a Content API kivezetése őket is érinti. Egy szkript átírása jellemzően kisebb munka, mint egy teljes integrációé, de ha senki nem figyel rá, csendben hibára fut, a tőle várt automatikus riasztások vagy címkézések pedig egyszerűen elmaradnak.

Lépésről lépésre: egyedi integráció átállítása a Google Merchant API-ra

Egy egyedi integráció átállítása tíz jól elkülöníthető lépésből áll: a régi kód leltárától a hitelesítésen, az adatforrások és az azonosítók átalakításán át a tesztelésig és a folyamatos figyelésig. A sorrend a Google hivatalos migrációs útmutatójának logikáját követi, amely az indulás és a hitelesítés után a fiókokon és a termékeken át halad a készletek és a promóciók felé. A listát érdemes a fejlesztőddel közösen átnézni, mert így könnyebb felmérni, reális-e egy árajánlat.

• Leltár a régi kódról. Gyűjtsétek össze, a régi integráció milyen Content API-szolgáltatásokat hívott: termékek, termékállapotok, készletek, fiókok, riportok, kötegelt kérések. Ebből derül ki, mely al-API-kra lesz szükség.
• Google Cloud-projekt és fejlesztői regisztráció. A Google útmutatója szerint a Merchant Center-fiókot és a Google Cloud-projektet a developerRegistration registerGcp hívással kell összekapcsolni, ezután következik a hitelesítés beállítása a Merchant Centerből.
• Adatforrás kiválasztása vagy létrehozása. Minden termékírási művelethez kötelező megadni az adatforrást. A Google azt javasolja, hogy az adatforrás nevét egyszer mentsétek el a saját adatbázisotokba, ne minden művelet előtt kérdezzétek le.
• Azonosítók átalakítása. A kettőspontos formátumból hullámvonalas lesz, a csatorna kikerül belőle, a célország helyére a feedcímke (feedLabel) lép. Ha a termékazonosító speciális karaktert tartalmaz, a Google útmutatója szerint kötelező a base64url kódolás.
• Az adatmodell átírása. A termékadatok a productAttributes csoportba kerülnek, az árak mikroegységbe, az elérhetőséghez hasonló mezők előre rögzített értékkészletre.
• A kötegelt kérések kiváltása. A Merchant API nem ismeri a customBatch metódust, ezért a kódot párhuzamos vagy aszinkron kérésekre kell átszervezni. Ez nagy katalógusnál teljesítménykérdés is.
• Az írás és az olvasás szétválasztása. Íráshoz a productInputs, a feldolgozott termék és a státusz lekérdezéséhez a products erőforrás kell. A státuszfigyelő részeket is át kell írni, mert a régi státuszszolgáltatás megszűnt.
• Készlet, promóció és riport. Ha a régi kód helyi vagy regionális készletet, promóciót vagy riportokat kezelt, ezeket is a megfelelő al-API-ra kell átültetni, különben a termékadat frissül, a helyi készlet vagy a promóció viszont nem.
• Tesztelés néhány terméken. Először tíz-húsz terméket küldjetek be, majd hasonlítsátok össze a beküldött adatot a Google által feldolgozott termékkel. Ellenőrizzétek az árat, a pénznemet, az azonosítót és az adatforrást.
• Élesítés és figyelés. Az élesítés után legalább két hétig naponta nézzétek a hibanaplót és a Merchant Center diagnosztikáját, állítsatok be riasztást a sikertelen kérések arányára, végül távolítsátok el a régi Content API-hívásokat a kódból.

Tipikus migrációs buktatók és hogyan kerüld el őket

A Merchant API-migráció tipikus hibái az adatok apró részleteiben rejlenek: rossz nagyságrendű ár, hiányzó vagy téves adatforrás, megváltozott termékazonosító, kódolatlan speciális karakter. Ezek egy része nem okoz látványos hibaüzenetet, csak csendben rontja a feed minőségét és a hirdetések teljesítményét.

• Mikroegység-tévedés az áraknál. A 12 990 Ft-os termék helyes értéke 12 990 000 000 mikro. Ha a fejlesztő kétszer szoroz vagy egyszer sem, akkor a hirdetésben irreális ár jelenhet meg, vagy a Google elutasítja a terméket az ár eltérése miatt.
• Hiányzó vagy téves adatforrás. A Google útmutatója szerint minden termékírási művelethez kötelező a dataSource paraméter. Ha a kód rossz adatforrásba ír, a termék duplikálódhat vagy összeakadhat egy másik forrással.
• Offer stealing. A Google meghatározása szerint ez akkor fordul elő, amikor egy termék az egyedi kulcsa (nyelv, feedcímke, termékazonosító) alapján egy másik elsődleges adatforrásba kerül, mint amelyikhez tartozik. A Google javaslata az, hogy frissítés előtt egy lekérdezéssel ellenőrizzétek, melyik adatforráshoz tartozik a termék.
• Megváltozó termékazonosító. Ha a migráció közben megváltozik a termékazonosító vagy a feedcímke, a Google új termékként kezeli a tételt, a régi pedig lejár. Ezzel elveszhet a termék hirdetési előzménye, amely a kampányok optimalizálásában sokat számít.
• Speciális karakterek a cikkszámban. A Google útmutatója szerint ha a termék azonosítója (az API-ban a termék erőforrásneve) olyan karaktert tartalmaz, mint a perjel, a pont, a kettőspont, a hullámvonal vagy a kérdőjel, akkor kötelező a base64url kódolás. Egy POLC/120 vagy ASZ.2024 típusú cikkszám tehát különleges kezelést igényel.
• Helyi termékek jelölése. A régi channel mező megszűnt, ezért a helyi üzletben kapható termékeknél a legacy_local jelzőt kell beállítani, különben ezek nem a várt módon jelennek meg a Google felületein.
• Türelmetlen visszaolvasás. A beküldött adatból a Google-nek idő kell a feldolgozott termék előállításához, a dokumentáció pedig nem ad meg pontos időtartamot. Ha a kód a beküldés után azonnal visszaolvassa a terméket és hibát jelez, mert még nem látja, akkor fals riasztásokat kapsz, amelyek elaltatják a figyelmet a valódi hibákkal szemben.

Hogyan győződj meg róla, hogy minden termék él?

Az ellenőrzéshez három dolgot kell összevetned: a Merchant Centerben aktív termékek számát a webshop hirdethető termékeinek számával, az adatforrások utolsó frissítésének dátumát, valamint néhány kiválasztott termék árát és készletét a webshopban és a Google-nél. Ha mindhárom rendben van, a feed él.

Az ellenőrzés nem igényel fejlesztői tudást, egy marketinges vagy maga a tulajdonos is elvégezheti egy óra alatt. A lényeg az, hogy ne egyetlen jelre hagyatkozz, mert a „nincs hibaüzenet” még nem jelenti azt, hogy minden rendben van. A következő ellenőrzőlistát érdemes most egyszer alaposan végigmenni, utána pedig két hétig hetente megismételni:

A szúrópróbánál érdemes tudatosan választani. Vegyél egy népszerű terméket, egy olyat, amelynek nemrég változott az ára, egy frissen feltöltött újdonságot, egy elfogyott terméket és egy olyat, amelynek a cikkszámában speciális karakter szerepel. Ez az öt eset lefedi a leggyakoribb hibaforrásokat: ha az árváltozás átment, a szinkron él, ha az újdonság megjelent, a termékfelvétel működik, ha az elfogyott termék nem szerepel készleten lévőként, a készletadat is frissül.

API-s feednél hasznos egy kontrollált próba is. Tegyük fel, hogy van egy kevésbé fontos terméked, amelynek az árát egy napra minimálisan módosíthatod. Változtasd meg a webshopban, majd figyeld meg, mennyi idő alatt jelenik meg az új ár a Merchant Center termékadatai között. Ha a változás rövid időn belül átér, a csatorna működik. Ha egy nap múlva sincs nyoma, akkor a szinkron valahol elakad, még akkor is, ha a felületen semmilyen hibaüzenet nem látszik. A próba után ne felejtsd el visszaállítani az eredeti árat.

A hirdetési oldalt a Google Ads-fiókban a termékszintű jelentés mutatja meg a legjobban. Ha a korábban rendszeresen megjelenő termékek egy része szeptember eleje óta nulla megjelenést hoz, miközben a kampány beállításai nem változtak, az erős jel arra, hogy ezek a termékek kiestek a feedből vagy elutasított állapotba kerültek. Ilyenkor a Merchant Center diagnosztikájában termékenként megnézheted az okot, amelyből általában kiderül, hogy ár-, készlet- vagy lejárati problémáról van-e szó.

Mennyibe kerül, ha csúszik a migráció?

Egy csúszó migráció költsége a kieső Shopping-bevételből és a rossz adatokra elköltött hirdetési pénzből áll össze, ami egy közepes webshopnál már két hét alatt könnyen meghaladhatja magának a migrációnak az árát. Fájlalapú feednél nincs ilyen kockázat, API-s integrációnál viszont a halogatás a drágább út.

Nézzünk egy egyszerű, szemléltető számítást. Vegyünk egy képzeletbeli debreceni kerti bútorokat árusító webshopot, amely havonta 900 000 Ft-ot költ Shopping- és Performance Max-hirdetésekre, átlagosan ötszörös hirdetési megtérüléssel (ROAS, vagyis minden elköltött forintra öt forint bevétel jut). Ez havi 4,5 millió Ft, napi nagyjából 150 000 Ft hirdetésből származó bevételt jelent.

Tegyük fel, hogy az egyedi integráció szeptember elején elakad, a termékek fele néhány napon belül elutasított állapotba kerül (például mert az áruk már nem egyezik a webshopéval), a probléma pedig csak két hét múlva derül ki. Ha egyszerűsítve azt feltételezzük, hogy a kieső termékek hozták a bevétel felét, akkor 14 nap alatt 14 × 75 000 Ft, azaz 1 050 000 Ft bevétel marad el. Harmincszázalékos fedezettel számolva ez körülbelül 315 000 Ft elmaradt fedezet, amelyben még nincs benne az elfogyott termékekre elköltött kattintások ára, illetve a csalódott vásárlók.

Ezzel szemben egy egyszerű termékszinkron migrációja a korábbi becslésünk szerint 16 és 40 fejlesztői óra között van. Egy feltételezett 12 000 Ft-os óradíjjal számolva ez 192 000 és 480 000 Ft közötti egyszeri kiadás. A két szám nagyságrendje hasonló, csakhogy a kiesés minden héttel nő, a migráció költsége viszont nem, ráadásul egy lejárt termék visszahozása és a kampány újratanulása maga is időbe telik. A tanulság egyszerű: az a cég, amelyik API-n keresztül küldi a termékeit, ne várja meg, amíg a hirdetési fiók jelez.

Mit ad a Google Merchant API a kötelező átálláson túl?

A Google Merchant API olyan funkciókat is kínál, amelyek a Content API-ban nem voltak meg: értesítéseket a fiók- és termékadatok változásairól, termék- és kereskedőértékelések kezelését, hibaelhárítási segítséget, visszaküldési szabályok beállítását, 2026-ban pedig az AI-alapú vásárlást támogató új termékattribútumokat és egy MCP-szolgáltatás alfa verzióját.

A Google hivatalos migrációs útmutatója ezek mellett az omnichannel beállítások kezelését és a Google Cégprofil-fiókok összekapcsolását is az új API kizárólagos funkciói között sorolja fel. Egy magyar webshopnak ezek közül az értesítések a leghasznosabbak, mert a rendszer azonnal jelezhet, ha egy termék státusza megváltozik, nem kell rendszeresen lekérdezni az összes terméket.

A Merchant API frissítéseit összegző oldal szerint 2026 májusában új, beszélgetéshez igazított termékattribútumok jelentek meg: kérdés és válasz (question_and_answer), dokumentumlink (document_link), kapcsolódó termék (related_product), termékcsoport-cím (item_group_title), változatopció (variant_option) és népszerűségi sorrend (popularity_rank). Ugyanebben a hónapban indult el a Merchant API MCP-szolgáltatásának alfa verziója, amely a Google leírása szerint engedélyezett hozzáférést ad a Merchant Center adataihoz és elemzéseihez, elsősorban olvasási céllal. Augusztusban pedig megjelent a returns attribútum, amellyel termékenként felülírható a visszaküldési szabály.

Ezek az újdonságok abba az irányba mutatnak, amelyet a Google AI Mode és a Shopify agentic commerce kezdeményezése is jelez: a vásárlás egyre inkább AI-asszisztensekkel folytatott beszélgetésekben kezdődik. A Numinix 2026. szeptember 1-jei összesítése szerint az AI Mode havi felhasználóinak száma már egymilliárd fölött van. Egy termék, amelyhez gyakori kérdések és válaszok, kapcsolódó termékek és pontos változatadatok tartoznak, egy ilyen beszélgetésben nagyobb eséllyel kerül elő. Ehhez viszont először az kell, hogy a feed egyáltalán működjön, vagyis a Merchant API-ra való átállás az alap, amelyre minden további fejlesztés épül.

Miben segít a Convergo?

Ha nem tudod biztosan, hogyan jut a termékfeeded a Google-höz, vagy szeptember óta furcsán viselkedik a Shopping-forgalmad, szívesen átnézzük veled a Merchant Center adatforrásait és a hirdetési fiókot. Webshop és online értékesítés szolgáltatásunk keretében ellenőrizzük és rendbe tesszük a WooCommerce- vagy egyedi webshopod Google-kapcsolatát, egyedi fejlesztésű vagy Odoo-alapú rendszereknél pedig programozás és egyedi fejlesztés keretében elvégezzük a Merchant API-migrációt (10 000 Ft/óra). A Google Ads és Meta kampánykezelés csapatunk közben figyeli, hogy a Shopping- és Performance Max-kampányok visszanyerjék a megjelenéseiket. Az első lépés egy ingyenes egyeztetés, ahol megnézzük, érint-e egyáltalán a változás.