Jak zoptymalizować crawl budget dużej strony

Czy crawl budget to w ogóle Twój problem

Zanim zacznę optymalizować, sprawdzam, czy jest co. Google wprost pisze, że zarządzanie crawl budgetem dotyczy głównie dużych serwisów: takich, które mają ponad milion unikalnych adresów zmieniających się mniej więcej co tydzień, ponad 10 tysięcy adresów zmieniających się codziennie, albo dużą część stron w statusie „Strona wykryta – obecnie nie zindeksowana” w Search Console.

Jeśli Twoja strona ma kilkaset podstron i nowe treści pojawiają się w indeksie w ciągu kilku dni, problem z indeksowaniem leży gdzie indziej, najczęściej w jakości treści albo w linkowaniu. Optymalizacja budżetu niczego tam nie przyspieszy.

Sam budżet składa się z dwóch elementów. Pierwszy to limit, jaki robot nakłada, żeby nie przeciążyć serwera: gdy strona odpowiada szybko i bez błędów, limit rośnie, a gdy zwalnia lub zwraca błędy 5xx, Google ogranicza skanowanie. Drugi to zapotrzebowanie, czyli to, jak bardzo Google chce odwiedzać Twoje adresy, zależne od ich popularności i częstotliwości zmian. Optymalizacja polega na tym, żeby nie marnować pierwszego i nie rozpraszać drugiego.

Jak sprawdzam, na co robot marnuje czas

Pracę zaczynam od dwóch źródeł danych.

Statystyki indeksowania w Google Search Console (Ustawienia) pokazują, ile żądań Googlebot wysyła dziennie, jak szybko odpowiada serwer, jakie kody odpowiedzi dostaje robot i jakiego typu pliki pobiera. Zwracam uwagę na udział przekierowań i błędów, czas odpowiedzi oraz na to, czy większość żądań to odświeżanie znanych stron, czy odkrywanie nowych.

Logi serwera pokazują już konkretne adresy. Grupuję żądania Googlebota według typu strony: produkty, kategorie, filtry, wyniki wyszukiwania, parametry, zasoby. Dopiero taka analiza logów serwera pokazuje proporcje, np. że większość wizyt trafia w kombinacje filtrów, a karty produktów są odwiedzane raz na kilka tygodni.

Uzupełnieniem jest crawl własnym narzędziem, np. Screaming Frogiem, który pokazuje, ile adresów da się wygenerować z linków na stronie i jak głęboko w strukturze leżą ważne podstrony.

Najczęstsze źródła zmarnowanego budżetu

• Nawigacja fasetowa. Filtry koloru, rozmiaru, ceny i marki w dowolnych kombinacjach, często jeszcze z sortowaniem. Z jednej kategorii powstają tysiące adresów z prawie tą samą listą produktów.
• Parametry bez wpływu na treść. Identyfikatory sesji, parametry kampanii, widok siatki lub listy, liczba produktów na stronie.
• Wewnętrzna wyszukiwarka. Wyniki wyszukiwania dostępne pod linkami, które robot znajduje i skanuje bez końca.
• Przekierowania i łańcuchy. Każdy link prowadzący przez przekierowanie to dodatkowe żądanie, a łańcuch kilku przekierowań mnoży je dalej. W skrajnym przypadku kończy się to pętlą przekierowań.
• Strony błędów udające treść. Puste kategorie i usunięte produkty zwracające kod 200 zamiast 404 lub 410 robot odwiedza tak samo jak pełnowartościowe strony.
• Wolny serwer. Długi czas odpowiedzi i błędy 5xx bezpośrednio obniżają limit, więc robot odwiedza mniej stron, nawet jeśli wszystkie są wartościowe.

Co naprawiam i w jakiej kolejności

1. Wydajność i stabilność serwera. Zaczynam od czasu odpowiedzi i błędów, bo to one ustalają sufit dla wszystkich pozostałych działań. Cache stron, szybsze zapytania do bazy i eliminacja błędów 5xx często same zwiększają liczbę odwiedzanych adresów.
2. Ograniczenie przestrzeni adresów. Ustalam, które kombinacje filtrów mają wartość wyszukiwaniową, np. „buty do biegania damskie”, i robię z nich pełnoprawne, linkowane podstrony. Pozostałe kombinacje, sortowania i parametry techniczne blokuję w pliku robots.txt albo w ogóle nie generuję do nich linków, np. obsługując filtry formularzem zamiast odnośników.
3. Porządek w linkach wewnętrznych. Linki w menu, stopce i na listach produktów prowadzą bezpośrednio do docelowych adresów, bez przekierowań, parametrów i wersji z ukośnikiem na końcu i bez niego.
4. Poprawne kody odpowiedzi. Usunięte produkty zwracają 404 lub 410, a jeśli mają następcę, 301 do niego. Puste kategorie nie udają pełnych stron.
5. Mapy witryny z prawdziwymi datami. W mapach zostawiam tylko adresy kanoniczne zwracające 200, a lastmod zmieniam wyłącznie przy rzeczywistej zmianie treści. Wtedy mapa strony XML realnie podpowiada robotowi, co odświeżyć.
6. Obsługa nagłówków warunkowych. Jeśli serwer odpowiada kodem 304 na żądania z If-Modified-Since, Googlebot nie musi pobierać niezmienionej strony ponownie, co odciąża serwer przy dużej liczbie adresów.

Czego nie robić

• Noindex nie oszczędza budżetu. Robot i tak musi pobrać stronę, żeby zobaczyć tag noindex. To narzędzie do sterowania indeksem, a nie skanowaniem.
• Canonical też nie. Strony z canonical wskazującym inny adres są nadal skanowane. Canonical pomaga skleić duplikaty w indeksie, ale nie zmniejsza liczby żądań.
• Nie blokuj zasobów potrzebnych do renderowania. Zablokowanie plików CSS i JavaScript w robots.txt może oszczędzić kilka żądań, ale Google nie zobaczy wtedy strony tak jak użytkownik.
• Nie blokuj paginacji. Kolejne strony kategorii to dla robota droga do produktów, dlatego paginacja musi pozostać dostępna i oparta na zwykłych linkach.

Jak sprawdzam efekty

Po wdrożeniu zmian porównuję te same dane co na początku. W statystykach indeksowania sprawdzam, czy spadł udział przekierowań, błędów i adresów z parametrami, a w logach, czy rośnie częstotliwość wizyt na kartach produktów i w kategoriach. W raporcie stron w Search Console obserwuję, czy maleje liczba adresów „wykrytych, obecnie nie zindeksowanych”, a nowe produkty szybciej trafiają do indeksu.

Efekty nie są natychmiastowe, bo robot potrzebuje czasu, żeby przebudować obraz serwisu. Zwykle oceniam zmiany po kilku tygodniach, a przy bardzo dużych sklepach po kilku miesiącach. Najważniejsze jest, żeby każda zmiana była mierzona tymi samymi wskaźnikami, bo inaczej trudno odróżnić skutki optymalizacji od zwykłych wahań w zachowaniu Googlebota.