Egy webshopban a termékoldal a legfontosabb oldaltípus, mégis itt csúszik félre a strukturált adat a leggyakrabban. A Product jelölés elsőre egyszerűnek tűnik: van egy név, egy kép, egy leírás és egy ajánlat. A gyakorlatban viszont pont ezen a ponton kerül a legtöbb webshop olyan helyzetbe, hogy a kódban lévő adat mást állít, mint amit a látogató a képernyőn lát. Ebben a cikkben végigveszem, melyik mezőt érdemes kitölteni, melyiket jobb kihagyni, és hogyan tartható a jelölés tartósan szinkronban az oldal valós tartalmával.
Mit csinál valójában a Product jelölés a termékoldalon?
A Product jelölés géppel olvasható formában ismétli meg azt, ami az oldalon amúgy is látható: mit árulsz, milyen állapotban, milyen feltételekkel. Hivatalosan igazolt: a Google dokumentációja szerint a termék strukturált adat a keresési találatok gazdagabb megjelenítését és a kereskedői élményeket (merchant listing) segítheti, és a jelölésnek meg kell felelnie az oldalon megjelenő tartalomnak. Ez nem stílusbeli ajánlás, hanem a strukturált adatokra vonatkozó általános irányelv része.
Az AI-alapú válaszmotorok és vásárlási asszisztensek szempontjából a jelölés más okból is fontos. Ezek a rendszerek gyakran nem renderelik ki teljesen a JavaScripttel felépülő oldalt, viszont a HTML-be ágyazott JSON-LD blokkot könnyen kiolvassák. Szakmai feltételezés: a pontos, konzisztens termékjelölés jó eséllyel csökkenti annak esélyét, hogy egy asszisztens elavult vagy hibás adatot idézzen a termékedről, de ez nem garancia semmilyen megjelenésre, és a rendszerek viselkedése változékony.
Mely Product mezők kötelezőek, és melyek csak ajánlottak?
Rövid válasz: a name és egy értelmes offers blokk nélkül a jelölés gyakorlatilag használhatatlan, minden más fokozatosan növeli az értékét.
A gyakorlati minimum
@type: Productésname: pontosan az a terméknév, ami az oldal címsorában szerepel, kategórianév és marketingszöveg nélkül.image: a fő termékkép abszolút URL-je, lehetőleg több képarányban. Placeholder képet soha ne adj meg.offers: az ár, a pénznem, a készletállapot és a termékoldal URL-je.skuvagy más azonosító: ez köti össze a jelölést a saját rendszereddel.
Amit érdemes hozzátenni, ha valós
brand: a gyártó vagy márka neveBrandtípusként, nem a webshop neve.gtin13,gtin8,mpn: gyári azonosítók, ha ismered őket.description: a termékleírás rövidített, de az oldalon is olvasható változata.aggregateRatingésreview: kizárólag akkor, ha az értékelés az oldalon is látszik.color,size,material,isVariantOf: változatos termékkínálatnál segítik a pontos azonosítást.
Saját tapasztalat: a magyar webshopoknál a legnagyobb ugrást általában nem az egzotikus mezők hozzáadása jelenti, hanem az, hogy a meglévő négy-öt mező végre minden terméknél kitöltött és valós lesz. Egy százezer terméket kínáló katalógusban a részleges kitöltés sokkal többet ront, mint amennyit egy ritkán használt mező javítana.
Hogyan add meg helyesen az árat és a pénznemet?
Az árat mindig önálló Offer objektumban add meg, a price mezőben tiszta számformátumban, a priceCurrency mezőben pedig háromkarakteres ISO kóddal. Magyar webshopnál ez utóbbi a HUF.
"offers": { "@type": "Offer", "url": "https://pelda.hu/termek-url", "price": "{{ertek}}", "priceCurrency": "HUF", "availability": "https://schema.org/InStock", "itemCondition": "https://schema.org/NewCondition" }
Néhány szabály, ami magyar környezetben rendszeresen sérül. A price értékében ne legyen ezres elválasztó, pénznemjel, szóköz vagy szöveges kiegészítés. A tizedes elválasztó pont, nem vessző. Ha a webshop bruttó árat mutat, akkor a jelölésben is a bruttó szerepeljen, és a priceSpecification objektumban a valueAddedTaxIncluded mezővel jelezd, hogy az érték tartalmazza az áfát. Ha akciós és eredeti érték is szerepel az oldalon, a fő price mindig az legyen, amit a vásárló ténylegesen fizet a kosárban.
A priceValidUntil mező hasznos, de csak akkor, ha karbantartod. Ha ide egy régi dátum kerül, az ajánlat lejártnak látszik. Saját tapasztalat: ha nincs valós, rendszerből jövő lejárati dátumod, jobb kihagyni ezt a mezőt, mint egy évek óta változatlan értéket hagyni benne.
Hogyan jelöld a készletállapotot, hogy ne vezessen félre?
Az availability mező értéke schema.org URL, nem szabad szöveg. A leggyakrabban használt értékek: InStock, OutOfStock, PreOrder, BackOrder, LimitedAvailability és Discontinued. A magyar webshopok tipikus hibája, hogy a sablonba beégetett InStock kerül minden termékre, függetlenül a valós készlettől.
A helyes megoldás, hogy a készletállapot ugyanabból a rendszerváltozóból generálódik, amiből az oldalon megjelenő "Raktáron" vagy "Elfogyott" felirat. Ha az oldalon az szerepel, hogy a termék pár napos beszerzési idővel érhető el, akkor BackOrder a pontos érték, nem InStock. Ha a webshop több raktárt vagy több változatot kezel, a készletállapotot változatonként külön ajánlatban add meg, ne a fő terméken összevonva.
Mit írj a szállítási és visszaküldési adatokhoz?
Hivatalosan igazolt: a Google termék strukturált adat dokumentációja támogatja a shippingDetails és a hasMerchantReturnPolicy mezőket, amelyekkel a szállítási feltételek és a visszaküldési szabályzat géppel olvashatóan megadható. Ezek különösen a kereskedői megjelenéseknél kaphatnak szerepet.
A OfferShippingDetails objektumban a shippingRate tartalmazza a szállítás értékét és pénznemét, a shippingDestination az érintett országot (magyar webshopnál HU), a deliveryTime pedig a feldolgozási és a tényleges kézbesítési időt napokban. A MerchantReturnPolicy objektumban a visszaküldési határidő napokban, a visszaküldés módja és annak költségviselése adható meg.
Saját tapasztalat: ezt a két blokkot érdemes utoljára bevezetni. Ha a webshopban több szállítási mód, súlyhatár és utánvét-kombináció létezik, egyetlen általánosított érték a jelölésben könnyen félrevezetővé válik. Ilyen esetben inkább hagyd ki mindkettőt, és tartsd a szállítási feltételeket jól strukturált, olvasható formában az oldalon. A pontatlan szállítási jelölés rosszabb helyzet, mint a hiányzó.
Miért számít a termékazonosító, és mit tegyél, ha nincs?
A GTIN, az MPN és a márkanév azok az adatok, amelyekkel a rendszerek összekapcsolják a te terméklapodat a világ többi említésével: ugyanaz a cikk másik webshopban, gyártói adatlapon vagy összehasonlító oldalon. Enélkül a terméked lényegében szigetként áll.
Ha saját gyártású vagy egyedi termékről van szó, és nincs vonalkód, akkor a gtin mezőt egyszerűen hagyd üresen, és add meg a sku, mpn és brand hármast. Amit soha ne csinálj: kitalált vagy belső azonosítóból generált GTIN. Az érvénytelen ellenőrző összegű vonalkód nem semleges hiba, hanem aktív adatszennyezés a saját katalógusodban.
Hogyan kapcsolod össze a jelölést az oldalon látható tartalommal?
Az alapszabály egy mondatban: a jelölés soha ne tartalmazzon olyan állítást, amit a látogató a saját szemével nem tud ellenőrizni ugyanazon az oldalon.
Ez a gyakorlatban négy dolgot jelent. Először: a jelölés ugyanabból az adatforrásból generálódjon, mint a látható tartalom, ne külön szerkesztett mezőkből. Másodszor: ha az oldal JavaScripttel frissíti az árat vagy a készletet (például változatválasztáskor), akkor a JSON-LD blokk is frissüljön vele, vagy a szerveroldali válaszban már a helyes érték szerepeljen. Harmadszor: az értékelés jelölése csak akkor kerüljön ki, ha az értékelések ténylegesen láthatók, mert a nem látható tartalom jelölése az irányelvek megsértése. Negyedszer: a gyorsítótár. Saját tapasztalat: a magyar webshopoknál a hibás árjelölés meglepően nagy része nem fejlesztési hiba, hanem cache-probléma. Az oldal HTML-jét egy CDN vagy oldalgyorsító réteg tárolja, az ár időközben változik, és a jelölés napokig a régi értéket mutatja.
Hogyan validáld a jelölést lépésről lépésre?
- Nyisd meg a termékoldalt inkognitó ablakban, és nézd meg a forráskódban a JSON-LD blokkot. Ha ott nincs, a keresőrendszer sem biztos, hogy látja.
- Futtasd le a Rich Results Test és a Schema Markup Validator ellenőrzést ugyanarra az URL-re. Az első a Google-megjelenésekre, a második a schema.org-megfelelésre fókuszál.
- Vesd össze soronként: az ár, a pénznem, a készlet és a terméknév pontosan egyezik a képernyőn látottal?
- Ismételd meg legalább négy oldaltípuson: raktáron lévő termék, elfogyott termék, akciós termék, változatos (méret vagy szín szerinti) termék.
- Ellenőrizd a Search Console Termékek jelentését, és nézd meg, hány oldal ad hibát vagy figyelmeztetést, illetve hogy a hibák egy sablonhoz kötődnek-e.
- Változás után ellenőrizz újra: árazási akció, sablonfrissítés vagy bővítménycsere után is fusson le ugyanez a kör.
Melyek a leggyakoribb hibák a magyar webshopokban?
- Nem látható adat jelölése: értékelés vagy vélemény a kódban, miközben az oldalon egyetlen értékelés sem jelenik meg.
- Elavult ár: a látható érték frissül, a JSON-LD nem, jellemzően gyorsítótár vagy különálló sablonmező miatt.
- Hiányzó azonosító: nincs SKU, MPN vagy GTIN, így a termék nem köthető össze más adatforrásokkal.
- Beégetett készletállapot: minden termék raktáron van a jelölés szerint, akkor is, ha az oldal mást ír.
- Formátumhiba az árnál: szóköz, pénznemjel vagy tizedesvessző a
pricemezőben. - Kettős jelölés: a téma és egy bővítmény is kiír egy-egy Product blokkot, egymásnak ellentmondó tartalommal.
- Kategórialap termékként: a listaoldal egyetlen Product objektumként jelölve, holott ott
ItemLista helyes megközelítés. - A webshop neve márkaként: a
brandmezőbe a saját üzlet neve kerül a valódi gyártó helyett.
Miért jobb a hiányos, de pontos jelölés a teljesnél?
Ez a cikk fő állítása, és tudatosan szembemegy azzal a reflexszel, hogy minden mezőt ki kell tölteni. A strukturált adat bizalmi eszköz. Amikor a jelölés és az oldal eltér, a rendszer nem azt tanulja meg, hogy melyik adat a helyes, hanem azt, hogy a te forrásod megbízhatatlan. Ezt a hatást egyetlen extra mező sem ellensúlyozza.
Ezért a javasolt sorrend: először legyen néhány mező, ami minden terméknél kitöltött és bizonyítottan valós. Utána jöhet a bővítés, mezőnként, mindig validálással. Szakmai feltételezés: az AI-vásárlási asszisztensek terjedésével az adatkonzisztencia súlya jó eséllyel nőni fog, mert ezek a rendszerek több forrásból dolgoznak, és az ellentmondó adat könnyen kiesik a válaszból. Ez sem garancia semmire, de a kockázat aszimmetrikus: a pontos, kisebb jelölésen nincs mit veszíteni, a pontatlan, teljes jelölésen viszont van.
Ha egyetlen szabályt viszel el innen: minden Product mező előtt tedd fel a kérdést, hogy ez az adat valós, aktuális és látható-e az oldalon. Ha bármelyikre nem a válasz, hagyd ki a mezőt.
Források és további olvasnivalók
- Google Search Central: Product structured data (termék strukturált adat) dokumentáció
- Google Search Central: Structured data general guidelines (általános strukturált adat irányelvek)
- Google Search Central: Merchant listing experiences dokumentáció
- Google Rich Results Test és Search Console termék-jelentés súgó
- Schema.org: Product, Offer, AggregateOffer, OfferShippingDetails, MerchantReturnPolicy típusdefiníciók
- Schema Markup Validator (validator.schema.org)
- W3C: JSON-LD 1.1 specifikáció
- GS1 dokumentáció a GTIN azonosítók felépítéséről
- A Product jelölés minden mezőjének egyeznie kell az oldalon látható tartalommal, különben a jelölés kockázatot jelent, nem előnyt.
- Az árat mindig önálló Offer objektumban add meg, számformátumban, HUF pénznemmel, az adótartalomra vonatkozó jelzéssel együtt.
- A készletállapotot dinamikusan, a webshop valós készletadatából generáld, ne statikus sablonból.
- Az értékelést csak akkor jelöld, ha az értékelés a látogató számára is megjelenik az oldalon.
- A hiányzó termékazonosító (GTIN, MPN, SKU) a leggyakoribb oka annak, hogy a jelölés csak részben hasznosul.
Gyakori kérdések
Kötelező a Product séma egy webshopban?
Technikailag nem kötelező, a webshop nélküle is működik és indexelhető. A termék strukturált adat viszont feltétele annak, hogy a keresőrendszerek gazdagabb termékmegjelenéseket vegyenek figyelembe, és géppel olvasható formában adja át az ár, a készlet és az azonosító adatokat. Megjelenést egyik jelölés sem biztosít, a döntés a keresőrendszernél marad.
Mi legyen a price mezőben, ha a termék változatonként eltérő értékű?
Ilyenkor két jó megoldás van. Vagy AggregateOffer típust használsz lowPrice és highPrice mezőkkel, vagy minden változathoz külön Offer objektumot adsz meg saját azonosítóval és készletállapottal. A második pontosabb, de csak akkor működik jól, ha a változatok az oldalon is külön kiválaszthatók és láthatók.
Jelölhetem az értékeléseket, ha csak egy külső platformon vannak véleményeim?
Csak akkor, ha ezek a vélemények a termékoldalon is megjelennek a látogató számára. A strukturált adat irányelvei szerint nem látható tartalmat nem szabad jelölni. Ha csak külső platformon vannak értékelések, előbb jelenítsd meg őket az oldalon, és utána kerüljön be az aggregateRating mező.
Mit tegyek, ha a bővítményem és a sablonom is kiír Product jelölést?
Ez gyakori probléma WordPress és WooCommerce alapú webshopoknál. Nézd meg a forráskódban, hány JSON-LD blokk szerepel, és kapcsold ki az egyiket, jellemzően a sablon beépített változatát. Két, egymásnak ellentmondó Product objektum esetén nem tudod kontrollálni, melyiket dolgozza fel a rendszer.
Elég, ha a jelölés JavaScripttel jön létre?
A Google renderelés után általában feldolgozza a JavaScripttel beillesztett JSON-LD blokkot, de ez lassabb és sérülékenyebb út. Több AI-alapú olvasó és egyszerűbb crawler nem futtat JavaScriptet, így számukra a jelölés nem létezik. Ahol megoldható, a szerveroldali beillesztés a biztonságosabb választás.
Milyen gyakran érdemes újraellenőrizni a termékjelölést?
Havonta egyszer érdemes átnézni a Search Console termék-jelentését, illetve minden olyan esemény után, ami a sablont vagy az árazást érinti: bővítményfrissítés, akciós időszak indulása vagy zárása, katalógus-migráció. Egy-két mintaoldal validálása ilyenkor néhány percet vesz igénybe, és a legtöbb tömeges hiba már ekkor kiderül.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.