Mislukt uw InspectWP-crawl, levert deze een leeg rapport op of analyseert hij zichtbaar alleen een challenge-pagina, dan zijn beveiligingsmechanismen op de doelsite vrijwel altijd de oorzaak. Deze gids loodst u door elke veelvoorkomende belemmering, van Cloudflare via Wordfence tot .htaccess, en laat zien hoe u ze voor de duur van een crawl versoepelt of kort uitschakelt.
1. Waarom crawls mislukken
Typische symptomen die erop wijzen dat een beveiligingsbarrière in de weg zit:
- Time-out / afgebroken crawl: de site reageert niet, of pas na 30+ seconden.
- Leeg of bijna leeg rapport: geen titel, geen plug-ins, geen thema gedetecteerd, hoogstwaarschijnlijk is een challenge- of blokkadepagina gecrawld.
- HTTP 403 / 429 / 503: een firewall heeft het verzoek afgewezen of er is een rate-limit geactiveerd.
- Verkeerde inhoud: de screenshot toont een Cloudflare-controlepagina, een Wordfence-blokkadepagina, een coming-soon-scherm of een loginformulier in plaats van uw echte website.
2. Voordat u begint
InspectWP gebruikt een echte headless Chrome-browser en gedraagt zich als een gewone bezoeker met een actuele Chrome. De crawl komt uit een pool van wisselende server-IP's. Er is dus noch een vast crawler-IP, noch een InspectWP-markering in de user agent die u zou kunnen whitelisten. Dat betekent: blokkeert uw botbescherming onbekende bezoekers of legt ze een challenge op, dan raakt dat ook InspectWP, en dat is de eigenlijke oorzaak van het probleem. De oplossing is daarom altijd om de betreffende bescherming voor de duur van de crawl te versoepelen of kort uit te schakelen.
3. Cloudflare
Cloudflare is de meest voorkomende reden voor mislukte crawls. Log in op het Cloudflare-dashboard en controleer:
- Security → Bots: zet Bot Fight Mode en Super Bot Fight Mode op Off.
- Security → Settings: zet Security Level tijdelijk op Essentially Off of Low.
- Security → WAF → Tools: controleer dat Under Attack Mode uit staat (gebruik in plaats daarvan High of lager).
- Custom Rules: hebt u eigen WAF-regels, controleer dan of een ervan user agents of IP's blokkeert.
InspectWP kan een Managed Challenge in veel gevallen zelf doorstaan. Lukt dat niet, dan helpt alleen het verlagen van het Security Level of het uitschakelen van de Bot Fight Mode voor de duur van de crawl.
4. Wordfence
Wordfence is de populairste WordPress-beveiligingsplug-in en blokkeert crawlers vaak zeer agressief. Zo gaat u ermee om:
- Wordfence → Tools → Live Traffic: controleer of er op het moment van de crawl verzoeken zijn geblokkeerd. De vermelding laat zien welke regel is aangeslagen.
- Wordfence → Firewall → All Firewall Options: zet de firewall kort op Learning Mode of Disabled.
- Rate Limiting: verhoog de drempels voor „Hoeveel pagina's mag een crawler per minuut bezoeken“ flink.
- Block fake Google crawlers: deze optie kan InspectWP blokkeren, schakel hem tijdelijk uit.
5. Sucuri, Solid Security, iThemes Security, All-In-One Security (AIOS)
Andere bekende beveiligingsplug-ins gebruiken zeer vergelijkbare mechanismen. Zoek specifiek naar:
- Brute-force-bescherming / 404-detectie
- Rate-limiting voor onbekende user agents
- Featured / aanbevolen blokkadelijsten
- Landenblokkade
Schakel de relevante functie uit of verhoog de drempels tijdelijk.
6. Limit Login Attempts / Loginizer
Deze plug-ins blokkeren IP's na mislukte loginpogingen. InspectWP probeert nooit in te loggen, maar: heeft uw server net andere mislukte logins vanuit het crawl-IP-bereik geregistreerd, dan kan het IP al zijn geban. Controleer de blokkadelijst van de plug-in en verwijder zo nodig het item.
7. Anti-bot- en anti-spamplug-ins
CleanTalk, Blackhole for Bad Bots, StopBadBots en consorten werken op heuristieken en blokkeren elke ongebruikelijke user agent. De enige oplossing is: ze voor de duur van de crawl kort uitschakelen.
8. Coming-soon- en onderhoudsplug-ins
Plug-ins als SeedProd, WP Maintenance Mode, Elementor Coming Soon of WP Maintenance tonen externe bezoekers een placeholder-pagina. InspectWP analyseert dan die placeholder, niet uw echte site. Bypass-links die sommige plug-ins bieden, werken doorgaans niet voor externe crawls. Oplossing: deactiveer de plug-in kort, voer de crawl uit, activeer de plug-in opnieuw.
9. Caching- en optimalisatieplug-ins
WP Rocket, LiteSpeed Cache, W3 Total Cache en vergelijkbare tools kunnen vreemde crawl-resultaten opleveren wanneer agressieve optimalisatie is ingeschakeld, bijvoorbeeld wanneer JavaScript wordt vertraagd of gecombineerd. Aanbevelingen:
- Wis de cache vóór het crawlen
- Houd „Bot Cache“ / „Cache for logged-out users“ ingeschakeld, anders ziet InspectWP mogelijk een verouderde versie
- Controleer JavaScript-Delay-/lazy-render-opties; InspectWP wacht weliswaar op interactie, maar extreme vertragingen veroorzaken time-outs
10. Wachtwoordbeveiliging, members-only, beperkte content
Een pagina die alleen toegankelijk is voor ingelogde gebruikers of achter HTTP basic auth zit, kan niet door InspectWP worden gecrawld. Zorg dat de URL die u wilt analyseren publiek bereikbaar is zonder login. Deactiveer kort plug-ins als Restrict Content Pro, MemberPress of Password Protected, of stel de doelpagina in als publiek.
11. .htaccess en nginx, IP-, land- en user-agent-blokkades
Op serverniveau worden crawlers vaak geblokkeerd via Deny of RewriteRule. Voorbeelden uit typische .htaccess-bestanden die u tijdelijk kunt uitcommentariëren:
# Bot user-agent block (common)
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=BlockCountryVoor nginx ziet het equivalent er zo uit:
if ($http_user_agent ~* (bot|crawler|spider)) {
return 403;
}Commenteer deze regels uit voor de duur van de crawl.
12. Beveiligingsmechanismen aan de hostingzijde
Sommige hosters draaien een eigen Web Application Firewall (WAF) of ModSecurity-regels die u niet ziet in de plug-in- of .htaccess-audit. Vraag de support om de botbescherming voor de duur van de crawl te versoepelen. Bekende voorbeelden:
- All-Inkl, IONOS, Strato: botbescherming in het hostingpaneel, neem contact op met support of schakel ze uit via het klantmenu.
- SiteGround: AI anti-bot, Smart-WAF, onder Site Tools → Security.
- Kinsta, WP Engine: eigen botdetectie, vraag versoepeling via support aan.
- Hetzner / cloudaanbieders: zelden WAF-problemen, maar GeoIP-restricties zijn mogelijk.
13. CSP, X-Frame-Options en robots.txt
Voor de duidelijkheid: een robots.txt met Disallow: / houdt InspectWP niet tegen, wij volgen robots.txt niet strikt. Content-Security-Policy en X-Frame-Options kunnen daarentegen individuele subverzoeken (iframes, scripts van derden) verhinderen; dat is normaal en geen fout. De blokkades die er werkelijk toe doen, zijn 403/429/503-antwoorden op het hoofddocument.
14. Rate limiting en Fail2Ban
Op serverniveau kunnen fail2ban, mod_evasive of nginx limit_req het crawl-IP binnen seconden bannen, vooral bij veel parallelle subverzoeken. Hebt u SSH-toegang, controleer dan /var/log/fail2ban.log of iptables -L. Verhoog de drempels voor de duur van de crawl of verwijder het geblokkeerde IP uit de banlijst.
15. Checklist voor opnieuw crawlen
- ☐ Cloudflare Bot Fight Mode uit
- ☐ Wordfence-firewall in Learning Mode
- ☐ Beveiligingsplug-in (Sucuri / Solid / AIOS) op een gematigde instelling
- ☐ Coming-soon-/onderhoudsplug-in gedeactiveerd
- ☐ Cache van cachingplug-in gewist
- ☐ .htaccess / nginx gecontroleerd op user-agent-/IP-blokkades
- ☐ Hostingpaneel: botbescherming / WAF gecontroleerd
- ☐ Pagina is publiek bereikbaar zonder login
- ☐ Browsercache gewist en een verse testcrawl uitgevoerd
16. Wanneer niets helpt
Mail ons op hello@inspectwp.com met het domein en het ongeveerlijke tijdstip van de mislukte crawl.
Vergeet na een geslaagde crawl niet alle beveiligingsmechanismen weer in te schakelen!