2026-01-14 · Baduno szerkesztőség · 6 blog.readMin · Blog és tudás
Strukturált adatok: Schema.org érthetően elmagyarázva
A géppel olvasható kiegészítő információk gazdag találatokká varázsolják a keresési eredményeket értékelésekkel, GYIK-kel és céges adatokkal. Így működik.
Mik azok a strukturált adatok?
A forráskód láthatatlan JSON-blokkjai írják le, mi van az oldalon: ez egy vállalat ezzel a címmel, ez egy cikk ezzel a dátuman, ez egy GYIK ezekkel a kérdésekkel. A keresőmotoroknak nem kell találgatniuk – olvasnak.
Mit hoz?
Jogosultság bővített megjelenítésekhez (GYIK-kivonatok, morzsakék, szervezeti panel), az összefüggések jobb megértése és tisztább tudásgráf-bejegyzések. Nem rangsorolási turbó – de több felület és bizalom a keresési találatokban.
A legfontosabb típusok vállalkozások számára
Organization regisztrációs adatokkal, WebSite, Service vagy Product Offerrel, Article szakmai cikkekhez, FAQPage és BreadcrumbList. Többnyelvű esetben: minden nyelvi változat saját, lefordított jelölést visel.
Ne felejtsük el érvényesíteni
A Rich-Results-Test megmutatja, mit olvas a Google, a Schema-Validator ellenőrzi a szintaxist. A hibás jelölés rosszabb, mint a semmilyen – bizalomvesztést okoz, és súlyos esetben a bővített megjelenítés elvesztését.
Strukturált adatok és hreflang: Tökéletes összjáték többnyelvű oldalakhoz
A többnyelvű weboldalak gyakori hibája a strukturált adatok és a hreflang-címkék következetlen használata. Míg a hreflang a keresőmotorok számára jelzi egy oldal nyelvi és regionális alternatíváit, a strukturált adatok a tartalom típusát árulják el. A kettő független egymástól, de kiegészíti egymást: egy német termékoldalnak hreflang-címkével kell mutatnia az angol változatra, és a strukturált adatok blokkjában is ugyanazt a termékazonosítót kell feltüntetnie eltérő ajánlatokkal és nyelvekkel. Fontos: minden nyelvi változat saját JSON-LD blokkot kap megfelelő értékekkel – különben ellentmondások keletkeznek. A Google Rich Results tesztje gyakran jelez hibát, ha például a német verzióban szereplő szervezet angol címet tartalmaz. Ezért minden nyelvi bevezetés után mindig ellenőrizze a két jelölést párhuzamosan.
Karbantartás és frissítés: Ki gondozza az adatokat?
A strukturált adatok nem egyszeri projekt. Ha változnak az árak, nyitvatartási idők vagy termékadatok, a JSON-LD blokkokat frissíteni kell. Ideális esetben a tartalomkezelő rendszer végzi a dinamikus feltöltést. Ennek hiányában egyértelmű felelős személy szükséges a csapatban – például a szerkesztő a cikk- és GYIK-adatokhoz, a fejlesztő a szervezeti adatokhoz. Kerülje az adatsilókat: egy elavult telefonszám a Organization blokkban aláássa a bizalmat. Tervezzen negyedéves felülvizsgálatokat minden strukturált adatra, de legalább minden nagyobb újraindítás előtt. Hasznos egy központi irányítópult, amely az összes kijelölt oldalt és azok érvényesítési állapotát mutatja.
Mesterséges intelligencia által támogatott strukturált adatok létrehozása és ellenőrzése
A modern MI-eszközök strukturálatlan szövegből automatikusan képesek JSON-LD-t generálni – például GYIK-oldalakhoz vagy cikkekhez. Ez felgyorsítja a munkát, de kockázatokkal jár: az MI gyakran figyelmen kívül hagyja a kontextuális árnyalatokat (pl. hibás ár vagy elavult dátum). Ezért elengedhetetlen a szerkesztő általi anyanyelvi ellenőrzés. Használja az MI-t a nyers változathoz, majd hagyja, hogy egy ember érvényesítse az értékeket. Többnyelvű oldalak esetén az MI segít a strukturált adatok fordításában, de a hreflang-címkéket és a nyelvspecifikus azonosítókat manuálisan kell beállítani. Bevált gyakorlat: az MI elkészíti az angol standard blokkot, egy helyi szerkesztő javítja és kiegészíti a nyelvspecifikus mezőkkel.
A géppel olvasható kiegészítő információk gazdag találatokká varázsolják a keresési eredményeket értékelésekkel, GYIK-kel és céges adatokkal. Így működik.
Dinamikus tartalmak kijelölése: GYIK, vélemények és termékek
Különösen gyakoriak a hibák a dinamikus tartalmaknál. A GYIK-oldalaknál minden kérdéshez külön JSON-LD bejegyzés tartozzon – ne a teljes listát egyetlen Question-objektumként. Vélemények esetén az értékelési skálát helyesen kell megadni (pl. bestRating és worstRating). A változatokkal rendelkező termékoldalakhoz AggregateOffer-blokkok szükségesek az összes ár- és elérhetőségi információval. Használjon sablonokat a CMS-ben, amelyek automatikusan generálják a helyes típusokat. Teszteljen minden dinamikus oldalt külön a Rich Results Test segítségével, mivel a hibák csak konkrét értékeknél válnak láthatóvá. Gyakori hiba: a 'Review' használata az 'AggregateRating' helyett az átlagos értékeléseknél.
Több Schema.org-típus kombinációja egy oldalon
Egyetlen oldalon párhuzamosan több Schema.org-típust is megjelölhet, amennyiben azok a tartalom különböző aspektusait írják le. Egy termékoldal tartalmazhat egyszerre egy Product-blokkot (árral, elérhetőséggel), egy Organization-blokkot (a gyártó számára) és egy Review-blokkot (véleményekkel). Fontos, hogy minden típus saját JSON-LD szkriptben szerepeljen, vagy @id-vel konzisztensen összekapcsolva legyen. Példa: a Product-blokk a "brand": {"@id": "#organisation"} segítségével hivatkozik az Organization-blokkra. Kerülje az ellentmondásos adatokat – például eltérő címeket az Organization és LocalBusiness blokkokban. Minden típus tartalmilag helyes és nyelvspecifikus legyen: egy francia oldal francia értékeket kapjon minden blokkban. Használja a CMS-t a típusok moduláris kezelésére, hogy ne kelljen minden blokkot manuálisan módosítania. Ellenőrizze a Rich-Results-tesztben, hogy minden blokk elfogadásra kerül-e – egyes tesztek csak az első blokkot jelenítik meg. A típusok tiszta kombinációja növeli a gazdag eredmények (pl. karusszel, termékdobozok, szervezeti panel) esélyét.
Munka @id-vel és hivatkozásokkal összekapcsolt adatokhoz
A Schema.org lehetővé teszi objektumok @id-n keresztüli hivatkozását, így elkerülve a redundáns adatokat. Ahelyett, hogy minden oldalon megismételné a teljes szervezetet, határozzon meg egy központi Organization-blokkot egyedi @id-vel (pl. "https://példa.hu/#ceg") és hivatkozzon rá más blokkokban a "@id": "https://példa.hu/#ceg" segítségével. Ez különösen hasznos többnyelvű weboldalaknál: a szervezet ugyanaz marad, csak a nyelvspecifikus mezők (pl. "name" vagy "description") térnek el. Ügyeljen arra, hogy az @id konzisztens legyen az összes nyelvi verzióban – azaz ugyanaz az URI német, angol stb. esetén. A hivatkozások használhatók cikk szerzői, termékmárkák vagy értékelési tételek esetében is. Ellenőrizze a Schema-validatorrel, hogy minden @id-hivatkozás feloldható-e. Hiba: ha a hivatkozott @id nincs definiálva ugyanabban az oldal forráskódjában vagy egy másik oldalon, az érvényesítés meghiúsul. Ezért a központi entitásokat vagy egy globális fájlban (pl. organisation.json) tárolja és JavaScript segítségével illessze be, vagy használja a CMS-t a dinamikus beillesztésre. A tiszta @id-struktúra megkönnyíti a keresőmotorok számára az információk összekapcsolását és javítja a konzisztenciát a Knowledge Graphban.
BreadcrumbList helyes kódolása: tippek és buktatók
A BreadcrumbList megjelölése egyszerűnek tűnhet, de a gyakorlatban gyakran jelentkeznek hibák, amelyek veszélyeztetik a rich snippet sikerét. A helyes implementáció a hierarchia megértésével kezdődik: a lista minden egyes bejegyzéséhez szükség van egy ItemListElement objektumra, amely egy ListItem objektumot tartalmaz. Döntő fontosságú a position tulajdonság: ez számozza a elemeket növekvő sorrendben, a kezdőlap 1-esével kezdve. Kerülje el a kezdőlap kihagyását – még ha nem is jelenik meg a látható breadcrumb-ben, a strukturált adatokban szerepelnie kell. Gyakori hiba az abszolút URL-ek használata a nyelvi verzió figyelembevétele nélkül: győződjön meg arról, hogy a breadcrumb URL a megfelelő nyelvi változatra mutat, pl. /de/produkte a /en/products helyett. Az elemek elnevezésének is nyelvspecifikusnak kell lennie – 'Kezdőlap' magyarul, 'Home' angolul. Használja a name mezőt a megjelenített szöveghez, és kerülje a keresőmotorok által félreérthető rövidítéseket. Az implementáció után minden útvonalat ellenőrizzen a Rich-Results teszttel, mivel különösen a dinamikusan generált breadcrumb-eknél könnyen felcserélődnek a pozíciók vagy duplikált bejegyzések keletkeznek. Továbbá vegye figyelembe, hogy a Google legfeljebb tíz elemet jelenít meg – ezért a rövidebb, pontos navigáció előnyben részesítendő a túl hosszúval szemben.
Beágyazott objektumok és referenciák: @id és @context
Az összetett strukturált adatok gyakran több típus összekapcsolását használják @id referenciákon keresztül. Tipikus példa egy olyan termékoldal, amely tartalmaz egy ajánlatot (Offer) és egy értékelést (Review) is. Ahelyett, hogy az összes adatot egy monolitikus blokkba tömörítené, tisztább különálló blokkokat definiálni egyedi @id értékekkel, majd ezekre hivatkozni. Az @id értéknek az oldalon és a teljes domainen belül egyedinek kell lennie – ideális esetben használja az objektum abszolút URL-jét egy fragmenttel, mint #product-1. Kerülje az olyan általános ID-ket, mint #termék, mert több oldalon konfliktusokat okozhatnak. Egy másik fontos szempont a @context: alapértelmezés szerint a Schema.org szókincset használjuk, de saját bővítményekhez saját kontextus is megadható. Ügyeljen arra, hogy ellenőrzött bővítmények, mint a health-lifesci vagy a bib, ne kerüljenek véletlenül kereskedelmi oldalakra. Többnyelvű oldalakon az @id referenciáknak nyelvspecifikusnak kell lenniük: a német termékoldal a német ajánlat azonosítójára hivatkozik, nem az angolra. Hasznos technika a @reverse használata inverz kapcsolatokhoz, például amikor egy termék egy szervezetre hivatkozik, de a szervezet nem vezet közvetlen listát az összes termékről. Tesztelje az ilyen láncolatokat a séma-validátorban, mert már egy hiányzó kettőspont is érvényesítési hibát okoz. Szánjon elegendő időt a hivatkozott objektumok hibakeresésére – ezek gyakori hibaforrások a kiterjedt implementációkban.
blog.faqT
Hozzáadhatok strukturált adatokat utólag régi oldalakhoz is?
Igen, a strukturált adatok bármikor kiegészíthetők. Ügyeljen arra, hogy minden adat naprakész legyen. Használja a Google Rich-Results-tesztjét a helyes implementáció ellenőrzéséhez. Sok oldal esetén célszerű lépésenként haladni tartalomtípusonként.
Milyen gyakran kell frissíteni a strukturált adatokat?
Mindig, amikor az alapul szolgáló információk változnak (árak, nyitvatartási idők, termékadatok). Tervezzen be legalább negyedéves átfogó ellenőrzést. A dinamikus rendszerek automatikusan kitölthetik az adatokat – ez csökkenti a frissítési erőfeszítéseket és a hibalehetőségeket.
