AI crawler budget: które boty AI warto wpuszczać, a które tylko palą zasoby?

Bot AI potrafi wejść na stronę ciszej niż Googlebot, ale zostawić po sobie większy rachunek. Nie zawsze widać to w GA4. Nie zawsze pojawi się referral. Czasem w logach zostaje tylko długa seria żądań do artykułów, tagów, filtrów, PDF-ów i endpointów, których normalny użytkownik nigdy nie dotyka.

Dlatego pytanie „blokować boty AI czy wpuszczać?” jest źle postawione. Nie ma jednego ruchu AI. Jest crawling treningowy, crawling pod wyszukiwanie, pobrania na żądanie użytkownika, podszywanie się pod przeglądarki i ruch, którego analityka nie umie jeszcze czysto przypisać. Decyzja musi zejść poziom niżej: który bot, na jakie sekcje, z jakim limitem, za jaki potencjalny efekt i przy jakim koszcie infrastruktury.

To właśnie jest AI crawler budget. Nie klasyczny crawl budget znany z SEO, tylko operacyjny limit tolerancji dla botów AI: ile requestów, transferu, cache missów, obciążenia aplikacji i ryzyka użycia treści jesteśmy gotowi zaakceptować, zanim dostęp trzeba przyciąć.

Nie blokuj „AI” jako jednej kategorii. Rozdziel trening, search i retrieval

Największy błąd w robots.txt to wpis w stylu: „blokujemy wszystkie boty AI, bo AI kradnie treści”. Drugi największy błąd to pełne otwarcie strony, bo „trzeba być widocznym w ChatGPT”. Obie decyzje są zbyt grube.

W praktyce trzeba rozdzielić trzy typy ruchu.

Boty treningowe pobierają publiczne treści, które mogą zostać użyte przy rozwoju modeli. Tu nie chodzi o szybkie kliknięcie z odpowiedzi AI, tylko o pytanie: czy chcę, żeby moje materiały zasilały systemy trenowane przez zewnętrzną firmę? Przykładem jest GPTBot, który OpenAI opisuje jako crawler treści mogących trafić do treningu modeli foundation. OpenAI wskazuje też, że zablokowanie GPTBot jest sygnałem, że treści nie powinny być użyte do treningu generatywnych modeli foundation.

Boty search pracują bliżej widoczności. OAI-SearchBot służy OpenAI do pokazywania stron w funkcjach wyszukiwania ChatGPT; dokumentacja OpenAI mówi wprost, że strona wyłączona z OAI-SearchBot nie będzie pokazywana w odpowiedziach ChatGPT search, choć może nadal pojawić się jako link nawigacyjny. OpenAI dodaje, że właściciel strony może dopuścić OAI-SearchBot i jednocześnie zablokować GPTBot. To jest dokładnie ten niuans, który powinien zmienić podejście do robots.txt: blokada treningu nie musi oznaczać blokady widoczności w AI search.

Boty retrieval / user-triggered pobierają stronę wtedy, gdy użytkownik w narzędziu AI o coś pyta albo wskazuje konkretny adres. W tej kategorii mieszczą się m.in. ChatGPT-User, Claude-User i Perplexity-User. Anthropic opisuje Claude-User jako agenta, który może pobierać strony na potrzeby zapytań użytkowników Claude; blokada może ograniczyć widoczność strony w user-directed web search. Perplexity z kolei podaje, że Perplexity-User wspiera działania użytkownika, nie służy do trenowania modeli foundation, ale ponieważ pobranie jest inicjowane przez użytkownika, ten fetcher zasadniczo ignoruje robots.txt.

Tu pojawia się praktyczna konsekwencja: robots.txt nie jest pełną polityką bezpieczeństwa. Dla uczciwych crawlerów to ważna deklaracja. Dla pobrań na żądanie użytkownika i botów ignorujących zasady — za mało. Reguły dostępu trzeba przenieść również do WAF, CDN, nginx, reguł cache i rate limitingu.

Osobny przypadek to Google-Extended. Nie należy go szukać w logach jako normalnego user-agenta HTTP. Google opisuje Google-Extended jako standalone product token w robots.txt. Pobrania są wykonywane przez istniejące user-agenty Google, a token Google-Extended kontroluje, czy treści Google crawlowane z witryny mogą być używane do trenowania przyszłych generacji Gemini oraz do grounding, czyli dostarczania treści z indeksu Google modelowi w czasie odpowiedzi. Google deklaruje, że Google-Extended nie wpływa na obecność w Google Search ani nie jest sygnałem rankingowym.

