Crawl budget: diagnoza i optymalizacja

Crawl budget to limit zasobów, które Googlebot gotów jest wydać na przeszukiwanie Twojej domeny w określonym czasie. Dla sklepów z 500 produktami to kwestia drugorzędna. Dla marketplace’a z 200 000 URL-i, portalu z filtrami kategorii lub serwisu news z publikacją 200 artykułów dziennie — crawl budget decyduje, czy Google w ogóle zobaczy nowe treści i jak szybko.

W 2026 roku crawl budget stał się krytyczny z trzech powodów: wzrostu kosztów indexowania po stronie Google (limity fizyczne data centers), większego udziału JS-rendered content (koszt renderingu jest 3-5× wyższy niż statycznego HTML) i ekspansji AI crawlerów (GPTBot, ClaudeBot, PerplexityBot), które konkurują z Googlebotem o zasoby serwera. Pełen kontekst technicznego SEO opisujemy w przewodniku SEO 2026.

Czym jest crawl budget i jak go policzyć

Crawl budget to iloczyn dwóch zmiennych: crawl rate limit (ile requestów Googlebot może wykonać bez zmęczenia serwera) i crawl demand (jak bardzo Google chce odwiedzić stronę, bazując na popularności i świeżości). Produkt tych zmiennych definiuje realny limit dziennego crawla.

Crawl rate limit

• Google monitoruje czas odpowiedzi serwera i błędy 5xx.
• Serwer odpowiadający 1 s — niższy.
• Każdy 5xx obniża rate limit na 24–48 h.
• W Search Console → Crawl Stats widać dzienny wykres.
• Ręczne ustawienie (Crawl rate) zostało wycofane w 2024 — teraz tylko algorytmiczne.

Crawl demand

• Popularność: strony z wieloma linkami przychodzącymi crawlują się częściej.
• Świeżość: sekcje z częstymi zmianami (blog, aktualności) mają wyższy demand.
• Staleness: strony niezmienione 6+ miesięcy crawlują się rzadko (raz/miesiąc).
• Ważność: homepage i strony kategorii wyższego poziomu > pojedyncze strony produktowe.
• Hreflang: strony z hreflangiem dodatkowo crawlowane w kontekście wersji językowych.

Kiedy crawl budget jest realnym problemem

Sygnały z Search Console

1. Indexing Coverage pokazuje 30%+ stron „Discovered – currently not indexed” lub „Crawled – currently not indexed”.
2. Nowe treści indeksują się > 72h po publikacji (standardem jest 2–24h).
3. Średnia liczba requestów dziennie w Crawl Stats znacznie niższa od liczby URL-i w sitemap.
4. Growing gap między „Valid” a „Submitted” w sitemap reports.
5. Stałe ostrzeżenia o wykluczonych URL-ach z parametrami.

Progi wielkości, przy których zaczyna boleć

Liczba URL-i	Crawl budget status
< 10 000	Nie problem — Google indeksuje wszystko
10 000–50 000	Monitoruj; optymalizuj jeśli rośnie
50 000–500 000	Aktywna optymalizacja konieczna
> 500 000	Krytyczny priorytet — log analysis obowiązkowa

Gdzie crawl budget jest marnotrawiony

80% problemów crawl budget w audytach polskich sklepów Q1 2026 pochodzi z pięciu powtarzalnych źródeł. Każde z nich można zdiagnozować w ciągu 2–4 godzin.

Parameter URLs

• UTM tagi indeksowane jako osobne strony (?utm_source=facebook).
• Parametry filtracji w URL (?color=red&size=M).
• Parametry sortowania (?sort=price_asc, ?sort=price_desc).
• Session ID w URL (?session_id=abc123).
• Query strings od zewnętrznych trackerów (?gclid, ?fbclid).

Facet navigation

Filtry kategorii w e-commerce (kolor, rozmiar, marka, cena) generują tysiące kombinacji URL-i. 5 filtrów po 10 opcji = 10^5 teoretycznych stron, z czego 99% to duplikaty lub strony niskiej wartości. Rozwiązania: noindex dla kombinacji > 2 filtrów, kanoniczny do bazowej kategorii, robots.txt blok.

Search results pages

• Wewnętrzne strony wyszukiwania (site.com/search?q=produkt).
• Paginacja search (site.com/search?q=produkt&page=2).
• Google nie chce tych stron w indeksie — używa ich tylko do crawlu.
• Standard: blok w robots.txt (/search*, /szukaj*).

