Masowe pobieranie katalogu zwykle nie zaczyna się od spektakularnego ataku. Najpierw rośnie liczba wejść na strony kategorii, później jeden klient zaczyna przechodzić przez kolejne rekordy, a na końcu serwer generuje tysiące prawie identycznych odpowiedzi dla adresów, które nie wykonują żadnych normalnych działań użytkownika. Nie klikają telefonu, nie wysyłają formularza i nie wracają do wcześniej oglądanych wpisów. Tylko pobierają.
W katalogach firm szczególnie cenne są nazwy podmiotów, adresy, numery telefonów, opisy działalności, współrzędne, godziny otwarcia i powiązania między kategoriami. Dla operatora modelu AI taki zbiór może być gotowym materiałem do budowy wyszukiwarki, bazy odpowiedzi albo konkurencyjnego katalogu. Dla właściciela serwisu oznacza to koszt transferu, obciążenie bazy, spowolnienie strony oraz utratę kontroli nad dalszym wykorzystaniem danych.
Całkowite zatrzymanie automatycznego pobierania publicznie dostępnych stron nie jest realne. Można jednak sprawić, że hurtowe kopiowanie będzie wolniejsze, droższe, łatwiejsze do wykrycia i mniej opłacalne. Trzeba przy tym chronić katalog tak, aby nie odciąć Googlebota, partnerów korzystających z API ani zwykłych użytkowników przeglądających wiele ofert.
Najpierw rozpoznaj pobieranie, zamiast blokować każdy nietypowy ruch
Sam wysoki ruch nie dowodzi działania bota AI. Użytkownik może otworzyć kilkanaście ofert, porównując restauracje, lekarzy albo wykonawców. Robot indeksujący może natomiast poruszać się powoli i przez kilka godzin nie przekroczyć prostego limitu liczby żądań z jednego adresu IP.
Najbardziej wiarygodny jest zestaw kilku sygnałów:
- przechodzenie kolejno przez identyfikatory wpisów, na przykład
/firma/12001,/firma/12002,/firma/12003; - pobieranie setek stron szczegółowych bez ładowania obrazów, arkuszy CSS i skryptów;
- brak plików cookie albo tworzenie nowej sesji przy każdym żądaniu;
- identyczne odstępy między kolejnymi wejściami, na przykład jedno żądanie co dwie sekundy;
- bardzo duża liczba unikalnych rekordów odwiedzonych podczas jednej sesji;
- brak wejść z wyszukiwarki, stron kategorii i wewnętrznych wyników wyszukiwania;
- częste zmiany adresów IP przy niezmiennym nagłówku
User-Agent; - zapytania o strony sortowane, filtrowane i stronicowane w sposób pozwalający odtworzyć cały katalog.
W praktyce dobrym punktem wyjścia jest analiza logów z 24 godzin, 7 dni i 30 dni. Dłuższy zakres pokazuje roboty rozkładające pobieranie w czasie, natomiast krótszy pozwala wychwycić nagłe skoki.
Dla każdego klienta warto policzyć co najmniej:
- liczbę żądań na minutę i godzinę;
- liczbę unikalnych kart firm;
- stosunek stron HTML do plików statycznych;
- odsetek odpowiedzi z poszczególnych kategorii;
- liczbę użytych adresów IP, sesji i nagłówków
User-Agent; - czas między pierwszym a ostatnim żądaniem;
- udział odpowiedzi pochodzących z pamięci podręcznej i z bazy danych.
Najbardziej użyteczna metryka katalogowa to często nie liczba wszystkich żądań, lecz liczba unikalnych rekordów pobranych przez jednego klienta. Limit 100 żądań na minutę niewiele daje, jeżeli bot pobiera po jednej stronie co pięć sekund przez całą dobę. To nadal 17 280 żądań, czyli potencjalnie znacząca część katalogu.
Nie należy również ufać samej nazwie klienta. Nagłówek User-Agent: Googlebot można wpisać ręcznie. Tożsamość znanych robotów trzeba sprawdzać na podstawie opublikowanych zakresów IP, odwrotnego DNS, podpisów kryptograficznych albo klasyfikacji dostawcy WAF. Fałszywy Googlebot powinien być traktowany jak zwykły, niezaufany automat.
Ochrona musi działać na kilku warstwach
Plik robots.txt jest potrzebny, ale nie stanowi zabezpieczenia dostępu. To instrukcja dla robotów, które dobrowolnie zgadzają się jej przestrzegać. Nieuczciwy scraper może ją zignorować albo przedstawić się jako dozwolony klient.
Można w nim zablokować rozpoznane roboty AI oraz obszary generujące szczególnie dużo wariantów adresów:
User-agent: GPTBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: *
Disallow: /wyszukiwarka?
Disallow: /*?sort=
Disallow: /*?page=Takiej konfiguracji nie wolno kopiować bez sprawdzenia. Zablokowanie wszystkich adresów z parametrem page może odciąć roboty wyszukiwarek od dalszych stron kategorii. Z kolei reguła dla Google-Extended dotyczy kontroli określonych zastosowań treści przez Google, a nie zwykłego indeksowania witryny przez Googlebota. Mieszanie tych dwóch funkcji jest częstym i kosztownym błędem.
Druga warstwa to rate limiting, czyli twardy limit egzekwowany przez serwer, reverse proxy albo CDN. Dla publicznych kart firm rozsądny profil startowy może wyglądać następująco:
- do 30–60 stron szczegółowych na minutę z jednego IP;
- krótki bufor, czyli
burst, na poziomie 10–20 dodatkowych żądań; - maksymalnie 300–600 unikalnych kart na godzinę na sesję;
- ostrzejszy limit dla wyników wyszukiwania, eksportów i kolejnych stron paginacji;
- łagodniejszy limit dla plików statycznych oraz potwierdzonych robotów wyszukiwarek.
Są to wartości początkowe, a nie uniwersalny standard. Katalog dla profesjonalnych analityków będzie miał inny profil niż serwis z wizytówkami lokalnych hydraulików. Przed włączeniem blokowania należy przez kilka dni uruchomić regułę w trybie obserwacji i sprawdzić, ilu prawdziwych użytkowników przekracza wybrany próg.
W NGINX można ograniczyć ruch mechanizmem limit_req, opartym na modelu przypominającym leaky bucket. Sama definicja strefy nie ogranicza jeszcze ruchu; limit trzeba przypisać do konkretnego bloku location.
Przykładowa konfiguracja:
limit_req_zone $binary_remote_addr zone=catalog_per_ip:20m rate=30r/m;
server {
location /firma/ {
limit_req zone=catalog_per_ip burst=15 nodelay;
limit_req_status 429;
proxy_pass http://catalog_backend;
}
}Taki zapis dopuszcza średnio 30 żądań na minutę z jednego adresu IP i pozwala na krótkie przekroczenie limitu w ramach bufora. Po jego wykorzystaniu serwer zwraca kod 429 Too Many Requests.
Problem zaczyna się wtedy, gdy cały ruch przechodzi przez CDN lub load balancer. Jeżeli serwer widzi wyłącznie adres pośrednika, limit zostanie nałożony na wszystkich odwiedzających jednocześnie. Przed wdrożeniem trzeba więc poprawnie skonfigurować odczytywanie rzeczywistego IP klienta, a nagłówki takie jak X-Forwarded-For przyjmować wyłącznie od zaufanego proxy. Nagłówek przesłany bezpośrednio przez użytkownika można podrobić.
Trzecia warstwa to WAF i klasyfikacja botów. Reguła może uwzględniać jednocześnie ścieżkę URL, wynik wykrywania automatyzacji, kraj, ASN, reputację adresu IP, częstotliwość żądań i obecność prawidłowej sesji. To znacznie bezpieczniejsze niż blokowanie całych państw albo wszystkich centrów danych.
Działania powinny być stopniowane:
- pierwszy próg — zapis zdarzenia i oznaczenie sesji;
- drugi próg — spowolnienie lub zarządzane wyzwanie;
- trzeci próg — odpowiedź 429 przez 10–60 minut;
- powtarzające się naruszenia — czasowa blokada adresu IP, zakresu albo fingerprintu;
- stałe pobieranie rozproszone — wymóg logowania lub tokenu dostępu.
Nie każdy bot wykona JavaScript, ale stawianie wyzwania JavaScript na każdej karcie firmy ma wyraźne minusy. Pogarsza czas ładowania, może irytować użytkowników korzystających z VPN i potrafi utrudnić działanie narzędzi dostępności. Lepiej uruchamiać je dopiero po przekroczeniu progu ryzyka.
Ogranicz wartość hurtowego eksportu, nie użyteczność pojedynczej wizytówki
Najskuteczniejsza ochrona katalogu nie polega na ukrywaniu wszystkich danych. Polega na rozdzieleniu normalnego użycia od odtwarzania całego zbioru.
Na publicznej karcie firmy można nadal pokazywać nazwę, kategorię, adres i podstawowe dane kontaktowe. Nie ma jednak powodu, aby anonimowy użytkownik mógł w kilka minut przejść przez dziesiątki tysięcy rekordów, pobrać pełną historię zmian albo wywołać prywatne endpointy używane przez panel administracyjny.
W pierwszej kolejności należy ograniczyć:
- endpointy zwracające całe obiekty JSON;
- nieudokumentowane API używane przez frontend;
- eksporty CSV, XLSX i XML;
- mapy witryny zawierające wszystkie warianty filtrów;
- strony pozwalające ustawić bardzo wysoki parametr
limit; - filtrowanie po identyfikatorach i pobieranie kolejnych rekordów bez normalnej nawigacji;
- GraphQL bez ograniczenia złożoności i głębokości zapytań.
Parametr limit=100000 nie powinien być przyjmowany tylko dlatego, że aplikacja technicznie potrafi go obsłużyć. Dla anonimowych klientów warto ustawić twarde maksimum, na przykład 20–50 rekordów na odpowiedź. Wyższe limity mogą być dostępne po zalogowaniu, w płatnym API albo dla zatwierdzonych partnerów.
W API należy stosować kilka niezależnych ograniczeń:
- limit żądań przypisany do klucza API, a nie tylko do adresu IP;
- dzienny limit pobranych rekordów;
- maksymalną wielkość strony wyników;
- limit równoległych połączeń;
- podpisywane tokeny z datą wygaśnięcia;
- osobne uprawnienia do odczytu danych publicznych i rozszerzonych;
- rejestrowanie identyfikatora klienta przy każdym eksporcie.
Dla małego partnera pobierającego aktualizacje wystarczy często limit rzędu 1–5 żądań na sekundę i kilka tysięcy rekordów dziennie. Dostęp do pełnego eksportu powinien wymagać osobnej zgody, harmonogramu oraz warunków określających dalsze wykorzystanie danych. Gdy partner potrzebuje regularnej synchronizacji, lepiej udostępnić mu paczkę zmian raz na dobę niż pozwalać ponownie skanować cały katalog.
Istotne jest również ograniczenie duplikatów URL. Jeden rekord dostępny pod dziesięcioma adresami zwiększa powierzchnię indeksowania i ułatwia botowi obchodzenie limitów opartych na ścieżkach. Parametry sortowania, identyfikatory sesji, wersje drukowane i niepotrzebne kombinacje filtrów należy usuwać, przekierowywać albo oznaczać adresem kanonicznym.
Cache zmniejsza koszt obsługi scraperskiego ruchu, ale nie rozwiązuje problemu kopiowania danych. CDN może ochronić bazę przed przeciążeniem, jednocześnie umożliwiając botowi znacznie szybsze pobieranie odpowiedzi z węzłów brzegowych. Dlatego pamięć podręczna musi działać razem z ograniczeniami liczby żądań i unikalnych rekordów.
Nie warto też liczyć na proste zaciemnianie numerów telefonu w kodzie JavaScript. Podnosi ono koszt najprostszych scraperów, lecz narzędzia korzystające z przeglądarki bez interfejsu potrafią wykonać skrypt i odczytać wynik. Podobnie działa dzielenie adresu e-mail na kilka elementów HTML. To przeszkoda, nie zabezpieczenie.
Najtrudniejsze do zatrzymania jest pobieranie rozproszone przez tysiące adresów IP. W takiej sytuacji limit per IP przestaje wystarczać. Potrzebna jest korelacja sesji, fingerprintu TLS i przeglądarki, wzorca poruszania się po rekordach, nagłówków, ASN oraz liczby unikalnych kart. Nie wolno jednak automatycznie blokować całych sieci operatorów komórkowych. Jeden adres NAT może reprezentować wielu rzeczywistych użytkowników.
Od strony prawnej regulamin serwisu powinien jasno określać zasady automatycznego pobierania, ponownego wykorzystywania i eksportowania danych. Sam zapis w regulaminie nie zatrzyma robota, ale ułatwia egzekwowanie warunków wobec zidentyfikowanego podmiotu. Trzeba też oddzielić dane własne serwisu od informacji pochodzących z publicznych rejestrów. Fakt, że pojedyncza informacja jest publiczna, nie oznacza automatycznie, że całą przygotowaną bazę można kopiować bez ograniczeń. Ocena zależy między innymi od źródła danych, sposobu ich opracowania, skali pobrania i ponownego wykorzystania.
FAQ
Czy wpis w robots.txt wystarczy do zablokowania botów AI?
Nie. robots.txt jest deklaracją zasad, a nie kontrolą dostępu. Uczciwy robot może ją respektować, lecz scraper może ją zignorować. Zakaz trzeba egzekwować przez WAF, rate limiting, autoryzację albo ograniczenia aplikacyjne.
Jaki kod HTTP zwracać po przekroczeniu limitu?
Najczęściej 429 Too Many Requests. Można dodać nagłówek Retry-After, wskazujący, po ilu sekundach klient powinien ponowić próbę. Kod 403 lepiej zostawić dla ruchu, któremu dostęp został świadomie zabroniony, a 401 dla zasobów wymagających uwierzytelnienia.
Czy należy blokować wszystkie adresy IP centrów danych?
Nie. Z takich sieci korzystają również systemy monitoringu, integracje, partnerzy, narzędzia SEO i legalne roboty. Blokada całego ASN ma sens dopiero wtedy, gdy analiza logów potwierdza trwałe nadużycie i nie ma w nim potrzebnego ruchu.
Czy CAPTCHA zatrzyma masowe pobieranie?
Zatrzyma część prostych narzędzi, ale nie daje gwarancji. Rozwiązywanie CAPTCHA można automatyzować albo zlecać zewnętrznym usługom. CAPTCHA powinna być reakcją na podwyższone ryzyko, a nie obowiązkową bramką przed każdą wizytówką.
Czy ukrycie danych w JavaScript wystarczy?
Nie. Bot oparty na Playwright, Puppeteerze lub innej przeglądarce automatycznej wykona JavaScript podobnie jak zwykły użytkownik. Takie ukrywanie ma sens tylko jako dodatkowe utrudnienie dla najprostszych skryptów.
Jak nie zablokować Googlebota?
Nie opieraj wyjątku wyłącznie na nazwie User-Agent. Potwierdź tożsamość robota, wyłącz go z reguł przeznaczonych dla scraperów i obserwuj błędy indeksowania. Zbyt agresywne ograniczenie może opóźnić wykrywanie nowych wpisów, aktualizację cen i usuwanie nieaktualnych stron z wyników.
Od czego zacząć ochronę istniejącego katalogu?
Najpierw sprawdź logi i policz liczbę unikalnych kart pobieranych przez jedną sesję, IP oraz ASN. Następnie usuń najbardziej niebezpieczny błąd: publiczny endpoint lub parametr pozwalający pobrać setki albo tysiące rekordów jednym żądaniem. Dopiero później ustaw testowy limit 30–60 kart na minutę, uruchom go w trybie obserwacji i porównaj wyniki z ruchem prawdziwych użytkowników. Blokowanie wszystkich botów bez takiego pomiaru jest szybsze, ale zwykle kończy się problemami z indeksowaniem i fałszywymi alarmami.
Więcej informacji na: wizytówki NAP – aiqo.pl.
