Trzy różne problemy pod jednym hasłem

Zanim cokolwiek ustawię, ustalam, z czym mam do czynienia, bo środki zaradcze są rozłączne.

• Zalewanie łącza i warstw niższych — ruch, którego celem jest wyczerpanie przepustowości albo zasobów sieciowych. Tego nie odfiltrujesz w aplikacji, bo serwer nie dożyje momentu, w którym mógłby zdecydować. To zadanie dla dostawcy usługi ochronnej lub operatora.

• Ataki na warstwę aplikacji — pozornie zwykłe żądania HTTP kierowane na kosztowne adresy: wyszukiwarkę wewnętrzną, filtry katalogu, koszyk, generowanie plików. Kilkaset takich zapytań na sekundę wystarcza, żeby położyć sklep, i wyglądają one bardziej jak ruch niż jak atak.

• Skanowanie i zbieranie treści — próby wejścia na adresy paneli i typowe podatności, testowanie haseł, masowe pobieranie asortymentu przez konkurencję. Rzadko wywraca serwis, ale generuje szum w logach i realne ryzyko.

Rozróżnienie ma znaczenie, bo tylko pierwszy przypadek wymaga radykalnych środków. Dwa pozostałe rozwiązuje się precyzyjnie i bez skutków ubocznych dla indeksowania — o ile ktoś w ogóle rozdzieli je w zgłoszeniu.

Jak sprawdzić, że to naprawdę Googlebot

Ten fragment jest fundamentem wszystkiego dalej, a bywa pomijany, bo wydaje się oczywisty.

Nagłówek identyfikujący klienta może zawierać dowolny tekst. Znaczna część ruchu podpisanego jako robot wyszukiwarki nim nie jest — to skanery i scrapery liczące na to, że nazwa da im przepustkę przez zapory. Reguła „przepuszczaj wszystko, co ma w nazwie Googlebot” jest więc regułą otwierającą drzwi.

Weryfikacja odbywa się dwoma sposobami. Pierwszy to odwrotne zapytanie DNS: sprawdzasz nazwę hosta przypisaną do adresu IP i potwierdzasz ją zapytaniem w drugą stronę. Drugi, wygodniejszy w automatyzacji, to porównanie adresu z listami zakresów publikowanymi przez Google w plikach JSON — osobno dla robotów indeksujących, osobno dla robotów specjalnych i osobno dla pobrań uruchamianych działaniem użytkownika. Listy się zmieniają, więc pobieram je regularnie, a nie raz przy wdrożeniu.

Praktyczny wniosek dla konfiguracji: wyjątki buduję na zweryfikowanej tożsamości, nie na nazwie. Jeśli korzystasz z gotowej usługi ochronnej, sprawdź, czy ma mechanizm weryfikowanych botów i czy jest on włączony — zwykle jest to jedno pole, o którym nikt nie pamięta.

Reguły, które najczęściej odcinają wyszukiwarkę

Zebrałem to z konfiguracji, w których musiałem szukać przyczyny spadku indeksowania.

Blokada geograficzna jest najczęstsza i najmniej oczywista. Robot indeksujący pobiera strony przede wszystkim z adresów w Stanach Zjednoczonych, więc sklep sprzedający tylko w Polsce, który „dla bezpieczeństwa” ogranicza ruch do Europy, odcina się od indeksowania w całości. Zdarzyło mi się to zobaczyć kilka razy i za każdym razem autor reguły był absolutnie pewien, że nie ma to nic do rzeczy.

Drugi mechanizm to zagadki i wyzwania wymagające wykonania skryptu w przeglądarce. Robot ich nie rozwiązuje. Zamiast treści dostaje stronę pośrednią, którą w najlepszym razie zignoruje, a w gorszym zaindeksuje jako zawartość podstrony.

Trzeci to zbyt agresywne ograniczanie liczby żądań. Robot potrafi pobierać wiele adresów w krótkim czasie i przy limicie ustawionym pod zachowanie człowieka wpadnie w niego natychmiast. Limity ustawiam dla adresów kosztownych, nie globalnie, i z progiem wyraźnie powyżej naturalnego tempa indeksowania.

Czwarty to wymaganie ciasteczek, nagłówków językowych albo poprawnego adresu strony odsyłającej. Robot ich nie dostarcza i nie ma powodu, żeby to robić.

Jakim kodem odpowiadać przy przeciążeniu

To jedna z niewielu rzeczy w tym temacie, w których dokumentacja Google jest jednoznaczna, a i tak wdrażana jest źle.

Gdy serwer nie wyrabia, właściwą odpowiedzią jest kod 429 albo 503, najlepiej z nagłówkiem wskazującym, po jakim czasie ponowić próbę. Roboty rozumieją to jako sygnał do zwolnienia i faktycznie zwalniają, zwykle bardzo szybko. Adresy pozostają w indeksie, bo błąd jest odczytany jako przejściowy.

