Organization vagy LocalBusiness séma: melyiket használd?

Sok vállalkozás tévesen azt hiszi, hogy az Organization és a LocalBusiness séma közül csak az egyiket kell megadni. Valójában a legtöbb esetben mindkettőre szükség van — és gyakran a Service sémára is. Az AI-modellek a JSON-LD strukturált adatból olvassák ki az azonosítókat: ki a cég, hol található, mit kínál, és hol ellenőrizhető mindez. Ez a cikk segít eldönteni, melyik sémát érdemes megadni, hogyan lehet ezeket kombinálni, és miért fontos a sameAs lista az entitás hitelességéhez.

Mit mond az AI az Organization-sémáról?

Az Organization séma a legáltalánosabb szintű entitásleírás: azt mondja az AI-nek és a Google-nak, hogy az oldalon azonosítható szervezet mutatja be magát. A @type mezőbe írt „Organization” érték közvetlenül az Organization típust jelöli a Schema.org taxonómiájában, és minden más típus — LocalBusiness, Corporation, NGO — ennek az altípusa.

Az Organization-blokkban legalább a következő tulajdonságok legyenek jelen: @id (a cég kanonikus URL-je, például https://example.hu/#organization), name (a tényleges márkanév, pontosan ugyanúgy, ahogy a Google Cégprofilon és más katalógusokban szerepel), url (a honlap gyökér-URL-je) és sameAs (tömb, amelybe a cég más megbízható forrásokban lévő azonosítói kerülnek: Google Cégprofil URL, Wikidata Q-azonosító, LinkedIn-oldal).

Miért olvassa ezt az AI? Mert az AI-modellek nem pusztán a szövegből próbálják kitalálni, melyik cégről van szó — a JSON-LD blokkból kiolvasott @id és sameAs értékeket használják arra, hogy az entitást elhelyezzék a tudásgráfjukban. Ha az @id egyezik a Wikidata-bejegyzés P856 (official website) mezőjével, és a sameAs a Google Cégprofil URL-jére mutat, az AI-nek nincs miért találgatnia: tudja, hogy az oldalon szereplő cég és a külső forrásokban említett cég ugyanaz. A 7 dimenzió második szintjén (D2 — strukturált adat, súly 15%) ez az egyik legközvetlenebb, technikai úton megszerezhető pont.

Ami hiányozhat, és rontja az AI-élményt: ha a name mező más formátumban szerepel, mint amit a Google Cégprofil mutat (pl. „ABC Kft.” vs. „ABC Kereskedelmi Kft.”), az AI elbizonytalanodik az entitásazonosításban. Hasonlóan ront a helyzeten, ha a sameAs teljesen hiányzik — ilyenkor a modell csak a domainnév alapján következtet, ami könnyen téves összekapcsoláshoz vezet. Ezt részletesen a hallucináció-cikkben fejtem ki: az egyik leggyakoribb hiba az, amikor az AI a helyes vállalkozás helyett egy hasonló nevű másik céget ajánl.

Hogyan tudja meg az AI, hogy a cég helyi vagy globális?

A LocalBusiness az Organization egyik leggyakrabban használt altípusa. Ha a vállalkozás meghatározott fizikai helyszínen üzemel — fogorvos, autószerelő, könyvelőiroda —, akkor a LocalBusiness (vagy annak egyik specifikusabb altípusa, pl. DentalClinic, AutoRepair, AccountingService) az elsődleges típus, amelyet be kell állítani. A Google helyi vállalkozás dokumentációja szerint a LocalBusiness sémával ellátott oldalaknál kötelező megadni a name, address és telephone mezőket — ez az a NAP-hármas (Név, Cím, Telefon), amelynek minden felületen következetesnek kell lennie.

A LocalBusiness és az Organization nem egymást kizáró választás. A @type mezőbe tömb is írható: ["LocalBusiness", "DentalClinic"], vagy egyszerűen a specifikus altípus is elegendő, mert a Schema.org hierarchia alapján a DentalClinic automatikusan LocalBusiness is és Organization is. Az AI-modellek ebből azt látják, hogy a cégnek fizikai helyszíne van, amelyet egy adott földrajzi területen kereső felhasználó megtalálhat — ez közvetlenül befolyásolja, hogy helyi lekérdezésekre szóba kerül-e a vállalkozás.

Ha a cég egyszerre több telephelyen is üzemel, akkor minden egyes telephelynek érdemes saját LocalBusiness blokkot adni, az adott oldal canonical URL-jével mint @id értékkel. A főoldalon az Organization-blokk fogja össze a „cégszintet”, az egyes telephelyek oldalain pedig a LocalBusiness-blokk írja le a helyi adatokat. Ez pontosan azt a struktúrát adja, amelyet a GEO-pontszám és az AI-ajánlás cikkben tárgyalt entitásazonosítási kérdés megoldásához kell: a modell tudja, hány telephely létezik, és melyik hol van — nem keveri össze őket.

Hogyan dönti el az AI, hogy valami inkább „lokális” vagy „globális”? Nem kizárólag az oldalon megadott típus alapján dönt, hanem a típus és a külső jelek együttese alapján: van-e Google Cégprofil a vállalkozáshoz, szerepel-e helyi katalógusokban és véleményplatformokon, és egyeznek-e a NAP-adatok. Ha a séma LocalBusiness-t mond, de sem GBP nem létezik, sem helyi katalógus nem hivatkozik rá, az AI ezen a ponton nem tudja biztonsággal helyi entitásként kezelni. Ezért a strukturált adat mindig a külső jelenléttel együtt hat — ez a két dimenzió egymást erősíti. Részletesebben a ChatGPT, Gemini, Perplexity és a magyar vállalkozások cikkben írom le, hogy a három modell miképp különbözteti meg a helyi és a nem helyi szereplőket.

Szükségesek a sameAs hivatkozások az Organization-ben?

Technikailag nem kötelezők — a Schema.org Validator és a Google Rich Results Test nem jelöl hibát a hiányzó sameAs miatt. Mégis ez az egyik legfontosabb mező, amelyet érdemes megadni, és az AI-láthatóság szempontjából kihagyhatatlan.

A sameAs értékek azok az „entitáshorgonyok”, amelyekkel az AI-modellek és a Google tudásgráfja összeköti az oldalon leírt céget a világ többi részén megjelenő azonos céggel. Ha a sameAs tartalmazza a Google Cégprofil URL-jét, a Wikidata Q-számot és a LinkedIn-oldalt, akkor a modell három független forráson is ellenőrizheti, hogy az adott szervezet valós, azonosítható entitás. Ahol ez az ellenőrzés sikerül, ott az AI magabiztosabban nevezi meg a céget — és kisebb a valószínűsége annak, hogy összekeveri egy hasonló nevű másik vállalkozással.

A magyar vállalkozásoknál leggyakrabban javasolt sameAs értékek:

• Google Cégprofil URL: a maps.google.com/maps?cid=... formátumú hivatkozás, amely egyértelműen azonosítja a GBP-bejegyzést.
• Wikidata Q-azonosító: https://www.wikidata.org/wiki/Q... — ha a cégnek van Wikidata-bejegyzése, ez az egyik legerősebb hitelességi jel az AI számára, mert a Wikidata enciklopédikus, harmadik fél által szerkesztett forrás.
• LinkedIn céges oldal: https://www.linkedin.com/company/... — különösen a B2B szegmensben kezelik erős jelként az AI-modellek a LinkedIn-jelenlétet.
• Facebook-oldal URL: helyi vállalkozások esetén hasznos kiegészítő, bár önmagában kevésbé hiteles, mint a Wikidata.

A sameAs feltöltésekor fontos, hogy minden hivatkozott oldal valóban létezzen és elérhető legyen. A sameAs listában szereplő broken link nem hat annyira rosszul, mint egy hibás NAP-adat, de csökkenti a blokk megbízhatóságát. Az ingyenes láthatóságmérési eszközök között is szerepelnek olyan validátorok, amelyek kimutatják a strukturált adat hibáit.

Mikor kerül be a Service séma is?

A Service séma akkor válik relevánssá, ha az oldalon nemcsak magát a vállalkozást, hanem egy konkrét szolgáltatást is le kell írni géppel olvasható formában. Egy könyvelőiroda esetén a szervezet (Organization vagy LocalBusiness) leírja, ki nyújtja a szolgáltatást; a Service séma pedig azt, hogy mit nyújt — pl. könyvelés, bérszámfejtés, adóbevallás-készítés. Az AI számára ez azért hasznos, mert a service-típus-specifikus lekérdezésekre (pl. „ki végez bérszámfejtést Győrben?”) a Service-blokkból ki tudja olvasni a releváns kínálatot, nem csak a vállalkozás általános nevét.

Webáruházak esetén a Service séma helyett általában az Offer és a Product sémák relevánsak — ezekből az AI-nek és az agentic commerce rendszereinek (ahol az AI önállóan vásárol a felhasználó nevében) az árazási és elérhetőségi adatokra van szükségük. Az agentic kereskedelemről és a Product/Offer sémák szerepéről részletesebben az agentic kereskedelem cikkben írok.

A kombinálás alapszabálya: az Organization (vagy LocalBusiness) blokk a cégszintű entitást írja le, a Service blokk az egyes kínálati elemeket, a kettőt pedig a provider vagy parentOrganization mező köti össze. Ez a hierarchia pontosan azt adja az AI-nek, amire szüksége van: tudja, ki a szereplő, mit nyújt, és hol található.

Hogyan ellenőrizd, hogy a séma működik-e?

Miután felírtad a JSON-LD blokkot, két eszközzel érdemes ellenőrizni. Az első a Google Rich Results Test (ingyenes), amely megmutatja, hogy a Google valóban olvassa-e a struktúrát, és jelzi az esetleges hiányzó kötelező mezőket. A második a Schema.org Validator, amely a típushierarchiával való összhangot ellenőrzi — például azt, hogy a megadott altípus tényleg létezik-e a taxonómiában.

Fontos: a validátor csak a szintaktikai helyességet nézi, nem azt, hogy a megadott adatok igazak-e. Ha a name mezőben más cég neve áll, a validátor nem fog hibát jelezni — de az AI entitásazonosítása sérül. Ezért a technikai ellenőrzés mellett mindig kézzel is össze kell vetni a JSON-LD tartalmát a Google Cégprofil adataival és az oldal látható tartalmával.

Az AI Labs Audit nemzetközi mérései szerint az érvényes strukturált adattal ellátott oldalak 20–30%-kal gyakrabban kerülnek be az AI-összefoglalókba, mint a séma nélküli társaik. Ez az arány ingyenes, technikai eszközökkel percek alatt elérhető javulás — és pontosan ezért kapja a strukturált adat a 7 dimenzió közül a D2 jelölést 15%-os súllyal. Hogy a többi dimenzió hogyan illeszkedik ebbe a képbe, a módszertan oldalon írom le tételesen.

Kindl Dávid · Közzétéve: 2026. július 1. · Frissítve: 2026. július 5.