Stará dohoda byla jednoduchá jen na pohled

Robots Exclusion Protocol vznikl v roce 1994 pro mnohem menší web. Jeho základní logika byla praktická: crawler si na kořeni webu přečte textový soubor, zjistí, kam smí, a dobrovolně se podle toho chová. V roce 2022 byl protokol formalizován jako RFC 9309, ale ani tím se z něj nestal bezpečnostní mechanismus. Samotné RFC říká přímo, že pravidla v robots.txt nejsou forma autorizace přístupu.

To dlouho nevadilo, protože výměna mezi webem a crawlerem byla zhruba čitelná. Vyhledávač stáhl veřejný obsah, zařadil ho do indexu a provozovatel webu z toho mohl dostat návštěvnost. Ani tehdy to nebylo právně ani technicky čisté, ale provozně to dávalo smysl. Bot, který respektoval robots.txt, byl většinou vítaný host. Bot, který ho nerespektoval, byl scraper.

S nástupem generativní AI se tahle dohoda rozpadla na několik různých účelů přístupu. Crawl už automaticky neznamená vyhledávání. Může jít o indexaci pro search, sběr dat pro trénink základního modelu (foundation modelu), uzemnění odpovědi v aktuálních zdrojích, jednorázové načtení URL na pokyn uživatele, interní výzkum, benchmark nebo dataset prodávaný dál. HTTP požadavek v access logu může vypadat podobně. Obchodní a technický význam je jiný.

Správná otázka proto dnes nezní jen „mám bota povolit, nebo zakázat“. Přesnější je ptát se, pro jaký účel má dostat přístup, jak ověřit, že jde opravdu o deklarovaného bota, a co se stane, když se pravidly řídit nebude.

Robots.txt řídí crawling, ne bezpečnost

Google ve své dokumentaci opakuje věc, kterou si část provozovatelů webů plete dodnes: robots.txt slouží ke správě crawlování, ne k ochraně obsahu. URL blokovaná v robots.txt se může v Google Search pořád objevit, pokud na ni vedou odkazy odjinud; Google jen nemusí znát její obsah a obvykle ji zobrazí bez snippetu. Pro skutečné vyřazení stránky z indexu má sloužit noindex, HTTP hlavička X-Robots-Tag, odstranění stránky nebo omezení přístupu.

To má praktický dopad. Když dáte neveřejnou část aplikace jen do Disallow, nechráníte ji. Jen veřejně říkáte slušným crawlerům, že tam nemají chodit. Citlivý obsah patří za autentizaci a autorizaci. Staging, preview buildy, exporty tenant dat nebo placené části aplikace nemají spoléhat na textový soubor, který si může přečíst každý. Jinými slovy: Disallow je provozní pokyn, ne kontrola přístupu.

Druhý častý omyl je noindex uvnitř robots.txt. Google už v roce 2019 napsal, že nepodporovaná pravidla typu crawl-delay, nofollow a noindex v robots.txt nepatří do jeho produkčního parseru. Pokud chcete indexaci řídit na úrovni stránky, použijte meta robots nebo X-Robots-Tag. Jen pozor na pořadí: crawler se k těmto direktivám dostane až tehdy, když smí stránku načíst.

U AI crawlerů se k tomu přidává další komplikace. robots.txt neumí sám od sebe říct, že stejný obsah smí být použit pro vyhledávání, ale ne pro trénink, nebo že smí být načten jen při explicitním požadavku uživatele. Někteří dodavatelé proto přidali vlastní tokeny. Jinde pomáhá WAF, CDN, IP allowlisty a ověřování botů. Jednotný produkční standard pro „povol vyhledávání, zakaž trénink, povol citaci v odpovědi jen s linkem“ zatím hotový není.

Jeden crawler už neznamená jednu věc

Nejsnáze je to vidět na Googlu. Googlebot je crawler pro Google Search. Vedle něj existuje Google-Extended, což není samostatný HTTP user-agent, ale token v robots.txt. Google ho popisuje jako způsob, jak řídit použití obsahu, který Google crawluje, pro trénink budoucích modelů Gemini a pro grounding v Gemini Apps a Vertex AI. Google zároveň uvádí, že Google-Extended neovlivňuje zařazení do Google Search ani ranking.

