Ügynöki (agentic) böngészés: amikor nem ember nyitja meg az oldalad

Scheo · 2026-08-10 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Van a weboldaladnak egy látogatói köre, amelyik soha nem nézi meg a képeidet, nem görget végig a nyitóképen, és nem hatódik meg a szép animációtól. Az AI-ügynök megbízást kapott: hasonlítson össze három szolgáltatót, gyűjtse ki a nyitvatartást, töltsön ki egy ajánlatkérőt. Ha nem talál meg valamit három-négy lépésen belül, továbbmegy a következő oldalra. Ez a viselkedés más tervezési szempontokat kíván, mint amit a klasszikus keresőoptimalizálás megszokott.

Mit csinál pontosan egy AI-ügynök az oldaladon?

Rövid válasz: feladatot hajt végre. Nem későbbre gyűjt, hanem itt és most keres egy konkrét adatot vagy elvégez egy műveletet, majd visszaadja az eredményt annak, aki elindította.

Érdemes három, egymástól eltérő géptípust szétválasztani, mert máshogy is kell rájuk készülni.

• Tanító és indexelő robotok. Végigjárják az oldalt, elteszik a tartalmat későbbi felhasználásra. Ide tartozik a klasszikus keresőrobot és a nagy modellek adatgyűjtője.
• Válaszidőben lekérő botok. Amikor valaki kérdez a chatben, és a rendszer élőben behúz egy-két oldalt, hogy hivatkozhasson rá.
• Valódi ügynökök. Böngészőt vezérelnek, kattintanak, űrlapot töltenek, több oldalon át visznek végig egy feladatot.

Egy tipikus ügynöki menet így néz ki, amikor valaki azt kéri, hogy kérjen be három ajánlatot egy redőnyjavításra:

1. Keresés indul, az ügynök kiválaszt néhány találatot a szolgáltatók közül.
2. Megnyitja az első oldalt, és a nyers HTML-ben keresi a szolgáltatás nevét és az ellátott települést.
3. Ha megtalálta, megkeresi a kapcsolati útvonalat: menülink, gomb, telefonszám, űrlap.
4. Ha az űrlap mezői azonosíthatók, kitölti; ha nem, kimásolja az elérhetőséget, vagy egyszerűen továbblép a következő szolgáltatóra.

Hivatalosan igazolt: a nagy szolgáltatók külön dokumentálják ezeket a szerepeket. Az OpenAI eltérő azonosítót ad az adatgyűjtésnek, a keresőindexelésnek és a felhasználó kérésére induló élő lekérésnek. Az Anthropic hasonlóan elkülöníti a saját robotját a felhasználó által kezdeményezett lekéréstől. A Google külön vezérlőt kínál a generatív felhasználásra. Ezek a nevek megjelennek a szervernaplóban, tehát meg tudod nézni, van-e nálad ilyen forgalom.

Miben más egy ügynök, mint egy klasszikus keresőrobot?

Rövid válasz: a keresőrobot türelmes, az ügynök nem. A robot visszatér, újra próbálkozik, hetekig épít képet rólad. Az ügynök egyetlen munkamenetben dolgozik, korlátozott idővel és korlátozott figyelemmel.

Ennek három gyakorlati következménye van. Az első: a lassú oldal nem csak kényelmetlen, hanem kiesést jelent, mert az ügynök időkorláttal dolgozik. A második: a mély, sok kattintásos szerkezet hátrány, mert minden lépés esély a félresiklásra. A harmadik: a kétértelmű szöveg drágább, mint gondolnád. Egy ember kikövetkezteti, hogy a "Kérj visszahívást" gomb ajánlatkérés. Az ügynök inkább keres egy oldalt, ahol ez ki van írva.

Saját tapasztalat: amikor kkv-oldalakat vizsgálok abból a szempontból, mit tud belőlük kinyerni egy gép, a leggyakoribb elakadás nem a hiányzó tartalom, hanem a rosszul elhelyezett tartalom. A szolgáltatási területek egy térképes bővítményben vannak, a nyitvatartás egy képen, az árajánlat feltételei egy legördülő elemben, amely csak kattintás után tölt be. Az információ létezik, csak nem szövegként.

Miért baj, ha a tartalom kizárólag JavaScriptből épül fel?

Rövid válasz: mert sok gépi látogató a nyers HTML-t olvassa, és ami abban nincs benne, az számára nem létezik.

