Product schema: teljes útmutató

A Product schema egy strukturált adatjelölés (általában JSON-LD formátumban), amely gépileg olvasható módon írja le a termékoldalad lényegét: a termék nevét, árát, pénznemét, készletállapotát, értékeléseit és azonosítóit. A keresők ebből érthetik meg pontosan, mit árulsz, és ennek alapján bővített találatot jeleníthetnek meg. Megjelenést nem garantál, de a pontos, a látható tartalommal egyező jelölés ennek alapfeltétele.

Alapfogalmak

Mielőtt egyetlen sor kódot is írnál, érdemes tisztázni, mit jelent a Product schema, és mi nem tartozik bele. A schema.org egy közös szókincs, amelyet a nagy keresők együtt hoztak létre azért, hogy a weboldalak egységes nyelven írhassák le a tartalmukat. Ebben a szókincsben a Product egy típus, amelyhez tulajdonságok tartoznak, például name, image, description, sku, brand vagy offers. A webshopod termékoldala pedig ennek a típusnak egy konkrét példányát írja le.

A strukturált adat nem a látogatónak szól. A látogató a megszokott HTML oldalt látja, a jelölés a forráskódban él, és a keresőrobotnak segít abban, hogy ne kelljen kitalálnia, melyik szám az ár, melyik a régi ár, és melyik egy cikkszám. Ez az egyértelműség a lényeg: a jelölés nem trükk, hanem a meglévő információ pontosabb leírása.

A három formátum

Strukturált adatot háromféleképpen adhatsz meg. A gyakorlatban az elsőt érdemes választani, mert a Google is ezt javasolja, és ez a legkönnyebben karbantartható.

Formátum	Hol él	Előny	Hátrány
JSON-LD	Külön script blokkban, a HTML-től elválasztva	Könnyű sablonból generálni, nem töri el a dizájnt	Könnyű elcsúszni a látható tartalomtól, ha nem ugyanabból az adatforrásból jön
Microdata	HTML attribútumokban, a látható elemeken	Szorosan kötődik a látható tartalomhoz	Nehezen karbantartható, sablonváltásnál könnyen sérül
RDFa	HTML attribútumokban	Rugalmas, más szókincsekkel is működik	Webshopoknál ritka, kevés fejlesztő ismeri jól

Product, Offer, AggregateOffer, Review

A Product típus önmagában csak a terméket írja le. Az ár és a készlet nem közvetlenül a Product része, hanem a hozzá kapcsolt Offer objektumé. Ez fontos különbség: egy termékhez több ajánlat is tartozhat, például különböző eladóktól. Ha egy oldalon több ár szerepel, mert több eladó kínálja a terméket, akkor az AggregateOffer a megfelelő típus, amely legalacsonyabb és legmagasabb árat ad meg.

Offer: egy konkrét ajánlat egy árral, pénznemmel és elérhetőséggel.
AggregateOffer: több ajánlat összesítése árintervallummal.
Review: egy konkrét vásárlói értékelés szöveggel és pontszámmal.
AggregateRating: az értékelések átlaga és darabszáma.
Brand: a márka, lehetőleg külön objektumként, névvel.

Termékrészlet és kereskedői listázás

A Google dokumentációja két nagy felhasználási irányt különít el. Az egyik a termékrészletek (product snippet), ahol az organikus találat mellett megjelenhet például az értékelés vagy az ár. A másik a kereskedői listázás (merchant listing), amely a vásárlási felületekhez kapcsolódik, és jellemzően több mezőt igényel, például szállítási és visszaküldési információkat. Ha webshopod van és közvetlenül a vásárlónak adsz el, a kereskedői listázás követelményei a relevánsak számodra. Ha csak ismertetőt vagy összehasonlítást írsz, a termékrészlet. A pontos mezőlista időnként változik, ezért a Google aktuális dokumentációját mindig ellenőrizd élesítés előtt.

Gyakori tévhit: a jelölés rangsorolási faktor

