Szeptember 16.: a schema.org új mezőket adott a webshopodnak

A schema.org 2026. szeptember 16-án kiadta a 30.1-es verziót, benne egy csomag új kereskedelmi mezővel. A minimumOrderValue a szállítási díjszabásra kerül, az itemPopularity az ajánlatra, a consumerNotice és az isOftenBoughtWith a termékre, és megjelent egy új ártípus is: a MaximumRetailPrice. Ezekre nem kell engedélyt kérni, és nincs országkapcsoló: a szótár a megjelenés napjától magyar webshopban is használható. Azt viszont nem állítom, hogy már bárki olvassa is őket.

Mi került be a 30.1-be?

Ez a blog az elmúlt hetekben túl sokszor kezdte úgy a mondatot, hogy „Magyarországon még nem elérhető”. Most nem ez a helyzet. A schema.org szótár: amit kiadtak, azt aznap beírhatod a saját oldalad JSON-LD-jébe, függetlenül attól, hol van a céged székhelye. Ezért érdemes ezzel a kiadással foglalkozni.

A schema.org saját kiadási jegyzéke egy sorban foglalja össze a verziót: „Version 30.1 - Add vocabulary to support discovery of EU Digital Product Passports, Add vocabulary to express common eCommerce product data, Misc. schema, doc, and infra updates.” Két csomag van tehát benne. Az egyik az EU digitális termékútleveléhez ad szókincset, a másik a szokásos e-kereskedelmi termékadatokhoz. Ebben a cikkben a másodikkal foglalkozom, mert azt ma be tudod írni a terméklapjaidba. Az elsőre a végén térek ki.

A kereskedelmi csomag pontos szövege ez:

Add properties consumerNotice, isOftenBoughtWith, and specification for use on Product. Add property valueGroup for use on PropertyValue, itemPopularity for use on Offer, and minimumOrderValue for use on ShippingRateSettings. Add enum value MaximumRetailPrice to enumeration PriceTypeEnumeration. Add existing property provider for use on OfferShippingDetails. Extend the range of variesBy to include PropertyValue, and the range of value to include QualitativeValue.

Egy apró dátumügyet inkább kimondok, mint elhallgatok. A GitHubon a v30.1-es címke már 15-én este felkerült („15 Sep 20:22”), a kiadási jegyzet szövege viszont ott a mai napig nem töltődik be. A schema.org saját, emberi szemmel olvasható oldalán a 30.1 mellett 2026-09-16 szerepel, és a lap alján is ez áll: „Schema.org, V30.1, 2026-09-16”. Én ezt a dátumot használom, mert ez a szervezet saját, közzétett kiadási dátuma. A schema.org blogján egyébként nincs bejelentés erről a verzióról, ott a legfrissebb írás továbbra is a júniusi. Vagyis a kiadási jegyzék ma az egyetlen hely, ahol a változáslista olvasható.

Melyik mező hova kerül, és mit írj bele?

A kiadási jegyzék két dolgot ad meg: a mező nevét és azt, melyik típusra kerül fel. A táblázat harmadik oszlopa már az én olvasatom arról, mit írna bele egy magyar webshop. A kötelező érvényű definíciót mindig a mező saját schema.org-oldala mondja ki, nem én, úgyhogy mielőtt kiírsz valamit, nézd meg ott is.

