Sok cégnél a szolgáltatásnak nincs egy neve, hanem van öt. A menüben az egyik szerepel, a szolgáltatásoldal címében a másik, a blogcikkekben a harmadik, az ajánlatkérő űrlapon a negyedik, a Google Cégprofilban az ötödik. Emberként ezt észre sem veszed, mert a fejedben mind ugyanazt jelenti. Egy nyelvi modell viszont pontosan azt dolgozza fel, ami le van írva, és neki külön munka eldönteni, hogy ezek tényleg egyetlen dologra utalnak-e. Az entitásszótár ezt a munkát veszi le róla, egyetlen A4-es oldalon.
Miért zavarja meg az AI-motorokat, ha öt néven hívod ugyanazt a szolgáltatást?
Rövid válasz: mert minden névváltozat külön jelöltet indít el a rendszerben, és a gépnek magának kell kitalálnia, hogy ezek egy fogalom változatai. Ha a döntés bizonytalan marad, a válaszban vagy nem te szerepelsz, vagy pontatlanul.
Tovább a témában: Szakmai fogalomtár oldal építése · Helyi SEO Szombathelyen
A válaszmotorok két lépésben dolgoznak. Először előkeresik azokat a szövegdarabokat, amelyek valószínűleg tartalmazzák a választ, majd ezekből fogalmazzák meg a feleletet. Az első lépésben a felhasználó kérdésének megfogalmazása kerül szembe a te szövegeddel. Ha a kérdező azt írja be, hogy „ki szerel klímát a környéken", a te oldaladon viszont végig „hűtéstechnikai kivitelezés" szerepel, a találkozás esélye kisebb. Nem lehetetlen, csak drágább: a rendszernek egy plusz általánosítási lépést kell megtennie, és minden ilyen lépésnél nő a tévedés esélye.
Hivatalosan igazolt: a Google dokumentációja évek óta írja, hogy a keresés nem pusztán karakterláncokat, hanem entitásokat (személyeket, cégeket, fogalmakat, helyeket) kezel, és hogy a strukturált adat feladata többek között az egyértelműsítés. A Schema.org szótárában külön tulajdonság szolgál az alternatív megnevezésre (alternateName) és a külső azonosításra (sameAs). Ezek nem trükkök, hanem a szabvány szándékolt használata.
Szakmai feltételezés: azt, hogy egy adott nagy nyelvi modell belül pontosan hogyan súlyozza a névváltozatokat, kívülről senki nem látja. Amit látunk, az a viselkedés: a következetesen egy néven nevezett szolgáltatásokat magabiztosabban, teljesebb kontextussal idézik vissza a válaszmotorok, mint a sokféleképpen nevezetteket. Ok-okozatot ebből nem bizonyítok, mintázatot igen.
Mit jelent az, hogy „hígul az entitáskapcsolat"?
Rövid válasz: azt, hogy a cégnév és a szolgáltatás közötti kapcsolat nem egyszer, erősen jelenik meg, hanem ötször, gyengén, öt különböző megnevezéssel.
Képzeld el, hogy az oldalad huszonöt helyen említi a szolgáltatást. Ha mind a huszonöt ugyanazt a nevet használja, a cégneved és a fogalom együtt-előfordulása huszonötször erősíti ugyanazt a kapcsolatot. Ha viszont öt név oszlik el rajtuk, akkor öt darab ötös kapcsolat keletkezik. Egyik sem lesz elég erős ahhoz, hogy egy generatív válaszban téged nevezzenek meg, amikor a felhasználó pont az egyik változatot használja.
Ez a hígulás máshol is fáj. A belső linkek horgonyszövegei szétszóródnak, a címsorok nem erősítik egymást, a strukturált adat neve eltér a látható H1-től, és ha valaki a cégedről kérdez egy asszisztenst, az sem tudja egy mondatban összefoglalni, hogy mit is csináltok. Saját tapasztalat: a legtöbb magyar kkv-oldalon nem hiányzik a tartalom, hanem szét van kenve. Ugyanaz a szolgáltatás négy aloldalon, négy néven, mindegyik félkészen. Egyetlen erős oldal helyett négy gyenge.
Mi kerül bele egy egyoldalas entitásszótárba?
Rövid válasz: fogalmanként hat mező, és a teljes dokumentum ne legyen hosszabb egy kinyomtatott oldalnál, különben senki nem fogja használni.
- Elsődleges megnevezés: az az egy alak, amit a H1-ekben, a menüben, a strukturált adatban és az ajánlatokban használtok. Egy fogalomhoz pontosan egy.
- Elfogadott szinonimák: azok a változatok, amiket a szövegben természetes módon használhat a szövegíró (jellemzően kettő, legfeljebb három). Ezek nem tiltottak, csak nem ők a fő alakok.
- Kerülendő alakok: a belső zsargon, a rossz helyesírású változat, a versenytárs márkaneve és minden olyan alak, ami mást is jelenthet.
- Angol megfelelő: nem a fordítás kedvéért, hanem mert a modellek tudásának jelentős része angolul épült fel, és a strukturált adatban, illetve a képek alt-szövegében is előkerülhet.
- Rövidítés: ha van bevett rövidítés, rögzítsd, és azt is, hogy első előfordulásnál ki kell írni teljesen. Ha nincs bevett rövidítés, azt is írd le, hogy nincs.
- A fogalom otthona: az az egy URL, ahová a fogalom tartozik. Minden más oldal, ami említi, ide linkel.
Ha akarsz még egy oszlopot, az legyen a tulajdonos: ki az az egy ember, aki dönt, ha vita van. Több oszlopra nincs szükség, és minden további mező azzal a kockázattal jár, hogy a dokumentum karbantartás nélkül elavul.
Hogyan néz ki ez egy konkrét magyar szolgáltatáson?
Rövid válasz: úgy, hogy a piacon valóban használt három-négy elnevezésből kiválasztod az egyet, a többit besorolod, és leírod, hol lakik a fogalom.
Vegyünk egy hétköznapi példát: a lakossági klímaszerelést. A piacon legalább négy elnevezés él egymás mellett, és a keresők tényleg mind a négyet beírják: klímatelepítés, klímaszerelés, klíma beszerelés, split klíma felszerelés. A szótársor így nézhet ki:
- Elsődleges megnevezés: klímatelepítés
- Elfogadott szinonimák: klímaszerelés, split klíma felszerelése
- Kerülendő alakok: „légkondi bekötés" (beszélt nyelvi, nem illik az ajánlatokba), „klímázás", valamint a puszta „klíma" a szolgáltatás megnevezéseként, mert az a készüléket is jelenti
- Angol megfelelő: air conditioner installation
- Rövidítés: nincs bevett rövidítés, ne is vezessetek be
- A fogalom otthona:
/klimatelepites/
Figyeld meg, hogy a „klíma karbantartás" és a „klímatisztítás" szándékosan nem szinonima itt: az másik szolgáltatás, másik vásárlói szándékkal, tehát külön szótársor és külön otthon illeti meg. A szótár egyik legnagyobb haszna éppen ez: kényszerít arra, hogy eldöntsd, mi számít külön szolgáltatásnak és mi csak másik névnek.
Miért ne csinálj külön oldalt vagy átirányítást minden névváltozatra?
Rövid válasz: mert a névváltozat nem külön téma. Az átirányítás egy már meglévő, felesleges oldal orvossága, nem terv arra, hogyan kezeld a szinonimákat.
Ha minden elnevezésre külön aloldalt gyártasz, négy majdnem egyforma szöveged lesz, amelyek egymás elől viszik el a figyelmet, és egyik sem elég alapos ahhoz, hogy egy AI-válasz forrása legyen. Ha pedig legyártod, majd 301-gyel mind a főoldalra irányítod, akkor csináltál egy kört, aminek a végén ott állsz, ahol a szinonimák egyetlen oldalon vannak. Kezdd rögtön ott. A helyes szerkezet egy oldalon belül így néz ki:
- A H1 és a title az elsődleges megnevezést tartalmazza, egyszer, tisztán.
- A nyitó bekezdésben egy természetes mondatban megjelenik a két legfontosabb szinonima, például: „A klímatelepítés (sokan klímaszerelésként keresik) nálunk a helyszíni felméréssel kezdődik."
- Az oldal közepén egy rövid, három-négy mondatos szakasz külön is kimondja: „Hogy hívják még ezt a szolgáltatást?" Itt sorolod fel a bevett neveket, és megmagyarázod, melyik mit takar valójában. Ez a szakasz önmagában is idézhető, ezért a válaszmotorok szeretik.
- A GYIK-ben egy kérdés kifejezetten a névhasználatra vonatkozik, mert a felhasználók pont így teszik fel.
- A strukturált adatban a szinonimák a szabvány szerinti helyükre kerülnek, nem a látható szövegbe zsúfolva.
A JSON-LD része ennyi, semmi bonyolult nincs benne:
{ "@context": "https://schema.org", "@type": "Service", "name": "Klímatelepítés", "alternateName": ["Klímaszerelés", "Split klíma felszerelése"], "areaServed": "Székesfehérvár", "provider": { "@type": "LocalBusiness", "name": "Példa Kft." } }
Ha Székesfehérváron vagy Budapesten dolgozol, a földrajzi megnevezésre ugyanez a fegyelem vonatkozik: egy alak, mindenhol. A „Fehérvár" és a „Székesfehérvár" váltogatása ugyanúgy hígít, mint a szolgáltatásnévé. Szakmai feltételezés: a strukturált adatban megadott alternatív nevek önmagukban nem hoznak találatot, de csökkentik annak esélyét, hogy egy gép rossz fogalomhoz kösse a cégedet. Ez a kockázatcsökkentés az érték, nem valamiféle helyezésígéret.
Honnan gyűjtsd össze a valós szóhasználatot?
Rövid válasz: ne a fejedből. A szótárba csak olyan alak kerüljön be, amit dokumentáltan használ vagy az ügyfél, vagy a kereső, vagy a szakma.
- Google Search Console lekérdezés-riport: a legolcsóbb valóságellenőrzés. Itt látod, milyen szavakkal találnak meg most.
- Belső keresés (GA4 vagy a webshop keresője): amit az oldaladon belül keresnek, az a legőszintébb szóhasználat.
- Beérkező levelek és ajánlatkérő űrlapok szabad szöveges mezői: ügyfélszavak, tisztán.
- Telefonos jegyzetek: kérd meg azt, aki felveszi a telefont, hogy két hétig írja fel, hogyan nevezik meg a hívók a szolgáltatást.
- Google Cégprofil kérdések és értékelések: a vélemények szövegében gyakran ott a laikus megnevezés.
- Szakmai vagy hatósági megnevezés: ha van jogszabályi vagy kamarai név, azt is rögzítsd, akkor is, ha nem az lesz az elsődleges.
- Amit az AI-asszisztensek maguktól használnak: kérdezd meg egy chatbottól magyarul, hogyan hívják ezt a szolgáltatást. Amit visszaad, az jelzés arról, milyen alakot tart bevettnek.
Ki hagyja jóvá, és hogyan kerül be a szövegírói briefbe?
Rövid válasz: egy ember dönt, nem bizottság, és a szótár releváns öt sora minden brief legelső blokkja lesz.
A jóváhagyó legyen az, aki a szolgáltatásért üzletileg felel: a cégvezető vagy a szakmai vezető. Nem a szövegíró, mert ő nem tudja eldönteni, hogy a „klíma beszerelés" és a „klímatelepítés" között van-e szakmai különbség, és nem is a marketinges egyedül, mert ő hajlamos a keresési adat felé húzni akkor is, amikor a szakmai pontosság fontosabb. A vita ilyenkor kezelhető: az elsődleges megnevezés legyen a szakmailag helyes alak, a legkeresettebb laikus alak pedig kerüljön az elfogadott szinonimák közé, és jelenjen meg a nyitó bekezdésben.
A bevezetés akkor él túl, ha nem kell külön megkeresni a dokumentumot. Vagyis: a szótár releváns sorai bemásolva ott vannak minden szövegírói brief tetején, a szerződött külsős szövegíró briefjében is; az új szolgáltatás indításának checklistjén szerepel a „szótársor megírva" pont; és negyedévente valaki végigfut rajta. Saját tapasztalat: a különálló, szép szótárdokumentumok fél éven belül elhalnak. Amelyik be van másolva a briefbe, az működik.
Milyen ellenőrzőlistával vezesd be az entitásszótárt?
- Írd össze a szolgáltatásaidat, és jelöld meg, melyikre használtok több nevet.
- Gyűjts valós szóhasználatot a fenti hét forrásból, legalább két hét adatából.
- Tölts ki fogalmanként hat mezőt, egyetlen oldalon, dátummal és verziószámmal.
- Jelöld ki fogalmanként a fogalom otthonát, és nézd meg, van-e ott ténylegesen elég tartalom.
- Vidd végig egy szolgáltatáson: H1, title, menüfelirat, nyitó bekezdés, névhasználati szakasz, GYIK, strukturált adat.
- Keress rá a CMS-ben a kerülendő alakokra, és javítsd őket a régi cikkekben is.
- Egyeztesd a külső felületeket: Google Cégprofil, közösségi oldalak, katalógusok, ajánlatsablonok.
- Másold be a szótársorokat a szövegírói brief sablonjába, és rögzítsd, ki a jóváhagyó.
- Három hónap múlva nézd meg a Search Console lekérdezéseit: megjelentek-e olyan alakok, amiket eddig nem kezeltél.
Miért ez a legolcsóbb entitásmunka, amit szinte senki nem csinál?
Rövid válasz: mert nem kell hozzá fejlesztő, nem kell hozzá tartalomgyártási költségvetés, és fél nap alatt megvan, mégis minden későbbi szöveg minőségére hat.
Az entitásépítés drága végén ott vannak a külső hivatkozások, a szakmai publikációk, a strukturált adat karbantartása. Ehhez képest a szóhasználat egységesítése egy táblázat és néhány óra döntés. Mégis ez marad ki, mert nincs mögötte látványos szám, és nem lehet vele mutatós riportot csinálni. Saját tapasztalat: amikor egy oldalon végigvezetjük a szótárt, a leggyakoribb reakció nem az, hogy „nőtt a forgalom", hanem hogy „végre értem, mit is árulunk". Ez elsőre puha eredmény, de a szövegírás, az ajánlatadás és az értékesítés mind ebből él, és a gépi olvasónak is pontosan ez hiányzik. Eredményt egyik sem garantál, de a bizonytalanság csökkentése ritkán árt.
Források és további olvasnivalók
- Google Search Central: Search Essentials, valamint a strukturált adatok általános útmutatója
- Google Search Console súgó: Teljesítmény-jelentés és a lekérdezések értelmezése
- Schema.org szótár:
Service,Organization,alternateName,sameAstulajdonságok - W3C: JSON-LD 1.1 ajánlás
- Wikidata és Wikipedia mint nyilvános entitás-hivatkozási pontok
- OpenAI dokumentáció: embeddings és retrieval alapfogalmak
- Anthropic dokumentáció: contextual retrieval leírása
- Google Cégprofil súgó: a vállalkozás nevére és kategóriáira vonatkozó irányelvek
- Az öt párhuzamos elnevezés nem gazdagítja a tartalmat, hanem öt gyenge jelzésre bontja az egyet.
- Egy entitásszótárban minden fogalomhoz hat mező tartozik, és pontosan egy oldal a fogalom otthona.
- A szinonimákat egyetlen oldalon belül kezeld (szövegben, egy rövid szakaszban, GYIK-ben és alternateName-ben), ne külön aloldalakon.
- A valós szóhasználatot ne találd ki: Search Console, ügyfélszolgálati levelek, telefonos jegyzetek és értékelések adják.
- Egy ember hagyja jóvá, és a szótár első öt sora minden szövegírói brief tetején ott van, különben nem marad életben.
Gyakori kérdések
Mekkora legyen egy entitásszótár?
Egy kinyomtatott oldalnál ne legyen hosszabb. Egy átlagos kkv-nál ez öt-tizenkét fogalmat jelent, fogalmanként hat mezővel. Ha harminc sorra duzzad, jó eséllyel olyasmit is beleírtatok, ami nem külön fogalom, csak másik név, vagy olyat, amit valójában senki nem használ.
Mi legyen, ha a szakmailag helyes név nem az, amit az emberek keresnek?
Az elsődleges megnevezés maradjon a szakmailag helyes alak, mert az kerül a címsorokba, az ajánlatokba és a strukturált adatba. A legkeresettebb laikus alak kerüljön az elfogadott szinonimák közé, és jelenjen meg a nyitó bekezdésben, illetve a névhasználatot magyarázó rövid szakaszban. Így mindkét olvasó, az ember és a gép is megtalálja a kapcsolatot.
Kell külön aloldalt csinálni minden szinonimára?
Nem. A névváltozat nem külön téma, és a majdnem egyforma aloldalak elviszik egymás elől a figyelmet. Egyetlen alapos oldal, benne a szinonimák természetes kezelésével, jellemzően jobb megoldás. Átirányítást akkor használj, ha a párhuzamos oldalak már léteznek, és össze akarod vonni őket.
Tényleg segít az alternateName az AI-válaszokban?
Hivatalosan annyi igazolt, hogy a Schema.org szabvány pontosan erre a célra tartalmazza ezt a tulajdonságot, és a keresők a strukturált adatot az egyértelműsítéshez használják. Hogy egy adott válaszmotor mennyit épít rá, kívülről nem mérhető, tehát ez szakmai feltételezés marad. Kockázata nincs, a kitöltése pár perc.
Milyen gyakran érdemes frissíteni?
Negyedévente elég átnézni, plusz mindig, amikor új szolgáltatás indul vagy a Search Console lekérdezései között felbukkan egy eddig nem kezelt névalak. A dokumentumon legyen dátum és verziószám, különben senki nem tudja, melyik változat érvényes.
Mi legyen a saját márkanevekkel és termékcsomagokkal?
Ugyanaz a hat mező vonatkozik rájuk, azzal a kiegészítéssel, hogy a márkanév mellé mindig oda kell írni a köznyelvi kategóriát is, legalább az első előfordulásnál. Ha egy csomagot csak a saját fantázianevén emlegetsz, a gépnek esélye sincs kitalálni, hogy az valójában milyen szolgáltatás.
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.