Cloudflare mění výchozí nastavení AI botů. Kdo zablokuje trénink, přijde i o Google

Patnáctého září 2026 se mění výchozí nastavení, se kterým Cloudflare pouští AI boty na weby. Kdo si toho nevšimne, může se o následku dozvědět až z propadu v Search Console – a to je ten typ chyby, který se špatně hledá, protože v logu nevypadá jako chyba.

Napsal jsem tady v červenci, že AI boti se dělí na tři druhy a že pro provozovatele MCP serveru je jeden z nich zákazník. Tehdy to byl rámec. Teď je z toho termín v kalendáři, tak si projdu, co přesně se mění a co z toho plyne pro moje vlastní servery.

Co se mění a koho se to týká

Od 15. září budou crawlery kategorií Training a Agent ve výchozím stavu blokované na stránkách, které zobrazují reklamu. Search zůstává ve výchozím stavu povolený.

Netýká se to všech stejně. Nové nastavení dopadá na nové domény přicházející do Cloudflare, na nové zákazníky a na stávající zákazníky na bezplatném tarifu. Kdo to tak nechce, musí to do 15. září vypnout v nastavení Security. Placené tarify beze změny.

Dva detaily, které se ve shrnutích ztrácejí a přitom rozhodují. Za prvé: podmínkou je zobrazování reklamy. Můj blog ani MCP servery reklamu nemají, takže se mě výchozí změna přímo netýká. Za druhé, a to je důležitější: ta kategorizace existuje pro každého, kdo je za Cloudflare, bez ohledu na to, jestli se ho výchozí stav dotkne. Jakmile jednou sáhnete na přepínač „blokovat trénink“, platí pro vás totéž, co popisuju níž.

Tři kategorie nejsou tři jména

Rozdělení dává smysl, protože nepopisuje, kdo bot je, ale co dělá.

U vydavatele je ta úvaha přímočará: text je zboží, trénink je odnesení zboží bez placení. U provozovatele API nebo MCP serveru se to obrací. Agent, který přijde v reálném čase vyřídit úkol pro konkrétního člověka, je přesně ten provoz, kvůli kterému server běží. Zablokovat ho není obrana, je to zavření krámu.

Past, kvůli které tenhle článek píšu

Kdo zablokuje kategorii Training, zablokuje i víceúčelové crawlery – Googlebota, Applebota, Bingbota – i když má Search povolený.

Důvod je prostý a nepříjemný: jeden crawler dělá obojí. Googlebot indexuje pro vyhledávání a zároveň sbírá data, ze kterých se učí modely. Když řeknete „trénink ne“, není koho pustit napůl. Tohle je jediná věta z celé změny, kterou bych si přál, aby si přečetl každý, kdo v tom nastavení bude něco překlikávat.

Zrádné je na tom načasování zpětné vazby. Když omylem zablokujete zákazníka, ozve se vám. Když omylem zablokujete Googlebota, neozve se nikdo. Server vrací korektní odpovědi, monitoring je zelený, dashboard nesvítí. Poznáte to za týdny podle klesajících impresí – a to je doba, za kterou už dávno nebudete hledat příčinu v tom, na co jste v září klikli.

Sám jsem si na něco podobně tichého naběhl loni v jiné podobě, když jsem ověřoval hosting z domácí sítě a DNS mě obelhalo: všechno odpovídalo správně, jen z jiného stroje, než jsem si myslel. Poučení je stejné. Nastavení, jehož selhání nevyrobí chybovou hlášku, se musí ověřovat aktivně a zvenčí.

Co to znamená pro MCP server

MCP server nemá čtenáře. Má volající. Přijde-li automat jménem člověka, který se právě ptá na firmu v rejstříku, je to obsloužený dotaz, ne krádež obsahu. Kategorie Agent je u něj příjmová položka.

To ale neznamená, že je každý automatizovaný požadavek užitečný. Provozuji na svých serverech vlastní klasifikátor, který každý požadavek zařadí do třídy podle chování, a čísla z něj jsou v tomhle střízlivá.

Jeden monitorovací nástroj třetí strany posílal tisíce požadavků denně na všechny moje MCP endpointy. Zhruba dvě třetiny z nich skončily chybou 400, protože to nebyl platný MCP JSON-RPC – byl to ping na dostupnost, ne volání nástroje. Prošel počítadlem požadavků, ale nespotřeboval žádný výpočet a nezavolal jediný nástroj.

Z toho plyne pravidlo, které opakuji, protože se na něj pořád zapomíná: požadavky se nerovnají použití. Kdo měří zájem o svůj server počtem požadavků, měří hlavně to, kolik katalogů a monitorů o něm ví.

Opačným směrem funguje tentýž rozdíl. Jeden AI crawler prošel jednu moji aplikaci rychlostí 77 tisíc požadavků za den, druhý den 89 tisíc. Kdybych se díval jen na zátěž, byl by to důvod k zablokování. Jsou to ale organizační stránky ve všech jazykových verzích, které tím vstoupily do indexu, ze kterého se odpovídá lidem. To není útok. To je distribuční kanál, který si sám naběhl.

Jak si to změřit u sebe

Základní chyba je klasifikovat podle jména v hlavičce. Hlavičku si nastaví kdokoli. Noční provoz, který mi na jedné doméně vypadal jako lidé, byl z velké části skenery s civilní hlavičkou prohlížeče, které projížděly neexistující cesty a hledaly zranitelnosti.

Užitečnější je ptát se po chování:

Chodí to v noci a nikdy nezavolá nástroj?      → sonda nebo skener
Volá to nástroj a čeká na výsledek?             → agent, tedy zákazník
Prochází to systematicky sitemapu?              → index, tedy distribuce
Dostává to většinou 400?                        → to není použití, to je ping

Ověření před 15. zářím je krátké. Zjistit, jestli je doména na bezplatném tarifu a jestli některá stránka zobrazuje reklamu – jen tehdy se výchozí změna projeví sama. Podívat se, co je v nastavení Security přepnuté, a nesahat na blokaci tréninku, dokud je pro vás vyhledávání důležitější než ochrana textu. A po 15. září se dívat na imprese, ne jenom na chybovost.

Co budu měřit a co by to vyvrátilo

Tvrdím tady tři věci, u kterých vím, jak zjistím, že jsem se pletl.

Za prvé: že se moje domény samy nezmění, protože nemají reklamu a nejsou na bezplatném tarifu. Vyvrátí to jakýkoli pokles indexovaných stránek nebo impresí v týdnech po 15. září, který nepůjde vysvětlit ničím jiným.

Za druhé: že podíl agentního provozu na mých MCP serverech po 15. září neklesne, protože Agent boti k nim chodí přímo, ne přes weby s reklamou. Vyvrátí to pokles počtu skutečných volání nástrojů – ne požadavků – proti srpnovému průměru.

Za třetí: že crawler, který sbírá pro odpovědi, přináší lidi. To zatím tvrdit nemůžu. Mám jen jeho objem, ne návštěvy, které z toho vznikly. Až budu mít data z obou stran, napíšu, jak to dopadlo – i kdyby ten kanál nepřinesl nic.