Structured data: teljes útmutató

A structured data, vagyis strukturált adat, olyan géppel olvasható leírás egy weboldal tartalmáról, amely egyértelműen megmondja a keresőnek, hogy mi szerepel az oldalon: egy termék és az ára, egy cikk szerzője, egy esemény időpontja. Jellemzően JSON-LD formátumban kerül a HTML-be. Nem közvetlen rangsorolási tényező, de a tartalom pontosabb értelmezését segíti, és bizonyos kiemelt találatok feltétele.

Alapfogalmak

Egy weboldal szövegét az ember könnyen értelmezi: ránéz egy termékoldalra, és látja, melyik szám az ár, melyik a cikkszám, és melyik mondat a vásárlói vélemény. A kereső ugyanezt a szöveget statisztikai és nyelvi módszerekkel próbálja kitalálni, ami sokszor sikerül, de nem mindig. A strukturált adat ezt a találgatást váltja ki egy külön, szabványos formájú leírással, amely kimondja: ez az objektum egy termék, ennek ez a neve, ez az ára, ebben a pénznemben, és jelenleg raktáron van.

A strukturált adat tehát nem a látogatónak szól, hanem a gépnek. A böngésző nem jeleníti meg, a keresők, közösségi platformok és egyéb feldolgozó rendszerek viszont kiolvassák. Fontos elv, hogy a strukturált adatnak ugyanazt kell állítania, amit az oldal látható tartalma: nem kiegészítő információforrás, hanem a meglévő tartalom egyértelmű, gépi fordítása.

A három alapréteg

A témát három, egymásra épülő rétegként érdemes elképzelni, mert a gyakorlati hibák nagy része abból fakad, hogy valaki összekeveri őket.

Réteg	Mit határoz meg?	Példa
Szókészlet (vocabulary)	Milyen típusok és tulajdonságok léteznek, mit jelentenek	A schema.org szókészlete, amelyet a nagy keresők közösen támogatnak
Formátum (szintaxis)	Hogyan kerül a leírás a HTML-be	JSON-LD, Microdata, RDFa
Felhasználási szabályok	Mit fogad el és mit jelenít meg egy adott kereső	A Google kiemelt találatokra vonatkozó irányelvei

Ebben az útmutatóban a második és a harmadik rétegre, valamint a stratégiára koncentrálunk: mit jelent az adatmodellezés, hogyan dolgozza fel a kereső a jelölést, és melyik oldaltípusra milyen adat kerüljön. A konkrét típusok és tulajdonságok részletes leírása a Schema markup: teljes útmutató cikkben található.

Entitás, tulajdonság, kapcsolat

A strukturált adat gondolkodásmódja entitásokra épül. Az entitás egy azonosítható dolog: egy cég, egy személy, egy termék, egy cikk. Minden entitásnak vannak tulajdonságai (név, ár, dátum), és kapcsolatai más entitásokhoz (a cikket egy személy írta, a személy egy cégnél dolgozik, a cég egy weboldalt üzemeltet). Ha a jelölés ezt a hálót pontosan leírja, a kereső nem egyes oldalakat lát, hanem egy összefüggő képet arról, hogy ki áll a webhely mögött és miről szól.

Kiemelt találat és jogosultság

A kiemelt találat (rich result) a szokásos kék link és leírás mellett megjelenő extra elem: csillagos értékelés, ár és készletinformáció, recept elkészítési ideje, eseménydátum. A strukturált adat ezeknek szükséges, de nem elégséges feltétele. Helyes jelölés mellett is a kereső dönti el, hogy megjeleníti-e a kiemelést, ezért pontosabb a jogosultság kifejezés: a jelöléssel az oldal jogosulttá válik, garanciát nem kap.

Hogyan működik?

A folyamat a feltérképezéssel kezdődik. A Googlebot letölti az oldalt, és a HTML feldolgozása során megkeresi a strukturált adatot. JSON-LD esetén ez egy külön script blokk, Microdata és RDFa esetén a HTML-elemekhez kapcsolt attribútumok. Ha a jelölést JavaScript illeszti be, a kereső csak a renderelés után látja, ami a Google-nél általában működik, de késleltetést és hibalehetőséget hordoz, ezért a szerveroldalon kiírt jelölés a biztonságosabb.