Mező	Melyik típusra kerül	Mit írna bele egy webshop
`minimumOrderValue`	`ShippingRateSettings`	A szállítási díjtételhez tartozó minimális rendelési érték. Ez az a szám, amit ma csak a szállítási oldalad szövege mond el, például hogy mekkora kosárérték fölött érvényes egy adott díjszabás.
`provider`	`OfferShippingDetails`	A szállítást végző fél, tipikusan a futárszolgálat vagy a csomagpont-hálózat neve. Nem új mező, csak mostantól ezen a típuson is használható.
`itemPopularity`	`Offer`	Az adott ajánlat népszerűsége. Ugyanaz, amit ma a „legkeresettebb” vagy „népszerű” címke mond el az embernek, csak mezőként.
`consumerNotice`	`Product`	A termékhez tartozó fogyasztói tájékoztatás vagy figyelmeztetés. Ott jön elő, ahol ma is kötelező kiírni valamit a termék mellé, például korhatárt vagy használati figyelmeztetést.
`isOftenBoughtWith`	`Product`	Az a másik termék, amit gyakran együtt vásárolnak ezzel. A „gyakran együtt vásárolt” blokk párja mezőként, ha az ajánlóblokkod adata már megvan a rendszerben.
`specification`	`Product`	A termék specifikációja, vagyis a műszaki adatlap. Ma ez a legtöbb boltban szabad szöveg vagy kép, és emiatt az AI nehezen olvassa ki.
`valueGroup`	`PropertyValue`	Az összetartozó tulajdonságértékek csoportja. Akkor van értelme, ha a variánsválasztóban több érték tartozik ugyanahhoz a dimenzióhoz, például a méretek és a színek külön csoportba kerülnek.
`MaximumRetailPrice` (új felsorolásérték)	`PriceTypeEnumeration`	Ártípus, nem önálló mező. Akkor jön elő, ha egy árat maximált kiskereskedelmi árként kell megjelölni a listaáron kívül.

Az idézet utolsó mondata két értéktartomány-bővítésről szól: a variesBy mostantól PropertyValue értéket is felvehet, a value pedig QualitativeValue-t. Ezek a variánskezelés fejlesztői részletei, nem olyasmi, amit egy boltvezető kézzel állítgat a felületen.

Ez pont az a séma, amit a returnPolicyCountry-cikkben már megnyitottál

Ha olvastad azt a cikket, amelyben a returnPolicyCountry mezőről és a szállítási adatokról írtam, akkor ennek a kiadásnak a fele ismerős területen mozog. Az OfferShippingDetails az a struktúra, amelyben a szállítási célországot, a kézbesítési időt és a szállítási díjat adod meg. A 30.1 két ponton nyúl hozzá ehhez a családhoz: a provider mostantól ezen a típuson is használható, a minimumOrderValue pedig a hozzá tartozó ShippingRateSettings típusra kerül.

Ez így a legkisebb munka az egész kiadásban. Aki már végigvitte a visszaküldési és szállítási sémát, annak most nem új rendszert kell bevezetnie, hanem két sort hozzátennie egy meglévő blokkhoz. Aki viszont akkor kihagyta, annak nem ezekkel a mezőkkel kell kezdenie. Ha a terméklapjaidon egyáltalán nincs Product és Offer séma, az alapokat a Product és Offer sémáról szóló cikkben szedtem össze. Új mezőt hiába írsz be egy olyan terméklapra, amelyen az AI még az árat sem találja meg.

Olvassa ezt már bárki?

Nem tudom, és ezt nem kerülgetem. Amit ma megnéztem, az annyi: a mezők bekerültek a schema.org szótárába. Hogy a Google, az OpenAI, a Perplexity vagy bármelyik AI-vásárlási ügynök olvassa-e ezeket a konkrét mezőket, arról nincs adatom, és nem is találtam olyan forrást, amelyik ezt állítaná.

Ez a két dolog külön él. A schema.org szótár: leírja, milyen fogalmakkal lehet beszélni egy termékről. Hogy egy kereső vagy asszisztens miből épít megjelenést, az a saját, külön döntése, és a saját dokumentációjában szerepel. Attól, hogy egy mező bekerült a szótárba, még nem lett sem rangsorolási tényező, sem megjelenési formátum belépője. Ha valaki azt mondja neked, hogy „a ChatGPT már az itemPopularity mezőt nézi”, kérd el hozzá a forrást.

Akkor miért írnád be? A saját álláspontom kettős, és szerintem ez a különbségtétel ér a legtöbbet. Amihez az adat már megvan a rendszeredben, azt írd ki: a minimális rendelési érték, a szállító neve, a gyakran együtt vásárolt termék és a műszaki adatlap kinyerése a legtöbb webáruházban konfiguráció, nem projekt. Ez nulla forint és nulla kockázat. Amihez viszont új adatot kellene előállítanod vagy kézzel karbantartanod, azzal várj, amíg tudod, ki olvassa. Az itemPopularity tipikusan ilyen: ha nincs automatizált forrásod rá, nem érdemes külön táblát építeni egy olyan mezőért, amelyről ma senki nem mondta ki, hogy számít.

