Van egy weboldalad. Rajta a cégnév, a cím, a telefonszám, öt szolgáltatásoldal, egy bemutatkozás, negyven blogcikk és három szerző. Emberi szemmel ez teljesen világos rendszer. Gépi szemmel viszont egy csomó szöveg, amiről semmi nem árulja el biztosan, hogy a lábléc telefonszáma ugyanahhoz a vállalkozáshoz tartozik-e, mint a kapcsolati oldalé, vagy hogy a cikk alján szereplő név szerző, ügyfél, esetleg egy interjúalany.

A strukturált adatok pontosan ezt a hiányt töltik be. Nem helyettesítik a látható tartalmat, hanem gépileg olvasható leírást adnak róla. Az AI-alapú keresésben pedig már nem elég indexelhetőnek lenni: egyértelműen értelmezhetőnek is kell lenni. Ki a szolgáltató, mit kínál, hol dolgozik, ki írta a tartalmat, és hogyan kapcsolódnak egymáshoz az oldalak.

Az AI-láthatóság a Google AI Overviews, a ChatGPT Search és a Perplexity rendszerében soha nem egyetlen technikai beállításon múlik, hanem a weboldal teljes információs rendszerén. A Schema markup ennek a rendszernek az egyik rétege – és ebben a cikkben az öt legfontosabbat vesszük végig: Organization, LocalBusiness, Service, Article és FAQPage.

@alapok

1. Mi a Schema markup, és mit jelent az AI SEO szempontjából?

A Schema.org egy közösen használt szókészlet: egy szótár, amelyben a keresőmotorok és a weboldalak ugyanazokat a fogalmakat ugyanúgy nevezik. Ennek segítségével megjelölhető, hogy egy adott adat vállalkozásnév, szolgáltatás, postai cím, szerző, cikk, kérdés vagy éppen válasz. A jelölés legtöbbször JSON-LD formátumban kerül az oldal forráskódjába, egy külön kódblokkban, a látható tartalomtól elkülönítve.

A Google a JSON-LD mellett a Microdata és az RDFa formátumot is támogatja, a dokumentációja mégis egyértelműen a JSON-LD használatát ajánlja. Ennek gyakorlati oka van: a JSON-LD nem keveredik bele a HTML-szerkezetbe, így sablonváltásnál, dizájnfrissítésnél vagy oldalszerkesztő használatakor sokkal kevésbé törik el.

A Schema markup akkor működik, ha stabil alapokra épül. Hibás sitemap, lassú betöltés, vékony tartalom és kaotikus belső linkelés mellett a jelölés nem hoz csodát: a technikai SEO és a tartalomoptimalizálás nélkül a strukturált adat csak szép kód egy gyenge oldalon.

@type: Organization

2. Organization: a vállalkozás központi digitális személyazonossága

A legfontosabb kérdés, amire ez a jelölés válaszol: ki áll a weboldal, a tartalmak és a szolgáltatások mögött? Az Organization entitást általában a főoldalon vagy a bemutatkozó oldalon érdemes létrehozni, és onnantól kezdve az egész oldal erre hivatkozik vissza.

A gyakorlatban ezek a tulajdonságok viszik a súlyt: name, legalName, url, logo, description, address, telephone, email, contactPoint, sameAs, founder, foundingDate, areaServed és hasOfferCatalog.

A legtöbb elrontott jelölésnél nem valamelyik mező hiányzik, hanem az @id. Adj a vállalkozásnak egy állandó, saját azonosítót – például https://pelda.hu/#organization –, és onnantól minden szolgáltatás, cikk és szerzői profil erre hivatkozhat. Enélkül minden oldalon egy új, névtelen szervezet születik, ami pontosan az ellenkezője annak, amit el akarunk érni.

AI SEO szempontból az Organization azt tisztázza, melyik márka a weboldal tulajdonosa, melyik szervezet publikálja a cikkeket, mely szolgáltatások tartoznak hozzá, és mely közösségi vagy szakmai profilok képviselik ugyanazt az entitást. A Google szerint az Organization strukturált adat segíthet a szervezet azonosításában és elkülönítésében, valamint a logó, a jogi név és egyes szervezeti adatok pontosabb értelmezésében.

Az egységes szervezeti adatok nem csak a klasszikus keresésben számítanak: a ChatGPT Search láthatóságát támogató entitásjelek rendszerében is központi szerepük van.

@type: LocalBusiness

3. LocalBusiness: helyi vállalkozások, üzletek és telephelyek

Mikor használjunk LocalBusiness típust az általános Organization helyett? Egyszerű a szabály: ha van konkrét fizikai hely, ahol a szolgáltatás történik. Étterem, fodrászat, fogászati rendelő, autószerviz, ügyvédi iroda, bolt, hotel, helyi szolgáltató vállalkozás – mind ide tartozik.