A kiolvasott adatot a kereső értelmezi: azonosítja a típusokat, ellenőrzi, hogy a tulajdonságok értéke a várt formájú-e (dátum, szám, URL), és összeveti a látható tartalommal. Ezután két dolog történhet. Egyrészt az adat bekerülhet abba a tudásba, amelyet a kereső az entitásokról gyűjt, másrészt az oldal jogosult lehet egy vagy több kiemelt találattípusra, ha teljesíti az adott típus kötelező mezőit és minőségi irányelveit.

A feldolgozás lépései egy pillantásra

Feltérképezés: a kereső letölti a HTML-t.
Renderelés, ha a jelölés JavaScriptből érkezik.
Kinyerés: a JSON-LD blokkok, illetve az attribútumok beolvasása.
Érvényesítés: szintaktikai helyesség, típusok és kötelező mezők.
Minőségi ellenőrzés: egyezik-e az adat a látható tartalommal, megfelel-e az irányelveknek.
Felhasználás: entitásértelmezés, illetve kiemelt találat megjelenítése, ha a kereső úgy dönt.

A negyedik és az ötödik lépés közötti különbség a gyakorlatban nagyon fontos. Egy jelölés lehet szintaktikailag hibátlan, és a teszteszköz zöld pipát mutathat rá, miközben a kereső mégsem jelenít meg kiemelést, mert például az értékeléseket a cég saját magáról írta, vagy a jelölt ár nem szerepel az oldalon. A validátor a formát ellenőrzi, a szabályoknak való megfelelést csak részben.

Mire nem való a strukturált adat?

Nem pótolja a tartalmat. Ha egy oldalon nincs recept, a recept jelölés nem teszi receptoldallá, és az irányelvekkel ellentétes jelölés kézi intézkedést is vonhat maga után. Nem is rangsorolási trükk: a Google nyilvánosan úgy kommunikál, hogy a strukturált adat önmagában nem javítja a helyezést. A hatása közvetett: pontosabb értelmezés, és ha megjelenik kiemelés, feltűnőbb találat, ami jó esetben több kattintást hozhat. Ez utóbbit viszont minden webhelyen mérni kell, nem lehet előre garantálni.

Fő módszerek

Három elterjedt formátum létezik a strukturált adat HTML-be illesztésére. Mindhárom ugyanazt a szókészletet tudja kifejezni, a különbség abban van, hogy hol él az adat, és mennyire fonódik össze a megjelenítéssel. A Google mindhármat támogatja, és a JSON-LD-t ajánlja, ha a webhely technikai háttere megengedi.

JSON-LD

A JSON-LD egy különálló script blokk, jellemzően a head részben vagy a body végén, amely JSON formában írja le az entitásokat. Legnagyobb előnye, hogy független a HTML szerkezetétől: a sablon átalakítása nem töri el, a fejlesztő egy helyen, egyben látja az egész adatmodellt, és könnyen generálható adatbázisból. Hátránya, hogy mivel elválik a látható tartalomtól, könnyebb olyan adatot írni bele, amely nem egyezik az oldallal, például egy régi árat, amelyet a sablon már frissített, a JSON-LD viszont nem.

Microdata

A Microdata HTML-attribútumokkal (itemscope, itemtype, itemprop) jelöli meg a meglévő elemeket. Előnye, hogy az adat és a látható tartalom fizikailag ugyanaz, így nehezebb eltérést létrehozni. Hátránya, hogy a jelölés szétszóródik a sablonban, egy dizájnváltás könnyen eltávolít egy attribútumot, és a beágyazott entitások kezelése bonyolult. Régebbi rendszerekben és egyes webshopmotorokban ma is gyakran találkozni vele.

RDFa

Az RDFa szintén attribútum alapú (vocab, typeof, property), és a szemantikus web szabványaiból érkezik. Rugalmasabb a Microdatánál, több szókészletet is képes keverni, de keresőoptimalizálási célra ritkábban választják. Leginkább olyan rendszerekben fordul elő, amelyek alapból RDFa kimenetet adnak.

Szempont	JSON-LD	Microdata	RDFa
Hol él az adat?	Külön script blokkban	HTML-attribútumokban	HTML-attribútumokban
Sablonváltás hatása	Általában nem érinti	Könnyen eltörhet	Könnyen eltörhet
Eltérés a látható tartalomtól	Nagyobb kockázat	Kisebb kockázat	Kisebb kockázat
Generálás adatbázisból	Egyszerű	Sablonfüggő	Sablonfüggő
Mikor válaszd?	Új fejlesztés, CMS, webshop	Meglévő, működő jelölés	Ha a rendszer ezt adja

