2026-ban a strukturált adat (schema.org jelölés) nem rangsorolási trükk, hanem címke: segít a Google-nek egyértelműen azonosítani, ki vagy, mit publikálsz és ki írta. A legtöbb szolgáltató cégnek egy pontos Organization a kezdőlapon és egy rendes BlogPosting a cikkeken elég; a FAQPage-től már ne várj semmilyen látványos találatot, a Service pedig opcionális. Ami biztosan árt: olyan jelölés, ami nem azt írja le, ami az oldalon látszik.
Azért írjuk le ezt most, mert az elmúlt másfél évben a Google sorra kapcsolta ki a schema-alapú találati extrákat, és a „mit tegyek be a JSON-LD-be?” kérdésre adott régi válaszok jó része elavult. Nálunk minden új oldal sablonból kapja a jelölést, ezért nekünk is újra kellett gondolni, mi marad benne.
- A Google 2026. május 7-étől egyáltalán nem mutat GYIK-találatot, és júniusban a FAQ-dokumentációt is törölte. A meglévő FAQPage-jelölés nem árt, de újonnan nem érdemes ezért beépíteni.
- Az Organization a kezdőlapra való: név, URL, logó, elérhetőség,
sameAsprofilok. Ez segít a cég azonosításában és a logó megjelenítésében. - A Service érvényes schema.org típus, de a Google nem ad hozzá külön találati megjelenést. Ha használod, csak azt írd bele, ami az oldalon is ott van.
- A BlogPosting-nál nincs kötelező mező; a szerző, a dátumok, a cím és a kép számít. A szerzőt köss egy valódi szerzői oldalhoz.
- Az alapszabály változatlan: a jelölés a látható tartalmat írja le, semmi mást.
Mire jó még a strukturált adat 2026-ban?
A Google 2025 júniusában hét strukturáltadat-funkciót vezetett ki a találati oldalról (többek között a Course Info, az Estimated Salary és a Vehicle Listing megjelenést), 2025 novemberében a practice problem típust, 2026 májusában pedig a GYIK-találatot. Mindez a Search Central dokumentációs naplójában követhető.
Ebből sokan arra jutottak, hogy a schema halott. Szerintünk ez téves következtetés. A látványos extrák fogynak, de a jelölés eredeti funkciója, hogy géppel olvasható formában rögzítsd, mi micsoda az oldalon, megmaradt. A Google Organization-dokumentációja például kifejezetten arról szól, hogy a jelölés segít megkülönböztetni a cégedet más, hasonló nevű szervezetektől, és befolyásolhatja, melyik logó jelenik meg a találatok között és a tudáspanelen.
Amit viszont nem ígérünk: hogy a schema miatt jobb helyen leszel, vagy hogy az AI-keresők emiatt idéznek. A Google AI-funkciókról szóló útmutatója szerint az AI-összefoglalóban való megjelenéshez nincs külön technikai követelmény; a szokásos SEO-alapokat és a látható tartalommal egyező strukturált adatot említi. Hogy mi alapján idéz ténylegesen az AI-összefoglaló, arról saját mérésünkben írtunk.
Mit állíts be az Organization-nel?
Ez az egyetlen típus, amit minden cégnek javaslunk. A Google a kezdőlapra ajánlja, és nincs kötelező mezője: azt add meg, ami rád igaz. Mi ezeket tesszük bele:
nameés szükség eseténlegalName(a márkanév és a cégjegyzékben szereplő név sokszor eltér),urléslogo(a logó legyen stabil URL-en, ne egy hash-elt build-fájl),sameAs: a hivatalos profilok (LinkedIn, Facebook, GitHub), csak azok, amelyeket tényleg ti kezeltek,- elérhetőség:
email,telephone,address, ha ezek a weboldalon is szerepelnek, - egy állandó
@id, hogy a többi oldal jelölése erre hivatkozhasson.
A Google dokumentációja olyan azonosítókat is felsorol, mint az iso6523Code vagy a naics; ezeket a háttérben, egyértelműsítésre használja. Magyar kkv-nál ritkán van értelme ennyire belemenni, a pontos név, URL és a sameAs többet ér.
Egy minimális, de használható példa (a <script type="application/ld+json"> elembe kerül, a Google a JSON-LD formátumot ajánlja):
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.example.hu/#organization",
"name": "Példa Stúdió",
"legalName": "Példa Stúdió Kft.",
"url": "https://www.example.hu/",
"logo": "https://www.example.hu/logo.png",
"email": "hello@example.hu",
"sameAs": [
"https://www.linkedin.com/company/pelda-studio"
]
}Organization vagy LocalBusiness?
Ha van fizikai helyed, ahová az ügyfelek bemennek (üzlet, rendelő, szalon), a LocalBusiness valamelyik altípusa pontosabb, nyitvatartással és címmel. Ha főleg online vagy egyeztetett időpontban dolgozol, maradj az Organization-nél. Szerintünk a helyi találatoknál a Google Cégprofil ettől függetlenül többet számít bármilyen jelölésnél.
Kell-e Service séma a szolgáltatásoldalakra?
Rövid válasz: nem kell, de lehet. A Service érvényes schema.org típus, viszont a Google támogatott jelölések listájában nem szerepel, vagyis nem kapsz tőle semmilyen külön találati megjelenést. A Rich Results Test sem fogja „érvényes találatként” mutatni, ami sokakat összezavar.
Mi akkor tesszük be, ha a szolgáltatásoldal tényleg egy jól körülhatárolt szolgáltatásról szól, és a jelölés pusztán a látható tartalmat foglalja össze: name, description, provider (hivatkozás az Organization @id-jára), areaServed. Ennél többet nem. Két dolgot kifejezetten kerülünk:
- Ár vagy ajánlat a jelölésben, ha az oldalon nincs. Ami a JSON-LD-ben van, annak a látogató számára is látszania kell.
- Saját értékelések csillagként. A Google értékelési útmutatója szerint az Organization és a LocalBusiness saját oldalán gyűjtött, önmagáról szóló értékelések nem jogosultak csillagos megjelenésre. Az
aggregateRatinga szolgáltatásoldalon tehát legjobb esetben hatástalan.
Webshopnál más a helyzet: ott a Product és a merchant listing jelölés a Google által aktívan támogatott és fejlesztett terület, az ár, a készlet és a szállítás is megjelenhet a találatban. Ezt a webshopjainkban alapból kezeljük.
Mit kezdj a FAQPage-dzsel, most hogy nincs GYIK-találat?
A GYIK-találatot a Google már 2023 augusztusában jól ismert kormányzati és egészségügyi oldalakra szűkítette, 2026. május 7-én pedig teljesen megszüntette. A változásnapló szerint júniusban a dokumentációt is eltávolították, a Rich Results Test és a Search Console FAQ-riportja is megszűnt. A kivezetéskor a Google azt is leírta, hogy a nem használt strukturált adat nem okoz problémát a keresésben.
A mi gyakorlatunk ebből:
- Meglévő, valódi GYIK-blokknál maradhat a jelölés. Érvényes schema.org, nem árt, és nem tudjuk kizárni, hogy más rendszerek olvassák.
- Újonnan nem építünk FAQPage-et a találati megjelenés miatt. Az már nincs.
- Maga a látható kérdés–válasz szekció viszont marad. Rövid, konkrét kérdések egyenes válaszokkal: ezt az olvasó és az AI-keresők is a szövegből értik, nem a JSON-LD-ből.
Ha a GYIK-ot korábban csak a csillogó találat miatt raktad minden oldalra, ugyanazokkal az általános kérdésekkel, akkor most jó alkalom kitakarítani. Három valódi kérdés többet ér tíz kitöltő jellegűnél.
Hogyan jelöld a blogcikket BlogPostinggal?
A Google Article-dokumentációja szerint a cikk típusa Article, NewsArticle vagy BlogPosting lehet, és nincs kötelező mező; a javasolt tulajdonságokat érdemes megadni, amelyek az adott tartalomra igazak. Mi ezeket használjuk:
headline: a cikk tényleges címe, nem egy kulcsszavakkal kitömött változat,author: Person típus névvel ésurl-lel, amely egy valódi szerzői oldalra mutat (a Google ezt ProfilePage jelöléssel ajánlja, alternatívakéntsameAs-szel),datePublishedésdateModifiedidőzónával,image: ha van a cikkhez kép,publisher: hivatkozás az Organization@id-jára, így nem kell minden cikkben újra leírni a céget.
A dateModified-et csak akkor frissítjük, ha a tartalom érdemben változott. A dátum „felfrissítése” változtatás nélkül olcsó trükk, és a látogató is észreveszi, ha a „frissítve” cikkben a régi adatok szerepelnek.
Hogyan ellenőrizd, hogy rendben van?
Három eszközt használunk, mert mindegyik mást lát:
| Eszköz | Mire jó | Mire nem |
|---|---|---|
| Rich Results Test | Google által támogatott típusok (Organization, Article, Product) hibái | A Service-t és a FAQPage-et már nem értékeli |
| Schema Markup Validator | Bármilyen schema.org típus szintaktikai ellenőrzése | Nem mondja meg, mit kezd vele a Google |
| Search Console | Élesben, az egész oldalon jelentkező hibák | Csak a támogatott típusokra van riport |
A leggyakoribb hiba, amit auditokon látunk, nem a hiányzó mező, hanem az elsodródás: a sablon vagy egy bővítmény még a régi címet, telefonszámot vagy logót írja a jelölésbe, miközben az oldalon már más szerepel. Ezért nálunk a JSON-LD ugyanabból az adatból generálódik, amiből az oldal is, nem kézzel karbantartott külön blokk. Egyedi rendszereknél ezt fejlesztéskor érdemes eldönteni, utólag drágább.
Ha a nagyobb képet is látnád, a technikai SEO-ról szóló cikkünkben a strukturált adat a feltérképezéssel, a rendereléssel és az llms.txt-vel együtt szerepel.
Gyakori kérdések
Javít a strukturált adat a helyezésemen?
Közvetlen rangsorolási előnyt nem ad. Segít a Google-nek megérteni és egyértelműen azonosítani a tartalmat és a céget, és bizonyos típusoknál (például termékeknél) gazdagabb találatot tesz lehetővé.
Ki kell szednem a FAQPage-jelölést?
Nem kötelező. A Google szerint a nem használt strukturált adat nem okoz gondot. Ha a GYIK valódi és látható az oldalon, maradhat; ha csak a régi találat miatt került oda, nyugodtan kitakaríthatod.
Microdata vagy JSON-LD?
A Google mindkettőt érti, de a JSON-LD-t ajánlja, mert elkülönül a HTML-től, és könnyebb sablonból generálni és karbantartani.
Segít a schema abban, hogy a ChatGPT vagy az AI-összefoglaló idézzen?
Erre nincs olyan elsődleges forrás, amire építenénk. A Google az AI-funkcióknál nem ír elő külön jelölést. A pontos, látható, jól tagolt szöveg számít; a jelölés ezt legfeljebb kiegészíti.
Ha nem vagy biztos benne, hogy a weboldalad jelölése a valóságot írja le, az ingyenes SEO- és AI-láthatósági auditunkban ezt is átnézzük: mi hiányzik, mi elavult, és mi mond ellent az oldal tartalmának.