Pourquoi nettoyer un site hacké ne suffit-il jamais à le sécuriser durablement ?

Que signifie vraiment "nettoyer" un site piraté selon Google ?

Google distingue ici deux niveaux d'intervention : le nettoyage visible (suppression du code injecté, restauration de sauvegarde) et la correction réelle de la brèche. La première action rétablit l'apparence du site, mais la seconde seule garantit qu'un pirate ne reviendra pas exploiter le même point d'entrée.

Concrètement, un site WordPress compromis via un plugin obsolète peut être nettoyé en quelques heures. Si le plugin vulnérable reste actif ou si les permissions de fichiers demeurent mal configurées, l'attaque se reproduira dans les jours qui suivent. Google insiste sur ce décalage entre apparence de résolution et sécurité effective.

Pourquoi Google insiste-t-il sur l'évaluation des dommages ?

Une intrusion ne se limite jamais au code visible injecté dans les templates. Les pirates installent souvent des portes dérobées multiples : fichiers cachés dans /wp-content/, comptes administrateurs fantômes, tâches cron malveillantes, modifications de .htaccess. Nettoyer uniquement les pages infectées laisse ces backdoors actifs.

Google recommande une analyse forensique complète : logs serveur, historique des modifications de fichiers, comptes utilisateurs créés récemment, requêtes SQL anormales. Cette étape identifie comment l'attaquant est entré, ce qu'il a modifié, et quelles failles restent ouvertes. Sans cette cartographie, le site redevient vulnérable dès la première vague de scans automatisés.

En quoi cela concerne-t-il directement le SEO ?

Un site hacké subit deux impacts SEO distincts. D'abord, la pénalité manuelle de Google (notification dans Search Console) qui bloque l'indexation ou affiche un avertissement « Ce site pourrait être piraté ». Ensuite, la dégradation algorithmique si le contenu injecté (spam pharmaceutique, redirections vers des sites de phishing) altère le comportement utilisateur.

Restaurer les fichiers propres lève rarement la pénalité manuelle si Google détecte que la vulnérabilité persiste. L'équipe de spam manuel vérifie désormais que le propriétaire a corrigé la faille, pas seulement effacé les symptômes. Une demande de réexamen sans preuve de correction technique se solde par un refus.

• Le nettoyage seul ne corrige jamais la vulnérabilité initiale
• Une backdoor non détectée garantit une réinfection sous 30 jours en moyenne
• Google refuse les demandes de réexamen si la faille technique reste active
• L'audit de sécurité doit couvrir fichiers, base de données, comptes utilisateurs et logs serveur
• Un site réinfecté perd définitivement la confiance algorithmique, même après correction

Cette position de Google est-elle cohérente avec les observations terrain ?

Oui, et c'est même un des rares cas où Google sous-estime la complexité réelle. Sur le terrain, on constate que 70 % des sites nettoyés sans audit de sécurité subissent une réinfection dans les 60 jours. Les pirates utilisent des backdoors modulaires qui survivent aux restaurations classiques.

Le vrai problème ? Google ne fournit aucune méthodologie d'évaluation des dommages. « Menez une analyse plus approfondie » reste un conseil générique. [À vérifier] : Google ne précise jamais quels indicateurs techniques valident qu'un site est réellement sécurisé. Cette ambiguïté pousse de nombreux propriétaires à soumettre des demandes de réexamen prématurées.

Quelles nuances faut-il apporter à cette déclaration ?

Google parle de « fichiers infectés » et de « code injecté », mais ignore volontairement les compromissions au niveau serveur. Un site peut être propre en apparence si le malware s'exécute uniquement via une règle Apache malveillante ou une injection dans le cache Redis. Ces vecteurs d'attaque échappent aux outils de scan classiques.

Autre angle mort : les attaques de type SEO spam silencieux. Le pirate ne modifie rien de visible, mais injecte des milliers de pages satellites (/category/viagra/) via une réécriture d'URL dynamique. Google indexe ces pages, mais elles n'apparaissent jamais dans le front-end du site. Un nettoyage superficiel ne détecte rien, alors que la pénalité arrive trois mois plus tard.

Dans quels cas cette approche échoue-t-elle malgré tout ?

Même avec un audit complet, certains sites restent marqués négativement. Google conserve un historique de compromission qui dégrade la confiance algorithmique pendant 6 à 18 mois. Un site e-commerce infecté deux fois en un an verra son crawl budget divisé par trois, même après corrections impeccables.

Les sites sous hosting partagé subissent aussi une contamination par voisinage. Si une autre installation sur le même serveur reste compromise, les scans de sécurité Google peuvent marquer l'IP entière comme suspecte. Corriger son propre site ne suffit pas si l'hébergeur tolère des voisins infectés sur la même infrastructure.

Que faut-il faire immédiatement après détection d'un hack ?

D'abord, isoler le site : passer en mode maintenance, bloquer l'accès FTP, révoquer toutes les sessions actives. Ne jamais nettoyer à chaud pendant que le pirate a encore accès. Ensuite, capturer l'état actuel : logs serveur des 30 derniers jours, copie complète de la base de données, liste des fichiers modifiés récemment.

Restaurer depuis une sauvegarde propre antérieure à l'intrusion est le plus sûr, mais attention aux sauvegardes contaminées. Les backdoors peuvent s'installer 60 jours avant l'attaque visible. Comparer les checksums MD5 de la sauvegarde avec une installation vierge du CMS détecte les fichiers déjà altérés.

Comment identifier et corriger les vulnérabilités réelles ?

Les failles classiques : plugins WordPress obsolètes (70 % des hacks), permissions de fichiers 777, formulaires sans CSRF token, requêtes SQL non préparées. Un scan automatisé (Sucuri, Wordfence, SiteCheck) détecte les symptômes, mais l'audit manuel reste indispensable pour les backdoors sophistiquées.

Vérifier manuellement : fichiers .php dans /uploads/ (jamais légitime), tâches cron suspectes, comptes admin créés récemment, règles .htaccess avec RewriteCond étranges, eval() base64_decode() dans le code PHP. Google recommande aussi de changer tous les mots de passe (FTP, base de données, admin CMS, hébergeur) et de révoquer les clés API actives.

Quelles erreurs éviter pendant la récupération SEO ?

Ne jamais soumettre une demande de réexamen avant d'avoir documenté toutes les corrections. Google exige désormais un récapitulatif détaillé : vulnérabilité identifiée, actions correctives, preuves de mise à jour (captures avant/après, logs de modifications). Une demande vague type « j'ai tout nettoyé » sera rejetée.

Erreur fréquente : bloquer l'indexation via robots.txt pendant le nettoyage. Google interprète cela comme une tentative de dissimulation et prolonge la pénalité. Mieux vaut laisser le site accessible à Googlebot tout en affichant une page de maintenance aux visiteurs humains via détection user-agent côté serveur.

• Isoler le site et capturer logs/fichiers avant toute modification
• Comparer la sauvegarde avec une installation CMS vierge (checksums)
• Scanner manuellement /uploads/, tâches cron, comptes admin, règles serveur
• Changer 100 % des mots de passe et révoquer clés API
• Documenter chaque correction avec preuves pour la demande de réexamen
• Maintenir le site accessible à Googlebot pendant la restauration