Stratégia: melyik oldal milyen adatot kapjon?

A formátumnál fontosabb döntés, hogy mit jelölünk. A leggyakoribb hiba nem a rossz szintaxis, hanem a stratégia hiánya: egy bővítmény minden oldalra rárak valamilyen általános jelölést, a fontos oldaltípusok viszont nem kapják meg azt, ami igazán számítana. Érdemes oldaltípusonként gondolkodni, és minden típusnál megkérdezni: milyen entitás a fő tárgya ennek az oldalnak, és milyen tulajdonságai láthatók rajta?

Oldaltípus	Fő entitás	Kiegészítő adat	Prioritás
Kezdőlap	Szervezet és webhely	Logó, elérhetőség, közösségi profilok	Magas, egyszer kell jól megcsinálni
Termékoldal	Termék	Ajánlat (ár, pénznem, készlet), valódi értékelések	Magas, sok oldal, kiemelésre jogosító
Blogcikk	Cikk	Szerző, dátumok, kiadó	Közepes
Helyi üzlet oldala	Helyi vállalkozás	Cím, nyitvatartás, telefonszám	Magas helyi keresésnél
Kategóriaoldal	Lista, morzsamenü	Navigációs útvonal	Alacsony vagy közepes
Kapcsolat, adatvédelem	Általában elég a morzsamenü	Nincs	Alacsony

Döntési szabály a bevezetéshez

Saját gyakorlatunkban egy egyszerű háromkérdéses szűrőt használunk, mielőtt egy jelölést bevezetnénk. Először: látható-e az adat az oldalon a felhasználó számára? Ha nem, nem jelöljük. Másodszor: van-e megbízható forrása az adatnak (adatbázis, CMS mező), amelyből automatikusan frissül? Ha nincs, és kézzel kellene karbantartani, csak akkor vezetjük be, ha az oldal kiemelten fontos. Harmadszor: jogosít-e valamilyen kiemelésre vagy segíti-e az entitás pontos azonosítását? Ha egyiket sem, a jelölés alacsony prioritású, és a sor végére kerül.

Gyakori hibák

A strukturált adat hibái két csoportba sorolhatók. Az egyik a technikai hiba, amelyet a validátorok és a Search Console jelentései kimutatnak: hiányzó kötelező mező, rossz dátumformátum, érvénytelen JSON. A másik a tartalmi és irányelvi hiba, amelyet az eszközök gyakran nem jeleznek, mégis megakadályozhatja a kiemelést, súlyosabb esetben kézi intézkedéshez vezethet.

Technikai hibák

Érvénytelen JSON: egy hiányzó vessző vagy idézőjel miatt az egész blokk olvashatatlan lesz, nem csak egy mező.
Rossz értékformátum: az ár pénznemjellel együtt szövegként, a dátum magyar formában, nem szabványos alakban.
Hiányzó kötelező tulajdonság egy kiemelt találattípusnál, például az ajánlatból kimarad az ár vagy a pénznem.
Duplikált, egymásnak ellentmondó jelölés: a téma és egy bővítmény is kiír egy-egy termék entitást, eltérő adatokkal.
Csak JavaScriptből érkező jelölés, amely renderelési hiba esetén egyáltalán nem jelenik meg a kereső számára.
Relatív vagy hibás URL-ek a képeknél és azonosítóknál.

Tartalmi és irányelvi hibák

Az oldalon nem látható adat jelölése, például rejtett értékelések vagy egy másik oldalról átvett ár.
Saját magáról írt értékelések jelölése a cég oldalán, amelyet a Google irányelvei korlátoznak.
Elavult adat: lejárt esemény, régi ár, már nem elérhető termék készleten jelölve.
Félrevezető típusválasztás: egy kategóriaoldal egyetlen termékként jelölve, vagy egy szolgáltatásoldal receptként.
Minden oldalra ugyanaz az általános jelölés, amely semmit nem mond a konkrét tartalomról.

