Optymalizacja Crawl Budget

Czy Twój serwis ma problem z crawl budgetem? Diagnoza przed optymalizacją

Problem z crawl budgetem masz wtedy, gdy Google wie o ważnych adresach, ale ich nie pobiera albo pobiera je z dużym opóźnieniem, a jednocześnie wydaje żądania na adresy bez wartości. Jeśli nowe strony trafiają do indeksu w ciągu dnia lub dwóch, optymalizacja crawl budgetu nic nie da i lepiej zająć się treścią lub linkowaniem.

Google w przewodniku dla dużych serwisów (aktualizowanym w lipcu 2026 roku) podaje orientacyjne progi: ponad milion unikalnych stron zmieniających się mniej więcej co tydzień, ponad 10 000 stron zmieniających się codziennie albo duża liczba adresów w statusie „Wykryto – obecnie nie zindeksowano”. Ten ostatni warunek jest najważniejszy, bo dotyczy także mniejszych serwisów, np. sklepów z rozbudowanymi filtrami.

Dwa statusy, które łatwo pomylić

Raport indeksowania stron w Search Console rozróżnia dwie sytuacje, które wymagają zupełnie innych działań. Pomoc Search Console opisuje status „Wykryto – obecnie nie zindeksowano” tak: Google znalazł stronę, ale jej jeszcze nie pobrał, bo zwykle chciał, ale spodziewał się przeciążenia serwisu i przełożył crawl. Status „Zeskanowano – obecnie nie zindeksowano” oznacza, że strona została pobrana, ale nie trafiła do indeksu.

Raport statystyk indeksowania w Search Console: co z niego czytam

Raport „Statystyki indeksowania” pokazuje, ile żądań Google wysłał do serwisu, z jakim wynikiem i po co. To najszybsze źródło danych, jeśli nie ma logów, ale działa tylko dla usług na poziomie domeny lub katalogu głównego. Usługa dodana dla podkatalogu, np. /blog/, tego raportu nie ma.

Według pomocy Search Console raport dzieli żądania według odpowiedzi serwera, typu pliku (HTML, obraz, JavaScript, CSS, JSON i inne), celu (wykrywanie nowych adresów albo odświeżanie znanych) i typu Googlebota (smartfon, komputer, obrazy, wideo, wczytywanie zasobów strony, AdsBot, StoreBot i inne). Osobna sekcja „Stan hosta” pokazuje problemy z pobieraniem robots.txt, rozpoznawaniem DNS i połączeniem z serwerem w ostatnich 90 dniach.

Wzorce, na które patrzę

• Niski udział „Wykrywania” przy dużej liczbie nowych stron. Jeśli codziennie dodajesz setki produktów, a prawie całe żądania to odświeżanie starych adresów, Google nie nadąża z odkrywaniem nowych.
• Wysoki udział przekierowań i błędów 404. Każde takie żądanie to pobranie bez wartości. Zwykle pochodzi z nieaktualnych linków wewnętrznych albo z mapy witryny.
• Duży udział JSON lub „Inny typ pliku”. Często oznacza, że Googlebot pobiera endpointy API, które aplikacja JavaScript wywołuje przy renderowaniu.
• Wczytywanie zasobów strony jako duża część żądań. Strony wymagają wielu plików JS i CSS albo adresy plików zmieniają się przy każdym wdrożeniu.
• Średni czas odpowiedzi rosnący razem z liczbą żądań. Serwer zaczyna być wąskim gardłem; po przekroczeniu jego możliwości Google sam ograniczy tempo.
• Problemy z robots.txt w stanie hosta. Pomoc Search Console opisuje, że przy nieudanym pobraniu robots.txt Google może spowolnić lub wstrzymać indeksowanie, więc ten plik musi odpowiadać stabilnie.

Raport pokazuje przykładowe adresy, a nie pełną listę, i nie pozwala podzielić żądań według szablonu strony. Dlatego traktuję go jako punkt wyjścia, a decyzje opieram na logach.

Analiza logów serwera krok po kroku

Logi serwera to jedyne źródło, które pokazuje każde żądanie Googlebota do każdego adresu. Na ich podstawie widać, ile crawla trafia do stron sprzedażowych, a ile do filtrów, parametrów i błędów. Narzędzia typu crawler symulują robota; logi pokazują, co robot faktycznie robi.

