Crawl budget — definicja i zarządzanie

Crawl budget to maksymalna liczba URL-i, które Googlebot (lub inny bot wyszukiwarki) gotów jest odwiedzić w twojej domenie w danym okresie. Oficjalna definicja Google brzmi: „liczba URL-i, które Googlebot może i chce przeskanować”. To właśnie „może i chce” dzieli crawl budget na dwa komponenty — crawl rate limit i crawl demand — których odrębne zrozumienie jest kluczowe do zarządzania.

Termin pojawił się w dokumentacji Google Search Central w styczniu 2017 roku w poście Gary’ego Illyesa „What Crawl Budget Means for Googlebot”. Dla większości małych i średnich serwisów (do 10 000 URL-i) crawl budget nie jest problemem — Google skanuje je w całości. Dla dużych serwisów (e-commerce, portale, wydawcy z 100 tys. URL-i) niewłaściwe zarządzanie crawl budgetem odcina 15–40% treści od indeksacji, co bezpośrednio obniża widoczność w SERP.

Crawl budget — krótka definicja robocza

Crawl budget to liczba żądań HTTP, które Googlebot wykonuje w danej domenie w ciągu 24 godzin. Dla serwisu z 500 URL-ami budżet to zwykle 50–200 żądań dziennie (wystarcza do skanowania całości). Dla serwisu z 500 000 URL-i budżet to 5 000–50 000 żądań dziennie — i tu już wymaga zarządzania, bo bot nie dociera do wszystkich stron w rozsądnym czasie.

Google nie publikuje wartości crawl budgetu per domena. Są natomiast sygnały proxy, które pozwalają ją oszacować: raport „Statystyki indeksowania” w Search Console, logi serwera z filtrem na user-agent „Googlebot” i stosunek stron zindeksowanych do wysłanych w sitemap.

Definicja rozszerzona — crawl rate limit vs crawl demand

Oficjalna dokumentacja Google dzieli crawl budget na dwa komponenty, które razem dają końcową liczbę żądań. Rozumienie tego podziału jest fundamentalne — próba zwiększania crawl budgetu bez znajomości komponentów prowadzi do marnowania zasobów.

Crawl rate limit — techniczna górna granica

Crawl rate limit to maksymalna liczba równoległych połączeń i maksymalna częstotliwość żądań, jaką Googlebot uzna za bezpieczną dla serwera. Googlebot dynamicznie obniża tę wartość, gdy czasy odpowiedzi serwera rosną, albo gdy serwer zwraca błędy 5xx. Podniesienie crawl rate limit wymaga poprawy infrastruktury.

Crawl demand — potrzeba skanowania

Crawl demand to „głód” Googlebota na treści konkretnej domeny, liczony na podstawie: popularności stron, świeżości treści, linków przychodzących i sygnałów jakości. Domena z wysokim crawl demand jest skanowana częściej, nawet gdy serwer fizycznie pozwala na więcej.

Co waży więcej w 2026

Dla ~85% serwisów w Polsce ograniczeniem jest crawl demand, nie crawl rate limit. Oznacza to, że crawl budget można zwiększyć przez sygnały jakościowe (linki, świeżość, E-E-A-T), a nie przez szybszy serwer. Tylko przy naprawdę dużych serwisach (Allegro, Ceneo, Empik, OLX) ograniczeniem staje się infrastruktura.

Kontekst historyczny — jak Google tłumaczył crawl budget od 2010

Przed 2017 rokiem Google komunikował crawl budget nieformalnie przez wypowiedzi Matt Cutts’a (2010, YouTube Webmasters) i Johna Muellera (Google Hangouts). Oficjalny post z stycznia 2017 skonsolidował rozproszone wypowiedzi w jednej definicji. Od tego czasu dokumentacja była aktualizowana w 2020 i 2023 roku, głównie przez dodanie informacji o wpływie Core Web Vitals na crawl rate.

Oś czasu kluczowych zmian

Rok	Wydarzenie	Znaczenie
2010	Matt Cutts — koncepcja „crawl budget”	Pierwsze publiczne użycie terminu.
2017	Post Gary Illyes — oficjalna definicja	Podział na rate limit i demand.
2019	Evergreen Googlebot (Chrome)	Lepsze renderowanie JS, wyższe koszty dla bota.
2020	Core Web Vitals w dokumentacji crawl	Szybkie strony — więcej budżetu.
2023	Helpful Content Update v2	Słaba treść obniża crawl demand.
2024	AI Overviews	Nowe boty (Google-Extended, GPTBot) dzielą budżet.

