Az integráció egy hétvége. A felelősség egy negyedév.

Benkó János · 2026. augusztus 31.

„Kitettünk egy llms.txt-t, szóval az oldalunk AI-ready." Ezt a mondatot sokszor hallottam az elmúlt hónapokban, és értem is, honnan jön: olcsó, gyors, és van mögötte egy fájl, amit meg lehet mutatni a főnöknek. Körülbelül annyira igaz, mint hogy kitettük a cégtáblát, tehát működik az üzlet.

Öt szint van, nem egy. A múlt héten végigmentünk rajtuk a saját oldalainkon — tizenháromon —, úgyhogy ez nem elméleti összefoglaló. Az egyik szinten 100%-ot értünk el, egy másikat szándékosan üresen hagytunk, és menet közben kiderült, hogy amit a legnehezebbnek hittem, az a legkönnyebb.

Ahol a web most tart

A Cloudflare áprilisban adott ki egy ingyenes szkennert (isitagentready.com), ami öt kategóriában pontozza, mennyire használható egy oldal AI-ügynökök számára. Aztán lefuttatták a 200 000 leglátogatottabb domainen. Az eredmény:

robots.txt létezik                        78%   (de szinte mind keresőrobotra írva)
Content Signals (AI-preferenciák)          4%
Markdown-tárgyalás                       3,9%
MCP Server Card + API-katalógus     15 oldalnál kevesebb

Az utolsó sor a lényeg. Kétszázezer domain, és tizenöt alatt van azoknak a száma, amelyek gépi úton elmondják magukról, hogy mit tudnak. Ez nem lemaradás — ez egy nyitva felejtett ablak, és a magyar piacon szélesebbre, mint máshol.

Az öt szint, egy hasznosabb olvasatban

A hivatalos felosztást megtalálod a Cloudflare-nél, nem másolom ide. Ami többet ér: mindegyik kategória más szerepbe helyez téged. Máshol van a partner, más a kérdés, más a kockázat.

Discoverability        kiadó vagy       Megtalál egyáltalán?
Content Accessibility  kiadó vagy       Mennyibe kerül elolvasnia?
Bot Access Control     jogtulajdonos    Ki jöhet be, és mit vihet?
Protocol Discovery     szolgáltató      Tudsz-e CSINÁLNI valamit — és ki vagy?
Commerce               eladó            Ki fizet, kinek a nevében, mekkora kerettel?

Az ötödiket, a kereskedelmit, a szkenner bele sem számítja a pontszámba. Vagyis elérhetsz 100 pontot úgy, hogy közben egyetlen ügynök sem tud tőled megvenni semmit. Erről a szakadékról szól ez a bejegyzés.

1–2. szint: megtalálható és olcsón olvasható

Ez az a réteg, amit mindenki „AI-ready"-nek hív. robots.txt, sitemap, HTTP Link fejléc, llms.txt, és a legfontosabb: markdown-tárgyalás. Ha az ügynök Accept: text/markdown fejléccel kéri az oldalt, tiszta markdownt kap HTML helyett.

Ez nem kényelmi kérdés, hanem költségkérdés. A saját blogcikkünkön lemértük:

ugyanaz az oldal, kétféle kéréssel

Accept: text/html      → 89 621 bájt
Accept: text/markdown  → 17 134 bájt     (-81%)

Az ügynök nem bájtot fizet, hanem tokent, de a kettő nagyjából együtt mozog. Fordítsd le üzleti nyelvre: ha nálad drágán és lassan jut hozzá az információhoz, a versenytársadból fog idézni. Nem azért, mert az jobb, hanem mert olcsóbb elolvasni.

Egy dolgot érdemes tudni, mielőtt nekiállsz: ma még kevés ügynök küldi ezt a fejlécet. A Claude Code igen, más eszközök inkább a HTML-be tett <link rel="alternate" type="text/markdown"> mutatót követik. A Cloudflare épp ezért csinálja azt is, hogy minden dokumentációs oldala elérhető /index.md végződéssel — URL-alapú tartalékként. Vagyis a réteg megéri, de ne várj tőle azonnali forgalomváltozást.

