Was tun, wenn der Crawl nicht klappt? Sicherheitsmechanismen vorübergehend deaktivieren

Wenn dein InspectWP-Crawl fehlschlägt, einen leeren Report liefert oder sichtbar nur eine Challenge-Seite analysiert, liegt das fast immer an Sicherheitsmechanismen auf der Zielseite. Diese Anleitung führt dich durch alle gängigen Sperren, von Cloudflare über Wordfence bis zur htaccess, und zeigt, wie du sie für die Dauer eines Crawls deaktivierst oder InspectWP whitelistest.

1. Warum Crawls scheitern

Typische Symptome, an denen du erkennst, dass eine Sperre greift:

• Timeout / Crawl bricht ab: Die Seite antwortet nicht oder erst nach 30+ Sekunden.
• Leerer oder fast leerer Report: Kein Titel, keine Plugins, kein Theme erkannt, vermutlich wurde eine Challenge- oder Block-Page gecrawlt.
• HTTP 403 / 429 / 503: Firewall hat den Request abgelehnt oder Rate-Limit ausgelöst.
• Falscher Inhalt: Im Screenshot ist eine Cloudflare-Checking-Seite, eine Wordfence-Block-Page, eine Coming-Soon-Seite oder eine Login-Maske statt deiner echten Website zu sehen.

2. Bevor du startest

InspectWP nutzt einen echten Headless-Chrome-Browser und tarnt sich nicht als Suchmaschinen-Bot. Der User-Agent enthält den Hinweis InspectWP. Das bedeutet: Wenn du Bots generell blockst, wirst du auch InspectWP blocken, und das ist der eigentliche Grund für das Problem. Whitelisting ist meistens die sauberere Lösung als komplettes Abschalten.

3. Cloudflare

Cloudflare ist die häufigste Ursache für gescheiterte Crawls. Logge dich im Cloudflare-Dashboard ein und prüfe folgende Einstellungen:

• Security → Bots: Bot Fight Mode und Super Bot Fight Mode auf Off stellen.
• Security → Settings: Security Level kurz auf Essentially Off oder Low setzen.
• Security → WAF → Tools: Under Attack Mode muss aus sein (statt dessen High oder niedriger).
• Custom Rules: Falls du eigene WAF-Regeln hast, prüfe, ob eine davon User-Agents oder IPs blockt.

Wenn du den Bot-Schutz nicht ausschalten möchtest, lege stattdessen eine Cloudflare-WAF-Custom-Rule mit Action Skip für User-Agents an, die InspectWP enthalten.

4. Wordfence

Wordfence ist das beliebteste WordPress-Sicherheits-Plugin und sperrt Crawler oft sehr aggressiv. So gehst du vor:

• Wordfence → Tools → Live Traffic: Suche nach blockierten Requests von den InspectWP-IPs 195.201.17.43 und 46.224.183.125 und trage sie unter Whitelisted IPs ein.
• Wordfence → Firewall → All Firewall Options: Stelle die Firewall kurzzeitig auf Learning Mode oder Disabled.
• Rate Limiting: Erhöhe die Schwellenwerte für „How many page views can a crawler visit per minute“ deutlich.
• Block fake Google crawlers: Diese Option kann InspectWP blocken, vorübergehend deaktivieren.

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

Andere bekannte Sicherheits-Plugins haben sehr ähnliche Mechanismen. Schaue gezielt nach:

• Brute-Force-Schutz / 404-Detection
• Rate-Limiting für unbekannte User-Agents
• Featured / Recommended Block Lists
• Country-Blocking

Deaktiviere die jeweilige Funktion oder hebe die Schwellenwerte temporär an.

6. Limit Login Attempts / Loginizer

Diese Plugins sperren IPs nach fehlgeschlagenen Login-Versuchen. InspectWP versucht zwar nie sich einzuloggen, aber: Wenn dein Server gerade andere Login-Versuche von der Crawl-IP-Range registriert hat, kann die IP bereits gebannt sein. Prüfe die Block-Liste des Plugins und entferne ggf. den Eintrag.

7. Anti-Bot- und Anti-Spam-Plugins

CleanTalk, Blackhole for Bad Bots, StopBadBots & Co. agieren auf Heuristiken und blocken jeden ungewöhnlichen User-Agent. Hier hilft nur: kurz deaktivieren oder den InspectWP-User-Agent in die jeweilige Whitelist eintragen.

8. Coming-Soon- und Maintenance-Plugins

Plugins wie SeedProd, WP Maintenance Mode, Elementor Coming Soon oder WP Maintenance zeigen externen Besuchern eine Platzhalterseite. InspectWP analysiert dann diese Platzhalterseite, nicht deine echte Site. Bypass-Links, die manche Plugins anbieten, funktionieren bei externen Crawls in der Regel nicht. Lösung: Plugin kurz deaktivieren, Crawl ausführen, Plugin reaktivieren.