1. Zdobycie logów. Pobieram logi dostępu z serwera (Nginx, Apache), z CDN (np. Cloudflare, Fastly) albo z platformy hostingowej. Przy CDN biorę logi z warstwy brzegowej, bo część żądań nie dociera do serwera źródłowego. Potrzebuję co najmniej adresu, statusu, czasu odpowiedzi, user-agenta, adresu IP i znacznika czasu.
2. Weryfikacja Googlebota. User-agent łatwo podrobić. Google opisuje dwie metody weryfikacji: odwrotne zapytanie DNS (domena googlebot.com, google.com lub googleusercontent.com) potwierdzone zapytaniem w przód albo porównanie adresu IP z publikowanymi listami zakresów, np. common-crawlers.json. Robię to automatycznie, bo w logach regularnie trafiam na boty, które tylko podszywają się pod Googlebota.
3. Klasyfikacja adresów według szablonu. Każdy adres przypisuję do grupy: karta produktu, kategoria, filtr, paginacja, wyszukiwarka wewnętrzna, artykuł, zasób statyczny, API, inne. Robię to regułami na wzorcach adresów, a dla nietypowych struktur skryptem, który porównuje adres z bazą produktów i kategorii.
4. Zestawienie z listą adresów kanonicznych. Łączę logi z wynikiem crawla serwisu i mapą witryny. Dzięki temu widzę adresy kanoniczne, których Googlebot nie odwiedził w badanym okresie, oraz adresy odwiedzane, których nie ma w żadnej strukturze (stare linki, parametry z kampanii, adresy generowane przez skrypty).
5. Wnioski per szablon. Dla każdej grupy liczę udział w żądaniach, rozkład statusów, częstotliwość odwiedzin i czas odpowiedzi. Dopiero na tej podstawie decyduję, co zamknąć, co przyspieszyć, a co wzmocnić linkami.

Okres analizy dobieram do tempa zmian w serwisie, zwykle kilka tygodni, żeby wyrównać wahania dzienne i objąć pełny cykl odświeżania najważniejszych szablonów. Do analizy używam Screaming Frog Log File Analyser przy mniejszych zbiorach, a przy milionach wierszy własnych skryptów i bazy danych (BigQuery lub DuckDB). Te same logi przydają się do pomiaru ruchu z asystentów AI, o czym piszę w artykule jak mierzyć ruch z ChatGPT, Perplexity i AI Mode.

robots.txt, noindex, canonical czy 404: które narzędzie do którego adresu

Każde narzędzie robi co innego: robots.txt zatrzymuje pobieranie, noindex usuwa z indeksu, ale wymaga pobrania, canonical scala sygnały, a 404 lub 410 kończy życie adresu. Najwięcej szkód w crawl budgecie widzę wtedy, gdy ktoś używa noindex do oszczędzania crawla albo blokuje w robots.txt strony, które powinny zniknąć z indeksu.

Google w przewodniku zaznacza też, żeby nie używać robots.txt do tymczasowego przesuwania crawla na inne strony. Blokada ma sens dla adresów, które mają zostać zamknięte na stałe. Szerzej o działaniu robots.txt, także wobec crawlerów AI, piszę w artykule Crawlery AI – kto skanuje Twoją stronę.

Nawigacja fasetowa: które filtry indeksować, a które odciąć

Filtr zasługuje na indeksowany adres tylko wtedy, gdy ludzie wyszukują dokładnie tę kombinację, a wynik ma wystarczająco produktów, żeby strona była użyteczna. Pozostałe filtry działają dla użytkownika, ale nie powinny tworzyć adresów dostępnych dla robota.

Jak wybieram filtry do indeksacji

1. Zbieram frazy z kombinacją kategorii i atrybutu (np. marka, materiał, zastosowanie) z narzędzi do słów kluczowych i z Search Console.
2. Dla każdej kombinacji sprawdzam liczbę produktów w sklepie. Strona z jednym lub dwoma produktami rzadko wygrywa z kategorią nadrzędną.
3. Sprawdzam wyniki wyszukiwania: jeśli Google pokazuje na tę frazę strony kategorii z filtrem, mam potwierdzenie intencji.
4. Wybrane kombinacje dostają statyczny, czytelny adres, własny tytuł, nagłówek, krótki opis i link z kategorii. Reszta zostaje filtrami bez adresów do indeksacji.

Zasady techniczne z dokumentacji Google

Google opublikował w grudniu 2024 roku osobny dokument o nawigacji fasetowej (aktualizowany w grudniu 2025). Zalecenia, które wdrażam:

• Jeśli filtrowane adresy nie są potrzebne w wynikach, blokuję parametry filtrów w robots.txt i zostawiam dostępne tylko karty produktów i niefiltrowane listy.
• Filtry zapisane we fragmencie adresu (po znaku #) nie wpływają na crawl, bo Google zasadniczo nie obsługuje fragmentów przy indeksowaniu. To dobre rozwiązanie dla filtrów czysto użytkowych.
• rel=canonical i rel=nofollow mogą ograniczyć crawl, ale Google opisuje je jako mniej skuteczne długoterminowo niż robots.txt. Nofollow działa tylko wtedy, gdy ma go każdy link do danego adresu.
• Jeśli filtry mają być crawlowane: standardowy separator & w parametrach, stała kolejność filtrów w adresie i brak zduplikowanych filtrów.
• Pusta kombinacja filtrów, nielogiczne zestawienie i nieistniejąca strona paginacji zwracają status 404, a nie przekierowanie do ogólnej strony błędu.

Sklepy mają też inne źródła szumu: produkty niedostępne, warianty na osobnych adresach i głęboką paginację. Strategię dla e-commerce szerzej opisuję w artykule SEO i GEO dla e-commerce.

Pojemność crawla: serwer, cache HTTP i zasoby strony

Pojemność crawla rośnie, gdy serwer odpowiada szybko i stabilnie, i spada przy błędach 5xx, odpowiedziach 429 i rosnącym czasie odpowiedzi. To ta część crawl budgetu, na którą mam bezpośredni wpływ w kodzie i infrastrukturze.

Cache HTTP i odpowiedź 304

Google w przewodniku dla dużych serwisów zaleca obsługę statusu 304 (Not Modified). W serii „Crawling December” z grudnia 2024 roku Google dodał, że jego crawlery obsługują żądania warunkowe z nagłówkami ETag i If-None-Match oraz Last-Modified i If-Modified-Since, i rekomenduje ETag, bo jest mniej podatny na błędy. Na kartach produktów i artykułach, które rzadko się zmieniają, wdrażam ETag liczony z treści strony, a nie z daty wygenerowania, bo inaczej każde żądanie wygląda jak zmiana.

Zasoby strony też zużywają crawl

W tej samej serii Google wyjaśnił, że pobieranie zasobów potrzebnych do wyrenderowania strony (JavaScript, CSS, odpowiedzi API) obciąża crawl budget hosta, który je serwuje, a usługa renderowania przechowuje pobrane pliki JS i CSS do 30 dni niezależnie od nagłówków cache. Wnioski dla wdrożenia: mniej plików na stronę, ostrożność z parametrami „cache busting”, które zmieniają adres pliku bez zmiany treści, i treść dostępna w HTML bez dodatkowych zapytań do API. Szczegóły renderowania opisuję w artykule JavaScript SEO.

Limit rozmiaru pliku

Dokumentacja Googlebota mówi obecnie, że przy crawlowaniu dla wyszukiwarki pobiera on pierwsze 2 MB obsługiwanego pliku i pierwsze 64 MB pliku PDF. Google opisał zmianę z lutego 2026 roku jako doprecyzowanie dokumentacji, a nie zmianę działania. Większość stron jest daleko od tego limitu, ale sprawdzam go na kategoriach z setkami produktów i dużym JSON-em stanu aplikacji wklejonym w HTML. Treść i linki za granicą 2 MB nie zostaną odczytane.

Ograniczanie crawla w awarii

Jeśli Googlebot przeciąża serwer, Google zaleca tymczasowe zwracanie statusu 500, 503 lub 429 (z nagłówkiem Retry-After) zamiast 200, ale tylko przez kilka godzin, najwyżej 1–2 dni. Przy dłuższym działaniu adresy mogą wypaść z indeksu. Narzędzie do ograniczania szybkości indeksowania w Search Console Google wyłączył 8 stycznia 2024 roku, więc trwałym rozwiązaniem jest wydajniejszy serwer i cache, a nie hamowanie robota.

Popyt na crawl: mapy witryny, lastmod i linkowanie wewnętrzne

Popyt na crawl zależy od tego, jak ważne i jak często aktualizowane wydają się Google adresy. Mapa witryny z wiarygodnym lastmod i linki wewnętrzne do kluczowych stron to dwa sygnały, które kontroluję w całości.

Mapy witryny podzielone według szablonów

Google ogranicza jedną mapę witryny do 50 000 adresów lub 50 MB bez kompresji; większe zbiory dzieli się na kilka map połączonych indeksem. Dzielę je nie tylko według limitu, ale według szablonu: osobno produkty, kategorie, artykuły, strony lokalizacji. W Search Console widać wtedy odsetek zaindeksowanych adresów w każdej grupie i od razu wiadomo, który szablon ma problem.

• W mapie są tylko adresy kanoniczne, indeksowalne, zwracające 200. Bez przekierowań, 404, noindex i adresów zablokowanych w robots.txt.
• lastmod zmienia się tylko przy istotnej zmianie treści, danych strukturalnych lub linków. Google używa tej wartości, jeśli jest konsekwentnie i sprawdzalnie trafna, a ignoruje ją, gdy każda strona ma dzisiejszą datę.
• priority i changefreq pomijam, bo Google je ignoruje.
• Mapa generuje się z tej samej bazy co strona, więc wycofany produkt znika z niej w tym samym momencie, w którym zaczyna zwracać 404 lub przekierowanie.

Głębokość kliknięć i linki do nowych stron

W crawlu serwisu sprawdzam, ile kliknięć od strony głównej dzieli kluczowe kategorie i produkty, oraz które kanoniczne adresy nie mają żadnego linku wewnętrznego. Nowe produkty linkuję z kategorii (na pierwszej stronie listy, nie na 40. stronie paginacji) i z bloków „nowości”, a artykuły z powiązanych tekstów i stron usług. Linkowanie wewnętrzne działa na popyt na crawl i jednocześnie na ranking, dlatego daje najwięcej przy najmniejszym ryzyku.

Poza Google warto pamiętać o Bingu, z którego indeksu korzystają m.in. Copilot i ChatGPT Search. Bing obsługuje protokół IndexNow, który powiadamia wyszukiwarkę o zmianie adresu od razu po publikacji. Piszę o tym w artykule Bing, Copilot i IndexNow.

Crawlery AI a wydajność serwera

Crawlery AI nie zabierają budżetu Googlebota, ale korzystają z tego samego serwera. Jeśli GPTBot, ClaudeBot czy inne boty generują duży ruch, serwer zwalnia, a wolniejszy serwer to niższa pojemność crawla dla Google.

W analizie logów zawsze wydzielam ruch botów AI i sprawdzam trzy rzeczy: ile żądań wysyłają, do jakich szablonów i jak wpływają na czasy odpowiedzi w godzinach szczytu. Decyzję, które boty wpuścić, podejmuję z klientem osobno dla botów treningowych i dla botów wyszukiwarek AI, bo te drugie mogą przynosić cytowania i ruch. Przy tych decyzjach łączę SEO techniczne z GEO, czyli pozycjonowaniem w AI.

Boty AI zwykle nie wykonują JavaScriptu, więc treść ładowana skryptem jest dla nich pusta. To kolejny argument za renderowaniem po stronie serwera, który działa jednocześnie na crawl budget Google i na widoczność w odpowiedziach AI.

Jak mierzę efekty optymalizacji crawl budgetu

Efekt mierzę zmianą udziału crawla w wartościowych adresach, czasem od publikacji do indeksacji i spadkiem liczby adresów „Wykryto – obecnie nie zindeksowano”. Ruch organiczny jest celem, ale reaguje później i zależy też od innych czynników.

Pierwsze zmiany w statystykach indeksowania zwykle widać po kilku tygodniach, dlatego w procesie zakładam 4–8 tygodni monitoringu po wdrożeniu. Zmiany porównuję z okresem bazowym o tej samej długości, a przy sklepach odnotowuję sezonowe piki, które same w sobie zmieniają zachowanie Googlebota.

Sytuacje szczególne: migracja, programmatic SEO, wersje językowe

Crawl budget najczęściej staje się problemem nie przez stały rozmiar serwisu, ale przez nagłą zmianę: migrację, wygenerowanie tysięcy nowych stron albo dodanie kolejnego języka. W tych sytuacjach planuję crawl przed wdrożeniem, a nie po spadku.

• Migracja i zmiana adresów. Po przeniesieniu serwisu Google musi pobrać stare adresy, żeby zobaczyć przekierowania, i nowe, żeby je zaindeksować. Przekierowania jednoskokowe, aktualne linki wewnętrzne i nowe mapy witryny od pierwszego dnia skracają ten okres. Opisuję to przy usłudze migracji SEO.
• Programmatic SEO. Tysiące stron wygenerowanych z bazy szybko przekraczają możliwości crawla, jeśli większość z nich jest do siebie podobna. Publikuję je partiami, zaczynając od kombinacji z realnym popytem, i obserwuję odsetek indeksacji w mapie witryny danej partii. Więcej w artykule Programmatic SEO z AI.
• Wersje językowe. Każdy język mnoży liczbę adresów, a błędne hreflang i canonicale potrafią sprawić, że Google crawluje wersje, które uznaje za duplikaty. Zasady opisuję w artykule Hreflang i SEO międzynarodowe.
• Aplikacje JavaScript. Serwis renderowany wyłącznie w przeglądarce zużywa crawl na zasoby i zapytania API. Przy przebudowie na renderowanie po stronie serwera, np. w ramach migracji do Next.js, problem często znika razem z architekturą.
• Porządki w treści. Tysiące cienkich, nieaktualnych artykułów też rozcieńczają popyt na crawl. Decyzje, co aktualizować, scalać, a co usuwać, opisuję w artykule Starzejące się treści.

Optymalizacja crawl budgetu jest częścią szerszej pracy nad techniką serwisu. Pełny kontekst usług znajdziesz na stronie pozycjonowania i SEO technicznego, a dane strukturalne, które często wdrażam przy tych samych szablonach, opisuję przy usłudze wdrażania Schema.org.