Hivatalosan igazolt: a Google dokumentálja, hogy a JavaScriptet külön renderelési szakaszban futtatja, tehát a feldolgozás nem egy lépésben történik. Szakmai feltételezés: az élő lekérést végző AI-botok és az egyszerűbb ügynökök jelentős része nem futtat teljes böngészőt, hanem a válasz HTML-jét dolgozza fel, mert ez sokkal olcsóbb és gyorsabb. Ezt kívülről nem lehet biztosan megállapítani, de a viselkedés ezt sugallja.

Vegyünk egy valós szerkezetű példát. Egy nyíregyházi klímaszerelő oldalán a szolgáltatások füles elrendezésben vannak: karbantartás, telepítés, javítás. A fülek tartalma csak kattintásra töltődik be a szerverről. Ember számára ez rendben van. Gép számára a szolgáltatásoldal gyakorlatilag üres: egy cím, három fülfelirat, egy telefonszám. Ha valaki azt kérdezi az asszisztensétől, hogy hol vállalnak klímakarbantartást Nyíregyházán, ez az oldal nem tud versenyezni azzal, amelyiken ugyanez sima szövegként ott van.

A javítás nem az, hogy kidobod a modern felületet. Az a helyes megoldás, hogy a lényegi szöveg benne van a kiszolgált HTML-ben, és a JavaScript csak elrejti vagy megjeleníti. Ellenőrizni így tudod:

curl -sL https://pelda.hu/szolgaltatasok/ | grep -i "klimakarbantartas"

Ha nincs találat, az ügynök sem látja. Ugyanezt megnézheted a böngésző fejlesztői eszközében is: kapcsold ki a JavaScriptet, és töltsd újra az oldalt. Ami eltűnik, az kockázat. Ugyanez vonatkozik a "Tovább olvasom" mögé rejtett szövegre és a görgetésre betöltődő listákra is: ha a megjelenítés feltétele egy felhasználói mozdulat, akkor a tartalom feltételes, és a gép számára ez általában nemleges választ jelent.

Hogyan navigál egy ügynök, és mit ront el a menüd?

Rövid válasz: az ügynök valódi hivatkozásokat követ, és a linkszövegből dönti el, érdemes-e odamennie.

A leggyakoribb navigációs hibák, amelyekbe kkv-oldalakon belefutok:

• A menü csak JavaScriptből épül fel, így a HTML-ben nincs egyetlen aloldalra mutató hivatkozás sem.
• A "link" valójában egy doboz, amelyhez kattintáskezelő tartozik. Nincs href, nincs mit követni.
• A linkszöveg mindenhol "Tovább" vagy "Részletek". Az ügynök nem tudja, melyik vezet a szolgáltatáshoz és melyik a blogbejegyzéshez.
• Kötelező felugró ablak (sütikezelő, korhatár, hírlevél) takarja a tartalmat, és a bezárása nem egyértelmű.
• Végtelen görgetés a listaoldalon, lapozás nélkül.

Amit ehelyett érdemes: beszédes linkszöveg ("Klímakarbantartás Nyíregyházán"), morzsamenü minden aloldalon, működő sitemap.xml, és egy tartalomjegyzék a hosszabb oldalak elején, valódi horgonylinkekkel. Saját tapasztalat: a beszédes linkszöveg az egyik legolcsóbb javítás, amit egy kkv-oldalon el lehet végezni, és emberi oldalról sem árt.

Mit kezd egy ügynök az űrlapoddal?

Rövid válasz: csak azt tudja kitölteni, amit be tud azonosítani. Ha a mezőnek nincs címkéje és neve, akkor számára az egy névtelen doboz.

Egy géppel is használható űrlap alapkövetelményei:

• Minden mezőhöz tartozzon látható label, amely a for attribútummal az azonosítóra mutat.
• Legyen name attribútum, beszédes értékkel (email, telefon, uzenet).
• Helyes mezőtípus: type=email, type=tel, type=date.
• Automatikus kitöltési súgó: autocomplete az ismert mezőkön.
• A kötelező mezők legyenek megjelölve required attribútummal, ne csak csillaggal a címke mellett.
• A hibaüzenet és a sikeres beküldés visszajelzése is szövegként jelenjen meg, ne csak színnel vagy ikonnal.

Egy helyes mező így néz ki:

