Ha és-jel van a cégnevedben, a Google augusztus óta mást olvashat ki belőle

Augusztus 25-én egy fejlesztő megkérdezte a Google Search Relations csapatának egyik mérnökét, hogy a JSON-ról néhány órával korábban leírt mondat a strukturált adatra is igaz-e. A válasz egyetlen szó volt: „yes”. Technikai apróságnak hangzik. Csakhogy pár nappal korábban ugyanez az elemző csendben megváltozott, és a változás pontosan azt a karaktert érinti, amely rengeteg magyar cégnévben ott van: az és-jelet.

Mit mondott ki pontosan a Google mérnöke?

Gary Illyes, a Google Search Relations csapatából, 2026. augusztus 25-én ezt írta a Blueskyn: a Google crawlerei nem elemzik a JSON-t, csak letöltik; az elemzést — a Keresés esetében — az indexelés végzi.

Ez a mondat önmagában nem újdonság, és nem is ettől érdekes. A hír az, ami utána történt. Néhány órával később valaki visszakérdezett: ugyanez igaz a JSON-LD-ben megírt sémákra is? A válasz egyetlen szó volt: „yes” — vagyis igen.

Kimondva tehát: az az adatréteg, amelyből az AI-összefoglaló és az AI-mód a cég nevét, nyitvatartását és kérdés-válaszait kiolvassa, nem kap külön elbánást. Ugyanaz a közös feldolgozó dolgozik rajta, mint a többi indexelt adaton.

Egy fenntartás az attribúcióhoz. A bejegyzések olyan Bluesky-fiókból származnak, amelynek megjelenített neve „Gary Illyes”, és a szakmai sajtó is ehhez a fiókhoz köti a nevét. Google-domainhez kötött, hitelesített kézjegyet viszont nem találtam rajta. A tartalom súlyát ez nem dönti el, de illik kimondani.

Ugyanebben a szálban arról is kérdezték, hogy a Merchant Center ugyanazt az elemzőt használja-e. A válasza az volt, hogy általában közös infrastruktúrán dolgoznak, és „nagyon biztos” benne, hogy igen — de azzal a csapattal soha nem dolgozott együtt. Ez tehát a saját feltételezése, nem megerősített tény. Így is kezeld.

Mi változott néhány nappal korábban a JSON-LD-feldolgozásban?

A Google Search Central hivatalos LinkedIn-fiókja közzétett egy rövid bejegyzést a JSON-LD kinyeréséről. A lényege: az elemzőt a JSON-szabványhoz igazították, és mostantól egyetlen menetben végez HTML-visszafejtést. Gyakorlatilag ez azt jelenti, hogy a kétszeresen kódolt entitások — a bejegyzés név szerint az és-jelet és a pipa karaktert hozza fel példaként — többé nem bomlanak ki. A zárómondat kérés: aki JSON-LD-t használ strukturált adathoz, írja át a kódját szabványos JSON-escape-ekre vagy Unicode-os hexadecimális escape-ekre.

Három dolgot érdemes tudni erről a bejegyzésről, mielőtt bárhova továbbadod.

Először: ez nem blogbejegyzés és nem dokumentációs frissítés, hanem egyetlen LinkedIn-poszt a Search Central fiókjából. A Google saját, dátumozott dokumentációs változásnaplójában e cikk írásakor egyetlen 2026. augusztusi bejegyzés szerepel, és az nem ez.

Másodszor: a pontos dátumát nem tudom megadni. A szakmai feldolgozások augusztus 21-re teszik, maga a poszt viszont augusztus 27-én még csak relatív időbélyeget mutatott („5 nappal ezelőtt”), ami augusztus 22-t adja ki. Egy nap bizonytalanság — inkább kimondom, mint hogy válasszak helyetted.

Harmadszor: ez nem magyar és nem EU-s ügy. A Google globális feldolgozó-infrastruktúrájának egy részletéről van szó, országot egyik forrás sem említ, és ilyen technikai rétegnél ez nem is várható.

Miért pont a magyar cégneveket érinti ez érzékenyen?

Mert az és-jel a magyar cégnévadás visszatérő eleme. A „Társa” és a „Fiai” típusú nevek, a két tulajdonosnevet összekötő márkanevek, valamint a Kft.-k és a Bt.-k egy része mind ezt a karaktert viseli. A HTML-ben pedig az és-jel különleges karakter: minden rendes rendszer kódolja. A baj ott kezdődik, ha a lánc két pontján is megteszi.

Egy tipikus út: a cégnév a szerkesztőfelületen már kódolva kerül az adatbázisba, majd a sablon a JSON-LD kiírásakor még egyszer végigfut rajta. Eddig ez nem tűnt fel, mert a Google mindkét kódolást visszafejtette. Mostantól csak az egyiket.

És pont a name mezőt találja el, vagyis azt az adatot, amelyből egy AI-asszisztens megnevezi a cégedet. Erről korábban részletesen írtam: ha az AI nem ismer, a cégneved dönt helyetted. Ugyanez a mező adja a NAP-konzisztencia első betűjét is: ha a weboldalad gépi adata más nevet mond, mint a Cégprofilod, az plusz ellentmondás egy amúgy is bizonytalan rendszerben.

