Hogyan készítsd fel saját üzemeltetésű webhelyedet az MI-ügynökökre

Egy Hacker News-szálban, amely az MI-robotok forgalmáról szólt, egy tárhely-adminisztrátor üzemeltetői oldalról írta le a terhelést: „nagyjából 6 különböző, elég agresszív MI-bot”, amelyek időről időre beragadnak a termékváltozat- vagy kategórialapokon, és nagyjából másodpercenként egy kéréssel kezdik ostromolni őket, egy olyan oldalon, ahol „egy-egy oldalbetöltés akár teljes 1 másodperces körutat is igényelhet (ennek nagy része MySQL-ben telik el)”. Az összesített hatás, ugyanabban a hozzászólásban: „majdnem olyan, mintha a webhelyet minden egyes nap slashdottolnák”.

A webhely felkészítése az MI-ügynökökre mindenekelőtt kapacitáskérdés, ezért a munka nagy része szerverkonfiguráció, és csak nagyon kis része tartalomstratégia. Ennek a forgalomnak az a hasznos tulajdonsága, hogy nagyrészt nem névtelen: az azt előállító cégek közzéteszik robotjaik nevét, dokumentálják, melyik mire való, és megmondják, hogyan lehet őket kikapcsolni. A következőkben az szerepel, mit kell beállítani, mit kényszerít ki az egyes mechanizmusok a gyakorlatban, és melyik két lépést hagynám ki: az llms.txt közzétételét és a schema-jelölés hozzáadását az MI kedvéért.

Röviden

• Az MI-forgalom jellemzően három részre oszlik: tanítás, MI-keresési indexelés és felhasználó által kiváltott lekérések. Az OpenAI és az Anthropic külön tokeneket tesz közzé ezekre a célokra, így egymástól függetlenül szabályozhatók; egyes többcélú robotok viszont több szerepet fognak össze egyetlen azonosító alatt.
• Az OpenAI, az Anthropic, a Perplexity és a Common Crawl dokumentálja az automatikus robotjaik robots.txt-vezérlését. A kivételt a felhasználó által kiváltott lekérők jelentik: az Anthropic a Claude-Userre is alkalmazza a robots.txt-t, az OpenAI szerint a szabályok nem feltétlenül vonatkoznak a ChatGPT-Userre, a Perplexity-User pedig általában figyelmen kívül hagyja őket.
• A robots.txt fájl beleegyezési mechanizmus, nem hozzáférés-vezérlés. Az RFC 9309 nem ad neki saját kikényszerítő erőt; a szabálykövető botok csökkenthetik a terhelésedet azzal, hogy betartják, de a fájl nem tudja visszafogni vagy megállítani a szabályt nem követő forgalmat.
• Az Ahrefs analitikai ügyfélkörébe tartozó 137 210 domain között a közzétett llms.txt fájlok 97 %-a egyetlen kérést sem kapott 2026 májusában. Tedd közzé, ha kedved tartja, de ne építs köré eszközrendszert.
• Tartsd meg a strukturált adatokat ott, ahol a klasszikus Keresés funkcióit támogatják, a Google dokumentációja szerint azonban az MI-funkcióihoz nem kell sem külön séma, sem MI-célú szövegfájl.
• A kritikus tartalmat szerveroldalon rendereld, ha azt szeretnéd, hogy az OpenAI, a ClaudeBot, a PerplexityBot vagy a CCBot elolvassa. A Vercel mérése szerint ezek a robotok nem futtatnak JavaScriptet; a Googleboton keresztüli Gemini és az AppleBot kivétel.
• A robots.txt együttműködésen alapuló szabályain túli kikényszerítés a fordított proxynál, egy általad üzemeltetett WAF-ban, vagy egy proof-of-work kihívás mögött lakik, költség szerint ebben a sorrendben.

Amit ez a cikk nem tárgyal

Itt olyan webhelyről van szó, amelyet ügynökök látogatnak, nem olyanról, amely tranzakciókat bonyolít velük. Négy szomszédos témát érintetlenül hagyunk.

• Az ügynöki kereskedelem és a fizetési folyamatok: más típusú webhely más problémája.
• A tanítóadatok körüli jogi és szerzői jogi vita, ami üzleti döntés, nem szerverbeállítás.
• WebMCP-implementációs útmutató, mivel a szabvány még mindig csak origin trial.
• CDN-specifikus beállítások az alábbi egyetlen Cloudflare-szakaszon túl.

