Crawl budget – co to jest i kiedy warto go optymalizować?

Crawl budget (budżet indeksowania) to zestaw adresów URL, które Googlebot może i chce pobrać z Twojej witryny w danym czasie. Wynika z dwóch rzeczy: limitu wydajności indeksowania (ile Twój serwer „uniesie”) oraz zapotrzebowania na indeksowanie (jak bardzo Google chce Twoje strony odwiedzać). Realnie martwić się nim muszą duże i szybko zmieniające się serwisy – przy typowej stronie firmowej czy blogu wystarczy aktualna mapa witryny i zaglądanie do raportów w Search Console.

W świecie SEO można natknąć się na wiele technicznych pojęć, które z pozoru brzmią skomplikowanie, ale po rozłożeniu na czynniki pierwsze okazują się całkiem zrozumiałe. Jednym z nich jest Crawl Budget. Poniżej wyjaśniam, jak działa według aktualnej dokumentacji Google (stan na październik 2026 r.), kogo naprawdę dotyczy, co go marnuje, jak go sprawdzić i które popularne „porady” są mitami.

Czym jest Crawl Budget?

Internet jest praktycznie nieskończony, więc Google nie jest w stanie regularnie odwiedzać każdego publicznie dostępnego adresu URL. Czas i zasoby, które może poświęcić jednej witrynie, są ograniczone – i właśnie ten przydział nazywa się budżetem indeksowania. Google definiuje go jako „zestaw adresów URL, które Googlebot może i zamierza zindeksować”.

Mała uwaga językowa: polska dokumentacja Google tłumaczy crawling jako „indeksowanie”, choć technicznie to dwa różne etapy. Crawling to pobranie strony przez robota, a indeksacja to późniejsza decyzja, czy strona trafi do indeksu. Nie każda pobrana strona zostaje zindeksowana – po pobraniu Google ją ocenia, konsoliduje z duplikatami i dopiero wtedy decyduje. Crawl budget nie decyduje więc o tym, co trafi do indeksu, tylko o tym, co Google w ogóle zdąży obejrzeć.

Ważny szczegół: budżet liczony jest dla nazwy hosta. Dla Google www.example.com i sklep.example.com to osobne witryny z osobnymi budżetami.

Historia pojęcia

Termin „crawl budget” krążył w środowisku SEO na długo przed tym, zanim Google się do niego odniosło. Używano go jako umownej nazwy dla mechanizmów ograniczających pracę botów. Oficjalne wyjaśnienie pojawiło się 16 stycznia 2017 roku na blogu Google (wpis „What Crawl Budget Means for Googlebot”). Google opisało wtedy dwa składniki: crawl rate limit i crawl demand.

Dziś temat ma osobny przewodnik „Optymalizacja budżetu indeksowania” (Optimize your crawl budget). W grudniu 2025 r. Google przeniósł go razem z innymi dokumentami o crawlowaniu z Search Central do osobnego serwisu o infrastrukturze crawlowania: developers.google.com/crawling/docs/crawl-budget. To sygnał, że te zasady dotyczą nie tylko wyszukiwarki, ale wszystkich robotów Google.

Crawl rate limit – co to jest?

Crawl rate limit to stara nazwa limitu wydajności indeksowania, czyli górnej granicy tego, jak intensywnie Googlebot może pobierać strony z Twojego serwera, nie spowalniając go. Dziś Google nazywa go crawl capacity limit (albo hostload). Limit nie jest stały – rośnie, gdy serwer odpowiada szybko i stabilnie, a spada, gdy pojawiają się błędy 5xx, kod 429 albo wolne odpowiedzi. Nie da się go ustawić ręcznie (więcej o tym w sekcji o ograniczaniu crawlingu niżej).

Elementy Crawl Budget

Google wyróżnia dwie główne składowe wpływające na crawl budget:

• Limit wydajności indeksowania (crawl capacity limit, dawniej crawl rate limit, nazywany też hostload): określa, jak długo Twój serwer może utrzymywać otwarte połączenia z robotami Google – liczy się zarówno liczba równoległych połączeń, jak i czas ich trwania. Każda witryna startuje z tym samym, ostrożnym limitem. Jeśli serwer odpowiada stabilnie, a czasy odpowiedzi (w tym czas do pierwszego bajtu) się nie pogarszają, limit rośnie. Gdy serwer zwalnia, zwraca błędy 5xx albo kod 429, limit spada i Google pobiera mniej. Ten limit jest wspólny dla wszystkich robotów Google, więc duży apetyt jednego (np. AdsBota) może zmniejszyć pulę dla pozostałych.
• Zapotrzebowanie na indeksowanie (crawl demand): to „chęć” robota, by odwiedzać Twoje adresy – w odróżnieniu od limitu wydajności każdy robot Google ma własne zapotrzebowanie. W przypadku Googlebota zależy ono od rozmiaru witryny, częstotliwości aktualizacji, jakości i trafności stron. Google wymienia trzy czynniki, na które masz wpływ: domniemane zasoby (wszystkie znane Google adresy URL – jeśli wiele z nich to duplikaty lub śmieci, robot traci na nie czas; tu masz największą kontrolę), popularność (popularne adresy są odwiedzane częściej) oraz aktualność (Google wraca, żeby wychwycić zmiany). Zapotrzebowanie rośnie też chwilowo przy zdarzeniach obejmujących całą witrynę, np. przenosinach na nową domenę.

Sumując: nawet jeśli serwer wytrzymałby więcej, przy niskim zapotrzebowaniu Google będzie odwiedzać witrynę rzadziej. I odwrotnie – duże zapotrzebowanie nie pomoże, jeśli serwer nie nadąża.

	Limit wydajności (crawl capacity limit)	Zapotrzebowanie (crawl demand)
Pytanie, na które odpowiada	Ile Google może pobrać bez przeciążania serwera?	Ile Google chce pobrać?
Od czego zależy	Szybkość i stabilność odpowiedzi serwera, błędy 5xx, kod 429, zasoby Google	Liczba znanych adresów (i ich jakość), popularność, aktualność, zdarzenia typu migracja
Wspólny dla robotów?	Tak – jedna pula dla wszystkich robotów Google	Nie – każdy robot ma własne
Jak go poprawić	Szybszy, stabilniejszy serwer, mniej błędów	Mniej duplikatów i śmieciowych adresów, lepsza jakość treści

Kogo dotyczy crawl budget?

Dobra wiadomość jest taka, że większość stron internetowych – witryny firm lokalnych, blogi branżowe czy sklepy z ograniczonym asortymentem – nie musi się budżetem indeksowania przejmować. Google pisze wprost, że jeśli Twoje strony są pobierane w dniu publikacji, nie musisz czytać przewodnika o crawl budgecie. W pomocy Search Console dla raportu Statystyki indeksowania pada też próg: przy witrynie mającej mniej niż 1000 stron najprawdopodobniej nie musisz się tym poziomem szczegółów zajmować.

Przewodnik Google jest skierowany głównie do:

• dużych witryn (ponad milion unikalnych stron), których treść zmienia się mniej więcej raz w tygodniu,
• średnich i większych witryn (ponad 10 tys. unikalnych stron), których treść zmienia się codziennie,
• witryn, w których duża część adresów ma w Search Console status „Strona wykryta – obecnie niezindeksowana”.

Google zaznacza, że to wartości orientacyjne, a nie sztywne progi. Z mojego doświadczenia problem pojawia się wcześniej tam, gdzie liczba „technicznych” adresów rośnie lawinowo – w sklepach z filtrami, serwisach ogłoszeniowych czy portalach z kalendarzami wydarzeń. Wtedy znaczenia nabierają struktura wewnętrzna, przekierowania, plik robots.txt i jakość odpowiedzi serwera.

Szacowanie Crawl Budget

Nie istnieje jeden wskaźnik pokazujący „crawl budget” w postaci liczby. Można go jednak oszacować, analizując dane z Google Search Console i logi serwera. W raporcie Statystyki indeksowania zobaczysz m.in. łączną liczbę żądań Googlebota, ilość pobranych danych i średni czas odpowiedzi serwera. Na tej podstawie widać, jak często Google wraca do witryny i czy coś się zmienia. Jeszcze dokładniejszy obraz dają logi serwera – porównując wizyty Googlebota z listą adresów, które faktycznie chcesz mieć w Google, sprawdzisz, ile budżetu idzie na ważne strony, a ile na parametry, duplikaty i błędy.

