AX-readiness: hogyan legyen ellenőrizhető és feldolgozható a weboldalad?

Egy magyar vállalkozásnak az AI-keresés kapcsán először ugyanazt érdemes rendbe tennie, amire az ügyfeleinek is szükségük van: világos ajánlatot, aktuális feltételeket és ellenőrizhető állításokat. Egy technikai jelölés nem pótolja a hiányzó szolgáltatásleírást, és egy asszisztens válaszában megjelenő cégnév még nem jelent érdeklődőt.

Ebben a cikkben az AX-readiness az Agent Experience szempontú felkészültség saját munkafogalma: azt vizsgáljuk vele, mennyire hozzáférhető, egyértelmű és ellenőrizhető egy webhely nyilvános információja az automatizált feldolgozás számára. Nem iparági minősítés, nem tanúsítvány, és nem az AI-idézés kötelező feltétele. A fogalom nem jelenti azt sem, hogy egy ügynök jogosult rendelni vagy adatot módosítani a vállalkozás rendszerében.

Négy külön kérdés, négy külön bizonyíték

A technikai ajánlatokban gyakran összemosódik, hogy egy robot letölthet-e egy oldalt, és hogy egy válaszadó rendszer ténylegesen hivatkozik-e rá. A kettő között több önálló döntés történik.

Kérdés	Mit ellenőrizz?	Mit nem bizonyít?
Feltérképezhető az oldal?	Válaszkód, robothozzáférés, belső linkek	Hogy bekerült a kereső indexébe
Indexelt az oldal?	Az adott kereső indexelési visszajelzése	Hogy megjelenik egy konkrét keresésre
Helyes a strukturált adat?	Jelölés, látható tartalom és aktuális adatok egyezése	Hogy bővített találat vagy AI-hivatkozás készül
Hivatkozik rá egy AI-válasz?	Dátummal és kérdéssel rögzített megfigyelés	Hogy ebből kattintás vagy üzlet született

A Google AI Overviews és AI Mode funkcióihoz a Google nem ír elő különleges sémát vagy AI-szövegfájlt. A támogató hivatkozásként való megjelenéshez az oldalnak indexeltnek és keresési kivonat megjelenítésére jogosultnak kell lennie. A feltételek teljesítése sem garantál feltérképezést, indexelést vagy megjelenést. Ez a Google dokumentált működése; nem általánosítható automatikusan minden más szolgáltatóra. Forrás: Google Search Central: AI-funkciók és a webhely.

Először az üzleti információ legyen pontos

Válassz ki egy fontos szolgáltatásoldalt, és nézd meg úgy, mintha egy beszerző először találkozna a céggel. Kiderül-e, kinek szól az ajánlat, hol vehető igénybe, mit tartalmaz, és mi történik az ajánlatkérés után? Ha az ár csak egyedi felmérés után adható meg, ezt kell leírni, nem kitalált indulóárat közölni.

Egy szemléltető példa: egy ipari karbantartó vállalkozásnál a „teljes körű megoldások” állítás helyett felsorolható a vállalt géptípus, a kiszállási terület, a diagnosztika menete és az, milyen dokumentáció kell az ajánlathoz. Ez nem garantál AI-megjelenést, de konkrét információt ad az érdeklődőnek és az oldalt feldolgozó rendszernek.

Különösen gondosan kezeld a referenciákat és eredményeket. Egy bemutató felület nem ügyfélprojekt, egy tervezett funkció nem elérhető szolgáltatás. Teljesítményadat mellé mérési dátum, környezet és módszer szükséges. Ha csak becslésed van, nevezd becslésnek, és írd le a feltételezéseit. A forrás nélküli szám elhagyása jobb szerkesztői döntés, mint egy magabiztosan megfogalmazott találgatás.

Készíts belső tényjegyzéket a változó állításokról: ár, szolgáltatási terület, elérhetőség, termékállapot, felelős és utolsó ellenőrzés. Ebből dolgozzon az oldal szerkesztője. Így egy árváltozáskor nem marad eltérő összeg a GYIK-ben, a cikkben és az ajánlatkérő mellett.

Hozzáférés: a robots.txt nem biztonsági zár

A robots.txt a robotok feltérképezési viselkedésére ad utasításokat. Nem alkalmas bizalmas adatok védelmére, és egy blokkolt URL más hivatkozások alapján továbbra is bekerülhet a Google találatai közé. Indexelés tiltásához más eszköz, például feldolgozható noindex utasítás kell; bizalmas tartalomhoz valódi hozzáférés-szabályozás szükséges. Forrás: Google útmutató a robots.txt szerepéről és korlátairól.

A gyakorlati ellenőrzésben külön kezeld a nyilvános szolgáltatásoldalt, az ügyfélportált és az adminisztrációt. Az első elérhetőségét vizsgálni kell; az utóbbiakhoz nem szabad hozzáférést adni pusztán az AI-láthatóság érdekében. A bejelentkezéshez kötött árak, ügyféldokumentumok és személyes adatok ne kerüljenek nyilvános összefoglaló fájlba sem.

