Crawl budget 2026 - optymalizacja budzetu Google

Crawl budget to liczba URL-i, ktore Google jest w stanie pobrac z Waszej domeny w danym oknie czasowym. Dla malych stron (do 10 000 URL) nie stanowi problemu. Dla e-commerce, forum, programmatic SEO crawl budget jest czesto waskim gardlem – jesli Google nie crawluje, nie indeksuje, a wiec nie rankuje. Ten przewodnik pokazuje, jak zdiagnozowac problemy, zoptymalizowac infrastrukture i zwiekszyc skutecznosc indeksowania.

Po przeczytaniu bedziecie mieli: liste kontrolna crawl budget, proces analizy logow serwerowych, checklisty optymalizacji TTFB, HTTP/2, kompresji, CDN, oraz strategie usuniecia duplikatow URL. Plus case studies pokazujace jak srednia domena e-commerce odzyskala 40-80% crawl budget w 6 tygodni.

W skrocie

Crawl budget to liczba URL pobrana przez Googlebota w jednostce czasu.
Problem dla stron >10k URL, szczegolnie e-commerce i programmatic SEO.
Dwie osie optymalizacji: mniej URL do pobrania + szybsze pobieranie.
Glowne zmienne: TTFB (target <200ms), HTTP/2, CDN, parametry URL, canonicals.
Analiza logow serwerowych pokazuje rzeczywista dystrybucje crawlu Googlebota.

Czym jest crawl budget i jak go mierzy Google?

Crawl budget ma dwa komponenty: crawl rate limit (ile zapytan na sekunde Google wysle) i crawl demand (ile stron chce pobrac). Oba wynosza z osobnych czynnikow. Crawl rate limit zalezy od predkosci serwera – wolny serwer = Google zwalnia. Crawl demand zalezy od wielkosci, jakosci i popularnosci strony.

Pomiar: Google Search Console ma raport „Crawl Stats” (Ustawienia > Crawl Stats). Pokazuje liczbe zapytan dziennie, rozmiar pobranych danych, czas odpowiedzi, statusy HTTP. To podstawowe zrodlo danych o crawl budget.

Druga warstwa: logi serwera. Pokazuja dokladnie, ktore URL Googlebot odwiedzil, kiedy, z jakim statusem. Wymaga eksportu z serwera (Apache/Nginx access log) i analizy przez skrypt Python lub narzedzia jak Botify, OnCrawl, Screaming Frog Log Analyzer.

Crawl budget jest problemem infrastrukturalnym, nie contentowym. Nie da sie rozwiazac dobrymi tekstami – wymaga podejscia technicznego. Ale bez jego rozwiazania dobra tresc zostaje niezauwazona. Dlatego pojawia sie on wczesnie w planie wdrozenia zaawansowanego SEO, co szczegolowo omawiamy w pillarze o zaawansowanym SEO.

Ktore strony marnuja crawl budget?

Typ 1: Parametry URL bez wartosci

URL z parametrami jak ?sort=price, ?color=red&size=xl, ?ref=newsletter generuja tysiace wariantow tej samej strony. Google pobiera kazdy, marnujac budzet. W e-commerce to zwykle 40-60% wszystkich pobran.

Typ 2: Wewnetrzne wyszukiwarki

Strony typu /search?q=… tworza nieskonczenie duzo URL. Kazde wyszukiwanie uzytkownika = nowy URL w indeksie. Te strony rzadko maja wartosc SEO i powinny byc blokowane.

Typ 3: Strony paginacji bez kanonikalizacji

/kategoria/, /kategoria/?page=2, /kategoria/?page=3 – kazda osobno crawlowana. Dla kategorii z 50 stronami paginacji = 50 wariantow do pobrania. Rozwiazanie: rel=canonical lub rel=prev/next (od 2019 deprecated, ale widoczne) lub lepsza nawigacja.

Typ 4: Duplikaty wynikajace z wersji strony

HTTP vs HTTPS, www vs non-www, trailing slash vs bez, mobile vs desktop URLs. Kazdy wariant = osobny URL w indeksie. Bez redirectow lub canonicals = duplikat.

