Indeksacja i crawl budget: diagnostyka i optymalizacja

Crawl budget to jeden z najmniej zrozumianych mechanizmów SEO – dla małych stron (do 5000 URL) właściwie nie istnieje, dla dużych (100k+) jest najważniejszym czynnikiem decydującym o indeksacji nowych treści. Zły crawl budget objawia się tym, że publikujesz nowy produkt w sklepie i Google zauważa go po 14-30 dniach, podczas gdy konkurenci mają indeksację w 2-3 dni. Różnica w tempie indeksacji oznacza 2-4 tygodnie późniejsze zarabianie na nowym SKU – dla sklepów z wysoką rotacją asortymentu to dziesiątki milionów straconych rocznie.

Pokazujemy, jak zdiagnozować problemy z crawl budgetem (analiza logów serwera), jak je rozwiązywać (priorytetyzacja URL-i, blokowanie niepotrzebnych, CWV optimization) i jak mierzyć postępy. Na przykładach z 5 projektów e-commerce, portali informacyjnych i wielojęzycznych witryn.

W skrócie

Crawl budget = liczba URL-i, które Googlebot crawluje w twojej witrynie na dzień. Zależy od autorytetu domeny i CWV.
Problemy pojawiają się od 10-20k URL w indeksie, krytyczne od 100k+.
Główne źródła marnowania budgetu: filtry produktowe, paginacja, sortowanie, session IDs, duplicate content.
Optymalizacja crawl budgetu typowo skraca czas indeksacji nowych treści o 50-80%.
Monitoring: logi serwera (OnCrawl, Screaming Frog Log Analyser), Google Search Console Crawl Stats, Python analysis.

Czym dokładnie jest crawl budget

Crawl budget to liczba requestów (URL-i), które Googlebot wykonuje w twojej witrynie dziennie. Google nie publikuje oficjalnej liczby per domena, ale z analizy logów widać typowe zakresy:

Mała strona (500-2000 URL): 200-1000 requestów/dzień
Średnia (2k-20k URL): 2000-15000 req/dzień
Duża (20k-200k URL): 15k-80k req/dzień
Enterprise (200k+ URL): 80k-1M+ req/dzień

Crawl budget jest „elastyczny” – Google zwiększa go dla dobrze performujących witryn (wysoki autorytet, dobry CWV, mało błędów) i zmniejsza dla słabych. To oznacza, że optymalizacja CWV i jakości strony pośrednio zwiększa crawl budget, a z nim szybkość indeksacji.

Dla małych stron crawl budget nie jest problem – wszystkie URL są regularnie crawlowane. Problem pojawia się, gdy liczba URL przekracza dzienny budget – wtedy niektóre strony czekają tygodniami na crawl. Szerszy kontekst technicznego SEO w SEO techniczne 2026 – najważniejsze błędy.

Crawl rate limit vs crawl demand

Google dzieli crawl budget na dwa komponenty:

Crawl rate limit: maksymalna liczba równoczesnych connections i delay między requestami. Zależy od response time serwera – wolny serwer = Google zwalnia, żeby nie przeciążyć. Optymalizacja: szybki serwer (TTFB poniżej 200ms), CDN, caching. Efekt: Google może crawlować więcej URL-i na jednostkę czasu.

Crawl demand: ile Google chce crawlować twoją witrynę. Zależy od: popularity (traffic, backlinks), freshness (czy content się zmienia), stateness (czy Google widział ten URL niedawno). Popularne URL crawlowane częściej.

Twój realny crawl budget = min(rate limit, demand). Zwiększenie demand przez wyższy autorytet i freshness pushuje wyższy – ale bez rate limit (szybki serwer) efekt ograniczony.

Analiza logów serwera – kluczowa technika

Jedyny reliable sposób na zrozumienie crawl budgetu to analiza logów serwera. Screaming Frog crawl pokazuje, co MOŻESZ zaoferować Googlebotowi, logi pokazują, co GOOGLEBOT RZECZYWIŚCIE crawluje.

