- A leggyakoribb ok nem az AI-optimalizálás hiánya, hanem egy alap technikai vagy tartalmi feltétel bukása.
- Felülről lefelé haladj: ha a bot el sem éri az oldalt, a tartalom csiszolása semmit nem ér.
- A legtöbb AI-crawler a nyers HTML-t olvassa, ezért a csak JavaScripttel megjelenő szöveg gyakran láthatatlan marad.
- Kimondott, önmagában is idézhető állítás nélkül nincs miből válaszolni rólad.
- Ha minden technikai feltétel rendben van, a külső említések hiánya lesz a szűk keresztmetszet, és ez a leglassabban javuló lépcső.
A tipikus helyzet így néz ki: beírsz egy kérdést valamelyik AI-asszisztensbe, amire a te cégednek kellene a jó válasznak lennie, és a felsorolásban ott van fél megyényi versenytárs, csak te nem. Az első reakció majdnem mindig ugyanaz: „akkor kellene valami AI-optimalizálás”. Saját tapasztalat: az esetek túlnyomó részében nem ez hiányzik. Vagy egy alap technikai feltétel bukik (a bot el sem éri az oldalt, vagy nem tudja kiolvasni belőle a szöveget), vagy egy alap tartalmi feltétel (sehol nincs kimondva az az állítás, amit a kérdés kér). Az alábbi sorrend ezt bontja hat lépcsőre. Mindegyikhez leírom, hogyan ellenőrzöd, és mi a javítás.

