WordPress schema: teljes útmutató

A WordPress schema strukturált adat (általában JSON-LD formátumú kód), amely géppel olvasható módon írja le, mi van az oldaladon: cikk, termék, szervezet, recept vagy esemény. WordPressben a legtöbbször egy SEO bővítmény generálja automatikusan, amit egyedi típusokkal és mezőkkel bővíthetsz. A cél a tartalom pontos értelmezése és a gazdag találatokra való jogosultság, nem pedig a garantált jobb helyezés.

Alapfogalmak

Mielőtt bármit beállítanál, érdemes tisztázni néhány fogalmat. A WordPress schema körüli félreértések nagy része abból fakad, hogy a schema, a strukturált adat, a rich snippet és a JSON-LD kifejezéseket keverik, pedig mindegyik mást jelent. Ha ezek a helyükre kerülnek, sokkal könnyebb eldönteni, mire van szükséged, és mit hagyhatsz ki nyugodtan.

Schema.org szókészlet

A schema.org egy nyilvános szókészlet, amelyet a nagy keresőcégek közösen indítottak el. Típusokat (például Article, Product, Organization, LocalBusiness, Event) és ezekhez tartozó tulajdonságokat (például name, author, datePublished, offers) határoz meg. A szókészlet önmagában nem kód, hanem egy közös nyelv: megmondja, hogyan nevezd el azt, amit le akarsz írni.

Strukturált adat és formátumai

A strukturált adat az a konkrét jelölés, amelyet az oldaladba teszel a schema.org szókészletével. Három formátum létezik: JSON-LD, Microdata és RDFa. A Google a JSON-LD-t ajánlja, mert külön blokkban él, nem kell a HTML elemekbe szőni, így a sablon módosítása nélkül is karbantartható. WordPressben szinte minden modern bővítmény JSON-LD-t ad ki, ezért ez a cikk is erre épül.

Rich result, rich snippet

A gazdag találat a keresési eredmény bővített megjelenése: csillagos értékelés, ár és készlet, recept elkészítési ideje, eseménydátum, morzsamenü. Fontos tudni, hogy a strukturált adat csak jogosultságot ad erre, a megjelenítésről a Google dönt. Hibátlan jelölés mellett is előfordul, hogy egy oldal sima kék linkként jelenik meg.

Entitás és a @graph

A modern WordPress SEO bővítmények nem különálló blokkokat írnak ki, hanem egy összefüggő gráfot. Ebben a WebSite, a WebPage, az Organization vagy Person, az Article és a BreadcrumbList egymásra hivatkozik az @id azonosítókon keresztül. Így a kereső nem csak azt látja, hogy van egy cikk, hanem azt is, hogy ki adta ki, melyik webhelyhez tartozik, és melyik weboldalon szerepel.

Fogalomtáblázat gyors áttekintéshez

Fogalom	Mi ez?	Mire figyelj?
Schema.org	Közös szókészlet típusokkal és tulajdonságokkal	Nem minden típushoz tartozik Google gazdag találat
JSON-LD	Script blokkba írt strukturált adat	A tartalomnak egyeznie kell a látható oldallal
Rich result	Bővített keresési megjelenés	Jogosultság, nem garancia
@id	Egyedi azonosító egy entitáshoz	Duplikált entitásoknál ütközést okozhat
Kötelező és ajánlott tulajdonság	A Google dokumentációja szerinti mezők	A kötelező hiánya kizár a gazdag találatból

Egy gyakori tévhit, hogy a schema közvetlen rangsorolási tényező. A Google nyilvános kommunikációja szerint a strukturált adat a megértést és a megjelenést segíti, nem önálló helyezésjavító eszköz. A hatása közvetett: egy feltűnőbb találat több kattintást hozhat, a pontosabb értelmezés pedig relevánsabb lekérdezésekhez kötheti az oldalt. Ha a teljes keresőoptimalizálási környezetet is látni szeretnéd, a WordPress SEO: teljes útmutató ad hozzá keretet.

Hogyan működik?

A WordPress schema működése három rétegre bontható: az adatforrásra, a generálásra és a kiolvasásra. Ha érted, melyik réteg honnan veszi az információt, akkor egy hibánál is gyorsan rájössz, hol kell javítani: a bejegyzésben, a bővítmény beállításaiban vagy a sablonban.

1. Az adatforrás

