Uptime: 99.892%
Strony WWW:
Nowe strony WWW dzisiaj:
W SEOHOST Użytkownik jest zawsze na pierwszym miejscu! Czytaj więcej Z SEOHOST korzysta już ponad 90 000 Użytkowników! Czytaj więcej Jak Polacy marnują 164 miliony rocznie! Czytaj więcej Pierwszy taki film na YouTube od SEOHOST! Czytaj więcej Pełna transparencja: uptime naszej infrastruktury Czytaj więcej Wywiad z naszym CEO na bezprawnik.pl Czytaj więcej SEOHOST.pl zdobywa 2 miejsce w rankingu NASK. Czytaj więcej Uwaga: kolejna próba phishingu! Czytaj więcej Dlaczego warto migrować do SEOHOST? Czytaj więcej
Redakcja SEOHOST.pl
Redakcja SEOHOST.pl
29 Maja 2020
6 minut

Blokady robotów w pliku .htaccess

Na naszym hostingu SEO są domyślnie blokowane roboty analizujące zaplecze: Majestic SEO, ahrefs, SeoMoz itp. Możesz jednak chcieć zablokować inne boty lub posiadasz inny rodzaj hostingu i chcesz dokonać blokady. Poniższy poradnik pokaże Ci jak to zrobić.

Wszystkie poniższe reguły blokowania należy dodać w pliku .htaccess w katalogu public_html dla danej domeny.

Blokada botów poprzez SetEnvIfNoCase oraz SetEnvIf

Na naszych serwerach hostingowych zainstalowany jest LiteSpeed. Aby zablokować boty, należy użyć wpisu do pliku .htaccess:

RewriteCond %{HTTP_USER_AGENT} ^(nazwa_bota|nazwa_innego_bota) [NC]
RewriteRule .* - [F]

Fragmenty wpisów "nazwa_bota" lub "nazwa_innego_bota" należy zamienić na faktyczne nazwy botów, lub fragmenty tych nazw.

Korzystają z takiego zapisu, przy połączeniu serwer sprawdzi zawartość nagłówka User-Agent, jeśli jakiś jego fragment pasuje do ciągu znaków spisanych w powyższych formułach, do serwera odpytującego zostanie zwrócony błąd 403.

Powyższy zapis może być oczywiście dłuższy (posiadać więcej wierszy) lub więcej nazw botów w nawiasach, w zależności do potrzeb.

SetEnvIfNoCase User-Agent "BadBot|EvilScraper" bad_bot
<RequireAll>
    Require all granted
    Require not env bad_bot
</RequireAll>

W tym przykładzie, jeśli User-Agent zawiera „BadBot” lub „EvilScraper” (bez rozróżniania wielkości liter), to ustawia się zmienna środowiskowa bad_bot, a następnie blokujemy (Require not env) wszystkie żądania z tą zmienną.

Blokada botów poprzez RewriteCond i RewriteRule

Innym sposobem poza modułem **mod\_setenvif** jest wykorzystanie **RewriteCond** i **RewriteRule.**

RewriteRule to reguły przepisywania adresów URL, są one wykonywane jedna po drugiej. Jest jednak możliwość umieszczenia L w nawiasach kwadratowych na końcu wiersza **\[L\]**, oznacza to daną regułę jako ostatnią i kolejnie nie będą wykonywane.

RewriteCond to opcjonalny warunek, który musi być spełniony, aby zostały wykonane reguły zawarte w RewriteRule. Warunki umieszczane są przed RewriteRule i sprawdzane są jeden po drugim. RewriteRule jest wykonywane, jeśli wszystkie warunki zostały spełnione. Tak, jak w przypadku RewriteRule powyżej i tutaj można umieścić na końcu linii dodatkowe zapisy. Warunki zawarte w RewriteCond dotyczą tylko pierwszej reguły zapisanej w RewriteRule, zaraz po warunkach.

