Blokowanie botów w .htaccess: Ochrona serwera, SEO i crawl budget

W tym artykule znajdziesz konkretne reguły .htaccess do blokowania agresywnych botów AI (GPTBot, Bytespider, ClaudeBot) oraz scraperów SEO (Ahrefs, Semrush). Pokazuję, jak odzyskać kontrolę nad Crawl Budget, obniżyć TTFB i chronić wskaźniki Core Web Vitals – bez ryzyka utraty pozycji w Google.

Diagnoza z terminala

root@prod-01: ~/artykul_boty_v2.md

$ git commit -am "Fix: Usunięcie kotwicy UA, optymalizacja pod LiteSpeed, segmentacja botów AI pod kątem SEO"

Trafienie w dziesiątkę. Usunięcie kotwicy ^ w %{HTTP_USER_AGENT} to kluczowy ruch. Boty takie jak SemrushBot maskują się za pełnymi ciągami typu Mozilla/5.0 (compatible; SemrushBot/7...) — bez tej poprawki reguła przepuściłaby połowę szkodliwego ruchu. Poprawka wdrożona do mastera.

Architektura Odporności: Dlaczego boty to cichy zabójca Twojego SEO

W świecie e-commerce trwa niewidzialna wojna. Ponad 40% ruchu w sieci to nie są Twoi klienci. To boty. Od oficjalnych crawlerów wyszukiwarek, przez agresywne skrobaki AI kradnące content bez podawania źródła, aż po złośliwe skanery podatności szukające dziur w kodzie.

Gdy na stronę wchodzi armia nieproszonych botów, wykresy w Grafanie lecą w kosmos. Efekt? Procesor dobija do 100%, baza danych MariaDB/PostgreSQL puchnie od zapytań, a czas odpowiedzi serwera (TTFB) drastycznie rośnie.

Dla biznesu i SEO to katastrofa o potrójnym skutku:

• Destrukcja Core Web Vitals: Wysoki TTFB i przeciążony serwer bezpośrednio degradują wskaźnik INP (Interaction to Next Paint). Klient klika „Dodaj do koszyka”, widzi kręcące się kółko z powodu laga serwera i opuszcza sklep.
• Drenaż Crawl Budget: Googlebot ma ograniczony czas na indeksowanie Twojej witryny. Jeśli musi dzielić zasoby serwera z agresywnym botem AI, który akurat wysysa bazę produktów, Googlebot odbije się od ściany (napotka błędy 503 lub timeouty). Nowe produkty nie wchodzą do indeksu tygodniami.
• Wypalanie budżetu marketingowego: Płacisz za mocniejszy serwer, transfer i utrzymanie infrastruktury, która zamiast generować konwersje, obsługuje puste zapytania farm botów.

Zasada jest jedna: zero partyzantki. Boty trzeba ciąć skutecznie, chirurgicznie i na odpowiednim poziomie infrastruktury.

1. Strategia Obronna: Trzy linie oporu (WAF vs Serwer vs robots.txt)

Nie każdy mechanizm blokowania nadaje się do każdego zagrożenia. Jeśli próbujesz zatrzymać rozproszony atak scrapingowy plikiem robots.txt, to tak, jakbyś postawił papierowy znak „Zakaz wstępu” przed rozpędzonym czołgiem. Złośliwe boty po prostu go ignorują.

