Crawl budget określa, ile adresów w danym serwisie Google może i chce pobrać w określonym czasie. Ma największe znaczenie w dużych, szybko zmieniających się witrynach oraz serwisach generujących bardzo wiele wariantów URL-i. W małej stronie usługowej zwykle nie jest pierwszym ograniczeniem widoczności.
Optymalizacja nie polega na zmuszaniu Googlebota do częstszych wizyt. Najpierw trzeba sprawdzić, czy robot traci zasoby na duplikaty, filtry i błędy, czy serwer ogranicza pobieranie oraz czy najważniejsze strony otrzymują wyraźne sygnały dotyczące ich wartości.
Z czego składa się crawl budget?
Google opisuje crawl budget jako połączenie możliwości crawlowania i zapotrzebowania na ponowne odwiedzanie adresów. Pierwszy element zależy między innymi od odpowiedzi serwera i obciążenia witryny. Drugi od tego, jak ważna, popularna i aktualna może być dana strona.
Nie każdy adres jest odwiedzany z taką samą częstotliwością. Strona główna, ważna kategoria lub regularnie aktualizowana oferta może być pobierana częściej niż archiwalny tag bez linków wewnętrznych.
Nie istnieje też stały limit przydzielany stronie na zawsze. Zachowanie robota zmienia się wraz ze stanem serwera, liczbą adresów, częstotliwością zmian i zapotrzebowaniem systemów Google.
Kiedy crawl budget wymaga uwagi?
Temat jest szczególnie ważny, gdy serwis:
- ma setki tysięcy albo miliony adresów,
- codziennie publikuje lub zmienia dużą liczbę stron,
- generuje wiele kombinacji filtrów i parametrów,
- posiada rozbudowane archiwa, wyszukiwarkę lub kalendarze,
- ma dużo adresów oznaczonych jako „Discovered – currently not indexed”,
- regularnie odpowiada błędami 5xx albo działa bardzo wolno,
- przeszedł dużą migrację wymagającą ponownego pobrania URL-i.
Dla serwisu obejmującego kilkaset stabilnych stron większy wpływ mogą mieć słaba treść, duplikacja intencji, brak linkowania, canonicale albo niewłaściwy status HTTP. Prace nad crawl budgetem nie powinny zastępować rozwiązania tych problemów.
Crawled – currently not indexed a crawl budget
Status „Crawled – currently not indexed” oznacza, że Google pobrał stronę, ale obecnie nie umieścił jej w indeksie. Nie jest więc dowodem, że robot nie miał budżetu na odwiedzenie URL-a.
Przyczyny mogą dotyczyć między innymi podobieństwa do innych stron, niewielkiej wartości samodzielnej, słabego osadzenia w strukturze, niejednoznacznej intencji lub tymczasowej decyzji systemów Google. Adres może zostać zaindeksowany później bez ponownej publikacji.
W takiej sytuacji należy sprawdzić:
- czy strona powinna istnieć jako samodzielny wynik,
- czy nie powiela innego artykułu lub strony usługi,
- czy canonical wskazuje prawidłowy adres,
- czy URL znajduje się w aktualnej sitemapie i linkowaniu,
- czy treść odpowiada na odrębną potrzebę użytkownika,
- czy w raporcie skuteczności są wyświetlenia lub zapytania,
- czy lepszą decyzją nie będzie aktualizacja albo konsolidacja.
Szerszy proces diagnozy opisuję w poradniku o poprawie indeksowania strony.
Jak diagnozować sposób crawlowania serwisu?
Żadne pojedyncze narzędzie nie pokazuje pełnego obrazu. Warto połączyć kilka źródeł:
- raport indeksowania i statystyki indeksowania w Search Console,
- kontrolę adresu URL dla reprezentatywnych stron,
- aktualną mapę XML,
- crawl serwisu wykonany od strony głównej,
- logi serwera pokazujące żądania Googlebota,
- monitoring czasu odpowiedzi i błędów serwera,
- dane o linkach wewnętrznych oraz głębokości adresów.
Logi pozwalają sprawdzić, które URL-e są rzeczywiście odwiedzane, jak często i z jaką odpowiedzią. Crawler pokazuje natomiast, co robot może znaleźć, podążając za linkami w serwisie. Różnica między tymi zbiorami często ujawnia osierocone strony, pułapki parametrów albo niespójność sitemap.
Co najczęściej zużywa zasoby crawlowania?
Filtry i parametry
Sklep może generować tysiące kombinacji sortowania, koloru, ceny i dostępności. Jeśli każda kombinacja tworzy linkowalny adres, liczba URL-i rośnie znacznie szybciej niż faktyczna oferta.
Duplikaty i alternatywne wersje
Warianty z parametrami śledzącymi, ukośnikiem i bez niego, różną wielkością liter albo kilkoma hostami mogą prowadzić do tej samej treści. Wymagają spójnych przekierowań, canonicali i linkowania.
Soft 404
Pusta strona produktu lub komunikat o braku treści zwracający kod 200 może być wielokrotnie pobierany jak zwykły dokument. Jeżeli zasób nie istnieje, powinien zwracać właściwy kod. Różnice wyjaśniam w artykule o błędach 404 i soft 404.
Łańcuchy przekierowań
Jeżeli stary adres prowadzi do pośredniego URL-a, a dopiero ten do strony docelowej, robot i użytkownik wykonują dodatkowe żądania. Linki oraz reguły należy aktualizować tak, aby prowadziły bezpośrednio do końcowej wersji.
Błędy i niska wydajność serwera
Powtarzające się odpowiedzi 500, 502, 503 lub długi czas oczekiwania mogą ograniczać możliwości pobierania. Dalsze zwiększanie liczby linków do strony nie rozwiąże problemu infrastruktury.
Jak dobrać właściwe narzędzie kontroli URL-i?
Różne mechanizmy rozwiązują inne problemy:
- przekierowanie 301 stosuje się, gdy adres ma właściwego następcę;
- canonical wskazuje preferowaną wersję podobnych, dostępnych stron;
- 404 lub 410 informuje o braku zasobu bez odpowiednika;
- noindex wyklucza dostępną stronę z indeksowania, gdy robot może odczytać dyrektywę;
- robots.txt ogranicza pobieranie określonych ścieżek, ale nie jest zamiennikiem noindex;
- linkowanie wewnętrzne pokazuje relacje i znaczenie stron w architekturze;
- sitemap XML powinna zawierać podstawowe, działające i przeznaczone do indeksowania adresy.
Zablokowanie URL-a w robots.txt nie gwarantuje jego usunięcia z wyników. Jeżeli robot nie może pobrać dokumentu, nie zobaczy znajdującej się w nim dyrektywy noindex. Plik robots.txt i sitemapę należy więc projektować jako części jednego systemu. Więcej informacji znajduje się w poradniku o sitemap XML i robots.txt.
Jak poprawić efektywność crawlowania?
- Ustal, które typy stron powinny być indeksowane.
- Usuń źródła bezwartościowych kombinacji parametrów.
- Ujednolić linki, canonicale i warianty domeny.
- Połącz treści odpowiadające na tę samą intencję.
- Usuń łańcuchy oraz pętle przekierowań.
- Napraw soft 404 i powtarzające się błędy 5xx.
- Umieść w sitemapie wyłącznie właściwe adresy docelowe.
- Popraw czas odpowiedzi serwera i wykorzystaj mechanizmy pamięci podręcznej.
- Sprawdź rezultat w logach i Search Console.
Google publikuje aktualne zalecenia w dokumentacji dotyczącej crawl budgetu. Zwraca tam uwagę między innymi na zarządzanie zasobem URL-i, aktualne sitemapy, ograniczanie duplikatów, poprawne kody odpowiedzi i wydajność serwera.
Jak odebrać wdrożenie?
Po zmianach należy sprawdzić zarówno efekt techniczny, jak i zachowanie robota:
- \
- liczbę dostępnych kombinacji adresów,\
- udział żądań kierowanych do ważnych sekcji,\
- czas odpowiedzi i liczbę błędów 5xx,\
- zgodność sitemap z canonicalami i kodami odpowiedzi,\
- zmianę statusów reprezentatywnych URL-i,\
- kliknięcia, wyświetlenia i konwersje najważniejszych stron.\
\
\
\
\
\
\
Spadek liczby pobieranych, bezwartościowych parametrów jest korzystny tylko wtedy, gdy robot nadal dociera do produktów, usług i treści, które firma chce prezentować. Celem nie jest maksymalizacja ani minimalizacja crawlowania, lecz skierowanie go do właściwych adresów.
Jeżeli Search Console pokazuje dużą grupę niezaindeksowanych URL-i, mogę sprawdzić, czy przyczyną jest struktura, duplikacja, jakość treści, konfiguracja techniczna czy rzeczywisty problem z crawlowaniem. Taka analiza jest częścią audytu SEO. Napisz na czesc@seomariusz.pl lub zadzwoń: 665 015 610.