Az új elem itt a DNS-AID: a felfedezés lecsúszik HTTP alá, a DNS-be. Nem talál ki új rekordtípust, hanem a meglévő SVCB, TLSA, DNSSEC és DNS-SD rétegre ül rá — a logika ugyanaz, mint az SPF/DKIM/DMARC esetében, ahol már megszoktuk, hogy a domainhez tartozó metaadat a DNS-ben él. Májusban indult (IETF-vázlat, Linux Foundation-projekt, Infoblox-szerzőkkel, Deutsche Telekom- és Amazon-közreműködéssel); a kezdeti támogatók közt ott a Cloudflare, a GoDaddy, az Equinix és az ISC.

Ez a réteg egy hétvége munka. Ha most kezdesz a témának, itt kezdd.

3. szint: ki jöhet be

Content-Signal a robots.txt-ben (a keresés, az AI-válasz és a modell-tréning külön kapcsolható), AI-bot szabályok, és a Web Bot Auth, amivel egy jóhiszemű bot aláírja a saját HTTP-kéréseit, te pedig ellenőrzöd az aláírást.

Egy dolgot érdemes tisztán látni: a robots.txt nem fal, hanem kérés. Aki nem akarja betartani, nem tartja be. A jogi háttér pedig épp most mozdult el, méghozzá abba az irányba, ami sokakat meg fog lepni: az Amazon tavaly novemberben perelte be a Perplexityt, mert annak Comet böngészője a felhasználó nevében vásárolt az Amazonon. Márciusban kapott is egy tiltó végzést. Augusztus 4-én viszont a Ninth Circuit egyhangúlag hatályon kívül helyezte: a bíróság szerint nem a Perplexity lépett be az Amazonra, hanem a felhasználó — az ügynök csak eszköz volt a kezében. Az ügy megy tovább, de az irány innentől más.

4. szint: itt kezd érdekes lenni

MCP Server Card, Agent Skills, WebMCP, API-katalógus, OAuth-felfedezés, auth.md, ARD. Ez az a szint, ahol az oldalad már nem szöveg, hanem szolgáltatás. Nem azt mondod az ügynöknek, hogy „olvass el", hanem azt, hogy „ezt tudom megcsinálni neked, így hívj".

Az ARD (Agentic Resource Discovery, június 17-én publikálva a Microsoft, a Google, a GitHub, a GoDaddy és a Hugging Face közreműködésével) egy nagyon konkrét problémára válasz. A mai modell az, hogy minden eszköz leírását betöltjük a modell kontextusablakába, hogy tudjon választani. Tíz eszközzel ez működik. Tízezerrel nem. Az ARD kiviszi a kiválasztást a modellből egy keresőszolgáltatásba: te publikálsz egy ai-catalog.json-t a saját domainedre, a registry-k indexelik, az ügynök pedig rákeres, hogy mi tud segíteni az adott feladatban. Lényegében SEO az ügynökök képességkeresőjében. Csak most még nincs ott senki.

Amiért ezt az egészet leírtam

Nézd meg még egyszer a negyedik szint listáját. Hét ellenőrzésből három az azonosításról szól — OAuth-felfedezés, OAuth Protected Resource, auth.md. Egy sem a fizetésről.

Az auth.md (a WorkOS nyílt protokollja, májusból) pontosan ezt a lyukat tömi be. A mai gyakorlat ugyanis az, hogy ha egy ügynöknek hozzáférést adsz, adsz neki egy nyers API-kulcsot. Az a kulcs hatókör nélküli, sessiononként auditálhatatlan és szelektíven visszavonhatatlan. Ha az ügynök elszáll, mindent visz.

Az auth.md folyamata ott kezdődik, hogy az ügynök beleszalad egy védett végpontba:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://pelda.hu/.well-known/oauth-protected-resource"

