A strukturált adat legnagyobb ereje nem az egyes mezőkben van, hanem abban, hogy a keresők és a válaszmotorok összefüggő egészként lássák a weboldalad mögötti szereplőket: a szervezetet, a szerzőket és a tartalmakat. Ezt az összekötést a JSON-LD @id tulajdonsága teszi lehetővé. Ha jól használod, egyetlen, jól definiált entitásgráfot építesz. Ha rosszul, akkor ugyanabból a cégből vagy szerzőből több, egymással nem beszélő verziót gyártasz.
Mi az @id a JSON-LD-ben, és miért nem ugyanaz, mint a canonical?
Az @id egy globálisan egyedi, stabil azonosító (URI) egy entitáshoz, nem egy oldalhoz. Ez a Schema.org és a JSON-LD (a W3C ajánlása) alapmechanizmusa: kijelöl egy csomópontot a gráfban, amire máshonnan hivatkozni lehet.
Fontos a különbség: a canonical link azt mondja meg, melyik URL a mértékadó verziója egy oldalnak. Az @id ezzel szemben egy dolgot azonosít: egy céget, egy embert, egy cikket. Egy szerző @id-je akkor is ugyanaz marad, ha ötven különböző oldalon szerepel a neve. Ez hivatalos, a JSON-LD specifikációból következő működés, nem szakmai vélemény.
A gyakorlatban az @id-nek érdemes egy valós, létező URL-t választani, kiegészítve egy horgonnyal (fragmenttel), ami megmondja, melyik entitásról van szó az adott oldalon belül. Például: https://pelda.hu/#organization a cégre, https://pelda.hu/rolam/#person a személyre.
Hogyan néz ki a valós kód, ami összeköti a három entitást?
A lényeg: definiáld egyszer az Organization-t és a Person-t saját @id-vel, majd máshol csak hivatkozz rájuk ugyanazzal az @id-vel. Így néz ki egy összefüggő gráf egy cikkoldal fejlécében:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://pelda.hu/#organization",
"name": "Példa Kft.",
"url": "https://pelda.hu/",
"logo": "https://pelda.hu/logo.png",
"founder": { "@id": "https://pelda.hu/rolam/#person" },
"employee": { "@id": "https://pelda.hu/rolam/#person" }
},
{
"@type": "Person",
"@id": "https://pelda.hu/rolam/#person",
"name": "Kovács Anna",
"jobTitle": "online marketing szakértő",
"worksFor": { "@id": "https://pelda.hu/#organization" },
"sameAs": [
"https://www.linkedin.com/in/kovacsanna",
"https://hu.wikipedia.org/wiki/..."
]
},
{
"@type": "WebSite",
"@id": "https://pelda.hu/#website",
"url": "https://pelda.hu/",
"name": "Példa",
"publisher": { "@id": "https://pelda.hu/#organization" }
},
{
"@type": "WebPage",
"@id": "https://pelda.hu/cikk/#webpage",
"url": "https://pelda.hu/cikk/",
"isPartOf": { "@id": "https://pelda.hu/#website" }
},
{
"@type": "Article",
"@id": "https://pelda.hu/cikk/#article",
"headline": "A cikk címe",
"mainEntityOfPage": { "@id": "https://pelda.hu/cikk/#webpage" },
"author": { "@id": "https://pelda.hu/rolam/#person" },
"publisher": { "@id": "https://pelda.hu/#organization" },
"datePublished": "2026-01-10",
"dateModified": "2026-07-15"
}
]
}
Figyeld meg a mintát. A Person és az Organization teljes adattal egyszer szerepel. Mindenhol máshol csak egy rövid hivatkozás áll: { "@id": "..." }. Ez a JSON-LD referencia-szintaxisa. A gráf így egyértelmű: a cikk szerzője ugyanaz a személy, aki a cég alapítója és alkalmazottja, a kiadó pedig ugyanaz a szervezet, amelyik a weboldalt is működteti.
Mit köss mihez? A hivatkozások iránya
- Organization -> founder / employee -> Person: a cég megnevezi az embereit.
- Person -> worksFor -> Organization: a személy visszautal a cégre (a kapcsolat mindkét irányban álljon).
- Article -> author -> Person: ki írta a cikket.
- Article -> publisher -> Organization: ki adta ki.
- WebPage -> isPartOf -> WebSite: az oldal a weboldal része.
- Article -> mainEntityOfPage -> WebPage: a cikk melyik oldalon él.
Miért erős entitásjel ez a válaszmotoroknak?
Röviden: mert a keresők és a nyelvi modellek nem szövegmezőket, hanem összefüggéseket próbálnak érteni. Egy stabil @id-vel felépített gráf pontosan ezt adja nekik.
A Google hivatalos dokumentációja (Search Central) szerint a strukturált adat segít a rendszernek megérteni az oldal tartalmát és a szereplők közötti kapcsolatokat. Amikor a szerző @id-je ugyanaz a saját bemutatkozó oldalán, a szerzett cikkeken és a cég alkalmazotti listáján, akkor a rendszer nagyobb bizonyossággal tudja: ez egy és ugyanaz a személy. Ez összekapcsolható a sameAs hivatkozásokkal (LinkedIn, Wikipedia, hivatalos profilok), amelyek külső megerősítést adnak az entitásnak.
Ez a fajta koherencia jól illeszkedik az E-E-A-T logikájához: a tapasztalat, szakértelem és hitelesség jelei nem elszigetelt címkék, hanem egy konzisztens, visszakövethető azonosság köré épülnek. Saját tapasztalatom szerint azok az oldalak, ahol a szerző-entitás következetesen fel van építve és több helyről megerősített, tisztább jelet adnak a rendszereknek, mint ahol minden cikk egy névtelen vagy oldalanként újradefiniált szerzőt kap. Ez azonban szakmai megfigyelés, nem garantált rangsorolási tényező: a stabil @id önmagában nem javít helyezést, csak érthetőbbé teszi az entitásaidat.
Melyek a leggyakoribb hibák az @id használatában?
A tapasztalat azt mutatja, hogy a hibák túlnyomó része az inkonzisztenciából fakad: ugyanaz az entitás több, egymással nem összekötött formában jelenik meg.
- Oldalanként változó @id. Ha a szerző @id-je minden cikken az adott cikk URL-je, akkor minden cikkhez külön Person entitás jön létre. A rendszer így nem tud egy szerzőt kirajzolni, hanem lát ötven különbözőt. Az @id-nek változatlannak kell lennie az entitás minden előfordulásában.
- Elgépelt vagy nem egyező URI. A
#organizationaz egyik blokkban, a#orga másikban két külön csomópont. A hivatkozásnak karakterre pontosan egyeznie kell. - Az entitás teljes újradefiniálása minden blokkban. Ha minden oldalon kimásolod a teljes Person objektumot ahelyett, hogy hivatkoznál rá, könnyen elcsúsznak az adatok (más jobTitle, más név-formátum), és ellentmondó jelet küldesz.
- Egyirányú kapcsolat. A cég megnevezi az alkalmazottat (
employee), de a személy nem utal vissza (worksFor). A kétirányú kapcsolat erősebb és egyértelműbb. - Publisher mint Person. A cikk
publisher-e szervezet legyen, ne magánszemély. A szerző a Person, a kiadó az Organization. A kettő keverése zavaros gráfot ad. - Nem létező URL az @id-ben. Bár az @id technikailag lehet tetszőleges URI, jó gyakorlat valós, elérhető oldalra (a cégoldalra, a bemutatkozó oldalra) mutató alapot használni. Ez segít a keresőnek a horgonyzásban.
- Kimaradó dateModified. Nem @id-hiba, de gyakran együtt jár: a friss
dateModifiedhiteles kiegészítés a cikk-entitáshoz.
Milyen lépésekkel építs fel egy tiszta entitásgráfot?
Egy egyszerű, ismételhető folyamat, amit minden weboldalnál végig lehet vinni:
- Rögzítsd az @id-konvenciódat. Döntsd el egyszer: a cég
https://domain.hu/#organization, a weboldal#website, a szerző a saját bemutatkozó oldalán#person. Írd le, és mindenhol ezt használd. - Definiáld egyszer a törzsentitásokat. Az Organization és a Person teljes adatait tedd egy központi helyre (jellemzően a főoldal és a rólam oldal fejlécébe).
- A többi oldalon csak hivatkozz. Cikkeknél az
authoréspublishercsupán{ "@id": "..." }legyen. - Kösd össze kétirányban. Organization <-> Person, WebPage -> WebSite, Article -> WebPage.
- Adj hozzá sameAs-t a Person és Organization entitáshoz. Hivatalos külső profilok (LinkedIn, cégjegyzék, Wikipedia, ha van) megerősítik az azonosságot.
- Ellenőrizd. Fusson át a kód a Google Rich Results Test és a Schema.org validátor eszközön. Nézd meg, hogy a hivatkozott @id-k mind feloldódnak-e létező csomópontra.
Egy rövid ellenőrzőlista publikálás előtt: minden @id egyedi és stabil; minden hivatkozás egy létező @id-re mutat; a szerző Person, a kiadó Organization; a kapcsolatok kétirányúak; nincs elgépelés a fragmentekben.
Mit tegyél, ha WordPress vagy más CMS generálja a jelölést?
A legtöbb komolyabb SEO-bővítmény (például a Yoast) automatikusan @graph alapú JSON-LD-t állít elő, konzisztens @id-kkel. Ha ilyet használsz, ne írj mellé kézzel egy második, párhuzamos JSON-LD blokkot ugyanazokról az entitásokról más @id-vel, mert épp a duplikációt idézed elő, amit el akarsz kerülni. Ilyenkor a helyes út a bővítmény beállításainak pontosítása (cég- és szerzőadatok, logó, profilok kitöltése), nem a párhuzamos jelölés. Ha egyedi kódot írsz, akkor egyetlen, jól strukturált @graph legyen oldalanként.
Végül érdemes reális elvárással dolgozni: a strukturált adat egy jelzőrendszer, nem varázslat. Segítheti, hogy a keresők és a válaszmotorok pontosan értsék, ki áll a tartalom mögött, de a tartalom minőségét és a valós szakértelmet nem pótolja. Az @id ennek a jelzőrendszernek a gerince: ez teszi lehetővé, hogy a szétszórt adatok egyetlen, hiteles entitássá álljanak össze.
Források és további olvasnivalók
- Google Search Central: Bevezetés a strukturált adatokba és a strukturált adatok általános irányelvei
- Google Search Central: Article strukturált adat dokumentáció
- Schema.org: Organization, Person, Article, WebPage, WebSite típusdefiníciók
- W3C: JSON-LD 1.1 specifikáció (@id és node references)
- Google Rich Results Test és a Schema.org Validator eszközök
- Az @id egy globálisan egyedi, változatlan URI, ami egy entitást azonosít, nem egy oldalt ír le.
- Ugyanazt az @id-t újrahasználva (author, publisher, founder) egyetlen entitásgráfot építesz a szétszórt adatok helyett.
- Az Article->author->Person és Article->publisher->Organization összekötés erős szerzőségi és kiadói jel a válaszmotoroknak.
- A leggyakoribb hiba az inkonzisztens vagy oldalanként változó @id, ami két külön entitást hoz létre egy helyett.
- A stabil @id önmagában nem garantál jobb helyezést, de tisztább entitásjelet ad, ami segítheti a láthatóságot.
Gyakori kérdések
Kötelező, hogy az @id létező URL legyen?
Technikailag nem: az @id bármilyen egyedi URI lehet. A gyakorlatban viszont ajánlott valós, elérhető oldalra (cégoldal, bemutatkozó oldal) mutató alapot használni egy fragmenttel, mert ez segíti a keresőt az entitás horgonyzásában és csökkenti a hibalehetőséget.
Mi a különbség az @id és a canonical között?
A canonical egy oldal mértékadó URL-jét jelöli. Az @id egy entitást (cég, személy, cikk) azonosít, ami több oldalon is előfordulhat. A szerző @id-je ugyanaz marad az összes cikkén, míg minden oldalnak külön canonicalja van.
A szerző legyen author vagy a cég?
A cikk author mezője Person típusú, a valós szerző. A publisher mező Organization típusú, a kiadó cég. A kettőt ne keverd: a szerző ember, a kiadó szervezet.
Javít-e az @id a Google-helyezésemen?
Önmagában nem garantál jobb helyezést. Egy tiszta, konzisztens entitásgráf viszont segítheti, hogy a rendszerek pontosabban értsék a tartalom mögötti szereplőket, ami közvetve támogathatja a láthatóságot.
Több JSON-LD blokkot használjak, vagy egy @graph-ot?
Oldalanként egyetlen, jól felépített @graph a tisztább megoldás, mert minden entitás egy helyen definiált és a hivatkozások egyértelműek. Több párhuzamos blokk könnyen inkonzisztens @id-khez és duplikált entitásokhoz vezet.
Hogyan ellenőrzöm, hogy jól kötöttem-e össze az entitásokat?
Futtasd le a kódot a Google Rich Results Test és a Schema.org validátor eszközzel, majd nézd meg, hogy minden hivatkozott @id feloldódik-e egy létező csomópontra a gráfban, és nincs-e elgépelés a fragmentekben.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.