<label for="email">E-mail cím</label> <input type="email" id="email" name="email" autocomplete="email" required>

Itt jön egy őszinte megjegyzés. Nem biztos, hogy azt akarod, hogy gépek töltsék ki az ajánlatkérődet. Egy székesfehérvári asztalosműhelynél teljesen jogos igény, hogy valódi ember írjon. Ilyenkor a jó irány nem a nehéz, képfelismerős ellenőrzés (az az embereket is elriasztja), hanem a rejtett csapdamező, a beküldési sebesség figyelése és a beérkező üzenetek forrásának naplózása. Szakmai feltételezés: a következő időszak inkább arról fog szólni, hogy tudatosan eldöntöd, mely folyamataidat nyitod meg gépi kitöltésre (időpontfoglalás, készletlekérdezés) és melyeket nem.

Hogyan fogalmazz, hogy az ügynök ne értsen félre?

Rövid válasz: írd ki a tényt teljes mondatban, egy helyen, kiegészítés nélkül értelmezhető formában.

A gép nem tud a szövegkörnyezetből visszakövetkeztetni úgy, ahogy egy ember. A "Hozzánk Fehérvárról 20 perc" mondat egy embernek elég, egy gépnek nem mond semmit arról, hogy hol vagy. Írd ki: "A műhelyünk Székesfehérváron, a Palotai úton található, és Veszprém megyében is vállalunk kiszállást." Ugyanez a különbség a "gyors kiszállás" és a "munkanapokon 48 órán belül kiszállunk" között.

Három egyszerű szabály, amit érdemes betartani a szolgáltatásoldalakon:

• Egy tény egy mondatban legyen teljes, ne két bekezdésre osztva.
• A településneveket írd ki helyesen ragozva (Debrecenben, Egerben, Dunaújvárosban), ne csak felsorolásként a láblécben.
• Kerüld a képre írt szöveget: a nyitvatartás, az elérhetőség és a szolgáltatáslista mindig legyen kimásolható.

Milyen adatszerkezet teszi géppel olvashatóvá a vállalkozásodat?

Rövid válasz: a strukturált adat és a szövegben is kiírt tény együtt. A jelölés segít az egyértelműsítésben, de a szöveg az, amit idézni tudnak.

Egy helyi szolgáltatónál a minimum: cégnév, cím, telefonszám, nyitvatartás, ellátott települések, szolgáltatások listája. Ezek jelölésére a Schema.org LocalBusiness, Service és FAQPage típusai valók. Egy egyszerű, JSON-LD formátumú részlet:

{"@context":"https://schema.org","@type":"LocalBusiness","name":"Peldaceg Kft.","telephone":"+3612345678","areaServed":["Székesfehérvár","Veszprém"],"openingHoursSpecification":[{"@type":"OpeningHoursSpecification","dayOfWeek":"Monday","opens":"08:00","closes":"16:00"}]}

Hivatalosan igazolt: a Schema.org szótára és a Google strukturált adatokra vonatkozó dokumentációja nyilvános, a jelölés helyessége teszteszközzel ellenőrizhető. Saját tapasztalat: a leggyakoribb hiba nem a hiányzó jelölés, hanem az ellentmondás: a jelölésben nyolc órás nyitás szerepel, a láblécben kilenc, a Google-profilban tíz. Egy gép ilyenkor nem tud dönteni, és jó eséllyel inkább nem állít semmit rólad. Az adategyezés unalmas munka, mégis ez hozza a legtöbbet.

Hogyan teszteld le fél óra alatt, mit lát az ügynök?

Rövid válasz: nézd meg az oldalt úgy, ahogy egy egyszerű letöltő látja, majd kérdezz rá a saját tartalmadra.

1. Töltsd le a három legfontosabb aloldalad forrását parancssorból, és keress rá a legfontosabb kifejezésekre. Ami nincs a válaszban, azzal foglalkozz először.
2. Kapcsold ki a JavaScriptet a böngésződben, és járd végig a főbb útvonalakat: nyitóoldal, szolgáltatás, kapcsolat.
3. Nézd meg, van-e minden aloldalra mutató valódi hivatkozás a menüben, forráskódban.
4. Ellenőrizd az űrlapod mezőit: van-e mindegyiknek címkéje, neve, típusa.
5. Nyisd meg a szervernaplót, és keress rá a botok nevére. Így látod, ki jár nálad valójában.
6. Kérdezz rá egy AI-asszisztensnél a saját szolgáltatásodra, és nézd meg, mit idéz vissza. Ha rosszul idéz, általában a forrás kétértelmű.