A fejlesztőtől egy konkrét URL vizsgálatát kérd: milyen választ kap a látogató, látható-e a fontos szöveg, elérhető-e az oldal a menüből, és nem állítja-e meg a védelmi rendszer a kívánt keresőrobotot. A robot neve önmagában nem megbízható azonosítás: a naplózott user-agent szöveg hamisítható. Az ismeretlen forgalom teljes felengedése ezért nem jó javítási módszer.

Szemantika és strukturált adat: pontosítás, nem varázsszer

A HTML elemeinek megválasztása a dokumentum szerkezetét és használhatóságát segíti. A fő tartalom, a navigáció, a címsorok és az űrlapmezők legyenek felismerhetők. A div elem jelenléte önmagában nem teszi értelmezhetetlenné a tartalmat; a valódi probléma az, ha a lényegi információ hiányzik, félreérthető vagy csak nehezen hozzáférhető állapotban jelenik meg.

A Google strukturált adatokhoz JSON-LD, Microdata és RDFa formátumot is támogat, a JSON-LD használatát ajánlja. Ebből nem következik, hogy ez az egyetlen, minden AI-rendszer által értett formátum. A jelölés a látható tartalmat írja le, nem helyettesíti azt. A technikai bevezetéshez a Google strukturáltadat-útmutatója ad külön megvalósítási kiindulópontot.

Vezetőként azt kérd számon, hogy az ár és készlet ugyanabból a hiteles adatforrásból származzon a felületen és a jelölésben. A nem létező telephely, kitalált értékelés vagy elavult szolgáltatás gépi formátumban is hibás állítás marad. Egy sikeres szintaktikai ellenőrzés ezt az üzleti hitelességet nem igazolja.

Mire való az llms.txt?

Az llms.txt nyilvános információk és hivatkozások áttekinthető összefoglalására szolgáló közösségi javaslat. A javaslat saját dokumentációja alapján opcionális, kísérleti elemként érdemes kezelni. Nem azonos a robots.txt szerepével, nem ad hozzáférési jogosultságot, és önmagában nem bizonyítja, hogy egy szolgáltató fel is használja.

Egy KKV-nál akkor van értelme kipróbálni, ha a fontos tartalmak már rendben vannak, és valaki vállalja a fájl karbantartását. Legyen benne hivatkozás a hiteles, aktuális oldalakra, de ne hozz létre benne párhuzamos, gyorsan elavuló árlistát. Ha nincs rá fenntartási kapacitás, a szolgáltatásoldal javítása előrébb való.

Így mérj anélkül, hogy eredményt képzelnél az adatokba

Az alábbi munkamenet javasolt kísérleti terv, nem mért eredmény és nem kötelező iparági módszer.

1. Válassz 10–15 valós beszerzési kérdést az értékesítési beszélgetésekből. Legyen köztük márkaneves és márkanév nélküli kérdés is.
2. Rögzíts induló állapotot: URL, indexelés, keresési kattintás, ismert hivatkozó forgalom és minősített érdeklődés. Írd mellé az adatforrást és az időszakot.
3. Kérdésenként jegyezd fel a vizsgált szolgáltatást, dátumot, nyelvet, választ és a ténylegesen hivatkozott URL-t. A puszta névemlítést külön oszlopban kezeld.
4. Változtatási naplóban rögzítsd, melyik oldalon mit javítottál. Ha egyszerre indult hirdetés vagy új ajánlat, az is kerüljön ide.
5. Előre kijelölt időszak után ismételd meg a megfigyelést. A változást mutasd be, de kontrollált vizsgálat nélkül ne állítsd, hogy kizárólag a módosítás okozta.

A megjelenés, kattintás, űrlapbeküldés és elfogadott ajánlat külön esemény. Az érdeklődő forrására rákérdező mező segíthet, de az önbevallás sem hibátlan. Kis mintánál közöld a darabszámot és a bizonytalanságot; néhány megfigyelésből ne készíts általános piaci következtetést.

Mit rendelj meg ténylegesen?

Egy ellenőrizhető megbízás konkrét URL-listát, hozzáférési hibajegyzéket, javított tartalmakat, strukturáltadat-ellenőrzést és mérési tervet tartalmazzon. Az átadás feltétele legyen bizonyíték és felelős, ne egy magyarázat nélküli „AX-ready” jelvény.

Hosszabb távon az a hasznos rendszer, amelyben egy ár vagy szolgáltatás változását minden érintett felületen követni lehet. A nyilvános tartalom karbantartása a vállalkozás feladata; az, hogy egy külső AI-szolgáltató mikor és milyen összefüggésben idézi, kívül marad az ellenőrzésén. Erre a határra érdemes építeni az elvárásokat és a szerződést is.