Crawl budget: czym jest i jak go optymalizować

W tym poradniku dowiesz się, czym jest crawl budget, kogo naprawdę dotyczy i jak go optymalizować w 9 krokach. Crawl budget to zbiór adresów URL, które Google może i chce przeskanować w danej witrynie. Według Google optymalizacja crawl budgetu ma sens głównie w serwisach z ponad milionem stron albo z ponad 10 000 stron zmienianych codziennie.

Kroki optymalizacji crawl budgetu: sprawdź, czy problem istnieje, przejrzyj Statystyki indeksowania, przeanalizuj logi, zablokuj nieskończone przestrzenie URL, skonsoliduj duplikaty, skróć przekierowania, uporządkuj sitemapę, przyspiesz serwer i skróć ścieżkę do ważnych stron. Progi, nazwy raportów i dokumentacja Google są aktualne na październik 2026.

Przykłady w poradniku pochodzą z audytu bynajmniej.pl z 14.10.2026: crawl Screaming Frog na 441 wewnętrznych URL-ach i URL Inspection w Google Search Console dla 84 URL-i z sitemap. Pełny przebieg tego audytu opisałem w poradniku jak zrobić audyt SEO.

Crawl budget w skrócie: definicja i dwa składniki

Crawl budget (po polsku budżet indeksowania albo budżet crawlowania) to według dokumentacji Google Search Central o zarządzaniu crawl budgetem „zbiór URL-i, które Google może i chce przeskanować”. Google liczy crawl budget osobno dla każdej nazwy hosta, więc www.example.com i sklep.example.com mają osobne budżety.

Crawl budget Google wyznacza z dwóch składników:

• Crawl capacity limit (limit wydajności skanowania) ogranicza łączny czas, przez który serwer trzyma otwarte połączenia dla Google. Limit rośnie, gdy serwer odpowiada szybko i stabilnie, a spada, gdy serwer zwalnia albo zwraca błędy 5xx lub kod 429.
• Crawl demand (zapotrzebowanie na skanowanie) zależy od rozmiaru witryny, częstotliwości aktualizacji, jakości i trafności stron. Dokumentacja Google wymienia trzy czynniki zapotrzebowania: znany Google zbiór URL-i (perceived inventory), popularność adresów w internecie i nieaktualność kopii w indeksie (staleness).

Crawl capacity limit jest wspólny dla wszystkich crawlerów Google, choć każdy crawler, np. Googlebot dla wyszukiwarki i crawler Google Shopping, ma własne zapotrzebowanie. Skanowanie nie oznacza indeksacji: Google pisze, że nie każda przeskanowana strona zostanie zindeksowana.

Crawl budget nie jest czynnikiem rankingowym. Gary Illyes z Google napisał w styczniu 2017 roku na blogu Google Search Central, że skanowanie jest konieczne, żeby strona pojawiła się w wynikach, ale „nie jest sygnałem rankingowym”.

Kogo dotyczy crawl budget

Dokumentacja Google o crawl budgecie wskazuje trzy typy witryn, którym przewodnik jest potrzebny, i zastrzega, że progi są „przybliżone”, a nie dokładne:

Próg miliona stron Gary Illyes powtarzał w podcaście Search Off the Record. Według relacji Search Engine Journal w 2020 roku nazwał milion URL-i „punktem odniesienia”, a w maju 2025 roku powiedział: „milion jest prawdopodobnie w porządku”. Illyes dodał wtedy, że kosztowne zapytania do bazy danych mocno obciążają serwer.

Bynajmniej.pl ma 441 wewnętrznych URL-i w crawlu i 150 indeksowalnych stron HTML, więc według progów Google problemu z crawl budgetem nie ma. Żaden z 84 URL-i z sitemap sprawdzonych w URL Inspection nie miał statusu „Strona wykryta – obecnie niezindeksowana”. Mimo to crawl bynajmniej.pl pokazał adresy, na które Googlebot traci żądania, a mechanizmy marnowania crawla są takie same na małej i dużej stronie, tylko skala jest inna.

Jak optymalizować crawl budget w 9 krokach

