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 złagodzić lub na krótko wyłączyć na czas crawla.
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 występuje jak zwykły odwiedzający z aktualnym Chrome. Crawl pochodzi z puli zmieniających się adresów IP serwerów. Nie ma więc ani stałego IP crawlera, ani znacznika InspectWP w user agencie, który mógłbyś dodać do białej listy. To znaczy: jeśli Twoja ochrona przed botami blokuje nieznanych odwiedzających lub nakłada na nich challenge, dotyczy to również InspectWP i to jest właściwa przyczyna problemu. Dlatego rozwiązaniem jest zawsze złagodzenie danej ochrony na czas crawla lub jej krótkie wyłączenie.
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.
W wielu przypadkach InspectWP potrafi sam przejść Managed Challenge. Jeśli to się nie uda, pomaga tylko obniżenie Security Level lub wyłączenie Bot Fight Mode na czas crawla.
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: Sprawdź, czy w czasie crawla zablokowano jakieś żądania. Wpis pokazuje, która reguła zadziałała.
- 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: wyłącz je krótko na czas crawla.
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=BlockCountryDla 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 złagodzenie ochrony przed botami na czas crawla. 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 złagodzenie 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. Podnieś progi na czas crawla lub usuń zablokowane IP z listy banów.
15. Lista kontrolna przed ponownym crawlem
- ☐ Cloudflare Bot Fight Mode wyłączony
- ☐ Firewall Wordfence w trybie Learning
- ☐ Wtyczka bezpieczeństwa (Sucuri / Solid / AIOS) na umiarkowanym ustawieniu
- ☐ 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!