Google Merchant Center feed leggyakoribb hibái és javításuk

Scheo · 2026-08-27 · Frissítve: 2026-11-01 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A Merchant Center feed az a pont, ahol a webshop adatbázisa és a Google hirdetési rendszere találkozik. Ha itt hibázik valami, a termék kiesik a Shopping felületekről, a Performance Max kampány pedig ugyanabból a keretből kevesebb terméket tud mozgatni. A magyar webshopoknál nagyjából ugyanaz az öt hibatípus tér vissza újra és újra, és mindegyiknek megvan a maga javítási helye: a webshop, a feedgenerátor vagy a Merchant Center fiókbeállítás.

Az alábbiakban végigveszem mind az ötöt: mi az oka, hol nyúlsz hozzá, és nagyjából mennyi idő, amíg a javítás után a termék visszakerül a jóváhagyottak közé. A cikk végén találsz egy havi ellenőrzőlistát, egy rövid gyakorlatot arra, hogyan előzd meg a hibákat ott, ahol keletkeznek, a termékadatok forrásánál, és egy leírást a feed mindennapi kezeléséről. A megállapításoknál jelölöm, mi hivatalos dokumentációból származik, mi a saját tapasztalatom, és mi szakmai feltételezés.

Kinek a dolga valójában a feed karbantartása?

Rövid válasz: a termékadatok gazdájáé. A feed a terméktörzs gépi kivonata, ezért ha a hirdetéskezelő foltozza, a hiba forrása érintetlen marad, és a következő automatikus importnál visszatér.

Tovább a témában: Termékcím felépítése a Merchant Center feedben · AI SEO webáruházaknak

Saját tapasztalat: a legtöbb magyar webshopnál ez a felelősség senkihez nincs hozzárendelve. A termékfeltöltő kolléga azt hiszi, hogy a hirdetéskezelő figyeli a feedet, a hirdetéskezelő pedig azt, hogy a termékadatok a webshopban rendben vannak. Így keletkezik az az állapot, amikor több száz termék hónapok óta elutasított, és senki nem néz rá.

Praktikusan ez azt jelenti, hogy a Merchant Center Diagnosztika (Diagnostics) nézetéhez annak kell hozzáférést kapnia, aki a termékeket felviszi. Neki olvasási jog kell a fiókra, hirdetési jogosultság nélkül, és egy heti vagy havi rutin, amiben ránéz. A javítás nagy része amúgy is az ő kezében van:

• a cikkszám, a márkanév és a GTIN a terméktörzsben keletkezik,
• a készletállapot a raktárkezelésből jön,
• a képet a termékfeltöltő tölti fel,
• a hirdetéskezelő ezekhez legfeljebb hozzáfér, de nem ő állítja elő őket.

Miért utasítja el a Google a terméket hiányzó azonosító miatt?

Rövid válasz: mert azonosító nélkül nem tudja a terméket a saját katalógusához kötni, így nem tud árat és jellemzőket összehasonlítani más ajánlatokkal.

Hivatalosan igazolt: a Google terméktámogatási dokumentációja szerint a márkás, gyártói vonalkódos termékeknél a gtin és a brand attribútum megadása elvárt, egyedi kézműves vagy saját gyártású termékeknél viszont az identifier_exists attribútum no értékre állításával jelezheted, hogy nincs ilyen azonosító. A mpn (gyártói cikkszám) a gyártói azonosítót viszi be, a feed saját id mezője pedig a te belső kulcsod, aminek stabilnak kell maradnia.

Egy tipikus feedsor váza így néz ki:

<g:id>SKU-10432</g:id>
<g:brand>Gyártó Kft.</g:brand>
<g:gtin>5998123456789</g:gtin>
<g:mpn>GY-10432-BK</g:mpn>

Hol javítod: a webshopban, a termékadatlapon. A feedgenerátor csak akkor tud GTIN-t kiírni, ha van hol felvenni. Ha a webshop sablonjában nincs GTIN mező, azt a fejlesztőnek kell hozzáadnia, és utána a feedgenerátor leképezésénél (mapping) hozzárendelni. Fiókbeállításban ezt nem lehet megkerülni.

