Crawl budget 2026: zarządzanie botami i crawlerami AI

Crawl budget długo uchodził za niszowy temat dla bardzo dużych witryn. W 2026 roku to się zmieniło. Oprócz Googlebota do witryn trafia dziś cała gama crawlerów AI, z własnymi celami, własnym obciążeniem i własną wartością. Crawl budget przestał więc być wyłącznie sprawą Google i stał się problemem zarządzania wieloma botami. Ten artykuł wyjaśnia, jak crawl budget działa od strony technicznej, od kiedy naprawdę ma znaczenie w B2B i jak w praktyce wygląda zróżnicowane sterowanie Googlebotem, Bingbotem i crawlerami AI.

Dlaczego crawl budget w 2026 roku to problem wielu botów

W klasycznym ujęciu crawl budget opisuje, ile stron z danej witryny wyszukiwarka pobiera w określonym czasie. Dopóki liczył się tylko Googlebot, dotyczyło to niemal wyłącznie bardzo dużych witryn. W 2026 roku to założenie nie wystarcza, bo krajobraz crawlerów zasadniczo się poszerzył.

Wzrost da się zmierzyć. Według międzynarodowej analizy Cloudflare boty AI odpowiadały w 2025 roku średnio za 4,2% wszystkich żądań HTML, a Googlebot za 4,5%, przez co był już tylko nieznacznie większy niż wszystkie boty AI razem. Szczególnie dynamicznie rozwija się skanowanie AI inicjowane przez użytkowników: wzrosło w 2025 roku ponad 15-krotnie. Chodzi o skanowanie, przy którym bot odwiedza stronę w czasie rzeczywistym w odpowiedzi na pytanie zadane chatbotowi. Wśród samych crawlerów AI środek ciężkości mocno przesunął się w stronę OpenAI: udział GPTBota wzrósł między majem 2024 a majem 2025 z 5 do 30% wśród crawlerów AI, przy wzroście liczby żądań o 305%, podczas gdy udział Bytespidera w tym samym okresie spadł z 42 do 7,2%.

Na austriackim rynku B2B Googlebot pozostaje wprawdzie najważniejszym crawlerem, ponieważ Google wyraźnie dominuje: w maju 2026 roku miał 81,87% udziału w rynku, przed Bingiem z 9,01% i DuckDuckGo z 2,75%. Crawlery AI dochodzą jednak do tego wszystkiego: zużywają zasoby serwera, obciążają przepustowość edge i CDN i każą zadać pytanie, jaką wartość daje każdy bot. Właśnie dlatego crawl budget staje się tematem sterowania dla wszystkich interesariuszy, nie tylko dla Google.

Crawl Capacity Limit i Crawl Demand: od kiedy to ma znaczenie

Google definiuje crawl budget witryny jako liczbę adresów URL, które Google może i chce przeskanować. Składa się on z dwóch elementów: Crawl Capacity Limit i Crawl Demand.

• Crawl Capacity Limit: górna granica tego, co serwer wytrzyma bez przeciążenia. Jeśli witryna odpowiada szybko i bez błędów, limit rośnie. Jeśli zwalnia lub zwraca błędy serwera, Google ogranicza skanowanie, aby ją oszczędzać.
• Crawl Demand: zapotrzebowanie na przeskanowanie danego adresu URL. Zależy od popularności strony i od tego, jak często zmienia się jej treść. Nieaktualne lub niezmieniane strony są odwiedzane rzadziej.

Kluczowe jest pytanie, od kiedy w ogóle ma to znaczenie. Google stawia sprawę jasno: jego przewodnik jest skierowany do dużych witryn z ponad 1 milionem unikalnych stron i treścią zmieniającą się co tydzień oraz do średnich i większych witryn z ponad 10 000 unikalnych stron i treścią zmieniającą się bardzo często, na przykład codziennie. Dla typowej witryny B2B liczącej kilkaset stron crawl budget z perspektywy samego Googlebota rzadko jest więc wąskim gardłem.

To uspokojenie dotyczy jednak tylko Googlebota i tylko klasycznego skanowania. Gdy nawigacja fasetowa, adresy URL filtrów lub duży katalog produktów sztucznie zwiększają liczbę adresów URL, problem z budżetem może mieć także średniej wielkości witryna. A crawlery AI działają według własnej logiki, która nie ma nic wspólnego z progami Google.

Zarządzanie wieloma botami: zróżnicowana strategia robots.txt