Przykład poprawnej, ale świadomej konfiguracji:

# Blokada użycia treści do treningu OpenAI
User-agent: GPTBot
Disallow: /

# Dopuszczenie widoczności w ChatGPT Search
User-agent: OAI-SearchBot
Allow: /

# Google-Extended nie jest osobnym HTTP user-agentem w logach.
# To token kontroli użycia treści dla Gemini / Vertex AI.
User-agent: Google-Extended
Disallow: /

# Blokada treningowego crawlera Anthropic
User-agent: ClaudeBot
Disallow: /

# Dopuszczenie crawlera search Anthropic
User-agent: Claude-SearchBot
Allow: /

# Dopuszczenie Perplexity do wyników i linkowania
User-agent: PerplexityBot
Allow: /

To nie jest gotowiec dla każdej strony. To wzorzec myślenia. Inaczej ustawiłbym blog ekspercki, inaczej sklep z tysiącami filtrów, inaczej płatny serwis analityczny, a jeszcze inaczej dokumentację SaaS-a. Przy dokumentacji technicznej dopuszczenie botów search i retrieval zwykle ma sens, bo użytkownik chce dostać szybką odpowiedź i może przejść do źródła. Przy płatnych raportach, bazach danych i unikalnych analizach domyślna zgoda na trening to słaba pozycja biznesowa.

Najprostsza segmentacja decyzyjna:

• bot treningowy na treściach premium, raportach, analizach, bazach danych — zwykle blokada;
• bot search na publicznych poradnikach, dokumentacji i stronach produktowych — zwykle allow z monitoringiem;
• user-triggered retrieval — allow tam, gdzie odpowiedź AI może wygenerować wartościową ekspozycję, ale z ochroną sekcji kosztowych;
• bot podszywający się, ignorujący reguły, rotujący IP — traktować jak scraping, nie jak partnera od widoczności.

Ważne: sam user-agent nie wystarczy. Google wprost ostrzega, że ciąg user-agenta można podszyć, dlatego boty trzeba weryfikować przez IP, reverse DNS albo oficjalne zakresy operatora. Przy większych serwisach to nie jest nadgorliwość, tylko normalna higiena DevOps.

AI crawler budget liczy się w logach, cache missach i kosztach originu

AI crawler budget zaczyna się od eksportu logów. Minimum to 14 dni, rozsądniej 30 dni. Jeden dzień potrafi kompletnie zafałszować obraz, bo crawler mógł akurat wejść w sitemapę, archiwum albo sekcję z paginacją.

Do pierwszego raportu wystarczy prosta tabela:

• user-agent;
• IP / ASN / reverse DNS, jeżeli są dostępne;
• liczba requestów;
• transfer, najlepiej edge bytes i origin bytes osobno;
• cache status: hit, miss, bypass, dynamic;
• statusy HTTP: 2xx, 3xx, 4xx, 5xx;
• top URL patterns, np. /blog/, /tag/, /search/, /api/, ?sort=, ?filter=;
• średni i p95 czas odpowiedzi;
• udział requestów do HTML, PDF, obrazów, JSON i plików statycznych;
• widoczne wejścia z AI, ale traktowane ostrożnie.

Dopiero taki widok pokazuje, czy bot czyta wartościowe artykuły, czy mieli śmieciowe kombinacje adresów. W audytach najczęściej problemem nie jest jeden crawler, który odwiedził 200 artykułów. Problemem jest bot, który wszedł w:

• filtry kategorii z setkami kombinacji;
• sortowania typu ?sort=price_asc;
• parametry sesji;
• wewnętrzne wyniki wyszukiwania;
• tagi bez unikalnej treści;
• paginację archiwów;
• stare PDF-y po kilka lub kilkanaście MB;
• endpointy JSON;
• obrazy w pełnej rozdzielczości;
• strony koszyka, konta albo checkoutu, które nie powinny być crawlwane.

Model kosztu powinien być brutalnie prosty:

koszt bota = transfer
           + requesty
           + cache missy
           + CPU / PHP / Node / DB
           + logowanie i monitoring
           + ryzyko użycia treści

Jeżeli bot pobiera 150 GB miesięcznie, a twoja infrastruktura rozlicza transfer po 0,08 USD/GB, sam transfer kosztuje 12 USD. To może wyglądać niewinnie. Ale jeżeli większość tych requestów omija cache i uruchamia aplikację, prawdziwy koszt siedzi w originie: wolniejszy TTFB, więcej procesów PHP, wyższe obciążenie bazy, dodatkowe reguły WAF, większe logi i gorsza stabilność w godzinach szczytu.