Soft 404 i pagination over-extension

• Strony kategorii z 0 produktami (soft 404).
• Paginacja page=1000 dla kategorii z 20 produktami.
• Strony profilowe użytkowników z 0 postami.
• Tag pages z 1 wpisem.

Duplicated content

• www vs non-www bez 301.
• http vs https bez 301.
• Trailing slash vs no trailing slash bez kanonicznych.
• Upper case vs lower case w URL.
• Ta sama treść na wielu URL-ach (print version, AMP, mobile subdomen).

Narzędzia do diagnozy crawl budget

Google Search Console

• Crawl Stats (Settings → Crawl stats) — wykres requestów dziennych, średni response time, breakdown po typach (HTML, image, JS, CSS).
• Index Coverage — ile URL-i indexed vs excluded, z podziałem na powód.
• Sitemaps — submitted vs indexed — różnica to pierwszy sygnał problemu.
• URL Inspection — pokazuje, kiedy Googlebot ostatnio crawlował dany URL.

Log file analysis

• Logi Apache / Nginx filtrowane po user-agent Googlebot.
• Narzędzia: Screaming Frog Log Analyzer, Oncrawl, JetOctopus, Botify.
• Pokazuje co Googlebot faktycznie robi, nie co powinien.
• Pełny tutorial opisujemy w osobnym artykule (Log file analysis dla SEO).

Screaming Frog crawl

• Symulacja Googlebota (user-agent + rendering).
• Wykrywa orphaned pages, broken links, długie redirect chains.
• Analiza linków wewnętrznych — ile linków wskazuje na każdy URL.
• Eksport crawl depth — jak głęboko od homepage jest każdy URL.

Optymalizacja — pięć dźwigni

1. Robots.txt — blokowanie marnotrawstwa

