Wat te doen wanneer de crawl mislukt: beveiligingsmechanismen tijdelijk uitschakelen

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 uitschakelt of InspectWP whitelist.

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 doet zich niet voor als een zoekmachinebot. De user agent bevat de marker InspectWP. Dat betekent: blokkeert u in het algemeen bots, dan blokkeert u ook InspectWP, en dat is de werkelijke oorzaak. Whitelisten is meestal een schonere oplossing dan de bescherming volledig uitschakelen.

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.

Wilt u de botbescherming niet volledig uitschakelen, maak dan een Cloudflare WAF custom rule met actie Skip voor user agents die InspectWP bevatten.

4. Wordfence

Wordfence is de populairste WordPress-beveiligingsplug-in en blokkeert crawlers vaak zeer agressief. Zo gaat u ermee om:

• Wordfence → Tools → Live Traffic: zoek naar geblokkeerde verzoeken vanaf de InspectWP-IP's 195.201.17.43 en 46.224.183.125 en voeg ze toe onder Whitelisted IPs.
• 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 tijdelijk uitschakelen, of de InspectWP-user-agent toevoegen aan de whitelist van de plug-in.

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=BlockCountry

Voor 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 de InspectWP-IP's 195.201.17.43 en 46.224.183.125 te whitelisten. 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 whitelisting 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. Een korte whitelist van het InspectWP-server-IP lost het probleem op.

15. Checklist voor opnieuw crawlen

• ☐ Cloudflare Bot Fight Mode uit
• ☐ Wordfence-firewall in Learning Mode of InspectWP-IP gewhitelist
• ☐ Beveiligingsplug-in (Sucuri / Solid / AIOS) op een gematigde instelling
• ☐ InspectWP-IP's 195.201.17.43 en 46.224.183.125 toegevoegd aan plug-in-/hostingwhitelist
• ☐ 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!