Dlatego sama liczba requestów jest słabą metryką. Lepiej liczyć:

AI crawler cost score =
(requesty × waga requestu)
+ (cache missy × waga missu)
+ (GB z originu × koszt GB)
+ (requesty 5xx × kara stabilności)
+ (URL-e premium × kara biznesowa)

Nie trzeba od razu budować idealnego modelu finansowego. Wystarczy porównać boty między sobą. Jeżeli jeden crawler robi 5 000 requestów miesięcznie, głównie do HTML-a z cache, a drugi robi 120 000 requestów, z czego połowa to cache missy na parametrach filtrów, decyzja nie wymaga długiego warsztatu. Drugi dostaje limit albo blokadę ścieżek.

Warto też policzyć crawl-to-referral ratio:

crawl-to-referral ratio = liczba crawlów AI / liczba widocznych wejść z danego narzędzia

Przykład: 60 000 requestów bota i 20 widocznych wejść z narzędzia AI daje 3000:1. To nie znaczy automatycznie „blokuj”. Znaczy: sprawdź, za co płacisz.

Ten wskaźnik ma jednak poważne ograniczenie. AI referrals są niedoszacowane. Część kliknięć z narzędzi AI pojawia się z referrerem, część wpada jako direct / none, część miesza się z ruchem organicznym, a część ekspozycji nie kończy się kliknięciem. Google dodało w maju 2026 roku w GA4 kanał AI Assistant, który pomaga identyfikować ruch z chatbotów takich jak ChatGPT, Gemini i Claude, ale to nadal nie jest pełny obraz. Branżowe analizy zwracają uwagę, że nowy kanał opiera się na rozpoznanym referrerze, więc nie obejmuje wszystkich sesji, a ruch z Google AI Overviews i AI Mode nadal jest klasyfikowany w ekosystemie organic search, nie jako osobny pełny kanał AI Assistant.

Najbezpieczniejsza interpretacja: widoczne AI referrals to dolna granica wpływu, nie pełny wpływ. Jeżeli ChatGPT, Claude, Gemini albo Perplexity cytują markę bez kliknięcia, klasyczna analityka tego nie policzy. Jeżeli użytkownik zobaczy odpowiedź, a potem wpisze domenę ręcznie, system może przypisać wejście do direct. Jeżeli Google pokazuje odpowiedź w AI Overview, dane w Search Console i GA4 nie dadzą tak czystego rozbicia, jakiego oczekiwałby SEO-wiec.

Dlatego decyzji nie podejmowałbym na podstawie jednego wskaźnika. Minimum to zestaw:

• logi CDN / serwera: requesty, transfer, cache missy, statusy, ścieżki;
• GA4: AI Assistant, referrale, direct / none, landing pages;
• GSC: zmiany kliknięć i widoczności z Google, bez udawania, że da się idealnie oddzielić AI Overviews;
• monitoring cytowań: ręczne albo narzędziowe sprawdzanie, czy strona pojawia się w odpowiedziach AI;
• koszt originu: nie tylko transfer, ale też obciążenie aplikacji.

Dane Cloudflare pokazują, dlaczego to ma znaczenie. W analizie ruchu AI za ostatnie 12 miesięcy Cloudflare podał, że około 80% crawlingu AI dotyczyło treningu, około 18% search, a około 2% działań użytkowników. W ostatnich sześciu miesiącach udział treningu wzrósł do 82%, search spadł do 15%, a działania użytkowników wzrosły do 3%. Innymi słowy: większość aktywności AI crawlerów nie jest tym samym co użytkownik klikający odpowiedź i odwiedzający stronę.

Praktyczny próg decyzyjny:

Najpierw stabilność.
Jeżeli bot powoduje cache missy, wzrost 5xx, obciąża bazę albo pogarsza TTFB, nie czekaj na pełny raport SEO. Daj limit na CDN/WAF, zamknij parametry i wytnij dynamiczne ścieżki.

Potem wartość treści.
Treści premium, raporty, autorskie bazy danych, dokumenty płatne, cenniki B2B i eksperckie analizy nie powinny być domyślnie otwarte na trening. Search i retrieval można rozważyć osobno.

Na końcu widoczność.
Jeżeli bot może dawać cytowania, wejścia albo ekspozycję marki, nie blokuj globalnie bez sprawdzenia ścieżek. Często najlepsza konfiguracja to allow na /poradnik/, /docs/, /produkty/, a blokada na /search/, /tag/, /cart/, /account/, /api/ i parametrach.