Pierwszą dźwignią jest plik robots.txt. W 2026 roku nie chodzi w nim już o proste zezwalanie lub blokowanie, tylko o tabelę sterowania dla różnych klas botów. Na świecie robots.txt od dawna jest areną zarządzania crawlerami AI. Według Web Almanac 2025 najważniejsze user agenty AI są w nim już celowo uwzględniane: GPTBot w 4,5%, ClaudeBot w 3,6%, CCBot w 3,5% i Google-Extended w 3,4% plików robots.txt w wersji desktop, przy czym GPTBot niemal podwoił swój udział względem 2024 roku. Zdecydowanie najczęstszą dyrektywą pozostaje symbol wieloznaczny: uniwersalny user agent, czyli gwiazdka (*), pojawił się w 2025 roku w 77% plików.

Przemyślana strategia rozróżnia boty według ich celu:

• Crawlery wyszukiwarek (Googlebot, Bingbot): pełny dostęp. Dostarczają ruch organiczny i są podstawą biznesu. Tu nigdy nie blokuje się ich hurtowo, a jedynie celowo ogranicza marnowanie crawl budgetu.
• Crawlery wyszukiwania AI (OAI-SearchBot, PerplexityBot): obsługują odpowiedzi w czasie rzeczywistym z podaniem źródeł i potencjalnym ruchem z odesłań. Jeśli zależy ci na widoczności w odpowiedziach AI, z reguły je dopuszczasz.
• Crawlery treningowe AI (GPTBot, ClaudeBot, CCBot, Meta-ExternalAgent): zbierają dane do trenowania modeli. Tu potrzebna jest świadoma decyzja, ponieważ zużyciu zasobów często nie odpowiada żadna bezpośrednia korzyść.

Ważne jest czyste rozdzielenie user agentów. Google-Extended nie jest osobnym crawlerem. Według Google nie ma własnego ciągu user agenta, tylko jest wyłącznie tokenem sterującym dla pliku robots.txt. Strony pobierają zwykłe crawlery Google. Token określa jedynie, czy Google może wykorzystywać treści do trenowania modeli Gemini i do groundingu. Grounding oznacza, że Gemini, odpowiadając na zapytanie, korzysta jako ze źródła z treści z indeksu Google. Na uwzględnienie w wyszukiwarce Google i ranking token nie ma wpływu. Jeśli zablokujesz Google-Extended, zachowasz więc widoczność w Google i wykluczysz jedynie wykorzystanie treści przez Gemini. To rozróżnienie jest sednem zarządzania wieloma botami.

Rozróżnianie rodzajów obciążenia od crawlerów AI: trening, wyszukiwanie, czas rzeczywisty

Hurtowe blokowanie lub zezwalanie pomija fakt, że crawlery AI pełnią trzy zupełnie różne funkcje. Międzynarodowa analiza danych Cloudflare jasno określa te proporcje: trening odpowiada dziś za niemal 80% aktywności botów AI, 18% przypada na wyszukiwanie, a tylko 2% na działania inicjowane przez użytkowników.

• Skanowanie treningowe: boty takie jak GPTBot, ClaudeBot czy CCBot pobierają treści do trenowania modeli. Taki dostęp generuje obciążenie, ale rzadko przekłada się na ruch, który można mu bezpośrednio przypisać. To rodzaj obciążenia o najsłabszej bezpośredniej korzyści.
• Skanowanie wyszukiwawcze: systemy wyszukiwania AI pobierają treści, aby cytować je w odpowiedziach. Tu istnieje szansa na ruch z odesłań i widoczność marki, podobnie jak w klasycznym wyszukiwaniu.
• Skanowanie w czasie rzeczywistym inicjowane przez użytkowników: boty takie jak ChatGPT-User odwiedzają stronę na żywo, bo użytkownik zadał pytanie na czacie. Ten rodzaj obciążenia ma niewielką skalę, ale sygnalizuje konkretne zainteresowanie użytkownika właśnie tą treścią w momencie zapytania.

Praktyczny wniosek: jeśli chcesz obniżyć koszty serwera bez utraty widoczności, najpierw ogranicz skanowanie treningowe, a skanowanie wyszukiwawcze i w czasie rzeczywistym zostaw. Hurtowa blokada wszystkich botów AI odcięłaby natomiast także potencjalnie wartościowe wizyty.

Jak wyeliminować marnowanie crawl budgetu