W przypadku RewriteRule i RewriteCond w nawisach kwadratowych mogą znajdować się oznaczenia:

  • \[OR\] – łączy to wpis/warunek w kolejnej linii zapisem logicznym "lub". W tym wypadku ciąg warunków jest spełniony, jeśli jeden lub więcej warunków składowych jest spełniony.
  • \[NC\] – wielkość liter nie ma znaczenia (ważne przy nazwach botów)
  • \[L\] – oznacza daną regułę RewriteRule jako ostatnią, kolejne nie będą wykonywane
  • \[F\] – po spełnieniu warunków zwraca błąd 403

Przykładowy zapis w .htaccess przy wykorzystaniu RewriteCond i RewriteRule będzie wyglądał następująco.

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} .*nazwa_bota* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} .*nazwa_innego_bota* [NC]
RewriteRule ^.* - [F,L]

Oznacza to: jeśli nazwa user agenta zawiera "nazwa_bota" lub **\[OR\]** "nazwa_innego_bota" (wielkość znaków nie ma znaczenia **\[NC\]**), zwróć błąd 403 **\[F\]** i zakończ wykonywanie RewriteRule **\[L\]**.

Blokada botów z pustym User-Agent z wykorzystaniem RewriteCond i RewriteRule

Niekiedy roboty nie mają uzupełnionego User-Agent, dzięki czemu nie będą blokowane przez poprzednie wpisy. Aby takie boty zablokować, należy do pliku .htaccess dodać następujący wpis.

RewriteEngine On

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

Wpis blokuje roboty z pustym User-Agent i User-Refferer, dzięki temu nie będą blokowani użytkownicy korzystający ze starych programów antywirusowych. Niektóre mogą blokować User-Agent użytkownika.

Blokowanie botów poprzez IPv4 i IPv6

Część robotów podszywa się pod przeglądarki internetowe, takie jak: Mozilla Firefox, Opera, czy Google Chrome. Całego ruchu z danej przeglądarki nie powinno się blokować, z oczywistej przyczyny - zablokowani zostaną również odwiedzający stronę, korzystający z danej przeglądarki.

W takim wypadku można zablokować adres IPv4 lub IPv6, z którego łączy się dany bot. Można to osiągnąć poprzez dodanie poniższego wpisu do .htaccess.

Deny from "Adres IPv4"
Deny from "Adres IPv6"

Oczywiście "Adres IPv4" lub "Adres IPv6" należy zamienić na faktyczny adres IP.

Plik robots.txt

Dodatkowo do .htaccess można również w głównym katalogu domeny dodać plik robots.txt, dzięki temu plikowi można zezwolić lub zablokować dostęp robotom do danej strony, lub konkretnych plików czy katalogów.

Zezwolenie na dostęp do całej strony

Ten zapis zezwala wszystkim robotom na dostęp do całej strony, tak samo byłoby w przypadku braku pliku robots.txt.

User-agent: *
Allow:

Zablokowanie dostępu do całej strony

Poniższy wpis działa całkowicie przeciwnie do poprzedniego. Blokuje wszystkim robotom dostęp do całej strony.

User-agent: *
Disallow: /

Zablokowanie dostępu do konkretnych katalogów

Poniższy wpis blokuje dostęp do katalogów "pliki" oraz "zdjecia" w głównym katalogu domeny.

User-agent: *
Disallow: /pliki/
Disallow: /zdjecia/

Zablokowanie dostępu do pliku

Ostatnim przedstawionym w tym tekście przykładów, jest blokada dostępu do danego pliku na domenie. Jako przykład podałem plik "strona.html" w katalogu "pliki".

User-agent: *
Disallow: /pliki/strona.html

Powyższe przykłady można rozszerzać o kolejne katalogi czy pliki, do których chcesz zablokować dostęp. Nie ma tutaj limitu na ilość zablokowanych elementów.

