Blokowanie botów i crawlerów bez psucia SEO: praktyczny poradnik

Blokowanie botów ma sens tylko wtedy, gdy wiesz, którego bota blokujesz i po co. Dobre crawlery pomagają stronie pojawić się w wyszukiwarkach. Złe boty skanują podatności, kopiują treści, przeciążają serwer albo spamują formularze. Wrzucenie wszystkiego do jednego worka może zabić widoczność strony szybciej niż sam spam.

Najważniejsza zasada: robots.txt nie jest firewallem. To prośba dla crawlerów, które respektują zasady. Złośliwe boty mogą ją zignorować. Do bezpieczeństwa używaj WAF, rate limitów, blokad aplikacyjnych i logów serwera.

Najpierw rozdziel typy botów

Typ ruchu	Przykład	Co robić
Wyszukiwarki	Googlebot, Bingbot	Nie blokować ważnych sekcji. Kontrolować crawl przez sitemap, canonical i jakość URL-i
Narzędzia SEO	AhrefsBot, SemrushBot	Decyzja biznesowa: można ograniczyć, ale nie mylić z Googlebotem
AI crawlery	Boty pobierające treści do trenowania lub indeksów AI	Ustalić politykę w robots.txt i monitorować zgodność
Scrapery	Masowe pobieranie treści/cen	Rate limiting, WAF, blokady po zachowaniu
Skanery podatności	Próby wejścia w wp-admin, xmlrpc, znane exploity	Blokady serwerowe, WAF, aktualizacje, logi
Spam boty	Formularze, komentarze, rejestracje	Honeypot, limity, walidacja, Turnstile/reCAPTCHA dopiero gdy trzeba

robots.txt, noindex i WAF: czego użyć?

Mechanizm	Do czego służy	Czego nie robi
robots.txt	Kieruje crawlerami, które go respektują	Nie usuwa strony z indeksu, nie zatrzymuje złych botów
meta noindex	Prosi wyszukiwarkę, żeby nie indeksowała konkretnej strony	Nie działa, jeśli crawler nie może wejść na stronę przez robots.txt
canonical	Wskazuje preferowaną wersję duplikatu	Nie jest blokadą dostępu
WAF	Blokuje podejrzane żądania i wzorce ataków	Nie zastępuje poprawnej architektury SEO
Rate limit	Ogranicza nadmierne żądania z IP/sieci	Może trafić legalnych użytkowników, jeśli ustawisz go zbyt ostro

Bezpieczny przykład robots.txt

User-agent: *
Disallow: /wp-admin/
Disallow: /koszyk/
Disallow: /checkout/
Disallow: /konto/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://stronyinternetowe.uk/sitemap.xml

To jest przykład kierunkowy, nie gotowiec dla każdej strony. Dla sklepów, filtrów i wyszukiwarek wewnętrznych trzeba osobno sprawdzić parametry URL-i, canonicale i to, czy przypadkiem nie blokujesz stron, które powinny rankować.

Czego nie blokować bez testu?

• Plików CSS i JS potrzebnych Google do renderowania strony.
• Obrazów, jeśli mają pracować w Google Images albo jako element strony.
• Stron usługowych, kategorii i artykułów z ruchem organicznym.
• Starych URL-i przed oceną, czy powinny dostać redirect, merge czy odtworzenie.
• Googlebota na podstawie samego user-agenta, bez weryfikacji IP i zachowania.

Praktyczny proces decyzji

1. Wyciągnij logi serwera lub dane z Cloudflare za ostatnie 7-30 dni.
2. Podziel ruch na wyszukiwarki, narzędzia SEO, AI crawlery, scrapery i ataki.
3. Sprawdź, które URL-e są najczęściej pobierane i czy mają wartość SEO.
4. Dla crawl budget napraw śmieciowe URL-e, parametry i duplikaty.
5. Dla ataków użyj WAF, reguł aplikacyjnych i limitów, nie robots.txt.
6. Po zmianie sprawdź GSC: Coverage/Pages, crawl stats i spadki wyświetleń.

Matryca ryzyka blokady

Planowana blokada	Ryzyko SEO	Bezpieczniejsza alternatywa
Disallow całego /blog/	Bardzo wysokie	Poprawić/połączyć słabe artykuły, nie odcinać całego katalogu
Blokada parametrów filtrów	Średnie	Canonical + noindex dla wybranych typów + test w GSC
Blokada wp-admin	Niskie	Standard, zostawić admin-ajax jeśli potrzebny
Blokada konkretnego scrapera	Niskie/średnie	WAF/rate limit po zachowaniu, nie tylko user-agent
Blokada Googlebot	Krytyczne	Nie robić, chyba że to zweryfikowany fałszywy user-agent

Jak rozpoznać fałszywego Googlebota?

