Crawl budget w praktyce 2026 - pomiar i optymalizacja

Crawl budget w praktyce to jedno z najczęściej źle rozumianych pojęć w SEO. Dla 95% stron w Polsce (blogi, małe e-commerce, portale do 10 tys. URL) crawl budget nie jest wąskim gardłem. Dla pozostałych 5% (duże portale, marketplace’y, sklepy z 500 tys. SKU) to kluczowy czynnik widoczności – niezrozumiany prowadzi do strat 40-80% potencjalnego ruchu.

Ten artykuł pokazuje, jak zmierzyć crawl budget w logach serwera i Google Search Console, kiedy ma realne znaczenie i jak go optymalizować. Uzupełnia on przewodnik SEO podstawy 2026, który kontekstualizuje crawl budget w szerszym ujęciu indeksacji.

W skrócie

Crawl budget = liczba URL, które Googlebot odwiedza na Waszej domenie w określonym okresie.
Składa się z crawl capacity (ile serwer wytrzyma) + crawl demand (ile Google chce).
Dla stron do 10 tys. URL – zwykle nie jest problemem.
Dla >100 tys. URL – kluczowy czynnik. Optymalizacja daje 30-70% więcej indeksacji.
Pomiar: logi serwera (najdokładniej), Search Console > Crawl Stats (dobre przybliżenie).

Czym jest crawl budget

Crawl budget to termin opisujący, ile URL na Waszej stronie Googlebot jest w stanie i chce odwiedzić. Składa się z dwóch komponentów.

Crawl capacity limit – ile requestów Googlebot może wysłać, żeby nie przeciążyć serwera. Google sam zmniejsza tempo, jeśli serwer zwalnia lub zwraca 5xx.

Crawl demand – ile URL Google chce odwiedzić. Zależy od popularności (popularne strony są crawlowane częściej), świeżości (często zmieniane = częściej odwiedzane), staleness (dawno niewidziane = priorytet).

Iloczyn tych dwóch daje efektywny crawl budget. Zwiększenie capacity (szybszy serwer) i demand (więcej linków, świeższy content) podnosi budget.

Kiedy crawl budget ma znaczenie

Google oficjalnie stwierdza, że dla stron do kilku tysięcy URL crawl budget zwykle nie jest problemem. W praktyce wyróżniamy trzy progi.

Rozmiar strony (URL)	Czy crawl budget matter	Co robić
< 1 000	Nie	Skupcie się na jakości content i linkach
1 000 – 10 000	Rzadko	Monitoring co 3-6 miesięcy w GSC
10 000 – 100 000	Czasami	Regularny audyt, optymalizacja robots.txt
100 000 – 1 000 000	Tak	Monthly review logów, architektura pod crawl
> 1 000 000	Kluczowe	Weekly monitoring, dedicated crawl engineer

Jak zmierzyć crawl budget

Dwie metody – od szybkiej do dokładnej.

Metoda 1 – Google Search Console Crawl Stats

Najłatwiejsza droga. W GSC: Ustawienia > Crawl stats. Raport pokazuje:

Total crawl requests per day (ostatnie 90 dni).
Total download size.
Average response time.
Breakdown by file type (HTML, CSS, JS, images).
Breakdown by purpose (refresh vs discovery).
Breakdown by HTTP response (200, 301, 404, 5xx).

Dla średniej strony widzicie 1000-20 000 requests/dzień. Stabilne wartości = zdrowy crawl. Duże spadki (-40% w tydzień) sygnalizują problem (serwer, robots.txt, sitemap).

Metoda 2 – logi serwera

Najdokładniejsze źródło danych. Log serwera (Apache, Nginx, Cloudflare) zawiera każdy request – z User-Agent, timestampem, URL, response code.

Proces:

Pobierz logi z ostatnich 30 dni (zwykle 500 MB – 50 GB dla średniej strony).
Zaimportuj do narzędzia: Screaming Frog Log File Analyzer, Semrush Log File Analyzer, albo własny parser w Python.
Filtruj po User-Agent: Googlebot, Googlebot-Image, Googlebot-Mobile, AdsBot-Google.
Analiza: które URL są crawlowane, jak często, ile czasu zajmuje response, jakie response codes.

