NAP-konzisztencia: név, cím, telefon egy szervezetben

Az AI-modellek minden vállalkozásnál egy alapkérdésre keresnek választ: „Ez egy cég, vagy öt különböző névváltozat alatt futó két különböző entitás?” A NAP-konzisztencia — vagyis hogy a weboldal, a Google Business Profile, a Wikidata és az összes katalógus pontosan ugyanazt a nevet, címet és telefonszámot mutassa — erre az alapkérdésre ad választ. Ha az adatok szétfutnak, a modell elbizonytalanodik, és inkább kihagyja a céget, mint hogy összekeverje egy másikkal. Megmutatom, hogyan azonosíthatod és javíthatod a leggyakoribb eltéréseket.

Miért fontos a NAP az AI-modellek számára?

A név, cím és telefonszám (angolul: Name, Address, Phone — ezért NAP) nem csupán elérhetőségi adat. Az AI-modellek ezek alapján döntik el, hogy egy adott online bejegyzés ugyanahhoz a fizikai vagy jogi személyhez tartozik-e, mint egy másik bejegyzés. Ha a honlapon „Példa Kereskedelmi Kft.” szerepel, a Google Business Profile-on „Példa KFT.” áll, egy katalógusban pedig „Példa Kft. és Társa” név jelenik meg, a modell nem egy entitást lát, hanem bizonytalanságot. A bizonytalanság következménye egyszerű: kihagyás.

Ez különösen fájó a lokális vállalkozásoknál. A fogászati rendelők AI-láthatóságát vizsgáló mérésemben az egyik leggyakoribb hiányosság az volt, hogy a Google Business Profile-on szereplő telefonszám és a honlap fejlécében megjelenő szám nem egyezett. A modell ilyenkor nem tudta eldönteni, melyik a hiteles kapcsolattartási pont, és inkább más rendelőt ajánlott. Ez nem rosszindulat, hanem a bizonytalanság kerülése — az AI nem akar tévedni, ezért ahol kétség merül fel, visszalép.

A hét dimenziós mérési rendszerben az entitás és a NAP-konzisztencia önálló dimenziót (D4) alkot, 15%-os súllyal. Ez azt jelenti, hogy ha egy oldalon minden más dimenzió rendben van, de a NAP-adatok szétfutnak, az a pontszámon azonnal érződik — és ami fontosabb, az AI-válaszokban is.

Melyik névváltozat a hiteles: a jogi név vagy a márkanév?

A legtöbb vállalkozásnál kettő fut párhuzamosan: a jogi név (ami a cégjegyzékben szerepel) és a márkanév (amit a vásárlók ténylegesen használnak). Az AI-modellek mindkettőt kezelni tudják, de csak akkor, ha az Organization séma mindkét változatot megnevezi, és összeköti őket egymással.

A Schema.org Organization típus erre pontosan két mezőt kínál:

• name — a vásárlók felé kommunikált márkanév (pl. „Virágbolt a Körúton”)
• legalName — a teljes jogi név (pl. „Virágbolt a Körúton Kft.”)

Ha a két mező ki van töltve és konzisztens, a modell tudja, hogy a kettő azonos entitás. Ha csak az egyik szerepel — vagy ami még rosszabb, a kettő ellentmond egymásnak —, a modell nem tud biztos döntést hozni. A AI-láthatóság mérésének részleteinél is hangsúlyozom: az AI nem találgat, ha kétség merül fel. Inkább átugorja a céget.

A márkanév és a jogi név egységesítése hat felületen a legfontosabb:

1. A honlap fejléce és impresszuma
2. Az Organization JSON-LD séma (name és legalName mezők)
3. A Google Business Profile cégnévmezője
4. A Wikidata-bejegyzés (label mező, ha van)
5. A fontosabb iparági katalógusok (pl. Arany Oldalak, BISNODE, szakmai kamarai listák)
6. A közösségi profilok leírásai (LinkedIn, Facebook oldal neve)

Az egységesítés nem jelenti azt, hogy mindenhol betűre pontosan egyező szövegnek kell állnia — a modell tolerálja az apróbb formai különbségeket (nagybetű, rövidítés). Amit nem tolerál: az eltérő tartalmat. Ha az egyik helyen Bt., a másikon Kft. szerepel, az nem formai, hanem tartalmi eltérés — és az AI számára azt jelzi, hogy két különböző jogi személy áll a háttérben.

Mit kell tenni, ha az adatok szétfutottak?