Hogyan néz ki ez a gyakorlatban?

Vegyünk egy kitalált céget, a Kovács & Társa Kft.-t, és nézzük meg, mi történik a nevével a JSON-LD name mezőjében.

Az első két sor rendben van, és eddig is rendben volt. A harmadik a kétszeres kódolás esete: ezt eddig a Google helyretette, most már nem. A cég neve az utolsó cellában látható módon kerül be — betű szerint, a kódolással együtt.

A Google javaslata szerint így írd le helyesen:

"name": "Kovács & Társa Kft."            <- jó: maga a karakter
"name": "Kovács \u0026 Társa Kft."       <- jó: szabványos JSON-escape
"name": "Kovács &amp;amp; Társa Kft."    <- ez az, ami eltört

A JSON-ban az és-jelnek nincs szüksége HTML-kódolásra. Egy <script type="application/ld+json"> blokkban leírhatod magát a karaktert, vagy használhatod a JSON saját, Unicode-alapú escape-jét — a Google mindkettőt elfogadható megoldásként nevezi meg.

Miért nem szól semmi, ha elromlik?

Mert ezen a területen az utóbbi hónapokban éppen a magától érkező visszajelzés fogyott el.

A Google saját dokumentációja szerint a FAQPage gazdag találat 2026. május 7-től nem jelenik meg a Keresésben. A séma maga érvényes schema.org-típus marad, nem dob hibát, és a rangsorolásodnak sem árt, ha ott hagyod. Ez három és fél hónapos hír, nem mai — itt csak azért fontos, mert megmutat egy mintát. Amíg volt gazdag találat, a megjelenése vagy eltűnése önmagában jelezte, hogy a strukturált adatoddal történt valami. Ahol ez a felület megszűnt, ott ez a jelzés is megszűnt.

Tedd mellé, amit a mérnök mondott: a crawler nem elemzi a JSON-t, csak letölti. Vagyis abból, hogy az oldalad letöltése sikeres volt, semmi nem következik a JSON-LD tartalmának helyességére nézve. A kettő külön rendszerben, külön időben történik.

A FAQPage-ről egyébként korábban itt írtam részletesen, arról pedig, hogy melyik sémát mikor érdemes megadni, az Organization és a LocalBusiness összevetésében.

Hogyan ellenőrzöd tíz perc alatt?

Ehhez nem kell külön eszköz, csak a böngésződ.

Egy. Nyisd meg a saját kezdőlapodat, és kérd le a forráskódját (a legtöbb böngészőben Ctrl+U).

Kettő. Keress rá az application/ld+json szövegre. Ez a JSON-LD-blokkod.

Három. Ezen belül keress rá az amp;amp; karaktersorra. Ez a kétszeres kódolás ujjlenyomata. Ha megtalálod — jellemzően a cégnévben, a leírásban vagy egy kérdés-válasz szövegben —, akkor a rendszered kétszer kódol, és a Google ezt mostantól nem javítja ki helyetted.

Négy. Ugyanezt futtasd le egy terméklapon és a kapcsolati oldaladon is, mert a sablonok gyakran eltérnek. A webshopos sémákról külön írás szól: a visszaküldési és szállítási adatok a webshopod sémájában.

Öt. Ha van hiba, ne a kimenetet javítsd kézzel. Azt keresd meg, hol kódol kétszer a lánc: rendszerint egy sablonfüggvény vagy egy exportlépés az, amelyik egy már kódolt szövegre még egyszer ráfut.

Egy megjegyzés a kereséshez: az egyszeres & önmagában nem hiba, azt a Google egy menetben továbbra is visszafejti. A dupla az, ami elakad — ezért keress rá pontosan az amp;amp; sorozatra, ne csak az és-jelre.

Mit ne olvass ki ebből?

Négy korlátot érdemes kimondani.

Először: ebből nem következik, hogy a JSON-LD elvesztette az értékét. Éppen fordítva. Ha a strukturált adat nem kap külön védelmet a rendszer többi részéhez képest, akkor a pontossága a te dolgod, nem a Google-é.

Másodszor: nem minden oldal érintett. Ha a rendszered egyszer kódol, vagy egyszer sem, semmi dolgod. A hiba a kétszeres kódolásból jön, és sok tartalomkezelőben egyáltalán nem fordul elő.

Harmadszor: arról, hogy ez a változás bárhol mérhető láthatóságvesztést okozott volna, nincs adat. Nem láttam ilyet, és nem is állítom. Amit tudunk, az a mechanizmus, nem a hatás.

Negyedszer: a „nem a crawler elemzi a JSON-t” mondat önmagában régi ismeret. Az újdonság az, hogy a JSON-LD-re is kimondták — névvel, dátummal, egy konkrét kérdésre válaszolva.

Ez a fajta ellenőrzés amúgy a saját mérési módszertanom egyik technikai dimenziójában is szerepel: a gépi adat és a látható tartalom egyezése nem hitkérdés, hanem megnézhető. Tíz perc, és tudod.

Kindl Dávid · Közzétéve: 2026. augusztus 27.