Więcej o kontekście aktualizacji algorytmów czytacie w słowniku marketingu cyfrowego 2026.

Jak Googlebot wydaje crawl budget — mechanika

Googlebot nie skanuje losowo. Decyzję, który URL odwiedzić, podejmuje scheduler na podstawie listy prioritetów. Rozumienie kolejki pozwala ukierunkować bota na strony, na których zależy nam najbardziej.

Kolejność priorytetów Googlebota

1. Strony z listy sitemap z parametrem lastmod wskazującym niedawną zmianę.
2. Strony linkowane z innych serwisów (świeże linki zewnętrzne budzą crawl demand).
3. Strony z dużą liczbą linków wewnętrznych — hub-and-spoke działa nie tylko dla rankingów.
4. Strony, które w historii generowały ruch — Google preferuje URL-e o potwierdzonej „popularności”.
5. Strony z częstymi zmianami — blogi aktualizowane codziennie dostają priorytet nad statycznymi.

Co obniża priorytet URL-a

• Wysoki stosunek stron „thin” (poniżej 300 słów) do reszty serwisu.
• Duplikaty treści — szczególnie facetowe filtry w e-commerce.
• Wolne czasy odpowiedzi serwera (powyżej 600 ms TTFB).
• Częste błędy 5xx — trzy błędy w ciągu doby znacząco obniżają rate limit.
• Długie łańcuchy przekierowań (3+) — każde przekierowanie konsumuje budżet.

Jak zmierzyć crawl budget własnego serwisu

Nie ma jednej liczby „crawl budget = X”. Są za to trzy źródła sygnału, które razem dają obraz. Każde z nich mierzymy co miesiąc i porównujemy w trendzie.

Źródło 1: Search Console — Statystyki indeksowania

Raport „Statystyki indeksowania” (Settings → Crawling) pokazuje średnią dzienną liczbę żądań Googlebota, rozmiar pobranych danych w KB i średni czas odpowiedzi serwera. Liczba żądań to przybliżenie crawl budgetu. Trend spadkowy 20%+ w 30 dni to sygnał ostrzegawczy.

Źródło 2: logi serwera

Najdokładniejsze źródło. Logi Apache/Nginx/IIS filtrowane na user-agent „Googlebot” pokazują każde żądanie bota. Parsowanie logów (narzędzia: Screaming Frog Log Analyzer, Botify, Oncrawl) daje odpowiedzi, których Search Console nie da — który URL był skanowany, jak często i z jakim HTTP status code.

Źródło 3: stosunek sitemap → indeks

W Search Console porównujemy liczbę URL-i w sitemap z liczbą zindeksowanych. Stosunek poniżej 70% to sygnał, że crawl budget jest za mały albo treści są niskiej jakości. Próg alarmowy: poniżej 50%.

Przykłady zarządzania crawl budgetem — trzy przypadki

Teoria bez przykładów jest niepełna. Pokazujemy trzy realne scenariusze z polskich serwisów, z liczbami przed i po optymalizacji.

Przypadek 1: sklep z 180 000 URL-i (filtracja fasetowa)

Startowo: 180 000 URL-i, Googlebot skanował ~12 000 dziennie, zindeksowane 34 000 stron (19%). Diagnoza: 140 000 URL-i to kombinacje filtrów (kolor × rozmiar × marka × sortowanie), które generują duplikaty. Akcja: canonical do strony bazowej kategorii, parametry filtrów w robots.txt. Po 45 dniach: 60 000 URL-i skanowanych dziennie (5× więcej strategicznych stron), zindeksowane 52 000 stron (wzrost o 53%).

Przypadek 2: portal informacyjny z archiwum 2008–2026

Startowo: 480 000 artykułów, Googlebot skanował 28 000 dziennie, świeże treści (ostatnie 90 dni) zdobywały indeksację w 24–48 h, stare dostawały się do top-10 dopiero po tygodniach. Akcja: aktualizacja sitemap (priority=0.3 dla archiwum starszego niż 2 lata, lastmod świeżych), usunięcie 40 000 artykułów „evergreen” bez ruchu (noindex + redirect do nowych). Po 60 dniach: crawl rate wzrósł do 41 000/dzień, indeksacja nowych w 8–12 h, wzrost ruchu organicznego o 18%.

Przypadek 3: blog B2B z 600 artykułami

