ItemList jelölés kategóriaoldalon: mikor segít és mikor felesleges

Scheo · 2026-10-03 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A kategóriaoldal a webshop egyik legforgalmasabb oldaltípusa, a strukturált adatoknál mégis ritkán kap annyi figyelmet, mint a termékoldal. Sokan kipipálandó tételként kezelik az ItemList jelölést, pedig a haszna erősen függ attól, mennyire rendezett a mögötte lévő termékadat, és hogyan kezeli az oldal a lapozást meg a szűrést. Ebben a cikkben végigmegyünk azon, mit ad ez a jelölés egy kategóriaoldalon, hol vannak a határai, és mikor jársz jobban, ha fel sem teszed.

Mit ad az ItemList jelölés egy kategóriaoldalon?

Az ItemList jelölés géppel olvasható formában rögzíti, mely termékek szerepelnek az oldalon, milyen sorrendben, és melyik URL-re mutatnak. Kategóriaoldalon ez elsősorban egyértelmű leírás a keresőknek és más feldolgozó rendszereknek, látványos találati elemet önmagában nem garantál.

Hivatalosan igazolt. A Google Search Central karusszel-dokumentációja az ItemList típust egy összefoglaló oldal és több részletoldal mintájára írja le, ahol a lista elemei a részletoldalak URL-jeire mutatnak. A klasszikus karusszel-megjelenést a dokumentáció néhány tartalomtípushoz köti, például recepthez, kurzushoz, filmhez és étteremhez. Emellett a Google leírt egy béta állapotú karusszel-funkciót, amely az Európai Gazdasági Térség országaiban termékeket, helyi vállalkozásokat és eseményeket tartalmazó listákra is vonatkozhat. Ez béta, a feltételei bármikor változhatnak, ezért bevezetés előtt mindig nézd meg az aktuális leírást. A Google termékjelölési irányelvei azt is rögzítik, hogy a Product jelölés egy konkrét termékről szóljon, kategóriaoldalra vagy terméklistára ne tedd fel.

Saját tapasztalat. A jelölés legkézzelfoghatóbb haszna sok webshopnál maga a bevezetés folyamata. Amikor a lista elemeit egyetlen forrásból kell legenerálni, gyorsan kiderül, hol van duplikált termék-URL, hol mutat a kategória átirányított vagy megszűnt termékre, és hol tér el a sorrend a sablonban és az adatbázisban.

Szakmai feltételezés. Az AI-alapú válaszmotorok és a vásárlást segítő ágensek egy része feldolgozhatja a JSON-LD blokkot, amikor egy oldal kínálatát próbálja összefoglalni, de erről nincs nyilvános, részletes leírás.

Miért a nyers termékadat rendberakásával kezdd?

Mert az ItemList csak tükrözi azt, ami a termékadatban van. Ha a forrás hibás, a jelölés a hibát gépi formában is publikálja, és a keresőnek egy újabb jelzést ad arról, hogy az oldal adatai nem megbízhatók.

Ezt tartjuk a téma legfontosabb gondolatának. A helyes sorrend az adatrendezés, utána a látható lista, és csak ezután a jelölés. Mielőtt bármilyen kódot írnál, nézd át ezeket:

• Minden terméknek egyetlen kanonikus URL-je van, és a kategória linkje pontosan ezt a címet használja, paraméter és kategóriaútvonal nélkül.
• A változatok kezelése eldöntött, vagyis tudod, hogy egy méret vagy szín külön elem a listában, vagy egy szülőtermék alá tartozik.
• A terméknevek egyediek és beszédesek, két különböző termék nem viseli ugyanazt a nevet.
• A megszűnt termékek URL-je rendezett (átirányítás vagy 404/410 válasz), és ezek a termékek nem jelennek meg a listában.
• A készlet és a láthatóság szabálya egyértelmű, tehát tudod, hogy a nem elérhető termék látszik-e a kategóriában.
• A kategória alapértelmezett sorrendje determinisztikus, ugyanarra a kérésre mindig ugyanazt a sorrendet adja.