Saját tapasztalat: a leggyakoribb rejtett hiba az ismétlődő vagy változó id, ez még a hiányzó GTIN-nél is többször okoz gondot. Ha a webshop újragenerálja a belső azonosítót minden termékmódosításnál, a Google minden importnál új terméknek látja a régit, és a felhalmozott teljesítménytörténet elvész. Ellenőrizd, hogy az azonosító a termék teljes élettartama alatt változatlan marad-e.

Az ellenőrzés egyszerű. Mentsd le a feedet, módosíts egy tesztterméknél egy apró adatot a webshopban, futtasd újra a generálást, majd hasonlítsd össze a két fájlban a termék id értékét. Ha a kettő eltér, az azonosítót a fejlesztőnek a cikkszámhoz vagy más állandó mezőhöz kell kötnie.

Miért tér el az ár az oldal és a feed között?

Rövid válasz: az eltérés mögött szinte mindig időzítési, áfa- vagy akciókezelési különbség áll a webshop és a feedgenerátor között, az elgépelés ritka.

A Google robotja megnyitja a terméklapot, kiolvassa a strukturált adatot vagy a látható árat, és összeveti a feedben szereplő értékkel. Ha a kettő nem egyezik, a termék elutasításra kerül vagy figyelmeztetést kap. A gyakori okok sorrendben:

1. Gyorsítótár. A feedgenerátor éjszaka fut, az akció reggel indul. A feedben a régi ár marad egy napig.
2. Áfa-kezelés. A magyar webshopok egy része nettó árat tárol, és a feedbe is nettó kerül, miközben az oldalon bruttó látszik. A lakossági feedbe bruttó árnak kell kerülnie.
3. Akciós ár rossz mezőben. Az eredeti ár a price, az akciós a sale_price. Ha az akciós árat írod a price mezőbe, és az akció lejár, azonnal eltérés lesz.
4. Ügyfélcsoportos vagy bejelentkezés utáni ár. A Google a kijelentkezett látogató árát látja. Ha csak regisztráció után látszik a valós ár, az eltérésnek minősül.
5. Devizás megjelenítés. Ha az oldal automatikus árfolyamváltással dolgozik, a feed pénzneme és az oldalé elválhat.

Hol javítod: az első és a harmadik esetet a feedgenerátorban (gyakoribb frissítés, helyes mezőleképezés), a másodikat és a negyediket a webshopban, az ötödiket a Merchant Center pénznem- és országbeállításánál. Saját tapasztalat: ha napi többször változik az árazás, érdemes a Merchant API (a Content API for Shopping utódja) vagy a kiegészítő feed használatát megnézni, mert a napi egyszeri teljes import ilyen tempónál mindig le fog maradni.

Így keresd meg az ár-eltérés okát

1. Nyisd meg az érintett terméklapot inkognitó ablakban, és írd fel a látható árat.
2. Keresd meg ugyanezt a terméket a feedfájlban az id alapján, és nézd meg a price és a sale_price értékét.
3. Nézd meg a terméklap forráskódjában a Product és Offer strukturált adatot. Az itt szereplő árnak is egyeznie kell a látható árral.
4. Hasonlítsd össze a feed utolsó generálásának idejét az árváltozás idejével. Ha az árváltozás a későbbi, időzítési hibát találtál.

Mikor lesz rossz az elérhetőségi állapot?

Rövid válasz: akkor, ha a feed készletadata és a terméklapon látható állapot nem ugyanabból a forrásból származik.

Az availability mező elfogadott értékei az in_stock, az out_of_stock, a preorder és a backorder (hivatalosan igazolt, a Google terméktámogatási leírása szerint). A hiba jellemzően úgy néz ki, hogy a feed készleten lévőnek jelöl egy terméket, a terméklapon viszont ott a felirat, hogy elfogyott, vagy hiányzik a kosárba tevés gombja.

Ennek három tipikus forrása van. Az első a késleltetett import: a raktárkészlet a nap folyamán nullázódik, a feed viszont csak éjjel frissül. A második a rendelésre kapható termékek kezelése, ahol a webshop szövegesen jelzi a hosszú szállítási időt, de a feed in_stock értéket kap, holott a backorder lenne pontos. A harmadik a változat-szintű készlet: az L-es méret elfogyott, de a feed a szülőtermék készletét írja ki minden változathoz.

