Z czego składa się budżet indeksowania

Google mówi o dwóch osobnych czynnikach i ta dwoistość jest najważniejszą rzeczą do zrozumienia.

Pierwszy to limit wydajności indeksowania. Robot pilnuje, żeby nie zaszkodzić serwerowi. Jeśli odpowiedzi przychodzą szybko i bez błędów, zwiększa tempo pobierania. Jeśli czasy odpowiedzi rosną albo pojawiają się błędy piątej setki, natychmiast zwalnia. To znaczy, że wydajność hostingu jest tu czynnikiem technicznym, nie „miękkim” — wolny serwer dosłownie ogranicza liczbę adresów, które Google pobierze w ciągu dnia.

Drugi to zapotrzebowanie na indeksowanie. Google pobiera częściej to, co jest popularne i to, co się zmienia. Adres, który od dwóch lat wygląda identycznie i nikt do niego nie linkuje, będzie odwiedzany rzadko, bo nie ma powodu, żeby było inaczej. Tu nie pomoże żaden zabieg techniczny — pomaga tylko to, żeby strona miała wartość.

Budżet to iloczyn tych dwóch rzeczy, nie stała liczba przypisana do domeny. Nie ma licznika, który da się „podbić” jednym ustawieniem, i nie ma progu, po przekroczeniu którego robot przestaje przychodzić.

Dla kogo to naprawdę problem

Powiem wprost: jeśli Twoja strona ma kilkaset adresów, budżet indeksowania nie jest Twoim problemem i nie będzie. Google poradzi sobie z takim serwisem bez żadnej pomocy. Kiedy słyszę, że przyczyną słabych pozycji małej strony firmowej jest crawl budget, zakładam, że ktoś nie sprawdził rzeczy oczywistych: treści, intencji zapytań i linków.

Sytuacje, w których naprawdę warto się tym zająć, są dość konkretne:

• Duże sklepy z filtrowaniem — kilka tysięcy produktów i parametry w adresach potrafią wygenerować setki tysięcy unikalnych URL-i, z których żaden nie wnosi nic nowego.

• Serwisy z bardzo szybko starzejącą się treścią — ogłoszenia, oferty pracy, wydarzenia. Tu liczy się nie tylko to, czy adres zostanie pobrany, ale kiedy.

• Serwisy po dużej migracji, w których robot musi jednocześnie przetrawić nowe adresy i stare przekierowania.

• Strony na słabym, przeciążonym hostingu — niezależnie od rozmiaru. Tu ograniczeniem jest wydajność, nie liczba adresów.

Jak sprawdzić, co się faktycznie dzieje

Nie zgaduję. W Search Console jest raport statystyk indeksowania i to jest pierwsze miejsce, do którego zaglądam. Interesują mnie trzy rzeczy: liczba żądań w czasie, średni czas odpowiedzi i rozkład kodów odpowiedzi. Skok czasu odpowiedzi połączony ze spadkiem liczby żądań to klasyczny obraz serwera, który nie wyrabia.

Drugie miejsce to raport indeksowania stron. Czytam nie tylko liczbę adresów zaindeksowanych, ale przede wszystkim powody wykluczenia. Duża grupa „wykryte, ale jeszcze nie zaindeksowane” przy dużym serwisie to sygnał, że Google ma kolejkę, której nie nadąża przerabiać albo nie uznaje jej za wartą uwagi.

Najbardziej wiarygodne dane leżą jednak w logach serwera. Widać w nich dokładnie, po jakich adresach chodzi robot i ile razy. Prawie za każdym razem, gdy analizuję logi dużego sklepu, okazuje się, że znaczna część wizyt robota trafia w adresy z parametrami sortowania i paginację — czyli w miejsca, na których nikomu nie zależy.

Co marnuje budżet najczęściej

Lista jest krótka i powtarzalna. Filtry i sortowanie generujące osobne adresy dla każdej kombinacji. Identyfikatory sesji w URL-ach. Wyniki wyszukiwania wewnętrznego dostępne dla robota. Nieskończona paginacja. Kalendarze, które potrafią wygenerować adres dla każdego dnia następnych dziesięciu lat.

Do tego dochodzą rzeczy mniej oczywiste: łańcuchy przekierowań, w których każde ogniwo to osobne żądanie, oraz strony błędów zwracające kod 200. Robot pobiera je jak zwykłe podstrony i dopiero potem stwierdza, że nie ma tam treści.

Osobno wymienię duplikaty wynikające z niekonsekwencji technicznej: ta sama treść pod adresem z i bez ukośnika na końcu, po http i https, z i bez „www”. To nie jest egzotyka, to bardzo częsty stan sklepów rozwijanych latami.

Co robić, a czego nie robić

Kolejność działań ma znaczenie, bo część zabiegów wyklucza się wzajemnie.

Zaczynam od ograniczenia liczby adresów, które w ogóle powstają. Filtry, które nie mają wartości wyszukiwawczej, najlepiej obsłużyć tak, żeby nie tworzyły nowych URL-i. To robota dla programisty, nie dla wtyczki SEO, i jest to najskuteczniejszy krok z całej listy.

Potem blokuję w robots.txt te wzorce adresów, po których robot nie ma po co chodzić — wyszukiwanie wewnętrzne, koszyk, parametry sortowania. Ważna uwaga: blokada w robots.txt nie usuwa adresu z indeksu. Jeśli chcesz coś wyindeksować, potrzebujesz znacznika noindex, a wtedy adres nie może być zablokowany, bo robot nie zobaczy tego znacznika. Te dwa narzędzia rozwiązują różne problemy i mieszanie ich jest źródłem większości pomyłek, jakie widuję.

Dalej porządkuję sygnały: poprawne adresy kanoniczne, mapa witryny zawierająca wyłącznie adresy, które mają być w indeksie, i linkowanie wewnętrzne prowadzące do rzeczy ważnych. Robot idzie za linkami, więc struktura nawigacji jest realnym narzędziem sterowania jego uwagą.

Czego nie robię: nie liczę na to, że przesłanie mapy witryny przyspieszy cokolwiek samo z siebie, i nie używam ręcznego zgłaszania adresów jako metody pracy przy tysiącach podstron.

Kiedy odpuścić i zająć się czymś innym

Uczciwa konkluzja jest taka: u większości klientów, z którymi pracuję, budżet indeksowania nie jest wąskim gardłem. Wąskim gardłem jest treść, która nie odpowiada na zapytania, albo strona, której nikt nie linkuje.

Jeśli nowe podstrony wchodzą do indeksu w ciągu kilku dni, raport statystyk indeksowania nie pokazuje anomalii, a serwis ma poniżej kilku tysięcy adresów — zamknij ten temat i wróć do niego, gdy serwis urośnie. Czas poświęcony na mikrooptymalizację robots.txt w takiej sytuacji jest czasem straconym.

Odwrotnie: jeśli prowadzisz sklep z dziesiątkami tysięcy adresów, nowe produkty wchodzą do indeksu tygodniami, a w logach widzisz robota krążącego po parametrach filtrów, to masz konkretny problem inżynieryjny i warto go rozwiązać przed jakąkolwiek pracą nad treścią. Bez tego najlepsze opisy kategorii po prostu nie zdążą zostać zauważone.