Crawl budget — jak Google indeksuje dużą stronę

Google nie odwiedza Twojej strony w nieskończoność. Ma ograniczony „budżet" na crawlowanie — i jeśli marnujesz go na śmieciowe adresy, najważniejsze strony są indeksowane wolniej albo wcale. Crawl budget to temat, który małe witryny mogą zignorować, a który decyduje o widoczności dużych serwisów i sklepów. W tym przewodniku tłumaczę — w oparciu o oficjalny przewodnik Google — czym jest, kogo dotyczy i jak go optymalizować.

Google ma ograniczony budżet na crawlowanie — jeśli marnujesz go na śmieciowe URL-e, ważne strony są indeksowane wolniej albo wcale. Tłumaczę, czym jest crawl budget, kiedy ma znaczenie (sklepy, parametry URL) i jak go optymalizować.

Definicja Google: pojemność + popyt

Google definiuje crawl budget jako „zbiór adresów, które Googlebot może i chce crawlować". Składają się na niego dwa elementy:

• Crawl capacity limit (limit pojemności) — ile Googlebot może crawlować bez przeciążania serwera. Rośnie, gdy strona odpowiada szybko i stabilnie; spada przy błędach 5xx i wolnych odpowiedziach.
• Crawl demand (popyt na crawlowanie) — jak bardzo Google *chce* crawlować Twoje strony. Zależy od popularności adresów, ich świeżości oraz od tego, jak Google postrzega „inwentarz" witryny (im więcej śmieciowych URL-i, tym gorzej wykorzystany popyt).

Zasada: nawet jeśli serwer wytrzyma więcej, niski popyt oznacza mniej crawlowania. Muszą zaistnieć oba.

Kogo to naprawdę dotyczy (progi Google)

Oficjalny przewodnik Google jest „zaawansowany" i przeznaczony dla:

• serwisów 1 000 000+ unikalnych stron z treścią zmieniającą się mniej więcej co tydzień,
• serwisów 10 000+ stron ze zmianami codziennie,
• albo stron z dużym udziałem adresów w statusie „Wykryto – obecnie niezindeksowane".

Google podkreśla, że to orientacyjne progi. Małe witryny (do kilku tysięcy stron), zwłaszcza indeksowane tego samego dnia co publikacja, nie muszą się tym martwić.

Co marnuje crawl budget (lista Google)

Nawigacja fasetowa — wróg numer jeden

W sklepach internetowych pojedynczy problem odpowiada za większość zmarnowanego budżetu: nawigacja fasetowa (filtry koloru, rozmiaru, ceny, marki). Każda kombinacja filtrów tworzy nowy URL, a kombinacji są miliony — Googlebot może utonąć w nieskończonej przestrzeni adresów, które nie wnoszą nic nowego.

Strategia zależy od wartości danej fasety dla wyszukiwania:

Reguła: wybierz świadomie garść wartościowych faset do indeksacji, a resztę odetnij od crawla. Najczęstszy błąd to pozostawienie wszystkich kombinacji jako crawlowalnych linków — wtedy nawet duży serwer nie nadąży z indeksacją realnych produktów.

Crawl budget w e-commerce — typowe pułapki

Sklepy to środowisko, gdzie crawl budget boli najbardziej. Najczęstsze źródła marnotrawstwa poza fasetami:

• Produkty niedostępne / wycofane. Tysiące stron „brak w magazynie" pochłaniają crawl. Decyzja zależy od tego, czy produkt wróci: zostaw (200) jeśli wróci, 404/410 jeśli zniknął na stałe, ewentualnie przekieruj do następcy.
• Paginacja kategorii. Głębokie strony /kategoria?page=87 rzadko mają wartość — zadbaj o dotarcie do najważniejszych produktów inną drogą i rozważ ograniczenie głębokości.
• Warianty produktu jako osobne URL-e (kolor, rozmiar) — konsoliduj przez canonical do strony produktu nadrzędnego, jeśli różnią się tylko atrybutem.
• Identyfikatory sesji i parametry śledzące w adresach — klasyczny generator nieskończonych duplikatów.

Porządek w tych czterech obszarach zwraca Googlebotowi budżet, który trafia tam, gdzie chcesz: na realne, sprzedażowe strony produktów i kategorii.

Jak optymalizować (rekomendacje Google)

• Uporządkuj inwentarz URL-i. Konsoliduj duplikaty przez `rel=canonical`; usuwaj martwe strony kodem 404/410; eliminuj soft 404.
• Blokuj nieważne adresy w `robots.txt` (filtry, akcje, nieskończone przestrzenie). Pamiętaj: `Disallow` nie usuwa strony z indeksu — do tego służy `noindex` (który z kolei wymaga, by strona była crawlowalna).
• Zwracaj 304 dla niezmienionych stron. Googlebot wysyła nagłówek `If-Modified-Since`; jeśli treść się nie zmieniła, odpowiedz 304 Not Modified bez treści — oszczędzasz zasoby i Google crawluje więcej realnych adresów.
• Trzymaj czystą sitemap z trafnym `lastmod` — tylko kanoniczne, indeksowalne adresy.
• Spłaszczaj łańcuchy przekierowań do jednego skoku.
• Przyspiesz serwer — szybsze, stabilne odpowiedzi podnoszą limit pojemności. Dbaj o Core Web Vitals.