Proces analizy logów:

Export logów serwera za 30-90 dni (Apache, Nginx, IIS format).
Filter dla user-agent Googlebot (smartphone, desktop, image).
Parse logów – regex lub dedicated tools.
Grupowanie requestów per URL pattern.
Ranking URL po liczbie requestów.
Identyfikacja „crawl waste” – URL-e z dużą liczbą crawl, ale niska wartość.
Identyfikacja „crawl starvation” – ważne URL rzadko crawlowane.

Narzędzia: Screaming Frog Log Analyser (239 GBP/rok), OnCrawl (enterprise, 500-5000 USD/mies.), Splunk, ELK stack, Python + pandas dla custom analysis. Dla średnich sklepów Screaming Frog Log Analyser wystarczy, dla enterprise OnCrawl.

Typowe źródła crawl waste

W 12 logs audits, które zrobiliśmy w ostatnich 18 miesiącach, oto najczęstsze „crawl waste”:

Filtry produktowe (25-50% waste): każda kombinacja filtrów = unique URL. Sklep z 8 filtrami × średnio 10 wartości = miliardy kombinacji URL. Rozwiązanie: meta robots noindex + parameter handling w GSC.
Paginacja deep (10-20% waste): strony /page/50/ i dalej mają niski value, ale crawlowane. Rozwiązanie: ograniczenie paginacji, meta robots noindex po stronie 5+.
Sortowanie (5-15%): ?sort=price_asc to ten sam content w innym porządku. Rozwiązanie: canonical + noindex.
Session IDs i tracking params (3-10%): ?utm_source=, ?sessionid=. Rozwiązanie: canonical + parameter handling.
404 errors (2-8%): broken internal links prowadzą Googlebota w dead ends. Rozwiązanie: audit i fix wszystkich 404.
Redirect chains (1-5%): A → B → C zamiast A → C. Rozwiązanie: direct redirects.
Soft 404 (1-5%): strony zwracające 200 ale praktycznie puste. Rozwiązanie: właściwy 404 status lub naprawa content.
Staging / dev URLs (może być wiele): jeśli staging.site.com nie jest blokowane, Google tam chodzi. Rozwiązanie: robots.txt block + noindex.

W projekcie dla sklepu 180k produktów: przed audytem 78% crawl budgetu szło na filtry i paginację. Po implementacji polityki filtrów i paginacji: 22%. Crawl budget wolny zastąpiony przez crawling nowych produktów – indeksacja z 18 dni spadła do 3 dni.

Proces optymalizacji crawl budgetu – 10 kroków

Audit logów serwera (8-16 godzin) – identyfikacja głównych źródeł crawl waste.
URL taxonomy mapping (4-8 godzin) – każdy URL pattern = indexable lub non-indexable.
Polityka filtrów (16-40 godzin) – noindex dla non-valuable filtrów, canonical, parameter handling.
Paginacja strategy (8-16 godzin) – ograniczenie głębokości, noindex dla deep pages.
Fix 404 i redirect chains (8-20 godzin) – audit, 301 dla broken, direct redirects.
Sitemap optimization (8-16 godzin) – tylko indexable URLs, priority i changefreq (advisory).
Robots.txt refinement (4-8 godzin) – block staging, admin, dev URLs.
CWV improvement (40-120 godzin) – szybszy serwer, optymalizacja LCP, INP.
Internal linking refactor (20-60 godzin) – priority URLs dostają więcej inbound linków.
Monitoring setup (16-40 godzin) – dashboard tracking crawl requests, indexation, errors.

Total effort: 130-330 godzin dla średniej witryny. Koszt w agencji: 25-70 tys. zł. Zwrot: 30-70% szybsza indeksacja, +15-40% organic traffic w 6-12 miesięcy.

GSC Crawl Stats – co pokazuje

