Jak ograniczać pobieranie katalogu bez blokowania robotów wyszukiwarek

Masowe pobieranie katalogu zwykle zaczyna się niewinnie: jeden adres IP otwiera kolejne strony kategorii, produktów albo firm. Po kilku minutach liczba żądań rośnie do setek na minutę, baza danych zaczyna odpowiadać wolniej, a prawdziwi użytkownicy czekają na wygenerowanie strony. Najprostsza reakcja — blokada wszystkich botów — usuwa obciążenie, ale może jednocześnie odciąć Googlebota, Bingbota i inne roboty potrzebne do indeksowania serwisu.

Problem trzeba więc rozdzielić na dwie części. Pierwsza to ograniczenie zbędnych adresów URL, które roboty mogą odkrywać. Druga to kontrola częstotliwości żądań na poziomie serwera, CDN lub zapory aplikacyjnej. Sam plik robots.txt nie zatrzyma agresywnego scrapera, który ignoruje standard Robots Exclusion Protocol. Z kolei źle ustawiony rate limiting potrafi potraktować wyszukiwarkę jak atak i regularnie zwracać jej błędy 429 Too Many Requests.

Najpierw ustal, kto naprawdę pobiera katalog

Nagłówek User-Agent nie jest dowodem tożsamości robota. Skrypt napisany w Pythonie może przedstawić się jako Googlebot, Bingbot albo zwykła przeglądarka Chrome. Reguła typu „jeżeli User-Agent zawiera Googlebot, pomiń zabezpieczenia” tworzy więc prostą furtkę dla każdego, kto potrafi zmienić jeden nagłówek HTTP.

Ruch należy analizować na podstawie co najmniej czterech danych:

• adresu IP i autonomicznego systemu sieciowego, z którego pochodzi żądanie;
• ścieżki i parametrów URL, na przykład /katalog?page=181 albo /firmy?miasto=krakow&sort=nazwa;
• częstotliwości żądań w oknie 10, 60 lub 300 sekund;
• zachowania sesji, w tym kolejności otwieranych podstron, obsługi plików cookie i pobierania zasobów CSS oraz JavaScript.

Prawdziwego Googlebota trzeba zweryfikować przez opublikowane zakresy adresów IP Google albo procedurę opartą na odwrotnym i ponownym zapytaniu DNS. Analogicznie należy postępować z Bingbotem. Samo sprawdzenie nazwy hosta nie wystarczy: wynik odwrotnego DNS powinien zostać ponownie rozwiązany do tego samego adresu IP.

W praktyce warto podzielić automatyczny ruch na trzy grupy:

1. Zweryfikowane roboty wyszukiwarek — otrzymują dostęp do publicznych stron, ale nadal podlegają ochronie serwera przed przeciążeniem.
2. Znane roboty komercyjne — mogą zostać dopuszczone, ograniczone albo zablokowane zależnie od celu serwisu.
3. Niezidentyfikowane skrypty i scrapery — powinny trafiać pod rate limiting, challenge lub blokadę.

Pierwszym sygnałem problemu nie powinna być sama liczba odsłon. Robot odwiedzający 20 stron na sekundę może pobierać lekkie dokumenty z pamięci podręcznej i nie powodować szkody. Inny wykonujący dwa żądania na sekundę może uruchamiać kosztowne zapytania SQL, generowanie mapy albo filtrowanie katalogu po kilku polach. Dlatego limit trzeba wiązać nie tylko z adresem IP, ale również z kosztem konkretnego endpointu.

Dobry punkt startowy dla publicznego katalogu to obserwacja, a nie natychmiastowa blokada. Przez 7–14 dni warto zapisywać liczbę żądań na IP, kod odpowiedzi, czas generowania strony, User-Agent, referrer oraz wykorzystanie procesora i bazy danych. Dopiero z tych danych można wyznaczyć próg, który odróżnia normalne indeksowanie od pobierania całej bazy.

Ogranicz przestrzeń adresów URL, zanim zaczniesz ograniczać roboty

Największe obciążenie katalogów często nie wynika z liczby rekordów, lecz z liczby możliwych kombinacji filtrów. Katalog mający 30 tys. wpisów może wygenerować kilka milionów adresów, gdy pozwala łączyć województwo, miasto, branżę, ocenę, zakres cen, dostępność, sortowanie i numer strony.

Przykładowo jedna lista może występować pod adresami:

• /firmy/warszawa/hydraulicy;
• /firmy?miasto=warszawa&branza=hydraulicy;
• /firmy?branza=hydraulicy&miasto=warszawa;
• /firmy/warszawa/hydraulicy?sort=ocena;
• /firmy/warszawa/hydraulicy?page=1;
• /firmy/warszawa/hydraulicy?utm_source=partner.