A WordPress minden bejegyzéshez és oldalhoz tárol olyan adatokat, amelyek közvetlenül schema tulajdonsággá alakíthatók: cím, közzététel és módosítás dátuma, szerző, kiemelt kép, kategória, kivonat, permalink. A WooCommerce ehhez hozzáadja az árat, a pénznemet, a készletállapotot, a cikkszámot és az értékeléseket. Az egyedi mezők (például ACF mezők) további forrást jelentenek, ha a bővítményed vagy a saját kódod képes kiolvasni őket.

2. A generálás

A generálást jellemzően egy SEO bővítmény végzi. Az oldal betöltésekor összeállítja a gráfot a webhely szintű beállításokból (szervezet neve, logó, közösségi profilok) és az aktuális tartalom adataiból, majd egy application/ld+json típusú script blokkba írja a forráskódba. Egyes sablonok és oldalépítők szintén kiadnak saját jelölést, és itt kezdődnek a bajok: ha két forrás ír ki Article vagy Organization entitást, a kereső egymásnak ellentmondó adatokat kap.

3. A kiolvasás

A Googlebot feltérképezéskor és renderelés után kiolvassa a JSON-LD blokkot, összeveti a látható tartalommal, és eldönti, melyik gazdag találattípusra lehet jogosult az oldal. A Search Console külön jelentésekben mutatja a felismert típusokat, az érvényes elemeket és a hibákat. Ez a visszacsatolás a mérés alapja, erről később részletesen lesz szó.

Szemléltető példa: egy blogbejegyzés gráfja

Vegyünk egy kitalált webhelyet, a kertlap.hu-t, amelyen megjelenik egy „Paradicsom palántázása lépésről lépésre” című cikk. A bővítmény által generált gráf logikailag így épül fel:

• WebSite: név „Kertlap”, URL a kezdőlap, kiadóként hivatkozik az Organization entitásra.
• Organization: név, logó URL, közösségi profilok a sameAs tulajdonságban.
• WebPage: a cikk URL-je, címe, része a WebSite entitásnak, hivatkozik a morzsamenüre.
• Article: headline, datePublished, dateModified, image, author, publisher, mainEntityOfPage a WebPage felé.
• Person: a szerző neve és a szerzői archívum URL-je.
• BreadcrumbList: Kezdőlap, Zöldségek, Paradicsom palántázása.

Ebből a gráfból a kereső egyetlen összefüggő képet kap. Ha később kézzel hozzáadsz egy HowTo blokkot, annak illeszkednie kell ehhez a gráfhoz, különben két külön, egymástól független leírás keletkezik ugyanarról az oldalról.

Mi történik, ha a tartalom változik?

Mivel a jelölést a bővítmény minden oldalbetöltéskor a friss adatokból állítja össze, a cím, a dátum vagy az ár módosítása automatikusan átkerül a schemába. Kivétel a gyorsítótár: ha a cache plugin vagy a CDN régi HTML-t szolgál ki, a schema is régi marad. Ugyanez igaz a kézzel bemásolt JSON-LD blokkokra, ezek nem frissülnek maguktól. Ezért érdemes a kézi kódot a lehető legkevesebb helyen használni, és mindig dinamikus adatból táplálni.

Fő módszerek

WordPressben négy fő úton juthatsz el a működő strukturált adatig. Nem kell mindet használnod, sőt, a legtöbb oldalnál egy jól beállított SEO bővítmény elég. A döntés attól függ, milyen tartalomtípusaid vannak, mennyire egyediek, és ki fogja hosszú távon karbantartani a megoldást.

1. Általános SEO bővítmény

A Yoast SEO, a Rank Math és az All in One SEO mind kiad alapértelmezett schema gráfot, és mindháromban beállíthatod a webhely gazdáját (szervezet vagy személy), a logót, valamint tartalomtípusonként az alapértelmezett oldal- és cikktípust. A különbségek abban vannak, mennyi típust és egyedi mezőt kezelnek a felületről, és mi érhető el az ingyenes, illetve a fizetős változatban. A pontos funkciókészlet verziónként változik, ezért a részleteket a bővítményekről szóló külön útmutatókban érdemes megnézni: Yoast SEO: teljes útmutató, Rank Math: teljes útmutató, All in One SEO: teljes útmutató.

2. Dedikált schema bővítmény

Léteznek kifejezetten strukturált adatra szakosodott bővítmények is. Akkor jöhetnek szóba, ha sok egyedi típust kell kezelned, és szabályalapú hozzárendelést szeretnél (például minden „recept” kategóriájú bejegyzés kapjon Recipe jelölést). A kockázat itt a duplikáció: ha mellette a SEO bővítményed is ír ki gráfot, az egyiket le kell tiltanod az érintett típusokra.