V logách se ten rozdíl snadno ztratí. Když zablokujete Googlebot, řešíte Search. Když zablokujete Google-Extended, řešíte navazující použití dat v jiných AI produktech Googlu. Je to dodavatelské rozdělení, ale technicky dává smysl: search crawl a souhlas s tréninkem už nejsou totéž.

OpenAI dnes rozlišuje několik relevantních identit. OAI-SearchBot slouží pro search v ChatGPT, GPTBot pro crawling obsahu, který může být použit při tréninku generativních základních modelů, a ChatGPT-User pro akce vyvolané uživatelem v ChatGPT, Custom GPTs nebo GPT Actions. OpenAI v dokumentaci výslovně říká, že nastavení pro search a trénink jsou nezávislá: web může povolit OAI-SearchBot, aby se objevil v ChatGPT search, a zároveň zakázat GPTBot, aby tím dal najevo nesouhlas s použitím obsahu pro trénink.

Největší provozní háček je ChatGPT-User. OpenAI ho nepopisuje jako automatický web crawler, ale jako user-agent pro určité uživatelské akce. Když uživatel požádá ChatGPT o práci s konkrétní stránkou, může systém na URL sáhnout s tímto user-agentem. Podle dokumentace OpenAI se na takové akce nemusí vztahovat pravidla robots.txt, protože je spustil uživatel. Pro provoz webu je to konkrétní rozdíl v tom, co uvidíte v logách a co dává smysl blokovat.

Anthropic má podobné rozdělení. ClaudeBot sbírá webový obsah, který může přispět k tréninku modelů. Claude-User slouží pro načtení webu při dotazech uživatelů Clauda a Claude-SearchBot pro zlepšování kvality search odpovědí. Pokud zakážete Claude-SearchBot, Anthropic upozorňuje, že tím můžete snížit viditelnost obsahu ve vyhledávání v Claudovi. Pokud zakážete Claude-User, bráníte načítání vyvolanému uživatelem.

Apple zvolil vlastní variantu. Applebot crawluje pro Spotlight, Siri, Safari a další systémové funkce. Applebot-Extended je sekundární token pro opt-out z použití dat k tréninku základních modelů Applu. Apple výslovně píše, že Applebot-Extended nic necrawluje. Pokud ho zakážete, obsah může zůstat dostupný pro vyhledávací a systémové funkce Applu přes Applebot.

Perplexity ukazuje rozdíl mezi search indexací a načtením na pokyn uživatele ještě ostřeji. Podle vlastní dokumentace PerplexityBot slouží k tomu, aby se weby mohly objevovat ve výsledcích Perplexity, a není určen pro trénink základních modelů. To je tvrzení dodavatele. Perplexity-User naproti tomu slouží pro požadavky vyvolané uživatelem a dokumentace Perplexity říká, že tento fetcher obecně ignoruje robots.txt. Pokud chcete tyto requesty řídit, samotné pravidlo v robots.txt nestačí. Musíte pracovat s WAF pravidly, IP rozsahy a user-agentem.

Prakticky z toho vychází čtyři kategorie, které je dobré posuzovat odděleně:

Minimální robots politika už vypadá jinak

Dřív stačilo mít pár pravidel pro Googlebot, Bingbot a případně několik otravných scraperů. Dnes by provozovatel veřejného webu měl nejdřív rozhodnout, zda chce být viditelný ve vyhledávání, zda chce být citovatelný v AI search odpovědích, zda dovolí trénink a zda dovolí načtení na pokyn uživatele. To jsou různé otázky.

Jedna možná politika pro veřejnou dokumentaci, která chce zůstat viditelná v klasickém vyhledávání a AI searchi, ale nechce signalizovat souhlas s tréninkem, může vypadat takto:

User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

User-agent: Applebot
Allow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: ClaudeBot
Disallow: /

User-agent: PerplexityBot
Allow: /

User-agent: CCBot
Disallow: /

User-agent: *
Disallow:Code language: HTTP (http)