Sokan azt hiszik, hogy a Product schema közvetlenül feljebb viszi a terméket a találatok között. Erre nincs megbízható bizonyíték. A jelölés a megjelenést befolyásolhatja, és ezen keresztül az átkattintást, de egy gyenge, vékony tartalmú termékoldalt nem tesz erőssé. A strukturált adat a jó termékoldal kiegészítője, nem helyettesítője. Az alapokhoz a E-commerce SEO áttekintés ad keretet.

Hogyan működik?

A folyamat négy lépésből áll: a webshop sablonja legenerálja a JSON-LD blokkot, a robot feltérképezi az oldalt, a kereső értelmezi és validálja a jelölést, végül eldönti, megjelenít-e bővített találatot. Ezek közül csak az első kettőt irányítod közvetlenül, a döntés a keresőé.

1. Generálás a sablonból

Egy webshopban senki nem ír kézzel jelölést ezer termékhez. A termékoldal sablonja ugyanabból az adatbázisból veszi az árat, a nevet és a készletet, amiből a látható oldal is készül, és ezeket egy script blokkba írja. Ez a legfontosabb elv: a jelölés és a látható tartalom ugyanabból a forrásból jöjjön. Ha az ár a kosárban egy akció miatt változik, de a JSON-LD egy gyorsítótárazott régi értéket mutat, ellentmondás keletkezik.

2. Feltérképezés és renderelés

A robot letölti az oldalt. Ha a JSON-LD a szerver által küldött HTML-ben benne van, azonnal olvasható. Ha JavaScript szúrja be utólag, a kereső csak renderelés után látja, ami késést és bizonytalanságot okozhat. A biztosabb megoldás, ha a jelölés szerveroldalon kerül a kódba.

3. Értelmezés és validálás

A kereső ellenőrzi, hogy a kötelező mezők megvannak-e, a típusok helyesek-e (az ár szám, a pénznem érvényes kód, az elérhetőség elfogadott érték), és hogy a jelölés összhangban van-e az oldal tartalmával. Itt dől el, hogy egy elem érvényes, figyelmeztetéses vagy hibás.

4. Megjelenítési döntés

Érvényes jelölés mellett sincs garancia. A kereső a lekérdezés, az eszköz, az oldal minősége és más tényezők alapján dönti el, mutat-e bővített elemet. Ezért fordulhat elő, hogy hibátlan jelölés mellett egy ideig semmi nem változik a találati oldalon.

Kidolgozott saját példa

Vegyünk egy szemléltető terméket: egy kerámia bögrét egy kis hazai webshopból. Az adatok kitaláltak, csak a szerkezetet mutatják.

Mező	Szemléltető érték	Megjegyzés
@type	Product	A fő típus
name	Kézzel festett kerámia bögre, 350 ml, kék	Egyezzen a látható terméknévvel
image	A fő termékfotó abszolút URL-je	Lehetőleg több kép, jó felbontásban
sku	BG-350-KEK	Saját cikkszám
gtin13	A gyártói vonalkód, ha van	Ne találj ki számot
brand.name	A márka neve	Brand objektumként
offers.price	4990	Szám, pénznemjel nélkül
offers.priceCurrency	HUF	ISO 4217 kód
offers.availability	https://schema.org/InStock	Teljes schema.org URL
offers.url	A termékoldal kanonikus URL-je	Ugyanaz, mint a canonical

A sablonban ez egyetlen script blokk lesz, amelyet a termékoldal minden betöltésekor friss adatból generálsz. Ha a bögre elfogy, a látható „Elfogyott” felirattal együtt az availability is OutOfStock értékre vált, mert mindkettő ugyanabból a készletmezőből olvas.

Határeset: variánsok

Mi történik, ha a bögre három színben létezik? Két út van. Ha minden színnek saját URL-je van, mindegyik saját Product jelölést kap. Ha egy oldalon választható a szín, akkor a variánsok csoportosítására szolgáló megoldásokat (például a ProductGroup típust és a variáló tulajdonság megadását) érdemes megvizsgálni, a Google aktuális variánsdokumentációja szerint. A rossz megoldás az, ha egy oldalon egyetlen Product szerepel, de az ár a kiválasztott színnel változik, a jelölés pedig mindig az alapvariáns árát mutatja.

