Service schema a szolgáltatásoldalakon

Scheo · 2026-07-18 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A szolgáltatásoldalak strukturált adatozása régóta gyengébb lábakon áll, mint a termékoldalaké. Egy webshopban a Product és az Offer típus szinte magától adódik, egy szolgáltatóvállalkozásnál viszont sokan bizonytalanok, mit is tegyenek a HTML-be. A Service schema pontosan erre a helyzetre való: strukturáltan leírja, hogy milyen szolgáltatást kínálsz, ki nyújtja és hol. Az alábbiakban végigveszem, mikor éri meg használni, hogyan kösd össze a szolgáltatót a cégentitással, mire jó az areaServed, és megnézünk egy tiszta kód-példát is.

Mi az a Service schema, és mire jó valójában?

A Service egy Schema.org típus, amivel egy nyújtott szolgáltatást írhatsz le géppel értelmezhető formában: mi a szolgáltatás neve, ki a szolgáltató, milyen területen érhető el, milyen kategóriába tartozik. A hangsúly a gépi értelmezhetőségen van, nem a látványon.

Fontos tisztázni egy elterjedt félreértést. Hivatalos információ, hogy a Google jelenleg nem kínál dedikált gazdag találat (rich result) megjelenést a Service típusra, ellentétben például a FAQPage vagy a Product egyes eseteivel. Ez azt jelenti, hogy a Service jelöléstől nem fog csillag, ár vagy kép megjelenni a találati listában. A haszna máshol van: egyértelművé teszi a keresők és az AI-alapú válaszmotorok számára, hogy az oldal egy konkrét szolgáltatásról szól, mit takar, és kihez köthető. Szakmai feltételezés, hogy ez a fajta egyértelműség hosszabb távon segítheti az entitás-megértést és a témába illesztést, de garantált előnyt nem ad, és önmagában nem javít helyezést.

Mikor használd a Service típust, és mikor ne?

Röviden: akkor használd, ha az oldal fő tárgya egyetlen, jól körülhatárolt szolgáltatás, amit egy azonosítható szolgáltató nyújt. Ha az oldal valójában cikk, terméklista vagy általános bemutatkozó, más típus illik rá jobban.

Jó jelöltek a Service típusra:

• Egy dedikált szolgáltatásoldal, például "Épületgépészeti tervezés" vagy "Autóklíma-töltés".
• Olyan oldal, ahol egyértelmű a szolgáltató és a kiszolgált terület.
• Olyan kínálat, amit nem lehet darabáruként, termékként leírni.

Ezeknél viszont ne a Service legyen az elsődleges választás:

• Blogcikk vagy útmutató egy szolgáltatásról: ide az Article vagy BlogPosting való, a Service legfeljebb hivatkozásként.
• Konkrét, megvásárolható termék vagy csomag rögzített feltételekkel: ott a Product és Offer pontosabb.
• Maga a cég főoldala: ott az Organization vagy LocalBusiness az alap, a szolgáltatásokat külön aloldalakon érdemes jelölni.

Saját tapasztalat, hogy a leggyakoribb hiba a túljelölés: minden szolgáltatáshoz külön Service-t raknak, tele árral és ígérettel, miközben az oldalon ezek az adatok nem is szerepelnek. A strukturált adat első szabálya, hogy csak azt jelölöd, ami a látogató számára is látható az oldalon. Ha ettől eltérsz, a jelölés inkább kockázat, mint előny.

Hogyan kösd a providert az Organization entitáshoz?

A provider mező mondja meg, ki nyújtja a szolgáltatást. Itt ne szabad szöveget adj meg, hanem hivatkozz a saját cégentitásodra egy Organization (vagy ha helyi vállalkozás vagy, LocalBusiness) objektummal, lehetőleg @id-vel összekötve.

