A séma, amelyet a webshopod kihagy: returnPolicyCountry és szállítási adatok az MI-nek

2026 márciusától a returnPolicyCountry mező kötelező a visszaküldési sémában, és a Google megtagadja a visszaküldési szalagjegyet minden olyan webshoptól, amely kihagyja. De ez csak a jéghegy csúcsa: a Product és Offer struktúra — amelybe a visszaküldési és szállítási adatok beágyazódnak — ma az egyetlen közös nevezője minden MI-vásárlási felületnek. Ha ez a struktúra hiányzik a terméklapjaidról, az MI-ügynök egyszerűen nem tudja kiolvasni az áradat, a készletedet és a feltételeidet. Nem rossz választ ad: semmit sem ad.

A strukturált adatról sok webshoptulajdonos úgy gondolkodik, hogy az a Google-rangsorolás ügye — valami, amivel az SEO-s foglalkozik, ha ráér. Ez a keret téves, és egyre költségesebb tévhit. A Product/Offer JSON-LD ma már nemcsak a keresési megjelenési formátumokat vezérli, hanem azt is, hogy egy MI-ügynök egyáltalán „látja”-e a termékedet, amikor egy vásárló tőle kér összehasonlítást vagy ajánlást. Az alábbiakban leírom, hogy mi változott pontosan, mit kér ma a Google, és mi az, amit a webshopok leggyakrabban kihagynak.

Mi az a returnPolicyCountry, és miért lett kötelező?

A MerchantReturnPolicy a schema.org egyik típusa, amellyel a kereskedők leírhatják a visszaküldési feltételeiket — a visszaküldési határidőtől a visszatérítési módokon át a visszaküldési díjig. A returnPolicyCountry mező azt határozza meg, hogy a visszaküldési szabályzat melyik országra vonatkozik. Olyan mezőről van szó, amelynek kitöltését a Google korábban csak ajánlotta, 2026 márciusától viszont kötelezővé tette a visszaküldési szalagjegy (Return Badge) megszerzéséhez.

A visszaküldési szalagjegy az a kis ikon és összefoglaló, amellyel a Google Shopping találati oldalán bizonyos termékek kiemelve jelennek meg, és amelyet a vásárlók egyre nagyobb arányban keresnek döntéshozatal előtt. Ha ez a mező hiányzik, a Google nem jeleníti meg a szalagjegyet, és a termék elveszíti azt a vizuális megkülönböztetőt, amely növeli a kattintási arányt.

A konkrét értéke egy kétbetűs ISO-3166-1 országkód: Magyarország esetében HU. A leggyakoribb hiba az, hogy a webshopok a visszaküldési feltételeket csak szöveges oldalként jelenítik meg, JSON-LD nélkül — így a feltétel emberi szemmel olvasható, de gép számára láthatatlan. A bot nem olvassa el a szöveges bekezdést, és a vásárlói ügynök sem.

A visszaküldési séma önmagában csak a kirakós egyik darabja. Sokkal nagyobb hatása van annak, hogy a Product és Offer struktúra egyáltalán jelen van-e az összes terméklapodon — mert ez az a keret, amelybe a visszaküldési adat, a szállítási adat, az ár és a készlet egyaránt beágyazódik.

Miért nem tudja az MI kiolvasni az áradat séma nélkül?

Az MI-modellek — a ChatGPT, a Gemini és a Perplexity — egyre gyakrabban kapnak vásárlási jellegű kérdéseket. „Melyik boltból rendeljem a legjobban?” „Ez a termék kapható itthon, és mennyi a visszaküldési határidő?” Ezekre a kérdésekre az MI úgy próbál válaszolni, hogy értelmezi az elérhető strukturált adatot, az indexelt szövegeket és az aggregátori forrásokat.

Ha a terméklapod nem tartalmaz schema.org Product JSON-LD-t, az ügynök nem tud megbízhatóan kiolvasni belőle árat, pénznemet, készletet és visszaküldési feltételt. Nem azért, mert nem próbálja — hanem azért, mert strukturált adat hiányában a szöveges tartalom értelmezése bizonytalanná válik, az MI pedig ilyenkor vagy hallucinál, vagy egyszerűen azt mondja, hogy nem talál infót.

Fontos pontosan látni, mit jelent ez a két eset. Ha az ügynök hallucinál — például kiad egy árat, amely valójában nem az aktuális listaárad —, a vásárló téves adaton alapuló döntést hoz. Ha az ügynök azt mondja, hogy nincs elérhető adat, a vásárló egy versenytárshoz fordul, akinek a terméklapján ezek az adatok strukturáltan megvannak. Egyikből sem leszel te a nyertes.

Az Offer típus — amelybe az ár (price), a pénznem (priceCurrency), az elérhetőség (availability) és az előző pontban tárgyalt visszaküldési szabályzat (hasMerchantReturnPolicy) beágyazódik — az a közös nevező, amelyet a Google Product Structured Data specifikációja megkövetel, és amelyet a legfontosabb MI-vásárlási felületek mind olvasnak. Ez a kapcsolat közvetlen: az Offer nélkül a Google Shopping nem tud pontos ajánlatot megjeleníteni, és az MI-ügynök sem kap biztos adatpontot.