User-agent: *Disallow: /*?sort=Disallow: /*?filter=Disallow: /koszykDisallow: /szukajSitemap: https://twojadomena.pl/sitemap.xmlUwaga: dawny **suwak crawl rate w Search Console został wyłączony 8 stycznia 2024** — Google reguluje tempo automatycznie (zwalnia przy błędach 5xx/429 i rosnących czasach odpowiedzi).

Sitemapy i lastmod — jak sterować popytem

Sitemapa to nie tylko lista adresów — to sygnał popytu i mapa tego, co chcesz indeksować. Trzymaj w niej wyłącznie kanoniczne, indeksowalne URL-e (bez przekierowań, 404, `noindex` i adresów zablokowanych w robots). Element `lastmod` powinien odzwierciedlać realną datę istotnej zmiany treści — Google używa go jako wskazówki, co odświeżyć. Sztuczne ustawianie `lastmod` na „dziś" w całej sitemapie podważa zaufanie do tego sygnału i przestaje działać. Dla bardzo dużych serwisów dziel sitemapy tematycznie (np. per kategoria), bo w GSC od razu widać, która sekcja indeksuje się gorzej.

JavaScript a crawl budget — ukryty kosztożerca

Na dużych serwisach renderowanie JavaScriptu potrafi cicho zjadać budżet. Googlebot crawluje dwuetapowo: najpierw pobiera HTML, a renderowanie JS (uruchomienie strony, by zobaczyć treść doładowaną skryptem) trafia do osobnej kolejki i kosztuje znacznie więcej zasobów niż czysty HTML. Konsekwencje dla budżetu:

• Treść wstrzykiwana wyłącznie przez JS jest „droższa" do scrawlowania i bywa indeksowana z opóźnieniem — przy dużym serwisie to realne wąskie gardło.
• SSR lub statyczne generowanie (SSG) zamiast czystego client-side rendering oddaje Googlebotowi gotowy HTML i odciąża budżet.
• Każdy zbędny zasób (ciężkie skrypty, niepotrzebne pliki) podnosi koszt pojedynczego pobrania — porządki w renderowaniu to też porządki w budżecie.

Reguła: im więcej treści widać w surowym HTML bez wykonywania JS, tym efektywniej Google wykorzystuje Twój crawl budget. To ten sam fundament, który poprawia Core Web Vitals.

Crawl budget to nie indeksacja — i nie ranking

Dwa częste mity. Po pierwsze, crawlowanie ≠ indeksacja: strona może być scrawlowana i mimo to nie trafić do indeksu („Zaindeksowano: nie, scrawlowano – obecnie niezindeksowane" to zwykle sygnał jakości, nie budżetu). O indeksacji decyduje wartość strony, nie sam budżet. Po drugie, crawl budget nie jest czynnikiem rankingowym — to warunek wstępny (trzeba być scrawlowanym, by rankować), ale większy budżet nie podnosi pozycji.

Jak monitorować

W Search Console korzystaj z raportu Statystyki indeksowania (Crawl Stats): liczba żądań, rozmiar pobrań, średni czas odpowiedzi oraz rozbicia po kodzie odpowiedzi, typie pliku i celu (Discovery vs Refresh). W raporcie „Strony" obserwuj dwa statusy: „Wykryto – obecnie niezindeksowane" (Google zna URL, ale go jeszcze nie scrawlował — klasyczny objaw problemu z budżetem/popytem) i „Scrawlowano – obecnie niezindeksowane" (scrawlował, ale nie zaindeksował — sygnał jakości).

Analiza logów serwera — najgłębszy wgląd

Search Console pokazuje obraz zagregowany; logi serwera pokazują prawdę — każde żądanie Googlebota z osobna. Na co patrzeć:

• Rozkład trafień po sekcjach — ile crawla idzie na produkty/kategorie, a ile na śmieci (parametry, koszyk, filtry). To Twój wskaźnik „crawl waste".
• Kody odpowiedzi dla Googlebota — udział 404/5xx i przekierowań; wysoki odsetek to wyciek budżetu.
• Częstotliwość odwiedzin kluczowych stron — czy najważniejsze produkty są odwiedzane regularnie, czy raz na kwartał.
• Weryfikacja prawdziwego Googlebota — po odwrotnym DNS, bo wiele botów się podszywa.

Cel analizy jest prosty: zobaczyć, gdzie Googlebot marnuje czas, i tę część odciąć — przez `robots.txt`, kanonikalizację albo brak crawlowalnych linków.

---

Optymalizuję crawl budget dużych serwisów i sklepów w ramach technicznego SEO. Uczę tego w kursie SEO & GEO. Napisz do mnie — zacznę od analizy Twoich statystyk indeksowania i logów serwera.

Warto przeczytać dalej:

• Core Web Vitals — jak poprawić LCP, INP i CLS
• Migracja strony bez utraty pozycji w Google