Saját tapasztalat. Az utolsó pont meglepően gyakran sérül. Ha a sorrend véletlenszerű vagy személyre szabott, a lista két lekérés között is mást mutat, és ilyenkor a jelölés stabilitása eleve nem érhető el.

Mely mezőket érdemes megadni?

Kategóriaoldalon a minimum az itemListElement tömb, benne ListItem elemekkel, mindegyiknél position és url mezővel. Ez az összefoglaló oldal mintája, amelyet a Google dokumentációja is leír, és ennél a legkisebb az eltérés kockázata.

• Az @type értéke ItemList, oldalanként egy darab a terméklistához.
• Az itemListElement pontosan annyi ListItem elemet tartalmaz, ahány termék az adott oldalon látszik.
• A position egész szám, és a látható sorrendet követi.
• Az url a termék kanonikus, abszolút URL-je, ugyanaz, amelyre a rácsban a link mutat.
• A name opcionális, csak akkor add meg, ha szó szerint egyezik a látható névvel.
• A numberOfItems opcionális. Ha használod, az oldalon jelölt elemek számát írd bele, hogy ne mondjon ellent az itemListElement tartalmának.
• Az itemListOrder opcionális, a Schema.org szerint növekvő, csökkenő vagy rendezetlen sorrendet jelezhet.

Amit kategóriaoldalon kerülnék, az a teljes Product objektum ár- és készletadattal minden listaelemben. A Google irányelve szerint a termékjelölés egyedi termékoldalra való, és az ár a listában jellemzően gyorsabban elavul (gyorsítótár, akció, változatár), mint ahogy a jelölés frissül. Az árat és a készletet hagyd a termékoldalra, ott a helye.

Egy lapozott kategória második oldalának jelölése rövidítve, két elemmel így nézhet ki. A blokk egy application/ld+json típusú script elembe kerül.

{ "@context": "https://schema.org", "@type": "ItemList", "name": "Női túracipők", "numberOfItems": 24, "itemListOrder": "https://schema.org/ItemListUnordered", "itemListElement": [ { "@type": "ListItem", "position": 25, "url": "https://pelda.hu/termek/alpesi-gore-tex-noi-turacipo" }, { "@type": "ListItem", "position": 26, "url": "https://pelda.hu/termek/konnyu-noi-trekkingcipo" } ] }

Hogyan viszonyul a jelölés a lapozott oldalakhoz?

Minden lapozott oldal a saját, ténylegesen megjelenő termékeit jelöli. A második oldal ItemList-je pontosan a második oldalon látható termékeket tartalmazza, a teljes kategória listája egyik oldalon sem kerül a jelölésbe.

Hivatalosan igazolt. A Google lapozásról szóló útmutatója szerint minden lapozott oldalnak saját URL-je legyen (például ?page=2), az oldalak egymásra hagyományos, követhető linkkel mutassanak, és a lapozott oldalak kanonikus címe ne az első oldal legyen. A rel="next" és rel="prev" jelölést a Google már nem használja indexelési jelzésként.

Vegyünk egy példát. A Női túracipők kategóriában 87 termék van, oldalanként 24 jelenik meg, így négy oldal készül.

• Az 1. oldal (/noi-turacipo/) 24 elemet jelöl, 1-től 24-ig.
• A 2. oldal (/noi-turacipo/?page=2) 24 elemet jelöl, 25-től 48-ig.
• A 3. oldal 24 elemet jelöl, 49-től 72-ig.
• A 4. oldal 15 elemet jelöl, 73-tól 87-ig.

Mindegyik oldal saját magára kanonikusít, és a numberOfItems a 4. oldalon 15, a teljes kategória 87 terméke nem szerepel benne.

Szakmai feltételezés. A Schema.org nem írja elő, hogy a második oldalon a számozás 1-től vagy 25-től induljon. Mi a folytatólagos számozást javasoljuk (az 1-től induló sem hibás), mert az a vásárló szemszögéből látható sorrendet adja vissza, és a kategórián belül nincs két különböző termék ugyanazzal a pozícióval.

Mi a helyzet a szűrt és a rendezett nézetekkel?