9. Caching- und Optimierungs-Plugins

WP Rocket, LiteSpeed Cache, W3 Total Cache und ähnliche Tools können bei aggressiven Optimierungen seltsame Crawl-Ergebnisse erzeugen, z. B. wenn JavaScript verzögert geladen oder kombiniert wird. Empfohlen:

• Cache vor dem Crawl leeren
• „Bot Cache“ / „Cache for logged-out users“ aktiv lassen, sonst kann InspectWP eine veraltete Version sehen
• JavaScript-Delay / Lazy-Render-Optionen prüfen, InspectWP wartet zwar auf Interaktion, aber extreme Verzögerungen schaffen Timeouts

10. Passwort-Schutz, Members-Only, Restrict Content

Eine Seite, die nur eingeloggten Nutzern oder per HTTP-Basic-Auth zugänglich ist, kann InspectWP nicht crawlen. Stelle sicher, dass die zu analysierende URL ohne Login öffentlich erreichbar ist. Plugins wie Restrict Content Pro, MemberPress oder Password Protected kurz deaktivieren oder die Zielseite öffentlich schalten.

11. .htaccess und nginx, IP-, Country- und User-Agent-Blocks

Auf Server-Ebene werden Crawler oft per Deny oder RewriteRule ausgesperrt. Beispiele aus typischen .htaccess-Dateien, die du temporär auskommentieren kannst:

# Bot-User-Agent-Block (typisch)
RewriteCond %{HTTP_USER_AGENT} (bot|crawler|spider) [NC]
RewriteRule .* - [F,L]

# IP-Block
Deny from 1.2.3.4

# Country-Block via mod_geoip
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountry

Bei nginx sieht das vergleichbar aus:

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

Kommentiere die entsprechenden Zeilen für die Dauer des Crawls aus.

12. Hoster-seitige Schutzmechanismen

Manche Hoster betreiben eine eigene Web Application Firewall (WAF) bzw. ModSecurity-Regeln, die du im Plugin- oder htaccess-Audit gar nicht siehst. Bitte den Support, die InspectWP-IPs 195.201.17.43 und 46.224.183.125 auf die Whitelist zu setzen. Bekannte Beispiele:

• All-Inkl, IONOS, Strato: Bot-Schutz im Hosting-Panel, Support kontaktieren oder im Kundenmenü deaktivieren.
• SiteGround: AI-Anti-Bot, Smart-WAF, unter Site Tools → Security.
• Kinsta, WP Engine: Eigene Bot-Detection, Whitelist über den Support anfragen.
• Hetzner / Cloud-Provider: Selten WAF-Probleme, aber GeoIP-Restriktionen möglich.

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

Zur Klarstellung: Eine robots.txt mit Disallow: / hindert InspectWP nicht am Crawl, wir respektieren robots.txt nicht zwingend. Content-Security-Policy und X-Frame-Options hingegen können einzelne Sub-Requests (Iframes, Drittanbieter-Skripte) verhindern; das ist normal und kein Fehler. Hauptsächlich relevante Sperren sind 403/429/503 vom Hauptdokument.

14. Rate Limiting und Fail2Ban

Auf Server-Ebene können fail2ban, mod_evasive oder nginx limit_req die Crawl-IP nach wenigen Sekunden sperren, gerade bei vielen parallelen Sub-Requests. Falls du SSH-Zugriff hast, prüfe /var/log/fail2ban.log bzw. iptables -L. Eine kurzfristige Whitelist der InspectWP-Server-IP löst das Problem.

15. Checkliste vor dem erneuten Crawl

• ☐ Cloudflare Bot Fight Mode aus
• ☐ Wordfence Firewall im Learning Mode oder InspectWP-IP whitelisted
• ☐ Sicherheits-Plugin (Sucuri / Solid / AIOS) auf moderate Stufe
• ☐ InspectWP-IPs 195.201.17.43 und 46.224.183.125 in Plugin-/Hoster-Whitelist eingetragen
• ☐ Coming-Soon- / Maintenance-Plugin deaktiviert
• ☐ Caching-Plugin geleert
• ☐ .htaccess / nginx auf User-Agent-/IP-Blocks geprüft
• ☐ Hoster-Panel: Bot-Schutz / WAF prüfen
• ☐ Seite ist ohne Login öffentlich erreichbar
• ☐ Cache des Browsers geleert und Test-Crawl ausgeführt

16. Wenn nichts hilft

Schreibe uns an hello@inspectwp.com mit der Domain und dem ungefähren Zeitpunkt des fehlgeschlagenen Crawls.

Vergiss nach dem erfolgreichen Crawl nicht, alle Sicherheitsmechanismen wieder zu aktivieren!