3. Kézi JSON-LD egyedi mezőkből

Fejlesztői megoldás, amikor egy gyermeksablonban vagy saját bővítményben, a megfelelő hookra kötve írod ki a JSON-LD-t, és az adatokat egyedi mezőkből olvasod. Előnye a teljes kontroll, hátránya a karbantartás. A legtöbb nagy SEO bővítmény biztosít szűrőket a saját gráfja bővítésére, ami általában tisztább, mint egy teljesen különálló blokk, mert az új entitás be tud kapcsolódni a meglévő @id hivatkozásokba.

4. Sablon vagy oldalépítő által kiadott jelölés

Egyes sablonok Microdata attribútumokat tesznek a HTML-be, egyes blokkok vagy widgetek saját schemát adnak ki. Ezt ritkán érdemes elsődleges módszernek választani, inkább ellenőrizni kell, nem ütközik-e a bővítményed gráfjával.

Döntési szabály: melyiket válaszd?

Helyzet	Ajánlott módszer	Indoklás
Blog, céges oldal, szolgáltatásoldalak	SEO bővítmény alapbeállítással	Article, Organization, Breadcrumb lefedve, minimális karbantartás
Helyi vállalkozás címmel, nyitvatartással	SEO bővítmény LocalBusiness támogatással vagy kiegészítővel	Az adatok egyszer, központilag adhatók meg
WooCommerce webshop	WooCommerce és SEO bővítmény együttese, duplikáció ellenőrzéssel	A termékadatok dinamikusan frissülnek
Egyedi tartalomtípus sok saját mezővel	Bővítmény gráfjának bővítése kóddal	Összefüggő gráf, pontos mezőleképezés
Egyszeri, egyedi oldal (például egy esemény)	Bővítmény egyedi schema funkciója, ha van	Nem éri meg kódot írni egy oldalért

Bevezetési workflow lépésről lépésre

1. Készíts listát a tartalomtípusaidról (bejegyzés, oldal, termék, egyedi típusok) és arról, melyikhez milyen schema típus illik.
2. Nézd meg néhány jellemző URL forráskódját, és jegyezd fel, ki ad ki most strukturált adatot (bővítmény, sablon, egyéb).
3. Döntsd el, melyik forrás lesz az egyetlen „gazda” az egyes típusoknál, a többit kapcsold ki.
4. Állítsd be a webhely szintű adatokat: szervezet vagy személy, logó, közösségi profilok.
5. Rendeld hozzá az alapértelmezett típusokat tartalomtípusonként.
6. Egyedi igényeknél bővítsd a gráfot, és ellenőrizd tesztoldalon.
7. Futtasd végig a jellemző URL-eket az ellenőrző eszközökön, majd figyeld a Search Console jelentéseit.

Gyakori hibák

A WordPress schema hibái ritkán látványosak. Az oldal ugyanúgy működik, a látogató semmit nem vesz észre, közben a Search Console figyelmeztetéseket gyűjt, vagy a gazdag találat egyszerűen nem jelenik meg. Az alábbi hibák fordulnak elő a leggyakrabban, mindegyikhez megmutatom a javítás irányát is.

Duplikált entitások

A klasszikus eset: a SEO bővítmény kiad egy Article entitást, a sablon pedig Microdata formában egy másikat, eltérő szerzővel vagy dátummal. Ugyanez megtörténik, ha két SEO bővítmény fut egyszerre (például váltás után bent maradt a régi), vagy ha a WooCommerce és egy SEO bővítmény is teljes Product jelölést ad ki. Javítás: válassz egy gazdát, a többi forrást kapcsold ki a beállításokban vagy szűrővel.

A látható tartalommal nem egyező jelölés

A Google irányelvei szerint a strukturált adatnak a felhasználó számára látható tartalmat kell tükröznie. Hiba például értékelést jelölni olyan oldalon, ahol nincs látható értékelés, vagy más árat írni a schemába, mint ami a termékoldalon szerepel. Ez a gazdag találat elvesztéséhez, súlyosabb esetben kézi intézkedéshez vezethet. Ellenőrzéskor mindig tedd egymás mellé a forráskód JSON-LD blokkját és a látható oldalt.

Rossz típusválasztás

