Ten tekst jest uzupełnieniem do artykułu z 10 sierpnia o zmianie domyślnych ustawień Cloudflare. Tamten tekst zostaje bez zmian — był trafny na czas publikacji. Ten dopisujemy, bo od sierpnia pojawiły się trzy rzeczy warte odnotowania, a temat wciąż się rusza.
Piętnastego września zmieniają się domyślne ustawienia Cloudflare dla botów AI. Zostało osiem dni. Jeśli nie sprawdziłeś jeszcze starego przełącznika „Block AI bots" — to wciąż jest priorytet numer jeden, dokładnie taki jak w sierpniu.
Trzy rzeczy zmieniły się od tamtego tekstu. Piszemy o nich, ale bez pretensji do ostatecznej diagnozy — ten obszar zmienia się co kilka tygodni i część z tego może wyglądać inaczej za miesiąca nawet już za wspomniane w tytule 8 dni.
1. Google powiedział wprost, że nie stosuje się do jednej z warstw tej polityki
Rozróżnijmy od razu dwie różne rzeczy, które łatwo pomylić.
Ustawienia w panelu Cloudflare (Search / Agent / Training, o których pisaliśmy w sierpniu) działają na poziomie sieci — Cloudflare blokuje ruch, zanim dotrze do Twojego serwera. To jest twarda blokada.
Dyrektywa Content-signal w pliku robots.txt to coś innego — deklaracja intencji zapisana w pliku tekstowym, którą bot może przeczytać i uszanować, albo zignorować. Cloudflare dopisuje ją automatycznie do zarządzanego robots.txt jako uzupełnienie tych samych trzech kategorii.
John Mueller z Google potwierdził w ostatnich tygodniach, że wyszukiwarka nie stosuje się do tej drugiej warstwy — do samej dyrektywy w pliku. Nie wiemy, czy to się zmieni, ani kiedy. Nie zmienia to natomiast pierwszej warstwy: blokada sieciowa w panelu Cloudflare działa niezależnie od tego, co robi Google z plikiem robots.txt. To wciąż jest ta sama decyzja, o której pisaliśmy w sierpniu, i wciąż warto ją podjąć świadomie.
Innymi słowy: sam plik robots.txt z sygnałami to dziś deklaracja, nie zamek. Jeśli chcesz zamka, potrzebujesz warstwy sieciowej — czyli właśnie tych ustawień w Cloudflare.
2. Pojawiło się czwarte pole — i jeszcze jeden, zupełnie inny standard
Cloudflare testuje dodatkowe pole use (obok search/ai-input/ai-train), które opisuje, co bot może zrobić z treścią po jej pobraniu — od „nic nie zachowuj" do „streszczaj i reprodukuj". Jest nowe, wciąż oznaczone jako testowe, i nie wiemy, jak szybko się ustabilizuje.
Równolegle IETF (organizacja standaryzująca protokoły internetowe, nie Cloudflare) rozwija osobny, konkurencyjny — albo równoległy, trudno dziś powiedzieć który termin będzie właściwy — standard o nazwie Content-Usage. Współautorem jest inżynier Google, co bywa cytowane jako sygnał, że to może zyskać szersze wsparcie. To jednak wciąż wersja robocza bez pełnego konsensusu grupy roboczej. Nie mamy podstaw, by dziś powiedzieć, czy to wystrzeli, czy zostanie ciekawostką.
Praktyczny wniosek na teraz: jeśli dbasz o kompletność, można dodać oba — to prawie nic to nie kosztuje, a zwiększa szansę na pokrycie niezależnie od tego, który standard ostatecznie zyska adopcję.
3. Przy budowie naszego generatora znaleźliśmy błąd, który pewnie popełnia też ktoś inny
To jest szczegół techniczny, ale konkretny i łatwy do przeoczenia.
Standard robots.txt (RFC 9309) mówi, że bot, który znajdzie dedykowaną dla siebie sekcję — na przykład User-agent: GPTBot — czyta wyłącznie tę sekcję. Ignoruje całkowicie sekcję globalną User-agent: *, nawet jeśli to tam zadeklarowałeś ai-train=no.
Konsekwencja: jeśli masz w pliku osobne sekcje dla konkretnych botów (co jest coraz częstsze — wiele generatorów i wtyczek to robi), a Twoja polityka Content-signal siedzi tylko w sekcji *, to każdy bot z własną sekcją jej po prostu nie widzi bo wcale jej nie czyta. Blokujesz trenowanie „na papierze", a bot, który ma swoją sekcję, i tak nie wie, że mu tego zabroniłeś.
Sprawdź swój plik: jeśli masz osobne wpisy dla GPTBot, ClaudeBot czy innych named agentów, i chcesz żeby polityka Content Signals ich dotyczyła — musi być powtórzona w każdej z tych sekcji, nie tylko w globalnej.
Co z tego wynika na 8 dni przed deadline'em
Niewiele się zmienia w praktycznej rekomendacji z sierpnia: sprawdź stary przełącznik, ustaw trzy kategorie świadomie, zapisz kalendarz na 22 września. To wciąż jest właściwy plan - sprawdzenie po tygodniu od zmian Search Console i odpowiedzi AI.
To, co dopisujemy, to głównie kontekst i ostrzeżenie przed nadmierną pewnością: sam plik robots.txt to deklaracja, nie gwarancja; nowe pola i standardy są w ruchu i mogą wyglądać inaczej za kwartał; a jeśli budujesz plik ręcznie albo przez inny generator, warto sprawdzić, czy polityka faktycznie dochodzi do każdego bota, a nie tylko do sekcji domyślnej.
Zaktualizowaliśmy i rozbudowaliśmy nasz Generator robots.txt + Content Signals o te trzy rzeczy — pole use, opcjonalny Content-Usage, i poprawkę na dziedziczenie polityki per bot. Generator dopasował się też wizualnie do nowej sekcji narzędzi iFox.pl, którą sukcesywnie poprawiamy i uzupełniamy.
Jeśli to Twój pierwszy kontakt z tematem, zacznij od artykułu sierpniowego — matryca decyzyjna dla typu strony wciąż jest aktualna. Ten tekst tylko dopisuje to, co zmieniło się od tamtej pory.