Hol javítod: elsősorban a webshopban és a feedgenerátorban. A Merchant Center oldalán van egy segédeszköz, az automatikus elérhetőségfrissítés, amely a terméklap alapján korrigálja az állapotot, de ezt csak biztonsági hálónak érdemes tekinteni. Szakmai feltételezés: a tartósan pontatlan készletjelzés a fiók egészének megítélésére is hatással lehet, mert a Google a felhasználói élményt védi, ezért a stabilan pontos adat hosszabb távon is kifizetődő.

Milyen szállítási adat hiányzik a leggyakrabban?

Rövid válasz: a fiókszintű szállítási beállítás, ami az egész országra érvényes. A terméksoros szállítási költség ehhez képest ritkábban hiányzik.

A Google Shopping magyar felületén a szállítási díj megjelenítése elvárás. Ha se fiókszinten, se a feedben nincs szállítási adat, a termékek figyelmeztetést kapnak, és bizonyos felületekről kimaradhatnak. A gyakorlati sorrend a következő:

• Fiókszintű szállítási szolgáltatás a Merchant Center beállításai között: itt adod meg az országot, a kézbesítési időt és a díjszabást. Ezt egyszer állítod be, és minden termékre érvényes.
• Termékszintű felülírás a shipping attribútummal: csak akkor kell, ha egyes termékeknél eltér a szabály (például terjedelmes áru vagy raklapos szállítás).
• Súly és méret (shipping_weight, shipping_length): ha súlyalapú a díjszabás, ezek nélkül a rendszer nem tud számolni.
• Kézbesítési idő: a feldolgozási és a szállítási nap külön mező, és a hétvégéket is kezelni kell.

Hol javítod: a legtöbb esetben a Merchant Center fiókbeállításban. Saját tapasztalat: a magyar webshopok jelentős részénél a szállítási költség logikája bonyolultabb annál, hogy pontosan leképezhető legyen (súlyhatárok, csomagpont, utánvét-felár, ingyenes szállítás értékhatár felett). Ilyenkor a legrosszabb megoldás a beállítás elhagyása. Egy közelítő, de kicsit felfelé kerekített szabály jobb, mint a hiányzó adat, mert így a vásárló nem talál drágábbat a kosárban, mint amit a hirdetésben látott.

Miért utasítja el a Google a képet?

Rövid válasz: mert vagy technikailag nem felel meg (méret, formátum, elérhetőség), vagy promóciós elemet tartalmaz, ami a Shopping felületen nem megengedett.

Hivatalosan igazolt: a Google képkövetelményei szerint a nem ruházati termékeknél legalább 100x100, ruházatnál legalább 250x250 képpont az elvárás, a felbontás nem haladhatja meg a 64 megapixelt, a fájl mérete pedig a 16 megabájtot. Tilos a vízjel, a promóciós felirat (például akciót jelző matrica), a helykitöltő kép és a kép körüli felesleges keret.

A gyakorlatban ezek a leggyakoribb okok:

• Akciós matrica ráégetve a képre. A magyar webshopoknál ez a leggyakoribb elutasítási ok, amit látok. A megoldás a matrica CSS-rétegre helyezése, így a jelzés megmarad az oldalon, de nem kerül bele a képfájlba.
• Nem elérhető kép URL. A robot nem tudja letölteni, mert a szerver blokkolja, a kép bejelentkezés mögött van, vagy a hivatkozás lejáró tokent tartalmaz.
• Helykitöltő kép. A logót vagy a hamarosan érkezik feliratú képet a rendszer elutasítja.
• Túl kicsi vagy erősen tömörített kép. A listaoldali bélyegkép URL-je kerül a feedbe a nagyfelbontású helyett.

Hol javítod: a webshopban (kép feltöltése, matrica leválasztása), a feedgenerátorban (melyik kép URL kerül ki), és ritkábban a szerver oldalán (robotok blokkolása). Ha a képet blokkolja a tűzfal, engedélyezni kell a Googlebot hozzáférését a képkönyvtárhoz.

Mennyi idő, amíg a javítás után jóváhagyják a terméket?

Rövid válasz: a szokásos menet néhány óra és három munkanap között mozog, és ez több lépcső összege.

Hivatalosan igazolt: az új vagy módosított termékek felülvizsgálata a Google leírása szerint jellemzően néhány munkanapot vesz igénybe. Saját tapasztalat alapján a lépcsők így néznek ki: a feed újbóli beolvasása az ütemezés szerint történik (napi egyszer, ha nem állítottad át, vagy azonnal, ha kézzel elindítod a lekérést), az automatikus ellenőrzés általában néhány órán belül lefut, a kézi felülvizsgálatot igénylő esetek (jellemzően a képes és a szabályzati kifogások) pedig hosszabbak lehetnek.