Gyakori, hogy minden oldal Article lesz, a szolgáltatásoldalak és a kapcsolati oldal is. Ez nem tiltott, de pontatlan. Egy kapcsolati oldalhoz a ContactPage, egy rólunk oldalhoz az AboutPage WebPage altípus illik jobban. A fordított hiba is létezik: egy kategóriaoldal kap Product jelölést, holott több terméket listáz.

Elavult elvárásokhoz igazított jelölés

A Google időnként szűkíti egyes gazdag találatok megjelenítését. Az FAQ gazdag találatokat 2023-ban jelentősen korlátozta, a HowTo megjelenítést pedig ugyanebben az időszakban kivezette. Ettől a jelölés nem lett hibás, de ha valaki kizárólag ezekért a megjelenésekért tette az oldalaira, ma más okból kell indokolnia a megtartásukat. Mielőtt egy típusba energiát fektetsz, nézd meg a Google aktuális dokumentációjában, hogy támogatott-e még gazdag találatként.

Hiányzó kötelező vagy rossz formátumú tulajdonság

• Dátum ISO 8601 helyett magyar formátumban (például „2026. október 1.”).
• Ár szövegként, pénznemjellel együtt a számmezőben.
• Logó vagy kép URL-je relatív útvonallal, vagy olyan fájlra mutat, amely már nem létezik.
• A szerző csak egy név szövegként, URL és Person entitás nélkül.
• Termékoldalon hiányzik az offers, a review vagy az aggregateRating közül legalább egy, amit a Google a termékjelöléshez elvár.

Ellenpélda: amikor a „hiba” valójában nem az

A Search Console gyakran mutat figyelmeztetést hiányzó, nem kötelező tulajdonságra, például hiányzó GTIN azonosítóra. Ez nem hiba, hanem javaslat. Ha az adat nem létezik (saját készítésű termékeknek nincs GTIN-je), ne találj ki értéket csak azért, hogy eltűnjön a figyelmeztetés. A kitalált azonosító rosszabb, mint a hiányzó.

Határeset: gyorsítótár és többnyelvű oldalak

Ha a schema beállításait módosítod, de a cache nem ürül, az ellenőrző eszköz régi jelölést láthat, és azt hiszed, nem működik a változtatás. Többnyelvű oldalaknál pedig előfordul, hogy a fordítóbővítmény nem fordítja a szervezet nevét vagy a morzsamenüt, így a magyar oldal angol breadcrumb elemeket kap. Mindkét esetben a megoldás a nyelvenkénti és ürített cache melletti tesztelés.

Mérés

A strukturált adat bevezetése akkor ér valamit, ha látod a hatását. A mérés két szinten zajlik: technikai érvényesség (helyes-e a jelölés) és üzleti hatás (változott-e a megjelenés és a kattintás). A kettőt érdemes külön kezelni, mert egy hibátlan jelölés sem garantál jobb átkattintási arányt.

Technikai ellenőrzés eszközei

Eszköz	Mire való?	Mikor használd?
Google Rich Results Test	Megmutatja, mely Google gazdag találatra jogosult egy URL vagy kódrészlet	Minden új típus bevezetése után, mintavételezett URL-ekkel
Schema Markup Validator (validator.schema.org)	A teljes schema.org szókészlet szerinti érvényesség, Google-specifikus szűrés nélkül	Gráfszerkezet és nem Google-típusok ellenőrzésére
Search Console jelentések	Webhelyszintű összesítés érvényes, figyelmeztetéses és hibás elemekről	Folyamatos figyelés, hetente vagy kéthetente
URL-ellenőrzés a Search Console-ban	Az indexelt, renderelt változat vizsgálata	Ha a teszt mást mutat, mint amit a Google lát

Mintavételezési szabály

Nem kell minden URL-t egyenként tesztelni. Elég tartalomtípusonként és sablononként két vagy három jellemző oldalt választani: egy friss bejegyzést, egy régit, egy terméket készleten és egyet készlet nélkül, egy kategóriaoldalt. Ha ezek rendben vannak, a hiba nagy valószínűséggel nem rendszerszintű. A Search Console jelentései aztán megmutatják, ha egyedi oldalak lógnak ki.

Üzleti hatás mérése a Search Console teljesítményjelentésében

A teljesítményjelentésben a keresési megjelenés szerinti szűréssel bizonyos gazdag találattípusok külön is vizsgálhatók, amennyiben a Google az adott típust megjeleníti ott. Ha erre nincs lehetőség, összehasonlíthatod az érintett oldalcsoport átkattintási arányát a bevezetés előtti és utáni időszakban.

