Faut-il vraiment utiliser un scanner de vulnérabilités sur votre site web ?

Pourquoi Google évoque-t-il les scanners de vulnérabilités dans un contexte SEO ?

La sécurité technique fait partie des signaux que Google évalue pour le classement. Un site compromis peut se retrouver blacklisté, désindexé ou marqué comme dangereux dans les SERP. Les scanners de vulnérabilités automatisent la détection de failles (injections SQL, XSS, failles CSRF, dépendances obsolètes) avant qu'un attaquant ne les exploite.

Google ne dit pas que ces outils sont indispensables, mais leur utilisation proactive limite les risques de compromission sévère. Un site hacké génère souvent du spam, du cloaking malveillant ou des redirections vers des domaines pourris, ce qui détruit la confiance algorithmique et peut prendre des mois à récupérer.

Que signifie exactement « invasif » dans ce contexte ?

Un scanner de vulnérabilités fonctionne en injectant des requêtes malformées, en testant des payloads SQL, en forçant des uploads, en bombardant les formulaires avec des patterns d'attaque connus. Sur un serveur mal configuré, cela peut provoquer un crash Apache, saturer la mémoire PHP, ou déclencher des WAF (Web Application Firewall) qui bloquent ensuite l'IP du serveur lui-même.

Certains scanners testent les dénis de service (DoS) en mode agressif, ce qui peut rendre le site temporairement inaccessible. D'autres exploitent réellement les failles trouvées pour confirmer leur existence, ce qui peut corrompre la base de données ou altérer des fichiers. Google dit donc : ces outils sont utiles, mais ils ne sont pas sans risque opérationnel.

Quels types de scanners sont concernés ?

On parle ici d'outils comme OWASP ZAP, Burp Suite, Acunetix, Nessus, Qualys, ou des solutions SaaS comme Sucuri SiteCheck. Ces scanners vont au-delà d'un simple audit de surface : ils testent activement les injections, les débordements de buffer, les permissions mal configurées. Ce ne sont pas des outils SEO classiques comme Screaming Frog ou OnCrawl.

Google ne recommande pas une marque précise, mais sous-entend que tout scan actif doit être encadré. Un crawler SEO basique ne pose aucun problème. Un penetration test automatisé, lui, peut déclencher des alertes chez votre hébergeur ou bloquer votre IP si vous n'avez pas prévenu le support technique.

• Sauvegarder l'intégralité du site (fichiers + base de données) avant tout scan actif
• Privilégier les scans en mode passif ou surveillance continue plutôt que les tests d'intrusion agressifs
• Prévenir votre hébergeur ou CDN pour éviter un blocage IP automatique par leur firewall
• Tester d'abord sur un environnement de staging, jamais directement en production
• Vérifier que le scanner respecte le robots.txt et les rate limits de votre serveur

Cette recommandation est-elle alignée avec les pratiques terrain observées ?

Oui, et c'est même un conseil qui révèle une réalité peu discutée : Google pénalise durement les sites compromis, mais n'offre aucun outil de détection proactive dans Search Console pour anticiper les failles. Les webmasters découvrent souvent un hack après coup, quand le mal est fait et que le trafic organique s'est effondré. L'avertissement sur le caractère invasif est pertinent, car beaucoup de sites e-commerce ou WordPress mal optimisés crashent sous un scan Burp Suite en mode agressif.

Ce que Google ne dit pas : certains hébergeurs mutualisés interdisent explicitement les scans de sécurité dans leurs CGU. Lancer un Acunetix sur un Shared Hosting OVH peut entraîner une suspension de compte. La nuance terrain ? Toujours vérifier les contraintes contractuelles de votre infrastructure avant de scanner.

Quels sont les risques réels si on ignore cette précaution ?

Les cas documentés montrent trois scénarios récurrents. Premier cas : le scanner exploite une faille LFI (Local File Inclusion) et corrompt le .htaccess, ce qui provoque une erreur 500 générale. Deuxième cas : un test de charge DoS sature les workers PHP-FPM, le site devient inaccessible pendant 20 minutes, Google crawle à ce moment précis et interprète cela comme une instabilité chronique. Troisième cas : le WAF de Cloudflare ou Sucuri détecte les patterns d'attaque et bloque l'IP du serveur d'origine, créant une boucle de redirection infinie.