Fő módszerek

A Product schema bevezetésére több út létezik, és a választás főleg attól függ, milyen platformon fut a webshopod, mennyire férsz hozzá a sablonhoz, és ki fogja karbantartani. Nincs univerzálisan legjobb megoldás, csak olyan, ami a te helyzetedben a legkevesebb ellentmondást termeli hosszú távon.

1. Platform beépített jelölése

Sok webshopmotor és téma alapból generál valamilyen termékjelölést. Ez gyors kiindulópont, de ritkán teljes. Gyakran hiányzik a GTIN, a márka, a szállítási adat, vagy a jelölés nem követi a variánsokat. Első lépésként mindig nézd meg, mit ad a platform, mielőtt bármit hozzáadnál, mert a duplikált jelölés gyakori hibaforrás.

2. Bővítmény vagy alkalmazás

SEO-bővítmények és alkalmazások sokszor kínálnak termékjelölést. Előnyük, hogy fejlesztő nélkül is beállíthatók. Hátrányuk, hogy egy másik réteg is jelölést ír, amely ütközhet a téma saját jelölésével. Ha bővítményt használsz, kapcsold ki a téma kimenetét, vagy fordítva, hogy csak egy forrás maradjon.

3. Egyedi sablonfejlesztés

Közepes és nagy webshopoknál ez a legmegbízhatóbb. A fejlesztő a termékoldal sablonjába írja a JSON-LD generálást, közvetlenül a termékadatbázisból. Teljes kontrollt ad, és a variánsok, akciós árak, készletváltozás pontosan kezelhető.

4. Címkekezelőből injektálás

Technikailag lehetséges a jelölést egy címkekezelőből beszúrni, de ez JavaScript-függő, és az adatot gyakran a látható oldalról kell visszakaparni. Átmeneti megoldásnak elmegy, tartósnak kevésbé ajánlott.

Döntési szabály

Az alábbi szabályt érdemes egy belső wikibe is beírni, hogy mindenki ugyanúgy döntsön:

Ha a platform jelölése érvényes és tartalmazza az árat, a pénznemet, az elérhetőséget, a nevet és a képet, maradj ennél, és csak a hiányzó mezőket pótold.
Ha hiányos és nincs fejlesztői erőforrás, válassz egyetlen bővítményt, és kapcsold ki a téma jelölését.
Ha a termékeidnek variánsai, gyakran változó árai vagy több eladója van, egyedi sablonfejlesztés kell.
Címkekezelős megoldást csak ideiglenesen használj, határidővel a kiváltásra.

Mezők prioritása

Prioritás	Mezők	Miért
Alap	name, image, offers (price, priceCurrency, availability)	Ezek nélkül a jelölés jellemzően nem használható bővített találatra
Erősen ajánlott	brand, sku, gtin, description, url	Segítik a termék egyértelmű azonosítását
Helyzetfüggő	aggregateRating, review	Csak valódi, az oldalon látható értékelésnél
Kereskedői	szállítási és visszaküldési adatok, priceValidUntil	Vásárlási felületekhez relevánsak, ellenőrizd az aktuális követelményt

Kapcsolat a teljes webshop SEO-val

A jelölés a termékoldal technikai rétege. Ugyanilyen fontos az oldal tartalma, a belső linkelés és az indexelhetőség. Ha a terméklapok nincsenek indexelve, mert szűrőparaméteres duplikációk nyelik el a feltérképezést, a legjobb jelölés sem segít. Ennek összképét a Webshop SEO: teljes útmutató írja le.

Ellenpélda: a kategóriaoldal Product jelölése

Gyakori kísértés, hogy a kategóriaoldalra is Product jelölést tegyenek, a listában szereplő összes termékre. Ez félrevezető, mert a kategóriaoldal nem egy termékről szól. A kategóriaoldalakon inkább a navigáció, a tartalom és a szűrők kezelése a fontos, erről a Kategóriaoldal SEO: teljes útmutató szól részletesen.