1. Zablokuj katalogi search, filter, parameter URLs w robots.txt.
2. Nie blokuj zasobów renderowania (CSS, JS) — Googlebot musi je ściągnąć do renderowania JS.
3. Przykład: Disallow: /search/, Disallow: /*?sort=, Disallow: /*?utm_*.
4. Test w Search Console → robots.txt tester przed deployem.
5. Po zmianie czekaj 48–72h na re-crawl robots.txt przez Google.

2. Meta robots i X-Robots-Tag

• <meta name="robots" content="noindex,follow"> dla stron niskiej wartości, które chcesz, żeby Google przeszedł (follow) ale nie indeksował.
• X-Robots-Tag w HTTP header dla plików nie-HTML (PDF, obrazy).
• Nie kombinować Disallow w robots.txt z noindex meta — Google nie zobaczy meta, jeśli nie może scrawlować strony.

3. Kanoniczne URL-e

• <link rel="canonical" href="..."> wskazuje preferowaną wersję.
• Dla filtracji: kanoniczny do bazowej kategorii bez filtrów.
• Dla paginacji 2026: każda strona jako canonical do siebie (rel=prev/next wycofane).
• Dla www/non-www, http/https: 301 zamiast kanonicznego (bezpieczniejsze).

4. Sitemap XML — czysty i aktualny

1. Tylko strony, które chcesz indeksować (200 status, canonical do siebie, indexable).
2. Maksymalnie 50 000 URL-i na sitemap; większe dziel na wiele plików w sitemap index.
3. Aktualizuj lastmod przy każdej zmianie treści — Googlebot używa do priorytetyzacji.
4. Rozdziel na sitemap per typ treści: /sitemap-products.xml, /sitemap-blog.xml, /sitemap-categories.xml.
5. W Search Console → Sitemaps zobaczysz indexed / submitted per sitemap.

5. Internal linking

• Ważne strony z crawl depth 2–3 od homepage, nie 5+.
• Breadcrumbs dla wszystkich stron produktowych i kategorii.
• Related products / related articles — linki z produktów na inne produkty.
• Hub pages — strony agregujące kategorii z linkami do poszczególnych.
• Strategia opisana szerzej w przewodniku SEO 2026.

Crawl budget a JavaScript rendering

JS-rendered content zużywa 3–5× więcej crawl budget niż statyczny HTML. Google używa dwuetapowego indeksowania: najpierw HTML, potem rendering w Web Rendering Service (WRS). Strony ciężkie JS-em siedzą w kolejce renderingu 1–14 dni.

Koszty crawlu dla różnych typów renderingu

Typ	Czas crawlu	Koszt dla budget
Static HTML (SSG)	50–200 ms	1× (baseline)
SSR (Next.js, Nuxt)	200–600 ms	1,5–2×
CSR (React, Vue SPA)	1–5 s + WRS queue	3–5×
Hybrid (ISR)	100–300 ms	1,2–1,5×

Pełne omówienie renderingu w kontekście SEO znajdziesz w Rendering JavaScript pod SEO w 2026.

Konkurencja AI crawlerów o zasoby serwera

W 2026 Googlebot konkuruje z GPTBot, ClaudeBot, PerplexityBot, CCBot i kilkoma mniejszymi. Łącznie AI crawlery generują 15–35% ruchu botów na typowym polskim e-commerce.

Strategia współżycia z AI crawlerami

1. Rozdziel user agents w logach — mierz każdego osobno.
2. AI crawlery zjadają pasmo serwera, które mogłoby trafić do Googlebota.
3. Decyzja: blokować AI crawlery w robots.txt (stracić AIO visibility) czy serwować (utrzymać AIO, ale nawalić bandwidth).
4. Kompromis: zezwolić AI na główne strony, zablokować na parameter URLs i paginacji.
5. Dla dużych serwisów: rate limiting per user-agent na poziomie serwera (nginx limit_req_zone).

Plan optymalizacji crawl budget w 30 dni

Tydzień 1: audyt

1. Pobierz 30 dni logów serwera; filtruj po Googlebot user-agent.
2. Screaming Frog crawl całej strony (max 500 000 URL-i).
3. Search Console → Crawl Stats, Index Coverage, Sitemap reports.
4. Lista 20 najbardziej crawlowanych URL-i — czy są wartościowe?
5. Lista 20 najmniej crawlowanych URL-i z sitemap — dlaczego Google je pomija?

Tydzień 2: robots.txt i meta robots

1. Dodaj Disallow dla parameter URLs, search, filter combinations.
2. Sprawdź i popraw meta robots na stronach niskiej wartości (soft 404, pagination).
3. Testuj w robots.txt tester przed deployem.
4. Deploy, monitoruj Crawl Stats 7 dni.

Tydzień 3: sitemap i kanoniczne

1. Przegenerowanie sitemap — tylko indexable 200-status URL-e.
2. Split na sitemap per typ treści.
3. Aktualizacja lastmod dla zmienionych URL-i.
4. Naprawa kanonicznych — wszystkie strony powinny canonical do siebie (chyba że alias).

Tydzień 4: internal linking

1. Audyt crawl depth — strony priorytetowe muszą być ≤ 3 kliki od homepage.
2. Dodanie breadcrumbs i related links.
3. Usunięcie orphaned pages lub dodanie do nich linków wewnętrznych.
4. Re-submit sitemap w Search Console.

Monitoring po optymalizacji

Metryki do śledzenia co tydzień

• Średnia liczba requestów Googlebot / dzień w Crawl Stats.
• Średni response time (< 200 ms = ok).
• Liczba 5xx w crawlu (0 = ideal).
• Indexed / submitted ratio w sitemap (> 95% = ok).
• Czas od publikacji do indexing dla nowych treści (< 24h = ok).

Kiedy ponownie zrobić full audit

1. Co 6 miesięcy rutynowo.
2. Po migracji domeny / CMS.
3. Po dodaniu nowej sekcji z 1000+ URL-ami.
4. Po update algorytmu Google (ogłoszonym).
5. Gdy Crawl Stats pokazuje spadek > 30% w ciągu 14 dni.

FAQ — najczęstsze pytania o crawl budget

Czy crawl budget to problem dla mojego sklepu z 2000 produktami?

Prawdopodobnie nie. Google spokojnie indeksuje strony do 10 000 URL-i bez optymalizacji crawl budget, pod warunkiem że serwer odpowiada szybko (< 500 ms) i nie ma 5xx. Problemy zaczynają się od 50 000 URL-i. Jeśli Twój sklep ma 2000 produktów, ale dodatkowo filtracje generują 500 000 kombinacji URL-i — wtedy tak, crawl budget jest problemem. Diagnoza: Search Console → Index Coverage → porównaj „Valid” z „Excluded”. Jeśli Excluded > 3× Valid, masz problem.

Czy robots.txt blokowanie jest lepsze niż noindex?

Nie zawsze. Robots.txt blokuje crawlowanie — Google w ogóle nie widzi strony, nie może jej zindeksować, ale też nie może przekazać page rank przez linki na niej. Noindex pozwala Google przeczytać stronę i przejść dalej linkami, ale nie indeksuje. Wybór: robots.txt dla czystego marnotrawstwa (search, parameter URLs); noindex dla stron, które mają wartość linking (author pages, tag pages). Nigdy nie łącz Disallow w robots.txt z noindex w meta — Google nie zobaczy meta.

Jak szybko widać efekty optymalizacji crawl budget?

Pierwsze sygnały w Crawl Stats 3–7 dni po deployu. Pełne efekty w indexing coverage 14–30 dni. Google potrzebuje czasu na przecrawlowanie całej strony i zaktualizowanie swojego wewnętrznego rozumienia sitemapy. Dla dużych serwisów (100 000+ URL-i) pełny cykl może trwać 60–90 dni. Nie panikuj, jeśli w pierwszym tygodniu Crawl Stats pokazują spadek requestów — to oczekiwane, bo Google uczy się nowej struktury.

Czy warto ręcznie zwiększać crawl rate w Search Console?

Nie da się. Google wycofał ręczne ustawienie crawl rate w 2024. Teraz wszystko jest algorytmiczne — oparte na szybkości serwera i demand. Jedyny sposób zwiększenia crawl rate: poprawa response time (< 200 ms), eliminacja 5xx, zwiększenie demand przez świeże treści i linki przychodzące. Szybszy serwer to dosłownie większy crawl budget — w audytach widzimy, że optymalizacja CDN i cachowania podwaja liczbę requestów Googlebot w ciągu 30 dni.

Czy AI crawlery (GPTBot, ClaudeBot) zjadają crawl budget Google?

Nie bezpośrednio — Google ma oddzielny budżet. Ale pośrednio: jeśli AI crawlery zasypują serwer, response time rośnie, Google obniża crawl rate dla Googlebota. W logach polskich e-commerce Q1 2026 widzimy AI crawlery generujące 15–35% ruchu botów. Decyzja strategiczna: blokować (stracić widoczność w ChatGPT, Claude, Perplexity) czy tolerować (zjada infra). Kompromis: rate limiting per user-agent (nginx) lub blokowanie AI na paramater URLs i search, ale pozwolenie na główne strony.

Czy pagination wymaga rel=prev/next?

Nie. Google wycofał support dla rel=prev/next w marcu 2019. W 2026 każda strona paginacji powinna mieć canonical do siebie i być normalnie indexable. Wyjątek: dla bardzo głębokiej paginacji (page=50+) warto noindex lub krótsza lista wyświetlanych produktów per strona. Dla list kategorii: infinite scroll z progressive enhancement (linki w HTML) działa najlepiej pod SEO; pure infinite scroll bez linków = orphaned pages.

Ile logów serwera trzeba zachowywać do analizy?

Minimum 30 dni dla typowej analizy. 90 dni dla pełnego obrazu sezonowości. 365 dni dla analizy year-over-year i trendów po update’ach algorytmu. W praktyce polskich e-commerce 90 dni to sweet spot — wystarczy danych, a koszty storage kontrolowalne. Logi kompresuj (gzip), przechowuj w cold storage (S3 Glacier, GCS Coldline). Do analizy bieżącej 30 dni w hot storage wystarczy. Narzędzia analizy (Screaming Frog Log Analyzer, JetOctopus) akceptują pliki gzipped bezpośrednio.

Co dalej

Crawl budget to mechanizm, który aktywujesz optymalizacją — nie ma magicznego switcha w Search Console. Kluczowe są: log analysis, robots.txt, canonicals, internal linking i szybki serwer. Każdy z tych elementów kontrybuuje 10–25% do ogólnego wyniku.

• Rendering JavaScript pod SEO w 2026 — wpływ renderingu na crawl budget.
• Indexing 2026 — dlaczego strony po crawlu nie trafiają do indeksu.
• Audyt SEO 2026 — gdzie crawl budget łączy się z pełnym audytem.
• SEO 2026 — przewodnik — kontekst technicznego SEO w całym ekosystemie.