Sans sauvegarde, récupérer d'un incident de scan peut prendre des heures voire des jours. Le downtime prolongé impacte directement le crawl budget et peut déclencher une désindexation temporaire des pages critiques. Google ne suspend pas le crawl automatiquement quand vous faites un scan, il faut le déclarer manuellement dans Search Console via l'outil de suspension temporaire du crawl. [A vérifier] si cet outil fonctionne encore ou s'il a été retiré dans les dernières versions de GSC.

Dans quels cas cette recommandation ne s'applique-t-elle pas ?

Si vous utilisez des scanners passifs comme Lighthouse Security Audit, Google PageSpeed Insights, ou des outils de monitoring continu comme Detectify en mode observation, il n'y a aucun risque. Ces outils ne testent pas activement les failles, ils scannent les headers HTTP, les certificats SSL, les dépendances JS exposées. Pas de sauvegarde nécessaire dans ce cas.

De même, si vous travaillez sur un environnement de pré-production isolé avec une base de données clonée et des données anonymisées, vous pouvez tester tous les scans agressifs sans risque pour le site live. Le conseil de Google vise clairement les scans directs en production, ce qui reste malheureusement une pratique courante chez les petites structures qui n'ont qu'un seul environnement.

Que faut-il faire concrètement avant de lancer un scan ?

La sauvegarde complète est non négociable : fichiers via FTP/SFTP, base de données via phpMyAdmin ou mysqldump, configuration serveur (.htaccess, nginx.conf, php.ini). Stockez ces backups hors du serveur cible, idéalement sur un stockage cloud chiffré ou un disque local. Vérifiez que la sauvegarde est restaurable en testant une extraction sur un autre serveur.

Ensuite, configurez le scanner en mode « safe » ou « passive » pour le premier passage. La plupart des outils comme OWASP ZAP proposent un mode qui détecte sans exploiter. Analysez les résultats, corrigez les failles critiques, puis seulement après, lancez un scan actif pour confirmer les correctifs. Prévenez votre hébergeur 24h avant si vous utilisez un VPS ou un dédié, certains exigent une white-list IP pour les scans.

Quelles erreurs éviter absolument ?

Ne jamais scanner en production un vendredi soir ou avant un week-end prolongé. Si le site crashe, vous n'aurez personne pour intervenir rapidement. Évitez les scans pendant les pics de trafic : un scan Burp Suite peut générer 10 000 requêtes en quelques minutes, saturant un serveur déjà sous charge.

Autre erreur fréquente : lancer un scan sans avoir exclu les zones sensibles (paniers d'achat actifs, processus de paiement, webhooks tiers). Un scanner qui bombarde une API Stripe ou PayPal avec des payloads malformés peut déclencher un blocage permanent de votre compte marchand. Configurez toujours des exclusions explicites pour ces endpoints.

Comment vérifier que le scan n'a pas endommagé le site ?

Après le scan, testez manuellement les fonctionnalités critiques : connexion utilisateur, soumission de formulaires, processus de commande, moteur de recherche interne. Vérifiez les logs serveur (Apache error.log, PHP error.log) pour détecter des erreurs 500 ou des warnings inhabituels générés pendant le scan. Utilisez un outil de monitoring uptime comme UptimeRobot ou Pingdom pour confirmer que le site est resté accessible durant toute la durée du test.

Contrôlez également que le nombre de pages indexées dans Search Console n'a pas chuté brutalement dans les 48h suivant le scan. Si Google a crawlé pendant un crash temporaire, certaines URLs peuvent avoir été marquées comme erreur serveur. Un re-crawl via l'outil d'inspection d'URL permet de corriger rapidement ces statuts temporaires.

• Effectuer une sauvegarde complète (fichiers + BDD) et vérifier sa restaurabilité
• Configurer le scanner en mode passif pour le premier audit
• Exclure les endpoints sensibles (paiement, API tierces, webhooks)
• Prévenir l'hébergeur et demander une white-list IP si nécessaire
• Tester d'abord sur un environnement de staging avant la production
• Vérifier les logs serveur après le scan pour détecter des erreurs générées