Mely MI-robotok ostromolják a webhelyedet

A GPTBot és a ClaudeBot olyan tartalmat gyűjt, amelyet modelltanításra használhatnak. Az OAI-SearchBot és a Claude-SearchBot az MI-alapú keresést és visszakeresést szolgálja. A ChatGPT-User és a Claude-User felhasználói műveletekre válaszul tölt le oldalakat. Egyes szolgáltatóknál ezek a feladatok külön vannak választva, de a weben nem minden robot feleltethető meg tisztán egyetlen célnak.

A szabálykövetés képe pontosabb, mint amit a szokásos rövidítés sugall. az Anthropic robotdokumentációja szerint a ClaudeBot, a Claude-User és a Claude-SearchBot tiszteletben tartja a robots.txt-t. az OpenAI botdokumentációja szerint az automatikus robotjai önálló vezérlőket használnak, a robots.txt szabályai azonban nem feltétlenül vonatkoznak a ChatGPT-Userre, mert azokat a kéréseket ember indítja. a Perplexity robotdokumentációja hasonló különbséget tesz: a PerplexityBot követi a webmesteri beállításokat, a Perplexity-User viszont általában figyelmen kívül hagyja a robots.txt-t. Az az általánosító állítás tehát, hogy az MI-botok semmibe veszik a robots.txt-t, egy kalap alá veszi a fájlt tiszteletben tartó, dokumentált robotokat, a szolgáltatónként eltérően viselkedő, felhasználó által kiváltott lekérőket, és azokat a scrapereket, amelyek soha nem azonosítják magukat.

Az alábbi táblázat az írás pillanatában naprakész. Új tokenek gyorsabban jelennek meg, mint ahogy bármelyik cikk követni tudná őket, ezért kezeld rövid szavatosságú kiindulási térképként.

robots.txt-szabályok írása MI-robotokhoz

RFC 9309 kimondja, hogy a robots.txt szabályai nem hozzáférési engedélyezés. Az IETF 2022 szeptemberében szabványosította a szintaxist, az elemzést és a gyorsítótárazást; a fájlból ettől még nem lett kikényszerítő eszköz. A gyakorlatban fájó részletek a szintaxis alatt vannak: a fájlnak UTF-8 kódolásúnak kell lennie, az elemzőknek legalább 500 kibibájtot fel kell dolgozniuk, és ütköző direktívák esetén a legspecifikusabb útvonal-egyezés nyer. Az, hogy egy szabály hol áll a fájlban, semmit sem befolyásol.

Az MI-botoknak szóló robots.txt ugyanazt a fájlt és ugyanazt a szintaxist használja, ami már megvan; csak a tokenlista változik. Rendezd a szabályokat szándék szerint, és túlélik a szolgáltatói felállást. Ha a tanítás ellen van kifogásod, tiltsd a tanító tokeneket, az indexelőket pedig hagyd békén:

# Block training, keep AI search indexing
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Ha a táblázat minden megnevezett tokenjének webhelyszintű kilépési jelzést akarsz küldeni, fogd őket egyetlen szabály alá. Nem kell tizenegyszer megismételni a Disallow-t:

# Send a site-wide opt-out signal to named AI tokens
User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: OAI-AdsBot
User-agent: ClaudeBot
User-agent: Claude-User
User-agent: Claude-SearchBot
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Google-Extended
User-agent: CCBot
Disallow: /

Ez még mindig nem univerzális tiltás. Az Anthropic alkalmazza a robots.txt-t a Claude-Userre, az OpenAI szerint viszont a szabályok nem feltétlenül vonatkoznak a ChatGPT-Userre, a Perplexity-User pedig általában figyelmen kívül hagyja őket. Ha ezeket a felhasználó által kiváltott lekéréseket meg kell állítani, nem csak elbátortalanítani, akkor a döntést a proxynál vagy a WAF-ban kényszerítsd ki.