Az adateltérések általában nem egyszerre keletkeznek. Évek alatt gyűlnek fel: egy telefonszámcsere, amelyet a honlapon frissítettél, de a GBP-n elfelejtettél; egy cégforma-változtatás, amelyet a katalógusokban nem vezettél át; egy időközben elavult cím, amelyet az ügyfelek mégis linkekből találnak meg. Az eredmény: hat-nyolc különböző felületen hat-nyolc különböző adatsor, amelyeket az AI nem tud biztonsággal egy entitáshoz rendelni.

A javítás négy lépése:

1. Audit — térképezd fel az összes előfordulást. Keress rá a cégnév összes főbb változatára (jogi név, márkanév, korábbi nevek) a Google-on, majd ellenőrizd a főbb katalógusokat és az összes aktív social profilt. Jegyezd fel, melyik felületen mi szerepel.

2. Határozz meg egy kanonikus adatsort. Ez a „master record”: a pontos névalak, a teljes postai cím (irányítószám, helység, utca, házszám magyaros sorrendben) és az egyetlen elsődleges telefonszám. Ha több telephelyed van, mindegyikhez külön kanonikus sor kell.

3. Frissítsd felülről lefelé. Először a honlap sémáját és impresszumát, utána a Google Business Profile-t, végül a többi katalógust. Nem érdemes fordítva csinálni: a GBP-frissítés gyors, de ha a séma rossz, a modell az oldal adatát veszi irányadónak — és ott még a régi szám állhat.

4. Ellenőrizd a sémát validátorral. A Google Strukturált adatok tesztelő eszközével (search.google.com/test/rich-results) ellenőrizd, hogy az Organization séma name, address (PostalAddress típussal) és telephone mezői hibátlanul értelmezhetők-e. Egy szintaktikai hiba is elég ahhoz, hogy a séma érvénytelen legyen — az AI pedig ilyenkor inkább a „nyers” szöveget olvassa, nem a strukturált adatot.

Az utcacím formázásánál a leggyakoribb hiba a nem egységes rövidítés: „Fő u. 1.”, „Fő utca 1”, „fő utca 1.” — a modell ezeket akár különböző helyszínekként is kezelheti. Válassz egyet, és azt írd mindenhol. A magyaros sorrend (irányítószám, helység, utca, házszám) a Schema.org PostalAddress típusban külön mezőkkel adható meg, ami sokkal megbízhatóbb, mint a teljes címet a streetAddress szabad szöveges mezőbe zsúfolni.

Hogyan kapcsolódik a NAP a többi AI-láthatósági elemhez?

A NAP-konzisztencia nem önmagában áll. A hagyományos SEO-tól eltérő AI-láthatósági megközelítésben a NAP az entitásréteg alapköve: nélküle az összes többi struktúra bizonytalan talajon áll. A Google Business Profile-adatok konzisztenciája például közvetlenül hat arra, hogy a modell lokális kérdéseknél egyértelműen azonosítani tudja-e a céget. A „megtalál az AI, de téged választ-e?” dilemmájában a NAP-eltérés már az első szűrőn kiesést okoz: ha a modell nem biztos benne, hogy a cég egyáltalán azonos-e azzal, amit a katalógusban lát, a kiválasztási kérdésig el sem jut.

A sameAs hivatkozások — amelyeket az Organization sémában a cég Wikidata-bejegyzésére, LinkedIn-profiljára vagy GBP-URL-jére mutató linkként érdemes feltüntetni — tovább erősítik az entitásazonosítást. Ezek azt mondják a modellnek: „ez az oldal és ezek a külső profilok ugyanazt a szervezetet képviselik.” A sameAs nélkül a modell minden egyes forrást külön értékel, és ha az adatok nem teljesen egyeznek, inkább az egymástól független entitások hipotézisét állítja fel.

Egy NAP-konzisztens, sémával ellátott oldal nem garantálja az AI-ajánlást — erre fontos figyelmeztetni. A mérés azt mutatja meg, hogy megvan-e az az alap, amelyből az ajánlás táplálkozhat. Hogy a modell ténylegesen megnevezi-e a céget, azt élesben, lekérdezéssel kell ellenőrizni, ahogyan azt az ingyenes AI-láthatósági teszt leírásában részletezem. A NAP-konzisztencia belépőfeltétel — szükséges, de önmagában nem elégséges.

A NAP-konzisztenciát azért is érdemes rendszeresen ellenőrizni, mert az adatok maguktól is „romlanak”: a katalógusok automatikusan gyűjtenek be adatokat más forrásokból, és egy félresikerült automatikus frissítés hónapok alatt szétírhatja a gondosan összehangolt adatsort. Érdemes negyedévente lefuttatni az audit első lépését — az összes előfordulás feltérképezését —, és a nagyobb változásokat (telefonszámcsere, cím-, névváltoztatás) azonnal minden kulcsfelületen átvezetni.

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