A gyorsítás egyetlen legális módja, hogy nem vársz a következő ütemezett importra: a Merchant Center felületén elindítod a feed azonnali lekérését. Fontos, hogy a javítás után ne javítgasd tovább ugyanazt a mezőt naponta, mert az újraindítja a folyamatot. Fiókszintű felfüggesztésnél a menet más: ott a felülvizsgálat kérése előtt az összes megjelölt problémát rendezni kell, és a soron kívüli újbóli kérés általában nem javít a helyzeten.

Hogyan néz ki egy működő havi ellenőrzőlista?

Ez a lista nagyjából fél óra havonta, és a tapasztalatom szerint többet ér, mint egy negyedéves nagytakarítás, mert a hibákat még kicsi korukban fogja meg.

1. Nyisd meg a Merchant Center Diagnosztika nézetét, és nézd meg az elutasított termékek számának változását az előző hónaphoz képest.
2. Vesd össze a feedben szereplő termékek számát a webshop aktív, publikus termékeinek számával. A nagy eltérés mindig szűrési hibára utal.
3. Válassz ki véletlenszerűen öt terméket, és nyisd meg a terméklapjukat: egyezik-e az ár, a készlet és a szállítási idő azzal, amit a feed mond?
4. Ellenőrizd a legutóbbi feedlekérés időbélyegét. Ha régebbi két napnál, a beolvasás valamiért elakadt.
5. Nézd át a figyelmeztetéseket, ne csak az elutasításokat. A figyelmeztetés a jövő havi elutasítás.
6. Ellenőrizd a GTIN-lefedettséget: hány terméknél hiányzik, és ezek tényleg egyedi termékek-e.
7. Nézd meg, hogy az akciós termékeknél a sale_price mező van-e használatban.
8. Ellenőrizd a fiókszintű szállítási beállítást, különösen ha időközben változott a díjszabásod.
9. Futtass egy gyors képellenőrzést a hónapban felvitt új termékekre, kiemelten a promóciós feliratokra.
10. Írd fel egy megosztott dokumentumba, mit javítottál, mert a visszatérő hibák mintázata megmutatja, hol romlik el a forrás.

Hogyan előzöd meg a hibákat a termékadatok forrásánál?

Rövid válasz: úgy, hogy a hiányos termékadat már a felvitelnél sem tud továbbmenni, tehát a szabályt a webshop kényszeríti ki, és nem az emberi figyelemre bízod.

A gyakorlati lépések, fontossági sorrendben:

• Kötelező mezők a termékfelvitelnél. Márkanév, GTIN vagy annak hiányát jelző kapcsoló, legalább egy nagyfelbontású kép, kategória. Ha a mező kötelező, nem lehet elfelejteni.
• Egyetlen árforrás. A feedbe menő ár ugyanabból az adatmezőből jöjjön, mint az oldalon megjelenő, és az akciót ugyanaz a mechanizmus kezelje.
• Készlet-szinkron változat szinten. Minden változatnak saját sora és saját készletállapota legyen.
• Kép-előírás a feltöltőnek. Rövid, egyoldalas belső szabály: fehér vagy semleges háttér, nincs ráégetett szöveg, minimális méret, egységes fájlnévadás.
• Termékadat-gazda kijelölése. Egy név, aki felel a listáért, és aki hozzáfér a Merchant Centerhez.
• Beviteli minta a beszállítói adatokra. Ha a beszállítói táblázatból importálsz, a fogadó sablon írja elő a szükséges oszlopokat.

Szakmai feltételezés: ahogy a vásárlási folyamat a gépi olvasás felé mozdul (ajánlórendszerek, AI-alapú vásárlási asszisztensek), a strukturált termékadat pontossága valószínűleg a Shopping hirdetéseken kívül több más felületen is számít majd. Ez önmagában még nem jelent előnyt, de az a webshop, amelyik a feedjét rendben tartja, jó eséllyel kevesebb munkával tud majd új felületekre csatlakozni. A tiszta termékadat egyébként is olyan befektetés, ami a saját keresőnek, az árösszehasonlítóknak és a piactereknek is ugyanúgy hasznos.

Mit jelent a Google Merchant Center feed kezelés a gyakorlatban?

