Que faire quand le crawl échoue, désactiver temporairement les mécanismes de sécurité

Si votre crawl InspectWP échoue, renvoie un rapport vide ou n'analyse visiblement qu'une page de défi, des mécanismes de sécurité sur le site cible en sont presque toujours la cause. Ce guide vous accompagne à travers chaque obstacle courant, de Cloudflare à Wordfence en passant par .htaccess, et montre comment les désactiver pendant la durée d'un crawl ou mettre InspectWP en liste blanche.

1. Pourquoi les crawls échouent

Symptômes typiques indiquant qu'une barrière de sécurité fait obstacle :

• Délai d'attente / crawl interrompu : Le site ne répond pas, ou seulement après plus de 30 secondes.
• Rapport vide ou presque vide : Aucun titre, aucun plugin, aucun thème détecté, le plus souvent une page de défi ou de blocage a été analysée.
• HTTP 403 / 429 / 503 : Un pare-feu a rejeté la requête ou la limite de débit a été déclenchée.
• Mauvais contenu : La capture d'écran montre une page de vérification Cloudflare, une page de blocage Wordfence, un écran „bientôt disponible“ ou un formulaire de connexion au lieu de votre vrai site web.

2. Avant de commencer

InspectWP utilise un véritable navigateur Chrome headless et ne se déguise pas en bot de moteur de recherche. Le user agent contient le marqueur InspectWP. Cela signifie : si vous bloquez généralement les bots, vous bloquerez aussi InspectWP, et c'est la cause racine réelle. Mettre en liste blanche est généralement une solution plus propre que de désactiver entièrement la protection.

3. Cloudflare

Cloudflare est la raison la plus fréquente d'échec de crawl. Connectez-vous au tableau de bord Cloudflare et vérifiez :

• Security → Bots : Réglez Bot Fight Mode et Super Bot Fight Mode sur Off.
• Security → Settings : Réglez temporairement Security Level sur Essentially Off ou Low.
• Security → WAF → Tools : Assurez-vous que Under Attack Mode est désactivé (utilisez High ou inférieur).
• Custom Rules : Si vous avez vos propres règles WAF, vérifiez si l'une d'elles bloque les user agents ou les IP.

Si vous ne voulez pas désactiver entièrement la protection contre les bots, créez une règle personnalisée WAF Cloudflare avec l'action Skip pour les user agents contenant InspectWP.

4. Wordfence

Wordfence est le plugin de sécurité WordPress le plus populaire et bloque souvent les crawlers de manière très agressive. Voici comment le gérer :

• Wordfence → Tools → Live Traffic : Recherchez les requêtes bloquées provenant des IP InspectWP 195.201.17.43 et 46.224.183.125 et ajoutez-les sous Whitelisted IPs.
• Wordfence → Firewall → All Firewall Options : Mettez brièvement le pare-feu en Learning Mode ou Disabled.
• Rate Limiting : Augmentez significativement les seuils pour „How many page views can a crawler visit per minute“.
• Block fake Google crawlers : Cette option peut bloquer InspectWP, désactivez-la temporairement.

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

D'autres plugins de sécurité bien connus utilisent des mécanismes très similaires. Recherchez spécifiquement :

• Protection contre les attaques par force brute / détection 404
• Limitation de débit pour les user agents inconnus
• Listes de blocage proposées / recommandées
• Blocage par pays

Désactivez la fonctionnalité concernée ou augmentez temporairement les seuils.

6. Limit Login Attempts / Loginizer

Ces plugins bloquent les IP après des échecs de connexion. InspectWP ne tente jamais de se connecter, mais : si votre serveur vient d'enregistrer d'autres échecs de connexion depuis la plage IP du crawl, l'IP peut déjà être bannie. Vérifiez la liste de blocage du plugin et supprimez l'entrée si nécessaire.

7. Plugins anti-bot et anti-spam

CleanTalk, Blackhole for Bad Bots, StopBadBots et compagnie fonctionnent par heuristique et bloquent tout user agent inhabituel. La seule solution : les désactiver brièvement, ou ajouter le user agent InspectWP à la liste blanche du plugin.

8. Plugins „bientôt disponible“ et de maintenance

Des plugins comme SeedProd, WP Maintenance Mode, Elementor Coming Soon ou WP Maintenance affichent une page de remplacement aux visiteurs externes. InspectWP analyse alors cette page de remplacement, pas votre vrai site. Les liens de contournement proposés par certains plugins ne fonctionnent généralement pas pour les crawls externes. Solution : désactivez brièvement le plugin, lancez le crawl, réactivez le plugin.