Az AI-vásárlási ügynökökről és arról, hogy mit jelentenek egy magyar webshopnak, külön írtam az agentic kereskedelemről szóló cikkben. Az ott leírt logika itt is áll: a strukturált adat a belépő, nem a garancia.

Mit tegyél ezen a héten?

Nézd meg, melyik mezőnek van már meg az adata. Vedd elő a nyolcsoros táblázatot, és jelöld be, melyik érték van meg a webáruházad adatbázisában vagy a terméklap felületén. Amelyik megvan, azt írd ki a JSON-LD-be. Amelyik nincs meg, azt hagyd békén.

Kezdd a szállítási blokkal. Ha már van OfferShippingDetails a terméklapjaidon, a provider és a minimumOrderValue a leggyorsabb két kiegészítés, és pont azt a hiányt tömi be, amiről júniusban írtam: a szállítási feltétel eddig szövegként létezett, mezőként nem.

Ellenőrizd a kimenetet, ne a szándékot. A hibátlanul kinéző kód és az AI által kiolvasott adat nem ugyanaz. Erre jó példa az, amiről az és-jeles cégnevekről és a JSON-LD-elemzőről írtam: a kód megfelelt a szabálynak, az elemző mégis mást olvasott ki belőle, mint amit a boltos gondolt. Az új mezőknél ugyanez a veszély, csak még kevesebb tapasztalat van mögötte.

Ne tolj rá egy sprintet a fejlesztőre. A nyolc tétel közül a legtöbb boltban kettőnek vagy háromnak van értelme. A maradékot nem kell megvalósítani csak azért, mert megjelent. Egy fecske nem csinál nyarat, és egy kiadási jegyzék nem csinál prioritást.

És a digitális termékútlevél?

A 30.1 másik fele erről szól, és ez a nagyobb történet, csak nem a mostani hétről. Bekerült egy új osztály, a DigitalProductPassport, hozzá a hasDigitalProductPassport mező a Product és az Offer típusra. Bekerült két új tanúsítványtípus, az EnvironmentalProductDeclaration és a DeclarationOfConformity, mindkettő a Certification altípusaként. És bekerült négy mező a termékre: az authorizedRepresentative (ez az Organization típusra is felkerül), az importer, a recycledContentPercentage és a substanceOfConcern.

Olvasd el még egyszer ezt a négy nevet: meghatalmazott képviselő, importőr, újrahasznosított anyag aránya, aggodalomra okot adó anyag. Ez nem ár és nem készlet. Ez megfelelési és fenntarthatósági adat, és most kapott helyet ugyanabban a szótárban, amelyből az AI a termékedről olvas.

Amit viszont nem mondok meg: mikortól és mely termékkategóriákra lesz kötelező a digitális termékútlevél. Ezt nem ellenőriztem EU-s elsődleges forrásban, és sémakiadásból nem is lehet kiolvasni. Egy kiadási jegyzék arról szól, hogy mit lehet leírni, nem arról, hogy mit kell. Ha a határidő érdekel, ahhoz jogi forrás kell, és az egy másik cikk.

Ami ma biztosan igaz: a szótár készen áll. Ha a boltod olyan kategóriában mozog, ahol az anyagösszetétel, az újrahasznosított arány vagy az importőr adata egyébként is számít, ez a csomag jelzés arról, merre tart a termékedről szóló AI-olvasás. Nem teendő, hanem irány.

A séma, amit korábban beírtál, kapott néhány új szomszédot. Nincs bevezetés, amire várni kell, nincs országkapcsoló, és nem kell hozzá engedély. A dolgod annyi, hogy megnézd, melyik mezőnek van már meg az adata, és kiírd. Aztán megvárd, hogy valaki elolvassa.

Ha szeretnéd, hogy megnézzem, mit lát ma az AI a webshopod terméklapjairól, és hol tátong a legnagyobb lyuk a Product, az Offer és a szállítási adatok között, jelezd a kapcsolat oldalon.

Kindl Dávid · Közzétéve: 2026. szeptember 19.

Gyakori kérdések

Kötelező most beépítenem a schema.org 30.1 új mezőit a webshopomba?