Typowe znaleziska: 30-60% crawl budget idzie na strony bezużyteczne (archiwa tagów, filtry sklepu, paginacja bez canonical). Optymalizacja uwalnia budget na strony, które rzeczywiście powinny być indeksowane.

Najczęstsze marnotrawcy crawl budget

W audytach dużych stron identyfikujemy powtarzające się wzorce marnotrawstwa budget.

Faceted navigation w e-commerce

Sklep z 5000 produktów w 20 kategoriach i 10 filtrami generuje teoretycznie 10^6 URL (każda kombinacja filtrów). Googlebot marnuje ogromną część budget na filtrowane strony.

Naprawa: noindex + robots.txt disallow dla kombinacji 2+ filtrów, canonical do kategorii głównej, parametryzacja przez query string zamiast czystych URL.

Wewnętrzne wyszukiwarki

Strony wyników wyszukiwania (/?s=keyword) to nieskończenie wiele URL. Googlebot natrafia na nie przez linki wewnętrzne, indeksuje, marnuje budget.

Naprawa: robots.txt disallow dla /?s=, noindex na template wyników wyszukiwania.

Paginacja archiwów

Archiwum bloga z 500 artykułami paginowanymi po 10 = 50 stron archiwum. Googlebot odwiedza wszystkie, indeksuje, generując duplikat.

Naprawa: noindex na paginated pages (strona 2+), albo canonical do głównej strony archiwum.

Tagi

WordPress domyślnie generuje URL dla każdego tagu. Portal z 10 000 artykułów i 500 tagami ma 500 stron tagów, każda z paginacją.

Naprawa: noindex na tagach (większość nie ma wartości SEO), usunięcie tagów bez contentu.

Session IDs i tracking parametry

URL typu /produkt/?sessionid=xyz lub /?utm_source=fb to technicznie różne URL dla Googlebot. Bez canonical – generują masowe duplikaty.

Naprawa: canonical do czystej wersji URL, robots.txt disallow dla parametrów, URL Parameters tool w GSC.

Optymalizacja crawl budget – kolejność działań

Po identyfikacji marnotrawców, systematyczna optymalizacja. Szczegóły metodologii w podstawach crawlowania i indeksowania.

Szybki serwer – TTFB < 200ms, cache na wszystkich statycznych zasobach.
Czysta sitemapa – tylko URL 200 OK, priorytetowe strony, aktualizacja datetimeów.
Robots.txt optymalny – disallow marnotrawcy, allow strategic paths.
Canonical tags – self-canonical na każdej stronie, duplikaty do głównych.
Architektura linków – wszystkie ważne URL dostępne w maksymalnie 3 kliknięciach od home.
Usuwanie thin content – 410 Gone dla stron bez wartości.
Optymalizacja response codes – 301 zamiast łańcucha, brak 5xx.

Robots.txt dla crawl budget optimization

Robots.txt to pierwsza linia obrony. Przykładowy plik dla sklepu e-commerce z 50 000 produktów.