Kogo wpuszczać, kogo ograniczać, a kogo blokować

Dobra polityka dla botów AI nie jest manifestem ideologicznym. To tabela decyzji. Każdy bot powinien dostać jedną z czterech etykiet: allow, allow z ograniczeniami, rate limit, block.

Dla serwisu contentowego punkt startowy może wyglądać tak:

# 1. Nie oddajemy treści do treningu bez świadomej decyzji
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

# 2. Dopuszczamy boty search, jeśli chcemy widoczności w odpowiedziach AI
User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# 3. Zamykamy sekcje kosztowe i niskiej jakości dla wszystkich botów
User-agent: *
Disallow: /search/
Disallow: /tag/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /*?session=
Disallow: /*?utm_

Nie kopiowałbym tego bezmyślnie. Jeżeli /tag/ ma unikalne opisy, indeksuje się dobrze i dowozi ruch organiczny, globalna blokada może zaszkodzić. Jeżeli /tag/ to generator duplikatów i paginacji, blokada oszczędza zasoby. To samo z PDF-ami: karta produktu w PDF może być istotna, ale archiwum 4 000 starych plików po 20 MB to zaproszenie do spalenia transferu.

Dla e-commerce priorytetem są parametry i filtry. Bot AI nie powinien chodzić po nieskończonych kombinacjach rozmiaru, koloru, sortowania, dostępności i ceny. Publiczne kategorie oraz strony produktów można zostawić dla search/retrieval, ale dynamiczne kombinacje powinny dostać blokadę albo canonicale, a przy realnym koszcie — reguły WAF.

Dla wydawcy problem jest bardziej biznesowy. Artykuł newsowy może zostać skonsumowany w odpowiedzi AI bez kliknięcia. Tu sens ma rozdzielenie: search boty można dopuścić na wybrane sekcje, ale treningowe crawlery blokować globalnie albo przynajmniej na treściach premium.

Dla SaaS-a z dokumentacją sytuacja bywa odwrotna. Dopuszczenie search/retrieval może zmniejszyć tarcie użytkownika: ktoś pyta asystenta o błąd API, dostaje cytowaną dokumentację i przechodzi do źródła. Blokowanie wszystkiego może ograniczyć widoczność w miejscu, w którym użytkownicy realnie szukają rozwiązań.

Dla serwisu afiliacyjnego sprawa jest delikatna. Jeśli AI odpowie użytkownikowi pełnym porównaniem bez kliknięcia, model przychodowy cierpi. Ale jeżeli strona ma mocne testy, dane własne, zdjęcia, tabele i opinie, obecność jako źródło może nadal mieć wartość. Tu nie blokowałbym globalnie od pierwszego dnia. Najpierw sprawdziłbym, które sekcje boty pobierają, czy pojawiają się cytowania i czy największy koszt nie siedzi przypadkiem w filtrach, obrazach albo starych listingach.

W warstwie technicznej sama deklaracja w robots.txt nie wystarczy. Potrzebne są reguły na brzegu:

• allowlist dla zweryfikowanych botów search/retrieval;
• rate limiting dla crawlerów pobierających zbyt szybko;
• blokady ścieżek dla filtrów, searcha wewnętrznego, kont, koszyka, API i parametrów;
• cache rules dla publicznych treści HTML, żeby bot nie uderzał stale w origin;
• WAF rules dla user-agentów podszywających się pod przeglądarki;
• monitoring 4xx/5xx, bo zbyt agresywna blokada też generuje szum;
• osobne reguły dla PDF i obrazów, bo ciężkie pliki potrafią zdominować transfer.

Jeżeli korzystasz z Cloudflare, dochodzi jeszcze AI Crawl Control i Pay Per Crawl. Cloudflare podaje, że minimalna cena w Pay Per Crawl to 0,01 USD za crawl, rozumiany jako udane pobranie treści z odpowiedzią HTTP 200. Dokumentacja dla crawlerów wskazuje też mechanizm odpowiedzi HTTP 402 Payment Required z nagłówkiem crawler-price, gdy treść jest chroniona płatnym dostępem dla crawlera. To ciekawy kierunek dla dużych wydawców i właścicieli wartościowych baz treści. Dla mniejszej strony pierwszym krokiem nadal powinny być logi, cache i blokada sekcji kosztowych, nie ustawianie cennika dla świata.

Najbardziej praktyczna matryca wygląda tak:

Jedna rzecz jest szczególnie ważna: brak referralów nie oznacza automatycznie braku wartości. AI może pokazać markę bez kliknięcia. Może też zainspirować użytkownika do późniejszego wejścia direct. Ale duży crawl bez referralów, bez cytowań i z wysokim kosztem originu to już nie jest „inwestycja w widoczność”. To niekontrolowany koszt.

Dlatego pierwsze wdrożenie nie powinno być wielkim projektem. Wystarczy procedura na 30 dni:

1. Wyciągnij logi z CDN albo serwera.
2. Odfiltruj top user-agenty AI po requestach i transferze.
3. Zweryfikuj IP / ASN dla największych crawlerów.
4. Podziel boty na training, search, retrieval, unknown.
5. Sprawdź top URL patterns dla każdego bota.
6. Policz cache missy i statusy 5xx.
7. Sprawdź widoczne wejścia z AI w GA4, ale traktuj je jako minimum.
8. Ręcznie sprawdź cytowania w kilku narzędziach AI dla najważniejszych tematów.
9. Zablokuj sekcje kosztowe.
10. Dopiero potem podejmij decyzję: allow, limit, block.

Zaczynałbym nie od blokowania znanych nazw, tylko od wycięcia oczywistych strat: parametrów, filtrów, searcha wewnętrznego, koszyka, API, ciężkich PDF-ów i duplikatów. To daje efekt bez ryzyka, że strona zniknie z odpowiedzi AI tam, gdzie obecność może mieć sens.

FAQ: najczęstsze problemy przy kontroli botów AI

Dlaczego nie widzę Google-Extended w logach serwera?
Bo Google-Extended nie jest osobnym user-agentem HTTP. To token w robots.txt. Pobrania wykonują istniejące roboty Google, a token steruje użyciem treści dla Gemini i Vertex AI.

Czy blokada Google-Extended blokuje Google Search?
Nie według dokumentacji Google. Google deklaruje, że Google-Extended nie wpływa na obecność strony w Google Search i nie jest sygnałem rankingowym.

Czy można zablokować trening, ale zostać w ChatGPT Search?
Tak. OpenAI rozdziela GPTBot i OAI-SearchBot. Możesz zablokować GPTBot, a dopuścić OAI-SearchBot, jeśli zależy ci na widoczności w funkcjach wyszukiwania ChatGPT.

Czy GA4 pokazuje cały ruch z narzędzi AI?
Nie. Kanał AI Assistant pomaga, ale nie łapie wszystkiego. Część sesji może wpadać jako direct, część jako referral, a ruch z Google AI Overviews i AI Mode nie daje pełnego, osobnego obrazu wpływu AI.

Jaki bot powinien dostać blokadę jako pierwszy?
Ten, który łączy trzy cechy: dużo requestów, dużo cache missów i brak wartościowych ścieżek. Szczególnie jeśli pobiera filtry, search wewnętrzny, parametry, API, ciężkie pliki albo treści premium.

Czy robots.txt wystarczy?
Nie. robots.txt jest deklaracją dla botów, które ją respektują. Przy scraperach, podszywaniu się pod przeglądarkę i kosztownych ścieżkach potrzebne są reguły WAF/CDN, rate limiting, cache rules i weryfikacja IP.

Czy blokować Perplexity-User?
Nie automatycznie. Perplexity opisuje Perplexity-User jako agenta działań użytkownika, nie crawler treningowy. Trzeba jednak pamiętać, że pobrania inicjowane przez użytkownika mogą ignorować robots.txt, więc kontrola powinna działać również na warstwie serwera lub CDN.

Czy Pay Per Crawl ma sens dla małej strony?
Zwykle nie jako pierwszy ruch. Najpierw trzeba policzyć logi, zamknąć sekcje kosztowe i ustawić cache. Pay Per Crawl ma większy sens przy serwisach z dużą skalą i treściami o wyraźnej wartości licencyjnej.

Jaki raport zrobić jako pierwszy?
Top 20 botów AI z ostatnich 30 dni według requestów i transferu. Do tego cache missy, statusy 5xx, top URL patterns, typ bota i widoczne wejścia z AI. Ta tabela zwykle wystarczy, żeby podjąć pierwsze decyzje.

Od czego zacząć, jeśli serwis już jest przeciążany?
Nie od dyskusji o całej strategii AI. Najpierw zablokuj /search/, /cart/, /account/, /api/, parametry filtrów i sortowania, ciężkie archiwa PDF oraz URL-e generujące cache missy. Dopiero potem rozdzielaj boty na training, search i retrieval.