Startowo: 600 URL-i, crawl rate 400/dzień, 100% indeksacja — teoretycznie brak problemu. Diagnoza: Googlebot wydawał 60% budżetu na paginację tagów i stare komentarze (niskiej wartości). Akcja: noindex na paginacji >1, usunięcie komentarzy sprzed 2022. Po 30 dniach: ten sam crawl rate, ale bot odwiedzał każdy artykuł 3× częściej — świeżość wzrosła, rankingi przesunęły się o 4–9 pozycji dla 80 kluczowych fraz.

Różnice — crawl budget vs pokrewne pojęcia

Crawl budget myli się z trzema sąsiednimi pojęciami. Porządkujemy je, żeby wiadomo było, o czym mówimy w rozmowie z zespołem dev/SEO.

Tabela porównawcza

Pojęcie	Co mierzy	Jednostka
Crawl budget	Liczbę odwiedzin bota	URL-e/dzień
Index coverage	Liczbę stron w indeksie	URL-e łącznie
Render budget	Czas CPU na renderowanie JS	Sekundy CPU
Crawl frequency	Jak często odwiedzany pojedynczy URL	Odwiedzin/tydzień

Crawl budget vs index coverage

Crawl budget dotyczy procesu skanowania; index coverage — procesu indeksacji. Strona może być skanowana 10× i nadal nie trafić do indeksu, jeśli Google uzna ją za niskiej jakości. W Search Console raport „Pokrycie indeksu” pokazuje powody wyłączenia z indeksu: „Skanowane — obecnie nie zindeksowane”, „Duplikat bez preferowanego wyboru”, „Wykluczone przez tag noindex”.

Crawl budget vs render budget

Render budget to osobny zasób dla stron JS-heavy. Googlebot najpierw pobiera HTML (crawl budget), potem renderuje JS w drugiej fazie (render budget). Strony z dużą ilością React/Vue SPA mogą mieć pełny crawl budget, ale niedostateczny render budget, co skutkuje brakiem treści dynamicznej w indeksie.

Jak zwiększyć crawl budget — 8 technik

Zwiększanie crawl budgetu to de facto dwa zadania: podniesienie crawl rate limit (przez infrastrukturę) i podniesienie crawl demand (przez jakość i popularność). Poniższe techniki adresują oba frony.

Techniki zwiększające crawl rate limit

1. TTFB poniżej 400 ms. Szybszy serwer = więcej równoległych żądań. Przejście z shared hosting na VPS często daje 2–3× skok.
2. Zero błędów 5xx. Trzy błędy w 24 h obniżają rate limit o ~30%. Monitoring uptime to must-have.
3. Stabilne czasy odpowiedzi. Wariancja poniżej 20%. Duże skoki latencji (peak 2 s, średnia 300 ms) Googlebot traktuje jak niestabilność.
4. HTTP/2 lub HTTP/3. Multipleksowanie — bot pobiera wiele zasobów równolegle w jednej sesji.

Techniki zwiększające crawl demand

1. Linki zewnętrzne do nowych sekcji. Każdy link DR 40+ budzi crawl demand na podlinkowanej stronie i w jej okolicy.
2. Świeżość treści. Aktualizacje co 6 miesięcy podnoszą priorytet w kolejce skanowania.
3. Linkowanie wewnętrzne. Strony głębokie (4+ kliki od homepage) są odwiedzane rzadziej; spłaszczenie architektury to niedrogi zysk.
4. Topical authority w klastrze. Domena z wysoką topical authority jest skanowana częściej w całym swoim polu tematycznym.

Mit obalony — „wielki serwer = wielki crawl budget”

Popularne przekonanie: „przerzucimy się na potężny serwer, Googlebot będzie skanował więcej”. Półprawda. Crawl budget rośnie z infrastrukturą tylko do punktu, w którym rate limit przestaje być wąskim gardłem. Potem liczy się już tylko crawl demand.

Kiedy infrastruktura pomaga

• Gdy TTFB przekracza 800 ms — wtedy poprawa ma liniowy efekt.
• Gdy serwer generuje 5xx pod obciążeniem — stabilizacja podnosi rate limit o 30–60%.
• Gdy serwis jest bardzo duży (500 000+ URL-i) i fizycznie nie mieści się w obecnej infrastrukturze.

Kiedy infrastruktura nie pomaga

• Dla ~85% serwisów w Polsce ograniczeniem jest crawl demand — szybszy serwer niczego nie zmieni.
• Dla serwisów z niską jakością treści — bot po prostu „nie chce” skanować więcej.
• Dla serwisów z chaosem architektonicznym — bot marnuje nowy budżet na te same śmieci, co poprzednio.

