Crawl budget - czym jest budżet indeksacji i jak go optymalizować?
Crawl budget to pojęcie, które dla większości małych stron nie ma praktycznego znaczenia. Staje się ważne w dużych sklepach i serwisach, w których Googlebot ma do wyboru dziesiątki albo setki tysięcy adresów. Jeżeli regularnie odwiedza filtry, parametry i techniczne warianty URL-i, a z opóźnieniem dociera do nowych produktów lub aktualizowanych kategorii, problem może bezpośrednio ograniczać indeksację i widoczność w Google.
Dla większości małych i średnich stron wystarczy aktualna sitemapa XML, poprawne linkowanie i kontrola indeksacji. W dużym e-commerce trzeba już mierzyć, gdzie rzeczywiście trafia Googlebot. Crawl budget nie jest bowiem dziennym limitem stron ani suwakiem, który można po prostu „przesunąć” z filtrów na produkty.
Co to jest crawl budget?
Google definiuje crawl budget jako zbiór URL-i, które jego systemy mogą i chcą crawlować w danej witrynie. Wynika on z dwóch elementów, ale nie jest ich matematycznym iloczynem.
| Element | Co opisuje | Co na niego wpływa |
|---|---|---|
| Crawl capacity limit | Ile równoległych połączeń i jaką częstotliwość pobierania może bezpiecznie obsłużyć witryna | szybkość i stabilność odpowiedzi, błędy serwera oraz własne limity zasobów Google |
| Crawl demand | Jak duże jest zapotrzebowanie systemów Google na nowe i ponowne odwiedziny URL-i | rozpoznany zbiór adresów, popularność, świeżość, częstotliwość zmian, unikalność i przydatność treści |
Jeżeli serwer zwalnia albo zwraca błędy 5xx, limit możliwości crawlowania może spaść. Nie oznacza to jednak, że samo przyspieszenie serwera automatycznie zwiększy liczbę odwiedzin Googlebota. Gdy zapotrzebowanie jest niskie albo ważne strony nie są prawidłowo odkrywane, dodatkowa wydajność nie tworzy popytu na crawling.
Warto też oddzielić crawling od indeksacji. Google może pobrać stronę, a następnie nie dodać jej do indeksu po ocenie treści, duplikatów i sygnałów kanonicznych. Zwiększenie liczby żądań Googlebota nie jest więc celem samym w sobie. Celem jest sprawne odkrywanie i odświeżanie właściwych URL-i.
Kiedy crawl budget staje się realnym problemem?
Nie istnieje jeden próg liczby stron, po którego przekroczeniu każda witryna ma problem. Google podaje jedynie orientacyjne grupy serwisów, dla których zaawansowane zarządzanie crawlingiem może mieć znaczenie:
- ponad milion unikalnych stron, jeśli treść zmienia się mniej więcej raz w tygodniu,
- ponad 10 000 unikalnych stron, jeśli treść zmienia się bardzo szybko, na przykład codziennie,
- witryny, w których duża część URL-i ma w Search Console status „Wykryto — obecnie nie zindeksowano”.
Google zaznacza, że są to przybliżenia, a nie ścisłe progi. Sklep z kilkoma tysiącami produktów może mieć problem, jeżeli nawigacja generuje niemal nieskończoną przestrzeń parametrów. Serwis z setkami tysięcy stabilnych, dobrze uporządkowanych adresów może natomiast nie wymagać specjalnej optymalizacji, jeśli ważne zmiany są crawlowane bez opóźnień.
Sygnałem do analizy są przede wszystkim obserwowane skutki:
- nowe produkty, kategorie lub artykuły długo nie są odwiedzane przez Googlebota,
- zaktualizowane ceny, dostępność albo treść długo pozostają nieodświeżone w Google,
- logi pokazują dużą liczbę żądań do filtrów, sortowania, wyszukiwarki wewnętrznej lub identyfikatorów sesji,
- raport statystyk indeksowania wskazuje problemy z dostępnością hosta, wzrost
5xxalbo wydłużenie czasu odpowiedzi, - liczba adresów odkrywanych przez systemy Google wyraźnie przekracza liczbę stron, które rzeczywiście powinny być dostępne w wynikach.
Jak sprawdzić crawl budget w Google Search Console?
Najprościej zacząć od raportu Ustawienia → Statystyki indeksowania w Google Search Console. Pokazuje on, jak często Googlebot odwiedza serwis, jak odpowiada host i na jakie typy zasobów trafia.
W raporcie sprawdź przede wszystkim:
- łączną liczbę żądań i jej zmiany w czasie,
- stan hosta oraz problemy z
robots.txt, DNS-em i połączeniem z serwerem, - średni czas odpowiedzi — szczególnie nagłe pogorszenie zbieżne ze spadkiem crawlowania,
- rozkład kodów odpowiedzi — zwłaszcza przekierowania,
404, pozostałe4xxi błędy5xx, - cel crawlowania — odkrywanie nowych adresów albo odświeżanie już znanych,
- typ Googlebota i typ pobieranego pliku.
Nie oceniaj sytuacji wyłącznie po liczbie żądań. Najważniejsze pytanie brzmi: czy Googlebot szybko dociera do nowych i aktualizowanych produktów, kategorii oraz treści? Jeżeli tak, crawl budget prawdopodobnie nie ogranicza widoczności serwisu.
Raport zawiera przykładowe URL-e, a nie pełną historię wszystkich wizyt. Gdy ważne strony są odwiedzane z opóźnieniem albo większość przykładów prowadzi do filtrów i parametrów, warto sięgnąć do logów serwera. Logi pokażą, które klasy adresów Googlebot odwiedza najczęściej i jaki kod odpowiedzi otrzymuje. To etap zaawansowanej diagnozy dużego serwisu, nie warunek rozpoczęcia analizy.
Googlebot omija ważne produkty i kategorie?
Sprawdzimy Search Console, strukturę adresów i — gdy będzie to potrzebne — logi serwera, aby wskazać, gdzie sklep traci zasoby crawlowania.
Jak optymalizować crawl budget?
Optymalizacja budżetu indeksacji polega na ograniczeniu zbędnych adresów i ułatwieniu Googlebotowi dotarcia do stron, które mają realną wartość dla użytkowników oraz powinny pojawiać się w wynikach wyszukiwania.
Zablokuj zbędne przestrzenie w robots.txt
Plik robots.txt pozwala zablokować crawling sekcji, których Google nie powinien odwiedzać, na przykład wyników wewnętrznego wyszukiwania, koszyka albo nieskończonych kombinacji parametrów.
Pamiętaj, że robots.txt blokuje crawling, ale nie gwarantuje usunięcia znanego URL-a z indeksu. Sama blokada nie oznacza też automatycznie, że wszystkie zaoszczędzone żądania trafią do produktów. Po zmianie sprawdź w Search Console i logach, czy Googlebot rzeczywiście częściej odwiedza ważne strony.
Używaj noindex i canonicala zgodnie z ich funkcją
Dyrektywa noindex informuje Google, że strona nie powinna znaleźć się w wynikach. Canonical wskazuje natomiast preferowaną wersję, gdy kilka adresów pokazuje tę samą lub bardzo podobną treść.
Oba rozwiązania wymagają pobrania strony, aby Google mógł odczytać wskazanie. Nie zastępują więc kontroli nad tym, ile technicznych URL-i generuje i linkuje sam serwis.
Uporządkuj sitemapę i linkowanie wewnętrzne
Sitemapa powinna zawierać kanoniczne URL-e, które mają być indeksowane. Aktualizuj lastmod tylko wtedy, gdy główna treść strony rzeczywiście się zmieniła. Nie umieszczaj w mapie przekierowań, stron noindex, błędów ani technicznych wariantów adresów.
Google odkrywa strony również przez linki. Ważne produkty i kategorie powinny być osiągalne zwykłymi linkami <a href>, a nie wyłącznie po użyciu wyszukiwarki, formularza czy wykonaniu JavaScriptu. Nie ma gwarantowanej reguły „maksymalnie trzech kliknięć”; liczy się logiczna architektura, brak osieroconych stron i konsekwentne linkowanie do kanonicznych URL-i.
Popraw wydajność tam, gdzie ogranicza crawling
Jeżeli Crawl Stats pokazuje problemy ze stanem hosta, a logi potwierdzają wolne odpowiedzi lub 5xx, poprawa wydajności i dostępności może zwiększyć crawl capacity. W zależności od źródła problemu może to oznaczać optymalizację zapytań, cache HTTP, usunięcie ciężkich operacji z żądań użytkownika, naprawę błędów aplikacji albo zwiększenie zasobów serwera.
Nie blokuj plików CSS i JavaScript tylko po to, aby zmniejszyć liczbę żądań. Jeśli są potrzebne do renderowania głównej treści, utrudnisz Google ocenę strony. Współdzielone zasoby utrzymuj pod stabilnymi adresami, aby crawler mógł korzystać z cache.
Crawl budget w e-commerce: najczęstsze pułapki
Warianty produktowe
Sklep z 5 tys. produktów, czterema kolorami i sześcioma rozmiarami może wygenerować nawet 120 000 adresów kart produktowych — jeżeli platforma wystawia osobny URL dostępny do crawlowania dla każdej kombinacji. Nie oznacza to, że każdy wariant należy canonicalizować do produktu głównego.
Najpierw ustal, czy wariant ma osobną dostępność, cenę, zdjęcia, identyfikator, popyt i wartość dla użytkownika. Istotne warianty mogą wymagać własnych stron. Techniczne kombinacje bez osobnej wartości powinny prowadzić do stabilnego, kanonicznego modelu produktu bez mnożenia linkowanych URL-i.
Nawigacja fasetowa
Dziesięć filtrów z wieloma wartościami może utworzyć miliony kombinacji, nawet gdy sklep ma tylko kilka tysięcy produktów. Google wskazuje nawigację fasetową jako jedno z najczęstszych źródeł nadmiernego crawlowania.
Nie blokuj jednak wszystkich filtrów jedną regułą. Część kombinacji może odpowiadać na realne zapytania, np. kategorię, markę, rozmiar i zastosowanie. Podziel je na:
- indeksowalne landing pages z popytem, stabilnym asortymentem i własną treścią,
- użyteczne dla klientów filtry, które nie tworzą osobnego celu SEO,
- bezwartościowe lub nieskończone kombinacje techniczne.
Pełną macierz decyzji opisujemy w artykule o nawigacji fasetowej w e-commerce.
Paginacja
Kolejne strony paginacji powinny mieć osobne URL-e dostępne do crawlowania i linki prowadzące do następnych części listy. Nie canonicalizuj wszystkich do strony pierwszej i nie dodawaj automatycznie noindex, ponieważ Google potrzebuje ścieżki do produktów znajdujących się głębiej w kategorii.
Jeżeli katalog ma setki stron paginacji, problemu nie rozwiąże ukrycie numerów. Sprawdź liczbę produktów na stronie, linki do podkategorii, dostępność ważnych produktów w innych miejscach serwisu oraz to, czy puste i nieistniejące numery zwracają właściwy 404.
Sortowanie, wyszukiwarka, sesje i akcje
Adresy sortowania, wyniki wyszukiwarki wewnętrznej, identyfikatory sesji, koszyk, porównywarka i akcje typu „dodaj do ulubionych” mogą tworzyć bardzo duży zbiór URL-i bez wartości dla Search. Usuń zbędne linki do technicznych wariantów i zastosuj stabilne reguły crawlowania zgodne z ich funkcją. Nie polegaj wyłącznie na canonicalu, jeśli serwis stale generuje oraz linkuje nieskończone kombinacje.
Feedy produktowe i adresy techniczne
Sam plik feedu produktowego nie jest problemem z crawl budgetem i nie należy blokować go automatycznie — może być potrzebny Merchant Center, porównywarce lub innej integracji. Problem zaczyna się wtedy, gdy feed, szablon albo wtyczka wystawia i rozpowszechnia dodatkowe adresy produktów: z parametrami śledzenia, identyfikatorami eksportu, wersją do druku, pozostałością po AMP albo innym technicznym wariantem tej samej strony.
Sprawdź, czy linki produktowe w feedzie prowadzą do stabilnych adresów zwracających 200 i zgodnych z canonicalem. Następnie zweryfikuj w logach, czy Googlebot rzeczywiście odwiedza techniczne warianty. Dopiero na tej podstawie dobierz rozwiązanie: usuń zbędne linki wewnętrzne, popraw generator URL-i, przekieruj nieaktualne adresy albo zastosuj właściwy canonical, noindex lub regułę w robots.txt. Nie blokuj całej klasy adresów tylko dlatego, że wygląda technicznie — najpierw ustal, kto i do czego jej używa.
Jeżeli problem dotyczy samej jakości danych wysyłanych do Google, a nie crawlingu sklepu, przejdź do poradnika o feedzie produktowym w reklamach i bezpłatnych wynikach Google.
Problemy konkretnych platform omawiamy osobno w poradnikach o crawl budget w WooCommerce oraz indeksacji dużych katalogów Magento.
Jak mierzyć efekt optymalizacji?
Przed wdrożeniem zapisz punkt odniesienia, a później porównaj:
- jak szybko Googlebot dociera do nowych i zaktualizowanych produktów,
- jaki udział żądań trafia do właściwych stron, a jaki do filtrów, parametrów i błędów,
- ile ważnych URL-i pozostaje w stanie „Wykryto — obecnie nie zindeksowano”,
- czy poprawił się stan hosta, czas odpowiedzi i udział błędów
5xx, - czy zmiany techniczne przełożyły się na indeksację, widoczność i ruch organiczny.
Najpierw powinieneś zobaczyć zmianę w zachowaniu Googlebota i indeksacji, dopiero później w ruchu. Tempo zależy od wielkości serwisu i częstotliwości odwiedzin, dlatego zamiast czekać na umowny termin, sprawdzaj, czy właściwe strony są odkrywane i odświeżane szybciej.