A legalattomosabb a szinkronhiba. A sablon az árat a friss adatbázis-mezőből olvassa, a JSON-LD viszont egy gyorsítótárazott vagy kézzel beírt értéket mutat. A látogató helyes árat lát, a kereső mást, és ha az eltérést a Merchant Center vagy a keresőminőség-ellenőrzés észleli, az következményekkel járhat. A megoldás mindig az, hogy a látható tartalom és a jelölés ugyanabból a forrásból táplálkozzon.

Gyakori félreértés az is, hogy a strukturált adat elrejtése vagy tiltása ugyanúgy működik, mint az oldalé. Ha egy oldal noindex utasítást kap a meta robots címkében, a rajta lévő jelölés sem fog kiemelt találatot hozni, hiszen maga az oldal sem jelenik meg. Ha pedig a robots.txt tiltja a feltérképezést, a kereső a jelölést el sem olvassa. Ezért a strukturált adat ellenőrzésénél mindig nézd meg azt is, hogy az oldal egyáltalán indexelhető-e.

Mérés

A strukturált adat mérése három szinten történik: érvényes-e a jelölés, felhasználja-e a kereső, és hoz-e üzleti eredményt. A legtöbb csapat megáll az első szinten, pedig a döntésekhez a második és a harmadik kell.

Érvényesség

Az egyes oldalak ellenőrzésére a Google Kiemelt találatok tesztje (Rich Results Test) és a Schema Markup Validator szolgál. Az előbbi azt mutatja meg, mely Google kiemelésekre jogosult az oldal a jelölés alapján, az utóbbi általánosabb, a szókészlet szerinti helyességet vizsgálja. Webhelyszintű képhez a Search Console Fejlesztések, illetve kiemelt találatokra vonatkozó jelentései adnak áttekintést típusonként: hány elem érvényes, hány figyelmeztetéses és hány hibás. Nagy webhelyen egy feltérképező programmal is érdemes végigmenni, amely oldaltípusonként kigyűjti a jelöléseket, így kiderül, hol hiányzik teljesen.

Felhasználás és hatás

A Search Console Teljesítmény jelentésében a keresési megjelenés szerinti szűrő mutatja, mely kiemelt találattípusok jelentek meg, és mennyi megjelenést, kattintást hoztak. Ez az a pont, ahol kiderül, hogy a jogosultság valódi megjelenéssé vált-e. A hatás méréséhez az a legtisztább módszer, ha egy oldalcsoporton vezeted be a jelölést, egy hasonló csoportot pedig egyelőre változatlanul hagysz, és néhány hétig összeveted a két csoport átkattintási arányát. Szezonális vagy algoritmusfrissítés miatti ingadozás mindkét csoportot érinti, így a különbség jobban köthető a jelöléshez.

Kidolgozott példa: egy webshop bevezetése

Az alábbi eset szemléltető, kitalált forgatókönyv, a módszert mutatja, nem valós mérést. Egy kisebb kerti bútor webshop körülbelül kétszáz termékoldallal rendelkezik, és a témája egy általános jelölést ír ki minden oldalra, amely csak a webhely nevét tartalmazza. Az első lépés a leltár: feltérképező programmal kigyűjtjük oldaltípusonként a meglévő jelöléseket, és kiderül, hogy a termékoldalakon nincs termék entitás, a blogon pedig két bővítmény is kiír cikk jelölést, eltérő szerzővel.

A második lépés az adatmodell: rögzítjük, hogy a kezdőlapon egyszer, egyértelmű azonosítóval szerepel a szervezet, a termékoldalak termék entitást kapnak ajánlattal, amely az árat és a készletet ugyanabból az adatbázis-mezőből veszi, mint a látható ár, a blog pedig egyetlen forrásból kap cikk jelölést, a szervezetre hivatkozó kiadóval. A felesleges bővítményt kikapcsoljuk. A harmadik lépés a próba: tíz termékoldalt ellenőrzünk a Kiemelt találatok tesztjével, majd a teljes oldalcsoportot a feltérképezővel. A negyedik lépés a mérés: a termékoldalak felét a bevezetés első hetében élesítjük, a másik felét két héttel később, és a Search Console-ban a keresési megjelenés szűrővel figyeljük, mikor és hol jelennek meg a termékkiemelések.

Ellenőrzőlista bevezetés előtt és után