Ez sima RFC 9728. Az ügynök követi a mutatót, megtalálja az authorization servert, abban egy agent_auth blokkot, és ott derül ki, milyen folyamatok támogatottak, milyen jogosultságok kérhetők, hogyan kap hitelesítő adatot, és hogyan lehet azt visszavonni. A domain gyökerében pedig ott egy auth.md — sima markdown fájl, prózában —, ami elmagyarázza mindezt annak az ügynöknek is, amelyik nem ismeri a protokollt.

Két útja van. Az egyikben az ügynök szolgáltatója tanúsítja a felhasználó személyazonosságát. A másikban az ügynök kap egy kódot, a felhasználó belép a te oldaladon, és beírja — vagyis a jóváhagyás nálad történik, nem az ügynöknél. Ez a különbség fogja eldönteni, ki felel, ha baj van.

A gépi fizetés technikailag nevetségesen egyszerű

Itt buktam el a saját feltételezésemet. Azt hittem, az llms.txt és a gépi fizetés között óriási technikai szakadék van. Nincs. Az x402 és az MPP ugyanazon a négylépéses HTTP-folyamaton ül:

1. A kliens elkér egy erőforrást vagy meghív egy eszközt.
2. A szerver 402 Payment Required választ küld, benne géppel olvasható leírás: mennyit, mivel, hova.
3. A kliens fizet, és újrapróbálja a kérést a fizetési igazolással.
4. A szerver ellenőrzi, és visszaadja az erőforrást — plusz egy nyugtát.

Nincs regisztráció, nincs előre kiosztott API-kulcs, nincs kosár és nincs fizetési oldal. Az x402 (a Coinbase-től indult, ma az x402 Foundation gondozza) három HTTP-fejléccel dolgozik és on-chain stablecoin fizetést használ. Az MPP (Machine Payments Protocol, a Stripe és a Tempo közös protokollja) ugyanerre a 402-es válaszra ül rá, de nem csak kriptót támogat: kártyát is, Stripe-on keresztül, ráadásul visszafelé kompatibilis az x402-vel. Tud egyszeri, használatalapú és ismétlődő fizetést.

A 402-es státuszkód egyébként 1997 óta benne van a HTTP-ben. Huszonkilenc évig nem használta senki. Most kiderült, mire való.

Ha a technika ilyen egyszerű, akkor hol az a bizonyos óriási ugrás? Ott, hogy ez nem fejlesztési, hanem üzleti modell-döntés. Kell hozzá árazás olyan egységre, amit eddig nem árazott senki: egy oldalletöltés? egy API-hívás? egy megválaszolt kérdés? Kell hozzá számlázás, áfa, könyvelés. Kell hozzá ÁSZF, mert eddig emberrel szerződtél. És kell hozzá válasz arra, hogy ki a szerződő fél, amikor egy gép vásárol.

A négy kereskedelmi protokoll valójában két külön üzlet

Itt szokták összekeverni a dolgokat. Négy protokollt vesznek egy kalap alá — x402, MPP, UCP, ACP —, mintha egymás versenytársai lennének. Nem azok. Két különböző üzletről szólnak.

A) Terméket adsz el embernek, ügynökön keresztül

Ide tartozik az UCP (Universal Commerce Protocol — a Google és a Shopify jelentette be januárban az NRF-en, húsz-egynéhány partnerrel, Apache-licenc alatt) és az ACP (Agentic Commerce Protocol — OpenAI és Stripe). Klasszikus kiskereskedelem, csak a kattintó ember helyett egy ügynök rak kosárba: katalógus, kosár, fizetés, szállítás.

Egy figyelmeztetés hozzá, és ez a legjobb ellenszere az „azonnal integrálj mindent" típusú tanácsoknak: az OpenAI március 5-én visszavonta a ChatGPT-be épített Instant Checkoutot, mert nem hozott konverziót. Az ACP azóta inkább termékfelfedezési réteg — az ügynök megtalálja a terméket, a tranzakció viszont a kereskedő saját boltjában zárul.

Ehhez az ághoz webshop kell, készlet kell, forgalom kell. A magyar KKV-k döntő többségének ez ma nem aktuális.