Az agentic kereskedelemről — arról, hogy az MI hogyan vesz részt a vásárlási döntésekben — részletesebben írtam az agentic kereskedelem és a magyar webshopok bejegyzésben. Az ott leírt felkészülési lépések egyenesen következnek ebből a strukturált alapból: a visszaküldési és szállítási séma épp az a belépő, amelyet az ügynök az egyéb adatok előtt kérdez le.

Mi a helyzet a szállítási adatokkal?

Az OfferShippingDetails az Offer alatt beágyazható struktúra, amellyel a szállítási paramétereket géppel olvasható formában tudod megadni: a szállítási célországot (shippingDestination), a várható kézbesítési időt (deliveryTime) és a szállítási díjat (shippingRate). A Google ezeket az adatokat a vásárlási eredményekben jeleníti meg, ha elég pontosak és következetesek — és az MI-ügynök is ezekből számítja ki, hogy a te boltodból milyen szállítási feltételekkel érne a termék a vásárlóhoz.

A leggyakoribb hiányosságok ezen a területen:

• A szállítási idő csak szövegesen jelenik meg a leírásban („3–5 munkanap”), de deliveryTime mezőként nem szerepel a JSON-LD-ben — az MI ezért vagy kihagyja, vagy hallucinál egy értéket.
• A szállítási díjat csak a pénztároldal mutatja, terméklapszintű sémában nincs rögzítve — az összehasonlítást végző ügynök tehát nem tudja beépíteni a számításba.
• A shippingDestination mező hiányzik, így a Google és az MI sem tudja, hogy Magyarországra szállítasz-e, vagy csak belföldön értékesítesz.

Egy vásárló, aki összehasonlítást kér két webshop ajánlatai között, a „teljes ár szállítással együtt” dimenzióban dönt. Ha az egyik bolt szállítási adatait az ügynök ki tudja olvasni, a másikét nem, a döntés az előbbi javára dől — nem azért, mert jobb az ajánlat, hanem mert az adat rendelkezésre áll. A kitöltött adatmező veri az üres adatmezőt, még akkor is, ha az üres mező mögött valójában jobb feltételek rejlenek.

Hogyan érdemes elvégezni az ellenőrzést?

Az első lépés nem fejlesztőnek szóló megbízás — hanem saját ellenőrzés. A Google Rich Results Test eszközével bármelyik terméklapodon megvizsgálhatod, hogy a jelenlegi JSON-LD struktúra megfelel-e a Google elvárásainak, és pontosan látod, mely mezők hiányoznak. A Search Console „Vásárlás” (Shopping) jelentése a teljes terméklistát átvizsgálja, és listázza, hol van hiány a kötelező mezőkben.

Amit érdemes konkrétan ellenőrizni:

• Van-e Product típusú JSON-LD minden egyes terméklapon — nem csak a főoldalon vagy a kategóriaoldalon?
• Az Offer tartalmaz-e price, priceCurrency és availability mezőket aktuális értékekkel?
• A hasMerchantReturnPolicy hivatkozás kitöltött MerchantReturnPolicy blokkra mutat-e, amelyben szerepel a returnPolicyCountry?
• Az OfferShippingDetails tartalmaz-e shippingDestination, deliveryTime és shippingRate adatokat?

Ha ezek közül bármelyikre nemleges a válasz, ott van a legközelebbi javítási pont. A javítás sorrendjét érdemes az MI-ügynök számára releváns adatok szerint rangsorolni: az ár és az elérhetőség az alapréteg, utána jönnek a visszaküldési feltételek, majd a szállítási részletek.

A séma és az MI-láthatóság kapcsolatáról tágabb képet ad a hét dimenzió mentén mért MI-láthatóság bejegyzés, amely részletezi, hogy a strukturált adat hogyan illeszkedik a teljes GEO-felkészültségi képbe. A hogyan működik oldalon megmutatom, milyen lépésekből áll az a mérés, amellyel konkrétan kiderül, mit lát ma az MI a webshopodból.

Mekkora a különbség, ha megvannak ezek az adatok?

A strukturált adat jelenléte nem garantálja, hogy az MI téged fog ajánlani — ezt fontos szem előtt tartani. Ahogy a GEO-pontszám és az MI-ajánlás különbségéről szóló bejegyzésben részletesen leírtam, az ajánlást a vélemények, a márka ismertsége és a külső jelenlét együttese dönti el. A strukturált adat a belépő: enélkül az ügynök nem tud értékelni, mert nincs mit értékelnie.

Amiben a különbség ma is mérhető: a Google Shopping találati megjelenésben (visszaküldési szalagjegy, szállítási idő és díj megjelenítése a keresési lapon), a Rich Results státuszban, és abban, hogy az MI vásárlási kérdésekre adott válaszaiba bekerülnek-e az adataid, vagy az ügynök máshonnan pótol, esetleg azt jelzi, hogy nincs elérhető adat.

A webshopok MI-felkészültségéről átfogóbb képet ad az agentic kereskedelem bejegyzés is, ahol az ügynöki felkészülés teljes logikáját leírom — a séma a mozaik egyik, de nélkülözhetetlen darabja.

Ha meg szeretnéd nézni, mit lát ma az MI a webshopodból — van-e Product/Offer séma a terméklapokon, olvashatók-e a visszaküldési és szállítási feltételek, és hol vannak a legnagyobb hiányok —, a kapcsolat oldalon jelezd. Megvizsgálom a jelenlegi állapotot, és pontosan megmutatom, hol kezdődik a munka.

Kindl Dávid · Közzétéve: 2026. június 22.