Szemléltető, kitalált számpélda: egy webshop termékoldal-csoportja a bevezetés előtti 28 napban 40 000 megjelenést és 800 kattintást hozott (2,0% CTR). A Product jelölés javítása után, egy hasonló 28 napos időszakban 42 000 megjelenés és 1050 kattintás volt (2,5% CTR). Ebből még nem következik, hogy a schema okozta a teljes javulást: szezonalitás, árváltozás, helyezésváltozás is közrejátszhat. Ezért érdemes egy kontrollcsoportot is figyelni, például azokat a termékoldalakat, amelyeknél nem változott a jelölés.

Mérési workflow

1. Rögzítsd a kiinduló állapotot: Search Console jelentések képernyőképe, érintett oldalcsoport CTR-je és átlagos pozíciója.
2. Vezesd be a változtatást egyszerre egy oldalcsoporton, ne az egész webhelyen.
3. Teszteld a mintavételezett URL-eket a Rich Results Testben.
4. Kérj újraindexelést néhány kulcsoldalra, a többit hagyd a természetes feltérképezésre.
5. Várj legalább néhány hetet, amíg a Search Console jelentései frissülnek.
6. Hasonlítsd össze az érintett és a kontrollcsoport adatait azonos hosszú időszakokra.

Ellenőrzőlista negyedéves átnézéshez

• Nincs új hiba a Search Console strukturált adat jelentéseiben.
• Bővítmény- vagy sablonfrissítés után sem jelent meg duplikált entitás.
• A szervezet adatai (név, logó, profilok) naprakészek.
• A termékárak és készletadatok a schemában megegyeznek a látható adatokkal.
• Nem használsz olyan típust kizárólag gazdag találat miatt, amelyet a Google már nem jelenít meg.
• Az új tartalomtípusok is kaptak megfelelő jelölést.

Kapcsolódó részletes útmutatók

A strukturált adat a WordPress SEO egyik rétege, és a gyakorlatban szinte mindig egy SEO bővítményen keresztül kezeled. Ezért a következő lépés jellemzően az, hogy a választott bővítmény schema beállításait alaposan megismered, illetve elhelyezed a schemát a teljes optimalizálási folyamatban.

Hogyan haladj tovább?

Ha még nem döntötted el, melyik bővítményt használd, először a három nagy eszköz útmutatóját érdemes összevetned: nézd meg, melyik kezeli a számodra fontos típusokat (például LocalBusiness, Product, egyedi típusok) a felületről, és melyikhez kellene kódot írnod. Ha már van bővítményed, maradj annál, és a duplikációk felszámolására koncentrálj, mert egy bővítményváltás önmagában új kockázatokat hoz (elveszett beállítások, ideiglenesen dupla gráf).

Döntési szabályként jól működik a következő: ha a jelenlegi bővítményed kiadja a szükséges típusokat, és a Search Console nem jelez hibát, ne válts eszközt a schema miatt. Ha viszont rendszeresen kódot kell írnod olyan típusokhoz, amelyeket egy másik bővítmény a felületről kezel, és a csapatodban nincs fejlesztő, a váltás megfontolható, de csak tesztkörnyezetben kipróbálva.

Ajánlott olvasnivaló

• WordPress SEO: a témakör kiindulópontja, ahonnan az összes kapcsolódó anyag elérhető.
• WordPress SEO: teljes útmutató: a technikai, tartalmi és bővítménybeállítások átfogó áttekintése, amelybe a schema is illeszkedik.
• Yoast SEO: teljes útmutató: a Yoast beállításai, köztük a webhely gazdájának és a tartalomtípusok alapértelmezett jelölésének megadása.
• Rank Math: teljes útmutató: a Rank Math schema funkcióinak és általános beállításainak részletes leírása.
• All in One SEO: teljes útmutató: az AIOSEO strukturált adat beállításai és a webhelyszintű konfiguráció.

Rövid összefoglaló ellenőrzőlista indulás előtt

1. Egyetlen forrás adja ki az egyes schema típusokat.
2. A webhely szintű adatok (szervezet vagy személy, logó) be vannak állítva.
3. Minden tartalomtípus a tartalmához illő típust kapja.
4. A jelölés a látható tartalmat tükrözi, kitalált adat nélkül.
5. A mintavételezett URL-ek átmentek a Rich Results Testen.
6. Rögzítetted a kiinduló mérési adatokat, és van kontrollcsoportod.