Miért felülről lefelé kell keresni a hibát?
Mert a lépcsők egymásra épülnek, és a felsőbb lépcső bukása kioltja az alatta végzett minden munkát. Ha a szervered elutasítja a botot, hiába írsz kristálytiszta szakcikket. Ha a szöveg csak JavaScript lefutása után jelenik meg, hiába van benne pontos állítás. Ha nincs kimondott állítás, hiába tökéletes a strukturált adatod.
Tovább a témában: Eltűnt a cég a térképes találatokból · AEO - Válaszmotor-optimalizálás
Szakmai feltételezés: a válaszmotorok jelenleg három forrásból dolgoznak: saját crawlerrel épített indexből, klasszikus kereső találati listájából (grounding), és élő oldal-lekérésből, amikor a felhasználó kérdése ezt indokolja. Mindhárom út feltételezi, hogy az oldalad gép számára elérhető és olvasható. Ezért van az, hogy a hibakeresés első fele színtiszta technika, és csak a második fele szól tartalomról.
A gyakorlati haszon: átlagosan tíz-tizenöt perc alatt végig lehet menni az első három lépcsőn, és ez a tíz-tizenöt perc menti meg a hónapokat, amit egyébként fölöslegesen írt tartalomra költenél.
1. lépcső: elérik-e egyáltalán a botok az oldaladat?
Ha a szervered vagy a védelmi rétege elutasítja az AI-crawlereket, a többi lépcsőnek nincs értelme. Ez a leggyakoribb néma hiba, mert semmilyen felületen nem kapsz róla figyelmeztetést.
Hogyan ellenőrzöd
- Nézd meg a
robots.txttartalmát, és keresd benne ezeket:GPTBot,OAI-SearchBot,ChatGPT-User,ClaudeBot,PerplexityBot,Google-Extended,Googlebot,Bingbot. EgyUser-agent: *alattiDisallow: /mindet kizárja. - Kérd le az oldalt bot-fejléccel, és nézd a státuszkódot:
curl -A "GPTBot" -I https://pelda.hu/oldal. A200jó, a403és az503letiltás. - Vesd össze egy normál böngésző-fejléccel végzett lekéréssel. Ha böngészőként
200, botként403, akkor nem a szervered rossz, hanem valami szűr: CDN, WAF, bot-védelem, tűzfal-szabály, biztonsági bővítmény. - Nézd meg a szerver hozzáférési naplóját az elmúlt harminc napra, és számold meg, hány kérés jött ezektől a user agentektől. A nulla önmagában is válasz.
Mi a javítás
A letiltás feloldása üzleti döntés, nem technikai automatizmus, ezért érdemes tudatosan meghozni. Hivatalosan igazolt: a Google-Extended nem a Google Kereső indexelését szabályozza, hanem a generatív modellek felé történő felhasználást, tehát a letiltása nem véd meg az AI-válaszoktól a keresőben, viszont kizárhat más felületekről. Ha bot-védelmet használsz, a szűrőt user agent és IP-tartomány párosítás alapján állítsd, ne pusztán user agent szerint, mert az utóbbi hamisítható. A nagy szolgáltatók publikálják a crawlereik IP-tartományait.
2. lépcső: indexelt-e egyáltalán az oldal a klasszikus keresőben?
Ha a Google vagy a Bing nem tartja az oldaladat az indexében, akkor az arra épülő AI-felületek sem tudnak belőle idézni. Hivatalosan igazolt: a Google AI-összefoglalói a Kereső indexére épülnek, és ugyanazok az indexelési és robots-vezérlők vonatkoznak rájuk.
Hogyan ellenőrzöd
- Search Console URL-ellenőrzés az adott címre. Ez megmondja, indexelt-e, mikor járt ott a bot, és ha nem indexelt, mi az ok.
- Nézd meg az oldal fejlécében a
noindexmetacímkét és a HTTP-válaszX-Robots-Tagmezőjét. Ez utóbbit sokan kihagyják, pedig ugyanúgy kizár. - Ellenőrizd a
canonicalhivatkozást. Ha egy másik URL-re mutat, az adott oldal nem önálló találat. - Bing Webmaster Toolsban is nézd meg, mert a Bing indexe több AI-felület hátterében szerepet kap.
Mi a javítás
A tiltás feloldása után kérj újraindexelést, és ellenőrizd, hogy az oldal szerepel-e a sitemapban, illetve hogy vezet-e rá belső hivatkozás a saját oldaladról. Saját tapasztalat: az árva oldal (amire semmi nem mutat a saját site-on belül) meglepően gyakori a szolgáltatás-aloldalaknál, mert menübe nem fért be, és csak a sitemap tudott róla.
3. lépcső: kiolvasható-e a szöveged renderelés nélkül?
A tömör válasz: ha a szöveg csak JavaScript lefutása után jelenik meg, jó eséllyel nem jut el a modellhez. Szakmai feltételezés, saját méréssel megerősítve: a klasszikus keresőbot renderel, a legtöbb AI-crawler viszont a nyers HTML-t viszi el, és nem futtat JavaScriptet.
Hogyan ellenőrzöd
- Kérd le a nyers forrást és keresd benne a szöveget:
curl -s https://pelda.hu/oldal | grep -i "kulcskifejezes". Ha nincs találat, a szöveged nincs benne a HTML-ben. - Böngészőben kapcsold ki a JavaScriptet, és töltsd újra az oldalt. Ami eltűnik, az a bot számára is kétséges.
- Külön nézd meg a lapfülekbe, harmonikába, felugró ablakba, „tovább” gomb mögé rejtett tartalmat, illetve a beágyazott értékeléseket és a GYIK-blokkokat. Ezek gyakran külső szkriptből töltődnek.
Mi a javítás
A lényegi szöveg legyen benne a szerver által küldött HTML-ben. WordPress esetén ez általában a sablon és a lapszerkesztő beállítása: a harmonikába tett szöveg legyen a forrásban is ott, csak elrejtve, ne pedig utólag betöltve. Egyoldalas keretrendszernél szerveroldali renderelés vagy előre generált statikus változat a járható út. Ha külső szolgáltató szkriptje adja a tartalmat (értékelések, árlista, foglalási naptár), a legfontosabb tényeket írd le a saját HTML-edben is.
4. lépcső: van-e egyértelmű, kimondott állításod a témában?
Az idézhetőség feltétele, hogy legyen mit idézni. A modell nem következtet ki rólad olyat, ami sehol nincs kimondva a szövegedben.
Saját tapasztalat: a magyar szolgáltatói oldalak többsége hangulatot ír, nem állítást. „Több éves tapasztalattal, megbízható partnerként állunk ügyfeleink rendelkezésére” típusú mondatból nem lehet válaszolni arra, hogy „ki vállal hétvégi vízvezeték-javítást Budapesten”. Az utóbbi kérdés három konkrétumot kér: mit, mikor, hol.
Hogyan ellenőrzöd
- Írd le pontosan azt a kérdést, amire szerinted a te cégednek kellene válasznak lennie.
- Keresd meg a saját oldaladon azt az egy mondatot, ami erre önmagában, kontextus nélkül is válaszol.
- Ha nem találsz ilyet, megvan a hiba. Ha találsz, ellenőrizd, hogy szerepel-e benne a szolgáltatás neve, a földrajzi hely és a lényegi feltétel.
Mi a javítás
- Minden fontos kérdéshez legyen egy szakasz, aminek a címe maga a kérdés, és az első mondata a tömör válasz.
- A válasz álljon meg önmagában. Ne kezdődjön úgy, hogy „ahogy fentebb írtuk”, mert kiemelve értelmetlen lesz.
- Legyen benne ellenőrizhető konkrétum: időtartam, terület, feltétel, mennyiség, folyamatlépés. Számot csak akkor írj, ha tényleg igaz és fenn is tartod.
- A településneveket helyesen ragozd (Székesfehérváron, Budapesten, Pécsett), mert a helyhez kötött kérdéseknél ez az egyezés része.
5. lépcső: van-e a márkádhoz köthető entitásadat?
A tömör válasz: a motornak tudnia kell, hogy a „Kovács Kft.” nevű karaktersor egy konkrét cég, konkrét címmel és tevékenységgel. Ezt az azonosítást segíti a strukturált adat és az adatok egyezése a különböző felületeken.
Hogyan ellenőrzöd
- Nézd meg, van-e
OrganizationvagyLocalBusinesstípusú JSON-LD az oldaladon, bennename,url,address,telephoneéssameAsmezőkkel. - Futtasd le a Google Rich Results tesztjét és a Schema.org validátort. A hibás JSON-LD ugyanolyan, mintha nem lenne.
- Vesd össze a cégnevet, címet és telefonszámot a weboldalon, a cégprofilodban, a közösségi oldalakon és a szakmai katalógusokban. Az eltérő írásmód (Kft. és KFT, más utcanév-rövidítés) gyengíti az összekapcsolást.
Mi a javítás
Hivatalosan igazolt: a Schema.org sameAs mezője pontosan arra való, hogy a cégedet más felületeken lévő azonos profilokhoz kösd. Töltsd fel a hiteles profiljaid címével. Egységesítsd a névalakot mindenhol, egyetlen írásmódra. Az „Impresszum” és a „Kapcsolat” oldalon legyen teljes, olvasható formában a cégadat, ne képként.
Szakmai feltételezés: a gyakran emlegetett llms.txt fájlt jelenleg egyik nagy szolgáltató sem nyilvánította hivatalosan támogatott szabványnak. Készíteni nem árt, de számolni vele nem érdemes, és semmiképp nem helyettesíti a fenti négy lépcsőt.
6. lépcső: említenek-e mások?
Ha minden technikai és tartalmi feltétel teljesül, és a motor mégis a versenytársakat sorolja, akkor jellemzően a külső megerősítés hiányzik. A modellek jutalmazzák azt, amit több, egymástól független forrás állít ugyanarról a cégről.
Hogyan ellenőrzöd
- Keress rá a cégnévre idézőjelben, és nézd meg, hány olyan oldal beszél rólad, ami nem a tiéd és nem fizetett felület.
- Nézd meg, hogy a versenytársak melyik szakmai listákon, katalógusokban, sajtóanyagokban szerepelnek, ahol te nem.
- Nézd át a nyilvános értékeléseidet: mennyi van, mennyire frissek, és szerepel-e bennük szövegesen a szolgáltatás neve.
Mi a javítás
Szakmai katalógusok és kamarai listák pontos kitöltése, szakmai szervezeti tagságok megjelenítése, saját szakértői anyag, amire mások hivatkozni tudnak, illetve rendszeres, valós értékelés-gyűjtés. Saját tapasztalat: ez a leglassabban javuló lépcső, hónapokban mérhető, ezért is baj, ha valaki ezzel kezdi, miközben egy 403-as státuszkód áll a legelső lépcsőn. Eredményt egyik lépés sem garantál, de a sorrend betartása a ráfordítás megtérülését jelentősen javítja.
Tünet, valószínű ok, első lépés: mit nézz meg elsőként?
Ez az összesítő táblázat felsorolásként. Keresd meg a saját tünetedet, és onnan indulj.
- Tünet: semmilyen kérdésre, semmilyen motorban nem jössz elő, még a saját cégnévre sem. Valószínű ok: bot-letiltás vagy teljes indexelési hiba. Első lépés:
robots.txtéscurl -A "GPTBot" -Istátuszkód. - Tünet: a Google-ben rendben megtalálható vagy, de az AI-asszisztensekben soha. Valószínű ok: az AI-crawlerek külön tiltva vannak, vagy a szöveg csak rendereléssel jelenik meg. Első lépés: user agentenkénti státuszkód, majd nyers HTML ellenőrzése.
- Tünet: a főoldal előjön, az aloldalak soha. Valószínű ok: indexelési hiány, árva oldal, hibás canonical. Első lépés: Search Console URL-ellenőrzés az adott aloldalra.
- Tünet: a motor téged említ, de rossz adattal (régi cím, megszűnt szolgáltatás). Valószínű ok: elavult külső profilok és nem egyező entitásadat. Első lépés: cégadat egységesítése minden felületen, JSON-LD frissítése.
- Tünet: a cégnevedre tudja, ki vagy, de a szolgáltatás-kérdésre nem téged hoz. Valószínű ok: nincs kimondott állítás az adott szolgáltatásról. Első lépés: önmagában idézhető válaszmondat írása a témára.
- Tünet: minden technikai feltétel rendben, a versenytársak mégis megelőznek. Valószínű ok: kevés független külső említés. Első lépés: versenytársak említési forrásainak összeírása, a hiányzó listák pótlása.
- Tünet: korábban előjöttél, most már nem. Valószínű ok: URL-változás, oldal-átalakítás, új biztonsági bővítmény. Első lépés: a régi URL-ek átirányításának és a botok státuszkódjának ellenőrzése.
Mennyi idő után várható változás?
Őszinte válasz: lépcsőnként eltérő, és pontos határidőt senki nem tud ígérni. Saját tapasztalat: a bot-hozzáférés és az indexelési hibák javítása után hetekben mérhető a változás, a tartalmi átírásé szintén. Az entitásadat és a külső említések hatása lassabb, több hónapos folyamat. Fontos, hogy a mérés is legyen rendszeres: ugyanazt a kérdéskészletet tedd fel havonta, ugyanabban a formában, és írd le, mi jött ki. Egyetlen próbálkozásból nem lehet következtetni, mert ugyanaz a kérdés két futásra is más választ adhat.
Források és további olvasnivalók
- Google Search Central dokumentáció (robots.txt, indexelés, strukturált adatok, AI-funkciók a Keresőben)
- Google Search Console súgó (URL-ellenőrző eszköz, indexelési jelentések)
- Google Rich Results Test és a Schema Markup Validator
- OpenAI dokumentáció (GPTBot, OAI-SearchBot, ChatGPT-User, IP-tartományok)
- Anthropic dokumentáció (ClaudeBot és a crawler-hozzáférés)
- Perplexity fejlesztői dokumentáció (PerplexityBot)
- Microsoft Bing Webmaster Tools dokumentáció
- RFC 9309: Robots Exclusion Protocol
- Schema.org szótár (Organization, LocalBusiness, sameAs, FAQPage)
- W3C ajánlások (HTML, akadálymentesség, strukturált tartalom)
Gyakori kérdések
Honnan tudom biztosan, hogy nem az AI-optimalizálás hiányzik, hanem technikai a hiba?
Kérd le az oldalt bot-fejléccel, és nézd a státuszkódot, majd nézd meg a nyers HTML-ben, benne van-e a szöveged. Ha bármelyik bukik, technikai a hiba, és addig a tartalmi munka nem tud érvényesülni.
Ha feloldom a GPTBot tiltását, azonnal megjelenek az AI-válaszokban?
Nem. A feloldás csak a hozzáférést teszi lehetővé, utána a botnak újra kell járnia az oldalt, és a tartalomnak meg is kell felelnie a kérdésnek. Eredményt ez a lépés nem garantál, de nélküle a többi lépés hatástalan.
A JavaScripttel betöltött szöveget a Google sem látja?
A Google keresőbotja rendel, tehát általában látja, csak késleltetve. A legtöbb AI-crawlernél viszont a nyers HTML számít, ezért fordulhat elő, hogy a klasszikus keresőben megvagy, az asszisztensekben nem.
Elég, ha felteszem a strukturált adatot, és ettől említeni fognak?
Nem elég önmagában. A strukturált adat az azonosítást segíti, de nem pótolja a kimondott állítást a szövegben, sem a külső említéseket. Támogató elem, nem kiváltó.
Mennyi ideig kell figyelnem, mielőtt kimondom, hogy nem működik?
Havi rendszerességgel, ugyanazzal a kérdéskészlettel érdemes mérni, és legalább néhány hónapos idősort nézni. Egyetlen lekérdezés eredménye önmagában nem bizonyíték, mert ugyanaz a kérdés futásonként eltérő választ adhat.
Van értelme llms.txt fájlt készíteni?
Készíteni nem árt, de jelenleg egyik nagy szolgáltató sem nyilvánította hivatalosan támogatott szabványnak, ezért ez szakmai feltételezés marad. A hozzáférés, az indexelés és a kiolvasható szöveg sokkal többet számít.
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.