Zanim zajmiesz się zarządzaniem botami, usuń marnotrawstwo, które powstaje we własnej witrynie. W praktyce to największy problem i dotyczy wszystkich crawlerów w równym stopniu. Jak drastycznie mogą rozjechać się proporcje, pokazuje międzynarodowe studium przypadku Botify: 97% z około 1 mln przeskanowanych stron było niekanonicznych, przy zaledwie około 25 000 indeksowalnych adresów URL, z których Google skanował co miesiąc niewiele ponad połowę. Według tego samego źródła w całej branży w niezoptymalizowanych witrynach Google skanuje co miesiąc średnio tylko 40% strategicznych adresów URL, a 60% pozostaje nieprzeskanowanych.

Typowe źródła marnotrawstwa można celowo wyeliminować:

• Nawigacja fasetowa i adresy URL z parametrami: kombinacje filtrów i sortowania tworzą niemal nieograniczoną liczbę adresów URL o prawie identycznej treści. Sterowanie odbywa się przez tagi canonical, celowe użycie noindex lub zablokowanie całych ścieżek z parametrami w pliku robots.txt.
• Duplicate content: wiele adresów URL z identyczną treścią, np. z powodu wielkich i małych liter, końcowych ukośników (trailing slash) lub identyfikatorów sesji. Konsekwentna strategia canonical skupia sygnały na jednym preferowanym adresie URL.
• Soft 404: strony bez rzeczywistej treści, które błędnie zwracają status 200 zamiast 404 lub 410. Zużywają crawl budget na treści bez wartości.
• Niekończące się ścieżki skanowania: kalendarze, paginacja bez końca lub zagnieżdżone filtry, które prowadzą crawlery coraz głębiej.

Zasada brzmi: crawlery powinny spędzać swój ograniczony czas na stronach, które mają się pozycjonować lub być cytowane, a nie na technicznym balaście.

Aktywne sterowanie indeksem: mapy witryny i IndexNow

Zamiast tylko unikać marnotrawstwa, możesz aktywnie kierować crawlery do właściwych adresów URL. Służą do tego dwa uzupełniające się narzędzia.

• Mapy witryny XML: zawierają kanoniczne adresy URL warte zaindeksowania wraz z datą aktualizacji. Dobrze utrzymana mapa witryny pomaga wyszukiwarkom sprawnie znajdować nowe i zmienione strony bez przeszukiwania całej witryny. To podstawa oszczędnego gospodarowania crawl budgetem.
• IndexNow: protokół push, za pomocą którego witryna aktywnie informuje wyszukiwarki o nowych lub zmienionych adresach URL, zamiast czekać na kolejne skanowanie. Skala wdrożeń jest znaczna: według Binga za pośrednictwem IndexNow przesyła się ponad 3,5 mld adresów URL dziennie, a 18% wszystkich nowo klikniętych adresów URL w wynikach wyszukiwania internetowego pochodzi właśnie stamtąd.

Kluczowe zastrzeżenie: IndexNow obsługują Bing, Yandex i inne wyszukiwarki, ale nie Google. Ponieważ w Austrii rynek zdominował Google, IndexNow jest tu przydatnym uzupełnieniem dla widoczności w Bingu, ale nie zastępuje porządnej strategii map witryny i skanowania dla Google. Oba narzędzia się uzupełniają: mapy witryny dla Google, IndexNow dodatkowo dla wyszukiwarek uczestniczących w IndexNow.

Zarządzanie botami na poziomie edge, CDN i serwera

Plik robots.txt to prośba, a nie przymus. Rzetelne crawlery go przestrzegają, inne nie. Jeśli chcesz technicznie zapobiegać przeciążeniu przez skanowanie albo niezawodnie zatrzymywać niechciane boty, potrzebujesz sterowania na poziomie edge, CDN i serwera.

• Weryfikacja prawdziwych botów: autentyczne crawlery można zweryfikować na podstawie oficjalnie publikowanych zakresów IP lub przez odwrotne wyszukiwanie DNS. W ten sposób odróżnisz prawdziwego Googlebota od botów, które tylko się pod niego podszywają.
• Rate limiting: ogranicza częstotliwość żądań na bota lub zakres IP. Chroni to serwer źródłowy przed skokami obciążenia, nie odcinając całkowicie uprawnionych crawlerów.
• Selektywne blokowanie i dopuszczanie: na poziomie CDN można celowo blokować boty treningowe AI, przepuszczając jednocześnie boty wyszukiwania i działające w czasie rzeczywistym. To rozwiązanie jest precyzyjniejsze i skuteczniejsze w egzekwowaniu niż sam plik robots.txt.
• Ochrona cache: crawlery AI często sięgają po rzadko odwiedzane treści z długiego ogona, których nie ma w cache edge. Takie żądania trafiają bezpośrednio do serwera źródłowego i konkurują o zasoby z ruchem ludzi. Rate limiting i celowy routing zmniejszają tu obciążenie.