A Google-Extended a leggyakrabban félreértett token, és a különbség számít, ha a keresési forgalom fizeti a számláidat. a Google robotdokumentációja önálló terméktokenként írja le, amely azt szabályozza, felhasználható-e a bejárt tartalom a Gemini tanításához és megalapozásához a Keresésen kívül, és kimondja, hogy nem befolyásolja a webhely szerepeltetését vagy helyezését a Google Keresésben. A tiltása nem érinti a Googlebot keresési viselkedését.

Kézzel karbantartani egy tokenlistát nem jó időtöltés délutánra. A közösség által gondozott ai.robots.txt tároló nyomon követi az MI-felhasználóügynököket, és konfigurációkat állít elő robots.txt, nginx, Caddy, HAProxy, Lighttpd és Apache számára. Az Apache-üzemeltetők a generált blokkot odatehetik a többi könyvtárszintű .htaccess szabály mellé.

Profi tipp: ne bízz a user-agent karakterláncban. Az csak egy fejléc, a fejléceket pedig ingyen lehet hamisítani. A Common Crawl CCBot-dokumentációja figyelmeztet, hogy egyes robotok hamisan CCBotnak adják ki magukat. IPv4 esetén előre visszaigazolt fordított DNS-sel ellenőrizz a következő alatt: *.crawl.commoncrawl.org; IPv6 esetén használd a Common Crawl által közzétett IP-tartományokat, mert ott a fordított DNS jelenleg nem támogatott. A fent említett gyártói oldalak szintén közzéteszik a többi megnevezett robot aktuális IP-tartományait. Ez ezeknél a gyártóknál dokumentált ellenőrzési út, nem pedig az MI-robotok általános tulajdonsága.

Csinál egyáltalán bármit az llms.txt?

A jelenlegi adatok alapján szinte semmit. Az llms.txt egy javasolt, sima szöveges fájl a webhely gyökerében, amely a nyelvi modelleknek gondozott összefoglalót kínál a tartalmadról. Közzétenni olcsó, de a mostani adatok kevés okot adnak arra, hogy energiát fektess bele, és a Google dokumentációja szerint az MI-keresési funkcióihoz nincs is rá szükséged.

A formátum minimális. Az llms.txt javaslat 2024 szeptemberéből származik, itt található: /llms.txt, és egyedüli kötelező elemként a webhely vagy a projekt nevét tartalmazó H1 címsort írja elő.

Az ítélet a mérésekből jön. Az Ahrefs 137 210 domaint vizsgáló tanulmánya azt találta, hogy a vizsgált domainek 28 %-a tett közzé llms.txt fájlt, és hogy ezek 97 %-a egyetlen kérést sem kapott 2026 májusában. A ténylegesen beérkezett kérések 19,5 %-a névvel azonosítható MI-eszközöktől jött. Az Ahrefs arra is figyelmeztet, hogy egy letöltés nem bizonyítja, hogy a fájlt valóban használták is.

Az adatokat úgy olvasom, hogy az llms.txt fogadás egy olyan konvencióra, amelyet az általa megcélzott rendszerek nem vettek át széles körben. Tedd közzé, ha szereted a rendezett gyökérkönyvtárat. De ne építs köré generáló futószalagot, ne engedd, hogy blokkoló lépéssé váljon a telepítésedben, és aki rangsorolási vagy hivatkozási eszközként adja el neked, azt tekintsd jócskán a bizonyítékok előtt járónak.

Fő tanulság: az Ahrefs tanulmányában a közzétett llms.txt fájlok 97 %-a egyáltalán nem kapott kérést 2026 májusában.

Tedd géppel olvashatóvá az oldalaidat

A Vercel robotmérése azt találta, hogy az OpenAI robotjai, a ClaudeBot, a PerplexityBot, a Meta-ExternalAgent, a Bytespider és a CCBot nem futtat JavaScriptet. A Googleboton keresztüli Gemini és az AppleBot viszont igen. A nem renderelő robotok számára láthatatlan minden olyan tartalom, amely csak kliensoldali hidratálás után jelenik meg, ezért a kritikus részeket rendereld szerveroldalon. A jelölés a könnyebb kérdés, és a Google saját útmutatása ebben szokatlanul egyenes:

„Nem kell új, géppel olvasható fájlokat, MI-szövegfájlokat vagy jelölést létrehoznod ahhoz, hogy megjelenj ezekben a funkciókban. Nincs olyan külön schema.org strukturált adat sem, amelyet hozzá kellene adnod.”