Ahol lehet, ne álljunk meg a általános típusnál. A Dentist, Restaurant, Hotel, AutoRepair, LegalService, Store vagy ProfessionalService altípus pontosabb képet ad. A Google dokumentációja is azt javasolja, hogy a lehető legpontosabb, ténylegesen alkalmazható típust válasszuk – nem azt, amelyik a legjobban hangzik.

A fontos adatok: vállalkozás neve, fizikai cím, földrajzi koordináták, telefonszám, nyitvatartási idő, weboldal, logó és képek, kiszolgált terület, árkategória, valamint foglalási vagy kapcsolatfelvételi lehetőség. Ezekből a Google üzleti adatokat, nyitvatartást és útvonaltervezési információkat is értelmezhet. Fontos ugyanakkor tisztán látni: a helyes jelölés nem garantál tudáspanelt vagy kiemelt megjelenést. Jogosultságot adhat, nem eredményt.

Több telephely esetén ne próbáljunk egyetlen entitásba belezsúfolni mindent. Minden valós telephely kapjon külön LocalBusiness entitást, saját címmel, telefonszámmal, nyitvatartással, URL-lel és @id azonosítóval. A központi vállalat maradhat Organization, a telephelyek pedig hozzá kapcsolódó, önálló LocalBusiness entitások lesznek.

Helyi cégeknél ez a réteg akkor kezd igazán működni, ha az AI-láthatóság technikai, GEO- és AEO-alapjai is a helyükön vannak.

@type: Service

4. Service: a szolgáltatási oldalak gépi leírása

A Service jelölés célja, hogy minden fontos szolgáltatás önálló entitásként létezzen, ne csak bekezdésként egy hosszú oldalon. Javasolt tulajdonságok: name, description, serviceType, provider, areaServed, audience, offers, hasOfferCatalog, availableChannel, termsOfService, hoursAvailable, url, image.

Egyetlen részlet, ami az egész jelölés értékét eldönti: a provider ne egyszerű szövegként szerepeljen. Hivatkozzon vissza a központi Organization vagy LocalBusiness @id azonosítójára. Így lesz a szolgáltatásból nem lebegő adat, hanem egy konkrét céghez tartozó kínálat.

Gyakori hiba, hogy egyetlen általános Service objektumban próbáljuk felsorolni a vállalkozás összes tevékenységét. Ez sem az embernek, sem a gépnek nem segít. A fontos szolgáltatásokhoz készüljön külön szolgáltatási oldal, külön cím és leírás, külön célközönség, külön kiszolgált terület és külön Service entitás. Például: technikai SEO audit, AI-láthatósági audit, tartalomstratégia, linképítés, weboldalkészítés – öt oldal, öt entitás.

Egy szolgáltatási oldal jelölését soha nem önmagában érdemes nézni: érdemes egy teljes SEO audit részeként ellenőrizni, a tartalommal és a belső linkeléssel együtt.

@type: Article

5. Article: cikkek, szerzők és kiadók összekapcsolása

Az Article – blogok esetén a pontosabb BlogPosting – típus a tartalom eredetét írja le. Kulcsmezők: headline, description, image, datePublished, dateModified, author, publisher, mainEntityOfPage, articleSection, keywords, wordCount.

Az author lehet Person vagy Organization, de valódi szerzőt kell megadni. Nem a márkanevet szerzőként, nem egy kitalált „szakértői csapatot”. A publisher pedig hivatkozzon a korábban létrehozott szervezeti entitásra – ezzel zárul be a kör a cikk és a cég között.

Az Article strukturált adat segíthet a Google-nek a cím, a képek, a szerzői információk és a publikálási dátum pontosabb értelmezésében, és bizonyos keresési felületeken jobb cikkmegjelenésre teheti jogosulttá az oldalt. A megjelenés azonban itt sem garantált.

AI SEO szempontból az igazi nyereség az, hogy egy jól összekapcsolt cikkből egyértelműen kiderül: ki írta, mely szervezet publikálta, mi a témája, mikor frissítették, és mely szolgáltatáshoz vagy szakmai területhez kapcsolódik. Ez öt olyan információ, amit egy nyelvi modell egyébként csak találgatna.

A jelölés persze csak a keret. A szövegnek magának is követnie kell a SEO szövegírás alapelveit, különben pontosan leírt, jól címkézett, de gyenge tartalom marad.

@type: FAQPage

6. FAQPage: mire használható, és mire nem?

