Should you really use a vulnerability scanner on your website?

Why does Google mention vulnerability scanners in an SEO context?

Technical security is part of the signals that Google evaluates for ranking. A compromised site can end up blacklisted, de-indexed, or marked as dangerous in search results. Vulnerability scanners automate the detection of flaws (SQL injections, XSS, CSRF vulnerabilities, outdated dependencies) before an attacker can exploit them.

Google does not state that these tools are essential, but their proactive use limits the risk of severe compromise. A hacked site often generates spam, malicious cloaking, or redirects to harmful domains, which destroys algorithmic trust and can take months to recover from.

What does

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