Tohle není univerzální doporučení. Je to ukázka oddělení účelů. Klasické vyhledávání a načítání pro AI odpovědi mohou být pro vývojářskou dokumentaci užitečné, protože uživatelé se k ní dostanou přes Google, ChatGPT, Claude nebo Perplexity. Trénink a zařazení obsahu do datasetů jsou jiné rozhodnutí. U komerčního obsahu, placené knowledge base nebo webu s licenčně citlivými daty může být politika tvrdší.

robots.txt ale není finální stav. U slušných crawlerů je to deklarace preference. U crawleru, který pravidla ignoruje, je to jen textový soubor. Jakmile jde o skutečné náklady, bezpečnost nebo placený obsah, musí přijít kontrola na úrovni HTTP nebo WAF, rate limiting, validace identity bota a oddělení veřejných a neveřejných URL.

Cloudflare přesouvá kontrolu na edge, ale není to neutrální standard

Cloudflare má v téhle debatě zvláštní pozici. Provozuje infrastrukturu, na které sedí velká část webu, a zároveň prodává bot management. Jeho data jsou proto cenná, ale pořád jde o data jednoho dodavatele. V červenci 2025 Cloudflare uvedl, že na fixním vzorku zákazníků mezi květnem 2024 a květnem 2025 vzrostl AI a search crawler traffic o 18 %. Při započítání nových zákazníků uvádí růst 48 %. Není to nezávislé měření celého webu, ale jedna z mála veřejných sad, která ukazuje, že crawling už není jen SEO téma.

Cloudflare proto staví AI Crawl Control kolem tří praktických věcí: monitoringu aktivity crawlerů, pravidel pro konkrétní crawlery a sledování toho, zda respektují robots.txt. Dokumentace uvádí granularitu podle jednotlivých crawlerů a možnost vytvářet pravidla pro vynucení chování. To je posun od „napiš signál“ k „vynucuj chování na edge“.

Ještě zajímavější je Pay Per Crawl. Ke květnu 2026 ho Cloudflare v dokumentaci vede jako uzavřenou betu, tedy ne jako obecně dostupný webový standard. Mechanismus je přímočarý: crawler přijde na placenou URL, Cloudflare vrátí HTTP 402 Payment Required a hlavičku crawler-price. Crawler může zopakovat request s crawler-exact-price, případně poslat crawler-max-price už v prvním requestu. Úspěšný požadavek vrátí HTTP 200 a hlavičku crawler-charged.

V dokumentaci pro AI crawlery Cloudflare stejný tok popisuje konkrétněji: odpověď 402 obsahuje crawler-price, druhý request musí nést crawler-exact-price nebo crawler-max-price a platební hlavičky musí být zahrnuté do podpisu Web Bot Auth. Web Bot Auth je postavený na kryptograficky podepsaných HTTP zprávách, které Cloudflare používá k ověření identity deklarovaného automatizovaného bota.

Technicky jsou na tom zajímavé dvě věci. Zaprvé, 402 Payment Required se po letech existence v HTTP dostává do konkrétního provozního scénáře. Zadruhé, crawler politika se přesouvá z dobrovolného textového signálu k autentizovanému a účtovatelnému HTTP toku. Jenže to platí jen pro crawlery, které se do takového modelu zapojí, a pro weby v odpovídajícím CDN nasazení. Scraper, který pravidla ignoruje, se tím nezastaví. Maximálně dostane další překážku.

Pay Per Crawl proto není dobré popisovat jako nový standard webu. Ke květnu 2026 jde o konkrétní implementaci Cloudflare v uzavřené betě. Pro velké vydavatele může být obchodně zajímavá. Pro běžný vývojářský blog je důležitější princip: pokud má přístup k obsahu ekonomickou hodnotu, robots.txt není místo, kde se má vyjednávat cena.

Alternativní soubory nenahradí vynucování pravidel

Kolem AI crawlerů vznikla řada návrhů: llms.txt, ai.txt, TDMRep, RSL, Content Signals a další. Některé míří na lepší kontext pro modely, jiné na právní nebo licenční signalizaci. Všechny reagují na stejný problém. robots.txt umí dobře říct „crawler smí nebo nesmí na URL“, ale neumí dobře popsat účel použití, licenční podmínky, odměnu, souhlas s tréninkem nebo doporučené shrnutí dokumentace pro LLM.