Dla użytkownika różnice bywają niewielkie. Dla crawlera są to osobne adresy, które trzeba odkryć, pobrać, przetworzyć i porównać.

Najwyższy priorytet ma usunięcie nieskończonych lub prawie nieskończonych przestrzeni URL. Dotyczy to zwłaszcza kalendarzy bez ograniczenia daty, filtrów możliwych do łączenia w dowolnej kolejności, identyfikatorów sesji w adresie oraz sortowania generującego indeksowalne kopie tej samej listy.

Należy przyjąć jasną politykę:

• indeksowalne są tylko kombinacje filtrów, które mają samodzielną wartość wyszukiwawczą;
• kolejność parametrów jest zawsze taka sama;
• parametry śledzące nie zmieniają adresu kanonicznego;
• pierwsza strona paginacji nie występuje równocześnie jako adres bez parametru i jako ?page=1;
• puste wyniki zwracają prawidłowy kod 404 albo pozostają dostępne z dyrektywą noindex, zależnie od przyjętej architektury;
• linki do niepotrzebnych wariantów nie są generowane w nawigacji.

robots.txt nadaje się do blokowania obszarów, których robot nie powinien pobierać, na przykład wewnętrznej wyszukiwarki, kombinacji sortowania albo technicznych parametrów. Nie powinien jednak zastępować porządnej architektury URL.

Trzeba też rozróżnić blokowanie pobierania od blokowania indeksowania. Jeżeli adres zostanie zablokowany w robots.txt, robot nie pobierze strony i może nie zobaczyć umieszczonej na niej dyrektywy noindex. Adres nadal może pojawić się w wynikach jako URL bez opisu, jeżeli prowadzą do niego zewnętrzne linki. Gdy celem jest usunięcie strony z indeksu, należy najpierw pozwolić robotowi ją pobrać i zwrócić noindex, kod 404 lub 410. Dopiero po usunięciu adresu z indeksu można rozważyć ograniczenie dalszego crawlowania.

W katalogach szczególnie źle działa blokowanie całej paginacji, na przykład:

