Czym jest limit tempa pobierania

Google od lat opisuje to jako dwie niezależne rzeczy: ile adresów w serwisie warto pobrać oraz ile serwer jest w stanie znieść. Pierwsze wynika z popularności i jakości treści, drugie wyłącznie z zachowania infrastruktury.

Ten drugi element działa dynamicznie. Robot obserwuje czasy odpowiedzi i kody, które dostaje. Jeśli odpowiedzi przychodzą szybko i bez błędów, stopniowo zwiększa liczbę równoległych żądań. Jeśli czasy rosną albo pojawiają się kody z rodziny błędów serwera, ogranicza tempo — czasem drastycznie i na dłużej, niż trwała sama awaria.

Konsekwencja jest niewygodna: infrastruktura decyduje o tym, ile treści zostanie w ogóle zobaczone. Serwis z dwustoma podstronami tego nie odczuje. Sklep z kilkudziesięcioma tysiącami kart produktowych odczuje natychmiast, bo przy obniżonym tempie pełny obieg po serwisie wydłuża się z dni do tygodni.

Warto tu od razu rozbroić jedno nieporozumienie. Wolna odpowiedź nie jest karą ani sygnałem obniżającym ocenę treści. Skutek jest inny i w praktyce gorszy: nowe i zaktualizowane strony po prostu czekają dłużej w kolejce.

Gdzie warstwa pośrednicząca pomaga, a gdzie szkodzi

Sieć dostarczania treści z zasady powinna przyspieszać obsługę robota, bo część odpowiedzi wychodzi z pobliskiego węzła bez angażowania aplikacji. Tak to zwykle wygląda. Problemy zaczynają się w konkretnych, powtarzalnych sytuacjach.

• Chybienie w pamięci węzła przy każdym żądaniu robota. Robot odwiedza adresy, których ludzie nie odwiedzają — głęboko zagnieżdżone karty, warianty z parametrami, stare wpisy. Takich odpowiedzi w węźle nie ma, więc każde żądanie idzie do aplikacji, a węzeł dodaje do tego swój narzut.

• Nadmiarowa droga do aplikacji. Robot pobiera zwykle z infrastruktury Google, a nie z Polski. Jeśli węzeł, do którego trafi, leży daleko od aplikacji, powstaje trasa dłuższa niż połączenie bezpośrednie.

• Mechanizmy ochrony przed botami. Reguły ograniczające liczbę żądań z jednego adresu, weryfikacja przeglądarki, wyzwania zwracane zamiast treści. Robot dostaje wtedy kod błędu albo stronę pośrednią i traktuje to jak niedostępność serwisu.

• Przekierowania dodane na poziomie brzegu. Wymuszenie protokołu, dodanie lub usunięcie przedrostka w adresie, normalizacja końcowego ukośnika. Każde z osobna jest niegroźne, złożone razem tworzą łańcuch, który robot musi przejść przy każdym adresie.

Najbardziej podstępny jest przypadek pierwszy, bo nie widać go w żadnym raporcie użytkowym. Dla ludzi serwis jest szybki — bo ludzie chodzą po popularnych adresach, które w węźle leżą. Dla robota jest wolny.

Zasoby podrzędne i renderowanie

Osobny wątek, o którym łatwo zapomnieć: robot nie pobiera tylko dokumentu. Żeby zobaczyć stronę taką, jaką widzi użytkownik, musi też pobrać arkusze stylów i skrypty, a potem je wykonać.

Te zasoby zwykle leżą właśnie w sieci dostarczania treści i tu opóźnienie kosztuje podwójnie. Usługa renderująca ma ograniczony czas i ograniczony budżet na pobieranie zasobów podrzędnych. Jeśli plik ze skryptem odpowiada wolno albo zwraca błąd, może zostać pominięty. Strona zostanie wtedy oceniona bez części treści, którą ten skrypt dobudowuje.

W serwisach, w których treść powstaje po stronie przeglądarki, to nie jest problem teoretyczny. Widziałem karty produktowe indeksowane jako praktycznie puste, mimo że w przeglądarce wyglądały normalnie. Przyczyna leżała w jednym pliku, który przy żądaniu bez ciasteczek dostawał od warstwy ochronnej odpowiedź z błędem.

Dlatego przy diagnozie zawsze sprawdzam nie tylko adres strony, ale też adresy jej zasobów — osobno, bez sesji, bez nagłówków przeglądarki. Podejrzenia potwierdzają się częściej, niż bym chciał.

