Strukturált adatok: amit tudnod kell róla

Scheo · 2026-08-14 · Frissítve: 2026-09-11 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha beírod a keresőbe, hogy „strukturált adatok”, általában három dolog valamelyikét akarod: megérteni, hogy mi ez egyáltalán, eldönteni, hogy kell-e a te oldaladra, vagy megtalálni a konkrét lépéseket a bevezetéshez és teszteléshez. Ez a cikk mindhármat végigveszi, a fogalomtól a másolható kódrészletig és az ellenőrzőlistáig.

Mit jelent pontosan a strukturált adat?

A strukturált adat egy géppel olvasható címkeréteg a weboldaladon, ami a látogató számára láthatatlan, de a keresőmotoroknak és az AI-rendszereknek egyértelműen megmondja, hogy az oldalon lévő szövegdarabok mit jelentenek: ez itt egy cégnév, ez egy nyitvatartás, ez egy recept elkészítési ideje, ez pedig egy szerző.

Az ember ránéz egy oldalra, és látja, hogy „Hétfő: 8:00-16:00” az a nyitvatartás. A gép ezt nem tudja biztosan, csak sejti. A strukturált adat ezt a sejtést cseréli le állításra. A szótár, amiből a fogalmak jönnek, a Schema.org: ez egy közös típusgyűjtemény (Organization, Product, Article, FAQPage, LocalBusiness és még sok száz további), amit a Google, a Microsoft, a Yahoo és a Yandex közösen tart karban.

Érdemes három fogalmat szétválasztani, mert a gyakorlatban gyakran összekeverik őket. A szótár a Schema.org (minek hogy hívjuk). A formátum a JSON-LD, a Microdata vagy az RDFa (hogyan írjuk le a HTML-ben). A megjelenés pedig a gazdag találat, amiről a Google a saját szabályai alapján dönt. Attól, hogy a szótárt és a formátumot hibátlanul használod, a megjelenés még nem jár automatikusan.

Hivatalosan igazolt: a Schema.org szókészletét a felsorolt keresőmotorok alapították és fejlesztik, a Google pedig külön dokumentálja, hogy a Schema.org típusaiból melyeket használja ténylegesen.

Miért érdemes vele foglalkozni, ha közvetlenül nem javít a helyezésen?

Rövid válasz: mert a strukturált adat nem a rangsorolást mozgatja, hanem azt, hogy hogyan néz ki és mennyire jól értelmezhető a tartalmad. A Google többször megerősítette, hogy a strukturált adat önmagában nem rangsorolási tényező, viszont a gazdag találatok (csillagos értékelés, GYIK-lenyíló, recept-adatok, termékadatok, esemény-időpontok) megjelenésének technikai feltétele.

A gyakorlati haszon három szinten jelentkezik:

• Megjelenés a találati listában: több hely, több információ, ami javíthatja az átkattintási arányt.
• Egyértelműség: a kereső nem következtet, hanem tudja, hogy a cikk szerzője X, a frissítés dátuma Y, a szolgáltatási terület Z.
• Entitás-építés: a cégedről szóló adatok (név, logó, profilok, elérhetőség) összekapcsolhatók egy azonosított entitássá, ami a tudásgráf-jellegű megjelenítéseknek az alapja.

Van egy negyedik, ritkábban emlegetett haszon is: a rendrakás kényszere. Ahhoz, hogy kitöltsd egy LocalBusiness séma mezőit, el kell döntened, mi a pontos, hivatalos cégnév, melyik a valóban figyelt telefonszám, és mely közösségi profilok tartoznak hozzád. Ez az adategyeztetés önmagában is javítja, mennyire egységesen jelensz meg mindenhol.

Saját tapasztalat: a magyar kkv-oldalak nagy részén nem az a probléma, hogy hiányzik a strukturált adat, hanem hogy három különböző bővítmény tesz fel egymásnak ellentmondó verziót ugyanarról az oldalról. Ilyenkor a rendrakás többet ér, mint bármilyen új séma hozzáadása.

Melyik formátumot válaszd: JSON-LD, Microdata vagy RDFa?

JSON-LD-t. Ez a rövid válasz, és a Google dokumentációja is ezt jelöli meg ajánlott formátumként.

A három formátum ugyanazt a szótárt (Schema.org) használja, csak máshogy építi be az oldalba:

• JSON-LD: különálló szkriptblokk a HTML-ben, a látható tartalomtól függetlenül. Könnyen generálható, könnyen javítható, nem törik el, ha átalakítod a sablont.
• Microdata: a HTML-elemekbe szőtt attribútumok. Régi oldalakon még gyakori, de bármilyen sablonmódosítás könnyen szétszedi.
• RDFa: hasonló logika, ritkábban használt.