llms.txt je z těchto návrhů nejpraktičtější pro vývojářskou dokumentaci, ale neřeší blokování. Samotný návrh ho popisuje jako Markdown soubor na /llms.txt, který má LLM a agentům nabídnout kurátorovaný přehled důležitých dokumentů. Autoři výslovně míří na inference time, tedy na situaci, kdy model nebo agent potřebuje pochopit web při práci s uživatelem. Není to opt-out z tréninku ani mechanismus pro vynucení pravidel.

RSL, tedy Really Simple Licensing, jde jinudy. Specifikace RSL 1.0 definuje strojově čitelný formát pro licenční, platební a právní podmínky přístupu k digitálním aktivům automatizovanými systémy. Počítá s discovery přes robots.txt, HTTP hlavičky, HTML i další cesty a s navazujícím licenčním procesem. To je blíž obchodnímu vztahu než prosté crawl preferenci. Pořád ale platí, že samotný soubor nic nevynutí proti crawleru, který ho nechce respektovat nebo který k obsahu přistupuje mimo podporovaný tok.

TDMRep je důležitý hlavně v evropské debatě o text and data miningu. Specifikace umí vyjádřit rezervaci práv vůči TDM a odkaz na licenční politiku, mimo jiné přes HTTP hlavičky a metadata. Není to ale W3C Recommendation ani obecná odpověď na provozní otázku, co má správce běžného webu nasadit zítra vedle WAF a logování.

Do hry vstoupila i IETF. Pracovní skupina AI Preferences připravuje slovník pro vyjadřování AI usage preferences. Aktuální draft A Vocabulary For Expressing AI Usage Preferences je pracovní dokument, ne hotové RFC. Starší pracovní text k připojení preferencí k obsahu v HTTP je podle Datatrackeru expirovaný; pořád ale dobře ukazuje směr, kterým se debata ubírala. Navrhoval signalizaci preferencí při získávání obsahu přes HTTP a počítal i s úpravou RFC 9309, pokud by byl schválen. Provozovatelům webů to ale dnes ještě nedává univerzální produkční protokol, který by nahradil směs vendor tokenů, robots pravidel a WAF konfigurací.

Z toho plyne méně příjemné pravidlo: nové soubory a slovníky mohou pomoci dobře se chovajícím crawlerům pochopit záměr provozovatele. Nepomohou s crawlerem, který záměr ignoruje. U něj rozhoduje síťová a aplikační kontrola.

Co z toho plyne pro různé typy webů

Malý vývojářský blog nebo dokumentace by neměly panicky blokovat všechno, co má v názvu AI. Pro takový web je často důležitější objevitelnost než licenční čistota za každou cenu. Má smysl povolit klasické search crawlery a zvážit povolení AI search crawlerů, pokud chcete, aby dokumentace byla citovatelná v odpovědích. Tréninkové boty můžete blokovat zvlášť, pokud s použitím obsahu pro trénink nesouhlasíte.

SaaS knowledge base potřebuje ostřejší hranice. Veřejná dokumentace, changelogy a FAQ mohou být indexované a dohledatelné. Interní články, návody pro konkrétní tenanty, staging help centrum a preview verze patří za login nebo na oddělenou doménu s technickou ochranou. Disallow: /internal/ je slabá náhrada za autentizaci.

Obsahové weby a média mají nejtěžší rozhodnutí. Search crawler přivádí návštěvnost, AI vyhledávač může obsah použít v odpovědi, ale návštěva webu z toho vzniknout nemusí. Cloudflare na svém Radaru pracuje s crawl-to-refer poměrem a popisuje, že u některých AI crawlerů je poměr mezi crawlingem a návštěvností z odkazů velmi nepříznivý. Je to interpretace nad daty Cloudflare, ne neutrální obraz celého webu, ale dobře vysvětluje, proč se vydavatelé posouvají od prostého blokování k licencování, partnerstvím a placenému přístupu.

Aplikace s placeným nebo neveřejným obsahem by měly začít základní hygienou. Co nemá být veřejné, nemá být veřejně dostupné. Co má být veřejné jen pro platící uživatele, má být chráněné autorizací a měřením. Teprve nad tím dává smysl řešit, zda konkrétní AI crawler dostane placený, omezený nebo žádný přístup.