Co wpływa na zużycie crawl budgetu?

Ogólna zasada Google brzmi: generalnie każdy adres URL, który Googlebot pobiera, wlicza się do budżetu. Najczęściej marnują go:

• Parametry URL i nawigacja fasetowa: filtry, sortowania i ich kombinacje (np. ?kolor=zielony&rozmiar=s&sort=cena) potrafią wygenerować praktycznie nieskończoną liczbę adresów. Robot nie wie, czy są wartościowe, dopóki ich nie pobierze, więc pobiera ich mnóstwo – a na nowe, ważne strony zostaje mniej czasu. Podobnie działają kalendarze z osobnym adresem dla każdej daty.
• Powielone i mało wartościowe treści: duplikaty (wersje z parametrami sesji, różne sortowania tej samej listy, strony z nieskończonym przewijaniem powielające treść) sprawiają, że Google pobiera wiele adresów z tą samą zawartością. To właśnie „domniemane zasoby”, nad którymi masz największą kontrolę.
• Soft 404: strony, które wyglądają jak błąd („brak produktów”, „nie znaleziono”), ale zwracają kod 200. Google pisze wprost, że takie strony będą dalej pobierane i marnują budżet.
• Łańcuchy przekierowań: każdy adres w łańcuchu to osobne żądanie – raport Statystyki indeksowania liczy je oddzielnie. Google wskazuje, że długie łańcuchy przekierowań negatywnie wpływają na indeksowanie.
• Błędy serwera i wolne odpowiedzi: duża liczba błędów 5xx, przekroczeń czasu połączenia albo odpowiedzi 429 to dla Google sygnał, że serwer nie daje rady – limit wydajności spada i robot pobiera mniej. Inaczej jest z błędami 404 i 410: według Google strony zwracające kody 4xx (poza 429) nie marnują budżetu, bo robot dostaje sam kod, bez treści.
• Ciężkie zasoby i renderowanie: do budżetu wliczają się też pliki CSS i JavaScript (łącznie z zapytaniami XHR) oraz adresy alternatywne, np. AMP czy hreflang. Czas renderowania liczy się tak samo jak czas pobierania, więc strona, którą trudno wyrenderować, „kosztuje” więcej.
• Bardzo duże pliki: to nie tyle marnowanie budżetu, co pułapka, o której warto wiedzieć. Od lutego 2026 r. Google dokumentuje, że przy indeksowaniu dla wyszukiwarki Googlebot pobiera pierwsze 2 MB obsługiwanego pliku (np. HTML) i pierwsze 64 MB pliku PDF; każdy plik CSS i JS ma osobno ten sam limit 2 MB, liczony na danych po rozpakowaniu. Wszystko, co jest dalej, jest ignorowane. Domyślnie roboty Google pobierają pierwsze 15 MB pliku, ale poszczególne roboty mogą mieć własne limity.

Skutki złego zarządzania Crawl Budget

Budżet indeksowania nie jest czynnikiem rankingowym, ale pobranie strony to punkt wejścia do wyszukiwarki – jeśli Googlebot nie odwiedzi danej podstrony, nie ma ona szans na indeksację i pokazanie się w wynikach. W dużym serwisie nieefektywne wykorzystanie budżetu oznacza, że nowe produkty czy artykuły długo czekają na odkrycie, zmiany cen i dostępności trafiają do Google z opóźnieniem, a część ważnych adresów zostaje ze statusem „Strona wykryta – obecnie niezindeksowana”. Google ostrzega też, że jeśli robot spędza zbyt dużo czasu na adresach, których nie powinien pobierać, może nie dotrzeć do reszty witryny albo nie zwiększyć budżetu.

Gdzie sprawdzać Crawl Budget i indeksację strony?