Gyakori hibák

A legtöbb Product schema probléma nem bonyolult technikai hiba, hanem következetlenség: a jelölés mást mond, mint az oldal, vagy két forrás mond két különböző dolgot. Az alábbiak a leggyakoribb mintázatok, mindegyikhez a javítással.

Eltérő ár a jelölésben és az oldalon

Akciónál a látható ár csökken, a jelölés a régit mutatja, vagy fordítva. Oka szinte mindig a gyorsítótár vagy az, hogy a jelölés más mezőből olvas. Javítás: mindkettő ugyanabból a végső, kosárban is érvényes árból generálódjon. Ha az ár bruttó a látható oldalon, a jelölésben is a bruttó szerepeljen.

Rossz formátumú ár

„4 990 Ft” vagy „4.990,-” a price mezőben hibás. A mező számot vár, tizedespont használatával, pénznemjel és ezres elválasztó nélkül. A pénznem külön mezőbe kerül, HUF formában.

Kitalált értékelések

Az aggregateRating csak akkor szerepelhet, ha az értékelések valódiak és az oldalon is láthatók. Fix „4,8 csillag” beégetése minden termékre szabálysértő lehet, és kézi intézkedéshez vezethet. Ha nincs értékelés, egyszerűen hagyd ki a mezőt.

Duplikált vagy egymásnak ellentmondó jelölések

A téma és a bővítmény is ír egy Product blokkot, más árral vagy más névvel. A kereső nem tudja, melyiknek higgyen. Nézd meg a forráskódot, és ha két Product blokkot találsz ugyanarra a termékre, szüntesd meg az egyiket.

Elavult elérhetőség

Elfogyott termék InStock jelöléssel rossz vásárlói élményt okoz, és hosszú távon a bizalmat rontja. A készletállapot a jelölésben is valós idejű legyen, vagy legalább a látható felirattal azonos frissítési ciklusú.

Kitalált azonosítók

Ha nincs GTIN, ne generálj véletlen számot, és ne írd be a saját cikkszámot GTIN-ként. A hamis azonosító rosszabb, mint a hiányzó. Saját azonosítóra az sku való.

Relatív URL-ek és rossz kép

Az image és az url mezőbe abszolút URL kerüljön. A kép legyen az oldalon is látható termékfotó, ne logó vagy helyőrző kép.

Ellenőrzőlista élesítés előtt

Pontosan egy Product blokk van a termékre?
A name egyezik a látható terméknévvel?
A price szám, és egyezik a látható végső árral?
A priceCurrency érvényes ISO-kód?
Az availability teljes schema.org értéket használ, és megfelel a látható készletnek?
Az image abszolút URL, és valódi termékfotó?
Az aggregateRating csak valódi, látható értékelésekből jön?
A GTIN valós gyártói kód, vagy a mező hiányzik?
Az offers.url megegyezik a kanonikus URL-lel?
A jelölés a szerver által küldött HTML-ben megjelenik?
Variánsoknál a jelölés a kiválasztott variánst vagy a variánscsoportot írja le helyesen?

Gyakori tévhit: ha a validátor zöld, minden rendben

A validátor a szintaxist és a mezőket nézi, azt nem tudja, hogy az ár valóban egyezik-e azzal, amit a vásárló fizet. A tartalmi egyezést neked kell ellenőrizned, mintavétellel, rendszeresen.

Mérés

A Product schema bevezetése után két kérdésre keresel választ: technikailag rendben van-e a jelölés, és hoz-e valamilyen változást a keresési teljesítményben. Az első viszonylag egyértelmű, a második óvatos értelmezést kíván, mert sok más tényező is mozgatja a számokat.

Technikai ellenőrzés

A Google Search Console strukturált adatokra vonatkozó jelentései megmutatják, hány oldalon érvényes, figyelmeztetéses vagy hibás a termékjelölés. A Rich Results Test egyes URL-ek ellenőrzésére jó, a schema.org validátor pedig a szókincs szerinti helyességet nézi. A jelentésekben a hibák típusa alapján csoportosítva látod a problémákat, ami segít megtalálni a sablonszintű hibát, mert egy sablonhiba jellemzően minden terméket érint.