A Google Search Central MI-útmutatója

A 40 %-os láthatóságnövekedés, amelyre néha a FAQ-séma védelmében hivatkoznak, a GEO-tanulmányból származik, amelyet a KDD 2024 fogadott el. A tanulmány akár 40 %-os javulásról számol be, de a vizsgált beavatkozások tartalmi változtatásokra összpontosítanak: forrásmegjelölésre, idézetekre, statisztikákra, szakterminológiára és gördülékeny fogalmazásra, nem a FAQPage-re vagy bármely más Schema.org jelölésre. A szám stimmel; a séma-jelöléshez kötése nem.

Tartsd meg a strukturált adatokat ott, ahol egy klasszikus Keresés-funkciót támogatnak, és egyeznek a látható oldallal. A Google szerint az MI-funkcióira való jogosultság a szokásos keresési indexelésen keresztül vezet, külön jelölési követelmény nélkül. Csak épp nem bizonyított, hogy elmozdítaná az MI-hivatkozásokat.

Amikor a robots.txt kevés: sebességkorlátozás és WAF a szerveren

A direktívák azoknál a botoknál működnek, amelyek beszálltak a játékba. Ugyanabban a Hacker News-szálbantöbb üzemeltető is leírta azt a forgalmat, amelyik nem: robotok, amelyek hatalmas IP-blokk-készleteken osztják szét a kéréseiket, és forgatják a felhasználóügynököket, hogy hétköznapi látogatónak látsszanak, ami egyaránt kivédi a naiv IP-alapú korlátokat és a felhasználóügynök-egyeztetést. Kezeld közösségi beszámolóként; a szálban senki nem közölt méréseket. De pontosan azt a kört írja le, amelyet a robots.txt sosem volt hivatott elérni.

Mielőtt nekiindulnál ennek a létrának, van egy olcsóbb lépés az együttműködő forgalomra: lassítsd le:

User-agent: ClaudeBot
Crawl-delay: 1

Profi tipp: előbb fojtsd vissza, csak azután tilts. Az Anthropic dokumentációja támogatja a Crawl-delay-t a ClaudeBothoz , így egy nehéz, de jól nevelt robotot le tudsz lassítani, és mégis megtarthatod. Ugyanaz az oldal azt is kimondja, hogy az IP-tiltás nem tartós kilépési mechanizmus. Mindkét pont kifejezetten az Anthropicra vonatkozik; Crawl-delay nem univerzális direktíva, ezért előbb nézd meg az egyes gyártók dokumentációját.

Minden, ami ezen túl van, olyan kikényszerítés, amit magad üzemeltetsz, három, egyre költségesebb és egyre hatásosabb fokban. Mindegyik nyer valamit, és le is mond valamiről.

1. fok: fordított proxy direktívák és sebességkorlátozás

Az MI-robotok sebességkorlátozása a fordított proxynál kezdődik: ez az első elem a rendszeredben, amely látja a kérést, és le tudja lassítani, mielőtt az alkalmazás vagy az adatbázis bármit is dolgozna. Az NGINX sebességkorlátozási dokumentációja kimondja, hogy az üres kulcsú kéréseket nem számolja a rendszer, így egy map csak azoknak a robot-tokeneknek adhat sebességkorlát-kulcsot, amelyeket vissza akarsz fogni, az egyezés nélküli kéréseket pedig kívül hagyja ezen: limit_req_zone.

# /etc/nginx/nginx.conf, inside the http block
map $http_user_agent $ai_rate_key {
    default              "";
    ~*GPTBot             $binary_remote_addr;
    ~*OAI-SearchBot      $binary_remote_addr;
    ~*ClaudeBot          $binary_remote_addr;
    ~*Claude-SearchBot   $binary_remote_addr;
    ~*PerplexityBot      $binary_remote_addr;
    ~*CCBot              $binary_remote_addr;
}

limit_req_zone $ai_rate_key zone=ai_slowlane:10m rate=20r/m;