B) Hozzáférést adsz el gépnek

Ide tartozik az x402 és az MPP — és erről itthon nem beszél senki, pedig ez az érdekes ág. Mert itt nem termék a termék, hanem a tartalmad vagy az API-d. Nem kell hozzá webshop, készlet és szállítás.

Van egy adatbázisod, egy kalkulátorod, egy szakmai tudástárad, egy árlistád, egy méretezési táblázatod? Eddig ez marketingköltség volt: kitetted ingyen, hogy jöjjön a Google-forgalom. Most eladható tétel — kérésenként, oldalanként, hívásonként.

Ha valaki szakmai tartalomból él Magyarországon, ez a következő két év legfontosabb technikai kérdése. Nem az, hogy melyik AI-kereső idézi. Hanem az, hogy fizet-e érte, amikor idézi.

Három józan ellenérv

Nem lenne tisztességes, ha csak a lelkes felét írnám meg.

1. A szabvány megléte nem egyenlő a használatával. Hiába szolgálod ki tökéletesen a markdownt, ha az ügynökök nagy része ma még el sem kéri.
2. A lista négy hónap alatt négy taggal nőtt (DNS-AID, auth.md, ARD, MPP). Amit ma integrálsz a felső rétegben, jövőre lehet, hogy nem az a szabvány lesz.
3. A robots.txt nem véd meg. Ha a terved az, hogy szabályozod, ki fér hozzá a tartalmadhoz, ez önmagában nem eszköz, csak jelzés.

Ebből viszont nem az következik, hogy várni kell. Az következik, hogy tudni kell, melyik réteg stabil, és melyik nem.

Mit csinálj, ha magyar KKV vagy?

Négy fokot használok az ügyfeleimnél: Láthatatlan → Olvasható → Ajánlható → Tranzaktálható.

• Most, olcsón, biztosan megtérül (Olvasható): robots.txt AI-szabályokkal, sitemap, Link fejléc, markdown-tárgyalás, llms.txt, Content Signals. Egy hétvége, és ez a réteg stabil — nem fog jövőre megváltozni. Ha ma egyetlen dolgot csinálsz, ezt csináld.
• Ha van szolgáltatásod vagy API-d (Ajánlható): MCP Server Card, Agent Skills index, API-katalógus, ARD. Emlékszel a számra? Kétszázezerből tizenöt alatt. Ez nem fejlesztési feladat, hanem pozicionálás.
• Ha szakmai tartalomból élsz (Tranzaktálható, B ág): x402 vagy MPP kapuzás — nem az egész oldalra, hanem a mély tartalomra, a kalkulátorra, az adatbázisra.
• Csak ha tényleg webshop vagy (Tranzaktálható, A ág): UCP vagy ACP. És akkor sem egyetlen protokollra fogadva.

Egy szabály, amit érdemes megjegyezni: ne fizetési protokollt integrálj, amíg egy ügynök el sem tudja olvasni az árlistádat. Meglepően sokan pont fordítva kezdenek neki, mert a fizetés hangzik izgalmasabban.

A web mindkét végén egyszerre épül újra

Van ebben egy szimmetria, ami nekem csak a végén állt össze. A DNS-AID lefelé feszíti a webet: a felfedezés lemegy HTTP alá, a DNS-be, az internet legrégebbi és legstabilabb rétegébe. Az MPP és az x402 felfelé feszíti: a fizetés felkerül a HTTP-be, egy 1997 óta üresen álló státuszkódba.

A web háromszor tanult meg beszélni. Először a böngészőhöz, aztán a keresőmotorhoz, most az ügynökhöz. Az első két alkalommal is az járt jól, aki nem a harmadik évben kapcsolt.

Aki most kitesz egy llms.txt-t, az nem téved. Csak a létra legalsó fokán áll, és azt hiszi, hogy fent van.

Benkó János · webaktivátor

16 éve értékesít, 2014 óta weboldalakat üzemeltet és hirdetéseket kezel. Ki az a Benkó János? →