Google Search Console Settings > Crawl Stats pokazuje podstawowe dane o crawlingu twojej strony. Kluczowe reportowane metryki:

Total crawl requests per day: ostatnie 90 dni, z trendem.
Average response time: średnia TTFB per crawl (cel: <500ms).
Total download size: ile danych Google pobrał.
By response (status codes): 200, 301, 404, 500 – proportions.
By file type: HTML, CSS, JS, Image, PDF, etc.
By purpose: Discovery (nowe URL) vs Refresh (znane URL).
By Googlebot type: Smartphone, Desktop, Image, Ads.

Co analizować:

Trend total requests (stable = healthy, spadek = problem).
Response time trend (niskie = good, wysokie = bottleneck).
Status code distribution (chcesz 90%+ 200 i 301, max 5% 4xx/5xx).
Discovery vs Refresh ratio (zdrowe 30/70 do 50/50).
Image vs HTML proportion (zbyt wiele Image = waste dla text-heavy sites).

Więcej o diagnostyce przez Search Console w Search Console 10 raportów.

Core Web Vitals a crawl budget

CWV mają bezpośredni wpływ na crawl budget w dwie strony: (1) lepsze CWV = Google zwiększa crawl rate (więcej URL per sekundę), (2) gorsze CWV = Google ostrożniejszy (mniej URL aby nie przeciążyć serwera).

W projekcie dla portalu news (3200 artykułów, 800k URL z archiwum): LCP spadło z 4,2s do 1,8s w 8 tygodni pracy. Crawl budget wzrósł z 45k requestów/dzień do 78k. Oznacza to o 73% więcej URL crawlowanych dziennie – bez żadnej inwestycji w content. Sam CWV wystarczył, aby Google „dowiedział się”, że serwer szybki i warto crawlować więcej.

Praktyczne implikacje: CWV optimization to jedno z najtańszych sposobów zwiększenia crawl budgetu. Investment: 40-120 godzin pracy dev. Efekt: 30-80% więcej crawl budget, plus benefit w rankingu (CWV jest factor).

Meta robots noindex – kiedy używać

Meta robots noindex = „nie indeksuj tej strony”. Trzy poziomy:

noindex, follow: nie indeksuj, ale follow linki. Dla filtry parametryczne, paginacja głęboka. Zachowuje link equity flow.
noindex, nofollow: nie indeksuj i nie follow linki. Dla stron konkretnie nieużytecznych. Rzadko rekomendowane.
Brak meta robots (default): indeksuj, follow linki. Dla wszystkich value pages.

noindex nie zatrzymuje od razu – Google musi ponownie crawlować stronę, żeby zobaczyć noindex tag. Proces: (1) meta robots noindex dodane, (2) Google crawluje stronę (dni do miesięcy), (3) Google widzi noindex, (4) usuwa z indeksu. Pełne propagate: 7-60 dni zwykle.

Błąd, którego unikać: robots.txt disallow + noindex. Jeśli blokujesz URL w robots.txt, Google nie może go crawlować, więc nie widzi noindex. URL pozostaje w indeksie (jeśli był tam wcześniej) ale nieaktualny.

Canonical tags – krytyczne dla crawl budget

Canonical tag mówi Google „ta wersja URL jest „oficjalna”, wszystkie inne to duplikaty”. Dla crawl budget: Google crawluje tylko canonical URL, ignoruje duplikaty w indeksacji (ale czasem nadal crawluje je pobieżnie).

Typowe wzorce canonical:

Product page z query parameters: canonical do bazowej URL bez parameters.
Filtry nieidexowalne: canonical do category URL (bez filtra).
Pagination: każda strona ma self-canonical (nie canonical do strony 1 – to stary zły pattern).
Mobile vs desktop (jeśli separate URLs): canonical do desktop version, rel=”alternate” do mobile.
HTTP vs HTTPS: zawsze canonical do HTTPS.
WWW vs non-WWW: consistent choice + canonical.