A szűrt nézet jelölése az indexelési döntést követi. Ha a szűrt URL önálló, indexelhető céloldal, kaphat saját listát a saját elemeivel. Ha noindex, vagy a fő kategóriára kanonikusít, nem érdemes rá külön jelölést fenntartani.

A gyakorlatban három helyzet fordul elő.

• Önálló céloldal. Ha a „vízálló női túracipő” szűrés saját URL-t, címet és bevezetőt kapott, mert van rá valós keresési igény, a jelölése ugyanúgy készül, mint egy kategóriáé, csak a szűrt elemekkel.
• Technikai szűrés. A méret, ár vagy szín szerinti kombinációk jellemzően noindex vagy kanonikus címkével a fő kategóriára mutatnak. Itt a jelölés vagy elmarad, vagy a sablon automatikusan a látható elemeket adja ki, de külön energiát nem érdemes beletenni.
• Rendezés. Az ár vagy népszerűség szerinti rendezés ugyanazokat a termékeket mutatja más sorrendben. A jelölés a ténylegesen megjelenített sorrendet kövesse, külön jelölési változatot ne gyárts hozzá.

Hivatalosan igazolt. A Google lapozási útmutatója a végtelen görgetéshez és a „továbbiak betöltése” gombhoz is azt javasolja, hogy a tartalom lapozott, saját URL-lel elérhető oldalakon is megjelenjen. Ilyenkor a jelölés az adott lapozott oldal elemeihez tartozzon.

Saját tapasztalat. A szűrőkombinációk száma egy közepes webshopban is könnyen több ezerre nő. Ha ezek mindegyike saját jelölést kap, a hibák száma nő, a haszon viszont nem, mert ezek az oldalak többnyire amúgy sem indexelhetők.

Hogyan kerülöd el, hogy a lista eltérjen a látható tartalomtól?

Úgy, hogy a jelölést és a látható terméklistát ugyanabból a lekérdezésből, ugyanabban a kérésben állítod elő. Ha a kettő két külön úton készül, előbb-utóbb el fognak térni egymástól.

Hivatalosan igazolt. A Google általános irányelvei szerint a strukturált adat az oldal felhasználók számára látható tartalmát írja le, rejtett tartalmat ne jelölj meg. Az irányelvek megsértése esetén az oldal elveszítheti a kiemelt találati megjelenésre való jogosultságát, súlyosabb esetben kézi intézkedés is érheti.

A leggyakoribb eltérések, amelyekkel találkozunk:

• A JSON-LD gyorsítótárból érkezik, a rács élőben töltődik, így egy akció vagy készletváltozás után a kettő mást mutat.
• A kifutott termék eltűnik a rácsból, de a jelölésben bent marad.
• A jelölés az összes kategóriaterméket tartalmazza, a rács csak az aktuális oldalét.
• A termékek egy része később, JavaScripttel töltődik be, a jelölés pedig csak a szerveroldali első adagot ismeri, vagy fordítva.
• A rácson A/B teszt vagy személyre szabott sorrend fut, a jelölés az alapsorrendet mutatja.
• A rács linkje paraméteres URL-re mutat, a jelölés a kanonikusra.

A legegyszerűbb védekezés, ha a sablon egyetlen terméktömbön megy végig kétszer, egyszer a rácshoz, egyszer a JSON-LD-hez. Ha a bővítményed ezt nem tudja, inkább kapcsold ki a jelölését, mint hogy két forrás versenyezzen.

Mikor jobb kihagyni az egészet?

Akkor, ha a termékadat még rendezetlen, ha a lista tartalma kérésenként változik, vagy ha az oldalnak nincs önálló keresési szerepe. Ilyenkor a jelölés több hibalehetőséget hoz, mint amennyi hasznot.

• A termék-URL-ek duplikáltak, vagy a változatok kezelése még nincs eldöntve.
• A sorrend véletlenszerű, személyre szabott, vagy folyamatos tesztelés alatt áll.
• Az oldal belső keresési találati oldal, noindex szűrt nézet vagy kampányhoz készült ideiglenes lista.
• A platform nem tudja a jelölést ugyanabból a forrásból előállítani, mint a látható listát.
• A sablon és egy vagy több bővítmény már most is egymásnak ellentmondó jelölést ad ki. Ezt először rendbe kell tenni, csak utána érdemes újabbat hozzáadni.
• A kategória mindössze két-három terméket tartalmaz, így a listának alig van leírnivalója (ez szakmai feltételezés).