Najważniejszym narzędziem jest Google Search Console. Raport Statystyki indeksowania znajdziesz w Ustawieniach usługi (Ustawienia → Statystyki indeksowania). Pokazuje on historię wizyt Googlebota: łączną liczbę żądań, rozmiar pobranych danych, średni czas odpowiedzi, stan hosta (problemy z robots.txt, DNS i połączeniem z serwerem) oraz podział żądań według kodu odpowiedzi, typu pliku, celu (odkrywanie lub odświeżanie) i rodzaju Googlebota. Raport jest dostępny tylko dla usług najwyższego poziomu – usługi domeny albo usługi z prefiksem URL na poziomie głównym.

Drugi raport to Indeksowanie stron (dawniej „Stan” albo „Błędy indeksowania”). Znajdziesz tam adresy z błędami 404 i 5xx, soft 404, problemy z kanonicznymi, blokady w robots.txt i adresy ze statusem „Strona wykryta – obecnie niezindeksowana”. To tutaj najszybciej wychwycisz miejsca, które marnują budżet – szczególnie soft 404 i błędy serwera. Warto też zajrzeć do sekcji Mapy witryn i sprawdzić, czy przesłane sitemapy są odczytywane bez błędów.

Uzupełnieniem są logi serwera, które pokazują faktyczne wizyty Googlebota adres po adresie. Przy mniejszych stronach dane z GSC zwykle wystarczą, przy dużych sklepach analiza logów jest jednym z pierwszych kroków, które robię w ramach audytu SEO.

Porady techniczne optymalizujące Crawl Budget

Aby budżet indeksowania pracował na Twoją korzyść, warto zadbać o stronę od strony technicznej. Oto lista zaleceń oparta na przewodniku Google:

• Poprawna konfiguracja robots.txt: zablokuj adresy, których Google w ogóle nie powinno pobierać – np. kombinacje filtrów, różne sortowania tej samej listy czy wyniki wyszukiwarki wewnętrznej. Nie blokuj za to zwykłej paginacji kategorii, bo przez nią robot dociera do produktów i artykułów. Google zastrzega też, że robots.txt nie służy do tymczasowego „przesuwania” budżetu na inne strony – zwolniony budżet zostanie przesunięty tylko wtedy, gdy witryna już dobija do limitu wydajności. Upewnij się, że ważne podstrony nie są przypadkowo zablokowane.
• Aktualna mapa witryny (sitemap): Google regularnie odczytuje mapę witryny, więc umieść w niej wszystkie adresy, które chcesz mieć pobrane. Przy aktualizowanych treściach Google zaleca tag <lastmod> – pod warunkiem, że odzwierciedla on realną zmianę treści, a nie każde odświeżenie strony.
• Wydajność serwera: optymalizuj czas odpowiedzi serwera i zasoby (cache, kompresja, lżejszy kod, CDN). Szybki i stabilny serwer to dla Google sygnał, że może otworzyć więcej połączeń. Szczególnie warto pilnować czasu do pierwszego bajtu – o tym, jak go obniżyć, piszę w artykule TTFB – jak poprawić Time to First Byte. Dodatkowo obsługuj kod 304 Not Modified: jeśli strona się nie zmieniła, Google użyje wersji z pamięci podręcznej, oszczędzając transfer i zasoby serwera. Roboty Google obsługują nagłówki ETag i Last-Modified – Google zaleca ustawić oba, a jeśli występują razem, korzysta z ETag. Opcjonalnie możesz dodać max-age w Cache-Control, żeby podpowiedzieć, jak długo treść się nie zmieni.
• Unikaj zduplikowanych treści: konsoliduj powielone strony (przekierowania, poprawne tagi kanoniczne, porządek w parametrach URL), żeby robot skupiał się na unikalnych treściach. Upewnij się, że treści produktowe czy artykuły nie występują w wielu identycznych wersjach. Pamiętaj, że canonical nie blokuje pobierania – Google i tak musi pobrać duplikat, żeby zobaczyć tag. Jeśli duplikatów nie da się skonsolidować, a nie chcesz, żeby były pobierane, Google zaleca blokadę w robots.txt; według aktualnego przewodnika znacznie zmniejsza ona też szansę, że takie adresy będą przetwarzane przez inne systemy Google.
• Zarządzaj usuwaniem stron: jeśli usuwasz podstronę na stałe, zwracaj kod 404 lub 410 (410 oznacza „usunięte na stałe”). Google nie zapomina poznanego adresu, ale 404 to dla niego wyraźny sygnał, by nie pobierać go ponownie. Adresy zablokowane w robots.txt zostają w kolejce znacznie dłużej i wracają do pobierania po zdjęciu blokady. Więcej o różnicach między tymi kodami przeczytasz w artykule o błędach 404, 410 i innych kodach 4xx. Przy nawigacji fasetowej zwracaj 404 dla kombinacji filtrów bez wyników zamiast przekierowywać na wspólną stronę błędu.
• Usuń soft 404: strona „nie znaleziono” musi zwracać prawdziwy kod 404/410, a nie 200. Listę soft 404 znajdziesz w raporcie Indeksowanie stron.
• Optymalizuj przekierowania: ogranicz liczbę i długość łańcuchów przekierowań. Każde przekierowanie to osobne żądanie, więc przekierowuj bezpośrednio do adresu docelowego, aktualizuj linki wewnętrzne do finalnych URL-i i nie twórz pętli. Różnice między kodami 301, 302, 307 i 308 opisałem w osobnym wpisie o przekierowaniach 3xx, a hurtowe sprawdzanie kodów odpowiedzi dla listy adresów – w poradniku o skrypcie w Pythonie.
• Monitorowanie statystyk: śledź raport Statystyki indeksowania i stan hosta. Reaguj na gwałtowne spadki liczby żądań, wzrost czasu odpowiedzi czy przyrost błędów 5xx – mogą sygnalizować awarię serwera albo błąd w konfiguracji. Jeśli w narzędziu do sprawdzania adresów URL zobaczysz komunikat „Przekroczono limit obciążenia hosta”, Google wprost zaleca rozważenie mocniejszego serwera.