# /etc/nginx/sites-available/example.conf, inside the server block
location / {
    limit_req zone=ai_slowlane burst=10 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

A hangolandó páros a burst=10 nodelay: az átlagos ütem feletti kérések azonnal felélhetik a löketet, az azon túliak pedig alapértelmezés szerint 503 érkezik vissza. Ha túl szorosra állítod, egy jogos robotot pattintasz le a bejárás közepén, és ezt lassabb diagnosztizálni, mint egy kiesést. A Caddy ugyanezt a két gondolatot egy matcherrel és egy handlerrel fejezi ki; ha a kettő között választasz, a egymás mellé tett konfigurációs fájlok hasznosabbak egy szintetikus áteresztőképesség-számnál.

Ennek a foknak az a korlátja, hogy a lassú sáv továbbra is a bemondott felhasználóügynöktől függ. Egy Chrome-nak öltözött scraper teljesen megkerüli ezt a robotokra szabott kulcsot; az ilyen forgalom elkapásához tágabb, IP- vagy útvonal-viselkedésen alapuló sebességkorlát kell, vagy az alábbi WAF-fok.

2. fok: saját üzemeltetésű webalkalmazás-tűzfal

A WAF egyetlen fejlécről egy olyan szabálykészletre viszi át a döntést, amely a kérésmintákat, útvonalakat és ütemeket együtt olvassa, és pontosan erre van szükséged, amint a forgalom abbahagyja a bemutatkozást. Ha a saját gépeden futtatod, a szabályok és a naplók a te lemezeden maradnak, ahol hajnali háromkor is grepelheted őket. BunkerWeb az egyik ilyen projekt, SafeLine a másik, és mindkettő elfut egy VPS-en, ha a gazdagép megfelel a projekt architektúra- és erőforrásigényeinek; mindkettőből kínálunk egykattintásos változatot, hogy megspóroljuk neked a telepítést, bár nem a csomagolás az érdekes rész.

Ez egyben ennek a foknak az ára is. A szabályok karbantartást igényelnek, és egy olyan szabály, amely elég szoros ahhoz, hogy elkapjon egy elszánt scrapert, előbb-utóbb embert is elkap. A SafeLine Monitor, Balanced és Strict módjai kifejezetté teszik ezt a kompromisszumot: előbb figyeld a forgalmat elég sokáig ahhoz, hogy megtaláld a téves riasztásokat, és csak azután engedd, hogy a WAF automatikusan 403-at adjon vissza.

3. fok: proof-of-work kihívások

Az Anubis teljesen megkerüli az azonosítás problémáját. Arra a forgalomra, amelyet kihívásra jelölsz ki, kis számítási költséget fizettet a kéréssel, mielőtt az origin kiszolgálná. Szabályrendszere az illesztési szabályok szerint engedélyezni, tiltani vagy kihívással illetni is tudja a kéréseket. A projekt README-je Web AI Firewall Utilityként írja le, amely kihívások köré épül, hogy megvédje az upstream erőforrásokat a scraper botoktól. Úgy működik, hogy nem követeli meg minden bottól a helyes azonosítást.

Maga a projekt atomcsapásnak nevezi ezt a megközelítést, és a fenntartás jogos. Az adót minden olyan forgalom fizeti, amelyet a szabályzatod kihívással illet, és ha a szabályok túl tágak, ebbe lassú eszközt használó emberek vagy jogos robotok is beleférnek. Tartogasd ezt a fokot valóban ellenséges forgalomra. Egy lelkes robot rendszerint sebességkorlát-kérdés, a sebességkorlát pedig már megvan.

Méretezés a rohamra

A robotterhelés gyakran hullámokban érkezik, de hogy CPU-, adatbázis- vagy I/O-igényes-e, az az alkalmazástól és a bejárt URL-ektől függ. A fenti WordPress-példában az üzemeltető az egy másodperces oldalidő nagy részét a MySQL-ig vezette vissza, tehát az a konkrét eset forgalmi problémának öltözött adatbázis-szűk keresztmetszet volt.

Ezzel a méretezés elosztási kérdéssé válik, méghozzá kellemetlenné: a tartalékért folyamatosan fizetsz, és csak egy olyan csúcs alatt hozza vissza az árát, amelyet nem te irányítasz. Azért mégis tervezz a csúcsra. Ha a BunkerWeb egy gépen osztozik az alkalmazással és az adatbázissal, ne vedd a 8 GB-ot az egész rendszerre szóló ajánlásnak. A BunkerWeb gyorsindítási útmutatója 2 vCPU-t és 8 GB RAM-ot ajánl teszteléshez vagy nagyon kevés szolgáltatást futtató telepítésekhez, és legalább 4 vCPU-t 16 GB RAM-mal olyan éles környezetekhez, amelyek sok szolgáltatást védenek. Erre jön rá az alkalmazás saját CPU-csúcsa, az adatbázis memóriaigénye és az I/O-tartalék.

A magasabb órajelű magok akkor segítenek, ha a kéréskezelés vagy a lekérdezés-végrehajtás CPU-korlátos; a több mag akkor, ha egyszerre több munkát kell a levegőben tartanod. A méretezést a csúcs-párhuzamosságból, a p95 válaszidőből, az adatbázis CPU- és I/O-várakozásából, valamint a gyorsítótár-tévesztési arányból számold, ne pusztán a robotforgalomból.

Ha ezt a réteget magad üzemelteted, két dolgot kér az alatta lévő géptől: root hozzáférést, hiszen a fenti minden mechanizmus egy konfigurációs fájl, amit szerkesztesz, és egy szolgáltatás, amit újraindítasz, valamint elegendő tartalékot ahhoz, hogy egy roham ne vigye le a webhelyet, amíg a szabályok dolgoznak. Ha ehhez géppel méretezel vagy költözöl, a Linux VPS Linux VPS-ünk megadja azt a root hozzáférést, amit ez a rendszer megkövetel, és lehetővé teszi, hogy kipróbáld a proxy és WAF felállást, mielőtt hosszú távra elköteleződsz egy méret mellett.

Építkezz Linux VPS-en root hozzáféréssel, NVMe-vel és AMD EPYC teljesítménnyel.

Linux csomagok megtekintése

A Cloudflare új alapértelmezései az MI-forgalomra

A Cloudflare a Search, Agent és Training kategóriákra osztotta az MI-forgalmat a 2026 júliusi MI-forgalmi bejelentésében. 2026. szeptember 15-től a Cloudflare-hez újonnan csatlakozó domaineknél a Training és az Agent alapértelmezés szerint tiltva lesz a hirdetéseket megjelenítő oldalakon, a Search viszont engedélyezett marad. A meglévő ügyfelek előre módosíthatják a beállítást, és a vezérlők minden csomagban elérhetők.

Amit érdemes átvenni, az a bonyodalom, amelyet a Cloudflare a saját bejelentésében nevez néven. Az osztályozásában a Googlebot, az Applebot és a Bingbot mindegyike keresési és tanítási munkát is végez, így az az ügyfél, aki tiltja a Training kategóriát, ezeket a robotokat is tiltja, azt a keresési viselkedést is beleértve, amelyet meg akart tartani. Ugyanez a csapda vár minden kategóriaszintű vezérlőre, amely úgy kezel egy többcélú robotot, mintha egyetlen feladata volna.

Ha a webhelyed nem a Cloudflare mögött van, ezek közül egyik sem olyan kar, amit meghúzhatnál. Azt viszont tudd, hogy jön, mert szeptemberben elmozdítja a forgalmi mintázatokat; a te eszközeid továbbra is a robots.txt tokenjei és a fenti proxyréteg.

WebMCP: figyelni érdemes, építeni még nem

A WebMCP a Model Context Protocol böngészőoldali párja; ez utóbbi az a megállapodás, amellyel az ügynökök találgatás helyett strukturált eszközöket hívnak meg. A Chrome WebMCP origin trial bejelentése egyenesen fogalmazza meg a célt: ahelyett, hogy egy ügynök találgatná, mit csinál egy gomb vagy űrlapmező, a webhely strukturált függvényeket és feliratozott vezérlőket tehet közzé, amelyeket az ügynök közvetlenül hívhat meg.

Ez az első hitelt érdemlő kísérlet arra, hogy az ügynököknek az olvasáson túl is dolguk legyen a webhelyeden, és épp ettől ez a cikk legérdekesebb része. Ugyanakkor kísérleti és befejezetlen: egy Chrome 149-es origin trial, amely 2026 júniusában indult. Figyeld a specifikációt. Egyelőre ne építs rá éles függőséget, és hagyd ki a kapacitástervedből.

Gyakran ismételt kérdések

User-agent: GPTBot
Disallow: /

grep -ohE 'GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|ChatGPT-User' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn