Crawl budget w 2026: przewodnik techniczny dla e-commerce

Większość tekstów o crawl budgecie w polskim internecie opisuje go tak, jakbyśmy mieli rok 2017: „to liczba podstron, które Google zdąży zaindeksować”. Jeden z artykułów w top10 na frazę „crawl budget” ma wprost w tytule obietnicę „zwiększ crawl budget i zdobywaj wyższe pozycje”. To dwa błędy naraz – i oba Google dementuje w swojej dokumentacji.

W 2026 roku sensowna rozmowa o budżecie indeksowania zaczyna się od jednego zdania Gary’ego Illyesa z Google (Search Off the Record, 2025):

„It’s not crawling that is eating up the resources; it’s indexing and potentially serving or what you are doing with the data – that’s what’s expensive and resource-intensive.”

Innymi słowy: wąskim gardłem nie jest liczba URL-i, tylko wydajność serwera i to, ile z tego, co Google indeksuje, jest realnie warte indeksowania. A w sklepach internetowych, według danych Google z końca 2025 roku, 75% zgłaszanych problemów z nadmiernym indeksowaniem bierze się z dwóch rzeczy: nawigacji fasetowej (50%) i parametrów akcji w URL (25%).

Ten artykuł jest o tym, jak to naprawdę działa, jak zdiagnozować, czy to w ogóle Twój problem, i co z tym zrobić w e-commerce. Nie jest dla każdego – i to napiszę wprost, zamiast straszyć crawl budgetem właściciela sklepu z 300 produktami.

Czym naprawdę jest crawl budget (definicja z 2017 już nie wystarcza)

Crawl budget to zbiór URL-i, które Google może i chce zaindeksować. Google w oficjalnej dokumentacji (developers.google.com/crawling/docs/crawl-budget) rozkłada go na dwa składniki:

Crawl capacity limit (limit wydajności) – maksymalna liczba równoległych połączeń, których Googlebot używa do crawlowania, plus opóźnienie między żądaniami. Rośnie, gdy serwer odpowiada szybko i bez błędów; spada, gdy zwalnia albo sypie kodami 5xx. Jak ujął to Google: „Google ma dużo maszyn, ale nie nieskończenie wiele”.
Crawl demand (popyt na indeksowanie) – jak bardzo Google chce crawlować dany serwis. Napędzają go: postrzegany zasób (perceived inventory), popularność URL-i w internecie oraz „świeżość” (jak często treść realnie się zmienia).

Ważne rozróżnienie, które umyka: „site” w tej definicji to hostname. www.example.com i sklep.example.com mają osobne budżety. Zasoby JS/CSS ładowane z innego hosta zjadają budżet TEGO hosta, nie Twojego.

Co się zmieniło między 2017 a 2026

Sam mechanizm (capacity + demand) jest ten sam od artykułu „What Crawl Budget Means for Googlebot” z 2017 roku. Zmienił się ciężar. Przez lata 2024-2026 Google przesunął cały akcent na obciążenie serwera i koszt wygenerowania odpowiedzi:

W serii „Crawling December” (2024) Google dopisał dokumentację cache’owania HTTP i poprosił wprost o włączanie ETag/Last-Modified oraz odpowiedzi 304 (Not Modified). Powód: odpowiedź 304 bez ciała nie generuje kosztu po stronie serwera i pozwala Googlebotowi crawlować więcej. Illyes podał, że odsetek cache’owalnych fetchy spadł przez dekadę z 0,026% do 0,017% – czyli robimy to coraz gorzej.
Illyes (2025) postawił sprawę jeszcze ostrzej: to kosztowne zapytania do bazy danych, nie sama liczba URL-i, ograniczają crawl. Jego przykład: serwis z 500 tys. podstron robiący drogie zapytania SQL może mieć większy problem z crawlem niż serwis z 2 mln podstron serwujący statyczny, zcache’owany HTML.
Próg „1 mln podstron” pozostał niezmieniony od 2020. Zmieniło się to, że rozmiar strony przestał być głównym kryterium – jest nim wydajność.