Kezdjük a legfontosabb pontosítással, mert ebben nagyon sok elavult tanács kering. A FAQPage továbbra is létező, érvényes Schema.org típus, de a Google a hozzá kapcsolódó látványos, lenyitható GYIK-találatokat általában csak elismert, hiteles kormányzati és egészségügyi oldalakon jeleníti meg rendszeresen. Egy átlagos céges vagy marketingoldalon ezért senkinek nem szabad lenyitható Google GYIK-találatot ígérni.

Használjuk akkor, ha az oldalon valóban látható több gyakori kérdés, mindegyikhez egy hivatalos válasz, és a válaszokat maga az oldal üzemeltetője adja. Ne használjuk fórumoknál vagy olyan felületeken, ahol több felhasználó válaszolhat ugyanarra a kérdésre – ott a QAPage lehet indokolt.

AI SEO szempontból a rövid, pontos kérdés–válasz blokkok azért értékesek, mert könnyen feldolgozható, önmagában is értelmes tartalmi egységeket alkotnak. Egy generatív rendszer sokkal szívesebben emel ki egy 40 szavas, teljes választ, mint egy háromoldalas szövegfolyam közepét. A hangsúly viszont a hasznos, látható válaszokon van, nem a kódban elhelyezett jelölésen.

@graph

7. Hogyan kapcsoljuk össze a típusokat egyetlen rendszerben?

Itt válik szét a jó és a rossz implementáció. A gyenge megoldás öt különálló Schema blokkot tesz az oldalra, amelyek nem tudnak egymásról. A jó megoldás egyetlen @graph tömböt használ, amelyben az elemek @id azonosítókkal hivatkoznak egymásra. A Google dokumentációja szerint egy oldalon több strukturált entitás is elhelyezhető, és az egymáshoz tartozó elemeket érdemes @id segítségével összekapcsolni, hogy a rendszer felismerje a kapcsolatukat.

Egy tipikus blogcikk oldalán ezek az elemek jelenhetnek meg. Kattints egy csomópontra, és megnézheted, mihez kapcsolódik.

A kapcsolatok logikája néhány mondatban összefoglalható: az Article.publisher mutasson az Organization elemre, az Article.author a szerző Person elemére, a Service.provider a szolgáltatóra, a WebPage.isPartOf a WebSite elemre, a mainEntityOfPage pedig kösse össze a cikket és a weboldalt. A telephelyek kapcsolódjanak a központi vállalathoz.

A leggyakoribb technikai probléma nem is a logika, hanem a duplikáció. WordPress alatt könnyen előfordul, hogy több bővítmény is létrehoz külön Organization objektumot, eltérő logóval, más névvel, egymásnak ellentmondó címmel, és mellé duplikált Article jelölést. A gép ilyenkor nem tudja eldönteni, melyik az igazi – és a bizonytalanság az utolsó dolog, amit el akarunk érni. Az ilyen ütközéseket rendszeres strukturáltadat-minőségbiztosítással lehet feltárni.

@validáció

8. Ellenőrzés, validálás és folyamatos karbantartás

A strukturált adat nem „kész” állapot, hanem karbantartott állapot. A cím változik, a nyitvatartás változik, a szerző elmegy, a szolgáltatás átalakul – a jelölésnek követnie kell. Az alábbi hét lépés adja a minimumot; pipáld ki őket minden nagyobb módosítás után.

Egy dolgot fontos reálisan kezelni: a hibátlan teszt nem garantálja a gazdag megjelenést. A félrevezető vagy nem látható tartalom jelölése viszont a gazdag találatokra való jogosultság elvesztéséhez vezethet. A strukturált adatokhoz kapcsolódó manuális intézkedés önmagában nem feltétlenül módosítja a normál webes rangsorolást, de megszüntetheti a speciális találati megjelenést. A kockázat tehát aszimmetrikus: a jó jelölés esélyt ad, a rossz jelölés viszont biztosan elvesz valamit.

Összegzés: milyen sorrendben érdemes nekiállni?

1. Központi Organization vagy LocalBusiness entitás létrehozása.
2. Stabil, egyedi @id azonosítók kiosztása.
3. Külön Service jelölés a fontos szolgáltatási oldalakon.
4. Article vagy BlogPosting a szakmai tartalmakon, valódi szerzővel.
5. FAQPage csak ott, ahol látható kérdés–válasz tartalom van.
6. Rendszeres validálás és adatfrissítés.

A Schema markup nem helyettesíti a minőségi tartalmat, a technikai SEO-t vagy a márkahitelességet. Abban segít, hogy a már meglévő, valós információk következetesebb és géppel értelmezhetőbb rendszerben jelenjenek meg – és az AI-alapú keresésben pontosan ez a következetesség az, ami megkülönböztet egy megbízható forrást a zajtól.

Gyakori kérdések