Egy konkrét helyzet, ami eldönti a kérdést: ha jövőre sablont vagy oldalépítőt váltasz, a Microdata-jelölés jó eséllyel megtörik, mert a HTML-elemekhez tapad. A JSON-LD blokk átvihető, mert nem függ a megjelenítéstől. A JSON-LD-nek viszont van egy csapdája is: mivel külön él, könnyű elfelejteni frissíteni, amikor a látható tartalom változik. Ezért érdemes a sémát a tartalomból generáltatni, nem oldalanként kézzel bemásolni.

Szakmai feltételezés: a JSON-LD előnye idővel nőni fog, mert az AI-rendszerek szempontjából olcsóbb kinyerni egy tiszta, egyben álló adatblokkot, mint visszafejteni azt a HTML-attribútumok közül. Ez logikus következtetés, nem hivatalos állásfoglalás.

Melyik sématípust tedd fel az oldaladra?

Azt, amelyik az oldal tényleges tartalmát írja le, és amelyikhez a Google támogat megjelenítést. A „minél több, annál jobb” logika itt nem működik.

Tipikus párosítások:

• Kezdőlap: Organization vagy LocalBusiness (helyi szolgáltatónál), logóval, elérhetőséggel, közösségi profilokkal.
• Blogcikk, tudásbázis: Article vagy BlogPosting, szerzővel, kiadási és módosítási dátummal.
• Szolgáltatásoldal: Service, a szolgáltatás típusával és a lefedett területtel.
• Webshop terméklap: Product, ajánlattal, készletadattal, valós értékelésekkel.
• GYIK-szakasz: FAQPage, kizárólag akkor, ha a kérdések és válaszok az oldalon látszanak is.
• Bármilyen aloldal: BreadcrumbList, ha van morzsamenü.

A döntés két kérdésre egyszerűsíthető. Egy: mi ennek az oldalnak a fő tárgya (cég, cikk, termék, szolgáltatás, esemény)? Kettő: az ezt leíró típusnak van-e elég olyan mezője, amit valós, az oldalon is látható adattal ki tudsz tölteni? Ha a második kérdésre nem a válasz, inkább hagyd ki az adott mezőt, mint hogy hozzávetőleges adatot írj bele.

Hivatalosan igazolt: a Google 2023-ban szűkítette a GYIK-gazdagtalálatok megjelenítését, azóta jellemzően csak jól ismert egészségügyi és kormányzati forrásoknál mutatja. A jelölés attól még nem hiba, csak nem szabad rá vizuális megjelenést várni.

Hogyan néz ki egy működő JSON-LD a gyakorlatban?

Egy helyi szolgáltató kezdőlapjára ez a minta jó kiindulás. A szkriptblokkot a HTML fejlécébe vagy a törzs végére teszed, és a saját valós adataidra cseréled:

{

"@context": "https://schema.org",

"@type": "LocalBusiness",

"name": "Példa Kft.",

"url": "https://pelda.hu/",

"telephone": "+36 20 000 0000",

"address": { "@type": "PostalAddress", "streetAddress": "Fő utca 1.", "addressLocality": "Székesfehérvár", "postalCode": "8000", "addressCountry": "HU" },

"openingHours": "Mo-Fr 08:00-16:00",

"sameAs": ["https://www.facebook.com/pelda", "https://www.linkedin.com/company/pelda"]

}

Három dolog számít itt igazán. Az egyik, hogy a name pontosan az a cégnév legyen, ami a láblécben, a Google cégprofilodban és a számláidon szerepel. A másik, hogy a sameAs mezőbe csak olyan profilok kerüljenek, amiket tényleg te kezelsz. A harmadik, hogy a címnél a valós települést add meg helyesen ragozva a szövegben is (Székesfehérváron, Budapesten, Debrecenben), mert az AI-rendszerek a látható szövegből és a jelölésből együtt építik fel a képet.

Egy cikkoldalon ugyanez a logika ennyivel egészül ki: "@type": "Article", mellette "headline" (a valódi címmel), "datePublished" és "dateModified" ISO-formátumban, valamint "author" és "publisher". A dátumoknál gyakori hiba, hogy a dateModified minden éjjel átíródik, holott a tartalom hónapok óta változatlan.

Hogyan vezeted be lépésről lépésre?

A folyamat hat lépés, és egy közepes oldalon néhány óra munka:

1. Leltár: nézd meg, mi van jelenleg az oldalon. A böngésző forráskódjában keress rá az application/ld+json kifejezésre, vagy futtasd le a Rich Results Testet néhány jellemző oldalra.
2. Duplikátumok kiszűrése: ha több bővítmény is generál sémát (SEO-plugin, sablon, süti- vagy értékelésmodul), döntsd el, melyik marad, a többiben kapcsold ki a séma-kimenetet.
3. Sablonszintű tervezés: ne oldalanként gondolkodj, hanem sablononként. Egy Article-séma a blogsablonban több száz cikket lefed.
4. Kitöltés valós adatokkal: minden mező mögött legyen tényleges, az oldalon is látható tartalom.
5. Tesztelés élesítés előtt: staging vagy előnézeti URL, kódrészlet-beillesztéses teszt.
6. Élesítés és megfigyelés: a Search Console Fejlesztések riportjában napok, néha hetek alatt jelennek meg az új típusok.

Saját tapasztalat: WordPress-en a legstabilabb felállás az, ha egyetlen komponens felel a sémáért (jellemzően a SEO-bővítmény), és az egyedi kiegészítéseket egy külön, jól dokumentált kódrészlettel teszed hozzá. A vegyes megoldások később átláthatatlanná válnak.

Mit tegyél, ha kész rendszert, például WordPress-t vagy webshopmotort használsz?

Rövid válasz: ne írj mindent kézzel, hanem derítsd ki, mit generál helyetted a rendszer, és hol tudod felülírni.

A legtöbb WordPress SEO-bővítmény alapból kiad Organization vagy Person, WebSite, WebPage és Article sémát, a nagyobb webshopmotorok pedig Product-blokkot a terméklapokra. Ez kiindulásnak általában rendben van. A gond ott kezdődik, hogy a sablon, egy értékelésmodul és egy külön séma-bővítmény ugyanezt még egyszer, kicsit másképp kiadja, és a kereső ellentmondó állításokat kap ugyanarról az oldalról.

Három lépés, ami rendet tesz:

1. Nyisd meg a forráskódot, és számold meg, hány ld+json blokk van az oldalon. Kettőnél több már gyanús.
2. Kapcsold ki a felesleges kimeneteket a bővítmények beállításai között, egyesével, minden lépés után újratesztelve.
3. Az egyedi mezőket egyetlen, dokumentált helyen add hozzá, ne szórd szét több modul között.

Saját tapasztalat: oldalépítővel készült oldalaknál gyakran előfordul, hogy a séma csak a látogató böngészőjében, JavaScript futása után jelenik meg. Ilyenkor a nyers HTML-ben nincs benne, és ez kockázatot jelent, mert nem minden feldolgozó rendszer futtat teljes renderelést.

Hogyan ellenőrzöd, hogy tényleg működik?

Két eszköz kell hozzá, és a kettő mást mutat. A Rich Results Test azt mondja meg, hogy a Google felismeri-e a jelölést és jogosult-e gazdag találatra. A Schema Markup Validator azt mondja meg, hogy a kód a Schema.org szerint szintaktikailag helyes-e, akkor is, ha a Google nem használja az adott típust.

Az igazi visszajelzés viszont a Search Console. A Fejlesztések menüpont alatt típusonként látod az érvényes és hibás elemek számát, és ott derül ki, ha egy sablonhiba több száz oldalt érint egyszerre. Ha kizárólag validátorral dolgozol, azt látod, hogy a kód jó. Ha a Search Console-t is nézed, azt látod, hogy a Google mit fogadott el belőle.

Érdemes negyedévente újranézni: a Google időnként megszünteti egy-egy gazdagtalálat-típus támogatását, és ilyenkor a korábban zöld riport csendben kiürül.

Milyen hibák miatt nem jelenik meg a gazdag találat?

A leggyakoribb ok nem technikai, hanem tartalmi: olyat jelöltek meg, ami az oldalon nem látszik. A Google irányelve egyértelmű, a strukturált adat a látható tartalmat írja le, nem helyettesíti.

A tipikus hibák:

• Értékelés-séma valós, felhasználók által beküldött vélemények nélkül, vagy saját magadnak adott csillagokkal.
• GYIK-jelölés olyan kérdésekre, amik csak a kódban szerepelnek.
• Hiányzó kötelező mezők (terméknél például az offers blokk vagy a készletállapot).
• Több, egymásnak ellentmondó Organization-blokk ugyanazon az oldalon.
• Zárójelbe került séma: a JSON-LD-t olyan JavaScript generálja, amit a renderelés során nem sikerül időben lefuttatni.
• Elavult vagy kitalált mezőnevek, amik nem szerepelnek a Schema.org szótárában.