Nie wystarczy spojrzeć na user-agent. Złośliwy bot może podpisać się jako Googlebot. Google zaleca weryfikację przez reverse DNS i forward DNS. W praktyce, jeśli nie masz automatycznego narzędzia, nie blokuj „Googlebota” ręcznie na podstawie jednej linijki logu.

Bezpieczniejszy proces to: sprawdzić IP, zachowanie, częstotliwość żądań, pobierane URL-e i wpływ na serwer. Jeżeli ruch wygląda jak atak, lepiej zastosować regułę WAF po zachowaniu niż globalną blokadę po nazwie bota.

Przykłady decyzji dla realnych sytuacji

Sytuacja	Lepsza reakcja	Czego unikać
Bot uderza w /wp-login.php na stronie bez WordPressa	Blokada WAF lub reguła serwerowa dla wzorca	Zmiany w robots.txt jako „zabezpieczenie”
Google crawluje stare parametry	Canonical, poprawa linkowania, sitemap, ewentualnie noindex	Disallow bez sprawdzenia indeksacji
Scraper pobiera setki artykułów	Rate limit, challenge, analiza IP i user-agent	Blokada całego kraju bez danych
Ahrefs/Semrush zużywa crawl budget serwera	Ograniczenie wybranych botów w robots.txt lub WAF	Mylenie ich z Googlebotem
Po migracji masa 404/410	Mapa redirectów i recovery ważnych URL-i	Zrzucanie winy na boty

Cloudflare, WAF i rate limiting

Jeżeli strona stoi za Cloudflare lub podobnym WAF-em, blokady warto ustawiać warstwowo. Najpierw reguły dla oczywistych ataków, potem limity dla nadmiernej liczby requestów, a dopiero potem bardziej agresywne challenge. Dla stron firmowych zwykle wystarcza ochrona formularzy, blokada znanych ścieżek ataków i rozsądne limity na endpointy, które są kosztowne.

• Nie challenge'uj Googlebota i podstawowych zasobów potrzebnych do renderowania.
• Nie blokuj CSS/JS, bo Google musi zobaczyć wyrenderowaną stronę.
• Formularze chroń honeypotem i walidacją po stronie serwera.
• Dla API stosuj rate limits i tokeny, a nie sam robots.txt.

Monitoring po zmianach

Każdą większą zmianę w blokowaniu botów monitoruj przez co najmniej kilka dni. W GSC sprawdź, czy nie spada liczba wyświetleń i czy Google nadal pobiera ważne strony. W logach serwera zobacz, czy spadł ruch problematyczny, a nie cały crawl. W Cloudflare porównaj liczbę blokad z faktycznymi błędami użytkowników.

1. Dzień 0: zapisz aktualny ruch botów i status GSC.
2. Dzień 1-3: sprawdź, czy ważne URL-e nadal zwracają 200.
3. Dzień 7: porównaj crawl stats, błędy i obciążenie serwera.
4. Dzień 14-28: oceń wpływ na widoczność, nie tylko na logi.

FAQ: blokowanie botów

Czy robots.txt usuwa stronę z Google?

Nie bezpośrednio. Robots.txt blokuje crawlowanie, ale URL może nadal pojawiać się w indeksie, jeśli Google zna go z linków. Do usuwania z indeksu służy noindex, ale Google musi móc wejść na stronę, żeby go zobaczyć.

Czy warto blokować narzędzia SEO?

To decyzja biznesowa. Możesz ograniczyć crawl Ahrefs czy Semrush, ale nie myl ich z wyszukiwarkami. Blokada narzędzi SEO nie powinna zaszkodzić Google, o ile reguły są precyzyjne.

Czy agresywna ochrona antybotowa może zaszkodzić SEO?

Tak. Jeśli WAF, challenge albo reguły serwera utrudniają Google renderowanie strony, możesz zobaczyć spadki indeksacji i widoczności. Dlatego po zmianach trzeba sprawdzić GSC i renderowanie ważnych stron.

Podsumowanie

Boty blokuj warstwowo: robots.txt do polityki crawl, noindex do indeksacji, canonical do duplikatów, WAF i rate limits do bezpieczeństwa. Najgorsze rozwiązanie to agresywna blokada bez sprawdzenia, czy odcinasz Google od ważnych zasobów.

Jeżeli problem dotyczy widoczności po migracji, zacznij od mapy URL-i, redirectów i GSC. Zła blokada lub źle ustawione 410 potrafią wyglądać jak „problem z botami”, choć realnie chodzi o utratę ciągłości treści. W takich przypadkach warto połączyć SEO techniczne z analizą bezpieczeństwa strony.

Źródła bazowe: Google Search Central o robots.txt oraz dokumentacja dostawcy WAF, którego używasz.