Crawl budget (budżet indeksowania)

Jak wygląda w praktyce

Budżet nie jest liczbą w panelu. Widać go pośrednio w logach i w Search Console. Fragment logu z jednej nocy w sklepie z nawigacją fasetową:

66.249.66.1 - - [20/Oct/2026:02:14:07] "GET /buty?kolor=czarny&rozmiar=42&sort=cena HTTP/1.1" 200

66.249.66.1 - - [20/Oct/2026:02:14:09] "GET /buty?rozmiar=42&kolor=czarny&sort=cena HTTP/1.1" 200

66.249.66.1 - - [20/Oct/2026:02:14:11] "GET /buty?kolor=czarny&rozmiar=42&sort=cena&page=2 HTTP/1.1" 200

Trzy żądania, jedna treść, zero nowych produktów w indeksie. W raporcie Statystyki indeksowania ten sam problem widać jako wysoką liczbę żądań z celem „Odświeżenie” bez nowych stron w celu „Wykrycie”.

Jak traktuje to Google

Przewodnik Google (optymalizacja budżetu indeksowania) definiuje witrynę jako unikalną nazwę hosta, więc www.example.com i sklep.example.com mają osobne budżety. Budżet zależy od dwóch czynników.

Limit wydajności indeksowania, nazywany też obciążeniem hosta, ogranicza łączny czas otwartych połączeń z Google: liczbę połączeń równoległych i ich czas trwania. Każda witryna zaczyna od tego samego konserwatywnego limitu. Rośnie on, gdy witryna odpowiada spójnie, a czasy odpowiedzi, w tym czas do pierwszego bajtu, są stabilne albo się poprawiają. Spada, gdy czas odpowiedzi rośnie, pojawiają się błędy 5xx albo sygnały ograniczania szybkości, jak HTTP 429. Limit jest wspólny dla wszystkich robotów Google.

Zapotrzebowanie na indeksowanie zależy od rozmiaru witryny, częstotliwości aktualizacji, jakości stron i trafności. Największy wpływ masz na domniemane zasoby, czyli wszystkie adresy, które Google znajduje, w tym duplikaty i strony usunięte. Nawet przy niewykorzystanym limicie Googlebot skanuje rzadziej, gdy zapotrzebowanie jest niskie.

Dokument określa też, komu przewodnik się przyda: witrynom z ponad milionem unikalnych stron zmieniających się raz w tygodniu, witrynom z ponad 10 tysiącami stron zmieniających się codziennie oraz witrynom z dużą częścią adresów w statusie Strona wykryta, obecnie niezindeksowana. Liczby to wartości szacunkowe, nie sztywne progi. Jeśli strony są indeksowane w dniu publikacji, przewodnik Cię nie dotyczy.

Co marnuje budżet

Według sprawdzonych metod z tego samego dokumentu:

• duplikaty treści pod różnymi adresami - skonsoliduj je, bo Google skanuje adresy, a nie unikalne treści,
• strony z przewijaniem nieskończonym i różnie posortowane wersje tej samej strony - zablokuj w pliku robots.txt, jeśli nie da się ich skonsolidować,
• soft 404 - Google nadal je skanuje, więc zużywają budżet bez korzyści,
• strony trwale usunięte bez kodu 404 lub 410 - Google nie zapomina adresu, ale 404 to wyraźny sygnał, by nie skanować go ponownie,
• długie łańcuchy przekierowań - negatywnie wpływają na skanowanie,
• nieaktualna mapa witryny - ma zawierać wszystko, co ma być skanowane, najlepiej z tagiem lastmod.

Dokument ostrzega przed dwoma pozornymi oszczędnościami. Tag noindex nie oszczędza budżetu, bo Google i tak pobiera stronę, żeby go zobaczyć. Blokowanie w robots.txt nie przenosi budżetu na inne strony, chyba że witryna już osiąga limit wydajności. Dokument o zmniejszaniu szybkości skanowania (zmniejszanie szybkości indeksowania) jako najczęstsze przyczyny nagłego wzrostu żądań wymienia nawigację fasetową, sortowanie i filtrowanie oraz kalendarze z osobnym adresem dla każdej daty.

Najczęstsze błędy

Jak sprawdzić

Zacznij od raportu Statystyki indeksowania w Search Console. Według dokumentacji (raport Statystyki indeksowania) pokazuje łączną liczbę żądań, rozmiar pobierania, średni czas odpowiedzi i stan hosta, a także podział żądań według odpowiedzi, typu pliku, celu i typu Googlebota. Stan hosta mówi, czy w ciągu ostatnich 90 dni robot napotkał poważne problemy z dostępnością. Spadek żądań przy rosnącym czasie odpowiedzi to typowy obraz obniżonego limitu.

Potem logi. Odfiltruj Googlebota, zweryfikuj adresy IP zgodnie z dokumentacją (weryfikacja żądań Googlebota) i policz udział adresów z parametrami oraz rozkład kodów:

grep Googlebot access.log | awk '{print $7}' | grep -c '?'

grep Googlebot access.log | awk '{print $9}' | sort | uniq -c

Czas odpowiedzi pojedynczego adresu zmierzysz z linii poleceń:

curl -s -o /dev/null -w "%{time_starttransfer}\n" https://example.com/kategoria/

Wartość objaśnia hasło o TTFB. Mapę witryny pod kątem adresów z błędami sprawdzisz w sprawdzarce sitemapy, a znaczenie poszczególnych kodów w haśle o kodach odpowiedzi HTTP.

Monitorowanie

IndexRise nie liczy budżetu, bo tę liczbę zna tylko Google. Co noc zapisuje za to trzy rzeczy, od których budżet zależy: kod odpowiedzi każdego monitorowanego adresu, czas odpowiedzi strony oraz stan mapy witryny. Seria 5xx, wolniejsze odpowiedzi po wdrożeniu, niedostępny robots.txt albo mapa, która nagle straciła część adresów, pojawią się jako zdarzenia, zanim raport Statystyki indeksowania pokaże spadek żądań.