9. Plugins de cache et d'optimisation

WP Rocket, LiteSpeed Cache, W3 Total Cache et outils similaires peuvent produire des résultats de crawl étranges quand une optimisation agressive est activée, par exemple lorsque le JavaScript est différé ou combiné. Recommandations :

• Videz le cache avant le crawl
• Gardez „Bot Cache“ / „Cache for logged-out users“ activés, sinon InspectWP pourrait voir une version périmée
• Vérifiez les options JavaScript-Delay / lazy-render, InspectWP attend bien l'interaction, mais des délais extrêmes provoquent des dépassements de délai

10. Protection par mot de passe, réservé aux membres, contenu restreint

Une page accessible uniquement aux utilisateurs connectés ou derrière une authentification HTTP basique ne peut pas être analysée par InspectWP. Assurez-vous que l'URL que vous voulez analyser est accessible publiquement sans connexion. Désactivez brièvement les plugins comme Restrict Content Pro, MemberPress ou Password Protected, ou rendez la page cible publique.

11. .htaccess et nginx, blocages d'IP, de pays et de user-agent

Au niveau serveur, les crawlers sont souvent bloqués via Deny ou RewriteRule. Exemples typiques de fichiers .htaccess que vous pouvez commenter temporairement :

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

# Blocage IP
Deny from 1.2.3.4

# Blocage par pays via mod_geoip
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountry

Pour nginx, l'équivalent ressemble à :

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

Commentez ces lignes pendant la durée du crawl.

12. Mécanismes de protection côté hébergement

Certains hébergeurs exécutent leur propre Web Application Firewall (WAF) ou règles ModSecurity que vous ne verrez pas dans l'audit du plugin ou du .htaccess. Demandez à leur support de mettre en liste blanche les IP InspectWP 195.201.17.43 et 46.224.183.125. Exemples connus :

• All-Inkl, IONOS, Strato : Protection anti-bot dans le panneau d'hébergement, contactez le support ou désactivez depuis le menu client.
• SiteGround : Anti-bot IA, Smart-WAF, sous Site Tools → Security.
• Kinsta, WP Engine : Détection de bot propriétaire, demandez la mise en liste blanche via le support.
• Hetzner / fournisseurs cloud : Rarement des problèmes WAF, mais des restrictions GeoIP sont possibles.

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

Pour clarifier : un robots.txt avec Disallow: / n'empêche pas InspectWP de crawler, nous ne respectons pas strictement robots.txt. Content-Security-Policy et X-Frame-Options en revanche peuvent empêcher des sous-requêtes individuelles (iframes, scripts tiers) ; c'est normal et ce n'est pas une erreur. Les bloqueurs qui comptent vraiment sont les réponses 403/429/503 sur le document principal.

14. Limitation de débit et Fail2Ban

Au niveau serveur, fail2ban, mod_evasive ou nginx limit_req peuvent bannir l'IP du crawl en quelques secondes, surtout avec de nombreuses sous-requêtes parallèles. Si vous avez un accès SSH, vérifiez /var/log/fail2ban.log ou iptables -L. Une mise en liste blanche à court terme de l'IP du serveur InspectWP résout le problème.

15. Liste de contrôle avant un nouveau crawl

• ☐ Cloudflare Bot Fight Mode désactivé
• ☐ Pare-feu Wordfence en Learning Mode ou IP InspectWP en liste blanche
• ☐ Plugin de sécurité (Sucuri / Solid / AIOS) sur un réglage modéré
• ☐ IP InspectWP 195.201.17.43 et 46.224.183.125 ajoutées à la liste blanche du plugin/hébergeur
• ☐ Plugin „bientôt disponible“ / maintenance désactivé
• ☐ Cache du plugin de cache vidé
• ☐ .htaccess / nginx vérifiés pour les blocages user-agent/IP
• ☐ Panneau d'hébergement : protection anti-bot / WAF examinés
• ☐ La page est accessible publiquement sans connexion
• ☐ Cache du navigateur vidé et nouveau crawl de test lancé

16. Quand rien ne marche

Envoyez-nous un e-mail à hello@inspectwp.com avec le domaine et l'heure approximative du crawl raté.

Après un crawl réussi, n'oubliez pas de réactiver tous les mécanismes de sécurité !