Logy jsou důležitější než seznam módních botů

Praktická práce nezačíná u opsání dvaceti user-agentů z cizího blogu. Začíná u vlastních logů. Potřebujete vědět, kdo vám na web chodí, z jakých IP rozsahů a ASN, jak často si stahuje robots.txt, jak se chová po Disallow, které pathy zatěžuje, kolik provozu jde na origin a kolik se obslouží z cache.

Minimum, které má smysl sledovat, je User-Agent, normalizovaný název crawleru, IP range, ASN, request rate, poměr 200/301/304/403/429/402, cache hit ratio, provoz z originu, top pathy podle počtu requestů a objemu dat, četnost přístupů na parametrické URL a reakce na změny v robots.txt. U AI searchu navíc sledujte referraly a UTM parametry tam, kde je platformy posílají. Bez toho budete rozhodovat podle pocitu a podle blogů dodavatelů.

Další krok je rozdělení obsahu. Veřejná dokumentace, blog, marketingové stránky, API reference, help centrum, aplikace, preview, staging a placené články nemají mít stejnou crawler policy. V ideálním případě mají odlišné hostname, pravidla pro cesty, pravidla cache a WAF politiku. Kdo to celé spravuje jedním globálním Disallow, koleduje si o dva typy problémů: zbytečné náklady na crawling, nebo nechtěné odříznutí od discovery kanálů.

Tady se ukazuje riziko závislosti na jednom dodavateli. Cloudflare dnes patří k nejviditelnějším dodavatelům nástrojů pro AI crawl control, ověřování botů a Pay Per Crawl. Pokud Cloudflare používáte, je logické je testovat. Pokud ne, neznamená to, že nemůžete dělat nic. Přenositelný základ je pořád stejný: čistý robots.txt, správné meta robots a X-Robots-Tag, autentizace pro neveřejný obsah, rate limiting, WAF pravidla, logy a pravidelná kontrola skutečného chování crawlerů.

Základní politika pro crawlery v roce 2026

Následující přehled odpovídá stavu k květnu 2026. U produkční konfigurace je nutné ověřit aktuální dokumentaci dodavatelů, jejich IP rozsahy a skutečné chování v logách.

Rozumná crawler politika dnes nevypadá jako jeden seznam zákazů. Vypadá spíš jako provozní rozhodnutí nad čtyřmi otázkami.

První otázka zní, co má být veřejně dohledatelné v klasickém searchi. Sem patří Googlebot, Applebot, Bingbot a další search crawlery, plus noindex, snippety a crawl budget.

Druhá otázka se týká viditelnosti v AI search a odpovědích s odkazy. U ní jde o OAI-SearchBot, Claude-SearchBot, PerplexityBot a podobné identifikátory. Blokování může snížit citovatelnost a viditelnost v těchto produktech.

Třetí otázka je souhlas s tréninkem nebo jiným navazujícím AI použitím. Sem patří GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, případně CCBot a další dataset crawlery, jejichž výstupy mohou navazujícím způsobem sloužit i pro ML nebo LLM trénink. U části tvrzení budete závislí na dokumentaci dodavatele, nikoli na nezávislém auditu.

Čtvrtá otázka je technické vynucení bez ohledu na dobrovolné signály. V té chvíli přestává být robots.txt hlavním nástrojem. Nastupuje autentizace, WAF, IP a ASN pravidla, ověřování botů, rate limiting, cache politika a u hodnotného obsahu možná i 402 handshake.

Vývojářský závěr je střízlivý. robots.txt nevyhazujte. Jen ho přestaňte přeceňovat. Berte ho jako veřejný kontrakt pro slušné crawlery, ne jako firewall, licenční smlouvu nebo přepínač pro AI. Pokud provozujete blog nebo dokumentaci, oddělte search od tréninku a měřte dopad. U média nebo placeného obsahu řešte vynucení pravidel a ekonomiku přístupu. U aplikace s neveřejnými daty nezačínejte u crawlerů. Začněte tím, že ta data opravdu nejsou veřejně dostupná.