Typ 5: Thin content

Strony bez wartosci (puste tagi, kategorie z jednym produktem, puste profile uzytkownikow). Googlebot je pobiera, traci czas. Usunienie lub noindex zwalnia budzet.

Typ 6: Infinite redirect chains

URL A > 301 > URL B > 301 > URL C. Kazdy krok to osobne zapytanie. Dluzsze laczchuchy redirectow = wiekszy koszt.

Jak analizowac logi serwerowe?

Analiza logow serwerowych pokazuje prawdziwe zachowanie Googlebota. Podstawowe kroki.

Eksport logu serwera (Apache access.log lub Nginx access.log) za okres 30 dni.
Filtrowanie po User-Agent zawierajacym „Googlebot” (oryginalny lub mobilny).
Walidacja IP (Google publikuje zakres IP Googlebota w dokumentacji).
Analiza: ile unikalnych URL, rozklad typow, czestotliwosc, statusy HTTP.
Wizualizacja: wykres pobran per dzien, per typ URL, per status.

Kluczowe metryki z logow

Unikalne URL dziennie – ile roznych stron Googlebot odwiedza.
Stosunek productive:non-productive crawls – ile pobran idzie na wartosciowe URL (artykuly, produkty) vs nie (parametry, filtry).
Srednia glebokosc pobran – jak gleboko Google wchodzi w strukture strony.
Czas odpowiedzi serwera – TTFB per URL.
Rozklad statusow HTTP – 200, 301, 404, 500.

Narzedzie: skrypt Python (pandas + regex) w 100-200 liniach. Alternatywnie: Screaming Frog Log Analyzer (99 GBP/rok), Botify (enterprise), OnCrawl (enterprise).

Jak optymalizowac TTFB i speed servera?

TTFB (Time To First Byte) to czas od zapytania do pierwszego bajta odpowiedzi. Google limituje crawl rate na podstawie TTFB – wolny serwer = mniej pobran. Cel: TTFB <200ms.

Optymalizacje na poziomie serwera

HTTP/2 lub HTTP/3 – multiplexing daje 2-3x szybsze pobieranie wielu zasobow.
Kompresja gzip/brotli – zmniejszenie rozmiaru odpowiedzi o 60-80%.
CDN (Cloudflare, Fastly) – cache statycznych zasobow, redukcja obciazenia origin.
Keep-Alive – reuse TCP connections.
SSL session resumption – szybsze handshake.

Optymalizacje na poziomie aplikacji

Cache strony – WordPress LiteSpeed, WP Rocket, Varnish.
Database query optimization – indeksy, query cache.
Opcode cache PHP – OPcache.
Lazy loading – obrazow i zasobow.

Jak zarzadzac parametrami URL?

Parametry URL to glowne zrodlo marnowania crawl budget w e-commerce. Trzy strategie zarzadzania.

Strategia 1: Blokada w robots.txt