Poziom ochrony	Mechanizm / Warstwa	Typ bota	Efekt dla SEO i Biznesu	Główna zaleta	Ryzyko / Wąskie gardło
Linia 1: Brzeg sieci	Cloudflare / WAF (Layer 7)	Ataki DDoS, Distributed Scraping, agresywne AI crawly	Pełna ochrona Core Web Vitals. Ruch nie dociera do VPS/Dedyka. Load serwera: 0%.	Oszczędność zasobów, ochrona TTFB przed skokami.	Koszt zaawansowanych reguł Enterprise.
Linia 2: Serwer WWW	.htaccess / Nginx / LiteSpeed	Natrętne crawlery SEO (Ahrefs, Semrush), puste User-Agent	Odzyskiwanie Crawl Budget. Szybkie odcięcie na poziomie backendu (Błąd 403 / 444).	Błyskawiczna reakcja bez zmian w DNS.	Przy tysiącach reguł w czystym Apache plik obciąża CPU.
Linia 3: Konwencja	robots.txt	Grzeczne boty (Googlebot, Bingbot)	Zarządzanie indeksacją. Wskazywanie tras dla robotów wyszukiwarek.	Standard rynkowy, zerowe obciążenie.	Całkowicie ignorowany przez złośliwy ruch.

2. Hardening Serwera: Szybkie ściągi kodu (.htaccess)

Przejdźmy do wdrożenia. Poniższe reguły implementujesz bezpośrednio w pliku .htaccess Twojej aplikacji (np. PrestaShop, WordPress czy dedykowany e-commerce). Do poprawnego działania wymagany jest aktywny moduł Apache mod_rewrite.

Krok 1: Blokowanie botów AI i agresywnych scraperów (Bez fałszywych kotwic)

Skanery SEO oraz boty LLM potrafią wygenerować tysiące zapytań na minutę, paraliżując serwer. W poniższej regule celowo usunięto kotwicę ^, ponieważ boty wysyłają pełne ciągi User-Agent. Flaga [NC] zapewnia ignorowanie wielkości liter, a [F,L] natychmiast zwraca błąd 403 Forbidden.

Apache

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|ClaudeBot|Anthropic-AI|PerplexityBot|ImagesiftBot|Omgilibot|Bytespider|SemrushBot|AhrefsBot|DotBot) [NC]
RewriteRule .* - [F,L]

💡 Rozróżnienie biznesowo-SEO botów:

• Bytespider – Crawler TikToka (ByteDance). Wyjątkowo agresywny. Jeśli nie prowadzisz intensywnych działań social-commerce bezpośrednio na tym kanale, jego zablokowanie natychmiast odciąży serwer.
• SemrushBot / AhrefsBot – Jeśli sami nie korzystacie z tych narzędzi do audytu i monitoringu konkurencji, zablokowanie ich zwalnia gigantyczne zasoby serwera dla Googlebota.
• ChatGPT-User – Celowo pominięty na powyższej czarnej liście. To nie jest crawler masowy, lecz bot działający na bezpośrednie zapytanie użytkownika w czasie rzeczywistym (np. gdy ktoś prosi ChatGPT o przeanalizowanie produktu z Twojego sklepu). Zablokowanie go odetnie Cię od nowoczesnych kanałów wyszukiwania AI.

Krok 2: Eliminacja fałszywego ruchu (Pusty lub myślnikowy User-Agent / Referer)

Profesjonalne boty i prawdziwe przeglądarki zawsze identyfikują się nagłówkiem. Skrypty pisane na kolanie do kradzieży contentu często czyszczą nagłówek User-Agent lub ukrywają Referera.

Uwaga: Stosujemy flagę [OR]. Ruch zostanie zablokowany, jeśli spełni choć JEDEN z tych warunków. Jeśli Twój system przyjmuje zewnętrzne webhooki lub zapytania API bez nagłówka Referer, bezpieczniej jest usunąć drugą linijkę kodu.

Apache

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^-?$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^-?$ [NC]
RewriteRule .* - [F,L]

Krok 3: Banowanie agresywnych adresów IP (Chirurgiczne cięcie)

Gdy analiza logów wykaże, że konkretna podsieć wykonuje złośliwy brute-force na wrażliwe endpointy (np. /wp-admin, /checkout, czy wewnętrzną wyszukiwarkę sklepu), stosujemy twardy ban w składni Apache 2.4.

Apache

<RequireAll>
    Require all granted
    Require not ip 192.0.2.1
    Require not ip 2001:db8::1
    Require not ip 198.51.100.0/24
</RequireAll>