Trzecia rzecz, którą Google nazywa „czynnikiem, na który masz największy pozytywny wpływ”, to perceived inventory:

„Bez wskazówek z Twojej strony Google próbuje crawlować wszystkie URL-e, o których wie. Jeśli wiele z nich to duplikaty (…), marnuje mnóstwo czasu Google na crawlowanie.”

To jest sedno całej optymalizacji e-commerce, do którego wrócę w sekcji o sklepach: nie chodzi o to, żeby Google crawlował więcej, tylko żeby przestał marnować budżet na śmieci.

Czy crawl budget to w ogóle Twój problem?

Zanim cokolwiek zoptymalizujesz – sprawdź, czy masz co optymalizować. To pytanie, którego polskie poradniki zwykle nie zadają, bo trudno sprzedać usługę komuś, komu powiesz „nie martw się tym”.

Google w dokumentacji podaje, że przewodnik o crawl budgecie jest przeznaczony przede wszystkim dla:

dużych serwisów (1 mln+ unikalnych podstron) z treścią zmieniającą się mniej więcej raz w tygodniu,
średnich i większych serwisów (10 tys.+ podstron) z treścią zmieniającą się bardzo szybko (codziennie),
serwisów, w których duża część URL-i ma w Search Console status „Discovered – currently not indexed” („Wykryta – obecnie niezaindeksowana”).

I dodaje wprost: „Jeśli Twój serwis nie ma dużej liczby szybko zmieniających się podstron albo Twoje strony są indeksowane tego samego dnia, którego je publikujesz – nie musisz czytać tego przewodnika.” Raport Statystyki indeksowania Google opatruje uwagą: „Jeśli masz mniej niż tysiąc podstron, ten raport nie jest Ci potrzebny.”

Nazwiska w Google mówią to samo. John Mueller:
„Moim zdaniem crawl budget jest przeceniany. Większość stron nigdy nie musi się tym przejmować.” Illyes:
„ponad 90% stron w internecie nie musi się tym martwić”.

Prosty test: czy to Twój problem

Zadaj sobie trzy pytania po kolei:

Czy serwis ma realnie ponad ~10 tys. wartościowych URL-i (albo 1 mln+ przy wolnej rotacji treści)? Jeśli nie – to prawie na pewno nie crawl budget. Szukaj przyczyny gdzie indziej (jakość, linkowanie, duplikacja).
Czy nowe strony indeksują się tego samego dnia, którego je publikujesz? Jeśli tak – budżet Ci wystarcza, temat zamknięty.
Czy w GSC rośnie pula „Discovered – currently not indexed” mimo dobrego linkowania wewnętrznego i obecności w sitemapie? Dopiero tu zaczyna się realna diagnostyka.

Jeżeli odpadłeś na 1 lub 2 – zamknij ten artykuł i zajmij się treścią. Jeśli doszedłeś do 3 – czytaj dalej, bo teraz trzeba odróżnić prawdziwy problem od udawanego.

Diagnoza: jak odróżnić realny crawl budget od udawanego

Najczęstszy błąd w diagnostyce to pomylenie dwóch zupełnie różnych statusów z Search Console. Wyglądają podobnie, a znaczą co innego i wymagają innego leczenia.

„Crawled – currently not indexed” (Zindeksowana, obecnie niezaindeksowana) to zwykle problem jakości lub duplikacji, nie budżetu. Google URL crawlnął, ale zdecydował go nie indeksować. Illyes (SERP Conf 2024): „eliminacja duplikatów to jedna z tych rzeczy (…) istnieje już wersja tego albo bardzo podobna. I ogólna jakość serwisu potrafi mieć duże znaczenie.” Zwiększanie crawl budgetu nic tu nie da.

