Crawl budget audit to analiza tego, jak Googlebot i inne roboty wyszukiwarek korzystaja z zasobow serwera na naszej stronie. W 2026 roku, przy rosnacej liczbie robotow (Google, Bing, GPTBot, ClaudeBot, PerplexityBot), crawl budget to nie tylko temat techniczny dla duzych portali. Audyt odkrywa marnotrawione URL-e, identyfikuje problemy ze struktura i priorytetyzuje poprawki w oknie 30-60 dni.
W skrocie
- Crawl budget to limit zasobow, ktore robot wyszukiwarki przeznacza na crawlowanie naszej domeny w danym okresie.
- Audyt crawl budget opiera sie na logach serwera (Apache, nginx), Google Search Console i Screaming Frog.
- Wazny dla stron 10 000+ URL-i, e-commerce z filtrami, portali z duzym archiwum.
- Typowe marnotrawstwo – parametry URL, duplikaty, strony 404, paginacja, soft 404.
- Pelny audyt zajmuje 6-12 godzin, poprawki wdrozeniowe 1-3 tygodni.
Czym jest crawl budget i kiedy ma znaczenie
Crawl budget to suma URL-i, ktore Googlebot jest sklonny crawlowac na naszej domenie w danym okresie (typowo miesiac). Zalezy od dwoch czynnikow: crawl rate limit (jak szybko serwer oddaje odpowiedzi) i crawl demand (jak bardzo Google chce crawlowac nasza domene). Oba sa regulowane przez algorytmy Google.
Dla stron ponizej 10 000 URL-i crawl budget rzadko jest problemem – Google crawluje wszystko w ciagu kilku dni. Dla wiekszych domen (e-commerce z dziesiatkami tysiecy produktow, portale news z archiwum) crawl budget staje sie waskim gardlem – Google po prostu nie ma czasu odwiedzic wszystkich URL-i w sensownym czasie.
Pelny kontekst techniczny opisuje przewodnik po SEO zaawansowanym. Google oficjalnie opisuje mechanike crawlowania (wiecej w dokumentacji Google Search Central).
Kiedy audyt crawl budget jest konieczny
Pieciopunktowy check ostatecznej konieczmy audytu. Pierwszy – domena ma ponad 10 000 URL-i indeksowalnych. Drugi – w Google Search Console widzimy ponad 30% URL-i w „discovered” lub „crawled, not indexed”. Trzeci – nowe tresci pojawiaja sie w indeksie dopiero po 2-4 tygodniach. Czwarty – strona ma duzo parametrow URL (sortowanie, filtry, paginacja). Piaty – wystapily niedawno migracje lub relaunch.
Jesli chocby jeden z tych warunkow jest spelniony, audyt ma sens. Jesli sa spelnione 3+ warunki, audyt jest pilny – prawdopodobnie tracimy znaczaca czesc potencjalnego ruchu organicznego, bo Google nie widzi nowych tresci w porecznym czasie.
Jakie dane zebrac do audytu
Audyt crawl budget opiera sie na trzech zrodlach danych. Kazde odpowiada na inne pytanie i razem daja pelny obraz.
- Logi serwera – co robot faktycznie odwiedzil w ostatnim miesiacu.
- Google Search Console Crawl Stats – agregowane dane z perspektywy Google.
- Screaming Frog lub Sitebulb crawl – co robot powinien odwiedzic (struktura strony).
Porownanie „faktycznie odwiedzil” i „powinien odwiedzic” pokazuje luke. URL-e, ktore Google crawluje, ale nie chcielibysmy (duplikaty, parametry) to marnotrawstwo. URL-e, ktore Google ignoruje, a sa wazne – problem z indeksacja.
Logi serwera – co wyciagnac
Z logow Apache lub nginx z ostatnich 30 dni filtrujemy requests z User-Agent zawierajacym „Googlebot”. Ciagniemy 5 pol: URL, status code, timestamp, user-agent (dla rozroznienia mobile vs desktop), response size.
Narzedzia – Screaming Frog Log File Analyzer, Splunk, ELK stack (Elasticsearch + Logstash + Kibana), OnCrawl. Dla malych stron wystarczy excel z parsowaniem pliku log. Dla duzych (10 GB logow) trzeba dedykowanego narzedzia.
| Metryka | Co mowi | Cel |
|---|---|---|
| Dzienna srednia requestow | Poziom crawlowania | Stabilna wartosc |
| % statusow 2xx | Zdrowie strony | 95%+ |
| % statusow 3xx | Redirecty do naprawy | Ponizej 5% |
| % statusow 4xx | 404 do naprawy | Ponizej 3% |
| % statusow 5xx | Bledy serwera | Ponizej 0.5% |
| Sredni czas odpowiedzi | Wplyw na crawl rate | Ponizej 500 ms |
GSC Crawl Stats – co sprawdzic
Settings / Crawl stats w Search Console pokazuje wykresy z ostatnich 90 dni. Interesuja nas: total crawl requests per day, average response time, by purpose (discovery vs refresh), by file type, by response.
Niezdrowe sygnaly: gwaltowny spadek crawl requests (-50% w tygodniu), rosnacy response time (sygnal problemow z serwerem), rosnacy % statusow 5xx, duzo „host issues”. Kazdy z tych sygnalow skraca crawl budget.
Jak znalezc marnotrawione URL-e
Marnotrawstwo to URL-e, na ktorych Googlebot spedza czas, ale nie przyczyniaja sie do rankingu lub indeksacji waznych stron. Piec najczesciej wystepujacych kategorii.
1. URL-e z parametrami
Sklepy internetowe generuja URL-e typu /produkty?sort=price&filter=color_red&page=2. Googlebot widzi to jako unikalne URL-e i crawluje kazda kombinacje. Dla sklepu z 1000 produktow i 10 filtrow powstaje teoretycznie miliony kombinacji.
Fix – canonical URL na wariant podstawowy, robots.txt blokujacy konkretne parametry, lub dynamic rendering tylko dla wariantu indeksowanego. Szczegoly w przewodniku po SEO e-commerce.
2. Duplikaty tresci
Ten sam artykul dostepny pod /blog/tytul/ i /artykuly/tytul/. Googlebot crawluje oba, wybiera jeden do indeksu, ale marnuje zasob na drugi.
Fix – redirect 301 z jednej wersji na druga. Jesli zachowac obie (np. dla aplikacji), canonical na jedna wersje. Canonical nie powstrzyma crawlowania, ale wlasciwie zgrupuje sygnaly.
3. Strony 404 i soft 404
Page 404 powinna zwracac status 404, nie 200 ze slowem „nie znaleziono”. Soft 404 (200 OK na stronie o niepewnej tresci) marnuje crawl budget, bo Google regularnie do niej wraca.
Fix – konfiguracja serwera zwracajaca 404 dla nieistniejacych URL-i. 301 dla URL-i, ktore sie zmienily. Usuwanie starych linkow prowadzacych do 404.
4. Paginacja bez konca
Archiwa kategorii z 500 stronami paginacji. Kazda strona ma ten sam tytul („Kategoria X – strona N”) i te same meta. Googlebot crawluje kazda strone, nic nie indeksuje.
Fix – rel=prev/next (przestarzale ale nadal wspomagajace), noindex od strony 3+ z zachowaniem follow, lub infinite scroll z historia URL. Zbieramy wszystkie produkty na jednej mape tematycznej zamiast na 500 stron.
5. Sitemap z URL-ami niepotrzebnymi
Sitemap zawierajacy URL-e redirectowane, 404 lub noindex. Googlebot ufa sitemapie i marnuje crawl na niepotrzebne URL-e.
Fix – regeneracja sitemap w oparciu o indeksowalne URL-e z canonicalem wlasnym. Automatyczny update przy publikacji nowych tresci i usuwaniu starych.
Analiza log-sourced vs sitemap-sourced
Trzy listy URL-i: co Googlebot odwiedzil (logi), co jest w naszym sitemap, co jest na stronie (crawl). Porownanie to kluczowy punkt audytu.
Logi minus sitemap = URL-e, ktore Google widzi ale nie wystawilismy (prawdopodobnie marnotrawstwo). Sitemap minus logi = URL-e, ktore wystawilismy ale Google ignoruje (problem z indeksacja lub niewlasciwa priorytetyzacja). Crawl minus sitemap = niewykorzystany potencjal linkow wewnetrznych.
Metoda ta jest szczegolnie skuteczna dla wiekszych stron. Dla e-commerce z 50 000 produktow odkrywa zwykle 15-30% URL-i, ktore sa odwiedzane przez Googlebot ale nie powinny byc.
Przyklad analizy – portal news
Portal z 80 000 artykulow. Logi pokazuja 2.5 mln Googlebot visits/month. Sitemap ma 75 000 URL-i (5 000 starych artykulow noindex).
Logi minus sitemap: 180 000 URL-i. Z tego 60% to parametry (sort, page), 20% to 404, 15% to redirecty, 5% to duplikaty. Wniosek – okolo 800 000 wizyt Googlebot idzie na URL-e, ktorych Google nie powinien widziec. To jest 32% crawl budget marnowanego.
Po poprawkach (robots.txt, canonical, 301, noindex) po 30 dniach: spadek marnotrawstwa do 8%, wzrost nowych artykulow indeksowanych do 24 godzin (wczesniej 5-7 dni).
Jak wdrozyc poprawki – priorytetyzacja
Z audytu powstaje lista 20-50 poprawek. Nie wdrazamy wszystkiego na raz – ryzyko zlamania czegos. Priorytety wedlug matrycy impact/risk.
| Typ poprawki | Impact | Risk | Termin |
|---|---|---|---|
| Robots.txt block parametrow | Wysoki | Sredni | Tydzien 1 |
| Canonical na duplikatach | Sredni | Niski | Tydzien 1 |
| 301 z 404 do najblizszej strony | Niski | Niski | Tydzien 2 |
| Noindex na paginacji | Sredni | Sredni | Tydzien 2 |
| Regeneracja sitemap | Niski | Niski | Tydzien 1 |
| Optymalizacja CWV | Wysoki | Wysoki | Tydzien 3-4 |
Wysoki risk to poprawki mogace zablokowac indeksowanie waznych stron (np. zle skonfigurowany robots.txt). Testujemy na staging, sprawdzamy w Google Search Console Live Test, dopiero potem na produkcji.
Testowanie robots.txt
Przed wdrozeniem nowego robots.txt – Google Search Console robots.txt tester. Wrzucamy nowy plik, wrzucamy 10 URL-i waznych (home, kategorie, topy artykuly) i sprawdzamy, czy sa „allowed”. Jesli chocby jeden jest „disallowed” – blad w regule, wracamy do edycji.
Typowa pomyłka – „Disallow: /*?sort=” blokuje nie tylko ?sort= ale wszystko z ? i sort w URL. Wlasciwa forma to „Disallow: /*?sort=*” lub konkretnie „Disallow: /*?sort=price*”.
Analiza log-file zaawansowana
Poza podstawowymi metrykami (status, response time), logi kryja wiecej insightow. Szczegolowa analiza to 4-6 godzin dodatkowej pracy, ale odkrywa problemy niewidoczne w GSC.
Pierwszy – crawl depth distribution. Sprawdzamy, na jaki glebokosci kategoria/podkategoria/produkt Googlebot schodzi. Jesli 80% crawlow jest na poziomie 1-2, a produkty sa na poziomie 4, to strukturalny problem z archiwiteria.
Drugi – czas miedzy crawlami tego samego URL. Waznie URL-e powinny byc crawled raz dziennie. Stare artykuly – raz w tygodniu-miesiacu. Jesli waznie URL-e maja luke 14+ dni, Google obniza im priorytet.
Trzeci – daily pattern. Googlebot czesto crawluje w nocy (UTC). Jesli w nocy serwer ma problemy (np. backup), crawl rate jest obnizony. Przesuniecie backupow na inne godziny czesto rozwiazuje problem.
User-agent spoofing
Nie wszystkie „Googlebot” w logach to Googlebot. Spamerzy i scraperzy udaja. Weryfikacja – reverse DNS lookup na IP. Prawdziwy Googlebot ma reverse DNS w domenie googlebot.com. Google oficjalnie opisuje weryfikacje (wiecej w dokumentacji Google).
W typowym polskim e-commerce fake Googlebot stanowi 5-15% requestow z User-Agent Googlebot. Po weryfikacji odsiewamy, analizujemy tylko prawdziwe wizyty.
Monitoring po wdrozeniu
Wdrozenie poprawek nie konczy audytu. Monitorujemy 3 wskazniki przez 30-60 dni.
Pierwszy – procent URL-i w „Indexed” w Google Search Console. Powinien rosnac jesli poprzednio duzo bylo w „Discovered”. Drugi – czas od publikacji nowego URL-u do indeksacji. Powinien skrocic sie z dni do godzin. Trzeci – total crawl requests per day w GSC Crawl Stats. Powinno utrzymac sie lub wzrosnac (nie spasc).
Jesli crawl requests znaczaco spadnie po wdrozeniu robots.txt, to znaczy ze zablokowalismy cos waznego. Wracamy do pliku i rewidujemy reguly.
Alerty na spadki
Skrypt sprawdzajacy GSC API codziennie i alertujacy na Slack, jesli: dzienny crawl spadnie o 30%+ vs srednia z 7 dni, % 5xx wzrosnie powyzej 2%, sredni response time wzrosnie powyzej 1 sekundy. Wczesnia detekcja problemow jest krytyczna.
Case study – duzy e-commerce z problemem crawl budget
Sklep z 120 000 produktow, 3 kategorie glowne, 8 warstw filtrow. Przed audytem 65% produktow w GSC pokazywalo sie jako „Crawled, not indexed” lub „Discovered”. Nowe produkty ladowaly w indeksie po 3-4 tygodniach.
Audyt odkryl, ze Googlebot crawluje 14 milionow URL-i miesiecznie, z czego 11 milionow to parametry filtrow i sortowania. Prawdziwe produkty dostawaly tylko 3 miliony crawlow, czyli 25 crawlow per produkt miesiecznie (sredni).
Wdrozone poprawki: robots.txt blokujacy /?filter= i /?sort=, canonical na stronach filtrowanych prowadzacy do kategorii bazowej, noindex na paginacji od strony 3, cleanup sitemap (usuniecie 15 000 noindex URL-i i 3000 404). Poprawa CWV (LCP z 3.1s do 1.8s, TTFB z 900 ms do 320 ms).
Wynik po 60 dniach: % Indexed w GSC wzrost z 35% do 82%, sredni czas indeksacji z 22 dni do 36 godzin, ruch organiczny +41% YoY. Cost saving na infrastrukturze – mniej requestow na serwer, spadek bill AWS o 28%.
Dashboard crawl budget – co pokazywac
Stan crawl budget powinien byc widoczny w stalym dashboardzie dla zespolu SEO. Gotowe rozwiazania – Data Studio (Looker Studio) podpiety do GSC API + BigQuery z logami serwera.
| Widget | Dane | Czestotliwosc |
|---|---|---|
| Daily crawl requests | GSC API | Dzienny update |
| % statusow 2xx/4xx/5xx | Logi | Godzinny |
| TTFB average | Logi / CWV API | Godzinny |
| Indexed vs submitted | GSC API | Dzienny |
| Time to indexation | Custom script | Dzienny |
| Wasted crawl % | Logi + sitemap | Tygodniowy |
Alerty kierujemy do kanalu Slack #seo-ops. Historia dashboard (>90 dni) pomaga w korelacji z duzymi zmianami na stronie (migracje, nowe kategorie, update algorytmu Google).
Automatyzacja raportow miesiecznych
Co miesiac skrypt generuje PDF raport z 4 sekcjami. Pierwsza – executive summary z glownym wskaznikiem zdrowia (0-100 skor). Druga – trendy (crawl, indexation, errors). Trzecia – top 10 URL-i najlepiej crawlowanych i top 10 problemow. Czwarta – rekomendacje na nastepny miesiac.
Raport trafia do managementu i klientow. Automatyzacja oszczedza 4-8 godzin manualnej pracy miesiecznie i gwarantuje regularnosc. Template raportu jest czescia pipeline automatyzacji SEO, integracja zajmuje jeden dzien.
Interakcja crawl budget z innymi warstwami SEO
Crawl budget nie jest oderwany od reszty SEO. Interakcje z innymi warstwami wplywaja na caloksztalt wynikow.
Z warstwa linkow – domeny z silnym profilem backlinkow maja wiekszy crawl demand. Google chce czesciej odwiedzac waznie strony. Budowa autorytetu zwieksza crawl budget posrednio.
Z warstwa tresci – strona z tysiacami thin content straci crawl budget szybciej niz strona z 100 dobrymi artykulami. Google szybko uczy sie, ktore URL-e nie warto czesto odwiedzac. Kasowanie thin content to jedna z najskuteczniejszych akcji poprawy crawl budget.
Z warstwa technique – Core Web Vitals, HTTPS, HTTP/2, compression. Kazdy element technicznej higieny poprawia crawl rate. Audit techniczny powinien poprzedzic audit crawl budget, bo wiele problemow ma wspolne zrodlo.
Harmonogram audytow na rok
Plan roczny dla duzego serwisu. Styczen – pelen audyt techniczny + crawl budget. Kwiecien, Lipiec, Pazdziernik – szybki crawl budget check (2 godziny, tylko kluczowe metryki). Grudzien – reczna rewizja strategii na rok nastepny. Dodatkowo po kazdej migracji lub wiekszym update audit w T+30 dni i T+90 dni.
Zespol 2-3 osobowy moze obslugiwac audyt rokowy bez problemu, jesli dane sa zbierane automatycznie. Wiekszosc czasu idzie na synteza i plan dzialania, nie na zbieranie.
Wazne – audyt nie jest celem sam w sobie. Celem jest wzrost ruchu i konwersji. Jesli po pelnym audycie i wdrozeniu poprawek nie widzimy zmian w ruchu w 6 miesiecy, prawdopodobnie crawl budget nie byl glownym problemem. Czas wrocic do warstwy tresci lub linkow.
Mierzenie ROI audytu – porownujemy ruch organiczny przed i po (T-90 dni vs T+90 dni). Jesli wzrost jest ponad 10%, audyt sie oplacil. Jesli mniej, trzeba krytycznie spojrzec co poszlo nie tak i zrewidowac podejscie dla nastepnej iteracji.
Specialne przypadki – JavaScript i dynamic rendering
Strony renderowane w JavaScript (React, Vue, Angular SPA) maja dodatkowy crawl budget problem. Googlebot renderuje JS, ale jest to droga operacja – Google ma wlasny crawl budget na rendering, ktory jest mniejszy niz na HTML.
Oznacza to, ze SPA ma szanse na 30-60% gorszy crawl vs statycznej strony HTML. Fix – server-side rendering (Next.js, Nuxt), static site generation lub hydration. Wiecej o tym w tekscie o pipeline automatyzacji SEO.
Dynamic rendering – kiedy ma sens
Dynamic rendering (serwer wysyla statyczny HTML dla robotow, JS dla userow) bylo rekomendowane przez Google w 2018-2020. Obecnie Google sugeruje unikanie, chyba ze nie ma innego wyboru. Nowoczesne SSR/SSG daje lepsze efekty.
Wplyw crawl budget na nowe roboty AI
W 2026 roku poza Googlebot odwiedzaja nas GPTBot, ClaudeBot, PerplexityBot, Bytespider i inne. Kazdy ma wlasny budget. Lacznie moga stanowic 20-40% calego ruchu robotow na stronie.
Crawl budget dla AI botow nie wplywa bezposrednio na Google ranking, ale wplywa na widocznosc w wyszukiwarkach AI. Jesli GPTBot nie zdazy crawl nowego artykulu, ChatGPT nie bedzie go cytowal. Szczegoly w tekscie o widocznosci w AI.
Strategia – nie blokujemy AI botow, jesli zalezy nam na widocznosci w wyszukiwarkach AI. Dopuszczamy w robots.txt z tymi samymi zasadami co Googlebot. Jesli content jest prywatny lub platny – blokujemy selektywnie.
Crawl budget a Core Web Vitals
Crawl rate limit Google ustala na podstawie odpowiedzi serwera. Wolny serwer = mniej crawlow. Jesli LCP przekracza 2.5 sekundy, TTFB przekracza 600 ms, crawl budget kurczy sie w sposob mierzalny – czesto o 20-40% wzgledem zdrowego stanu.
Fix serwera jest kluczowy zanim cokolwiek innego. Optymalizacja bazy danych, cache (Redis, Memcached), CDN, kompresja obrazow (WebP), minifikacja JS/CSS. Kazda z tych zmian daje 5-20% poprawy TTFB, a w sumie moze zmienic crawl budget dwukrotnie.
Pomiar zmian – Google PageSpeed Insights API raz dziennie dla 5-10 kluczowych URL-i. Wynik zapisujemy i korelujemy z crawl rate w GSC. Dwie linie na wykresie – TTFB w czasie i crawl requests/day – powinny odwrotnie korelowac.
Wplyw serwera na rozne typy URL-i
Googlebot dostosowuje crawl rate per host, ale w ramach hosta zwraca uwage na wzorce per URL. URL-e z response time >2 sekund sa crawlowane rzadziej od tych z <500 ms. Czyli wolne URL-e (np. niezoptymalizowane produkty) zostaja w kolejce dluzej.
Mobile-first indexing a crawl budget
Od 2022 Google domyslnie crawluje jako smartphone Googlebot. Logi powinny pokazywac >80% requestow z Googlebot-Mobile, reszta z Googlebot (desktop). Jesli proporcje sa odwrotne – strona moze byc jeszcze niewlasciwie oznaczona.
Mobile version musi miec te same tresci i linki co desktop. Jesli mobile ma mniej tresci (np. zwiniete accordiony bez tekstu), Google indeksuje tylko to co widzi – crawl budget na desktop jest marnowany.
Responsive vs separate URLs
Responsive design (jeden URL dla desktop i mobile) jest preferowany. Separate URLs (/m/ lub m.domena.pl) to osobne crawl budget dla kazdej wersji. Google musi crawl oba, co marnuje 2x zasoby.
Crawl budget na poziomie kategorii
Ogolny crawl budget to suma, ale rozklada sie nierowno. Niektore sekcje strony sa crawlowane duzo czesciej (homepage, kategorie top-level), inne rzadko (stare artykuly, podkategorie). Analiza per-kategoria pokazuje, gdzie sa niedobory.
Metodologia – filter logow per URL prefix (np. /blog/, /sklep/, /kategoria-A/) i liczymy crawl requests dla kazdej sekcji. Porownujemy z objetoscia tresci i waznoscia biznesowa.
Typowy wynik – homepage 5000 requestow/month, top kategorii 500 requestow, podkategorii 50, artykuly 5-10. Jesli jedna sekcja jest niedo-crawlowana (np. nowa kategoria produktow z 200 stronami i 20 requestow/month), to sygnal do poprawy wewnetrznych linkow lub priorytyzacji sitemap.
Internal linking a crawl priority
URL-e z wieloma wewnetrznymi linkami przychodzacymi sa crawlowane priorytetowo. Artykul z 50 linkami wewnetrznymi dostanie dziesiec razy wiecej crawlow niz artykul z 2. Fix dla niedo-crawlowanych URL-i to zwykle dodanie linkow z powiazanych artykulow lub strony glownej.
Najczestsze bledy w audycie crawl budget
Pierwszy blad – analiza bez logow serwera. Sam GSC Crawl Stats nie wystarczy – pokazuje agregat, nie konkrety URL-i. Bez logow nie wiadomo, co naprawic.
Drugi blad – blokada w robots.txt bez canonical fix. Blokowanie URL-i w robots.txt nie usuwa ich z indeksu – Google zostawia wpis bez tresci („Crawled, not indexed”). Prawidlowe podejscie to noindex + potem blokada.
Trzeci blad – agresywny canonical na pustych stronach. Canonical musi byc na istniejacej, wartosciowej stronie. Canonical na 404 lub thin content to kara.
Czwarty blad – ignorowanie 5xx. Pojedyncze 500 nie szkodza, ale 2%+ daje Google sygnal ze serwer jest niestabilny i zmniejsza crawl rate. To zmniejsza indeksacje calej domeny.
Piaty blad – zapominanie o sitemap. Po wszystkich fixach regenerujemy sitemap i subscribujemy w GSC. Inaczej Google dalej uzywa starej listy.
FAQ – najczestsze pytania
Czy crawl budget jest wazny dla malej strony?
Dla stron ponizej 1000 URL-i crawl budget praktycznie nie istnieje jako problem – Googlebot crawluje wszystko codziennie. Dla 1000-10 000 URL-i czasem warto sprawdzic, jesli zauwazymy powolne indeksowanie. Dla 10 000+ audyt jest standardem. Prawdziwa odpowiedz zalezy od crawl demand – popularne marki z 500 URL-i maja silniejszy crawl niz malo znane strony z 5000 URL-i.
Jak czesto robic audyt crawl budget?
Dla duzych stron raz na kwartal. Dla dynamicznych serwisow (news portali, e-commerce z wysokim turnover) co miesiac. Po kazdej wiekszej migracji lub redesign rob audyt w 30-60 dni po (zanim nie stabilizuje sie crawl). Pomiedzy audytami monitoring przez alerty GSC wystarczy.
Jakie narzedzie wybrac do analizy logow?
Dla malych stron (1 GB logow miesiecznie) – Screaming Frog Log File Analyzer, 99 GBP rocznie. Dla srednich (10 GB) – JetOctopus, OnCrawl, ~1000 USD rocznie. Dla duzych (100+ GB) – wlasny stack Elasticsearch + Kibana. Roznica miedzy narzedziami to nie tylko cena – OnCrawl i JetOctopus maja integracje z GSC i robia gotowe raporty, co oszczedza 10-20 godzin pracy miesiecznie.
Czy warto blokowac GPTBot i ClaudeBot?
Decyzja biznesowa. Blokada zachowuje crawl budget dla Googlebot (dominuje ruch organiczny) i chroni content przed uzyciem do trenowania AI bez kompensacji. Dopuszczenie zwieksza szanse cytowania w ChatGPT/Claude/Perplexity, co staje sie rosnacym zrodlem ruchu. Dla wiekszosci stron rekomendacja – dopuscic z podstawowymi regulami jak dla Googlebot. Dla wydawcow premium content – zablokowac albo negocjowac licencje z OpenAI/Anthropic.
Co zrobic, gdy Google znacznie zmniejszy crawl po wdrozeniu poprawek?
Sprawdz Search Console Crawl Stats i kategorie bledow – host errors, response time, server availability. Jesli jakis z nich rosnie, wycofaj zmiany (rollback). Jesli wszystko w porzadku, Google moze chwilowo zmniejszyc crawl po robots.txt changes aby dostosowac sie do nowej struktury. Daj 14 dni na stabilizacje. Jesli po 14 dniach nadal jest spadek -50%, mozliwie zablokowalismy cos waznego – prawdopodobnie robots.txt ma za agresywne reguly. Rewiduj regule po regule.
Czy XML sitemap moze pomoc w crawl budget?
Tak, posrednio. Dobry sitemap sluzy jako priorytetyzator – Google ufa, ze URL-e w sitemap sa wazne i crawluje je czesciej niz znalezione przypadkiem. Dwa warunki. Pierwszy – sitemap musi zawierac tylko URL-e 200 OK z canonicalem wlasnym (nie redirecty, nie 404, nie noindex). Drugi – lastmod musi byc rzetelny. Google ignoruje sitemap z lastmod updatowanym codziennie dla kazdego URL-u (oznacza, ze serwer sie myli).
Jak policzyc, ile crawl budget marnujemy?
Formula prosta. Z logow zbieramy wszystkie Googlebot requests z ostatnich 30 dni. Dzielimy na „wartosciowe” (200 OK, URL w sitemap) i „marnowane” (404, 3xx, parametry, duplikaty, soft 404). Procent marnotrawstwa to stosunek drugich do wszystkich. Zdrowa strona ma ponizej 15% marnotrawstwa. 15-30% – potrzeba audytu. 30%+ – pilny priorytet. Na bardzo duzych e-commerce widzielem marnotrawstwo na poziomie 50-60%.
Czy CDN wplywa na crawl budget?
Bezposrednio nie, ale posrednio bardzo. CDN obniza response time (dobry sygnal dla crawl rate), chroni serwer przed DDoS i zle reagujacymi botami, i moze wykryc Googlebot spoofing (bot udajacy Googlebot). Cloudflare, Fastly, AWS CloudFront maja wszystkie oferuja crawl control. Wazne – CDN nie powinien cachowac odpowiedzi dla Googlebot inaczej niz dla userow (cachowanie odpowiedzi robi sie z IP bota, nie z User-Agent).
Co dalej
Zacznij od zrzutu GSC Crawl Stats i porownania z logami serwera z ostatnich 30 dni – to daje baseline do audytu. Jesli pracujesz w duzym e-commerce, warto jednoczesnie zaczac zbierac dane do automatyzacji – metodologia opisana w tekscie o pipeline automatyzacji SEO obejmuje monitoring crawl budget jako jeden z krokow. Dla stron z rozbudowana taksonomia warto rowniez spojrzec na przewodnik o topical map – dobre mapowanie tematow zmniejsza nature marnotrawstwa przez eliminacje thin content.
