Co zrobić, gdy crawl się nie powiedzie — tymczasowe wyłączanie mechanizmów bezpieczeństwa

Jeśli Twój crawl InspectWP zawodzi, zwraca pusty raport lub widocznie analizuje tylko stronę z challenge, prawie zawsze przyczyną są mechanizmy bezpieczeństwa na stronie docelowej. Ten poradnik prowadzi przez każdą typową przeszkodę — od Cloudflare przez Wordfence po .htaccess — i pokazuje, jak je wyłączyć na czas crawla lub dodać InspectWP do białej listy.

1. Dlaczego crawle zawodzą

Typowe objawy wskazujące, że na drodze stoi bariera bezpieczeństwa:

• Timeout / przerwany crawl: Strona nie odpowiada lub odpowiada dopiero po 30+ sekundach.
• Pusty lub niemal pusty raport: Brak tytułu, wtyczek, nie wykryto motywu — najprawdopodobniej crawlowana była strona challenge lub blokująca.
• HTTP 403 / 429 / 503: Firewall odrzucił żądanie lub uruchomił się rate-limit.
• Niewłaściwa treść: Zrzut ekranu pokazuje stronę weryfikacji Cloudflare, stronę blokady Wordfence, ekran „wkrótce“ lub formularz logowania zamiast Twojej prawdziwej strony.

2. Zanim zaczniesz

InspectWP używa prawdziwej przeglądarki headless Chrome i nie udaje bota wyszukiwarki. User agent zawiera znacznik InspectWP. To znaczy: jeśli ogólnie blokujesz boty, zablokujesz też InspectWP — i to jest faktyczna przyczyna. Dodanie do białej listy jest zwykle czystszym rozwiązaniem niż całkowite wyłączenie ochrony.

3. Cloudflare

Cloudflare to najczęstsza przyczyna nieudanych crawli. Zaloguj się do panelu Cloudflare i sprawdź:

• Security → Bots: Ustaw Bot Fight Mode oraz Super Bot Fight Mode na Off.
• Security → Settings: Tymczasowo ustaw Security Level na Essentially Off lub Low.
• Security → WAF → Tools: Upewnij się, że Under Attack Mode jest wyłączony (zamiast tego użyj High lub niższego).
• Custom Rules: Jeśli masz własne reguły WAF, sprawdź, czy któraś nie blokuje user agentów lub IP.

Jeśli nie chcesz wyłączać ochrony przed botami w całości, utwórz w Cloudflare regułę WAF z akcją Skip dla user agentów zawierających InspectWP.

4. Wordfence

Wordfence to najpopularniejsza wtyczka bezpieczeństwa WordPress i często blokuje crawlery bardzo agresywnie. Oto, jak sobie z tym poradzić:

• Wordfence → Tools → Live Traffic: Poszukaj zablokowanych żądań z IP InspectWP 195.201.17.43 i 46.224.183.125 i dodaj je w Whitelisted IPs.
• Wordfence → Firewall → All Firewall Options: Krótko przełącz firewall na Learning Mode lub Disabled.
• Rate Limiting: Znacząco podnieś progi „Ile odsłon może mieć crawler na minutę“.
• Block fake Google crawlers: Ta opcja może blokować InspectWP — wyłącz ją tymczasowo.

5. Sucuri, Solid Security, iThemes Security, All-In-One Security (AIOS)

Inne znane wtyczki bezpieczeństwa stosują bardzo podobne mechanizmy. Zwróć szczególną uwagę na:

• Ochronę przed brute-force / wykrywanie 404
• Rate-limiting dla nieznanych user agentów
• Wbudowane / rekomendowane listy blokad
• Blokowanie po kraju

Wyłącz odpowiednią funkcję lub tymczasowo podnieś progi.

6. Limit Login Attempts / Loginizer

Te wtyczki blokują IP po nieudanych próbach logowania. InspectWP nigdy nie próbuje się zalogować, ale: jeśli Twój serwer właśnie zarejestrował inne nieudane logowania z zakresu IP crawla, IP może już być zablokowane. Sprawdź listę blokad wtyczki i usuń wpis, jeśli to konieczne.

7. Wtyczki anty-bot i anty-spam

CleanTalk, Blackhole for Bad Bots, StopBadBots i podobne działają na heurystykach i blokują każdy nietypowy user agent. Jedyne rozwiązanie: krótko je wyłącz lub dodaj user agent InspectWP do białej listy wtyczki.

8. Wtyczki coming-soon i maintenance

Wtyczki takie jak SeedProd, WP Maintenance Mode, Elementor Coming Soon czy WP Maintenance pokazują zewnętrznym odwiedzającym stronę zastępczą. InspectWP analizuje wtedy ten placeholder, a nie Twoją prawdziwą stronę. Linki obejścia oferowane przez niektóre wtyczki zwykle nie działają dla zewnętrznych crawli. Rozwiązanie: krótko dezaktywuj wtyczkę, uruchom crawl, ponownie ją aktywuj.