„Discovered – currently not indexed” (Wykryta, obecnie niezaindeksowana) to sytuacja, w której Google zna URL, ale go jeszcze nie crawlnął. Przy dużej skali, wolnym serwerze albo słabym hostingu to bywa realny sygnał ograniczenia budżetu.

Reguła interpretacyjna:

Crawlowane, ale nieindeksowane → problem jakości/duplikacji. Nie budżet.
Wykryte, nigdy nie crawlowane mimo dobrych linków i sitemapy → prawdopodobnie budżet/obciążenie hosta.

GSC Crawl Stats – co konkretnie czytać

Raport jest w Ustawieniach (tylko dla properties na poziomie domeny), obejmuje 90 dni i – jak zaznacza Google – jest „dla zaawansowanych”. Na co patrzeć:

Total crawl requests – spadek przy jednoczesnym dodawaniu treści to sygnał ostrzegawczy. Nagły spadek często oznacza świeżą, zbyt szeroką regułę w robots.txt albo wolny serwer.
Average response time – im niżej, tym lepiej. Wolne odpowiedzi obniżają crawl capacity.
Host status – gdy liczba żądań przebija czerwoną linię limitu, wejdź w URL-e, które padają. Status „Hostload exceeded” w URL Inspection oznacza wprost: Googlebot nie daje rady crawlować tylu URL-i, ile wykrył.
By response – dużo 4xx/5xx albo dominacja odpowiedzi 200, które nie są HTML-em (pliki, śmieci parametrowe), to kłopot.
By purpose (Discovery vs Refresh) – to jeden z najlepszych sygnałów. Jeśli Google przepala budżet na Refresh śmieciowych URL-i parametrowych, zamiast na Discovery Twoich nowych, ważnych stron – masz zdiagnozowane, gdzie ucieka budżet.

Uwaga techniczna: w tym raporcie dane NIE są przypisywane do kanonicznych (inaczej niż w pozostałych raportach). Każdy skok w łańcuchu przekierowań liczy się osobno.

Logi serwera to jedyny ostateczny dowód

GSC pokazuje agregaty. Prawdę pokazują logi. Dopiero zestawienie „co crawler wykrył” z „na co Googlebot realnie wydaje żądania” rozstrzyga sprawę. Powtarzalny obraz z praktyki: crawler znajduje setki tysięcy URL-i, a logi pokazują, że Googlebot większość żądań przepala na małym rdzeniu plus jednym klastrze śmieci generowanym przez parametry.

Narzędzia: Screaming Frog Log File Analyser, stack ELK/Elastic, Botify, OnCrawl/Lumar, JetOctopus. Przy okazji: Screaming Froga można puścić z user-agentem GPTBota albo PerplexityBota i zobaczyć, co realnie widzą crawlery AI (do tego wrócę).

Crawl budget kontra „render budget”

Przy serwisach opartych na JavaScript pojawia się drugie wąskie gardło. Google indeksuje JS w dwóch falach: najpierw pobiera i parsuje HTML, potem – w osobnej, kolejkowanej fazie – renderuje stronę w Web Rendering Service (WRS). To renderowanie potrafi się opóźnić od minut do tygodni.

Trzy rzeczy warto wiedzieć:

Renderowanie zjada budżet hosta.
Żeby wyrenderować stronę, WRS musi pobrać osadzone pliki JS/CSS/XHR – a każde takie pobranie liczy się do budżetu tego hosta. Mueller potwierdza: intensywne renderowanie może realnie ograniczać crawl budget. Lekarstwo: mniej zasobów, SSR/SSG. WRS cache’uje zasoby do 30 dni, właśnie po to, żeby chronić budżet.
Googlebot pobiera maksymalnie pierwsze 2 MB każdego URL-a.
Google doprecyzował to w dokumentacji na przełomie lutego i marca 2026 (post „Inside Googlebot”): Googlebot pobiera pierwsze 2 MB dowolnego zasobu, wliczając nagłówek HTTP (dla PDF – 64 MB; dla crawlerów bez zadeklarowanego limitu domyślnie 15 MB). Jeśli plik HTML jest większy, Googlebot go nie odrzuca – ucina pobieranie dokładnie na progu 2 MB, a bajty powyżej ignoruje w całości, przekazując pobrany fragment do indeksowania i WRS tak, jakby to był kompletny plik. Każdy zasób ma własny, osobny licznik bajtów. Google podkreśla, że to doprecyzowanie dokumentacji, nie zmiana zachowania (Mueller: „nic z tego się ostatnio nie zmieniło – chcieliśmy to tylko dokładniej udokumentować”) – mimo że część mediów opisała to błędnie jako „obcięcie limitu z 15 MB do 2 MB”.
Praktyczny wniosek dla e-commerce: mediana strony mobilnej to już ~2,5 MB (HTTP Archive 2025), więc ciężka karta produktu potrafi wypchnąć <title>, link kanoniczny i dane strukturalne (JSON-LD) poza próg 2 MB – a wtedy Google ich nie zobaczy. Krytyczne elementy sekcji <head> trzymaj na początku dokumentu.
„Render budget” i próg „5 MB / 5 s” to terminy środowiskowe, nie Google.
Sama koncepcja „render budget” oraz krążący próg „5 MB / 5 sekund” na abort renderowania to inferencje społeczności, nie potwierdzone przez Google liczby – i nie myl ich z oficjalnym limitem 2 MB na pobranie z punktu wyżej. Warto znać, ale nie sprzedawaj jako pewnika – to zresztą jedna z rzeczy, które odróżniają rzetelną diagnozę od agencyjnej ściemy.

Więcej o tej warstwie w moim empirycznym badaniu wzorców JavaScript w erze botów LLM.

E-commerce: gdzie realnie ucieka budżet (75% to dwie rzeczy)

Tu robi się konkretnie. Illyes w podsumowaniu problemów crawlowych zgłaszanych Google (Search Off the Record, raport końcowy 2025, wyemitowany na początku 2026) podał rozkład:

Źródło problemu	Udział
Nawigacja fasetowa (filtry)	50%
Parametry akcji (np. `?add_to_cart=`)	25%
Parametry nieistotne (sesje, UTM)	10%
Wtyczki/widżety	5%
„Dziwne rzeczy” (np. podwójnie zakodowane URL-e)	2%

Trzy czwarte problemu to filtry i parametry akcji. I – co kluczowe – Illyes zwraca uwagę na pułapkę: „Gdy Google wykryje zbiór URL-i, nie może zdecydować, czy ta przestrzeń jest dobra, dopóki nie crawlnie sporego jej kawałka”. Zanim to zrobi, serwis może być już scrawlowany na śmierć.

Nawigacja fasetowa – najczęstsze źródło overcrawlu

Każda kombinacja filtrów to zwykle osobny URL. Kolor x rozmiar x marka x sortowanie x cena = praktycznie nieskończona liczba URL-i z ograniczonej liczby produktów. Google dzieli poradę na dwa przypadki:

Jeśli NIE potrzebujesz indeksowania URL-i filtrowanych (najczęstszy przypadek): zablokuj je w robots.txt. Google mówi wprost – „często nie ma dobrego powodu, żeby pozwalać na crawlowanie filtrowanych elementów”. Pozwól crawlować pojedyncze karty produktu i jedną dedykowaną stronę listingu bez filtrów.

Jeśli filtry MAJĄ być indeksowane (np. „buty do biegania męskie” jako realne zapytanie):

używaj standardowego separatora & (nie przecinków, średników, nawiasów – Illyes: „???? to nie jest dobry znak separatora parametru”),
trzymaj stałą kolejność filtrów w URL i blokuj duplikaty filtrów,
dla kombinacji bez wyników zwracaj 404, nie przekierowanie do generycznej strony „nie znaleziono”,
konsoliduj warianty linkiem kanonicznym (działa wolno),
pamiętaj, że rel="nofollow" na linkach filtrów nie blokuje crawlowania – blokuje je tylko disallow w robots.txt, i to pod warunkiem, że nofollow jest na KAŻDYM linku, wewnętrznym i zewnętrznym.

