Egy webáruház ma két, egymástól nagyon különböző látogatóra dolgozik. Az egyik ember: görget, nézi a képet, elolvassa a véleményeket, aztán dönt. A másik egy program: lehúzza az oldal forráskódját, kiszedi belőle az árat, a készletet és a szállítási feltételt, majd összeveti öt másik bolttal. A második csoport az elmúlt időszakban látványosan nőtt, és a következő lépcsőfok már nem az információgyűjtés, hanem maga a tranzakció: az AI-ügynök nem csak ajánl, hanem kosárba tesz, kitölti az adatokat és fizet.
Ez ma még nem tömegjelenség Magyarországon. Viszont az a felkészülés, amit igényel, majdnem teljes átfedésben van azzal, amit egy webshopnak a saját emberi vásárlóiért amúgy is meg kellene tennie. Ezért érdemes vele foglalkozni akkor is, ha holnap nem áll be a sorba száz robotvásárló.
Mit jelent az, hogy nem ember, hanem AI-ügynök vásárol?
Röviden: a felhasználó megbíz egy AI-asszisztenst egy feladattal ("rendelj nekem egy 60 centis, fehér gránit mosogatót, ami három napon belül itt van"), és az asszisztens helyette járja végig a boltokat, választ terméket, és lezárja a rendelést.
Technikailag két útvonal létezik, és ezt érdemes szétválasztani, mert eltérő a felkészülés:
- Böngésző-vezérlő ügynök. A modell egy valódi böngészőt irányít: kattint, gépel, görget. A webshopod bármilyen fejlesztés nélkül "használható", viszont minden emberi buktató (felugró ablak, cookie-sáv, captcha, lassan betöltő ár) útközben megállítja.
- Protokoll-alapú ügynök. A bolt gépi felületet ad: strukturált termékadatot, kosár- és fizetési végpontot. Itt nem kattintás történik, hanem adatcsere. Sokkal megbízhatóbb, cserébe tudatos fejlesztést kíván a bolt oldaláról.
Hivatalosan igazolt: a nagy modellszolgáltatók (OpenAI, Anthropic, Google) mind publikáltak számítógép-, illetve böngészővezérlő ügynök-képességet, és létezik nyílt szabvány az AI-eszközök és külső rendszerek összekötésére (Model Context Protocol). Szakmai feltételezés: a magyar webshopok döntő többsége a következő egy-két évben nem protokollon keresztül, hanem böngészővezérlő ügynökön át fog ezzel találkozni, egyszerűen azért, mert az nem kér tőlük semmit. Emiatt rövid távon az akadálymentesítés fontosabb, mint bármilyen új integráció megépítése.
Milyen technikai előfeltételek kellenek ahhoz, hogy egy ügynök végigmenjen a folyamaton?
Röviden: négy dolog kell. Géppel olvasható termékadat, egyértelmű készlet- és szállítási információ, stabil termékazonosító és kevés lépéses pénztár. Ha ebből bármelyik hiányzik, az ügynök vagy rossz döntést hoz, vagy félúton kiszáll a folyamatból.
Géppel olvasható termékadat
A minimum a strukturált adat a terméklapon, Schema.org Product típussal, JSON-LD formában. Ez az egyetlen pont, ahol a bolt félreérthetetlenül kimondja, mi az ár, milyen pénznemben, és van-e készleten:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Gránit mosogató 60 cm, fehér",
"sku": "MOS-60-FEH",
"gtin13": "5901234123457",
"offers": {
"@type": "Offer",
"price": "AKTUALIS_BRUTTO_AR",
"priceCurrency": "HUF",
"availability": "https://schema.org/InStock",
"url": "https://pelda.hu/granit-mosogato-60-feher"
}
}
Két gyakori hiba fordul elő. Az egyik, hogy az ár csak a látható HTML-ben szerepel, a strukturált adatban nem. A másik, hogy a strukturált adat elavult, mert sablonból jön, nem az adatbázisból. Saját tapasztalat: magyar webshopoknál az eltérő HTML-ár és JSON-LD-ár meglepően gyakori, főleg akciók idején, és ilyenkor a gép azt hiszi el, amit a strukturált adat állít.
Stabil termékazonosító
Ha ugyanaz a termék tegnap a /mosogato-60-feher címen volt, ma pedig a /konyha/mosogatok/mosogato-60-feher-uj címen, akkor gépi szemmel ez két külön termék, a korábban elmentett hivatkozás pedig halott. Kell tehát egy azonosító, ami nem változik: cikkszám (SKU), és ahol értelmezhető, GTIN vagy EAN. A variánsokat (méret, szín) érdemes saját azonosítóval és közvetlenül hivatkozható URL-lel kezelni, mert egy ügynök a legördülő menü kiválasztását nehezebben végzi el megbízhatóan, mint egy link megnyitását.
Egyértelmű készlet és szállítás
A "Kérjük, érdeklődjön!" vagy a "Rendelhető" típusú megfogalmazás gépi szempontból nulla információ. Bináris, dátumos állítás kell: készleten van vagy nincs, és ha van, mikorra ér oda. Ugyanez igaz a szállítási költségre. Ha az összeg csak a pénztár harmadik lépésében derül ki, akkor az ügynök az összehasonlításkor hiányos végösszeggel dolgozik, és jó eséllyel nem a te boltodat választja.
Kevés lépéses pénztár
Minden extra lépés egy újabb hely, ahol az automatizált folyamat elhasal. A vendégként való vásárlás lehetősége, az egyoldalas pénztár, a mezők helyes autocomplete attribútuma (például autocomplete="postal-code") és a beszédes, mező mellé kiírt hibaüzenetek együtt teszik kiszámíthatóvá a folyamatot. Szakmai feltételezés: a fizetési lépés marad a legnehezebb pont, mert ott nem csak technikai, hanem biztonsági és jogi kérdés is felmerül (erős ügyfél-hitelesítés, felelősség vitás rendelésnél).
Mi akadályozza ma leginkább ezt a folyamatot egy magyar webáruházban?
Röviden: nem a fizetés, hanem az odáig vezető út. A leggyakoribb megállító elemek a kötelező regisztráció, a captcha, a JavaScripttel utólag betöltött ár és az elrejtett szállítási költség.
- Kötelező regisztráció. Az ügynök nem tud e-mailes megerősítő linkre kattintani, és nem hozhat létre a nevedben fiókot. Vendégvásárlás nélkül a folyamat itt véget ér.
- Captcha és agresszív botvédelem. A védelem célja jogos, de a beállítás gyakran vak: nem különbözteti meg a kártékony scrapert a felhasználó megbízásából érkező asszisztenstől. Saját tapasztalat: több hazai boltnál a CDN-szintű szabály úgy tiltott ki hasznos forgalmat, hogy erről a tulajdonos nem is tudott, mert a webanalitikában ez a forgalom meg sem jelent.
- JavaScripttel betöltött ár. Ha a nyers HTML-ben nincs benne az ár, csak utólag, kliensoldalon íródik be, akkor az egyszerűbb feldolgozók nulla vagy hiányzó árat látnak. Egy webshopnál ez a legdrágább technikai hiba.
- Elrejtett szállítási költség. Ha a végösszeg csak belépés után vagy az utolsó lépésben derül ki, akkor gépi összehasonlításban a boltod adata hiányos marad.
- Végtelen görgetés a kategórialapon. Klasszikus, lapozható, saját URL-lel rendelkező oldalak nélkül a kínálat nagy része gépi szemmel láthatatlan.
- Felugró ablakok. A hírlevél-popup, a cookie-sáv és a kuponablak együtt három olyan réteg, amit el kell tüntetni ahhoz, hogy a gomb kattintható legyen.
Hogyan nézd át saját magad a webshopodat nyolc pontban?
Röviden: az alábbi nyolc lépéshez nem kell fejlesztő, egy böngésző és fél óra elég. Ahol elakadsz, ott akad el az ügynök is.
- Nézd meg a nyers HTML-t. Kapcsold ki a JavaScriptet a böngésződben, vagy futtasd le:
curl -s https://a-boltod.hu/termek | grep -i "Ft". Ha az ár nem jelenik meg, gépi szempontból nincs árad. - Ellenőrizd a strukturált adatot. Dobd be a terméklapot a Google Rich Results Test vagy a Schema.org Markup Validator felületére. Nézd, hogy a
Product, azOffer, azavailabilityés apriceCurrencymind ott van-e. - Vesd össze a két árat. A látható ár és a JSON-LD-ben szereplő ár ugyanaz? Akciós terméken is? Ha nem, az adatforrást kell javítani, nem a sablont.
- Nézz rá az azonosítókra. Van cikkszám minden variánson? Van GTIN vagy EAN ott, ahol gyári termékről van szó? Változott-e termék-URL az elmúlt évben átirányítás nélkül?
- Keresd meg a szállítási költséget. Hány kattintás, amíg egy konkrét termékhez tartozó pontos szállítási díj látszik? Ha több mint kettő, ez a legelső javítanivalód.
- Próbálj vendégként vásárolni. Menj végig a pénztáron kijelentkezve. Ha bárhol regisztrációt vagy e-mailes megerősítést kér, jegyezd fel.
- Nézd meg, mit enged a robots.txt és a botvédelem. Ellenőrizd, hogy nincs-e teljes tiltás olyan botokra, amelyeket valójában engedni akarnál, és kérd el a tárhely- vagy CDN-szolgáltatótól, hány kérést dob el a szabályrendszer.
- Számold meg a pénztár lépéseit és a kötelező mezőket. Minden mezőnél kérdezd meg: tényleg szükség van rá a teljesítéshez? Ami nem kell, azt vedd ki, a maradékra tegyél helyes
autocompleteértéket.
Mennyire sürgős ez, és mi az a minimum, ami akkor is megtérül?
Röviden: ma korai szakaszban vagyunk, ezért csak azt érdemes megcsinálni, ami az emberi vásárlóknál is javít. Egyedi ügynöki API-t építeni most nem indokolt.
A megtérülő minimum: pontos és naprakész strukturált termékadat, szerveroldalon is látható ár, kosár előtt kiszámolható szállítási költség, vendégvásárlás, stabil termék-URL-ek és tiszta hibaüzenetek a pénztárban. Ez a hat elem akkor is hasznos marad, ha az ügynöki vásárlás lassan terjed, mert mind a hat közvetlenül hat a Google termékmegjelenéseire, az ár-összehasonlító oldalakra, a saját keresődre és az emberi kosárelhagyásra.
Amibe most nem érdemes belevágni: külön ügynöki fizetési végpont saját fejlesztésben, vagy bármilyen "AI-kompatibilitási" tanúsítvány. Szakmai feltételezés: a fizetési rész szabványosítása a következő időszakban a kártyatársaságok, a bankok és a nagy platformok között dől el, és a webshopok ehhez a saját rendszerük frissítésén keresztül fognak hozzáférni. Ezt megelőzni drága, és nagy eséllyel felesleges munkát jelent.
Miért kockázatmentes befektetés ez, még ha az ügynöki vásárlás lassan is terjed?
Röviden: mert minden felsorolt lépés egyben konverzió-javítás emberi vásárlóknál is. Ez a saját nézőpontom, és a gyakorlati tapasztalatom is ezt támasztja alá.
Gondold végig, mit is javítottunk valójában. A kötelező regisztráció eltörlése és a váratlan szállítási költség kiírása régóta a leggyakrabban mért kosárelhagyási okok között szerepel a nemzetközi felhasználhatósági kutatásokban. A rövid, egyoldalas pénztár és a helyes űrlapmezők mobilon gyorsítanak. A pontos készletadat csökkenti a csalódást és a visszáru arányát. A stabil URL-ek megőrzik a linkerőt és a könyvjelzőket. A strukturált adat pedig a Google ingyenes termékmegjelenéseihez és a hirdetési feedhez is alapanyag.
Vagyis nincs olyan forgatókönyv, amelyben ez a munka kárba vész. Ha az ügynöki vásárlás gyorsan terjed, felkészülten érkezel. Ha lassan, akkor is jobb webshopod lesz, mint tavaly. Ez nem garantál sem több rendelést, sem jobb helyezést, de a ráfordítás úgy hasznosul, hogy közben nem kell megjósolnod a jövőt. Saját tapasztalat: a legtöbb hazai boltnál ezek a javítások nem hónapokig tartó fejlesztések, hanem sablonszintű módosítások és beállítás-átnézések, amiket a meglévő rendszerben (WooCommerce, Shoprenter, UNAS és társai) sok esetben a beépített funkciók bekapcsolásával is meg lehet oldani.
Egy záró gondolat a fontossági sorrendről: ha csak egyetlen dologra van kereted, kezdd az árral és a szállítási költséggel. Ez a két adat dönti el, hogy egy gépi összehasonlításban egyáltalán szerepelsz-e a listán. Minden más csak utána következik.
Források és további olvasnivalók
- Google Search Central: Structured data, Product markup dokumentáció
- Schema.org: Product, Offer és ShippingDetails típusdokumentáció
- Google Merchant Center Súgó: termékadat-specifikáció
- WHATWG HTML Standard: autofill és
autocompletemezőnevek - W3C Web Content Accessibility Guidelines (WCAG)
- OpenAI dokumentáció: számítógép- és böngészővezérlő ügynökök, bot-kezelési útmutató
- Anthropic dokumentáció: Model Context Protocol, computer use
- Model Context Protocol nyílt specifikáció
- Baymard Institute: kosárelhagyási és pénztár-felhasználhatósági kutatások
- Európai Bankhatóság: PSD2 erős ügyfél-hitelesítésre vonatkozó szabályozói technikai standard
- Az ügynök ma legtöbbször böngészőt vezérel, ezért minden emberi buktató (regisztrációs fal, captcha, lassú JavaScript) őt is megállítja.
- A strukturált termékadat nem SEO-kozmetika: ez az egyetlen hely, ahol félreérthetetlenül kimondod az árat, a készletet és a szállítási feltételt.
- Stabil cikkszám és állandó termék-URL nélkül az ügynök korábbi hivatkozásai értéktelenné válnak.
- Az elrejtett szállítási költség gépi összehasonlításnál ugyanúgy kiejt a versenyből, mint emberi kosárelhagyásnál.
- Ez még korai szakasz, ezért ma csak azt érdemes megcsinálni, ami az emberi vásárlóknál is javít: az ilyen lépés akkor sem veszik el, ha az ügynöki vásárlás lassan terjed.
Gyakori kérdések
Mit jelent pontosan az ügynöki vásárlás?
Azt, hogy a vásárló megbíz egy AI-asszisztenst egy feladattal, és az asszisztens helyette keresi meg a terméket, hasonlítja össze a boltokat, majd leadja a rendelést. A webshop szempontjából a látogató ilyenkor nem ember, hanem egy program, amely a felhasználó megbízásából jár el.
Kell-e külön API-t vagy integrációt építenem ehhez?
Ma még nem indokolt. A ma működő ügynökök többsége hagyományos böngészőt vezérel, tehát a te dolgod az akadályok eltávolítása és a strukturált termékadat rendbetétele, nem új felület fejlesztése. A fizetési rész szabványosítása még folyamatban van, ezt érdemes megvárni.
Blokkoljam vagy engedjem az AI-botokat a webshopomban?
Érdemes szétválasztani. A képzési célú lehúzást és a felhasználó megbízásából érkező, vásárlási szándékú ügynököt más kategóriaként kezeld, mert az utóbbi kizárása közvetlen bevételkiesést jelenthet. A szerverterhelést inkább kérésszám-korlátozással kezeld, ne teljes tiltással.
Elég-e, ha felteszem a Schema.org Product jelölést?
Önmagában nem. A jelölésnek naprakésznek és a látható tartalommal egyezőnek kell lennie, különben rosszabb a helyzet, mintha nem lenne. Emellett kell mellé stabil azonosító, egyértelmű készletállapot és kiszámolható szállítási költség is.
Nem lesz-e biztonsági kockázat, ha kikapcsolom a captchát?
Nem azt javaslom, hogy kapcsold ki, hanem hogy nézd meg, hol van rá tényleg szükség. A pénztárban vagy a terméklapon többnyire felesleges, a regisztrációnál és a kapcsolatfelvételi űrlapnál viszont indokolt lehet. A cél a célzott védelem, nem az összes automatizált látogató kizárása.
Mennyi idő alatt lehet mindezt átnézni egy kisebb webáruházban?
A cikkben szereplő nyolc pontos ellenőrzés önállóan is elvégezhető, jellemzően egy ülésben. A javítások nagyobb része sablonmódosítás és beállítás, nem hetekig tartó fejlesztés, bár a pénztár egyszerűsítése rendszerfüggően nagyobb munka lehet.
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.