Ez a hat lépés nem garantál semmilyen megjelenést vagy helyezést, viszont megmutatja, hol vagy technikailag láthatatlan. A láthatatlanságot megszüntetni mindig olcsóbb, mint a versenytárs megelőzésével próbálkozni.

Mit engedj és mit tilts a robots.txt-ben?

Rövid válasz: az a tudatos döntés, ha külön kezeled a tanító célú gyűjtést és a felhasználó kérésére induló élő lekérést.

Sok cég azért tilt le mindent, mert egyben látja a botokat. Pedig más a tétje annak, ha egy modell tanul a szövegedből, és annak, ha valaki éppen most kérdez rólad, és a rendszer ezért nyitja meg az oldalad. Az utóbbi közvetlen üzleti érdek. Egy visszafogott beállítás:

User-agent: ChatGPT-User
Allow: /
User-agent: GPTBot
Disallow: /belso/

Hivatalosan igazolt: a robots.txt önkéntes megállapodás, betartása a szolgáltató jóindulatán múlik, és a nagy szereplők közzéteszik az azonosítóikat. Szakmai feltételezés: a bothullám szerverterhelése kis tárhelyeken érezhető lehet, ezért a szűrés helyett gyakran a sebességkorlátozás a jobb válasz.

Mikor éri meg ezzel foglalkozni egy kis cégnek?

Rövid válasz: akkor, ha a vevőid döntés előtt utánanéznek valaminek, és a válasz az oldaladon van. Ha a forgalmad kizárólag helyi ajánlásból jön, ez a téma ráér.

Kétféle helyzetben látom sürgősnek. Az egyik, amikor összehasonlítható szolgáltatást adsz (könyvelés, szerelés, oktatás), és a leendő ügyfél több céget mér össze, mielőtt telefonál. A másik, amikor sok az ismétlődő, tényszerű kérdés: nyitvatartás, ellátott terület, alkalmazott technológia, garanciális feltételek. Ezek pont azok az adatok, amelyeket egy ügynök ki tud olvasni és vissza tud adni.

A gyakorlati sorrend egy néhány fős cégnél: először a kapcsolat és a szolgáltatásoldalak legyenek gép számára is olvashatók, utána jöjjön a strukturált adat, és csak a végén a naplóelemzés. A fordított sorrend látványosabb, de kevesebbet ér. Saját tapasztalat: az első két lépés általában néhány óra fejlesztői munka, a harmadik viszont folyamatos figyelmet kíván.

Milyen ellenőrzőlistán menj végig a saját oldaladon?

Rövid válasz: ez a nyolc pont lefedi a gyakorlati kockázatok többségét egy magyar kkv-oldalon.

• A lényegi szöveg megjelenik a nyers HTML-ben, JavaScript futtatása nélkül is.
• A menü és a fontos hivatkozások valódi a href elemek, beszédes szöveggel.
• A nyitvatartás, a cím és a telefonszám szövegként szerepel, nem képen.
• Az ellátott települések ki vannak írva, helyes ragozással (Debrecenben, Egerben, Székesfehérváron).
• Az űrlapmezőknek van címkéje, neve és megfelelő típusa.
• A strukturált adat és az oldal szövege ugyanazt állítja.
• A sütikezelő nem takarja el tartósan a tartalmat.
• A szervernaplóban követed, milyen botok járnak nálad.

Ha ebből hatot teljesítesz, már jobb helyzetben vagy, mint a magyar kkv-oldalak nagy része. Ez nem varázslat és nem ígéret: a technikai hozzáférhetőség csak belépő, a tartalom minősége dönt utána.

Források és további olvasnivalók

• Google Search Central: JavaScript SEO alapok, strukturált adatok dokumentációja, robots.txt specifikáció
• Schema.org: LocalBusiness, Service, FAQPage és OpeningHoursSpecification típusleírások
• OpenAI dokumentáció: bot- és böngészőazonosítók, valamint kezelésük
• Anthropic dokumentáció: crawler és felhasználó által indított lekérés elkülönítése
• W3C: HTML űrlapok és WAI-ARIA szerzői útmutató
• MDN Web Docs: űrlapelemek, autocomplete attribútum