(Uwaga: Powyższe adresy to zakresy dokumentacyjne – przed wdrożeniem zastąp je realnymi IP wyciągniętymi z logów serwera).

3. Architektura i wydajność: Apache vs LiteSpeed pod kątem SEO

Blokowanie w .htaccess działa świetnie, ale musisz znać architekturę swojego serwera WWW, aby walka z botami nie pogorszyła wskaźników Core Web Vitals.

• Tradycyjny Apache: Przy każdym zapytaniu (nawet o statyczny obrazek .webp czy plik .css) serwer musi fizycznie odczytać plik .htaccess z dysku i przetworzyć każdą regułę Regex od góry do dołu. Jeśli wrzucisz tam listę setek złośliwych IP lub botów, procesor zacznie marnować zasoby na samą analizę tekstu. TTFB wzrośnie, co negatywnie wpłynie na pozycjonowanie.
• Nowoczesny LiteSpeed: Jeśli Twój stack technologiczny stoi na LiteSpeed, wydajność reguł .htaccess jest nieporównywalnie wyższa. Serwer kompiluje plik konfiguracyjny bezpośrednio do pamięci RAM przy jego zmianie. Narzut na procesor przy parsowaniu Regexów jest zminimalizowany. Pozwala to na stosowanie zaawansowanych blokad bez obawy o spadek szybkości ładowania strony.

Co robić, gdy atak idzie w dziesiątki tysięcy zapytań?

Gdy mamy do czynienia z Distributed Scraping (setki rotujących adresów IP), same reguły serwerowe to za mało. Należy przenieść blokowanie wyżej:

1. Firewall systemowy (iptables / ufw): Blokowanie na poziomie pakietów sieciowych (Layer 4) przetwarza ruch bez angażowania serwera WWW.
2. Cloudflare (Edge Filtering): Ruch odcinany jest na najbliższym serwerze brzegowym (Edge Node) globalnej sieci, zanim w ogóle dotrze i obciąży Twoją infrastrukturę.

4. Zarządzanie ryzykiem: Bezpieczeństwo SEO to podstawa

Optymalizacja infrastruktury to czysty biznes, ale wymaga chirurgicznej precyzji. Jedna pomyłka może kosztować utratę widoczności budowanej latami.

• Absolutna ochrona robotów wyszukiwarek: Filtrując ruch, musisz zachować stuprocentową pewność, że nie blokujesz Googlebota ani Bingbota. Sfałszowanie User-Agenta „Googlebot” przez złośliwego bota to powszechna praktyka. Nigdy nie blokuj Googlebota wyłącznie po nazwie. W przypadku wykrycia podejrzanego ruchu, który przedstawia się jako wyszukiwarka, zawsze zweryfikuj nagłówki poprzez Reverse DNS. Instrukcję krok po kroku znajdziesz w oficjalnym przewodniku Google: Jak zweryfikować Googlebota.
• Procedury i poufność: Każde wdrożenie na produkcji musi przejść przez środowisko stagingowe i testy składniowe (apachectl configtest). Dostęp do infrastruktury powinien odbywać się wyłącznie przez bezpieczne menedżery haseł (1Password/Bitwarden) pod osłoną restrykcyjnych umów NDA.

Inżynieria systemowa w e-commerce to rzemiosło, którego celem jest stabilność, szybkość i nieprzerwany proces zakupowy. Serwery mają być niezawodne, a roboty Google mają mieć czystą, szybką drogę do indeksowania Twoich produktów.

Audyt Twoich logów serwera

Chcesz sprawdzić, które boty aktualnie drenują Twój transfer, marnują Crawl Budget i sztucznie podbijają TTFB? Jeśli posiadasz już nasz dedykowany skrypt do analizy ruchu, porównaj wyniki. Jeśli nie, wklej fragment swoich logów serwera (Access Log) w komentarzu lub opisz, z jakim konkretnie crawlerem masz teraz problem, a zoptymalizujemy reguły bezpośrednio pod Twój stack technologiczny.