Parametry akcji – drugie 25%

To parametry, które wyzwalają akcję zamiast zmieniać treść: ?add_to_cart=true, ?add_to_wishlist=true. Google zgłosił kiedyś wręcz błąd przeciwko WooCommerce o parametry dodawania do koszyka – i WooCommerce to naprawił. Jeśli Twój sklep generuje crawlowalne linki akcji, blokujesz je w robots.txt. Szerzej o obsłudze parametrów w kompletnym przewodniku po parametrach w URL.

Reszta pułapek e-commerce

Warianty produktu – kanoniczny odsyłający do głównego URL produktu; w sitemapie tylko kanoniczne.
Out-of-stock – kategoria pusta na stałe → 404; produkt chwilowo niedostępny → zostaw stronę; produkt zniknął na dobre → 404/410.
Paginacja – rel="next"/"prev" Google już nie obsługuje (wycofane). Używaj crawlowalnych linków <a href> do kolejnych stron, spójnego ?page= i self-canonical na każdej stronie paginacji.
Linki wewnętrzne muszą być realnymi <a href>. Googlebot może nie wykryć nawigacji opartej wyłącznie na JavaScript (onClick). To brzmi banalnie, a wywala indeksację całych kategorii w headless commerce.
Identyfikatory sesji i nieskończone przestrzenie – URL-e ze zmiennym timestampem albo session ID sprawiają, że Google „myśli, że masz nieskończoną liczbę stron”.

Case: kiedy optymalizacja nie wystarcza – trzeba zmienić architekturę

Teoria teorią, ale najlepiej to widać na liczbach. Zrobiłem migrację serwisu z ~20 tys. podstron z WordPressa na Nuxt + Vercel. Stan wyjściowy był podręcznikowym przykładem problemu, który Illyes opisuje słowami „to nie crawl, to serwer”:

Serwer zwracał 200 OK, ale logi pokazywały błędy 499 (Client Closed Request). Googlebot wysyłał żądanie, PHP mielił odpowiedź 1500-2000 ms, a bot zrywał połączenie, zanim ją dostał.
TTFB dla Googlebota: ~850-1200 ms. Przy tysiącach podstron to zabójstwo crawl capacity.
Efekt: z ~20 tys. podstron zaindeksowana było tylko około 1 tys.

Nie było tu żadnego „sztuczki na crawl budget” do zrobienia. Problemem była architektura – generowanie każdej strony na żądanie przez PHP + bazę. Rozwiązanie: SSG dla artykułów (statyczny HTML), SSR tam, gdzie potrzebna logika, ISR dla dynamiki. Po migracji:

TTFB spadł do ~150 ms, każdy adres serwuje się w kilkadziesiąt milisekund niezależnie od wieku treści,
błędy 499 zniknęły (0),
crawl requests wzrosły około dwukrotnie,
indeksacja odblokowała się do ~16 tys. podstron w ciągu tygodnia, a czas indeksacji nowych stron radykalnie się skrócił.
efekt biznesowy: to ~20% wzrost kliknięć i wielokrotny wzrost wyświetleń

Wniosek, który powtarzam klientom: optymalizacja ma swoje granice. Czasem trzeba zmienić architekturę. Crawl budget to często nie jest problem SEO do rozwiązania dyrektywami – to problem inżynierii serwera.

Ten sam wzorzec widzę teraz na żywym projekcie migracyjnym dużego sklepu e-commerce (szczegóły objęte NDA), gdzie filtry generują rzędy wielkości więcej URL-i niż jest realnych produktów. Tam kolejność jest odwrotna niż w typowym poradniku: najpierw odcinamy przestrzeń faset i parametrów akcji, żeby Google w ogóle dotarł do kart produktu, dopiero potem walczymy o świeżość.