Kroki optymalizacji crawl budgetu idą od diagnozy do poprawek:

1. Sprawdź w Google Search Console, czy problem z crawl budgetem w ogóle istnieje.
2. Przejrzyj raport Statystyki indeksowania.
3. Przeanalizuj logi serwera i zweryfikuj Googlebota.
4. Zablokuj nieskończone przestrzenie URL w robots.txt.
5. Skonsoliduj duplikaty i usuń pozorne błędy 404.
6. Skróć przekierowania i napraw linki do błędów 4xx.
7. Uporządkuj sitemapę XML.
8. Przyspiesz serwer i włącz odpowiedzi 304.
9. Skróć ścieżkę kliknięć do ważnych stron.

Krok 1. Sprawdź, czy problem z crawl budgetem istnieje

Raport Indeksowanie stron w Google Search Console pokazuje główny objaw problemu z crawl budgetem: status „Strona wykryta – obecnie niezindeksowana”. Pomoc Google do raportu Indeksowanie stron podaje, że częstą przyczyną tego statusu jest ryzyko przeciążenia witryny, więc Google przełożył skanowanie na później.

Narzędzie do sprawdzania adresów URL w GSC daje drugi objaw: komunikat „Hostload exceeded”. Dokumentacja Google o crawl budgecie wymienia „Hostload exceeded” jako sygnał, że witryna ma problem z dostępnością podczas skanowania.

Status „Strona zeskanowana, ale jeszcze niezindeksowana” nie świadczy o problemie z crawl budgetem, bo Googlebot stronę już pobrał, a decyzja o indeksacji zapadła później. Na bynajmniej.pl taki status mają 2 wpisy z ok. 2008–2009 roku: /optymalizacja-wordpressa/ (ostatni crawl 23.08.2026) i /jak-zdobyc-site/ (02.09.2026). Oba wpisy uważam za problem jakości starej treści, nie budżetu.

Krok 2. Przejrzyj raport Statystyki indeksowania

Raport Statystyki indeksowania znajdziesz w Google Search Console w Ustawieniach. Pomoc Google do raportu Statystyki indeksowania opisuje jego zawartość:

• łączna liczba żądań robota indeksującego, całkowity rozmiar pobierania i średni czas odpowiedzi;
• stan hosta w trzech kategoriach: pobieranie pliku robots.txt, rozpoznawanie nazw DNS i połączenie z serwerem;
• podział żądań według odpowiedzi (200, 301, 404, 5xx), typu pliku (HTML, obrazy, JavaScript, CSS, PDF), celu (Wykrycie albo Odświeżenie) i typu Googlebota (np. Smartfon, Komputer, Obraz).

Raport Statystyki indeksowania Google opisuje jako narzędzie dla zaawansowanych i pisze, że witryny poniżej 1000 stron zwykle go nie potrzebują. W dużym serwisie najpierw patrzę na udział odpowiedzi 3xx i 4xx oraz na stosunek Wykrycia do Odświeżenia, bo pokazują, ile żądań Googlebot wydaje na adresy bez wartości.

Krok 3. Przeanalizuj logi serwera i zweryfikuj Googlebota

Logi serwera pokazują każde żądanie Googlebota, a raport Statystyki indeksowania pokazuje tylko zbiorcze liczby i przykłady. Analiza logów pokazuje, które sekcje Googlebot pomija i ile żądań idzie w parametry i przekierowania.

Screaming Frog Log File Analyser w darmowej wersji wczytuje 1000 zdarzeń logu i jeden projekt, a licencja kosztuje £99 rocznie (cennik Screaming Frog, październik 2026).

Ruch z user agentem Googlebota trzeba zweryfikować, bo user agent łatwo podszyć. Dokumentacja Google o weryfikacji Googlebota podaje dwie metody: odwrotne zapytanie DNS poleceniem host na adres IP z logu (nazwa hosta ma kończyć się na googlebot.com, google.com albo googleusercontent.com) i ponowne zapytanie DNS w przód albo porównanie IP z plikami common-crawlers.json, special-crawlers.json i user-triggered-fetchers.json.