Błąd: każdy URL z canonical do home page. To sygnał „cała strona to jeden URL” – Google consolidate wszystko, tracisz rankings dla wszystkich inner pages. Canonical self (wskazujący na siebie) jest default dla pages, które mają się indeksować.

Przykłady i liczby z projektów

Projekt 1 – sklep AGD 180k produktów: baseline crawl budget 45k req/dzień, 78% na filtry. Po 4 miesiącach optymalizacji (polityka filtrów, CWV, internal linking): 78k req/dzień, 22% na filtry, 58% na produkty. Indeksacja nowych produktów: z 18 dni do 3 dni. Szersze tło w naszym tekście o filtrach produktowych.

Projekt 2 – portal informacyjny 3200 artykułów, 800k URL archiwum: baseline 120k req/dzień, 45% na stare artykuły z tagów (noindex nie było stosowane). Po 3 miesiącach: 180k req/dzień, nowe artykuły indeksowane w 6 godzin (było 3-5 dni). Ruch organiczny dla świeżych wiadomości +85%.

Projekt 3 – wielojęzyczny SaaS B2B (6 wersji językowych, 40k URL): baseline 18k req/dzień, hreflang errors powodowały crawl waste. Po 2 miesiącach hreflang fix + parameter handling: 32k req/dzień, wszystkie 6 wersji równomiernie indeksowane. Ruch z DE i CZ wzrósł 3-4x (z marginalnego poziomu).

Narzędzia do analizy crawl budgetu

Narzędzie	Źródło danych	Cena	Kiedy używać
Google Search Console	Google’s own data	free	always, baseline
Screaming Frog Log Analyser	server logs	239 GBP/rok	średnie-duże witryny
OnCrawl	logs + crawl	500-5000 USD/mies.	enterprise, ogromne sklepy
Botify	logs + crawl	2000-10000 USD/mies.	enterprise
Python + pandas	custom analysis logów	free	tech teams, custom needs
DeepCrawl	crawl (nie logs)	500-3000 USD/mies.	audit mode

Dla średniego sklepu (20-100k URL): Screaming Frog Log Analyser + GSC wystarczy. Dla enterprise (100k+): OnCrawl lub Botify. Dla tech-savvy teams: Python skrypt czytający logi + integracja z BigQuery = pełna elastyczność w analizie.

Najczęstsze błędy w crawl budget optimization

Robots.txt disallow dla stron, które były zaindeksowane – blokujesz crawl, ale strony nadal w indeksie (często outdated).
Ignorowanie image bot – obrazy często >50% crawl budgetu.
Brak URL parameter handling w GSC – Google nie wie, jak traktować ?sort=, ?utm_source=.
Sitemap z noindex URL – konflikt sygnałów.
Deep paginacja bez limit – strona 50, 100, 500 crawlowane bez sensu.
Duplicate content bez canonical – Google marnuje crawl na identyczne strony.
Brak server optimization – wolny TTFB ogranicza crawl rate.
Ignorowanie 301 chains – A→B→C→D zżera 4x więcej crawl niż A→D.
Tagi bez contentu unikalnego – tagi z 2-3 artykułami traktowane jako thin pages.
Staging bez robots.txt disallow – Google chodzi tam i crawluje duplikaty produkcji.

FAQ – crawl budget i indeksacja

Czy małe strony (do 5000 URL) muszą dbać o crawl budget?

Nie bezpośrednio – Google crawluje małe strony w całości w ciągu 1-2 dni. Ale podstawy (brak 404, canonical, sitemap) są ważne. Crawl budget staje się realnym problemem od 10-20k URL, krytycznym od 100k+. Dla small sites fokus na quality content, backlinks, CWV – to daje organic signal lepszych niż obsesja na crawl budget.

Jak szybko zobaczę efekty optymalizacji crawl budgetu?

