- A Rich Results Test azt mutatja, jogosult-e az oldal rich resultra; a Schema.org validátor csak a szintaxist és a séma-helyességet nézi.
- A hiányzó kötelező mező és a látható tartalommal nem egyező adat a két leggyakoribb, súlyos hiba.
- Nem minden jelölés vezet gazdag találathoz: sok típus csak tartalomértelmezést, entitás-tisztázást segít.
- A jelölés csak akkor éles, ha az oldalon renderelt HTML-ben is ott van a strukturált adat, nem egy nézetben.
- Az érvényes kód nem garancia a megjelenésre: a Google minőségi és tartalmi feltételeket is támaszt.
A strukturált adat az a gépi olvasásra szánt réteg, amivel egyértelművé teszed egy keresőnek vagy egy AI-asszisztensnek, hogy mi micsoda az oldaladon: ez egy termék, az az ára, ez egy GYIK, az egy recept elkészítési ideje. A jelölés önmagában nem ér semmit, ha hibás vagy ha nem egyezik azzal, amit a látogató lát. Ezért a validálás nem opcionális utómunka, hanem a folyamat része. Az alábbiakban végigveszem, milyen eszközökkel ellenőrizd, mit jelentenek pontosan a visszajelzések, és mik azok a hibák, amikkel a gyakorlatban a legtöbbször találkozom.
Melyik validátort mikor használd?
Két külön kérdést két külön eszköz válaszol meg. A Google Rich Results Test arra felel, hogy az oldal jogosult-e valamelyik gazdag találati megjelenésre. A Schema.org validátor (a korábbi Structured Data Testing Tool utódja) arra, hogy a JSON-LD nyelvtanilag és séma szempontjából helyes-e, függetlenül attól, hogy a Google csinál-e vele bármit.
Ez a különbség fontos, mert a két eszköz szándékosan mást mér. A Rich Results Test csak azokat a típusokat ismeri, amikhez a Google ténylegesen kínál gazdag megjelenést (például Product, FAQPage, Recipe, BreadcrumbList). Ha egy általad használt típust nem támogat gazdag találattal, a Rich Results Test simán azt írja, hogy nem talált jogosult elemet, miközben a jelölésed teljesen szabályos. Ilyenkor a Schema.org validátor mutatja meg, hogy a kód rendben van, csak épp nem rich-result-célra való.
A gyakorlatban így érdemes sorrendbe tenni: először a Schema.org validátorral ellenőrzöd, hogy a séma önmagában hibátlan-e, utána a Rich Results Testtel, hogy a Google szemével jogosult-e megjelenésre. A Google Search Console "Rich results" jelentései pedig már az éles, indexelt állapotot mutatják, jellemzően pár napos késéssel.
Mit jelent a figyelmeztetés a hibával szemben?
Mindkét eszköz kétféle jelzést ad. A hiba (error) azt jelenti, hogy egy kötelező mező hiányzik vagy rossz típusú, és emiatt az elem nem jogosult a gazdag találatra. A figyelmeztetés (warning) egy ajánlott, de nem kötelező mező hiányát jelzi: az elem így is jogosult lehet, de a teljesebb jelölés jobb megjelenést adhat. Egy warningtól még nem dől össze semmi, egy errortól viszont kiesik az adott elem a rich result köréből.
Hogyan néz ki egy hibás és egy javított jelölés?
A leggyakoribb baj az, hogy a kötelező mezők közül kimarad egy, vagy a jelölt érték nem egyezik a látható tartalommal. Nézzünk egy termékoldalt. Az alábbi jelölés a Rich Results Testben hibát dob, mert hiányzik a Product több gyakran elvárt eleme, és az offers blokk hiányos.
Előtte, hibás:
{ "@context": "https://schema.org", "@type": "Product", "name": "Kültéri LED reflektor 50W", "image": "reflektor.jpg" }
Itt több gond van egyszerre. A kép relatív útvonallal szerepel, holott teljes URL kell. Nincs offers, tehát nincs ár és pénznem, így a Google nem tud árat mutatni. Nincs description és nincs azonosító (például sku) sem.
Utána, javított:
{ "@context": "https://schema.org", "@type": "Product", "name": "Kültéri LED reflektor 50W", "image": "https://pelda.hu/kep/reflektor.jpg", "description": "IP65 vedelmu kulteri LED reflektor, 50W, 4000 lumen.", "sku": "LED-50W-4000", "brand": { "@type": "Brand", "name": "Pelda" }, "offers": { "@type": "Offer", "price": "12990", "priceCurrency": "HUF", "availability": "https://schema.org/InStock" } }
A javított változatban minden kötelező és ajánlott mező a helyén van, a kép teljes URL, az ár és a pénznem külön mezőben szerepel, a készlet állapota pedig séma-URL formában. Fontos, hogy a price értéke szám legyen, ne tartalmazzon szóközt, pénznemjelet vagy ezres tagolást, mert attól a validátor elhasal.
Miért bukik el a jelölés, ha a kód szintaktikailag helyes?
Mert a Google azt is nézi, hogy a jelölt adat megegyezik-e a felhasználó által látott tartalommal. Ez az egyik legalattomosabb hibaosztály. A kód átmegy a Schema.org validátoron, mert nyelvtanilag rendben van, de a Rich Results Test vagy később a Search Console mégis kifogásolja, mert a jelölésben más ár, más értékelés vagy más termék szerepel, mint az oldalon. A Google hivatalos irányelve egyértelmű ebben: a strukturált adat nem tartalmazhat olyat, ami a látogató elől rejtve van vagy amit a látható tartalom nem támaszt alá.
A saját tapasztalatom szerint ez a tartalom-eltérés a leggyakoribb ok, amiért egy technikailag hibátlan jelölés mégsem hoz gazdag találatot, vagy amiért a Search Cons/ Console kézi intézkedést jelez. Tipikus esetek: a sablon minden termékhez ugyanazt a csillagos értékelést írja, miközben az oldalon nincs is látható értékelés; vagy a GYIK-jelölésben olyan kérdés-válasz szerepel, ami a látható oldalon nincs ott.
Mikor lesz rich result, és mikor csak tartalomértelmezés?
Rich result csak a Google által támogatott típusoknál lehetséges, és ott sem garantált; a többi jelölés a tartalom és az entitások értelmezését segíti. Érdemes fejben szétválasztani a két célt, mert másképp mérsz sikert.
A gazdag találatot célzó típusok azok, amikhez a Google dokumentált megjelenést kínál a keresőben. Ilyen a csillagos értékelés, a termékár, a recept elkészítési ideje, a morzsamenü, az eseményinfó, a GYIK-harmonika. Ha ezekhez hibátlan a jelölés és teljesül a minőségi feltétel, jó eséllyel megjelenhet a gazdag elem, de a Google fenntartja a jogot, hogy nem mutatja. A megjelenés tehát soha nem garantált, csak jogosultságot szerzel vele.
A tartalomértelmezést segítő jelölések nem hoznak látványos találati elemet, viszont segítik a keresőt és az AI-asszisztenseket abban, hogy megértsék, ki vagy és miről szól az oldal. Ilyen az Organization a márkaadatokkal, a Person, a WebSite, az Article szerzővel és dátummal, vagy a sameAs hivatkozások a hivatalos profiljaidra. Ezek nem a keresőben villannak fel, hanem az entitás-építést és a tartalom kontextusát erősítik. A szakmai feltételezésem az, hogy ez a réteg egyre fontosabb lesz a válaszmotorok terjedésével, mert egy AI-asszisztens ezekből az egyértelmű, gépi jelekből könnyebben rakja össze, mit állítasz magadról.
Számít-e, hogy JSON-LD, mikroadat vagy RDFa?
Mindhárom formátumot érti a Google, de a hivatalosan ajánlott forma a JSON-LD. A JSON-LD előnye, hogy egy külön script blokkban él, elkülönül a látható HTML-től, könnyebb karbantartani és kevésbé törik el egy sablonmódosításkor. A mikroadat és az RDFa a HTML-elemekbe szőve helyezi el a jelölést, ami nagyobb oldalakon hamar átláthatatlan lesz. Új projektnél gyakorlatilag mindig JSON-LD-t érdemes választani.
Miért mutat mást a validátor, mint amit az oldalon látok?
Mert a validátor a ténylegesen renderelt HTML-t nézi, és ha a jelölést JavaScript injektálja utólag, előfordulhat, hogy a beolvasott pillanatban még nincs ott. Ez a második nagy hibaforrás a tartalom-eltérés mellett. Ha a strukturált adatot egy kliensoldali script rakja be, tesztelni a renderelt kódon kell, nem a nyers forráson.
Két praktikus módszer a valós állapot ellenőrzésére:
- A Rich Results Testben nézd meg a "Rendered HTML" vagy a beolvasott forrás nézetet, és keresd rá, hogy tényleg benne van-e a JSON-LD blokk.
- Ha URL-t adsz meg a tesztnek (nem beillesztett kódot), akkor azt látod, amit a Googlebot lát, ami közelebb áll az éles állapothoz, mint egy másolt kódrészlet.
Fontos különbség: ha a validátorba beillesztett kóddal tesztelsz, csak azt a szövegdarabot vizsgálod, nem a valós oldalt. Az élesedés előtt mindig URL-alapú tesztet is futtass, mert csak az mutatja meg, hogy a jelölés tényleg kijut-e a látogatóhoz.
Milyen lépésekben validálj a gyakorlatban?
Érdemes egy rögzített ellenőrzési sort követni, hogy ne maradjon ki lépés. Az alábbi menet nálam bevált, és nagyjából minden jelölés-típusra alkalmazható.
- Válaszd ki a típust a Schema.org szótárból, és nézd meg a Google adott típusra vonatkozó irányelvét, hogy mi a kötelező és mi az ajánlott mező.
- Írd meg a JSON-LD-t, és futtasd a Schema.org validátoron. Itt a szintaxist és a séma-helyességet ellenőrzöd.
- Futtasd a Rich Results Testet, elsőként a beillesztett kóddal, majd élesedés után URL-lel is. Nézd, jogosult-e gazdag találatra, és hogy vannak-e figyelmeztetések.
- Vesd össze a jelölt értékeket a látható oldallal: minden ár, értékelés, kérdés-válasz, dátum egyezzen a renderelt tartalommal.
- Élesítés után pár nappal ellenőrizd a Search Console megfelelő jelentését, mert az mutatja az indexelt, valós állapotot és az esetleges lefedettségi hibákat.
Ez a rutin nem garantál gazdag megjelenést, de jó eséllyel kiszűri azt a hibatípust, ami miatt egyébként hetekig találgatnál, hogy miért nem történik semmi.
Mik a leggyakoribb hibák egy listában?
- Hiányzó kötelező mező: például
Product-nál nincsoffersvagyname. Ez errort ad, és kizárja a rich resultot. - Tartalom-eltérés: a jelölésben más érték szerepel, mint az oldalon. Technikailag helyes, mégis kézi intézkedést hozhat.
- Rossz értéktípus: az árban pénznemjel vagy szóköz, a dátumban nem ISO 8601 formátum.
- Relatív kép-URL: teljes, abszolút URL kell, különben a kép nem használható.
- Kliensoldali jelölés, ami nem renderelődik: a nyers forrásban látszik, a Googlebot nézetében nem.
- Nem támogatott típussal várt rich result: a jelölés szabályos, de a Google ehhez nem kínál gazdag megjelenést.
- Duplikált vagy ütköző jelölés: ugyanarra az entitásra két, egymásnak ellentmondó blokk kerül az oldalra.
Források és további olvasnivalók
- Google Search Central: Structured data general guidelines és az egyes típusok (Product, FAQ, Breadcrumb, Article) dokumentációi
- Google Rich Results Test (search.google.com/test/rich-results)
- Schema.org Validator (validator.schema.org)
- Schema.org: a hivatalos szótár és típusdefiníciók
- Google Search Console súgó: Rich results és Enhancement jelentések
- W3C: JSON-LD 1.1 specifikáció
Gyakori kérdések
Mi a különbség a Rich Results Test és a Schema.org validátor között?
A Rich Results Test azt mutatja meg, hogy az oldal jogosult-e valamelyik Google által támogatott gazdag találatra, és csak a rich-result-képes típusokat ismeri. A Schema.org validátor ezzel szemben a JSON-LD nyelvtani és séma-helyességét ellenőrzi, függetlenül attól, hogy a Google csinál-e vele gazdag megjelenést. A kettőt együtt érdemes használni.
Miért nem jelenik meg gazdag találat, ha a kódom hibátlan?
Az érvényes kód csak jogosultságot ad, nem garantál megjelenést. A Google minőségi és tartalmi feltételeket is támaszt, és fenntartja a jogot, hogy nem mutatja a gazdag elemet. Gyakori ok az is, hogy a jelölt adat nem egyezik a látható tartalommal, vagy hogy az adott típushoz a Google egyáltalán nem kínál rich resultot.
Mit jelent a tartalom-eltérés a strukturált adatban?
Azt, hogy a jelölésben olyan érték szerepel, amit a látogató által látott oldal nem támaszt alá, például minden termékhez azonos csillagos értékelés, miközben az oldalon nincs látható értékelés. Ez a Google irányelve szerint szabálysértés, és kézi intézkedést vagy a gazdag találat elvesztését okozhatja, még akkor is, ha a kód szintaktikailag helyes.
Melyik formátumot használjam: JSON-LD, mikroadat vagy RDFa?
A Google mindhármat érti, de hivatalosan a JSON-LD-t ajánlja. Ez külön script blokkban él, elkülönül a látható HTML-től, könnyebb karbantartani és kevésbé törik el egy sablonmódosításnál. Új projektnél szinte mindig a JSON-LD a praktikus választás.
Miért lát mást a validátor, mint amit én az oldalon látok?
Mert a validátor a renderelt HTML-t vizsgálja. Ha a jelölést kliensoldali JavaScript rakja be utólag, előfordulhat, hogy a beolvasás pillanatában még nincs ott. Ezért érdemes URL-alapú tesztet is futtatni és megnézni a renderelt forrást, nem csak a nyers HTML-t vagy egy beillesztett kódrészletet.
Minden strukturált adat vezet gazdag találathoz?
Nem. Csak a Google által támogatott típusok jogosultak gazdag megjelenésre, és ott sem garantált. A többi jelölés, például az Organization, a Person vagy a sameAs hivatkozások, nem a keresőben villan fel, hanem a tartalom és az entitások értelmezését segíti, ami a válaszmotorok szempontjából egyre fontosabb lehet.
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.