Krok 4. Zablokuj nieskończone przestrzenie URL w robots.txt

Adresy o niskiej wartości Gary Illyes w poście z 2017 roku uszeregował od najbardziej szkodliwych: nawigacja fasetowa i identyfikatory sesji, duplikaty w obrębie witryny, pozorne strony błędów, zhakowane strony, nieskończone przestrzenie URL i proxy, a na końcu treści niskiej jakości i spam.

Nawigację fasetową, czyli filtry w sklepie, Google każe ograniczać przede wszystkim w robots.txt. Dokumentacja Google o nawigacji fasetowej (aktualizacja z 18.12.2025) wyjaśnia, że filtry tworzą nieskończone przestrzenie URL i zabierają crawlerom czas na nowe, przydatne adresy. Google radzi zablokować parametry filtrów regułą Disallow, a filtry w fragmencie # są dla Google neutralne, bo Google zwykle nie używa fragmentów URL. Tag rel="nofollow" działa tylko wtedy, gdy ma go każdy link do filtra, a canonical według Google jest długoterminowo mniej skuteczny niż robots.txt.

Plik robots.txt ma u Google limit 500 KiB i obsługuje dwa symbole wieloznaczne: * (dowolny ciąg znaków) i $ (koniec adresu). Google przechowuje robots.txt w pamięci podręcznej do 24 godzin (dokumentacja robots.txt), więc nowa reguła działa z opóźnieniem.

Krok 5. Skonsoliduj duplikaty i usuń pozorne błędy 404

Duplikaty treści dokumentacja Google o crawl budgecie każe konsolidować, żeby Googlebot skanował oryginały, a nie kolejne kopie tej samej treści. Strony usunięte na stałe powinny zwracać kod 404 albo 410.

Pozorny błąd 404 (soft 404) to strona z komunikatem „nie znaleziono”, która zwraca kod inny niż 404. Google pisze, że pozorne błędy 404 dalej zużywają crawl budget, więc trzeba je wyszukać w raporcie Indeksowanie stron i zamienić na prawdziwy kod 404, 410 albo przekierowanie 301 na odpowiednik.

Krok 6. Skróć przekierowania i napraw linki do błędów 4xx

Długie łańcuchy przekierowań dokumentacja Google o crawl budgecie wymienia wprost jako marnowanie skanowania. Status „Błąd przekierowania” w raporcie Indeksowanie stron obejmuje m.in. zbyt długi łańcuch, pętlę przekierowań i nieprawidłowy adres w łańcuchu.

Na bynajmniej.pl crawl Screaming Frog znalazł 186 wewnętrznych przekierowań 3xx. 61 z nich to łańcuchy z co najmniej dwoma skokami, a 92 kończą się błędem lub brakiem odpowiedzi, np. http://www.bynajmniej.pl/wp-content/uploads/2009/06/kaspar.jpg → 301 → 404. Crawl znalazł też 60 wewnętrznych URL-i z kodem 4xx, głównie obrazki z wpisów z lat 2008–2009, 25 stron z linkami do adresów 4xx lub 5xx i 83 linkowane adresy po HTTP.

Linki w treści bynajmniej.pl do adresów http:// trzeba podmienić na docelowe adresy HTTPS, a linki do usuniętych plików usunąć, zamiast dokładać kolejne przekierowania.

Krok 7. Uporządkuj sitemapę XML

Sitemapa XML powinna zawierać tylko adresy kanoniczne z kodem 200 i prawdziwą datą <lastmod>. Dokumentacja Google o sitemapach podaje, że Google używa <lastmod>, gdy wartość jest „konsekwentnie i weryfikowalnie” dokładna, i ignoruje <priority> oraz <changefreq>. Jeden plik sitemapy mieści 50 000 URL-i albo 50 MB bez kompresji.

Na bynajmniej.pl 2 URL-e z sitemapy nie zwracają 200: /podcast/ i /wordpress-seo/ odpowiadają kodem 301. Adres /wordpress-seo/ ma w URL Inspection status „Błąd przekierowania”, a w sitemapie są też 2 nieindeksowalne URL-e. Z drugiej strony 23 indeksowalne URL-e są poza sitemapą, głównie strony paginacji, np. /page/2/.