Druga rzecz, o którą warto zadbać: zasoby potrzebne do złożenia treści nie powinny być blokowane w pliku z regułami dla robotów. To wciąż zdarza się w konfiguracjach przenoszonych ze starszych wersji serwisu, gdzie blokowano całe katalogi z plikami wykonywalnymi.

Jak sprawdzić, czy problem jest realny

Bez danych ta cała analiza jest zgadywaniem, więc konkretna kolejność.

Zaczynam od raportu statystyk pobierania w Search Console. Interesują mnie trzy przebiegi w czasie: liczba żądań, średni czas odpowiedzi i rozkład kodów. Wzrost czasu odpowiedzi z jednoczesnym spadkiem liczby żądań to podpis mechanizmu ograniczania tempa. Data przełamania w wykresie zwykle wskazuje wprost, co się wtedy zmieniło.

Potem patrzę na rozbicie po typie pobieranego zasobu i po celu pobrania. Widać z niego, czy robot traci czas na dokumenty, na obrazy, czy na skrypty, i czy pobiera głównie nowe adresy, czy odświeża stare. Serwis, w którym prawie cały budżet idzie na odświeżanie, ma problem z jakością mapy witryny albo z nadmiarem adresów.

Trzeci krok to logi serwera i logi warstwy brzegowej równolegle. To jedyne miejsce, w którym widać różnicę między czasem, jaki zmierzył robot, a czasem, jakiego potrzebowała aplikacja. Jeśli aplikacja odpowiada szybko, a robot mierzy wolno, winna jest droga pomiędzy nimi.

Na koniec test punktowy: pobranie wybranych adresów narzędziem do sprawdzania adresu URL i porównanie tego, co widzi robot, z tym, co widzi przeglądarka. To najprostszy sposób wykrycia brakujących zasobów.

Ustawienia, od których zaczynam naprawę

Kolejność ma znaczenie, bo część zmian unieważnia wnioski z poprzednich pomiarów.

Najpierw wyłączam robota spod reguł ograniczających ruch automatyczny. Weryfikacja tożsamości robota przez adresy publikowane przez Google jest do tego właściwym sposobem — nie sam nagłówek identyfikujący klienta, bo ten łatwo podrobić.

Potem porządkuję przekierowania. Wszystkie normalizacje adresu składam w jeden skok i pilnuję, żeby linki w serwisie prowadziły od razu do wersji docelowej. Łańcuchy przekierowań zjadają budżet pobierania w sposób całkowicie niepotrzebny.

Trzeci krok to reguły przechowywania odpowiedzi w węźle dla adresów, których ludzie odwiedzają rzadko. Nawet krótki czas życia kopii zmienia obraz, bo robot chodzący po archiwum przestaje przy każdym adresie budzić aplikację.

Czwarty, najbardziej niewdzięczny: ograniczenie liczby adresów, które w ogóle warto pobierać. Filtry generujące nieskończone kombinacje parametrów, paginacja bez końca, warianty sortowania — to wszystko konkuruje o ten sam budżet z kartami produktów, na których nam zależy. Zwykle jest to praca do wykonania w serwisie, nie w konfiguracji sieci.

Czego nie da się z tego wywnioskować

Zamknę dwoma zdaniami ostrożności, bo temat łatwo przesadzić w drugą stronę.

Skrócenie czasu odpowiedzi nie jest dźwignią do podnoszenia pozycji. Google nie nagradza szybkiego serwera lepszymi wynikami — po prostu przestaje ograniczać tempo pobierania. Jeśli serwis miał kłopot z widocznością z powodu treści, po poprawie infrastruktury nadal będzie go miał, tylko szybciej się o tym dowiemy.

Nie ma też jednego progu, po przekroczeniu którego robot zwalnia. Zależy to od rozmiaru serwisu, historii i tego, jak stabilne są odpowiedzi. Zamiast szukać magicznej liczby, patrzę na kierunek zmian w czasie i na stabilność — bo wahania są dla robota gorszym sygnałem niż stale przeciętny, ale przewidywalny czas odpowiedzi.

Ostatnia uwaga praktyczna. Zmiany w warstwie dostarczania treści mają tę nieprzyjemną własność, że skutek w indeksowaniu widać z opóźnieniem liczonym w tygodniach. Warto więc zapisywać daty wdrożeń w jednym miejscu, bo bez tego za dwa miesiące nikt nie połączy spadku pobrań z konfiguracją zmienioną w piątek po południu.