#	Ellenőrzés	Eszköz
1	Minden oldaltípusnak van meghatározott fő entitása	Oldaltípus-táblázat
2	A jelölt adat látható az oldalon	Kézi szúrópróba
3	A jelölés és a látható tartalom ugyanabból a forrásból jön	Sablon és CMS átnézése
4	Nincs duplikált vagy ellentmondó entitás egy oldalon	Feltérképező program
5	A kötelező mezők minden kiemelésre szánt típusnál megvannak	Kiemelt találatok tesztje
6	A jelölés a HTML forrásban is megjelenik, nem csak renderelés után	Forráskód nézet
7	Az oldal indexelhető és feltérképezhető	URL-ellenőrzés a Search Console-ban
8	A webhelyszintű jelentésekben nem nő a hibák száma	Search Console kiemelt találat jelentések
9	A megjelenések és kattintások oldalcsoportonként mérve vannak	Teljesítmény jelentés, keresési megjelenés szűrő

A lista első négy sora stratégiai és adatminőségi kérdés, ezeket egyszer kell alaposan végiggondolni, és minden sablonváltáskor újra átnézni. Az ötödiktől a hetedikig tartó sorok technikai ellenőrzések, amelyeket minden élesítés előtt érdemes lefuttatni. Az utolsó kettő a folyamatos mérés, havi rendszerességgel elegendő, kivéve közvetlenül egy nagyobb változtatás után, amikor hetente érdemes ránézni.

Kapcsolódó részletes útmutatók

A strukturált adat a technikai SEO része, és csak akkor ér valamit, ha az oldal feltérképezhető és indexelhető. Egy hibátlan jelölés egy olyan oldalon, amelyet a kereső el sem ér, vagy amelyet noindex utasítás zár ki a találatok közül, semmilyen eredményt nem hoz. Ezért a bevezetés sorrendjét érdemes úgy felépíteni, hogy előbb az alapok legyenek rendben, és csak utána jöjjön a jelölés finomhangolása.

Javasolt olvasási sorrend

Technikai SEO: a teljes témakör: az áttekintő oldal, amely megmutatja, hol helyezkedik el a strukturált adat a többi technikai feladat között.
Robots.txt: teljes útmutató: ha egy oldalcsoport feltérképezése tiltott, a kereső a rajta lévő jelölést sem olvassa el, ezért először ezt érdemes ellenőrizni.
Meta robots: teljes útmutató: az indexelési utasítások oldalszintű kezelése, amely eldönti, hogy egy jelölt oldal egyáltalán megjelenhet-e a találatok között.
X-Robots-Tag: teljes útmutató: ugyanez HTTP-fejlécben, amely a nem HTML fájloknál és a kiszolgálószintű szabályoknál fontos.
XML sitemap: teljes útmutató: segít, hogy a kereső gyorsan megtalálja azokat az oldalakat, amelyeken új vagy frissített jelölés van.
Schema markup: teljes útmutató: a konkrét típusok, tulajdonságok és kódminták, vagyis a szókészlet szintű részletek, amelyeket ez a cikk szándékosan nem tárgyal.

Ha most kezded, a gyakorlati lépés egyszerű: készítsd el az oldaltípus-táblázatot a saját webhelyedre, jelöld meg benne, hol van már jelölés és hol hiányzik, majd a döntési szabály alapján válassz ki egyetlen oldaltípust az első körre. A típusok és tulajdonságok kiválasztásához a schema markup útmutatót használd, az indexelhetőség ellenőrzéséhez a robots útmutatókat, az eredményt pedig a mérésnél leírt módon oldalcsoportonként kövesd.

A két cikk közötti munkamegosztás röviden: ez az útmutató arra válaszol, hogy miért és hol érdemes strukturált adatot használni, milyen formátumban, és hogyan ellenőrizd a hatását. A schema markup útmutató arra, hogy pontosan milyen típust és milyen tulajdonságokat írj bele egy adott oldal jelölésébe. Ha egy konkrét hibaüzenetet kapsz a Search Console-ban, például hiányzó mezőről, akkor ott találod a mezők jelentését, ha viszont azt kell eldöntened, hogy egy oldalcsoport kapjon-e egyáltalán jelölést, és ki tartsa karban, akkor az itteni döntési szabály és ellenőrzőlista a kiindulópont. Sablonváltás vagy migráció előtt mindkettőt érdemes újra átnézni, mert a jelölés az egyik első dolog, ami egy új téma bevezetésekor csendben elveszik.