Adres /windows-live-writer/ jest w sitemapie bynajmniej.pl, a URL Inspection pokazuje dla niego status „Adres URL jest Google nieznany”. Taki status oznacza, że Google adresu jeszcze nie odkrył, mimo wpisu w sitemapie, więc na małej stronie problemem jest odkrywanie, a nie budżet.

Krok 8. Przyspiesz serwer i włącz odpowiedzi 304

Szybkość serwera bezpośrednio podnosi crawl capacity limit, bo Google zwiększa liczbę połączeń, gdy witryna odpowiada stabilnie. Dokumentacja Google o crawl budgecie zaleca szybsze strony i obsługę kodu 304 (Not Modified), a gdy biznes tego wymaga, dodanie zasobów serwera.

Odpowiedź 304 wymaga walidatorów cache. Dokumentacja crawlerów Google (aktualizacja z 12.06.2026) podaje, że crawlery Google obsługują ETag z If-None-Match oraz Last-Modified z If-Modified-Since, a gdy serwer wysyła oba nagłówki, Google używa ETag.

Walidatory cache są rzadkie: według wpisu Google z 9.12.2024 pobrania, które dało się obsłużyć z pamięci podręcznej, stanowiły 10 lat wcześniej 0,026% wszystkich pobrań, a w 2024 roku 0,017%. Moim zdaniem włączenie ETag to najtańsza poprawka crawla na stronach, których treść rzadko się zmienia.

Bynajmniej.pl ma TTFB ok. 190 ms (mediana 3 prób z Polski) i HTML o wadze 116 KB, ale 10 URL-i odpowiadało w crawlu dłużej niż 1000 ms. Wszystkie 10 wolnych adresów to archiwa tagów i kategorii WordPressa, czyli strony z zapytaniami do bazy danych, o których mówił Illyes. Googlebot pobiera z każdego pliku HTML pierwsze 2 MB po dekompresji (dokumentacja Googlebota), więc HTML na 116 KB mieści się w limicie z zapasem.

Krok 9. Skróć ścieżkę kliknięć do ważnych stron

Popularność URL-a jest jednym z czynników crawl demand, a linki wewnętrzne pokazują Googlebotowi, które strony w witrynie są ważne. Dokumentacja Google o linkach zaleca, żeby każda ważna strona miała link z co najmniej jednej innej strony w witrynie, i opiera skanowanie na linkach <a href>.

Na bynajmniej.pl 45 stron jest na głębokości co najmniej 4 kliknięć od strony głównej, a 77 stron ma wewnętrzne linki nofollow. Wewnętrzny nofollow nie chroni crawl budgetu: według posta Illyesa z 2017 roku Google może przeskanować adres z linkiem nofollow, jeśli prowadzi do niego inny link bez nofollow.

Problemy z crawl budgetem: gdzie je widać i co zrobić

Crawl budget a boty AI

Boty AI nie zużywają crawl budgetu Google, bo crawl budget dotyczy crawlerów Google, a GPTBot, ClaudeBot i PerplexityBot należą do innych firm. Boty AI obciążają jednak ten sam serwer, a wolniejszy serwer według dokumentacji Google obniża crawl capacity limit Googlebota. Wniosek o pośrednim wpływie botów AI na crawl Google jest moją interpretacją, Google takiego zdania nie publikuje.

Skala ruchu botów AI rośnie. Według danych Cloudflare z 29.08.2025 udział GPTBota w ruchu crawlerów AI i wyszukiwarek wzrósł z 4,7% w lipcu 2024 do 11,7% w lipcu 2025, a 79% ruchu crawlerów AI w lipcu 2025 służyło trenowaniu modeli.

