Crawl budget. Co to jest i na co Googlebot go zużywa?

Publikacja: 15 października 2025 · Ostatnia aktualizacja: 1 listopada 2026

Crawl budget to zbiór adresów URL, które Google może i chce przeskanować w Twojej witrynie. Tak definiuje go dokumentacja Google (wersja z 22.07.2026). Chodzi o skanowanie, czyli pobieranie stron przez robota. Indeksacja to osobny, późniejszy etap i zeskanowana strona wcale nie musi do indeksu trafić. Jeśli Twoja strona ma kilkaset podstron, budżet najpewniej nie jest Twoim problemem. A mimo to w moich logach z lutego⁠–⁠sierpnia 2026 co piąta wizyta Googlebota (20,6%) poszła na adresy, które nic nie wnoszą.

Skąd bierze się zamieszanie? Po części z nazwy. Polska wersja dokumentacji Google mówi o „budżecie indeksowania” i crawling tłumaczy przeważnie jako „indeksowanie” (na tej stronie „indeksowanie” pada ponad 70 razy, „skanowanie” kilka). I to rozróżnienie ma praktyczne skutki, o czym niżej, przy noindex.

Masz małą stronę i dopiero startujesz? Crawl budget możesz spokojnie odłożyć, a ten czas lepiej poświęcić na podstawy pozycjonowania.

Co to jest crawl budget?

Google składa budżet z dwóch elementów, które działają jak dwa zawory na tej samej rurze.

Dwa zawory na jednej rurze: limit wydajności i zapotrzebowanie. Budżet ustawia ten, który akurat jest bardziej przykręcony.

• Crawl capacity limit, czyli limit wydajności

  Ile robot może pobrać, nie przeciążając serwera. Google opisuje go jako łączny czas, przez jaki Twój serwer trzyma otwarte połączenia dla Google. Kiedy strona odpowiada szybko, limit rośnie. Kiedy zwalnia albo odpowiada błędami 5xx lub kodem 429 (czyli „zwolnij, za dużo żądań”), limit spada.

• Crawl demand, czyli zapotrzebowanie

  Ile Google w ogóle chce pobrać. Dokumentacja wymienia wielkość serwisu, częstotliwość zmian oraz jakość i trafność stron, wszystko na tle innych witryn. Osobno opisuje popularność adresu (popularne strony są odświeżane częściej) i to, jak bardzo zestarzała się kopia strony w systemach Google. Przeprowadzka na nową domenę chwilowo podbija zapotrzebowanie, bo całą treść trzeba przetworzyć pod nowymi adresami.

I najważniejsze: Google pisze wprost, że nie każda zeskanowana strona trafi do indeksu. Po pobraniu strona jest oceniana, łączona z duplikatami (kanonikalizacja) i dopiero wtedy zapada decyzja. Cały łańcuch, od skanowania przez indeksowanie po ranking, rozpisałam we wpisie od skanowania do rankingu.

Kiedy crawl budget ma znaczenie?

Dokumentacja Google kieruje ten temat do trzech grup:

• 1

  Duże serwisy

  Ponad milion unikalnych stron, w których treść zmienia się mniej więcej raz w tygodniu.

• 2

  Średnie i większe

  Ponad 10 tys. stron z treścią zmieniającą się codziennie.

• 3

  Dużo stron „wykrytych”

  Duża część adresów ma w Search Console status „Strona wykryta – obecnie niezindeksowana”.

Google zastrzega, że to szacunki, a nie sztywne progi. Już w 2017 roku pisał zresztą, że strona, która ma mniej niż kilka tysięcy adresów, zwykle jest skanowana sprawnie, a jeśli nowe podstrony są pobierane w dniu publikacji, nie ma się czym zajmować.

Dla porównania: w mapach witryny podrez.pl jest dziś (1.11.2026) 117 adresów. Gdyby chodziło tylko o liczby, mogłabym w tym miejscu skończyć. Tyle że w sklepie skalę wyznacza liczba adresów, które robot jest w stanie znaleźć, a ta potrafi wielokrotnie przerosnąć liczbę produktów. Filtry, sortowanie i parametry potrafią z kilku tysięcy produktów zrobić setki tysięcy kombinacji. I wtedy próg z dokumentacji przestaje być abstrakcją.

Gdzie jesteś na skali? Oś jest logarytmiczna: każda kreska to dziesięć razy więcej adresów. Sklep z filtrami potrafi przeskoczyć dwa rzędy wielkości.