Az @id technika lényege, hogy a cégedet egyszer definiálod egy stabil azonosítóval (jellemzően a főoldal URL-je egy horgonnyal, például https://pelda.hu/#organization), és minden más helyen erre az @id-re hivatkozol. Így a keresők és a válaszmotorok tudják, hogy ugyanarról az entitásról van szó, nem véletlenül egyező nevű cégekről. Ez a gyakorlat az entitásépítés egyik alapköve.

A jó felépítés lépésről lépésre:

1. A cégedet egyszer definiáld Organization-ként egy @id-vel (érdemes a főoldalon vagy egy közös blokkban).
2. A szolgáltatásoldalon a Service provider mezőjében erre az @id-re utalj vissza.
3. Gondoskodj róla, hogy a hivatkozott Organization tartalmazza a legfontosabb adatokat: name, url, és ha van, logo, telephone, cím.
4. Ha helyi, telephelyhez kötött szolgáltatásról van szó, a LocalBusiness altípus pontosabb, mert kezeli a nyitvatartást és a földrajzi adatokat is.

Mire való az areaServed, és hogyan add meg helyesen?

Az areaServed azt írja le, hol érhető el a szolgáltatás. Ez különösen fontos, ha egy adott városban, megyében vagy régióban dolgozol, mert segít a keresőnek a földrajzi kontextust érteni.

Az areaServed értékét többféleképpen adhatod meg. A legegyszerűbb egy sima szöveges érték, például egy településnév. Ennél pontosabb, ha strukturált objektumot használsz, például egy City vagy AdministrativeArea típust névvel. Néhány elv, amit érdemes tartani:

• Csak valós kiszolgálási területet adj meg. Ha ténylegesen Székesfehérváron és környékén dolgozol, ne írj oda egy fél országot.
• A településnevek ragozásánál a szövegben ügyelj a helyes alakra (Budapesten, Székesfehérváron), a jelölésben viszont az alanyeset a természetes ("Budapest", "Székesfehérvár").
• Ha országosan dolgozol, megadhatod a Country típust vagy egyszerűen az ország nevét.
• Több terület esetén az areaServed tömbként is felsorolható.

Szakmai feltételezés, hogy a pontos, valós areaServed jó eséllyel segíti a helyi keresési relevanciát és a válaszmotorok földrajzi szűrését, de önmagában nem garantál helyi megjelenést. A helyi láthatóságnak továbbra is a Google cégprofil és a következetes cégadatok maradnak az erősebb pillérei.

Hogyan néz ki egy tiszta Service kód-példa?

Az alábbi JSON-LD egy szolgáltatásoldalra való minimál, de teljes példa. A provider az Organization @id-jére hivatkozik, az areaServed pedig egy konkrét várost jelöl.

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Service", "name": "Autóklíma-töltés és -tisztítás", "serviceType": "Autóklíma-karbantartás", "description": "Személyautók klímarendszerének töltése, szivárgásvizsgálata és fertőtlenítése.", "provider": { "@type": "Organization", "@id": "https://pelda.hu/#organization", "name": "Példa Autószerviz", "url": "https://pelda.hu/" }, "areaServed": { "@type": "City", "name": "Székesfehérvár" }, "url": "https://pelda.hu/szolgaltatasok/autoklima-toltes" } </script>

Néhány megjegyzés a példához:

• A name a szolgáltatás neve, a serviceType pedig a kategóriája. A kettő eltérhet, ha a nevet marketinges okból másképp fogalmazod.
• A description maradjon tényszerű és igazodjon az oldal tartalmához. Ne ígérj benne garantált eredményt.
• Ha van hozzá logikus Offer (például egyértelmű, publikált feltételekkel), az bekerülhet, de csak akkor, ha az oldalon is szerepel. Az árat itt szándékosan kihagytam.
• A url az adott szolgáltatásoldalra mutasson, ne a főoldalra.

Hogyan ellenőrizd, hogy jól működik-e a jelölés?

Röviden: a jelölés akkor jó, ha érvényes, konzisztens az oldal tartalmával, és a hivatkozott entitások összeérnek. Ehhez érdemes egy rövid ellenőrzőlistát végigfutni.

• Futtasd le a kódot a Schema.org Validatorral: tisztázza a szintaktikai és típushibákat.
• Nézd meg a Google Rich Results Testtel: bár a Service-hez nincs gazdag találat, a teszt jelzi, ha értelmezhető-e a strukturált adat.
• Ellenőrizd, hogy a provider @id-je pontosan egyezik a máshol definiált Organization @id-jével. Egyetlen elütés elszakítja az entitásokat.
• Vesd össze a jelölést az oldal látható tartalmával: minden mezőnek legyen fedezete a szövegben.
• Ellenőrizd, hogy az areaServed valós kiszolgálási területet jelöl.
• Ha frissítesz a Google Search Console URL-vizsgálatával, nézd meg, hogyan látja a Google a renderelt oldalt.

Saját tapasztalat, hogy a legtöbb hiba nem a Service típusban van, hanem a köré épített entitásokban: hiányzó vagy inkonzisztens @id, elgépelt URL, vagy olyan mező, aminek nincs megfelelője az oldalon. Ha ezekre figyelsz, a jelölés stabil marad, és jó alapot ad az egyéb strukturált adatok bővítéséhez, például a morzsamenü vagy a GYIK jelöléséhez.

Források és további olvasnivalók

• Schema.org: Service, Organization, LocalBusiness és areaServed dokumentáció
• Google Search Central: Bevezetés a strukturált adatokba és a strukturált adatok általános irányelvei
• Google Rich Results Test és a Schema Markup Validator
• W3C: JSON-LD 1.1 specifikáció