Hivatalosan igazolt: a Google manuális intézkedést is alkalmazhat a félrevezető strukturált adatra, ilyenkor az oldal elveszíti a gazdagtalálat-jogosultságát. Ez nem elméleti kockázat, hanem dokumentált szankciótípus.

Hogyan kapcsolod össze a sémákat egyetlen egésszé?

Rövid válasz: az @id mezővel, ami minden entitásnak állandó azonosítót ad, a többi séma pedig erre hivatkozik vissza.

A tipikus felállás az, hogy minden oldalon önálló szigetként áll a jelölés: a kezdőlapon egy Organization, a cikkeken egy-egy Article, és semmi nem köti össze őket. Ilyenkor a feldolgozó rendszernek oldalanként újra ki kell találnia, ki a kiadó, és ugyanaz a cég-e, mint amiről a másik oldal beszél.

A megoldás egyszerű. A cégedhez rendelsz egy állandó azonosítót (például https://pelda.hu/#organization), ezt beírod a kezdőlapi Organization-blokk @id mezőjébe, a cikkek Article-sémájában pedig a publisher már csak erre az azonosítóra hivatkozik. Ugyanez működik a szerzőknél is egy Person-entitással.

Két gyakorlati előnye van. Nem kell minden oldalon megismételni a teljes cégadatot, így az adatok nem tudnak szétcsúszni egymástól. És a jelölés szintjén is egyértelmű lesz, hogy végig ugyanarról a szervezetről beszélsz, nem több hasonló nevűről.

Számít-e a strukturált adat az AI-válaszokban?

Rövid válasz: valószínűleg segít, de nem ez a fő tényező, és senki nem ígérhet miatta beidézést.

Amit biztosan tudunk: a nagy nyelvi modellek elsősorban szöveget dolgoznak fel, és a válaszaikhoz használt webes forrásokat is szövegként olvassák. Amit a gyakorlat sugall: a strukturált adat két ponton kapcsolódik ehhez. Egyrészt a hagyományos keresőindexen keresztül, hiszen az AI-válaszmotorok jelentős része keresőtalálatokra támaszkodik, és ott a jól jelölt oldalak világosabb metaadatokkal jelennek meg. Másrészt konzisztencia-jelzésként: ha a látható szöveg, a séma és a külső profilok ugyanazt a cégnevet, címet és szolgáltatási kört mondják, kisebb az esélye, hogy a modell összekever egy másik szereplővel.

Szakmai feltételezés: a strukturált adat inkább az entitás-azonosítás pontosságát javítja, mint a beidézés valószínűségét. A beidézésben nagyobb súlyt kap az, hogy a tartalom önmagában is idézhető választ ad-e a feltett kérdésre. Ezt a saját mérési tapasztalatunk támasztja alá, nem hivatalos dokumentáció.

Milyen ellenőrzőlistán fusd át élesítés előtt?

• Minden fontos sablontípushoz tartozik legalább egy releváns séma.
• Egy oldalon egyetlen Organization vagy LocalBusiness blokk van.
• Minden megjelölt adat látható a felhasználó számára is.
• A cégnév, cím és telefonszám mindenhol azonos formában szerepel (weboldal, séma, cégprofil).
• A Rich Results Test hibamentesen fut a főbb sablonokon.
• A Search Console Fejlesztések riportja nem mutat tömeges hibát.
• A dátummezők valósak, és a frissítéskor tényleg változnak.
• Nincs értékelés-séma valódi vélemények nélkül.
• A séma a szerveroldali HTML-ben is megtalálható, nem csak kliensoldali szkript után.
• A cég- és szerzőentitásoknak állandó @id azonosítójuk van, amire a többi oldal hivatkozik.

Ha ezen a tíz ponton átmész, a strukturált adat oldaladról nagy valószínűséggel nem lesz több gond. Innentől a hangsúly a tartalom minőségén és az entitás-konzisztencián van, mert az AI-korszakban ez a két dolog dönti el, mennyire értenek meg helyesen.

Források és további olvasnivalók

• Google Search Central: Bevezetés a strukturált adatok jelölésébe a Google Keresésben
• Google Search Central: Strukturált adatokra vonatkozó általános irányelvek
• Google Rich Results Test és Search Console súgó (Fejlesztések riportok)
• Schema.org: hivatalos típus- és tulajdonságdokumentáció
• W3C: JSON-LD 1.1 specifikáció
• Bing Webmaster Guidelines: strukturált adatok fejezet
• OpenAI dokumentáció: webes böngészés és forráskezelés