SEO és AI-keresésFrissítve: 8 perc olvasás

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.

Hajtogatott matt papírlapok halma szénfekete geometriai blokk mellett, tetején egy égetett narancssárga agyag gömb.

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é.

#JSON-LD#schema.org#strukturált adatok#SEO#AI

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.