Ellenőrzési workflow

Élesítés előtt teszteld a sablont 5 to 10 jellemző terméken: akciós, elfogyott, variánsos, értékelés nélküli, GTIN nélküli.
Élesítés után néhány nappal nézd meg a Search Console jelentését, nőnek-e az érvényes elemek.
Havonta végezz mintavételt: válassz ki véletlenszerűen termékeket, és vesd össze a jelölést a látható oldallal.
Minden sablon- vagy platformfrissítés után ismételd meg az első lépést.
A hibákat sablonszinten javítsd, ne termékenként.

Teljesítménymérés

A Search Console teljesítményjelentésében a keresési megjelenés szerinti szűréssel (ha az adott bővített találattípushoz elérhető) összevetheted azokat a megjelenéseket, ahol bővített elem volt. Figyeld a megjelenéseket, a kattintásokat és az átkattintási arányt a termékoldalakon. Ne várj azonnali változást: a feltérképezés és a feldolgozás időbe telik.

Szemléltető számpélda

Az alábbi számok kitaláltak, csak a gondolkodásmódot mutatják. Tegyük fel, hogy egy termékcsoport négy héttel a bevezetés előtt 20 000 megjelenést és 400 kattintást kapott, ami 2,0 százalékos átkattintás. Négy héttel utána 21 000 megjelenés és 525 kattintás, azaz 2,5 százalék. A kattintásszám növekedése részben a megjelenések növekedéséből jön, ezért az átkattintási arányt nézd, ne a nyers kattintást. És mielőtt a javulást a jelölésnek tulajdonítanád, ellenőrizd, volt-e közben szezonális hatás, árváltozás, kampány vagy algoritmusfrissítés.

Kontrollcsoport

Ha teheted, ne egyszerre vezesd be minden terméken. Válassz két hasonló termékcsoportot, az egyiken élesítsd a bővített jelölést, a másikon később. Így a szezonális hatás mindkét csoportot érinti, és a különbség jobban köthető a jelöléshez. Ez nem tudományos kísérlet, de sokkal megbízhatóbb, mint egy egyszerű előtte-utána összevetés.

Mutató	Honnan	Mit jelez
Érvényes termékelemek száma	Search Console strukturált adat jelentés	A jelölés technikai lefedettsége
Hibák és figyelmeztetések	Search Console	Sablon- vagy adathibák
Átkattintási arány	Teljesítményjelentés	A megjelenés vonzereje
Termékoldal-konverzió organikusból	Analitika	Az érkező forgalom minősége

Határeset: nő az átkattintás, csökken a konverzió

Ha az ár látszik a találatban, előfordulhat, hogy kevesebb, de elkötelezettebb látogató jön, vagy fordítva. Ezért a keresési adatokat mindig a webshop konverziós adataival együtt értelmezd.

Kapcsolódó részletes útmutatók

A Product schema a termékoldal technikai rétege, de az eredményesség a teljes webshop szerkezetén múlik: az indexelhető termékoldalakon, a jól felépített kategóriákon és a belső linkelésen. Az alábbi útmutatók ezeket a területeket fedik le, érdemes a jelölés mellett ezeket is végignézni.

Hol érdemes folytatni

Ha a termékoldalaid jelölése rendben van, a következő lépés általában a kategóriaszint, mert a termékoldalak jelentős része onnan kap belső linket és feltérképezési prioritást. Ha a webshop egészének technikai állapota bizonytalan, kezdd az átfogó útmutatóval.

Egy praktikus sorrend: először nézd át az e-commerce SEO alapjait, aztán a webshop szintű technikai kérdéseket, majd a kategóriaoldalakat. A termékjelölést minden sablonmódosítás után ellenőrizd újra az előző ellenőrzőlista szerint, mert a legtöbb hiba nem bevezetéskor, hanem egy későbbi frissítés után jelenik meg.