Nem. A schema.org szótár, nem előírás: leírja, milyen fogalmakkal lehet beszélni egy termékről, de nem ír elő semmit. A kiadási jegyzék annyit mond, hogy a mezők mostantól használhatók. Az én javaslatom az, hogy azt írd ki, amihez az adat már megvan a rendszeredben, és azzal várj, amihez új adatot kellene előállítanod vagy kézzel karbantartanod.

Mi a különbség a minimumOrderValue és a korábban tárgyalt returnPolicyCountry között?

Két különböző típusra kerülnek. A returnPolicyCountry a visszaküldési szabályzat mezője, és azt adja meg, melyik országra érvényes a szabályzat. A minimumOrderValue a 30.1 új mezője, és a ShippingRateSettings típusra kerül, vagyis a szállítási díjszabáshoz tartozik. Közös bennük, hogy ugyanabba a Product és Offer keretbe ágyazódnak be, ezért aki már végigvitte a szállítási sémát, annak most csak hozzá kell tennie egy sort egy meglévő blokkhoz.

Olvassa már a Google vagy a ChatGPT ezeket az új mezőket?

Erre nem tudok igent mondani. Amit ellenőriztem, az annyi: a mezők 2026. szeptember 16-án bekerültek a schema.org szótárába. Hogy bármelyik kereső, asszisztens vagy AI-vásárlási ügynök olvassa-e ezeket a konkrét mezőket, arról nincs adatom, és nem is találtam olyan forrást, amelyik ezt állítaná. A szótár és az, hogy egy rendszer miből épít megjelenést, két külön dolog. Ha valaki azt mondja, hogy egy asszisztens már az itemPopularity mezőt nézi, kérd el hozzá a forrást.

Mit jelent a DigitalProductPassport, és kell ez már nekem?

A 30.1 bevezetett egy új osztályt DigitalProductPassport néven, hozzá a hasDigitalProductPassport mezőt a Product és az Offer típusra, két új tanúsítványtípust (EnvironmentalProductDeclaration és DeclarationOfConformity, mindkettő a Certification altípusa), valamint az authorizedRepresentative, importer, recycledContentPercentage és substanceOfConcern mezőket. Ez ma szókincs. Azt, hogy a digitális termékútlevél mikortól és mely termékkategóriákra lesz kötelező, nem ellenőriztem EU-s elsődleges forrásban, ezért nem is állítok róla dátumot. Sémakiadásból ez nem olvasható ki: ahhoz jogi forrás kell.

Honnan tudom, hogy a WooCommerce- vagy Shopify-boltom támogatja-e az új mezőket?

Ezt nem néztem meg, és nem is tippelek rá. Egy szótárba felvett mező nem jelenti azt, hogy a bolti rendszerek vagy a sémabővítmények automatikusan kiírják. A gyakorlati út az, hogy megnyitod az egyik terméklapod oldalforrását, megkeresed a JSON-LD-blokkot, és megnézed, mi szerepel benne ma. Ha az új mező nincs ott, akkor vagy a rendszer nem támogatja, vagy nincs bekapcsolva, és ez már a bolti rendszer dokumentációjának a kérdése.

Hol nézhetem meg, hogy melyik schema.org-verziót írja ki az oldalam?

A JSON-LD nem hordoz verziószámot: egy mező vagy létezik a szótárban, vagy nem, és a te oldaladat mindig a legfrissebb szótárhoz mérik. Amit ellenőrizni tudsz, az a saját kimeneted: nyisd meg a terméklap oldalforrását, keresd meg az application/ld+json blokkot, és vesd össze a benne szereplő mezőneveket a schema.org kiadási jegyzékével. A kiadási jegyzék a mai napig az egyetlen hely, ahol a 30.1 változáslistája olvasható, a schema.org blogján nincs róla bejelentés.

Ha most nem teszek semmit, veszítek AI-láthatóságot?

Erre nincs adatom, és nem is állítom. Ahhoz, hogy egy kihagyott mező veszteséget okozzon, előbb kellene valaki, aki olvassa, és erről ma nincs forrásom. Amiről viszont van tapasztalatom, az az eggyel lejjebb lévő szint: ha a terméklapjaidon egyáltalán nincs Product és Offer séma árral, pénznemmel és elérhetőséggel, az mérhető hiány, mert akkor nem az új mezőkkel van baj, hanem azzal, hogy az AI az alapadatokat sem találja. Az alapokkal kezdd, az új mezőkkel folytasd.