Google wymienia tylko dwa sposoby na zwiększenie budżetu indeksowania: dodanie zasobów serwera (gdy to serwer jest wąskim gardłem) oraz poprawę jakości treści – w przypadku wyszukiwarki liczą się m.in. popularność, wartość dla użytkowników i niepowtarzalność treści. Nie ma ustawienia ani formularza, którym można „poprosić” o większy budżet.

Jak ograniczyć crawling, gdy Googlebot przeciąża serwer?

Narzędzie do ograniczania szybkości indeksowania w Search Console zostało wyłączone 8 stycznia 2024 roku. Najpierw sprawdź w logach, skąd bierze się ruch – według Google najczęstsze przyczyny nagłego wzrostu to nawigacja fasetowa, kalendarze z adresami dla każdej daty i dynamiczne reklamy w wyszukiwarce. Jeśli trzeba zareagować awaryjnie, Google zaleca (w dokumencie Reduce Google’s crawl rate) zwracanie robotom kodów 500, 503 lub 429 (przy 503 i 429 można dodać nagłówek Retry-After) – ale tylko przez kilka godzin, maksymalnie 1–2 dni. Dłużej grozi to wypadaniem adresów z indeksu. Gdy to niemożliwe, zostaje specjalny formularz zgłoszenia zbyt intensywnego crawlowania.

Mity o crawl budgecie

Google prowadzi osobną stronę „Myths and facts about crawling” z kilkunastoma mitami. Najważniejsze punkty:

• „noindex oszczędza crawl budget” – częściowo prawda. Żeby zobaczyć noindex, Google musi stronę pobrać, więc noindex nie służy do sterowania crawlingiem – w przewodniku Google wprost odradza go w tej roli. W dłuższym okresie strony usunięte z indeksu mogą być pobierane rzadziej, więc noindex może pośrednio zwolnić trochę budżetu. Jeśli strona ma nie być w indeksie – używaj noindex i nie przejmuj się budżetem. Jeśli ma nie być pobierana – robots.txt.
• „Błędy 404 marnują budżet” – fałsz. Kody 4xx (poza 429) nie marnują budżetu. Problemem są soft 404 i błędy 5xx.
• „Małe strony są odwiedzane rzadziej niż duże” – fałsz. Jeśli witryna ma ważne, często zmieniane treści, Google odwiedza ją często niezależnie od rozmiaru.
• „Skompresowana mapa witryny zwiększa budżet” – fałsz. Spakowaną sitemapę i tak trzeba pobrać z serwera, oszczędność jest pomijalna.
• „Częste drobne zmiany i odświeżanie daty przyciągną robota” – fałsz. Sztuczne „odświeżanie” stron nie daje dodatkowej wartości.
• „Szybkość strony i błędy wpływają na budżet” – prawda. Szybki serwer to więcej pobranych stron w tym samym czasie, duża liczba błędów 5xx i timeoutów – mniej. Co to za błędy i jak je naprawiać, opisałem we wpisie o błędach serwera 5xx.
• „Strony bliżej strony głównej są ważniejsze” – częściowo prawda. Adresy linkowane ze strony głównej mogą być pobierane częściej, ale to nie znaczy, że będą wyżej w wynikach.
• „Google nie lubi parametrów w adresach” – fałsz. Google radzi sobie z parametrami. Problemem nie są same parametry, tylko ich niekontrolowana liczba kombinacji.
• „Zmiana adresu (np. dopisanie wersji) wymusza ponowne pobranie” – częściowo prawda. Zwykle jest to niepotrzebne i marnuje zasoby. Adres zmieniaj tylko wtedy, gdy treść zmieniła się istotnie.

FAQ – najczęstsze pytania o crawl budget

Czy crawl budget jest czynnikiem rankingowym?

Nie. Częstsze pobieranie strony nie przełoży się bezpośrednio na wyższe pozycje. Google pisze, że crawling jest konieczny, żeby strona w ogóle znalazła się w wynikach, ale sam w sobie nie jest sygnałem rankingowym. Pobranie i indeksacja to dopiero początek walki o widoczność.

Czy treści osadzone i alternatywne adresy URL wliczają się do crawl budgetu?

Tak. Generalnie każdy adres, który pobiera Googlebot, wlicza się do budżetu. Dotyczy to adresów alternatywnych (AMP, hreflang) i treści osadzonych – plików CSS i JavaScript, łącznie z zapytaniami XHR.

Czy mogę kontrolować crawling dyrektywą „crawl-delay”?

Nie. Niestandardowa reguła crawl-delay w pliku robots.txt jest ignorowana przez roboty Google (inne wyszukiwarki mogą ją respektować). Jeśli Googlebot naprawdę przeciąża serwer, użyj tymczasowo kodów 503 lub 429, jak opisałem wyżej.

Czy linki ze znacznikiem nofollow wpływają na budżet indeksowania?

Częściowo. Każdy pobrany adres zużywa budżet, a link oznaczony jako nofollow i tak może zostać pobrany, jeśli inna strona – w Twojej witrynie lub gdziekolwiek w sieci – linkuje do niego bez nofollow. Szczegóły znajdziesz na stronie Google Myths and facts about crawling.

Czy można poprosić Google o większy crawl budget?

Nie. Nie ma formularza ani ustawienia, którym zwiększysz budżet. Google wymienia tylko dwie drogi: dodanie zasobów serwera, jeśli to on ogranicza pobieranie (w narzędziu do sprawdzania adresów URL zobaczysz wtedy komunikat o przekroczeniu limitu obciążenia hosta), oraz poprawę jakości treści. Formularz istnieje tylko w drugą stronę – do zgłoszenia, że Googlebot pobiera stronę zbyt intensywnie.

Czy mała strona firmowa musi optymalizować crawl budget?

Zazwyczaj nie. Przy kilkudziesięciu czy kilkuset podstronach Google bez problemu pobiera całą witrynę. Jeśli takie strony nie są w indeksie, przyczyną jest zwykle jakość treści, duplikacja albo błąd techniczny (np. noindex, blokada w robots.txt), a nie brak budżetu.

Masz duży sklep albo serwis, w którym nowe strony długo czekają na Googlebota, a raport „Strona wykryta – obecnie niezindeksowana” tylko rośnie? Napisz do mnie w sprawie konsultacji SEO – sprawdzimy, czy problemem jest budżet indeksowania, czy coś zupełnie innego.