Optymalizacja: kolejność działań i najdroższy błąd

Kolejność ma znaczenie, bo większość ludzi zaczyna od końca (bawi się dyrektywami), zamiast od początku (naprawia serwer).

Najpierw zdrowie hosta i szybkość serwera. Szybkie, bezbłędne odpowiedzi podnoszą crawl capacity. Optymalizuj zapytania do bazy, włącz cache (ETag/Last-Modified/304), dołóż CDN, obetnij TTFB. To akcent lat 2024-2026 i – jak w case wyżej – często jedyne, co realnie zmienia liczby.
Potem tnij perceived inventory (te 75% z faset i parametrów akcji). Konsoliduj duplikaty, blokuj bezużyteczne przestrzenie URL w robots.txt, zwracaj 404/410 dla trwale usuniętych stron.
Dopiero potem jakość i linkowanie wewnętrzne. Wartość i unikalność treści, płytka głębokość kliknięć, realne linki <a href>.
Na końcu higiena sitemapy – tylko kanoniczne URL-e, poprawny <lastmod>. Więcej w przewodniku o sitemapie XML.

robots.txt kontra noindex kontra canonical

To, co ludzie mylą najczęściej. Każde z tych narzędzi robi co innego:

Narzędzie	Co robi	Czego NIE robi
robots.txt disallow	Jedyny sposób, żeby realnie zablokować CRAWLOWANIE. URL-e zablokowane nie obciążają budżetu.	Nie usuwa z indeksu (URL może zostać jako „goły” wpis z linków zewnętrznych)
noindex	Usuwa stronę z INDEKSU	Nie oszczędza budżetu – Google musi stronę crawlnąć, żeby zobaczyć noindex
canonical	Konsoliduje sygnały indeksowania do wersji głównej	Nie blokuje crawlowania

Najdroższy błąd eksperta: robots.txt + noindex naraz

To najczęstsza kosztowna pomyłka, jaką widzę. Jeśli chcesz usunąć stronę z indeksu, ale jednocześnie zablokujesz ją w robots.txt – Google nie może jej crawlować, więc nigdy nie zobaczy dyrektywy noindex. Strona zostaje w indeksie (często jako goły URL), a Ty jesteś przekonany, że ją usunąłeś.

Reguła, którą warto wykuć na blachę:

Chcesz usunąć z indeksu → pozwól crawlować + noindex. Bez blokady w robots.txt.
Chcesz zatrzymać crawlowanie bezużytecznej przestrzeni → robots.txt disallow. Bez noindexu.

Nie stosuj obu naraz na tym samym URL. To nie jest „podwójne zabezpieczenie”, to wzajemne wykluczenie.

Rzeczy, o które pytają, a których się nie robi

URL Parameters tool w GSC nie istnieje.
Google wycofał je 26 kwietnia 2022 (uzasadnienie: tylko ~1% konfiguracji było przydatne). Jeśli ktoś odsyła Cię do tego narzędzia – pracuje na wiedzy sprzed lat. Obsługę parametrów robisz dziś przez robots.txt i lepszą strukturę URL w CMS.
crawl-delay w robots.txt Googlebot ignoruje.
„Niestandardowa reguła crawl-delay nie jest przetwarzana przez crawlery Google” (Bing i Yandex ją respektują). Żeby spowolnić Googlebota, użyj limitowania w GSC albo zwracaj 503/429.
Kody 4xx nie marnują budżetu (z wyjątkiem 429).
404/410 to mocny sygnał „nie crawluj tego znowu”. URL zablokowany w robots.txt zostaje w kolejce znacznie dłużej.
noindex nie oszczędza budżetu w krótkim terminie – dopiero długofalowo, usuwając URL z indeksu, przekierowuje uwagę crawlera gdzie indziej.

Crawl budget a boty AI w 2026