Pierwsze zmiany w GSC Crawl Stats: 2-4 tygodnie. Pełne efekty (indeksacja nowych treści przyspiesza): 4-12 tygodni. Duże witryny z historycznymi problemami: 3-6 miesięcy pełnej propagacji. Najszybszy signal: spadek 4xx errors w GSC (tygodnie), wzrost Discovery crawl (miesiące), redukcja crawl dla wasted URLs (tygodnie).

Czy parameter handling w GSC to dead feature?

Google zdeprekowalo „URL Parameters” tool w 2022, ale zasada pozostaje. Teraz zamiast narzędzia używamy meta robots, canonical, robots.txt do tego samego celu. Parameter handling is still best practice, just done differently. Alternatives: robots.txt Disallow dla specific parameters (careful, może zablokować important URLs), canonical tags, meta robots, URL structure that avoids parameters.

Czy robots.txt może kompletnie rozwiązać crawl budget?

Tylko częściowo. Disallow w robots.txt blokuje crawl, ale jeśli URL był wcześniej indeksowany, zostaje w indeksie nieaktualny. Nie zwalnia crawl budgetu dla już zablokowanych URL (one nie są więcej crawlowane). Pełne rozwiązanie: robots.txt + meta robots noindex + canonical + sitemap cleanup. Wszystkie razem dają czysty sygnał.

Jak radzić sobie z ogromnymi katalogami produktów (1M+)?

Priorytetyzacja: crawl budget zawsze będzie mniejszy niż total URLs. Strategia: (1) sitemap segmentacja – osobna sitemap per klaster produktów, priorytety w sitemap (chociaż Google często je ignoruje), (2) internal linking – top produkty dostają więcej inbound links (sygnał ważności), (3) freshness – stale content deprioryteizowany, fresh content priorytet. Expectation: nie wszystkie 1M URL będą crawlowane co tydzień, niektóre co miesiąc, niektóre co kwartał. To OK.

Czy Request Indexing w GSC może przyspieszyć indeksację?

Tak, ale ograniczone. URL Inspection + Request Indexing: Google crawluje URL w 1-7 dni vs 3-21 dni bez request. Limit: 10-20 requestów dziennie per property. Useful dla: new critical content, content po big fixes. Nie dla: daily mass submission (spam). Dla ogromnej skali (sklepy 100k+): Request Indexing to drop in ocean – optymalizacja strukturalna skala lepiej.

Czy IndexNow to alternatywa dla Request Indexing?

IndexNow (inicjatywa Bing, Yandex, Seznam) to API dla natychmiastowej notyfikacji wyszukiwarek o zmianach URL. Działa dla Bing, Yandex, niektórych innych – Google NIE wspiera (2026). Dla ekosystemu Microsoft IndexNow pomaga (Bing Copilot indexation faster). Dla Google strategia pozostaje sama: sitemap, dobre internal linking, cierpliwość. IndexNow implementation: wtyczka WP 5 minut, manual w custom sitach – 2-4 godziny.

Co zrobić, gdy crawl budget drastycznie spada?

Diagnostyka: (1) GSC Crawl Stats – spadek request counts? Trendy per bot type? (2) Server response time – wzrost? (3) 4xx/5xx errors spike? (4) Manual penalty check w GSC (Security Issues, Manual Actions). Typowe przyczyny: technical issue (serwer downtime, regresja CWV), quality signals drop (Google mniej zainteresowany), manual penalty, structural change (nowa architektura URL bez proper redirects). Każdy wymaga innego działania.

Co dalej

Zacznij od audytu logów serwera – to jedyny sposób na zobaczenie rzeczywistego crawl behavior Googlebota. Screaming Frog Log Analyser dla typowych projektów, OnCrawl dla enterprise. Implementacja fixes zwykle trwa 2-4 miesiące; pełne efekty w 6-12 miesięcy. Szersze tło technicznego SEO w SEO techniczne 2026, a szczegóły optymalizacji CWV w Core Web Vitals 2026. Pełną checklistę audytu w audycie SEO lista kontrolna.