Mit obalony — „małe serwisy nie muszą się martwić”

Drugi mit: „mamy 500 URL-i, crawl budget nas nie dotyczy”. Prawda częściowa. Przy 500 URL-ach rzadko jest problem z objętością, ale może być problem z kierunkiem — Googlebot wydaje 40% budżetu na niepotrzebne strony (pagination tagów, stare komentarze, duplikaty session ID), zamiast na strategiczny content.

Co sprawdzić w małym serwisie

1. Procent żądań bota na strony spoza głównej struktury (admin, paginacje, feed).
2. Czy sitemap zawiera tylko strony strategiczne (zero śmieci).
3. Czy robots.txt blokuje parametry URL (utm_source, session_id).
4. Czy nie ma nieskończonych pętli paginacji.

Narzędzia do zarządzania crawl budgetem

W 2026 roku narzędziowy stack dla crawl budget składa się z trzech warstw: monitoring, analiza logów i symulacja. Dla polskich zespołów SEO pokazujemy widełki cenowe i alternatywy.

Warstwa 1: monitoring (darmowe + Search Console)

• Google Search Console — raport „Statystyki indeksowania” (darmowe, must-have).
• Bing Webmaster Tools — raport crawl (darmowe, pokazuje inne boty).
• GSC API — automatyzacja raportów do własnego dashboardu.

Warstwa 2: analiza logów (płatne)

• Screaming Frog Log Analyzer — 99 GBP rocznie, dobra na start.
• Oncrawl — od 99 EUR/miesiąc, zaawansowana segmentacja.
• Botify — enterprise, 2 000 EUR+/miesiąc, dla serwisów 500k+ URL-i.

Warstwa 3: symulacja (crawler + analiza)

• Screaming Frog SEO Spider — 149 GBP rocznie, symuluje bota na 500k+ URL-i.
• Sitebulb — 13,5 USD/miesiąc, wizualizacja architektury.
• DeepCrawl (Lumar) — enterprise, dla serwisów z 1 mln+ URL-i.

Najczęstsze błędy w zarządzaniu crawl budgetem

Audyty techniczne, które robimy klientom, pokazują te same błędy w 7 na 10 przypadków. Lista poniżej to checklist, który wychwytuje 85% problemów.

• Brak canonical na stronach filtrowanych. E-commerce często generuje 10–100× więcej URL-i niż produktów.
• Robots.txt blokujący CSS/JS. Bot nie renderuje strony, treść dynamiczna nie trafia do indeksu.
• Sitemap z błędami lastmod. Wszystkie strony z tą samą datą = bot ignoruje sitemap.
• Nieskończone pętle paginacji. Paginacja bez ograniczenia generuje pętlę, która zjada 40%+ budżetu.
• Strony archived bez 410. Usunięte produkty z 200 OK i pustą treścią = bot skanuje w nieskończoność.
• Redirect chains 3+. Każde przekierowanie to oddzielne żądanie HTTP.
• Brak noindex na stronach podziękowań/koszyk. Boty skanują, choć nie powinny.

FAQ — najczęstsze pytania

Czym jest crawl budget w jednym zdaniu?

Crawl budget to liczba URL-i, które Googlebot gotów jest odwiedzić w twojej domenie w ciągu 24 godzin, wypadkowa technicznych możliwości serwera (crawl rate limit) i „głodu” bota na treści domeny (crawl demand). Dla serwisów do 10 000 URL-i zazwyczaj nie jest problemem — Google skanuje całość. Dla serwisów większych (50 000+ URL-i) niewłaściwe zarządzanie odcina 15–40% treści od indeksacji. Pierwszym miernikiem jest raport „Statystyki indeksowania” w Google Search Console — średnia dzienna liczba żądań bota.

Jak sprawdzić crawl budget własnego serwisu?

Trzy źródła sygnału razem. Po pierwsze: Search Console — Settings → Crawling → Statystyki indeksowania. Pokazuje średnią dzienną liczbę żądań, rozmiar pobrany i czas odpowiedzi. Po drugie: logi serwera filtrowane na user-agent „Googlebot” — najdokładniejsze źródło, pokazuje każde żądanie. Po trzecie: stosunek URL-i w sitemap do zindeksowanych (poniżej 70% to sygnał alarmowy). Zestaw narzędzi: GSC (darmowe), Screaming Frog Log Analyzer (99 GBP/rok), Oncrawl (99 EUR+/miesiąc). Raport miesięczny w trendzie pokazuje, czy budżet rośnie czy spada.