W sklepie nie chodzi więc o to, żeby Google mogło wszystko zobaczyć i zaindeksować, tylko o to, żeby widziało to, co naprawdę istotne. Pomaga w tym linkowanie wewnętrzne: linki z popularnych podstron do kategorii i nowych produktów podpowiadają robotowi, gdzie warto zaglądać częściej. Filtry, które mają żyć jako osobne strony (np. „buty trekkingowe damskie”), niech będą zwykłymi linkami, a nie wyłącznie przyciskami czy suwakami. Kombinacji, których nikt nie szuka, lepiej robotowi w ogóle nie wystawiać.

Na co Googlebot zużywa budżet? Pomiar z moich logów

Zamiast pisać ogólnie o „marnowaniu budżetu”, policzyłam to u siebie. Wzięłam logi dostępowe serwera podrez.pl z okresu 02.02⁠–⁠05.08.2026 (185 dni, ponad 1,8 mln żądań – te same, na których oparłam analizę logów serwera pod kątem botów AI) i wyciągnęłam z nich wszystko, co przedstawiało się jako Googlebot.

Pierwsza niespodzianka? Nie każdy Googlebot jest Googlebotem. Z 11 102 takich żądań 2 154 (19,4%) przyszły spoza adresów IP, które Google publikuje dla swoich robotów, w tym prawie tysiąc z jednego serwera w chmurze DigitalOcean, w marcu. Jak sprawdzić bota po adresie IP, pokazuję w zestawieniu botów. Podszywaczy odrzuciłam. Zostało 8 948 zweryfikowanych żądań, czyli średnio 48 dziennie.

Wpisy i strony to 173 adresy, w tym 122 odpowiedzi 304 „bez zmian”. Źródło: logi dostępowe podrez.pl, 02.02⁠–⁠05.08.2026, tylko żądania z user-agentem Googlebot (bez Googlebot-Image) z adresów IP Google. Opracowanie własne, 10.10.2026.

Razem 1 845 żądań. Okno i źródło jak wyżej.

Co z tego jest problemem, a co tylko tak wygląda w tabeli?

Strony /embed/: noindex nie oszczędza budżetu

WordPress dokłada do każdego wpisu wersję do osadzania na innych stronach (adres kończy się na /embed/). Te strony mają noindex, co sprawdziłam 10.10.2026 na przykładzie /bluf/embed/. Googlebot pobrał je 434 razy, do tego 83 przekierowania. Najczęściej wracał do /geo-vs-seo/embed/ i /encja-kontekst-intencja/embed/, po 40 razy. A ten wpis? W tym samym czasie Googlebot pobrał go dwa razy, a jego wersję /embed/ – szesnaście.

Z /embed/ najpewniej wiąże się też trzecia pozycja z tabeli. Plik tribe-events-embed.min.css wtyczki The Events Calendar zwracał 404 w sześciu wersjach (od ?ver=6.15.14 do ?ver=6.16.3). Nazwa sugeruje, że wtyczka doklejała go właśnie do widoku osadzania, więc robot, renderując /embed/, prosił o arkusz stylów, którego nie było. To moja hipoteza: w logach widzę żądanie, ale nie widzę, która strona je wywołała.