User-agent: *
Disallow: /*?page=

Taka reguła może odciąć robotom drogę do wpisów dostępnych dopiero na dalszych stronach. Bezpieczniej zapewnić zwykłe linki HTML między stronami paginacji, ustawić stabilne adresy i ograniczyć indeksowanie tylko tych wariantów, które rzeczywiście się powielają.

Nie należy też liczyć na crawl-delay jako uniwersalny mechanizm. Dyrektywa nie jest jednakowo obsługiwana przez wszystkie wyszukiwarki. Bing udostępnia dodatkowo godzinową kontrolę szybkości crawlowania w Bing Webmaster Tools, natomiast w przypadku Google tempo pobierania jest dobierane automatycznie na podstawie odpowiedzi serwera i zapotrzebowania na indeksowanie.

Rate limiting, cache i WAF bez odcinania wyszukiwarek

Ograniczanie ruchu powinno działać warstwowo. Najpierw należy zmniejszyć koszt prawidłowego żądania, później spowolnić ruch podejrzany, a dopiero na końcu go blokować.

Pierwsza warstwa to pamięć podręczna. Strony kategorii, miast i profili firm często nie muszą być generowane od nowa przy każdej odsłonie. Jeżeli dane zmieniają się kilka razy dziennie, czas cache na poziomie 5–30 minut zwykle ogranicza obciążenie bazy bez zauważalnego pogorszenia aktualności. Popularne strony można przechowywać dłużej, a cache unieważniać po zmianie rekordu.

Dobrą praktyką jest osobne traktowanie:

• dokumentów HTML;
• zdjęć i plików statycznych;
• zapytań wyszukiwarki wewnętrznej;
• eksportów CSV, PDF i XML;
• endpointów API;
• stron z filtrami wymagającymi kosztownych zapytań do bazy.

Limit 60 żądań na minutę zastosowany jednakowo do całej domeny jest zbyt prymitywny. Jedno wejście na stronę może wywołać kilkanaście żądań po obrazy, skrypty i arkusze stylów. Zamiast tego można rozpocząć od progów obserwacyjnych, na przykład:

• 30–60 żądań HTML na minutę na IP dla stron katalogowych;
• 10–20 żądań na minutę dla kosztownej wyszukiwarki lub wielopolowego filtrowania;
• 3–5 eksportów danych w ciągu godziny na konto albo adres IP;
• wyższe limity dla plików statycznych obsługiwanych z CDN.

Nie są to wartości uniwersalne. Serwis mający 500 tys. podstron i szybki cache może obsłużyć intensywniejsze indeksowanie niż katalog działający na współdzielonym hostingu. Próg powinien zostać skorygowany po analizie logów, czasu odpowiedzi p95 i liczby błędów serwera.

Najbezpieczniejsza reakcja na przekroczenie limitu wygląda stopniowo:

1. zapisanie zdarzenia bez ingerencji;
2. opóźnienie lub kontrolowane zwrócenie kodu 429;
3. challenge dla niezidentyfikowanego klienta;
4. czasowa blokada na 10–60 minut;
5. dłuższa blokada dopiero przy powtarzalnym nadużyciu.

Zweryfikowane roboty wyszukiwarek należy wyłączyć z reguł przeznaczonych dla złych botów, ale nie wolno robić tego wyłącznie na podstawie User-Agenta. Cloudflare pozwala budować warunki wykorzystujące klasyfikację zweryfikowanych botów. W rozwiązaniu własnym trzeba utrzymywać listy zakresów IP wyszukiwarek i regularnie je aktualizować.

Wyjątek dla wyszukiwarek nie oznacza zgody na przeciążenie infrastruktury. Jeżeli serwer nie nadąża, powinien zwracać 429 lub 503 z nagłówkiem Retry-After, zamiast generować puste dokumenty z kodem 200. Fałszywa odpowiedź 200 OK utrudnia wykrycie awarii i może prowadzić do indeksowania niepełnych stron.

Trzeba uważać również na challenge oparty na JavaScript. Włączenie go dla całej sekcji /katalog/ może utrudnić pobieranie stron przez roboty, narzędzia audytowe, czytniki dostępności i użytkowników z restrykcyjnymi ustawieniami przeglądarki. Challenge należy stosować do ruchu niezidentyfikowanego, który przekracza próg albo wykazuje charakterystyczny wzorzec scrapowania, a nie do każdego wejścia bez pliku cookie.

Dodatkową ochronę daje ograniczenie ilości danych przekazywanych z pojedynczego endpointu. Publiczne API nie powinno zwracać całego katalogu w jednym zapytaniu. Rozsądne maksimum to zazwyczaj 50–100 rekordów na stronę, twardy limit głębokości paginacji oraz token dostępu dla operacji masowych. Eksport pełnej bazy warto przenieść za logowanie, ustalić limity konta i generować plik asynchronicznie po stronie systemu.

W katalogach lokalnych dochodzi jeszcze kwestia spójności nazw firm, adresów i telefonów. Duplikaty rekordów zwiększają liczbę podstron, komplikują adresy kanoniczne i powodują, że robot wielokrotnie pobiera niemal identyczne profile. Najpierw należy łączyć wpisy reprezentujące ten sam podmiot, a dopiero później walczyć z ruchem za pomocą coraz ostrzejszych limitów.

FAQ

Czy zablokowanie katalogu w robots.txt ochroni go przed skopiowaniem?
Nie. Reguły robots.txt respektują prawidłowo działające roboty, ale agresywny scraper może je całkowicie zignorować. Do ochrony przed masowym pobieraniem potrzebne są limity, analiza zachowania, cache, WAF oraz kontrola dostępu do eksportów i API.

Czy można ustawić osobny limit dla Googlebota?
Technicznie tak, ale najpierw trzeba zweryfikować jego adres IP. W większości przypadków lepiej wykluczyć potwierdzone roboty wyszukiwarek z typowych reguł antybotowych, a przeciążenie sygnalizować prawidłowymi kodami 429 lub 503.

Czy kod 429 zaszkodzi pozycjom strony?
Pojedyncze, krótkotrwałe odpowiedzi 429 nie są równoznaczne z usunięciem strony z wyników. Problem zaczyna się wtedy, gdy robot przez wiele godzin lub dni nie może pobrać dużej części serwisu. Limit trzeba więc ustawić tak, aby chronił infrastrukturę, lecz nie blokował regularnego odświeżania ważnych podstron.

Czy noindex zmniejsza liczbę żądań robota?
Nie od razu. Robot musi pobrać stronę, aby zobaczyć dyrektywę noindex, a później może okresowo wracać i sprawdzać, czy nadal obowiązuje. Do ograniczania crawlowania służą przede wszystkim architektura linkowania, eliminacja zbędnych URL-i, robots.txt i prawidłowe kody odpowiedzi.

Co sprawdzić jako pierwsze po wykryciu masowego pobierania?
Najpierw przeanalizuj logi i ustal, czy obciążenie powoduje prawdziwa wyszukiwarka, scraper podszywający się pod robota czy niekontrolowana liczba adresów z filtrami. Pierwszym błędem do usunięcia jest globalna blokada oparta wyłącznie na nazwie User-Agenta. Następnie ogranicz generowanie zbędnych URL-i, włącz cache dla publicznych list i dopiero na tej podstawie ustaw osobne limity dla kosztownych endpointów.

Więcej informacji na: wizytówki NAP – aiqo.pl