Jak zwiększyć crawl budget w praktyce?

Dwie strategie. Po stronie infrastruktury: TTFB poniżej 400 ms, zero błędów 5xx, HTTP/2 lub HTTP/3, stabilne czasy odpowiedzi (wariancja pod 20%). Po stronie treści i linków: świeżość pillarów (aktualizacje co 6 miesięcy), linki zewnętrzne DR 40+, linkowanie wewnętrzne z flat architecture (maks. 3 kliki od homepage), podnoszenie topical authority klastra. Dla 85% serwisów w Polsce ograniczeniem jest crawl demand, nie rate limit — czyli to sygnały jakościowe podnoszą budżet, nie szybszy serwer. Efekty widać w 30–60 dni w raporcie Search Console.

Czy crawl budget dotyczy tylko dużych serwisów?

Poniżej 10 000 URL-i crawl budget rzadko jest wąskim gardłem, ale kierunek budżetu tak. Nawet mały blog może marnować 40% żądań bota na paginacje tagów, stare komentarze i session IDs — a nie na strategiczny content. Dla małego serwisu checklist to: (a) procent żądań na strony spoza struktury głównej, (b) zawartość sitemap (tylko strategiczne strony), (c) robots.txt blokujący parametry URL (utm, session_id), (d) brak nieskończonych pętli paginacji. Dobrze zarządzany crawl budget w małym serwisie przekłada się na szybszą indeksację (24 h zamiast 7 dni) i większą częstotliwość odwiedzin per artykuł.

Czy Googlebot i GPTBot mają wspólny crawl budget?

Nie. Każdy bot ma osobny budżet i osobne zasady. Googlebot, Bingbot, GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Google-Extended (osobny od Googlebota, dla AI Overviews) — każdy skanuje niezależnie. Serwis musi obsłużyć wszystkie boty (łącznie bywają 1,5–3× intensywniejsze od samego Googlebota). W 2026 roku zespoły dev monitorują logi per user-agent i dla niektórych botów świadomie ograniczają rate przez robots.txt — szczególnie dla botów AI bez bezpośredniego ROI. Uwaga: zablokowanie Google-Extended może wycofać domenę z AI Overviews.

Czy paginacja zjada crawl budget?

Tak, ale nie w oczywisty sposób. Paginacja kategorii w e-commerce (produkt/strony 1–20) jest naturalna i Google skanuje ją rozsądnie. Problem zaczyna się przy paginacji tagów bloga (/tag/seo/page/27/), paginacji wyników wyszukiwania wewnętrznego i paginacji filtrów fasetowych. Te trzy źródła mogą wygenerować 10–100× więcej URL-i niż strategicznych stron. Rozwiązania: noindex na paginacjach poza stroną pierwszą, canonical na paginowanych widokach filtrów, blokada /search/ w robots.txt. Po wdrożeniu tej trójki crawl rate strategicznych stron często rośnie o 30–80%.

Crawl budget a JavaScript — co trzeba wiedzieć?

Googlebot skanuje w dwóch fazach: najpierw pobiera HTML (crawl budget), potem renderuje JS (render budget). Strona SPA z React/Vue może być skanowana, ale bez wyrenderowania JS treść nie trafi do indeksu. Render budget jest zasobem odrębnym i dużo mniejszym od crawl budgetu. Best practice 2026: SSR (server-side rendering) dla kluczowych stron, SSG (static site generation) dla blogów, ISR (incremental static regeneration) dla hybrydowych. Next.js, Remix, Nuxt domyślnie wspierają SSR/SSG. Pure client-side SPA to 2–5× niższa indeksowalność niż SSR na tym samym serwisie.

Co dalej

Techniczne zarządzanie crawl budgetem to fundament, ale nie całość widoczności. Kiedy bot skanuje domenę optymalnie, kolejnym krokiem jest podniesienie crawl demand przez sygnały jakościowe. Pogłębcie temat topical authority — definicji i praktyki, bo to właśnie autorytet tematyczny wywołuje wzrost crawl demand. Następnie przyjrzyjcie się E-E-A-T i jego wpływowi na rankingi, żeby poukładać jakościową warstwę klastra. Dla zespołów, które mierzą ROI działań technicznych i jakościowych razem z PPC, polecamy tekst o różnicach między ROAS, ROI i POAS. Pełny obraz pojęć z SEO, PPC i AIO znajdziecie w słowniku marketingu cyfrowego 2026.