To temat, w którym poradniki albo panikują, albo milczą – a odpowiedź jest niuansowa. Mówiłem o tym już w kontekście „budżet jest dzielony między wszystkie boty”, ale 2026 dokłada do tego crawlery modeli językowych.

Fakt pierwszy: crawlery AI (GPTBot, ClaudeBot, PerplexityBot, Bytespider i reszta) NIE zjadają crawl budgetu Googlebota. To osobne systemy.

Fakt drugi: ale zjadają realną wydajność Twojego serwera. A ponieważ crawl capacity Googlebota SPADA, gdy serwer zwalnia albo sypie błędami, ciężka nawała botów AI może pośrednio zdławić Googlebota. To nie teoria – w case migracji wyżej widziałem to na logach: gdy PHP dławiło się przy Googlebocie, GPTBot i ClaudeBot dostawały dokładnie te same błędy 499. Wąskim gardłem był serwer, a dla serwera wszystkie boty to jedno obciążenie.

Skala robi się poważna. Dane Cloudflare (2025):

boty przegoniły ludzi – 57,5% ruchu HTML jest zautomatyzowane,
crawlery AI to ~20% ruchu zweryfikowanych botów; udział GPTBota urósł z 4,7% (lipiec 2024) do 11,7% (lipiec 2025),
ponad 50% ruchu crawlerów AI to ponowne pobieranie niezmienionych stron – czysty narzut, który obcięłoby cache’owanie HTTP i odpowiedzi 304,
dysproporcja crawl-do-referral jest ogromna: Google przysyła jeden klik na ~14 pobrań, OpenAI na ~1700, Anthropic na ~73 000. Crawlery AI biorą znacznie więcej, niż oddają.

Jak tym zarządzać

robots.txt per user-agent – wylistuj konkretne tokeny (GPTBot, ClaudeBot, CCBot, Google-Extended, Bytespider). Działa tylko dla botów, które go respektują.
WAF / Cloudflare – Cloudflare od lipca 2025 domyślnie blokuje crawlery AI na nowych domenach i oferuje kontrolę wg celu (Search / Agent / Training) na wszystkich planach. To realne narzędzie, bo egzekwuje blokadę niezależnie od dobrej woli bota (Cloudflare udokumentował, że Perplexity potrafił omijać robots.txt podszywając się pod przeglądarkę).
Strategia: blokuj boty treningowe, przepuszczaj wyszukiwawcze. GPTBot (trening) blokujesz, OAI-SearchBot (wyszukiwarka, przysyła ruch) przepuszczasz. Analogicznie ClaudeBot vs boty odpowiadające na zapytania użytkownika. Blokujesz darmowe zbieranie danych treningowych, zachowując widoczność w wyszukiwaniu AI.

Jedno wykluczenie: Google-Extended to nie osobny crawler. To token opt-out z treningu AI. Googlebot dwoi się do Search i do funkcji AI (AI Overviews, Gemini), więc blokada Google-Extended NIE usuwa Cię z wyszukiwarki.

llms.txt – nie sprzedawaj tego jako dźwigni

Skoro o botach AI: Google nie używa llms.txt. Illyes (Search Central Live, lipiec 2025) powiedział wprost, że Google tego nie wspiera i nie planuje. Mueller porównał to do „zdyskredytowanego meta tagu keywords” – samodeklarowanego, łatwego do oszukania sygnału. Gdy llms.txt pojawił się na chwilę w dokumentacji Google (grudzień 2025), Mueller wyjaśnił, że to nie było poparcie, i plik usunięto. Duże badania na logach (setki tysięcy domen) nie znalazły korelacji llms.txt z cytowaniami w AI. Ma wąskie zastosowanie dla asystentów kodowania czytających dokumentację – nie jako dźwignia crawl budgetu ani rankingu.

Mity, które wciąż powtarzają „eksperci”