9. Wtyczki cachowania i optymalizacji

WP Rocket, LiteSpeed Cache, W3 Total Cache i podobne narzędzia mogą produkować dziwne wyniki crawla, gdy włączona jest agresywna optymalizacja — na przykład gdy JavaScript jest opóźniony lub łączony. Zalecenia:

• Wyczyść cache przed crawlem
• Pozostaw włączone „Bot Cache“ / „Cache dla wylogowanych użytkowników“, inaczej InspectWP może zobaczyć starą wersję
• Sprawdź opcje JavaScript-Delay / lazy-render — InspectWP czeka na interakcję, ale ekstremalne opóźnienia powodują timeouty

10. Ochrona hasłem, tylko dla członków, ograniczona zawartość

Strona dostępna tylko dla zalogowanych użytkowników lub za HTTP basic auth nie może być crawlowana przez InspectWP. Upewnij się, że URL, który chcesz przeanalizować, jest publicznie dostępny bez logowania. Krótko dezaktywuj wtyczki takie jak Restrict Content Pro, MemberPress lub Password Protected, albo ustaw docelową stronę jako publiczną.

11. .htaccess i nginx — blokady IP, krajów i user agentów

Na poziomie serwera crawlery są często blokowane przez Deny lub RewriteRule. Przykłady z typowych plików .htaccess, które możesz tymczasowo zakomentować:

# Blokada user-agentów botów (typowa)
RewriteCond %{HTTP_USER_AGENT} (bot|crawler|spider) [NC]
RewriteRule .* - [F,L]

# Blokada IP
Deny from 1.2.3.4

# Blokada krajów przez mod_geoip
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountry

Dla nginx odpowiednik wygląda tak:

if ($http_user_agent ~* (bot|crawler|spider)) {
    return 403;
}

Zakomentuj te linie na czas crawla.

12. Mechanizmy ochrony po stronie hostingu

Niektórzy hostingodawcy uruchamiają własne Web Application Firewall (WAF) lub reguły ModSecurity, których nie zobaczysz w audycie wtyczek ani .htaccess. Poproś ich pomoc o dodanie do białej listy IP InspectWP 195.201.17.43 oraz 46.224.183.125. Znane przykłady:

• All-Inkl, IONOS, Strato: Ochrona przed botami w panelu hostingu — skontaktuj się z supportem lub wyłącz z poziomu panelu klienta.
• SiteGround: AI anti-bot, Smart-WAF, w Site Tools → Security.
• Kinsta, WP Engine: Własne wykrywanie botów — poproś o dodanie do białej listy przez support.
• Hetzner / dostawcy chmury: Rzadko problemy z WAF, ale możliwe ograniczenia GeoIP.

13. CSP, X-Frame-Options i robots.txt

Dla jasności: robots.txt z Disallow: / nie powstrzymuje InspectWP przed crawlowaniem — nie przestrzegamy ściśle robots.txt. Natomiast Content-Security-Policy i X-Frame-Options mogą uniemożliwić poszczególne sub-żądania (iframe, skrypty firm trzecich); to normalne i nie jest błędem. Faktycznie istotne blokady to odpowiedzi 403/429/503 na dokument główny.

14. Rate limiting i Fail2Ban

Na poziomie serwera fail2ban, mod_evasive lub nginx limit_req mogą zbanować IP crawla w ciągu sekund, zwłaszcza przy wielu równoległych sub-żądaniach. Jeśli masz dostęp SSH, sprawdź /var/log/fail2ban.log lub iptables -L. Krótkoterminowe dodanie do białej listy IP serwera InspectWP rozwiązuje sprawę.

15. Lista kontrolna przed ponownym crawlem

• ☐ Cloudflare Bot Fight Mode wyłączony
• ☐ Firewall Wordfence w trybie Learning lub IP InspectWP na białej liście
• ☐ Wtyczka bezpieczeństwa (Sucuri / Solid / AIOS) na umiarkowanym ustawieniu
• ☐ IP InspectWP 195.201.17.43 i 46.224.183.125 dodane do białej listy wtyczki/hostingu
• ☐ Wtyczka coming-soon / maintenance wyłączona
• ☐ Cache wtyczki cachującej wyczyszczony
• ☐ .htaccess / nginx sprawdzone pod kątem blokad user-agent/IP
• ☐ Panel hostingu: ochrona przed botami / WAF przejrzane
• ☐ Strona publicznie dostępna bez logowania
• ☐ Cache przeglądarki wyczyszczony i uruchomiony świeży crawl testowy

16. Gdy nic nie pomaga

Napisz do nas na hello@inspectwp.com z domeną i przybliżonym czasem nieudanego crawla.

Po udanym crawlu nie zapomnij włączyć z powrotem wszystkich mechanizmów bezpieczeństwa!