Dla parametrow, ktore nigdy nie daja wartosciowego URL (?sort=, ?ref=, ?utm_): Disallow: /*?sort=. Google nie crawluje. Uwaga: nie blokujcie parametrow, ktore daja unikalne strony (np. ?category=).

Strategia 2: Canonical tag

Dla parametrow, ktore generuja wariacje strony ale wskazuja na glowna: <link rel="canonical" href="https://example.com/product">. Google pobiera, ale nie indeksuje wariantu, tylko kanoniczny URL.

Strategia 3: URL Parameters w Google Search Console

Dla niektorych parametrow mozna zglosic w GSC „jak je traktowac”. Od 2022 Google zrezygnowalo z tego narzedzia, ale zalecenia canonicals sa wystarczajace.

Jak skonfigurowac sitemap dla duzych stron?

Sitemap to mapa dla Googlebota. Dla stron z 10k+ URL wymaga szczegolnej struktury.

Zasada 1: Podzial na wiele plikow

Jeden plik sitemap – max 50 tys. URL lub 50 MB. Dla wiekszych stron – wiele sitemapow + sitemap index. Typowy podzial: jeden sitemap per typ tresci (produkty, kategorie, artykuly).

Zasada 2: Priority i changefreq

Dla kazdego URL – priority (0.0-1.0) i changefreq (daily/weekly/monthly). To wskaznik dla Googlebota, co jest wazne. Glowna strona – priority 1.0, daily. Artykuly – 0.8, weekly. Stare produkty – 0.4, monthly.

Zasada 3: Regularne aktualizacje

Sitemap aktualizowany przy kazdej zmianie: nowy produkt, usuniecie strony, aktualizacja artykulu. Submission w Search Console + ping w /ping?sitemap=... (deprecated 2023, ale wciaz czasem dziala).

Zasada 4: Tylko indeksowalne URL

Sitemap powinien zawierac tylko URL, ktore chcecie zaindeksowac. Nie dajcie tam 404, redirectow, stron z noindex. To rzucenie niegdziwych sygnalow Google.

Jak crawl budget laczy sie z programmatic SEO?

Programmatic SEO generuje tysiace/miliony URL. Bez optymalizacji crawl budget, Google zaindeksuje tylko 10-30% z nich. Reszta bedzie dryfowac miesiacami bez pobierania.

Strategia dla programmatic: (1) sitemap hierarchiczny z priorytetami, (2) linkowanie wewnetrzne miedzy rekordami (crawlbot podaza linkami, nie tylko sitemapa), (3) stopniowa publikacja (100-1000 stron dziennie), (4) monitoring indexacji w Search Console + logi.

Pelen kontekst programmatic SEO jest w przewodniku po programmatic SEO. Tam tez pokazujemy, jak crawl budget staje sie waskim gardlem dla tego typu projektow.

Jakie sa typowe bledy optymalizacji crawl budget?

Blokada zbyt duza – Disallow za szeroki = blokada waznych stron. Testujcie w GSC „URL Inspector”.
Noindex bez Disallow – noindex dziala, ale Googlebot dalej crawluje. Zwalnia budzet = Disallow w robots.txt.
Ignorowanie 404 – 404 nadal marnuja budzet. Przekieruj na relevantne strony lub 410 (permanent).
Zle kanonicals – canonical wskazujacy na 404 lub noindex = problem.
Za wolny serwer – TTFB >500ms ogranicza crawl rate dwukrotnie.
Brak monitoringu – raz wdrozone i zapomniane. Google zmienia algorytmy, strony sie rozrastaja, crawl budget trzeba regularnie przegladac.

Case study: e-commerce po optymalizacji

Anonimowy sklep z 50 tys. SKU. Stan przed: 2.5 mln URL w Google Index (parametry, filtry), Googlebot pobieral 150 tys. URL dziennie, ale 70% to parametry bez wartosci. Zaindeksowanych realnie: 45 tys. produktow (90% katalogu).

Optymalizacja: Disallow dla 8 parametrow, canonical dla paginacji, usuniecie 8 tys. stron thin content, HTTP/2, CDN (Cloudflare). Wdrozenie: 4 tygodnie.

Stan po 6 tygodniach: 650 tys. URL w index (-74%), Googlebot pobiera 85 tys. dziennie, 85% to produkty/kategorie (przed: 30%). Zaindeksowanych produktow: 49 tys. (98% katalogu). Ruch organiczny wzrosl o 18%.

Jak zaprojektowac strukture URL pod crawl budget?

Struktura URL jest pierwszym sygnalem dla Googlebota o hierarchii strony. Dobra struktura ogranicza crawl budget problemy juz na etapie projektowania.

Zasada 1: Plytka hierarchia

Max 3-4 poziomy zagniezdzenia. URL typu /kategoria/podkategoria/podpodkategoria/produkt to granica. Glebsze hierarchie utrudniaja crawling – Googlebot ma trudnosci z dotarciem do glebokich stron.

Zasada 2: Jasny schemat URL

Schemat /typ/kategoria/slug jest czytelny dla Googlebota i uzytkownika. Unikajcie losowych parametrow, ID-ow, hashow. URL /produkt/sneakers-nike-air-max jest lepszy niz /p/id=12345.

Zasada 3: Spojne parametry

Jeden typ parametru per funkcja. Nie: ?sort=price oraz ?order=price. Wybierzcie jedno konsekwentnie. Konsystencja ulatwia pozniej konfiguracje canonicals.

Zasada 4: Trailing slash vs bez

Wybierzcie jedno (z trailing slash lub bez) i trzymajcie sie tego globalnie. Mieszanie prowadzi do duplikatow. Lepiej: wszystkie URL z trailing slash (tak jest u nas).

Jak zoptymalizowac renderowanie JavaScript dla crawl budget?

Strony z duza iloscia JavaScript (React, Vue, Next.js, Nuxt) maja szczegolne wyzwania. Google musi renderowac JS dwuetapowo: pierwszy pass – HTML, drugi – wykonanie JS. Drugi pass ma znacznie mniejszy budzet.

Strategia 1: SSR (Server-Side Rendering)

Strona renderowana na serwerze przed wyslaniem do bota. Googlebot dostaje gotowy HTML. Wydajnosc jak klasyczna strona statyczna. Next.js, Nuxt, SvelteKit maja to out-of-the-box.

Strategia 2: SSG (Static Site Generation)

Strony generowane statycznie w buildzie. Najszybsze rozwiazanie – pliki statyczne na CDN. Idealne dla stron, ktorych content zmienia sie rzadko (blog, dokumentacja).

Strategia 3: ISR (Incremental Static Regeneration)

Hybryda SSG i SSR. Strony statyczne z regeneracja co N sekund. Next.js, Nuxt 3. Optymalne dla e-commerce z wielu kategoriami.

Czego unikac: czyste CSR (Client-Side Rendering)

SPA bez SSR/SSG jest trudne dla Googlebota. Renderowanie wymaga drugiego passa, ktory czasami nie nadchodzi. Content w ciagu 3-5 sekund od zaladowania HTML moze byc pomijany.

Jak konfigurowac robots.txt dla crawl budget?

Robots.txt to pierwszy plik, ktory Googlebot odwiedza. Poprawna konfiguracja oszczedza znacznie crawl budget.

Podstawowa konfiguracja

User-agent: *
Disallow: /admin/
Disallow: /wp-admin/
Disallow: /*?sort=
Disallow: /*?ref=
Disallow: /*?utm_
Disallow: /search?
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xml

Czego NIE blokowac w robots.txt

CSS i JS – Googlebot potrzebuje ich do renderowania. Blokada = Google widzi zdegradowana strone.
Obrazy – wazne dla Google Image search. Blokada = utrata ruchu z obrazow.
Stron z noindex – noindex wymaga crawlowania. Blokada = Google nie zobaczy noindex.

Specyficzne User-Agent

Dla niekworych botow (np. AhrefsBot, SemrushBot) mozna dac wiesze lub dokladniejsze regulazone. Googlebot – zwykle User-agent: * wystarczy.

Jakie sa zaawansowane techniki crawl budget?

Technika 1: Log-based prioritization

Analiza logow pokazuje, ktore URL Googlebot odwiedza czesto, ktore rzadko. Kluczowe strony z niskim crawl rate – wzmocnic linkami wewnetrznymi lub priorytetem w sitemapie.

Technika 2: Cache warming

Dla stron dynamicznych (PHP, DB query) – warming cache przed wizyta Googlebota. Skrypt uruchamiany po publikacji artykulu – pobiera strone, cache’uje, dziekuje czlowiekowi czekajacemu.

Technika 3: Preload krytycznych zasobow

Link rel=”preload” dla CSS, JS, fontow krytycznych. Skraca ladowanie strony, co widzi Googlebot.

Technika 4: Conditional requests (If-Modified-Since)

Serwer zwraca 304 Not Modified zamiast pelnej odpowiedzi, jesli strona sie nie zmienila. Googlebot nie marnuje budzetu na identyczne zawartosci. Konfiguracja naglowka Last-Modified lub ETag.

Technika 5: HTTP Signals

Naglowki jak X-Robots-Tag, Link rel=”canonical” w HTTP, sitemaps z kompresja gzip. Kazda optymalizacja oszczedzajaca ms lub bajty daje sumaryczne korzysci.

Jak crawl budget dziala dla Google Mobile-First Index?

Od 2019 Google dziala w trybie mobile-first: crawluje najpierw wersja mobilna strony. Crawl budget dla mobile i desktop zuzywa sie rownolegle, ale budzet jest wspolny.

Implikacje: wersja mobilna musi byc rownie szybka jak desktop. TTFB, HTML size, JS execution – wszystko dla mobile. Responsive design z jednym URL (vs m.example.com) oszczedza 50% crawl budget.

Praktyczne: walidacja w Search Console „Mobile Usability” + Lighthouse dla mobile. Wynik Lighthouse <50 dla mobile = crawl budget problem, niezaleznie od reszty.

Jak mierzyc ROI optymalizacji crawl budget?

ROI mierzy sie w trzech warstwach.

Warstwa 1: Liczba zaindeksowanych stron

Przed vs po: ile stron w Google index z waznych kategorii. Wzrost z 60% do 90% pokrycia katalogu = realny zysk.

Warstwa 2: Ruch organiczny

Lepsze crawlowanie = szybsza indeksacja nowych stron i aktualizacji. Efekt: szybszy wzrost pozycji (30-60 dni zamiast 60-90), wiecej stron z ruchem.

Warstwa 3: Koszt infrastruktury

Mniej niepotrzebnych zapytan = mniej obciazenia serwera = nizsze koszty hostingu. Dla wiekszych stron to 10-30% oszczednosci.

FAQ – najczestsze pytania

Czy crawl budget dotyczy malych stron?

Dla stron do 10 tys. URL crawl budget rzadko jest problemem – Google zwykle daje wystarczajaco duzy budzet. Ale dla e-commerce z 15k+ SKU, duzych portali, forum, programmatic – crawl budget staje sie waskim gardlem. Sprawdzenie: jesli w Search Console „Pages > Not indexed” ma 1000+ URL bez wyraznego powodu, prawdopodobnie macie problem z crawl budget.

Czy CDN naprawde zwieksza crawl budget?

Tak, znaczaco. CDN skraca TTFB o 100-300ms (cache lokalnie w kraju uzytkownika/bota). Google widzi szybsza odpowiedz i zwieksza crawl rate. Typowy efekt: 40-80% wzrost liczby pobran dziennie po wdrozeniu CDN. Najpopularniejsze: Cloudflare (bezplatny tier), Fastly (enterprise), AWS CloudFront.

Czy HTTP/3 (QUIC) daje przewage nad HTTP/2?

W 2026 roku przewaga HTTP/3 nad HTTP/2 jest marginalna (5-10% wydajnosci). Wiekszosc korzysci juz daje HTTP/2. Wdrozenie HTTP/3 wymaga wspolpracy hostingu i ma wyzsze wymagania. Dla wiekszosci stron HTTP/2 jest wystarczajace. HTTP/3 sprawdza sie dla stron globalnie rozproszonych i z wysokim udzialem urzadzen mobilnych.

Ile trwa, zanim zmiany w crawl budget beda widoczne?

Zmiany sa stopniowe. Po wdrozeniu Disallow – spadek niepotrzebnych pobran w 7-14 dni. Po optymalizacji TTFB – wzrost crawl rate w 14-30 dni. Pelne efekty (reindeksacja, poprawa pozycji, odzyskanie zagubionych stron) – 6-12 tygodni. Wymaga cierpliwosci i regularnego monitoringu.

Czy noindex jest lepsze niz Disallow?

Zalezy od celu. Noindex: Google pobiera, ale nie indeksuje. Dobre dla stron, ktore chcecie kontrolowac z duze szczegolowoscia (np. thin content, wewnetrzne wyszukiwarki). Disallow: Google wcale nie pobiera. Oszczedza crawl budget. Dobre dla parametrow URL, filtrow, duplikatow. W duzych stronach czesto uzywa sie obu: Disallow dla oczywistych smieci + noindex dla granicznych przypadkow.

Jak monitorowac crawl budget w czasie?

Codzienne: Google Search Console Crawl Stats (raport wbudowany). Tygodniowe: analiza logow serwerowych. Miesieczne: raport z narzedzi (Screaming Frog, Botify) o stosunku URL w index / URL w sitemapie. Alarm: spadek crawl rate o >20% w ciagu 2 tygodni – diagnoza natychmiast.

Czy crawl budget wplywa na pozycje?

Posrednio. Crawl budget wplywa na to, co jest indeksowane i jak szybko aktualizacje sa widoczne. Jesli Googlebot nie pobiera nowego artykulu przez 2-3 tygodnie, nie rankuje. Jesli dobre strony sa pogrzebane przez smieci w kolejce, tez dryfuja. Wplyw na pozycje: srednio 10-30% roznicy miedzy zoptymalizowanym a niezoptymalizowanym crawl budget.

Jakie sa scenariusze optymalizacji dla roznych typow stron?

Scenariusz 1: Sklep e-commerce (50k+ SKU)

Priorytet: Disallow dla filtrow, canonical dla paginacji, usuniecie thin content kategorii, HTTP/2 + CDN. Typowy efekt: 60-80% redukcja URL w index, 90%+ pokrycie katalogu, wzrost ruchu organicznego o 20-40%.

Czas wdrozenia: 4-8 tygodni dla zespolu 1-2 osob. Narzedzia: Screaming Frog, GSC, log analyzer.

Scenariusz 2: Portal contentowy (5k+ artykulow)

Priorytet: sitemap hierarchiczny, linkowanie wewnetrzne, usuniecie thin/osieroconego contentu, aktualizacja starych artykulow (sygnal swiezosci). Typowy efekt: szybsze indeksowanie nowych artykulow (24-48h zamiast 5-10 dni), wzrost organic visibility.

Scenariusz 3: Programmatic SEO (10k+ wygenerowanych stron)

Priorytet: stopniowa publikacja (500-1000/dzien), de-duplicator, hierarchiczny sitemap, linkowanie wewnetrzne miedzy rekordami. Typowy efekt: 70-90% stron zaindeksowanych w 60-90 dni zamiast 6-12 miesiecy.

Scenariusz 4: Forum / UGC (100k+ watkow)

Priorytet: noindex dla niskojakosciowych watkow, Disallow dla wewnetrznych wyszukiwarek, redukcja paginacji, usuniecie spamerskich/nieaktywnych watkow. Typowy efekt: Google skupia crawling na najlepszych watkach, wzrost pozycji top watkow.

Scenariusz 5: SaaS z duza dokumentacja

Priorytet: SSR/SSG dla dokumentacji, sitemap z priorytetami, linkowanie kanoniczne dla starych wersji, noindex dla wersji historycznych. Typowy efekt: lepsza indeksacja aktualnych docs, spadek crawlu na archival content.

Jak crawl budget wplywa na nowy content?

Dla nowych stron crawl budget jest krytyczny. Jesli domena ma marnotrawny crawl budget, nowe artykuly czekaja dni na pierwsze pobranie. Znaczy to: pozycje buduja sie wolniej, cytowania w AI przychodza pozniej, efekty calej strategii tresciowej sa opoznione.

Praktyczny test: opublikujcie nowy artykul i zmierzcie, ile trwa do pierwszego pobrania przez Googlebota (log file) i do pierwszej impresji w Search Console. Zdrowa domena: 2-24h. Problematyczna domena: 3-10 dni lub wiecej.

Rozwiazanie dla wolnego indexing: (1) sitemap + ping + Indexing API (dla 30 najwazniejszych stron dziennie), (2) link do nowego artykulu z glownej strony lub innych popularnych podstron, (3) social signals (post na LinkedIn, Twitter) – posrednio wplywaja na crawl demand.

Jak zarzadzac crawl budget po migracji lub re-design?

Migracje (zmiana platformy, struktura URL, redesign) to moment najwyzszego ryzyka dla crawl budget. Google musi przecrawlowac cala strone, zweryfikowac redirecty, zaktualizowac index. Zle zaplanowana migracja = spadek ruchu o 30-60% na miesiacach.

Checklista przed migracja

Mapa wszystkich URL z obecnej strony (Screaming Frog + baza).
Mapowanie 1:1 stare URL > nowe URL.
301 redirecty dla kazdego zmienionego URL.
Nowy sitemap.xml z nowymi URL.
Submission nowego sitemapu w Search Console.
Monitoring Search Console Coverage przez 60-90 dni.

Co sledzic po migracji

Crawl Stats – czy Googlebot pobiera nowe URL z porownywalnym tempem.
Coverage – ile stron zaindeksowanych vs przed migracja.
404 i soft 404 – ich liczba powinna spadac po 2-4 tygodniach.
Pozycje dla kluczowych fraz.

Jak crawl budget wspolpracuje z Indexing API?

Google Indexing API to nowoczesna alternatywa dla czekania na Googlebota. Pozwala przesylac do 200 URL dziennie z prosba o natychmiastowa reindexacje. Oficjalnie dostepne dla JobPosting i BroadcastEvent, ale dziala dla wszystkich typow stron.

Wdrozenie: skrypt Python + Google API credentials + cron. Czas implementacji: 4-8 godzin. Koszt: darmowe. Korzysc: nowe i zaktualizowane strony indeksowane w 1-4 godziny zamiast 2-10 dni.

Ograniczenia: 200 URL/dzien per projekt. Dla wiekszych stron trzeba priorytetyzowac – ktore URL najwazniejsze. Typowa strategia: wszystkie nowe artykuly + aktualizacje kluczowych stron + strony w SERP na pozycjach 8-20 (striking distance).

Jak crawl budget zmienia sie z wzrostem domeny?

Wraz z rozwojem domeny crawl budget skaluje sie, ale nieliniowo. Typowe etapy.

Etap 1: Maly serwis (0-10k URL)

Crawl budget nie jest problemem. Googlebot pobiera wszystko w ciagu dni. Fokus: jakosc tresci, nie technika.

Etap 2: Sredni serwis (10k-100k URL)

Crawl budget zaczyna sie ujawniac. Niektore strony nie sa pobierane regularnie. Podstawowe optymalizacje: sitemap, linkowanie wewnetrzne, TTFB.

Etap 3: Duzy serwis (100k-1M URL)

Crawl budget jest powaznym ograniczeniem. Konieczne: Disallow dla parametrow, canonical dla duplikatow, hierarchiczny sitemap, CDN. Dedykowane monitoringowanie logow.

Etap 4: Enterprise (1M+ URL)

Crawl budget management to osobna dyscyplina. Custom tools, log pipeline, dedicated team. Miliony URL, z ktorych tylko procent jest realnie w indexie w danej chwili.

Jakie narzedzia sa najlepsze do crawl budget w 2026?

Google Search Console – podstawa, darmowe. Crawl Stats, Coverage, URL Inspector.
Screaming Frog – desktop crawler + log analyzer. 259 USD/rok. Dla malych-srednich stron.
Sitebulb – wizualizacja struktury, 35-60 USD/mies. Dobre dla audytow technicznych.
Botify – enterprise log analyzer + crawler. Od 1000 USD/mies. Dla wiekszych stron.
OnCrawl – enterprise alternative Botify. Od 500 USD/mies.
Python skrypty – custom analizy, nieograniczone mozliwosci. Dla zaawansowanych zespolow.

Pelny przeglad narzedzi SEO i AIO w osobnym przewodniku.

Jak diagnozowac trudne przypadki crawl budget?

Niektore problemy wymagaja glebszej analizy. Ponizej 4 scenariusze diagnostyczne z procedura postepowania.

Przypadek 1: Crawl rate spada bez powodu

Sprawdz: TTFB w Crawl Stats (czy wzrosla?), liczba 5xx errors (czy serwer crashuje?), CDN status (czy cache hit rate spadl?). Czesto przyczyna: update hostingu lub nowy plugin obciazajacy serwer.

Przypadek 2: Nowe strony nie sa indeksowane przez tygodnie

Sprawdz: sitemap.xml (czy strona jest w nim?), linkowanie wewnetrzne (ile stron linkuje do nowej?), quality signals (czy tresc ma autora, schema, wystarczajaca dlugosc?). Czesto przyczyna: niska widocznosc (orphan page) lub thin content.

Przypadek 3: Stare strony znikaja z index

Sprawdz: Coverage w Search Console (sekcja „Crawled, not indexed”), ostatnia data crawlu (log files), canonical tag (czy nie wskazuje na inna strone?). Czesto przyczyna: low quality signal lub duplicate content.

Przypadek 4: Googlebot crawluje duzo, ale strony nie w indeksie

Sprawdz: quality strony (dluga, aktualna, autor?), schema markup, relacje (linki wewnetrzne), konkurencja (czy lepsza niz wasze?). Czesto przyczyna: low quality wzgledem konkurencji.

Jaki jest harmonogram optymalizacji crawl budget?

Typowa optymalizacja crawl budget zajmuje 8-12 tygodni pracy w rozlozonym modelu.

Tydzien 1: audyt poczatkowy – Crawl Stats, raport Coverage, analiza sitemap.
Tydzien 2-3: eksport i analiza logow serwerowych.
Tydzien 4-5: optymalizacja robots.txt, canonicals, parametrow URL.
Tydzien 6-7: optymalizacja infrastruktury – TTFB, HTTP/2, CDN.
Tydzien 8: nowy sitemap, indexing API setup.
Tydzien 9-12: monitoring, iteracja, dokumentacja.

Efekty stopniowe: pierwsze zmiany widoczne po 2-3 tygodniach, pelny efekt po 8-12 tygodniach. Regularny monitoring co najmniej kwartalny, bo zmiany algorytmu i struktury strony zmieniaja obraz.

Co dalej?

Zacznijcie od raportu Crawl Stats w Search Console – zdiagnozujcie skale problemu. Potem analiza logow serwerowych. Optymalizacja techniczna (TTFB, HTTP/2, CDN, Disallow, canonicals) to 4-8 tygodni pracy. Calosciowy kontekst: pillar o zaawansowanym SEO. Dla stron z duza skala warto tez zajrzec do programmatic SEO i automatyzacji SEO, bo crawl budget laczy sie tam najsilniej. Wiecej informacji od strony Google w dokumentacji Google Search Central dot. crawl budget, ktora szczegolowo opisuje mechanizmy Googlebota oraz konkretne zalecenia dla duzych serwisow. Po wdrozeniu podstawowych optymalizacji warto wrocic do raportu Crawl Stats co 30 dni i sledzic, czy liczba pobran na dzien rosnie proporcjonalnie do wielkosci serwisu – to glowny wskaznik skutecznosci wykonanej pracy. Drugim kluczowym sygnalem jest rosnacy procent stron produktowych/contentowych w ogolnej liczbie pobran, zamiast parametrow i filtrow marnujacych budzet. Warto tez okresowo porownywac wyniki z branzowymi benchmarkami, aby widziec, czy wasza strona dobrze wypada na tle konkurencji, a nie tylko wzgledem poprzednich miesiacy wlasnej historii – konkurencja zmienia sie dynamicznie i pozycja sredniaka z 2023 to czesto dno stawki w 2026, a standardy Googlebota stale rosna wraz ze wzrostem ogolnej jakosci sieci i liczby stron pod indeksacja oraz rosnacego znaczenia Mobile-First Indexu dla wszystkich serwisow internetowych, nawet tych z niewielkim udzialem ruchu mobilnego.