Google ma osobną stronę „Myths and facts about crawling” (developers.google.com/crawling/docs/myths-about-crawling). Warto przez nią przejść, bo połowa polskich poradników sprzedaje te mity jako porady.

„Crawl budget to czynnik rankingowy.”
FAŁSZ, i to najgroźniejszy. Google: „Poprawa tempa crawlowania niekoniecznie prowadzi do lepszych pozycji. (…) crawlowanie jest konieczne, żeby strona była w wynikach, ale nie jest sygnałem rankingowym.” Artykuł z top10, który obiecuje „zwiększ crawl budget i zdobywaj wyższe pozycje”, sprzedaje dokładnie ten mit.
„Sitemapa (albo jej kompresja) zwiększa budżet.”
FAŁSZ. „Spakowane sitemapy i tak trzeba pobrać z serwera, więc nie oszczędzasz czasu crawlowania.” Sitemapa pomaga w discovery, nie w budżecie.
„crawl-delay działa dla Google.”
FAŁSZ (patrz wyżej).
„noindex oszczędza budżet.”
W większości FAŁSZ – Google musi crawlnąć stronę, żeby zobaczyć noindex.
„Szybszy serwis = zawsze więcej crawlowania.”
CZĘŚCIOWO. Szybszy serwer pozwala crawlować więcej, ale Google i tak poświęci więcej czasu serwisowi z ważniejszą treścią, nawet jeśli wolniejszemu. Przyspieszenie słabych jakościowo stron nie kupi więcej crawlowania.
„Małe serwisy są crawlowane rzadziej.”
FAŁSZ. „Jeśli serwis ma ważną treść, która często się zmienia, crawlujemy go często – niezależnie od rozmiaru.”
„Google woli świeższą treść, więc podkręcaj daty.”
FAŁSZ. Treść jest oceniana wg jakości, nie wieku; sztuczne odświeżanie dat nie daje wartości.
„Usunięcie z sitemapy zatrzymuje crawlowanie.”
FAŁSZ. Google nie zapomni znanych URL-i. Chcesz zatrzymać – 404/410 albo robots.txt.

Wspólny mianownik tych mitów to mylenie crawlowania z indeksowaniem i indeksowania z rankingiem. To trzy różne rzeczy, na trzech różnych etapach – i większość „porad o crawl budgecie” ślizga się między nimi, nie zauważając różnicy.

Podsumowanie: architektura, nie sztuczki

Crawl budget w 2026 sprowadza się do trzech zdań:

Dla ponad 90% stron to nie jest problem. Jeśli masz mniej niż ~10 tys. wartościowych URL-i i indeksujesz się tego samego dnia – zajmij się treścią.
Jeśli to jest Twój problem, prawie zawsze siedzi w serwerze albo w perceived inventory – wolne odpowiedzi, drogie zapytania do bazy, i 75% śmieci z faset i parametrów akcji w e-commerce. Nie w dyrektywach.
Największe efekty daje inżynieria, nie SEO-sztuczki – szybki serwer, cache, odcięcie nieskończonych przestrzeni URL, a czasem zmiana architektury renderowania.

Jeśli podejrzewasz, że w Twoim sklepie Google przepala budżet na filtry i parametry, zamiast docierać do kart produktu – to jest dokładnie ten typ problemu, który diagnozuję w audycie technicznym SEO: logi serwera, GSC Crawl Stats, mapa przestrzeni URL i konkretna lista, co zablokować, co skonsolidować, a co przepisać architektonicznie.

Źródła pierwotne: dokumentacja Google (developers.google.com/crawling), seria „Crawling December” 2024, „Inside Googlebot” 2026, wypowiedzi Gary’ego Illyesa i Johna Muellera (Search Off the Record, Search Central Live), dane Cloudflare Radar 2025. Twierdzenia oznaczone w tekście jako środowiskowe (np. „render budget”, próg „5 MB / 5 s”) nie są oficjalnym stanowiskiem Google.

Crawl budget w 2026: przewodnik techniczny dla e-commerce