Quand un site WordPress se fait infecter, le plus frustrant n’est pas seulement la suppression du code malveillant. C’est l’après, quand vous réalisez que la réparation doit être prouvable. Google Search Console vous le force d’une façon très concrète, via la requête de réexamen. On ne vous demande pas d’être “convaincant”, on vous demande d’être clair, complet, et de montrer que vous avez compris ce qui s’est passé, puis que vous avez gardewp.fr réellement réparé.
J’ai vécu plusieurs retours de requêtes où tout semblait “réglé” côté technique, mais où le dossier de réexamen restait trop vague: pas de traces d’investigation, pas de chronologie, ou des actions décrites sans détails. Résultat, la demande est rejetée ou laissée sans amélioration pendant des jours, parfois plus. À l’inverse, lorsque le dossier est structuré avec des preuves et une chronologie, même si tout n’est jamais parfait, la lecture est plus simple.
Cet article explique comment nettoyer un site WordPress infecté, mais surtout comment préparer le dossier à fournir à Google Search Console. L’objectif est de transformer un travail parfois confus en un récit vérifiable, utile à la fois pour Google et pour vous-même.
Comprendre ce que Google attend dans une requête de réexamen
Google n’évalue pas votre motivation, il évalue votre correction. Et il le fait à partir d’indices. Certains sont visibles via les signaux “site infecté”, “problèmes de sécurité” ou d’autres alertes dans Search Console. D’autres sont moins visibles, mais ils se devinent par la nature des URL, des pages contaminées, et des patterns observés.
Dans une requête de réexamen, vous devez couvrir trois choses, de façon intelligible:
1) Ce que vous pensez être la cause (ou au moins la famille d’incidents)
2) Ce que vous avez fait pour supprimer l’infection (pas seulement “j’ai nettoyé”, mais comment et quoi) 3) Comment vous évitez que ça revienne (mesures de durcissement et surveillance)Le piège classique, c’est de décrire des actions “générales” sans preuves concrètes: mise à jour “des plugins” sans préciser lesquels, réinstallation “de WordPress” sans mentionner les fichiers rétablis depuis une source fiable, ou suppression “du code” sans préciser où il se trouvait (thème, plugin, fichier PHP atypique, base de données, variables dans wp-config.php, cron, etc.).
La bonne nouvelle, c’est que vous n’avez pas besoin d’écrire une thèse. Vous avez besoin d’un dossier qui ressemble à un rapport d’incident bien tenu.
Étape 1: stabiliser le site avant toute déclaration
Avant même de préparer le moindre texte pour Search Console, stabilisez. Parce que si votre site continue de propager du contenu ou si des scripts malveillants tournent encore, la requête sera au mieux prématurée, au pire inutile.
Dans la pratique, la stabilisation veut dire: arrêter les mécanismes qui peuvent réinfecter ou servir du code. Selon la situation, ça peut inclure la mise en quarantaine d’un thème ou d’un plugin suspect, la désactivation temporaire de l’exécution de certains fichiers, ou la mise hors ligne partielle si le risque est élevé.
Il y a un compromis à garder en tête. Mettre le site totalement hors ligne peut vous aider à couper le flux, mais si vous rendez l’accès impossible, vous perdez une partie de vos moyens de vérification (tests, scans sur pages, vérification de redirections). Par expérience, une approche “réduction du risque + capacité de vérifier” marche souvent mieux qu’un blackout total, sauf urgence évidente.
Si vous avez un accès FTP/SFTP et à la base de données, la meilleure discipline est simple: commencez par collecter, pendant que vous pouvez encore observer.
Collecter les éléments d’enquête (ce qui rend le dossier crédible)
Un dossier de réexamen robuste ne repose pas uniquement sur ce que vous avez fait, il repose aussi sur ce que vous avez trouvé. Même si vos analyses ne sont pas “parfaites” au sens médico-légal, elles doivent être suffisamment précises pour guider la décision.
Sur WordPress, l’infection se manifeste souvent à plusieurs endroits: fichiers PHP modifiés dans des thèmes ou plugins, ajouts dans des fichiers qui ne devraient pas exister (ou qui contiennent du code obfusqué), modifications dans wp-config.php, comptes administrateurs ajoutés, cron manipulé, scripts insérés dans la base de données (options, posts, ou transients), ou redirections pilotées depuis des pages précises.
Pour constituer votre dossier, gardez une trace de:
- La date et l’heure approximatives de début d’incident (celle où vous avez remarqué l’alerte, ou celle où vous avez identifié les premiers symptômes). Les indices observés: pages touchées, comportement (redirection, ajout de contenu, téléchargement), traces de scripts. Les fichiers et entrées de base de données suspectés, avec leurs chemins exacts. Les preuves “avant/après” quand c’est possible: captures de fichiers, empreintes de fichiers si vous les calculez, ou au moins un relevé d’emplacements.
Concrètement, je conseille de créer un dossier interne de travail (sur votre ordinateur) avec une structure simple: “01-infos”, “02-analyse”, “03-suppression”, “04-tests”, “05-preuves”. Pas besoin d’un système complexe, juste une logique que vous pourrez parcourir rapidement quand vous écrirez le texte pour Google.
Nettoyer un site WordPress infecté: stratégie pratique sans se tromper de cible
Nettoyer un site WordPress infecté, ce n’est pas “supprimer ce que l’on voit”. C’est s’assurer que la source de l’infection a disparu. Dans les faits, ça veut souvent dire une combinaison de restaurations propres, de suppression des modifications, et de vérifications sur la base de données.
Voici une approche qui, dans de nombreux cas, évite les retours en arrière.
Restaurer le “connu fiable” (et pas seulement corriger à la main)
WordPress lui-même, les thèmes, et les plugins proviennent idéalement de sources fiables. Quand un environnement est compromis, corriger fichier par fichier peut marcher, mais c’est long et fragile. Parfois, vous finissez par rater un détail, ou un fichier secondaire modifié reste actif.
Restaurer depuis une base saine est souvent plus rationnel: réinstaller WordPress depuis la version officielle correspondant à votre installation, puis réinstaller les thèmes et plugins depuis leurs paquets officiels (ou des sources internes fiables si vous développez). Le point délicat est évidemment la configuration et le contenu, mais ça se gère.
Le piège fréquent, c’est de réinstaller “presque tout” sans retoucher les éléments qui contiennent les déclencheurs. Par exemple, un plugin malveillant peut être supprimé, mais la base de données conserve des options injectées, ou un cron modifié continue d’appeler un script.
Donc, même si vous restaurez des dossiers, vous devez aussi traiter base de données, comptes, planificateurs et fichiers d’amorçage.
Faire une chasse guidée sur les zones d’attaque typiques
Sur WordPress, les infections aiment certains endroits. Je ne vais pas promettre que ce sont toujours les mêmes, mais dans la plupart des incidents récurrents, vous retrouvez des schémas proches.
Attaque via fichiers, par exemple:
- un fichier PHP supplémentaire ou modifié dans un thème ou un plugin du code obfusqué dans un fichier “pas fait pour ça” des appels à des URL externes des fonctions qui déclenchent des redirections conditionnelles
Attaque via base de données:
- ajout de contenu ou de pages “fantômes” modification d’options, injections dans des champs inattendus comptes utilisateurs ajoutés, ou rôles escaladés transients manipulés, ou planification d’actions
Attaque via l’exécution:
- wp-cron compromis tâches planifiées ajoutées ressources qui reviennent parce qu’un mécanisme de réinfection reste actif
Votre nettoyage doit donc inclure une phase de vérification après chaque action importante, pas uniquement à la fin.
Sécuriser les accès avant de rouvrir le site au trafic
Un incident de sécurité sur WordPress commence rarement par “le code malveillant apparaît par magie”. Il y a presque toujours un vecteur: mots de passe faibles, plugin vulnérable, mauvaise gestion d’accès, configuration trop ouverte (administration accessible, upload libre, permissions risquées), ou faiblesse côté serveur.
Après nettoyage, vous devez changer la logique de confiance:
- mots de passe admin réinitialisés sessions invalidées clés et sels WordPress renouvelés si vous avez un doute vérification des comptes “nouveaux” et suppression de tout utilisateur non attendu durcissement de l’accès à la partie administration
Je sais que ça peut sembler “hors de la requête de réexamen”, mais Google cherche aussi des signaux de prévention. Un site nettoyé mais laissé en conditions identiques est un site qui peut se réinfecter. Et l’absence de mesures de durcissement dans votre dossier décrédibilise souvent la demande.
Constituer la chronologie de votre incident (le cœur du dossier)
Quand vous écrivez à Google, la chronologie est votre meilleur allié. Même si vous n’avez pas l’heure exacte de chaque micro-étape, vous pouvez utiliser des fenêtres de temps réalistes, et relier les actions au diagnostic.
Une chronologie bien faite répond à une question implicite: “Est-ce que vous avez réagi comme il faut, et est-ce que vous avez vérifié après correction?”
Par exemple, vous pouvez présenter votre récit sous forme de paragraphes datés, ou de phrases successives, mais gardez une structure lisible. Mentionnez:
- la date où l’alerte a été observée dans Search Console (ou la date de découverte) les premières actions de stabilisation la période d’analyse (ce que vous avez inspecté) la période de suppression (quoi exactement) les tests effectués juste après la remise en ligne ou le retour normal du service
Évitez les formulations “nous avons nettoyé et tout est ok” sans mention de tests. Même des tests simples, documentés, sont utiles.
Rassembler les preuves techniques sans noyer Google
Il y a une tentation naturelle: envoyer trop de détails. Google ne veut pas forcément un inventaire exhaustif de chaque fichier. Par contre, il veut assez d’éléments pour comprendre que votre correction n’est pas cosmétique.
Les preuves utiles sont souvent celles-ci:
- liste des composants supprimés ou restaurés (thèmes, plugins, fichiers spécifiques) mention du remplacement de certains fichiers par des versions d’origine description des changements appliqués à la base de données (à un niveau raisonnable) informations sur les nouveaux mots de passe et la suppression des comptes non reconnus détails de la validation post-nettoyage (pages testées, scans réalisés, vérifications de redirections)
Vous pouvez aussi fournir des extraits de logs si vous en avez, mais uniquement si vous pouvez les interpréter. Un log brut non annoté n’aide pas toujours. Si vous l’incluez, expliquez ce que vous y avez observé, sinon ça reste un bruit.
Je recommande aussi d’écrire les noms des plugins ou thèmes concernés uniquement si vous les connaissez avec certitude. Si vous n’êtes pas sûr, dites-le. Un doute formulé honnêtement vaut mieux qu’un accusé trop précis qui s’avérerait faux.
Préparer une demande de réexamen dans Google Search Console
Dans Search Console, la requête de réexamen se nourrit de votre description. Selon les alertes, le formulaire peut varier, mais l’esprit reste le même.
Votre texte doit être factuel, et il doit montrer un fil conducteur. Voici la méthode qui fonctionne le mieux, sans se transformer en exercice de style.
Décrire l’impact et le diagnostic
Commencez par dire ce que vous avez vu. Par exemple, “des pages ont été modifiées, entraînant des redirections vers des URL inconnues” ou “un contenu inapproprié a été injecté dans des pages”, selon vos observations.
Ensuite, expliquez le diagnostic que vous avez retenu. Ne vous forcez pas à un scénario “parfait” si vous n’avez pas toutes les pièces. Sur WordPress, vous pouvez souvent dire “infection via modifications de fichiers dans X” et “persistance via réglages en base”, si c’est ce que vous avez confirmé.
Expliquer les actions de correction
Cette partie doit être la plus concrète. Sans entrer dans des détails ultra techniques, donnez assez d’éléments pour que Google comprenne ce que vous avez réellement enlevé.
C’est ici que vous mentionnez une logique du type: restauration des fichiers à partir de versions officielles, suppression des composants compromis, purge des modifications en base, suppression des utilisateurs créés, désactivation de planificateurs modifiés, puis remise en ligne après validation.
Si vous utilisez une phrase, ajoutez une précision. “Nous avons supprimé le code malveillant” devient “nous avons restauré les fichiers des thèmes et plugins concernés depuis des versions propres, puis supprimé les entrées identifiées dans la base de données”.
Décrire les vérifications post-nettoyage
Google veut s’assurer que vous avez testé. Vous n’avez pas besoin de tout lister en mode inventaire, mais vous devez donner des repères: pages vérifiées, comportement attendu, absence de redirections, re-scans, vérification des accès.
Si vous avez constaté qu’il y avait encore des traces au cours du nettoyage, mentionnez-le aussi, et indiquez comment vous avez corrigé. Cela peut être plus crédible qu’une histoire trop lisse.
Expliquer la prévention
Enfin, la prévention. Ici, on ne parle pas de “sécurité parfaite”. On parle de mesures raisonnables qui réduisent la probabilité de récidive.
Vous pouvez expliquer par exemple:
- mise à jour et maintien à jour des composants WordPress suppression ou remplacement des extensions inutilisées ou douteuses durcissement des mots de passe, des rôles, et des accès supervision et alertes (même simples) limitation des droits d’écriture et contrôle de l’intégrité
Le but est de montrer que vous avez compris le vecteur probable, pas seulement la “panne”.
Une checklist courte pour votre dossier (avant de cliquer “envoyer”)
Avant la soumission, je vous propose de valider ces points. C’est le genre de contrôle que j’utilise pour éviter les oublis qui coûtent du temps.
- Chronologie claire (dates, actions, décisions) et période de correction bien identifiée Description factuelle de l’infection: ce qui a été observé, où cela se manifestait, comment vous l’avez confirmé Actions de nettoyage détaillées: composants restaurés ou supprimés, éléments base de données traités, comptes non autorisés retirés Vérifications après correction: tests de pages, absence de redirections ou de contenu injecté, contrôles d’intégrité Prévention documentée: mise à jour, durcissement des accès, mesures anti-récidive concrètes
Si un de ces points est trop vague, corrigez-le avant d’envoyer. Les dossiers “trop techniques” ou “trop minimalistes” finissent souvent dans la même zone de risque: l’impression que Google ne peut pas conclure.
Exemples de formulations qui passent bien (sans en faire trop)
Les meilleures descriptions sont celles où le lecteur peut suivre votre raisonnement sans deviner.
Voici des tournures utiles, à adapter à votre cas:
- “Le 12/06, le site a affiché des signes d’infection, avec des modifications de contenu et des comportements de redirection observés sur des pages précises. Après analyse, nous avons identifié des fichiers et des entrées en base de données modifiés, ce qui a permis de déclencher l’injection.” “Du 13/06 au 14/06, nous avons restauré les composants WordPress (cœur, thèmes et plugins concernés) depuis des sources d’origine, puis supprimé les modifications identifiées. Les utilisateurs non reconnus ont été supprimés et les accès ont été durcis.” “Après correction, nous avons vérifié manuellement des pages représentatives, contrôlé l’absence de redirections vers des domaines inconnus, et effectué des scans sur les dossiers pertinents avant remise en ligne.” “Pour éviter la récidive, nous avons mis à jour les composants, appliqué des règles d’accès plus strictes, et mis en place un suivi afin de détecter rapidement toute réexécution inattendue.”
Remarquez ce que je n’ai pas fait: je n’ai pas juré que “tout est propre à 100%”, j’ai décrit ce qui a été observé, puis ce qui a été fait, puis comment j’ai vérifié.
Les pièges qui font rejouer la demande, même après nettoyage
Même quand vous avez nettoyé correctement, votre dossier peut être perçu comme incomplet. Voici les erreurs les plus fréquentes que j’ai vues sur des cas de nettoyer site WordPress infecté.
Le premier piège, c’est la correction sans preuve. Vous avez supprimé des fichiers, mais vous ne mentionnez pas quels chemins ont été restaurés, ni quelles catégories de modifications ont été retirées.
Le deuxième piège, c’est la remise en ligne immédiate. Vous publiez, vous attendez un effet positif, mais vous n’avez pas la certitude que des mécanismes de persistance ont été neutralisés. Ensuite, Google recroise un comportement résiduel.
Le troisième piège, c’est le manque de prévention. Si votre dossier ne mentionne pas d’actions anti-récidive, un évaluateur peut raisonnablement se dire que le même incident peut revenir.
Le quatrième piège, plus subtil, c’est le texte trop flou sur la base de données. Beaucoup d’infections “se cachent” dans des options, des contenus ou des mécanismes de planification. Si vous ne dites pas au moins que vous avez vérifié la base de données, votre récit paraît incomplet.
Enfin, le piège des “plugins mis à jour” sans préciser. WordPress compte beaucoup d’extensions, et un dossier vague laisse planer un doute sur la capacité à avoir identifié le bon vecteur.
Après l’envoi: quoi surveiller et quand reposer une demande
Une requête de réexamen n’est pas un bouton magique. Même si vous avez fait le travail proprement, il faut du temps pour que les signaux se stabilisent. En pratique, je surveille:
- les alertes de sécurité dans Search Console (leur évolution) la disparition des pages signalées la cohérence entre le comportement observé et les signaux
Si la demande est rejetée ou si rien ne bouge, ne recommencez pas “au hasard”. Reprenez votre chronologie, vérifiez vos hypothèses, et relisez votre récit: y avait-il un doute sur la source de l’infection, un élément que vous n’aviez pas traité, une étape de vérification trop optimiste? C’est souvent là que se cache la prochaine action.
Et surtout, si vous constatez une récidive, traitez le vecteur. Une réinfection est rarement un accident isolé, elle est un signal que le système d’accès ou la surface d’attaque n’a pas été réellement refermée.
Ajouter de la cohérence à votre dossier, même si tout a été chaotique
Il arrive que le nettoyage se fasse dans l’urgence, avec des décisions prises au fil de l’eau. Ce n’est pas forcément rédhibitoire. Ce qui compte, c’est la cohérence.
Si vous avez changé de stratégie en cours de route, vous pouvez l’expliquer sans vous excuser: “Nous avons d’abord isolé et analysé, puis nous sommes passés à une restauration contrôlée des composants après confirmation de modifications” ou “nous avons commencé par supprimer X, puis nous avons découvert une persistance en base qui a nécessité une purge supplémentaire”.
Cette transparence aide, parce qu’elle reflète une réalité technique. Google cherche la correction, pas la perfection narrée.
Et si vous avez utilisé des outils de scan, mentionnez-les sans les présenter comme une baguette magique. Les scans sont des indicateurs, pas une preuve absolue. Une preuve absolue, vous la fabriquez avec la combinaison: suppression, restauration propre, vérification et prévention.
Garder une trace utile pour la suite, même après résolution
Une fois l’alerte levée, c’est tentant d’arrêter de documenter. Pourtant, c’est exactement le moment de capitaliser.
Conservez:
- les versions des composants utilisés lors de la restauration le détail des comptes supprimés les changements de configuration (accès, rôles, durcissement) la liste des tests effectués et la date de vérification
Cette trace servira si:
- un nouveau signal apparaît plus tard vous devez expliquer l’incident à un client ou à une équipe vous cherchez à comprendre la cause racine réelle plutôt que “l’apparence de l’infection”
Et surtout, elle rend la prochaine intervention plus rapide. Nettoyer site WordPress infecté devient moins stressant quand votre méthode est reproductible.
Si vous voulez, je peux aussi vous proposer un modèle de texte de requête de réexamen (un paragraphe par partie, ou un texte continu), mais il faudra que vous me décriviez votre cas: type d’alerte dans Search Console, période d’observation, ce que vous avez trouvé (fichiers, base de données, redirections), et les actions exactes de correction.