Crawl budget: diagnoza i optymalizacja

Crawl budżet 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 budżet decyduje, czy Google w ogóle zobaczy nowe treści i jak szybko.

W 2026 roku crawl budżet 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 budżet i jak go policzyć

Crawl budżet 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 — więcej w artykule SEO 2026 – przewodnik.

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 budżet 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 budżet 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 budżet jest marnotrawiony

80% problemów crawl budżet 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 budżet

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 budżet a JavaScript rendering

JS-rendered content zużywa 3–5× więcej crawl budżet 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 budżet
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 budżet 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 budżet

Czy crawl budżet to problem dla mojego sklepu z 2000 produktami?

Prawdopodobnie nie. Google spokojnie indeksuje strony do 10 000 URL-i bez optymalizacji crawl budżet, 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 budżet 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 budżet?

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 budżet – 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 budżet 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.

Budżet – koszty analizy i optymalizacji

SME (do 50k URL)

• Audit jednorazowy: 8–20 tys. PLN (konsultant + narzędzia).
• Ongoing monitoring: 1,5–4 tys. PLN/mies. (freelance retainer).
• Narzędzia: GSC free + Screaming Frog 99 GBP/rok.

Mid-market (50k–500k URL)

• Audit: 30–80 tys. PLN.
• Monthly: 8–20 tys. PLN.
• Narzędzia: JetOctopus 300–1000 USD/mies., Ahrefs 500 USD/mies.

Enterprise (500k+ URL)

• Dedykowany team 2–4 FTE: 400 tys.–1 mln PLN/rok.
• Platform (Botify, Lumar): 30–150 tys. PLN/rok.
• Retainer agency: 20–80 tys. PLN/mies.

ROI optymalizacji crawl budżet

• Typowa optymalizacja uwalnia 15–30% budżetu dla ważnych URL.
• Traffic gain: 10–25% w 3–6 mies. po fixach.
• Break-even: 2–4 mies. dla mid-market, 1–3 mies. dla enterprise.
• Długoterminowy ROI: 5–12× w 12 mies. dzięki lepszej indexacji i pozycjom.
• Dodatkowe korzyści: niższe koszty hostingu (mniej marnotrawnego ruchu), szybsze time-to-index dla nowego contentu.
• Mniej błędów w GSC Coverage = mniejszy stres techniczny i prostszy raport dla zarządu.
• Konkurencyjna przewaga: większość rywali nie optymalizuje crawl budżet i tracisz oraz zyskujesz na tej pominiętej dyscyplinie.
• Lepsza widoczność w AI search – AI bots cenią dostępność i strukturę równie mocno jak Googlebot.
• Ułatwione planowanie content roadmap – wiesz, ile realnie możesz publikować bez ryzyka, że Google zacznie ignorować nowe URL-e.
• Stabilność rankingów podczas sezonowości i peaków traffic.

90-dniowy roadmap optymalizacji crawl budżet

Dni 1–30: diagnoza

• Audit obecnej sytuacji: GSC Crawl Stats, Screaming Frog crawl, log export 30 dni.
• Identyfikacja top 5 problemów (redirect chains, 5xx, thin content, orphans, crawl traps).
• Baseline KPI: crawl rate, error rate, unique URL crawled, time to index.

Dni 31–60: implementacja fixów

• Fix 5xx errors (najwyższy priorytet).
• Fix redirect chains – direct redirects.
• robots.txt optymalizacja – disallow low-value URL patterns.
• Sitemap split i resubmit w GSC.
• Internal linking audit i fix orphans.

Dni 61–90: monitoring i iteracja

• Setup automated monitoring (n8n procesy, Looker dashboard).
• Weekly review meetings z dev team.
• Comparison vs baseline – quantify improvement.
• Plan kolejnego kwartału (content pruning, URL rationalization).

Team i role – kto zarządza crawl budgetem

• Technical SEO: 12–18 tys. PLN B2B. Główny odpowiedzialny.
• Backend / Infrastructure Engineer: 16–24 tys. PLN. Server-side fixy.
• DevOps / SRE: 18–26 tys. PLN. CDN, hosting, caching.
• Data Engineer: 14–22 tys. PLN. Log analysis ciąg procesów.

Model zespołu

Skala site	Team	Miesięczny effort
< 10k URL	1 Tech SEO 0,1 FTE	4–8h/mies.
10k–100k	1 Tech SEO 0,3 FTE	15–30h/mies.
100k–1M	1 Tech SEO + 1 Backend	60–120h/mies.
1M+	Dedicated team 2–4 FTE	Fulltime

Automatyzacja monitoringu crawl budżet

Manualny monitoring skaluje się tylko do pewnego punktu. Od 100k URL – automatyzacja obowiązkowa.

n8n proces „Daily crawl health”

