Comment Google traite-t-il vraiment les demandes de révision après un piratage de site ?

Pourquoi Google impose-t-il un processus formalisé pour les sites piratés ?

Un site infecté par du malware, du phishing ou du spam injecté représente un danger direct pour les utilisateurs. Google pénalise ces sites en les déclassant massivement ou en affichant un avertissement rouge dans les SERPs.

La demande de révision via Search Console n'est pas une simple formalité administrative. Elle force le webmaster à documenter les corrections apportées et à prouver que la faille a été colmatée. Sans ce garde-fou, des sites infectés pourraient retrouver leur ranking en nettoyant superficiellement le contenu visible sans traiter la vulnérabilité sous-jacente.

Que se passe-t-il concrètement lors d'une révision de sécurité ?

L'équipe de sécurité de Google (Safe Browsing) vérifie manuellement ou via des crawls ciblés que les contenus malveillants ont disparu et que les backdoors ont été fermées. Le délai annoncé oscille entre quelques jours et plusieurs semaines, mais dans les faits, certains webmasters attendent un mois ou plus sans retour.

Si la révision est refusée, Google envoie un message générique pointant vers des ressources d'aide, rarement vers les fichiers infectés précis. C'est là que le recours aux forums d'aide Search Console devient nécessaire : des Product Experts bénévoles peuvent fournir un diagnostic plus fin, même si leur capacité d'action reste limitée.

Quels sont les pièges courants qui retardent la levée de la pénalité ?

Premier écueil : nettoyer les pages infectées sans traiter la vulnérabilité d'origine (plugin WordPress obsolète, identifiants FTP compromis, injection SQL non patchée). Google détecte souvent une réinfection dans les jours suivant la demande de révision, ce qui entraîne un refus automatique.

Deuxième piège : oublier les sous-domaines ou les répertoires secondaires infectés. Un seul fichier malveillant oublié dans /wp-includes/ ou sur un sous-domaine de staging suffit à maintenir la sanction. La révision doit couvrir l'intégralité du domaine et de ses variations accessibles publiquement.

• Passer par Search Console > Sécurité et actions manuelles pour soumettre la demande de révision
• Documenter précisément les actions correctives dans le formulaire (fichiers supprimés, plugins mis à jour, mots de passe changés)
• Vérifier les sous-domaines, répertoires cachés et fichiers temporaires avant de soumettre
• Si pas de réponse sous 10 jours, poster sur le forum d'aide Search Console avec l'URL et le numéro de demande
• Ne jamais supprimer un site de Search Console pendant une révision en cours, cela annule la demande

Cette procédure est-elle vraiment efficace pour protéger les utilisateurs ?

Sur le papier, oui. Forcer un passage manuel par Search Console évite que des sites infectés ne retrouvent leur visibilité par simple négligence. Mais dans la pratique, le processus souffre de manque de transparence : Google ne précise jamais quels fichiers posent problème, ni quel type de malware a été détecté.

Un webmaster peut nettoyer consciencieusement son site, soumettre une révision, recevoir un refus laconique, et se retrouver à fouiller manuellement des milliers de fichiers sans piste concrète. Les outils de détection de malware tiers (Sucuri, Wordfence, Maldet) deviennent alors indispensables, mais leur fiabilité varie. [À vérifier] : Google ne communique pas sur le taux de faux positifs de Safe Browsing, ni sur les critères précis de levée de sanction.

Le recours aux forums d'aide est-il réellement une solution d'escalade ?

Soyons honnêtes : les Product Experts des forums sont des bénévoles, pas des employés Google avec accès aux systèmes internes. Leur rôle se limite à orienter vers les ressources officielles, à suggérer des pistes de diagnostic, et parfois à remonter un cas bloqué aux équipes Google.

Dans la majorité des situations, un post sur le forum débouche sur des conseils génériques déjà trouvés dans la documentation. Les cas où un Product Expert obtient une intervention Google directe restent marginaux. Si la révision traîne au-delà de trois semaines sans retour, l'escalade via Twitter (@GoogleSearchC) ou les canaux de support payants peut s'avérer plus efficace, mais rien ne le garantit.

