Comment récupérer un site hacké sans perdre son référencement ?

Pourquoi Google impose-t-il un ordre précis dans la récupération ?

La logique derrière cette séquence n'a rien d'arbitraire. Google refuse catégoriquement de réexaminer un site tant que la preuve de propriété n'est pas établie via Search Console. Sans cette vérification, n'importe qui pourrait demander la levée d'une sanction sur n'importe quel domaine.

Le timing compte énormément. Remettre en ligne un site avant d'avoir colmaté la brèche de sécurité, c'est garantir un nouveau piratage sous 48h. Les bots malveillants scannent en permanence les sites fraîchement nettoyés pour vérifier si la vulnérabilité persiste. Un site réinfecté perd toute crédibilité aux yeux de Google, et la procédure de réhabilitation devient alors trois fois plus longue.

Que signifie réellement « nettoyé du vandalisme » ?

Le nettoyage superficiel ne suffit jamais. Les hackers plantent généralement plusieurs backdoors : fichiers PHP cachés dans /wp-content/uploads/, code obfusqué dans functions.php, comptes administrateurs fantômes, tâches cron malveillantes. Supprimer les pages de spam visibles sans traquer ces points d'entrée secondaires garantit une réinfection rapide.

Concrètement, ça implique un diff complet entre votre installation et une version propre du CMS. Chaque fichier modifié doit être inspecté manuellement, pas juste restauré depuis une sauvegarde potentiellement déjà compromise. Les bases de données WordPress, par exemple, contiennent souvent du code malveillant injecté dans les champs post_content ou dans des tables custom créées par le hacker.

Quel est le vrai risque si on zappe une étape ?

Google détecte instantanément les raccourcis. Demander une réexamen avec des traces de hack encore présentes rallonge le délai de traitement de 3 à 6 semaines minimum. L'équipe de sécurité Google rejette la demande avec un message laconique, et votre site reste blacklisté.

Pire : un site partiellement nettoyé continue d'infecter les visiteurs pendant ce temps. Si Search Console détecte du malware résiduel après votre demande de réexamen, Google peut durcir la sanction et passer le domaine en liste noire étendue, affichant alors des avertissements rouges dans Chrome pour tous les utilisateurs. La remontée devient alors un cauchemar de plusieurs mois.

• Vérification de propriété obligatoire dans Search Console avant toute démarche
• Nettoyage exhaustif incluant fichiers, base de données, comptes utilisateurs et tâches planifiées
• Correction impérative de la faille exploitée initialement (plugin obsolète, permissions 777, mot de passe faible)
• Tests de sécurité post-nettoyage avec scanners professionnels type Sucuri ou Wordfence avant remise en ligne
• Documentation du processus pour la demande de réexamen (captures, logs, actions correctives)

Cette procédure est-elle cohérente avec ce qu'on observe sur le terrain ?

Totalement. Les cas de réhabilitation échouée suivent tous le même pattern : un webmaster pressé qui demande un réexamen 24h après avoir supprimé les pages de spam visibles, sans avoir identifié le vecteur d'attaque initial. Google rejette systématiquement ces demandes.

Ce qui surprend davantage, c'est la rigueur absolue de l'équipe de sécurité lors du réexamen. Ils ne se contentent pas de vérifier la homepage. Leurs bots crawlent en profondeur, inspectent les sous-répertoires, analysent les en-têtes HTTP, testent les formulaires. Un seul fichier PHP malveillant oublié dans /cache/ suffit à bloquer la réhabilitation. Aucune tolérance.

Où Google reste-t-il flou dans cette déclaration ?

Le terme « remis en ligne propre » manque cruellement de définition opérationnelle. Propre selon quels critères exactement ? Absence de malware détecté par Safe Browsing ? Validation par un scanner externe ? Conformité avec des checksums officiels du CMS ? Google ne le précise jamais clairement.

Autre zone grise : le délai entre nettoyage et demande de réexamen. Certains experts recommandent d'attendre 48-72h après la remise en ligne pour laisser Google recrawler naturellement le site nettoyé. D'autres préconisent une demande immédiate. [A vérifier] — Google ne communique aucune best practice officielle sur ce timing, et les retours terrain varient énormément selon les cas.

Quels pièges échappent à cette checklist officielle ?