Po co stosować te blokady i mechanizmy?

  1. Ochrona zasobów serwera

    • Boty (szczególnie złe) mogą generować ogromny ruch, co obciąża serwer. Blokując je na poziomie Apache, można zmniejszyć ładunek serwera, zmniejszyć zużycie pasma i obniżyć ryzyko ataków.
    • Boty, które nie robią nic wartościowego (np. skrobaki treści, agresywne crawlery) nie powinny obciążać serwera.
  2. Bezpieczeństwo

    • Niektóre boty mogą być wykorzystywane do skanowania luk bezpieczeństwa lub prób ataków (np. brute-force, scraping, brute crawl).
    • Blokując boty z pustym User-Agent, można utrudnić ukrytym, „umaskowanym” botom działanie, choć nie jest to nieomylna ochrona (nagłówki mogą być fałszowane).
  3. Zarządzanie SEO

    • Chcesz kontrolować, które boty (crawler’y) mają dostęp do Twojego serwisu (np. Googlebot, Bingbot itp.), a które nie (np. złośliwe skrobaki).
    • robots.txt pomaga w kierowaniu „dobrych” botów do właściwych sekcji, a blokady Apache pomagają zatrzymać tych, którzy mogą szkodzić.
  4. Kontrola i filtrowanie

    • Używając SetEnvIf, można stworzyć dynamiczne reguły blokujące w oparciu o nagłówki HTTP. To pozwala na bardziej elastyczne filtrowanie niż tylko statyczna lista IP.
    • RewriteCond / RewriteRule daje bardzo precyzyjną kontrolę nad warunkami blokady (np. kombinacje warunków: User-Agent + IP + referrer + URI).

Kiedy stosować który mechanizm blokady?

  • Używaj **robots.txt** jako pierwszej linii obrony dla „dobrych” botów (crawler’y, indeksujące).
  • Gdy zauważysz **złośliwy ruch od botów** (np. scraping, agresywne crawlery), dodaj reguły blokujące w .htaccess (mod\_rewrite lub SetEnvIf).
  • Jeśli boty mają nietypowe lub puste User-Agent, rozważ reguły wykrywające puste UA (pusty referer + UA).
  • Dla dużych serwisów lub bardzo atakujących botów – rozważ ochronę na poziomie sieci (firewall, WAF) zamiast tylko Apache.

Przykład z życia? Czy SetEnvIfNoCase, SetEnvIf, RewriteCond i RewriteRule mogą pomóc przy wzmożonym ruchu?

Tak — to jedne z najprostszych i najskuteczniejszych narzędzi, kiedy chcesz ograniczyć niepożądany ruch, zanim dotrze do PHP, bazy danych i zasobów aplikacji. Wzrost bot traffic w sezonie jest faktem (w dokumentach: +18% przed Black Friday, +30% w szczycie). Ten ruch trzeba filtrować jak najbliżej wejścia na serwer, bo każde zapytanie, które przepuścisz do aplikacji, zużywa CPU, RAM i I/O. Zobacz, jak przygotować serwer VPS na ruch sezonowy.

Blokada botów, .htaccess i analiza logów serwera

Filtry serwerowe w .htaccess, takie jak SetEnvIfNoCase, SetEnvIf, RewriteCond i RewriteRule, działają jako pierwsza linia ochrony przed botami oraz nadmiernym crawlingiem, odcinając niechciany ruch jeszcze przed uruchomieniem silnika sklepu i obciążeniem bazy danych.

W praktyce pozwala to realnie obniżyć obciążenie CPU, RAM i I/O, zwłaszcza w okresach sezonowych skoków ruchu.

Te reguły warto traktować jako element większej strategii zarządzania ruchem. Umiejętne korzystanie z przekierowań 301 w pliku .htaccess pozwala uporządkować strukturę adresów URL i ograniczyć liczbę niepotrzebnych odwołań do aplikacji, co w sezonie dodatkowo odciąża serwer. Z kolei analiza logów serwera pod SEO pomaga wychwycić wzorce crawlingu, zidentyfikować nadmiernie aktywne boty oraz nietypowe piki zapytań — i na tej podstawie zbudować skuteczne reguły blokujące lub ograniczające ruch z problematycznych źródeł.

Czy udało Ci się rozwiązać problem?
Nie znalazłeś odpowiedzi na swoje pytanie?