Quelles sont les failles de ce processus côté webmaster ?

Trop de webmasters soumettent une demande de révision avant d'avoir réellement corrigé la vulnérabilité. Ils nettoient les fichiers infectés visibles, changent le mot de passe admin WordPress, et considèrent le travail terminé. Résultat : réinfection sous 48 heures, refus de révision, et perte de plusieurs semaines supplémentaires.

Autre erreur fréquente : ne pas vérifier les redirections 301 malveillantes injectées dans le .htaccess ou les DNS, ni les scripts obfusqués dans les fichiers de thème. Un audit de sécurité digne de ce nom implique un scan complet du système de fichiers, une revue des logs serveur, et une vérification des accès FTP/SSH. Sans cette rigueur, la révision Google échouera systématiquement.

Que faut-il faire immédiatement après détection d'une infection ?

Première action : isoler le site en le mettant en mode maintenance ou en le mettant hors ligne temporairement, surtout s'il distribue du malware actif. Chaque heure supplémentaire d'infection aggrave la sanction Google et expose les visiteurs. Parallèlement, changer tous les mots de passe (FTP, SSH, base de données, panel d'hébergement, admin CMS).

Ensuite, lancer un scan complet avec des outils spécialisés (Wordfence pour WordPress, Maldet en ligne de commande, ou un service comme Sucuri). Ne te limite pas au répertoire public : vérifie les cron jobs, les fichiers de configuration, et les répertoires temporaires. Les backdoors se cachent souvent dans des fichiers au nom anodin (error_log.php, cache.php) ou dans des répertoires peu consultés.

Comment documenter efficacement une demande de révision ?

Google demande une description des actions correctives. Ne te contente pas d'un vague « site nettoyé ». Liste précisément : quels fichiers ont été supprimés ou restaurés, quels plugins/thèmes ont été mis à jour ou désinstallés, quelles failles ont été patchées (ex : « Injection SQL dans le plugin XYZ v2.1, mise à jour vers v2.3 »).

Mentionne aussi les mesures préventives : activation d'un firewall applicatif (Cloudflare, Sucuri), durcissement des permissions fichiers (chmod 644 pour les fichiers, 755 pour les dossiers), mise en place de sauvegardes automatiques quotidiennes. Plus tu montres que le site est désormais sécurisé de manière pérenne, plus la révision a de chances d'être acceptée rapidement.

Et si la révision est refusée ou reste sans réponse ?

Un refus signifie que Google détecte encore du contenu malveillant ou une vulnérabilité active. Retourne dans Search Console, section Problèmes de sécurité : Google liste parfois des exemples d'URLs infectées. Scanne ces URLs spécifiquement, ainsi que toutes les pages liées (redirections, iframes cachées).

Si aucun détail n'est fourni, poste sur le forum d'aide Search Console en incluant ton domaine, le numéro de demande de révision, et un résumé des actions entreprises. Un Product Expert pourra parfois identifier un angle mort. En parallèle, vérifie les logs serveur des dernières semaines pour repérer des requêtes suspectes ou des tentatives d'accès non autorisées.

Ces opérations peuvent vite devenir chronophages et techniques, surtout sur des infrastructures complexes ou des CMS personnalisés. Si tu manques de ressources internes pour mener un audit de sécurité complet, ou si les refus de révision s'accumulent sans explications claires, faire appel à une agence SEO spécialisée en sécurité web peut débloquer la situation rapidement. Une expertise externe permet souvent d'identifier des backdoors invisibles et d'optimiser la documentation de révision pour maximiser les chances d'acceptation.

• Isoler le site et changer tous les mots de passe dès détection de l'infection
• Effectuer un scan complet du système de fichiers, y compris répertoires cachés et sous-domaines
• Documenter précisément chaque action corrective dans la demande de révision Search Console
• Vérifier les redirections 301, .htaccess, DNS et scripts obfusqués
• Attendre 7-10 jours après soumission avant d'escalader vers le forum d'aide
• Ne jamais soumettre plusieurs révisions simultanées ni supprimer la propriété Search Console pendant la révision