Szakmai feltételezés. A Google nyilvános közlései szerint a strukturált adat az oldal megértését és a kiemelt találati megjelenést segíti, általános rangsorolási előnyt nem ígér. Emiatt a kategóriaoldali ItemList elhagyásából önmagában nem számítunk visszaesésre, egy hibás, ellentmondásos jelölés viszont ronthatja az adatok megbízhatóságát.

Milyen lépésekben vezesd be egy többoldalas kategórián?

Röviden adat, indexelési döntés, egyetlen forrás, minimális mezők, ellenőrzés és fokozatos kiterjesztés. A Női túracipők példáján a lépések így néznek ki.

1. Rögzítsd a kategória állapotát. 87 termék, oldalanként 24, négy lapozott oldal ?page=N paraméterrel, determinisztikus alapsorrend.
2. Rakd rendbe a termékadatot a fenti lista szerint. Kanonikus URL, egyedi nevek, eldöntött változatkezelés, kivezetett megszűnt termékek.
3. Hozd meg az indexelési döntést. A lapozott oldalak indexelhetők és saját magukra kanonikusítanak, a szűrt nézetek közül csak a valódi céloldalak indexelhetők.
4. Állítsd át a sablont egyetlen forrásra, hogy ugyanaz a terméktömb adja a rácsot és a JSON-LD-t.
5. Számold a pozíciót képlettel, ez a (oldalszám - 1) × 24 + sorszám az oldalon, így a 3. oldal első eleme a 49. lesz.
6. Add ki a minimális mezőket (position, url, igény szerint name és numberOfItems), ár és készlet nélkül.
7. Teszteld tesztkörnyezetben mind a négy oldalt, különös figyelemmel a csonka utolsó oldalra.
8. Élesítsd egy-két kategórián, figyeld néhány hétig a Search Console jelentéseit, és csak hibamentes állapotban terjeszd ki a többi kategóriára.

Hogyan ellenőrizd, hogy a jelölés rendben van?

Az érvényes szintaxis csak az első szint. A valódi ellenőrzés az, hogy a jelölés minden lapozott oldalon pontosan azt írja le, amit a látogató lát.

• A Schema Markup Validator hiba nélkül olvassa a blokkot mind a négy oldalon.
• A Google Rich Results Test lefut, és látszik benne, hogy a Google értelmezi a jelölést. Kategóriaoldalnál ettől nem kell kiemelt találatot várni.
• Az itemListElement elemszáma egyezik a látható termékek számával, a 4. oldalon 15.
• A position értékek folyamatosak, nincs ismétlődés, és a 2. oldal a 25-tel indul.
• Minden url 200-as választ ad, átirányítás nélkül, és megegyezik a termékoldal kanonikus címével.
• A jelölés sorrendje megegyezik a rács sorrendjével alapértelmezett rendezésnél.
• Nem szerepel a jelölésben olyan termék, amely a rácson nem látszik.
• Oldalanként egy terméklistás ItemList van, nincs bővítményből származó második példány.
• A Search Console URL-ellenőrzésében a renderelt HTML tartalmazza a JSON-LD blokkot.
• Egy ár- vagy készletváltozás és a gyorsítótár ürítése után újra lefuttatod az összevetést.

Források és további olvasnivalók

• Google Search Central, Karusszel (ItemList) strukturált adatok dokumentáció
• Google Search Central, Karusszelek (béta) strukturált adatok dokumentáció
• Google Search Central, Termék strukturált adatok irányelvei
• Google Search Central, A strukturált adatokra vonatkozó általános irányelvek
• Google Search Central, Lapozás, fokozatos betöltés és ezek hatása a Google Keresésre
• Schema.org, ItemList és ListItem típusleírás
• W3C, JSON-LD 1.1 ajánlás