Czego unikać. Kod 403 sugeruje, że dostęp jest zabroniony na stałe. Kod 404 mówi, że strony nie ma — i przy dłuższym utrzymaniu tego stanu adresy zaczynają wypadać z indeksu. Najgorsze jest podawanie strony z komunikatem o blokadzie w odpowiedzi z kodem 200, bo wtedy wyszukiwarka dostaje informację, że wszystko jest w porządku, i zapisuje treść komunikatu jako zawartość serwisu.

Ważny warunek czasowy: sygnalizowanie przeciążenia jest bezpieczne, dopóki jest krótkotrwałe. Utrzymywane przez dłuższy czas — mowa o dniach, nie godzinach — prowadzi do usuwania adresów z indeksu. Ochrona włączona w trybie awaryjnym „do wyjaśnienia” i zostawiona na dwa tygodnie to najdroższy sposób poradzenia sobie z atakiem.

Sterowanie tempem pobierania bez blokowania

Bywa, że robot faktycznie obciąża serwis nadmiernie, zwłaszcza przy dużych katalogach z filtrowaniem. Kiedyś dało się to po prostu ograniczyć suwakiem w Search Console — narzędzie zostało wycofane w styczniu 2024 roku i dziś tempo reguluje się inaczej.

Podstawowa metoda jest opisana wyżej: serwer odpowiada wolniej albo zwraca kod przeciążenia, a robot ogranicza tempo samodzielnie. Metoda lepsza polega na tym, żeby nie generować mu zbędnej pracy. W praktyce oznacza to zamknięcie w robots.txt adresów z parametrami sortowania i filtrowania, które produkują nieskończoną liczbę kombinacji, uporządkowanie odnośników wewnętrznych tak, by nie prowadziły do tych kombinacji, i wystawienie sensownej mapy witryny.

Warto też sprawdzić w statystykach indeksowania, co robot pobiera najczęściej. Regularnie okazuje się, że większość jego wysiłku idzie na warianty tej samej listy produktów, a nie na podstrony, o które nam zależy. Wtedy problemem nie jest tempo, tylko struktura adresów — i to ona kosztuje serwer.

Warstwa aplikacji: gdzie realnie leży ryzyko

Ochrona na brzegu sieci nie zwalnia z porządku po stronie serwisu, a ten porządek jest tańszy niż jakakolwiek usługa.

• Buforowanie i odciążenie — strony dostępne bez logowania powinny dawać się serwować z pamięci podręcznej. Serwis, który każde żądanie obsługuje pełnym generowaniem strony, jest podatny na przeciążenie z definicji.

• Kosztowne funkcje pod kontrolą — wyszukiwarka wewnętrzna, porównywanie produktów, generowanie plików. Tu ograniczenie liczby żądań na adres IP jest uzasadnione i nie koliduje z indeksowaniem, bo te ścieżki i tak nie powinny być pobierane przez roboty.

• Panel i formularze logowania — ograniczenie prób, dwuetapowe uwierzytelnianie, blokada po serii nieudanych logowań. Ścieżki administracyjne wykluczam z indeksowania i chronię niezależnie od reszty.

• Aktualizacje i monitoring — większość skanowania szuka znanych, dawno załatanych dziur. Alert na wzrost liczby odpowiedzi z kodami 5xx daje zwykle więcej niż najlepiej dobrany zestaw reguł.

Kolejność jest tu ważna: najpierw serwis, który wytrzymuje normalny ruch, potem ochrona przed nietypowym. Odwrotna kolejność kończy się zaporą tłumiącą objawy problemu wydajnościowego.

Jak sprawdzić, że nic nie zepsułeś

Każdą zmianę w ochronie traktuję jak zmianę mogącą wpłynąć na indeksowanie i weryfikuję ją w ten sam sposób.

Pierwsze źródło to statystyki indeksowania w Search Console. Patrzę na rozkład kodów odpowiedzi w dniach po wdrożeniu: pojawienie się odpowiedzi 403, wzrost udziału 5xx albo nagły spadek liczby żądań to jednoznaczny sygnał. Zestawiam to z dokładną datą włączenia reguł, bo bez tego dyskusja o przyczynie nie ma końca.

Drugie to test pobrania konkretnego adresu na żywo i podejrzenie tego, co robot dostał w odpowiedzi. Jeśli w zwróconym kodzie widać stronę wyzwania albo komunikat zapory, sprawa jest rozstrzygnięta bez dalszej analizy.

Trzecie to logi. Filtruję ruch po zweryfikowanych zakresach adresów wyszukiwarki i sprawdzam, czy nie wpadł w żadną regułę oraz jakie kody dostaje. Jeżeli korzystasz z zewnętrznej usługi ochronnej, ten sam przegląd zrób w jej rejestrze zdarzeń — tam widać wprost, która reguła zadziałała.

I rzecz proceduralna, bez której reszta ma krótki żywot: zapisujcie, kto i kiedy włączył dane ustawienie. W ochronie najwięcej szkody robią zmiany wprowadzone „na chwilę” w nocy podczas incydentu, o których pół roku później nikt już nie pamięta.