Ten poziom jest szczególnie istotny dla witryn B2B wrażliwych na zasoby, w których przepustowość serwera i stabilne czasy odpowiedzi dla płacących klientów mają pierwszeństwo przed niekontrolowanym dostępem botów.

Analiza logów serwera jako narzędzie sterowania

Bez pomiaru każde sterowanie skanowaniem to lot na ślepo. Standardowa analityka internetowa, taka jak GA4, praktycznie nie rejestruje crawlerów AI, ponieważ nie wykonują one JavaScriptu i nie zapisują plików cookie. Jedynym wiarygodnym źródłem danych jest plik logów serwera. Pokazuje, który bot, kiedy i z jakim kodem statusu pobrał dany adres URL.

Z logów można wyznaczyć kluczowe parametry sterowania:

• Częstotliwość skanowania dla każdego bota: jak często Googlebot, GPTBot czy ClaudeBot odwiedzają witrynę i które obszary adresów URL? Dzięki temu widzisz, czy budżet trafia na bezwartościowe strony.
• Wskaźnik crawl-to-refer: stosunek liczby przeskanowanych stron do liczby faktycznie odesłanych odwiedzających mierzy, ile dany bot daje w zamian. Międzynarodowe dane Cloudflare za lipiec 2025 pokazują ogromną rozpiętość: Anthropic skanował około 38 065 stron na jednego odesłanego odwiedzającego, OpenAI około 1091, a Google tylko 5,4. Im wyższa ta wartość, tym gorszy stosunek obciążenia do korzyści.
• Rozkład kodów statusu: jeśli w ruchu botów kumulują się błędy 404 lub 5xx, wskazuje to na marnowanie crawl budgetu lub problemy z serwerem, które obniżają Crawl Capacity Limit.

Na tej podstawie można celowo przekierować budżet: ograniczyć boty o złym stosunku crawl-to-refer i kierować wartościowe crawlery na strategiczne adresy URL. Analiza logów serwera jest więc centralnym narzędziem pomiarowym w zarządzaniu wieloma botami.

Next.js i JavaScript SEO: pamiętaj o budżecie renderowania

Crawl budget ma drugi, często pomijany wymiar: budżet renderowania. Jeśli budujesz treść dopiero po stronie klienta za pomocą JavaScriptu, wymagasz od crawlera drugiego, kosztownego kroku. Google musi przeskanować i wyrenderować stronę, aby zobaczyć treść. Zużywa to dodatkowe zasoby i opóźnia indeksowanie.

Dla nowoczesnej architektury Next.js wynika z tego jasna hierarchia strategii renderowania:

• SSG (Static Site Generation): strony są wstępnie renderowane w momencie budowania (build) i dostarczane jako gotowy HTML. To podejście najbardziej wydajne pod względem skanowania i renderowania, idealne dla stabilnych treści, takich jak artykuły eksperckie czy strony usług.
• ISR (Incremental Static Regeneration): strony statyczne są okresowo generowane na nowo w tle. Łączy wydajność SSG z aktualnością i sprawdza się przy treściach zmieniających się często, ale nie co sekundę.
• SSR (Server-Side Rendering): HTML jest generowany na serwerze przy każdym żądaniu. Crawler otrzymuje kompletny HTML i nie musi niczego renderować sam. Ma to sens w przypadku stron spersonalizowanych lub bardzo dynamicznych.
• CSR (Client-Side Rendering): treść powstaje dopiero w przeglądarce. Dla SEO to najgorszy przypadek, ponieważ podwójnie obciąża crawl budget i budżet renderowania, a zwłaszcza crawlery AI, które często w ogóle nie wykonują JavaScriptu, zostają z niczym.

Praktyczna zasada dla wydajnych pod kątem skanowania witryn B2B brzmi: treści istotne dla indeksowania udostępniaj po stronie serwera lub statycznie, aby każdy crawler znalazł pełną treść bezpośrednio w HTML. Oszczędza to budżet renderowania i sprawia, że treści są dostępne także dla crawlerów AI, które nie widzą JavaScriptu.

Crawlery AI, GEO i monetyzacja: llms.txt i pay-per-crawl