La restauration depuis sauvegarde pose souvent problème. Beaucoup de webmasters restaurent une backup d'il y a 3 semaines, pensant revenir à un état propre. Sauf que le hack remonte parfois à 6 mois, la backdoor dormant sans activité visible jusqu'à activation récente. La sauvegarde restaurée contient donc le point d'entrée initial.

Autre écueil classique : les CDN et caches intermédiaires. Vous nettoyez votre serveur, mais Cloudflare ou votre reverse proxy continue de servir les pages hackées en cache pendant 24-48h. Google crawle ces versions cached, détecte du spam, et rejette la demande de réexamen alors que votre serveur origin est parfaitement propre. Il faut purger agressivement tous les caches avant de demander le réexamen.

Que faut-il faire concrètement avant toute demande de réexamen ?

Commencez par documenter l'incident méthodiquement. Capturez des screenshots de Search Console montrant les alertes de sécurité initiales. Notez la date de détection, le type d'attaque identifié (injection SQL, pharma hack, malware, etc.), et l'ampleur du compromis (nombre de pages affectées). Cette documentation servira lors de la demande formelle.

Ensuite, isolez complètement le site : passez-le en mode maintenance, bloquez l'indexation via robots.txt temporaire, et travaillez sur une copie locale ou un environnement de staging. Analyser un site hacké en production pendant qu'il continue d'être crawlé aggrave les dégâts. Pendant ce blackout, effectuez un scan forensique complet avec plusieurs outils (Sucuri SiteCheck, VirusTotal, Quttera) pour identifier tous les fichiers modifiés.

Comment s'assurer que la vulnérabilité est vraiment corrigée ?

Identifier le vecteur d'attaque prime sur tout le reste. 80% des hacks WordPress proviennent de plugins obsolètes ou de thèmes nulled. Vérifiez les logs d'accès Apache/Nginx pour repérer les requêtes suspectes juste avant la compromission initiale. Cherchez des patterns type /wp-content/plugins/old-plugin/upload.php ou des POST inhabituels.

Une fois le point d'entrée identifié, la correction doit être radicale : suppression complète du plugin vulnérable (pas juste une mise à jour), rotation de tous les mots de passe (admin, FTP, BDD, hébergeur), révocation des clés API tierces potentiellement exfiltrées, et durcissement des permissions fichiers (644 pour les .php, 755 pour les dossiers, jamais 777). Installez ensuite un WAF type Sucuri ou Cloudflare pour bloquer les tentatives de réexploitation de la même faille.

Quelle est la bonne séquence pour la remise en ligne ?

Ne réactivez jamais l'indexation avant validation complète. Remettez le site en ligne avec un robots.txt bloquant tous les bots (User-agent: * / Disallow: /), puis lancez un dernier scan de sécurité 24h après. Si tout est propre, soumettez la demande de réexamen dans Search Console avec une description détaillée des actions correctives, puis seulement après réactivez le robots.txt normal.

Le timing de réindexation compte énormément. Utilisez l'outil Inspection d'URL pour forcer le crawl des pages stratégiques une fois le site validé propre. Soumettez un sitemap XML fraîchement généré. Surveillez quotidiennement les rapports de sécurité Search Console pendant 2 semaines minimum. Un hack résiduel se manifeste généralement sous 5-7 jours si le nettoyage était incomplet.

Ces opérations techniques demandent une expertise pointue en sécurité web et en SEO. Un nettoyage bâclé peut détruire des années de référencement en quelques jours. Si vous manquez de ressources internes ou d'expérience sur ce type de crise, faire appel à une agence SEO spécialisée en récupération de sites hackés peut faire la différence entre une remontée rapide et des mois de galère. Les professionnels disposent d'outils forensiques avancés et connaissent les subtilités des procédures de réexamen Google.

• Vérifier et sécuriser l'accès Search Console (rotation des identifiants)
• Scanner exhaustivement fichiers ET base de données avec minimum 3 outils différents
• Comparer les fichiers modifiés avec une installation propre du CMS via diff
• Corriger la vulnérabilité initiale (mise à jour, suppression, patch de sécurité)
• Purger tous les caches (serveur, CDN, proxy) avant remise en ligne
• Documenter chaque action corrective pour la demande de réexamen
• Surveiller les rapports Search Console quotidiennement pendant 15 jours post-réhabilitation