• Cron 7:00 – pobiera GSC Crawl Stats API.
• Porównuje z 7-day moving average.
• Alert Slack jeśli: 5xx rate > 1%, crawl volume spadł > 20%, Googlebot average response time wzrósł > 30%.
• Dashboard Looker Studio z daily trend.

Proces „Weekly log analysis”

• Niedziela wieczór – agreguje log z tygodnia.
• Top 20 crawled URL (dobry) vs top 20 z errors (zły).
• Comparison vs prev week — nowe problemy flagged.
• Mail do Technical SEO z summary + link do dashboardu.

Proces „Deploy impact monitoring”

• Webhook z CI/CD po każdym deployment.
• Następne 2h — intensywny monitoring crawl + CWV.
• Alert jeśli 5xx rate > 0,5% po deploy.
• Automatyczna rollback recommendation jeśli threshold exceeded.

Narzędzia do zarządzania crawl budżet

Monitoring i audit

• Google Search Console: Crawl stats report, Coverage, URL Inspection.
• Screaming Frog: crawl simulation, identifies crawl traps.
• Sitebulb: detailed crawl analysis, hint suggestions.
• Ahrefs Site Audit: weekly crawl, issue śledzenie.
• Lumar (ex-DeepCrawl): enterprise crawler, scheduled crawls.

Log analysis

• Screaming Frog Log File Analyser: desktop, affordable (99 GBP/rok).
• JetOctopus: cloud-based, log + crawl correlation.
• Semrush Log File Analyzer: w ramach Semrush plan.
• Botify / OnCrawl: enterprise platforms.

Infrastruktura

• Cloudflare: edge cache, WAF rules, bot management.
• Fastly: real-time logs, custom rules.
• BunnyCDN: affordable CDN with good performance.
• Redis / Memcached: object cache dla dynamic content.

Typowe problemy crawl budżet – sygnatury

Problem: Infinite crawl spaces

• Sygnatura: miliony URL w logach, większość filter/sort combinations.
• Fix: robots.txt disallow dla patterns, use JS SPA dla filtry.

Problem: Session IDs w URL

• Sygnatura: URL z parametrami ?sid=xyz123, nowe przy każdej wizycie.
• Fix: usuń session ID z URL, użyj cookies.

Problem: Paginacja bez limit

• Sygnatura: /blog/page/487/, tysiące stron paginacji.
• Fix: noindex,follow po page 5, canonical do page 1.

Problem: Kalendarz z nieskończoną głębokością

• Sygnatura: /events/2019/03/15/, /events/2018/11/28/…
• Fix: robots.txt disallow dla przeszłych dat, canonical do głównej events page.

Problem: Tag/category explosion

• Sygnatura: 10 000 tagów, 95% z 1 postem.
• Fix: konsolidacja tagów, noindex dla tagów < 3 posts.

Kiedy crawl budżet to realny problem

Większość SME nie ma problemu z crawl budżet. To głównie zagadnienie dla średnich i dużych serwisów. Dla każdej skali inne priorytety.

Do 10k URL – nie przejmuj się

• Google crawluje 100% ważnych URL bez optymalizacji.
• Skup się na content quality, nie crawl management.
• Podstawy: sitemap aktualny, canonical tagi, brak 5xx.

10k–100k URL – zacznij monitorować

• Wprowadź log analysis (nawet manualną, raz na kwartał).
• Audit sitemap vs real URL universe – czy wszystko co ważne jest w sitemap.
• Watch 4xx/5xx rate – cel < 1%.

100k–1 mln URL – aktywnie zarządzaj

• Monthly log analysis z identyfikacją wzorców.
• Sitemap split per content type.
• Robots.txt precise dla low-value URLs.
• Internal linking strategy.

1 mln+ URL – priority zadanie

• Dedykowany analyst z real-time monitoring.
• Custom dashboard dla key metrics.
• A/B tests optymalizacji.
• Budżet śledzenie per category/section.

Sygnały wpływające na crawl budżet — pełna lista

Google nie publikuje pełnej listy sygnałów, ale z dziesiątków lat obserwacji (John Mueller Q&A, Gary Illyes tweets, własne testy) znamy 8 głównych:

1. Host load / server health

• Googlebot monitoruje response time i error rate.
• Spada crawl rate automatycznie przy 5xx lub wolnych odpowiedziach.
• Fast hosting z < 500ms TTFB = wyższy crawl rate.

2. Content quality signals

• Thin content zmniejsza crawl priority dla nowych URL.
• Google „uczy się”, które sekcje są high-value i prioritizuje te.
• Helpful Content update bezpośrednio wpłynął na crawl distribution.

3. Internal linking strength