Wraz z obciążeniem generowanym przez crawlery AI pojawia się strategiczne pytanie o korzyść w zamian. W 2026 roku powstają nowe mechanizmy, które są jeszcze młode i niejednolite.

• llms.txt: proponowany plik, który udostępnia systemom AI wyselekcjonowane, dobrze ustrukturyzowane treści w jednym miejscu. Jego popularność jest jednak wciąż niewielka: według Web Almanac 2025 tylko 2,13% witryn w wersji desktop udostępnia prawidłowy plik llms.txt, z czego 39,6% wygenerowano za pomocą wtyczki All in One SEO. Jak dotąd nie stał się on wiążącym standardem.
• Modele pay-per-crawl: rozwiązania, w których dostawcy AI płacą za dostęp do treści, zamiast skanować je za darmo. Odpowiadają właśnie na nierównowagę między dużym obciążeniem skanowaniem a niewielkim ruchem z odesłań, którą ujawniają wskaźniki crawl-to-refer.

W gruncie rzeczy chodzi o wyważenie: z jednej strony widoczność w odpowiedziach AI (GEO), z drugiej koszty serwera i kontrola nad własnymi treściami. Dla firm B2B w Europie, dla których treści eksperckie są kluczowym zasobem, warto podjąć świadomą decyzję dla każdej klasy crawlerów, zamiast bez rozróżnienia wszystko dopuszczać albo blokować.

RODO, zastrzeżenie TDM i wymiar prawny

W regionie DACH (Niemcy, Austria, Szwajcaria) postępowanie z crawlerami AI ma również wymiar prawny. Jest on istotny dla austriackich firm, ponieważ wykracza poza samo sterowanie techniczne.

• Opt-out z trenowania AI: dyrektywami takimi jak blokada Google-Extended lub GPTBota w pliku robots.txt witryna sygnalizuje, że jej treści nie powinny być wykorzystywane do trenowania AI. To techniczna realizacja zastrzeżenia dotyczącego korzystania z treści.
• Zastrzeżenie TDM (eksploracja tekstów i danych): unijne prawo autorskie pozwala podmiotom praw zastrzec w sposób odczytywalny maszynowo, że ich utwory nie mogą być wykorzystywane do komercyjnej eksploracji tekstów i danych. Zastrzeżenie zapisane w pliku robots.txt lub w odczytywalnej maszynowo deklaracji jest podstawą do prawnego wyłączenia trenowania AI.
• Związek z RODO: jeśli publiczne strony zawierają dane osobowe, ich włączenie do korpusów treningowych rodzi pytania z zakresu ochrony danych. Świadome sterowanie crawlerami jest więc częścią rzetelnej zgodności z przepisami.

Kluczowe jest tu połączenie sterowania technicznego i prawnego: plik robots.txt to nie tylko narzędzie do sterowania skanowaniem, ale zarazem dokumentacja woli podmiotu praw. Na potrzeby zgodności z RODO w austriackim kontekście takie sterowanie powinno być świadome i możliwe do prześledzenia, najlepiej uzgodnione z działem prawnym.

Dalsze materiały i podsumowanie

W 2026 roku crawl budget nie jest już tematem wyłącznie dla dużych witryn, lecz problemem wielu botów, który wymaga aktywnego sterowania. Z perspektywy samego Googlebota progi pozostają wysokie, ale różnorodność crawlerów AI, ich różne obciążenie i bardzo zmienna wartość sprawiają, że zróżnicowane zarządzanie ma sens także dla średniej wielkości witryn B2B w Europie.

Priorytety w praktyce są jasne: po pierwsze, wyeliminuj marnowanie crawl budgetu we własnej witrynie dzięki higienie tagów canonical, noindex i pliku robots.txt; po drugie, skonfiguruj zróżnicowany plik robots.txt, który inaczej traktuje wyszukiwarki, crawlery wyszukiwania AI i crawlery treningowe AI; po trzecie, analizuj logi serwera, aby mierzyć częstotliwość skanowania i wskaźniki crawl-to-refer oraz przekierowywać budżet; po czwarte, wybierz architekturę renderowania tak, aby treści były dostępne bez nakładu na renderowanie. Jeśli połączysz te cztery poziomy i uwzględnisz wymiar prawny, zachowasz kontrolę nad własnym serwerem i świadomie zdecydujesz, która treść jest otwarta dla którego bota. Temat możesz pogłębić w powiązanych artykułach o robots.txt, mapach witryny XML, tagach canonical i zarządzaniu crawlerami AI.