Na serwerze z ograniczoną mocą sprawdzam w logach udział botów treningowych i dopiero wtedy decyduję o blokadzie w robots.txt. Blokada botów wyszukiwarek AI, takich jak OAI-SearchBot czy PerplexityBot, odcina stronę od cytowań w ich wyszukiwarkach, więc moim zdaniem nie jest dobrym sposobem na odciążenie serwera. Na bynajmniej.pl robots.txt (Yoast SEO) niczego nie blokuje, również botów AI, a przy TTFB ok. 190 ms nie widzę powodu, żeby to zmieniać.

Czego nie robić z crawl budgetem

Poradniki o crawl budgecie wciąż polecają ustawienia, których Google nie obsługuje albo które wycofał. Moja ulubiona porada to „ustaw limit skanowania w Search Console”: narzędzie Crawl rate limiter Google wyłączył 8 stycznia 2024 roku, więc ta optymalizacja działa mniej więcej tak dobrze jak dyskietka w nowym MacBooku.

• Narzędzie Parametry URL w Search Console Google wycofał w 2022 roku, bo tylko ok. 1% konfiguracji było przydatnych dla skanowania. Parametry kontroluje się w robots.txt.
• Tag noindex nie oszczędza crawl budgetu: Google i tak pobiera stronę, żeby zobaczyć tag, a dokumentacja o crawl budgecie odradza używanie noindex do sterowania skanowaniem.
• Reguła crawl-delay w robots.txt nie działa w Google: dokumentacja robots.txt podaje, że Google jej nie obsługuje.
• Znaczniki <priority> i <changefreq> w sitemapie Google ignoruje.
• Tymczasowa blokada sekcji w robots.txt nie przesuwa crawl budgetu na inne strony, chyba że Google już dobija do limitu wydajności serwera. Zablokowane adresy zostają w kolejce i wracają do skanowania po zdjęciu blokady.
• Kody 500, 503 albo 429 spowalniają Googlebota, ale dokumentacja o zmniejszaniu częstotliwości skanowania pozwala na nie przez kilka godzin, najwyżej 1–2 dni. Dłużej utrzymywane błędy mogą usunąć adresy z indeksu.

FAQ: najczęstsze pytania o crawl budget

Czy crawl budget wpływa na pozycje w Google?

Crawl budget nie wpływa bezpośrednio na pozycje, bo według Google skanowanie „nie jest sygnałem rankingowym”. Crawl budget wpływa pośrednio: strona, której Googlebot nie przeskanuje, nie trafi do indeksu ani do wyników.

Jak sprawdzić crawl budget strony?

Crawl budget sprawdzasz w raporcie Statystyki indeksowania w Ustawieniach Google Search Console i w logach serwera. Objawem problemu jest dużo stron ze statusem „Strona wykryta – obecnie niezindeksowana” w raporcie Indeksowanie stron.

Czy mała strona musi się przejmować crawl budgetem?

Mała strona zwykle nie musi się przejmować crawl budgetem. Google kieruje przewodnik do serwisów z ponad milionem stron albo z ponad 10 000 stron zmienianych codziennie, a w 2017 roku pisał, że witryny poniżej kilku tysięcy URL-i są zwykle skanowane sprawnie.

Jak zwiększyć crawl budget?

Crawl budget zwiększa szybszy i stabilniejszy serwer, bo podnosi limit wydajności skanowania, oraz wyższa jakość i popularność stron, które podnoszą zapotrzebowanie na skanowanie. Google nie przyjmuje próśb o szybsze skanowanie.

Czy noindex oszczędza crawl budget?

Tag noindex nie oszczędza crawl budgetu, bo Googlebot musi pobrać stronę, żeby zobaczyć tag.

Czy boty AI zużywają crawl budget Google?

Boty AI, np. GPTBot czy ClaudeBot, nie zużywają crawl budgetu Google, bo crawl budget dotyczy crawlerów Google. Boty AI obciążają ten sam serwer, a wolny serwer obniża limit, z którym skanuje Googlebot.

Paweł Zinkiewicz

Członek zarządu i współwłaściciel agencji IF.PL, w SEO od ponad 20 lat (m.in. Gazeta.pl, Wirtualna Polska, Polska Press). Na bynajmniej.pl piszę z pomocą AI: temat, dane i testy są moje, AI pomaga ubrać to w słowa.