User-agent: *
Disallow: /search
Disallow: /*?s=
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /cart
Disallow: /checkout
Disallow: /my-account
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

User-agent: Googlebot
Crawl-delay: 0

Sitemap: https://example.com/sitemap.xml

Reguły: disallow dla ścieżek bez wartości SEO (search, filters, checkout), allow dla kluczowych dynamic endpoints (admin-ajax dla WordPressa), sitemapa na końcu.

Uwaga: robots.txt nie jest gwarancją noindex. URL zablokowany w robots.txt może nadal pojawić się w indeksie (bez treści, z opisem „URL zablokowany”). Dla pełnego noindex używajcie meta noindex.

Sitemapa – optymalizacja pod crawl

Sitemapa to propozycja Wasza dla Googlebota – tu są URL, które warto odwiedzić. Dobra sitemapa:

Zawiera tylko strony 200 OK (nie 404, nie redirect, nie noindex).
Ma prawidłowe datetime (lastmod) pokazujące, kiedy URL był ostatni raz zmieniony.
Priorytety (priority) ustawione rozsądnie – nie 1.0 dla wszystkiego.
Segmentowana dla dużych stron – sitemap index + dziesiątki mniejszych (do 50 000 URL każda).
Zawiera wszystkie ważne URL (nie tylko posty, ale też kategorie, autorzy, główne pages).

Generatory (RankMath, Yoast dla WordPressa) zwykle radzą sobie dobrze. Dla custom CMS – napiszcie własny generator z uwzględnieniem powyższych reguł.

Wpływ szybkości serwera na crawl budget

Googlebot redukuje crawl rate, jeśli serwer odpowiada wolno (powyżej 500-1000ms TTFB) lub zwraca błędy. To bezpośredni wpływ na crawl capacity.

Dane z naszych audytów (150 polskich stron):

Strony z TTFB < 200ms: crawl rate 5-15 requests/sekunda.
Strony z TTFB 200-500ms: crawl rate 2-5 requests/sekunda.
Strony z TTFB 500-1500ms: crawl rate 0.5-2 requests/sekunda.
Strony z TTFB > 1500ms: crawl rate < 0.5 request/sekunda, częste spadki visibility.

Przyspieszenie serwera (z 1500ms do 300ms TTFB) daje 3-5x więcej crawl budget. Dla dużego sklepu to różnica między indeksacją 30% a 90% katalogu produktów.

Jak sprawdzić, czy Google indeksuje wszystko, co chcecie

Crawl to nie to samo co indeks. URL może być crawlowany, ale nie trafić do indeksu.

Proces weryfikacji:

GSC > Indeksowanie stron – raport „Not indexed”. Kategorie: „Crawled – not indexed”, „Discovered – not indexed”, „Duplicate without user-selected canonical”.
„Crawled – not indexed” = Googlebot odwiedził URL, ale nie uznał go za wartościowy. Naprawa: rozbudowa treści, dodanie linków wewnętrznych, schema.
„Discovered – not indexed” = Googlebot wie o URL, ale jeszcze nie odwiedził. Sygnał crawl budget – zbyt dużo URL, priorytet niski.
„Duplicate” = Google wybrał inny URL jako canonical. Naprawa: explicit canonical, redirect duplikatów.

Case study – sklep z 300 tys. SKU

Sklep e-commerce z 300 000 produktów. Problem: tylko 85 000 indeksowanych, 215 000 „Discovered – not indexed”. Oznaczało to brak widoczności dla 71% asortymentu.

Audyt logów serwera ujawnił:

45% crawl budget szło na filtrowane URL (cena, kolor, rozmiar).
20% na wewnętrzne wyszukiwarki (/?s=).
12% na paginację archiwów i tagów.
Tylko 23% na realne strony produktów.

Optymalizacja wdrożona w 60 dni:

Robots.txt disallow dla filtrów, search, paginated tagów.
Canonical dla wszystkich wariantów produktów (kolor, rozmiar = canonical do głównego).
Pruning 40 000 stron produktów out-of-stock bez alternatyw (410 Gone).
Optymalizacja sitemapy – segmentacja po kategoriach, regeneracja.
Przyspieszenie serwera (TTFB z 800ms do 250ms).

Wynik po 90 dniach: 245 000 URL indeksowanych (82% asortymentu, +160 000 URL). Ruch organic +85% w 6 miesiącach.

Narzędzia do analizy crawl budget

Narzędzie	Co robi	Koszt
Search Console Crawl Stats	Podstawowy monitoring crawl, request history	0 zł
Screaming Frog Log File Analyzer	Analiza logów serwera, identyfikacja marnotrawców	99 GBP/rok
Semrush Log File Analyzer	Analiza logów + integracja z crawl data	w pakiecie Agency 449 USD/mc
Botify	Enterprise log analysis + site crawl	od 3000 USD/mc
OnCrawl	Log + crawl + SEO analytics	od 199 EUR/mc
Splunk	General log analytics (non-SEO)	od 2000 USD/mc

Dla małych stron wystarczy GSC Crawl Stats. Dla średnich – Screaming Frog Log Analyzer. Dla enterprise – Botify lub OnCrawl.

Crawl budget a AIO – nowy wymiar w 2026

W 2026 nie tylko Googlebot odwiedza Waszą stronę. Klaster crawlerów AI (ChatGPT, Perplexity, Anthropic, Common Crawl, CCBot) dokłada własne obciążenie.

Sygnały z logów 2024-2026:

GPTBot (OpenAI): 3-8% całkowitego ruchu crawlerów.
ClaudeBot (Anthropic): 2-5%.
PerplexityBot: 1-3%.
CCBot (Common Crawl): 5-10% (feeds większość LLM).
Googlebot pozostaje dominujący: 50-70%.

Dla crawl budget oznacza to: więcej requestów na serwer, więcej możliwych konfliktów z capacity. Strategia: szybki serwer (dobra capacity), selektywna dopuszczalność crawlerów przez robots.txt. Dla większości stron – pozwalajcie wszystkim (widoczność w AI to przyszłość).

Więcej o crawlerach AI w przewodniku o wyszukiwarkach AI.

Crawl budget dla news sites

Portale newsowe mają specyficzne wymagania. Google News chce indeksować nowe artykuły w minutach, nie godzinach.

Optymalizacje dla news:

News sitemap – oddzielna sitemapa z artykułami z ostatnich 48 godzin.
Instant indexing API (dostępne dla job postings i livestreaming, ograniczone dla news).
RSS feed – dobrze uformowany, aktualizowany natychmiast po publikacji.
Internal linking – z homepage i top categories do nowych artykułów.
Schema NewsArticle – włącza Top Stories eligibility.

Dla news sites typowy cel: indeksacja nowego artykułu w 5-30 minut od publikacji. Opóźnienie 2+ godziny oznacza utratę 40-80% potencjalnego early traffic.

Crawl budget w migracji

Migracja domeny lub struktury URL wymaga crawl budget planning. Googlebot musi odwiedzić stare URL (żeby zobaczyć 301), nowe URL (żeby zindeksować), a total traffic crawlowy wzrasta 2-3x w pierwszych miesiącach.

Planowanie:

Mapa 301 – każdy stary URL do nowego, bez łańcuchów.
Nowa sitemapa wysłana w GSC natychmiast.
Change of Address w GSC dla migracji domeny.
Stare URL dostępne w sitemapie przez 14-30 dni po migracji (żeby Googlebot znalazł redirects).
Monitoring GSC – indexing status dla starej i nowej domeny.

Typowy okres pełnej adopcji: 30-90 dni dla małych stron, 6-12 miesięcy dla dużych.

Sygnały alarmowe – kiedy reagować

Nie każdy spadek crawl rate to problem. Ale sygnały, które wymagają szybkiej reakcji:

-50% crawl rate w tydzień – prawdopodobnie problem techniczny (serwer, robots.txt, błąd).
Wzrost 5xx errors w GSC crawl stats – serwer przeciążony.
Plateau crawl rate po dodaniu 10 000+ URL – crawl budget wyczerpany, optymalizacja potrzebna.
Long-tail URL nie wchodzą do indeksu mimo sitemapy – niedostateczny demand, brak linków wewnętrznych.
Wzrost „Discovered – not indexed” – Google wie o URL, ale nie priorytetyzuje ich do crawlu.

Monitorujcie te metryki weekly (dla dużych stron) lub monthly (dla średnich).

Mit crawl budget – rzeczy, o które NIE musicie się martwić

Po latach audytów widzimy powtarzające się mity, które zjadają czas zespołów SEO.

„Musimy zmniejszyć liczbę linków na stronie, bo crawl budget” – Google crawluje linki szybko, 50 vs 100 linków na stronie to pomijalna różnica.
„Pagespeed wpływa tylko na ranking, nie na crawl” – mylne, pagespeed bezpośrednio wpływa na crawl capacity.
„Robots.txt disallow natychmiast usuwa URL z indeksu” – nie, disallow tylko blokuje nowy crawl, indeksowane URL zostają.
„Crawl budget = indexation budget” – nie, to dwie różne rzeczy. URL może być crawlowany, ale nie indeksowany.
„Mniejsza strona = lepsze SEO” – nie zawsze, pruning ma sens dla thin content, nie dla kompletnych wartościowych stron.

FAQ – crawl budget w praktyce

Jak często Googlebot odwiedza moją stronę?

Zależy od popularności i świeżości. Mała strona (100 URL) – zwykle 50-500 requests/dzień. Średni portal (10 000 URL) – 2000-10 000 requests/dzień. Duży sklep (100 000+ URL) – 20 000-200 000 requests/dzień. Search Console > Ustawienia > Crawl stats pokazuje dokładne dane dla Waszej domeny. Częstotliwość pojedynczego URL: popularne strony (dużo linków) co dzień, średnie raz na 3-14 dni, thin content raz na 30-180 dni.

Czy mogę poprosić Google o więcej crawl budget?

Nie ma oficjalnego mechanizmu zwiększenia budget. Ale możecie wpłynąć pośrednio: szybszy serwer (zwiększa capacity), więcej backlinków (zwiększa demand), regularne publikacje świeżego content (zwiększa demand), clean sitemap (zwiększa efektywność crawlu). Google sam dostosowuje budget do jakości i popularności – nie ma dźwigni do pociągnięcia. Historically Google zdjął URL parameters tool, który pozwalał na fine-tuning – teraz polegamy na robots.txt i canonical.

Co robić, gdy mam dużo stron „Discovered – not indexed”?

To sygnał crawl budget lub quality issue. Trzy możliwe przyczyny: (1) zbyt dużo URL, Google priorytetyzuje – pruning thin content, disallow marnotrawców. (2) Content niskiej jakości – Googlebot wie o URL, ale ocenia jako niewartościowe, nie crawluje. Naprawa: rozbudowa content. (3) Słabe linkowanie wewnętrzne – orphan pages. Naprawa: dodanie inline linków z innych stron. Dla dużych stron często kombinacja wszystkich trzech.

Czy crawl-delay w robots.txt działa z Googlebot?

Nie. Google ignoruje dyrektywę crawl-delay w robots.txt. Bing ją respektuje. Dla Google kontrolujecie crawl rate przez GSC > Settings > Crawl rate (dawniej Crawl Settings, obecnie adaptive). Google automatycznie dostosowuje rate do serwera – jeśli widzi 5xx errors albo powolne response, sam zmniejsza. Manual control rzadko potrzebny; ma sens tylko dla bardzo obciążonych serwerów w specyficznych scenariuszach.

Jak crawl budget wpływa na nowe strony?

Nowe URL mają niższy crawl priority niż istniejące, dobrze lincowane strony. Typowy czas od publikacji do indeksu: 1-24 godziny (popularna domena), 1-14 dni (przeciętna), 30-90 dni (słaba domena bez linków). Przyspieszenie: sitemap update po publikacji, wewnętrzne linki z popular pages, zgłoszenie przez URL Inspection Tool w GSC, social signals (udostępnienie na X/LinkedIn przyspiesza discovery). Dla news sites – news sitemap i schema NewsArticle dają najszybszy path.

Czy duża strona zawsze ma problem z crawl budget?

Nie. Duże strony dobrze zoptymalizowane (szybki serwer, clean sitemap, sensowny robots.txt, silna architektura linków) indeksują 90-100% wartościowych URL. Problem crawl budget pojawia się, gdy strona ma masę low-value URL (filtry, paginacja, duplikaty) albo wolny serwer. Facebook ma miliardy stron i nie ma crawl budget issue – bo każdy URL jest strategicznie linkowany i optymalizowany. Skala nie jest problemem, chaos jest problemem.

Czy warto używać noindex dla wszystkich kategorii i tagów?

Nie dla kategorii – dobre kategorie z unikalnym contentem są ważne SEO. Dla tagów – często tak, szczególnie jeśli są masowo generowane bez własnej wartości. Kategoria z 500 słowami opisu, listą artykułów i FAQ = wartościowa, indeksowana. Tag z 10 artykułów i generycznym tytułem = noindex. Reguła: każda strona powinna mieć raison d’être SEO. Jeśli nie rankuje, nie przyciąga ruchu i nie niesie wartości – noindex.

Czy crawl budget wpływa na ranking?

Pośrednio. Crawl budget wpływa na indexation – URL niezindeksowany nie rankuje. URL crawlowany rzadko – jego content Google widzi jako „stary” (staleness). Dla YMYL i news stale content traci pozycje. Dla evergreen content wpływ jest minimalny. Bezpośrednio: crawl frequency per URL jest jednym z hundreds signali ranking, ale nie dominującym. Optymalizacja crawl budget przekłada się na ranking głównie przez zwiększoną liczbę zindeksowanych, świeżych stron.

Analiza logów krok po kroku – praktyczny przykład

Pokażemy konkretną analizę logów dla portalu z 50 000 URL. Dane: 7 dni logów Nginx, 2.4 GB plików, ~800 000 requestów od crawlerów.

Krok 1 – parsing

Używamy Screaming Frog Log File Analyzer. Import 7 plików logów. Weryfikacja User-Agent dla Googlebota (reverse DNS lookup, żeby odfiltrować fake bots).

Wynik po parsingu: 620 000 verified Googlebot requestów, 180 000 innych (Bing, AI crawlers, scrapers).

Krok 2 – segmentacja URL

Grupujemy URL po pattern:

/artykul/* (posty blog): 180 000 requestów (29%).
/kategoria/*: 85 000 requestów (14%).
/tag/*: 120 000 requestów (19%).
/?s=* (search): 45 000 requestów (7%).
/strona/*/?*filter=*: 75 000 requestów (12%).
/wp-content/* (static assets): 55 000 requestów (9%).
Inne: 60 000 requestów (10%).

Wnioski: 38% budget idzie na tagi, search, filter – strony bez wartości SEO. Pruning i robots.txt zablokuje 236 000 zmarnowanych requestów tygodniowo.

Krok 3 – response codes

Breakdown:

200 OK: 92%.
301 redirect: 4%.
404 not found: 2.5%.
410 gone: 0.8%.
5xx errors: 0.7%.

404 na 2.5% to OK. 5xx na 0.7% – w granicach tolerancji, ale warto zdiagnozować (typowo: peak traffic moments, timeout na slow queries).

Krok 4 – crawl frequency per URL

Dla top 100 URL (najczęściej crawlowanych):

Homepage: 210 requestów/tydzień.
Top 10 kategorii: 80-150 requestów/tydzień każda.
Top 20 artykułów: 40-80 requestów/tydzień każdy.
Długi ogon artykułów (4000 URL): 0-3 requesty/tydzień.

Problem: 70% artykułów crawlowana raz na 14-30 dni. Dla news content to za rzadko. Naprawa: więcej linków wewnętrznych do świeższych artykułów, news sitemap, refresh old content.

Crawl budget dla SPA i JavaScript-rendered stron

Single-Page Applications (Next.js, React, Vue) mają specyficzne wyzwania crawl budget. Googlebot renderuje JavaScript w dwóch fazach: pierwsze skanowanie HTML, potem rendering w Chromium headless (dzień później).

Problemy crawl budget w SPA:

2x więcej resources – Googlebot musi pobrać HTML + JS + run rendering.
Wolniejsze discovery – linki w JS są discovered później niż w czystym HTML.
Gorszy crawl rate – capacity naturalnie ograniczony przez koszt renderingu.

Rozwiązania:

Server-Side Rendering (SSR) – Next.js getServerSideProps, Nuxt asyncData. HTML dostępny od razu, bez renderingu.
Static Site Generation (SSG) – pre-rendering w build time. Najlepszy wybór dla content-heavy stron.
Dynamic rendering – różne wersje dla user vs bot. Oficjalnie wspierane, ale Google rekomenduje SSR/SSG.
Hybrid rendering – krytyczne strony SSR, reszta CSR.

Dla sklepu e-commerce z 100 000 SKU: SSG top 1000 produktów + SSR kolejne 10 000 + CSR tail. Balans między performance build time a crawl efficiency.

Crawl budget i międzynarodowe SEO

Strony z wieloma wersjami językowymi (hreflang) multiplikują liczbę URL. 5000 artykułów x 8 języków = 40 000 URL, każdy wymagający crawl i index.

Strategia crawl budget dla international:

Separate sitemaps per język – łatwiejsza priorytetyzacja, monitoring per country.
Hreflang tags – pomaga Googlebotowi rozumieć relacje między wersjami, mniej „duplicate content” false positive.
Content sync – jeśli tylko część artykułów jest tłumaczona, sitemapa pokazuje tylko istniejące wersje.
Subfolder vs subdomain vs ccTLD – wpływa na crawl capacity sharing. ccTLD to oddzielne domeny z niezależnym budget.

Dla enterprise z 30+ krajów crawl engineering staje się full-time role. Dla małych firm (2-3 języki) – standardowe praktyki wystarczą.

Monitoring crawl budget – dashboard wzorcowy

Dla dużych stron (>100 000 URL) rekomendujemy stały dashboard. Narzędzia: Google Data Studio, Looker Studio, Tableau. Źródła danych: GSC API + logi serwera.

Kluczowe metryki na dashboardzie:

Daily crawl rate – total requests per day, trend 30 dni.
Crawl rate by URL pattern – jakie ścieżki dominują.
Crawl rate vs indexation – ile z crawlowanych URL jest indeksowanych.
Average response time – proxy dla serwer health.
5xx errors rate – alert przy >1%.
„Discovered not indexed” count – weekly trend.
Sitemap coverage – % URL w sitemapie które są indeksowane.
Crawl budget waste – % requestów na noindex/disallow URL.

Alerty: -20% crawl rate w 7 dni, +50% 5xx errors, +100 000 „Discovered not indexed”, pojawienie się nowych URL patternów w logach.

Crawl budget dla marketplace’ów

Marketplace (Allegro, Amazon, OLX-type) to najtrudniejszy scenariusz crawl budget. Miliony URL, wiele sellers, dynamic listings – każda decyzja techniczna ma ogromną skalę.

Kluczowe wyzwania:

Out-of-stock items – co robić z URL, gdy produkt zniknie. 404 traci PageRank, 410 jest prawidłowe ale kosztuje linki. Redirect do kategorii działa najlepiej dla 90% przypadków.
Duplicate listings – ten sam produkt od 20 sellers. Canonical do „buy box” wersji.
Parametryzacja – filtry (cena, marka, kolor) generują niezliczone kombinacje. Tylko popularnе combinations w sitemapie.
Seller pages – strony sprzedawców. Często thin, duplicate description z produktu. Noindex dla większości.

Marketplace’y klasy Allegro mają dedykowane zespoły 5-15 engineers od crawl/index. Mniejsze platformy stosują zasadę 80/20: optymalizacja top 20% URL, które dają 80% ruchu.

Historia i ewolucja crawl budget

Zrozumienie ewolucji pomaga w projekcji przyszłych zmian. Kluczowe kamienie milowe:

2009 – Matt Cutts pierwszy raz publicznie używa terminu „crawl budget”.
2017 – Gary Illyes oficjalny post na Google Webmaster Central o crawl budget.
2020 – Adaptive Crawl Rate: Google przestaje pozwalać na manual crawl rate setting.
2021 – usunięcie URL Parameters tool z GSC.
2023 – wprowadzenie IndexNow protocol dla real-time indexing signals.
2024 – lepsza integracja crawl signals z Core Updates, większa waga dla crawl efficiency.
2026 – AI crawlers (GPTBot, ClaudeBot) stają się 10-15% całkowitego crawl traffic.

Trend: coraz mniej manualnej kontroli dla SEO, coraz więcej automatyzacji po stronie Google. Nasze narzędzia to pośrednie sygnały (serwer, linki, sitemapa), nie bezpośrednia kontrola.

Checklist pre-optymalizacji crawl budget

Zanim zaczniecie optymalizację crawl budget, zweryfikujcie, że problem jest realny. Checklist 10 pytań:

Czy strona ma >10 000 URL? Jeśli nie, crawl budget rzadko jest problemem.
Czy w GSC „Discovered – not indexed” przekracza 20% wszystkich URL?
Czy „Crawled – currently not indexed” przekracza 10%?
Czy TTFB serwera przekracza 500ms?
Czy sitemapa zawiera >80% wartościowych URL?
Czy robots.txt blokuje oczywistych marnotrawców (search, filters, admin)?
Czy canonical tags są prawidłowo ustawione?
Czy nowe artykuły są indeksowane w <24 godziny?
Czy GSC Crawl Stats pokazuje stabilny trend bez dużych wahań?
Czy logi serwera pokazują rozsądny breakdown crawlu per URL pattern?

Jeśli odpowiedzieliście „nie” na 4+ pytania – czas na optymalizację. Jeśli na 1-3 – mała optymalizacja, duży impact. Jeśli na 0 – crawl budget nie jest Waszym problemem, skupcie się na innych aspektach SEO.

Co dalej

Crawl budget to narzędzie dla dużych stron, nie uniwersalna optymalizacja. Po zmierzeniu, gdzie Wasz crawl idzie, wróćcie do pillara SEO podstawy 2026, który kontekstualizuje crawl w szerszym planie SEO. Dla głębszego zanurzenia w mechanikę indeksacji sięgnijcie po podstawy crawlowania i indeksowania, a jeśli zarządzacie sklepem – po przewodnik SEO dla e-commerce.