Od lipca oba zjawiska zniknęły z logów, a udział adresów bez wartości spadł z 26,7% w lutym do 9,5% w lipcu. Dlaczego? Nie wiem na pewno, a w tekście o pomiarze zgadywać nie będę. Strony /embed/ nadal odpowiadają kodem 200, a w kodzie tego wpisu nie ma już śladu wtyczki The Events Calendar (sprawdzone 10.10.2026). Mimo to od jesieni blokuję je w robots.txt regułą Disallow: /*/embed/, żeby robot nie wracał do nich przy następnej okazji.

ads.txt: wygląda na stratę, ale tego nie ruszam

Plik ads.txt mówi, kto może sprzedawać reklamy na stronie. Reklam u siebie nie mam, więc pliku też nie. Googlebot pytał o niego 432 razy, co miesiąc od 57 do 82 razy: najpierw o adres z http (przekierowanie 301), potem o wersję z https (404). Czy to marnotrawstwo? Formalnie tak. W praktyce przy 48 żądaniach dziennie i około 120 adresach nic mi nie odbiera, a 404 to dla Google właściwa odpowiedź na plik, którego nie ma. Nie wszystko, co w logach wygląda na stratę, trzeba naprawiać.

Przekierowania: Google nie zapomina starych adresów

215 żądań poszło na 51 starych adresów, które dziś przekierowuję, na przykład /materialy-edukacyjne/google-moja-firma/ (31 razy) po przenosinach poradników jesienią 2025. Google pisze, że nie zapomina adresu, który już zna. Pojedyncze 301 to normalny koszt przeprowadzki. Gorzej z łańcuchami, a jeden mały mam u siebie: https://www.podrez.pl/ prowadzi najpierw na https://www.podrez.pl/, a dopiero potem na https://podrez.pl/ (sprawdzone 10.10.2026). Dwa skoki zamiast jednego. Przy mojej skali to drobiazg. Przy sklepie, w którym taki łańcuch powtarza się na każdym z kilkuset tysięcy adresów, już nie.

Przekierowania strony głównej (277) to w większości stare warianty adresu z http albo z www. Piszę „w większości”, bo mój log nie zapisuje nazwy hosta i nie rozróżnię ich co do sztuki.

Pliki do renderowania to koszt, ale nie strata

Prawie jedna trzecia żądań to pliki potrzebne do wyrenderowania strony. Google pisał w 2017 roku, że każdy adres pobrany przez Googlebota liczy się do budżetu, łącznie z CSS, JavaScriptem i wywołaniami AJAX. Tych plików nie blokuję, bo bez nich robot nie zobaczy strony tak, jak widzi ją czytelnik. Mogę natomiast pilnować, żeby było ich mniej i żeby serwer oddawał je szybko.

Jak nie marnować crawl budgetu? Co zaleca Google

Poniżej zalecenia z dokumentacji (stan z 22.07.2026), z moim komentarzem tam, gdzie mam coś z własnego podwórka.

• 1

  Jedna treść, jeden adres

  Duplikaty usuwaj albo scalaj, żeby robot skanował unikalną treść, a nie kolejne adresy z tą samą treścią. Jak scalać (canonical, 301), Google opisuje na osobnej stronie o duplikatach. W sklepie to przede wszystkim sortowanie i filtry.

• 2

  Robots.txt dla adresów, których robot nie ma pobierać nigdy

  Chodzi o wyniki wyszukiwania wewnętrznego, koszyk i kombinacje filtrów, których nikt nie szuka. Nie noindex (patrz /embed/ wyżej). I nie robots.txt „na chwilę”: Google uprzedza, że zwolnionego w ten sposób budżetu nie przesunie na inne strony, chyba że Twój serwis już dobija do limitu wydajności. To zdanie z dokumentacji przeczytałam dwa razy.

• 3

  404 albo 410 dla stron usuniętych na stałe

  Zablokowany adres zostaje w kolejce dłużej i wraca, gdy blokada zniknie, a 404 to mocny sygnał, żeby go więcej nie pobierać. Do tego soft 404, czyli strony, które mówią „nic tu nie ma”, a odpowiadają kodem 200. Google skanuje je dalej.

• 4

  Aktualne mapy witryny

  Z tagiem lastmod przy zmienionych treściach.

• 5

  Bez długich łańcuchów przekierowań

  W linkach wewnętrznych od razu adres docelowy.

• 6

  Szybki serwer i obsługa 304

  Jeśli strona się nie zmieniła od ostatniej wizyty, serwer może odpowiedzieć „bez zmian” (304 Not Modified) zamiast wysyłać ją od nowa. U mnie takich odpowiedzi było 122 na 3 665 pobrań stron. Google obsługuje tu dwa mechanizmy: ETag (robot odpytuje go nagłówkiem If-None-Match) i Last-Modified (If-Modified-Since). Zdecydowanie poleca ETag, bo trudniej w nim o błąd niż w dacie Last-Modified, a najlepiej ustawić oba. Byle zmieniona strona nie odpowiadała 304, bo robot zostanie wtedy przy starej wersji.

• 7

  Żadnych 5xx i 429 dla Googlebota

  To dla niego sygnał, żeby zwolnić. Kiedy siedziałam nad logami pod kątem botów AI, okazało się, że mój hosting odsyłał kod 429 botom AI tysiące razy. Googlebotowi ani razu. I całe szczęście.

Robots.txt, noindex, canonical czy 404?

Te narzędzia łatwo pomylić, a każde robi co innego:

Robots.txt steruje pobieraniem, noindex indeksowaniem, a canonical wyborem wersji. Mieszanie ich na jednej stronie (np. blokada w robots.txt plus noindex) daje sprzeczne sygnały.

Szybkość strony a crawl budget (i gdzie tu Core Web Vitals)

Core Web Vitals to trzy wskaźniki: LCP (ładowanie), INP (reakcja na interakcję, od marca 2024 w miejsce FID) i CLS (stabilność układu). TBT, czyli Total Blocking Time, to pomiar laboratoryjny z Lighthouse. Według web.dev służy jedynie jako przybliżenie INP, bo w symulacji nie ma użytkownika, który by cokolwiek kliknął.

Dla budżetu to rozróżnienie ma znaczenie. Core Web Vitals mierzą wrażenia ludzi w przeglądarce, a robot ma inne zmartwienia: czas odpowiedzi serwera i liczbę plików do pobrania. Według Google szybsze ładowanie i renderowanie stron pozwala mu przeczytać więcej treści z witryny. Moja hipoteza? Dobre Core Web Vitals i szybki serwer idą w parze częściej, niż się rozjeżdżają, ale wynik w PageSpeed Insights nie powie Ci, ile stron Googlebot pobiera dziennie. To widać w Search Console i w logach.

Dla robota liczy się przede wszystkim to, jak szybko odpowiada serwer. Core Web Vitals i TBT opisują wrażenia ludzi.

Jak sprawdzić crawl budget u siebie?

1. 1Search Console, Ustawienia → Statystyki indeksowania

   Zobaczysz tu, ile żądań dziennie wysyła Googlebot i jak szybko odpowiada mu serwer. Niżej jest podział według kodów odpowiedzi i typów plików, a także według celu pobrania (odkrywanie nowych adresów albo odświeżanie znanych). Nagły spadek liczby żądań przy rosnącym czasie odpowiedzi to pierwszy trop.

2. 2Raport Indeksowanie stron

   Ile adresów ma status „Strona wykryta – obecnie niezindeksowana”. Duża i rosnąca grupa to jeden z sygnałów, które wymienia dokumentacja.

3. 3Logi serwera

   Odfiltruj user-agenta Googlebot, zweryfikuj adresy IP, pogrupuj żądania według typu adresu i kodu odpowiedzi. A potem zadaj jedno pytanie: ile z tego to adresy, które chcę mieć w Google? Search Console pokazuje próbkę i agregaty. Logi pokazują każde żądanie, także te od podszywaczy.

W dużym serwisie analiza logów szybko wychodzi poza SEO i ląduje na biurku działu IT, więc rzadko kończy się na jednym raporcie z narzędzia. Robię ją w ramach strategicznego audytu SEO, na logach z kilku miesięcy, a nie z jednego dnia.

Co mierzyć po zmianach?

Reguły w robots.txt czy porządki w filtrach łatwo wdrożyć, trudniej sprawdzić, czy coś dały. Zanim cokolwiek zablokujesz, zapisz, co chcesz osiągnąć i na jakich adresach to sprawdzisz.

• 1

  Konkretny cel

  Nie „mniej wizyt Googlebota”, tylko np. krótszy czas od publikacji do pierwszego pobrania, szybsze odświeżanie zmienionych produktów albo mniej odpowiedzi 5xx. Sam spadek wszystkich wizyt może oznaczać, że robot rzadziej wraca także tam, gdzie powinien.

• 2

  Grupa ważnych adresów

  Wybierz adresy, które mają znaczenie: nowe wpisy, kategorie, bestsellery. Patrz na nie osobno, bo średnia dla całego serwisu rozmyje efekt.

• 3

  Logi i Search Console razem

  Statystyki indeksowania pokazują agregaty i próbkę adresów, logi każde żądanie. Jeśli część ruchu obsługuje CDN, logi serwera mogą go nie widzieć, więc liczby z obu źródeł nie muszą się zgadzać co do sztuki.

• 4

  Kontekst zmian

  Porównując okresy, zanotuj publikacje, wdrożenia i awarie. Patrz na liczby bezwzględne i na udziały: udział zbędnych adresów może spaść tylko dlatego, że wzrosło pobieranie innych stron.

U siebie sprawdzę to na /embed/. Od jesieni blokuję te adresy regułą Disallow: /*/embed/, więc w logach z kolejnych miesięcy żądania do nich powinny zniknąć, a nowe wpisy nadal powinny być pobierane w dniu publikacji. Jeśli robot nie wróci do tych adresów, ale też nie zacznie częściej odwiedzać pozostałych stron, to też będzie wynik: przy moim serwisie limit wydajności i tak nie był problemem.

Crawl budget: pytania i odpowiedzi