• URLs z silnym internal linking = wyższy crawl priority.
• Orphan pages (brak internal links) crawlowane rzadko lub wcale.
• Depth od homepage < 3 kliknięć = lepszy crawl rate.

4. Update frequency

• Pages aktualizowane regularnie crawlowane częściej.
• Stale pages (brak zmian > 12 mies.) crawlowane rzadko.
• News / blog content z częstymi publikacjami zwiększa host crawl rate.

5. Backlinks quality

• URLs z silnymi external backlinks = wyższy priority.
• Link authority przekłada się na crawl priority.
• Homepage z wysokim DR → wysoki crawl rate całej domeny.

6. Sitemap signals

• URL w sitemapie z lastmod signaluje priority.
• Sitemap per category pomaga Google zrozumieć strukturę.
• Updated sitemap = re-crawl triggera.

7. HTTP headers

• Last-Modified i ETag – pozwalają Googlebot użyć 304 (not modified).
• Cache-Control z sensownym TTL.
• Proper 200/301/404/410 – nie 200 dla missing content.

8. robots.txt directives

• Disallow oszczędza crawl budżet.
• Crawl-delay (dla Bingbot, Yandex).
• Sitemap declaration.

Optymalizacja crawl budżet – checklista 20 punktów

Szybkie wygrane (1 tydzień)

• Fix 404s – identyfikuj w GSC Coverage, naprawi redirecty.
• Fix 5xx errors – server-side, natychmiastowy impact.
• Optimizuj największe images (WebP, responsive sizing).
• Enable Gzip/Brotli compression.
• Fix broken internal links.

Średnioterminowe (1 miesiąc)

• Canonical strategy – 100% URL z canonical.
• Noindex dla wew. search results, filter URLs.
• Sitemap split per category.
• Internal linking audit – top 100 URL linkowanych z home.
• Redirect chains fix.
• Image CDN setup (Cloudflare, BunnyCDN).

Długoterminowe (3+ miesięcy)

• Upgrade hostingu dla CWV Good.
• JavaScript rendering audit – SSR vs CSR decision.
• Content pruning – usuń/consolidate thin content.
• URL structure rationalization.
• Log analysis rhythm (monthly).

Crawl budżet dla AI bots – nowy wymiar

W 2026 AI bots (GPTBot, ClaudeBot, PerplexityBot) generują 10–25% total crawl. Ich crawl budżet działa podobnie jak Googlebot, ale z różnicami:

Charakterystyka AI bots

• GPTBot: aggressive discovery, crawluje wszystko dostępne.
• PerplexityBot: wybiórczy, priorytetuje authoritative sources.
• ClaudeBot: umiarkowany, respects crawl-delay w większości przypadków.
• CCBot: używany przez wiele LLM, crawluje raz na 1–3 mies.

Optymalizacja dla AI bots

• Open robots.txt dla AI crawlers jeśli chcesz widoczności w AI search.
• Sitemaps z wszystkimi URL – AI bots nie spędzają czasu na discovery.
• Structured content (Schema.org) – AI preferuje strukturalne źródła.
• Factoid density — AI cytuje strony z konkretnymi faktami.
• Monitoring separately od Googlebot w logach.

Rate limiting

• Niektóre AI bots mogą generować 1000+ req/godz. – zawieszenie serwera.
• Cloudflare WAF rule: max 500 req/min per AI bot.
• Monitoring LCP/INP w okresach AI bot activity.

Case: marketplace z 800k URL, crawl budżet rescue

Klient: marketplace product listings, 800k URL, baseline: 50k crawl/dzień Googlebot, tylko 6% ważnych URL crawlowanych miesięcznie.

Problemy zidentyfikowane

• 500k URL z faceted search (size + color + price + brand combinations).
• 200k URL z paginacji (20 produktów per page, 10k pages).
• 100k legacy URL zdeprecjonowanych (nie usunięte, nie 301).
• 5xx errors na 2% requests podczas peak (DB bottleneck).

Rozwiązania

• robots.txt disallow dla facet combinations – obsługa przez JS SPA zamiast URL.
• 410 dla 100k legacy URL (szybkie usunięcie z indeksu).
• Paginacja: noindex, follow po stronie 5, canonical do page 1.
• DB optymalizacja – query caching, new indexes, Redis.
• CDN edge cache dla product pages (Cloudflare APO).

Rezultaty po 4 miesiącach

• Useful URL crawled monthly: 6% → 72%.
• Crawl errors rate: 2,1% → 0,3%.
• New products indexed within 7 days: 40% → 88%.
• Organic traffic: +54%.
• Przychód attributable to organic: +31% (180 tys. PLN/mies.).

Co dalej

Crawl budżet 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.

Jeśli chcesz pogłębić temat, sprawdź Rendering JavaScript pod SEO w 2026. Warto również zapoznać się z Indexing 2026.