Rövid válasz: a Google Merchant Center feed kezelés négy ismétlődő munkából áll. Beállítod, honnan és milyen gyakran érkezik a termékadat, a mezőket a Google specifikációjára képezed le, figyeled a hibákat, és a javítást a forrásnál végzed el.

Hivatalosan igazolt: a Merchant Center jelenlegi felületén a feedek adatforrásként (Data sources) szerepelnek, a termékadat pedig érkezhet feltöltött vagy ütemezetten lekért fájlból, Google Táblázatból vagy API-n keresztül. A fő adatforrás mellé kiegészítő adatforrást is köthetsz. A menüpontok neve időnként változik, ezért ha a leírás és a felületed eltér, a Merchant Center Súgó aktuális oldala a mérvadó.

Egy új vagy elhanyagolt fiók rendbetételénél ezt a sorrendet követném:

1. Írd össze, hány adatforrás él a fiókban, és melyik honnan frissül. A régi, elfelejtett forrás duplikált termékeket okozhat.
2. Állítsd be a lekérés gyakoriságát az ár- és készletváltozás tempójához.
3. Ellenőrizd a mezőleképezést legalább az id, title, price, availability, image_link, brand és gtin mezőknél.
4. Rendezd a hibákat érintett termékszám szerint, és a legtöbb terméket érintővel kezdd.
5. Jelöld ki, ki nézi a Diagnosztika nézetet, és milyen gyakran.

Saját tapasztalat: a kiegészítő feed jó eszköz arra, hogy a fő feed módosítása nélkül adj hozzá mezőt, például a kampánybontáshoz használt custom_label_0 értékét. Egyszerű Google Táblázat is elég hozzá, ahol az első oszlop a termék id értéke, a második a címke. Elírt GTIN-t vagy rossz árat viszont ne így javíts, mert a hiba a webshopban megmarad, és a két adat a következő változásnál újra szétcsúszik.

Milyen eszközzel érdemes kezelni a Google Merchant Center feedet?

Rövid válasz: a legtöbb webshopnak a saját rendszeréhez illő feedgenerátor elég. Külön feedkezelő eszköz akkor éri meg, ha több csatornára adsz át termékadatot, vagy a webshop kimenetét nem tudod a forrásban rendbe tenni.

A választást a saját tapasztalatom szerint három dolog dönti el: a termékszám, az árváltozás tempója és a csatornák száma.

• Webshop-bővítmény vagy beépített feedgenerátor. Az alapeset. Ellenőrizd, hogy kezeli-e a változatokat, a sale_price mezőt és az egyedi GTIN mezőt.
• Google Táblázat. Pár tucat, ritkán változó terméknél működik, kézi karbantartással. Automatikus készletfrissítés nélkül hamar elavul.
• Külső feedkezelő eszköz. Akkor hasznos, ha ugyanazt az adatot Google-re, Metára és árösszehasonlítókra is át kell alakítanod. Az adatminőségi hibát ez is csak elfedi, ezért a szabályokat tartsd rövid listán, és írd le, melyik miért él.
• API-kapcsolat. Sok termék és napon belül többször változó ár vagy készlet esetén jöhet szóba. A Content API for Shopping utódja a Merchant API, ezért új fejlesztést erre érdemes építeni, és előtte fejlesztővel felméretni a karbantartási igényt.

Szakmai feltételezés: a Merchant Center a webshop oldalairól is ki tud olvasni termékadatot, ez az elindulást könnyíti meg, de akciós időszakban vagy gyakori készletváltozásnál önmagában kevésnek tartom. Rendszeres hirdetésnél maradj az ellenőrizhető, ütemezett adatforrásnál.

Források és további olvasnivalók

Az itt hivatkozott hivatalos követelmények és mezőnevek az alábbi forrásokból származnak, ezek a mérvadóak, ha ellentmondást találsz:

• Google Merchant Center Súgó (termékadat-specifikáció, elérhetőségi és árattribútumok, adatforrások)
• Google Shopping hirdetési szabályzatok (Shopping ads policies)
• Google Merchant Center képkövetelmények (image requirements)
• Google Search Central dokumentáció (strukturált adat, Product és Offer típusok)
• Schema.org: Product, Offer, AggregateOffer típusdefiníciók
• Google Content API for Shopping és Merchant API fejlesztői dokumentáció