JSON-LD és strukturált adatok: gyakorlati útmutató KKV-knak
Schema.org, JSON-LD és Google-megjelenések különválasztva: ellenőrizhető cikk- és cégadatok, használható kódminták, valamint a megszűnt FAQ- és HowTo-találatok tanulságai.

A strukturált adat arra való, hogy a weboldal tartalmát egyértelmű mezőkkel írjuk le: ki a cikk szerzője, mikor jelent meg, melyik szervezethez tartozik az oldal, vagy milyen pénznemben szerepel egy termék ára. Nem helyettesíti a látható tartalmat, és nem biztosít automatikus ajánlást sem a keresőben, sem egy mesterségesintelligencia-asszisztens válaszában.
Egy magyar KKV számára az első haszna a következetes adatközlés. Ugyanaz a cégnév, ár és nyitvatartás jelenjen meg a felületen és a géppel feldolgozható változatban. Ha ez nincs rendben, egy technikailag hibátlan kódrészlet is félrevezető lehet.
Három fogalom, három külön feladat
A Schema.org szókészlet: típusokat és tulajdonságokat határoz meg, például Organization, BlogPosting, name vagy datePublished. A JSON-LD az adatok egyik leírási formátuma. A Google bővített találata pedig egy konkrét keresőfunkció, saját jogosultsági és tartalmi feltételekkel.
Ebből következik, hogy egy érvényes Schema.org-típus nem feltétlenül kap külön megjelenést a Google-ben. A JSON-LD-blokk a HTML head vagy body részében is szerepelhet. A formátumot a Google támogatja, de az érvényes jelölés sem garantál bővített találatot. Forrás: Google strukturáltadat-bevezető.
Az AI-láthatóságnál is kerüld a túlzó következtetést. A Google saját AI-funkcióihoz nem ír elő külön speciális Schema.org-jelölést. Ebből nem lehet más asszisztensek feldolgozási sorrendjére következtetni. Nincs megalapozott ok azt állítani, hogy JSON-LD nélkül egy oldal láthatatlan az MI számára. Forrás: Google AI-funkciók és weboldalak.
Mi változott a FAQ és a HowTo esetében?
A Google a HowTo bővített találatokat 2023. szeptember 13-án megszüntette; ezt az augusztusi bejelentés szeptemberi frissítése rögzíti. Ezért ma nem érdemes lépéses útmutatót erre a keresési megjelenésre hivatkozva eladni. Forrás: a Google HowTo- és FAQ-bejelentése.
A FAQ bővített találatok 2026. május 7-től szintén nem jelennek meg a Google Keresőben. A változásnapló ezt május 8-i bejegyzésben közli. A pontos Schema.org-típus neve FAQPage, nem FAQ. Forrás: Google Search dokumentációs változásnapló.
Egy hasznos kérdés–válasz rész ettől még segítheti a vásárlót. A tartalmat azért tartsd meg, mert megválaszolja például a szállítás, garancia vagy ajánlatkérés kérdéseit. Meglévő jelölés esetén vizsgáld meg, van-e más tényleges felhasználója; ne rendelj külön fejlesztést egy megszűnt Google-megjelenés reményében.
Mely adatokkal kezdjen egy kisebb vállalkozás?
Céges oldalon a szervezet pontos neve és URL-je jó kiindulópont. Helyi üzletnél a megfelelő LocalBusiness-altípus, a cím és a valós nyitvatartás lehet releváns. Cikknél a BlogPosting, termékoldalnál a Product és az ajánlati adatok, navigációnál a BreadcrumbList vizsgálható.
A kiválasztást az oldal tartalma indokolja. Egy kizárólag online működő céghez ne készíts kitalált ügyfélfogadó üzlethelyiséget. A helyi vállalkozás jelölése azt írja le, hogy mivel foglalkozik és hol érhető el; nem állítja elő a választ arra, hogy „ki a legjobb szolgáltató”.
Az első kör legyen szűk és ellenőrizhető. Jobb egy karbantartott cégadatblokk és cikkjelölés, mint sok egymásnak ellentmondó típus. A fölösleges mezők később is munkát adnak, amikor a cég címet vált, átnevezi szolgáltatását vagy módosítja az árait.
BlogPosting-minta az aktuális cikkhez
Az alábbi minta a cikk címét, szerzőjét és szerkesztőségi dátumait használja. A kanonikus URL alakját a tényleges publikálási beállításhoz kell igazítani. Ez implementációs példa, nem állítás arról, hogy az éles oldal már tartalmazza ezt a blokkot.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://conendigital.hu/blog/json-ld-strukturalt-adatok#article",
"url": "https://conendigital.hu/blog/json-ld-strukturalt-adatok",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://conendigital.hu/blog/json-ld-strukturalt-adatok"
},
"headline": "JSON-LD és strukturált adatok: gyakorlati útmutató KKV-knak",
"inLanguage": "hu-HU",
"datePublished": "2026-04-18",
"dateModified": "2026-10-18",
"author": {
"@type": "Person",
"name": "Chris Conen"
},
"publisher": {
"@type": "Organization",
"@id": "https://conendigital.hu/#organization",
"name": "Conen Digital",
"url": "https://conendigital.hu/"
}
}
A kódot application/ld+json típusú script elembe kell tenni. A #article és #organization végű azonosítók az entitások következetes hivatkozását szolgálják; nem szükséges külön oldalt létrehozni minden ilyen azonosítóhoz.
A tényleges cikkhez tartozó, elérhető képet érdemes hozzáadni az image mezőben, ha rendelkezésre áll. Kitalált kép- vagy szerzői profil-URL ne kerüljön be csak a kitöltöttség kedvéért. A Google cikkdokumentációja felsorolja az ajánlott tulajdonságokat és a képkezelés feltételeit. Forrás: Article strukturált adatok.
A publikálás dátuma maradjon az eredeti. A módosítás dátuma valódi tartalmi frissítést kövessen; egy napi újraépítés miatt ne legyen minden cikk látszólag friss. A megjelenített dátum és a gépi mező ugyanabból a szerkesztőségi adatból készüljön.
Magyar üzleti példa kitalált eredmények nélkül
A következő példa fiktív oktatási minta, az example.com cím nem ügyfélreferencia. A mintához tartozó látható szöveg: „Minta Kerékpárszerviz, 1111 Budapest, Példa utca 1. Nyitvatartás: hétfőtől péntekig 09:00–17:00.” Ezeket az adatokat éles oldalon kizárólag a valódi cég adataira cserélve szabad használni.
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"@id": "https://example.com/#business",
"url": "https://example.com/",
"name": "Minta Kerékpárszerviz",
"address": {
"@type": "PostalAddress",
"streetAddress": "Példa utca 1.",
"postalCode": "1111",
"addressLocality": "Budapest",
"addressCountry": "HU"
},
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "17:00"
}]
}
Szándékosan nincs benne csillagos értékelés, díj vagy ügyfélszám. Ezeket nem helyes példából átmásolni, és a jelölésükre külön keresőszabályok vonatkozhatnak. A nyitvatartás sem örök adat: ünnepi eltérésnél a látható tájékoztatást és a strukturált változatot együtt kell karbantartani.
Két teszt és egy tartalmi ellenőrzés
Első lépésként ellenőrizd a JSON szintaxisát. Egy hiányzó vessző vagy hibás idézőjel az egész blokkot feldolgozhatatlanná teheti. Ezután a Schema.org Validator segítségével vizsgáld a típusokat és tulajdonságokat; az eszköz feladatát a Schema.org dokumentációja ismerteti.
A Google Rich Results Test eszköze a Google által támogatott bővített találatok követelményeit vizsgálja. Nem teljes Schema.org-validátor. Ha egy általános szervezeti vagy üzleti jelöléshez nem jelez külön találattípust, abból önmagában nem következik, hogy a teljes adat hibás.
A harmadik ellenőrzés emberi: ugyanazt állítja-e a kód, amit az oldalon látni lehet? A „nincs hiba” eredmény nem ellenőrzi helyetted, hogy valódi-e a nyitvatartás, jogos-e az értékelés vagy aktuális-e az ár. Mentsd el a vizsgált URL-t, dátumot és az esetleges figyelmeztetések indoklását.
Karbantartás és biztonság a gyakorlatban
A látható oldal és a JSON-LD ugyanabból az adatforrásból épüljön. Webshopnál az ár és készlet változása a gyorsítótár frissítését is érintse. CMS-nél ellenőrizd, nem ad-e a téma és egy bővítmény két külön, ellentmondó adatblokkot ugyanarról a cégről.
A szerkesztő által beírt szöveget biztonságosan sorosító megoldással alakítsd JSON-LD-vé; ne kézzel fűzd be HTML-script elembe. A scriptkörnyezetből való kitörést is kezelni kell: a puszta JSON-sorosítás nem elegendő XSS-védelem. Erre a Next.js JSON-LD-útmutatója is felhívja a figyelmet. Személyes vagy belső üzleti adatot ne tegyél a blokkba: attól, hogy nem látszik a szövegben, a nyilvános HTML-ből még kiolvasható.
Az átadási feltétel tehát ne annyi legyen, hogy „van schema”. Legyen megnevezett adatgazda, közös adatforrás, dokumentált ellenőrzés és frissítési szabály. Így a jelölés hosszabb távon is a vállalkozás valós működését írja le, és nem válik az oldalon felejtett, elavult állítások gyűjteményévé.
HÍRLEVÉL
Az új írások elsőként nálad.
Szólunk, ha új cikk jelenik meg a webáruházakról, a SEO-ról és az AI-keresésről. Legfeljebb havonta egyszer, bármikor leiratkozhatsz.


