Quand un site WordPress se met à rediriger des visiteurs vers des pages bizarres, quand Search Console commence à remonter des “problèmes de sécurité”, ou quand les navigateurs affichent des avertissements, on ne parle plus de “bugs”. On parle de dégâts, d’urgence et de réputation. Et dans ce contexte, supprimer malware WordPress ne ressemble pas à un simple bouton “remove”. Il faut une méthode, de la rigueur, et surtout une capacité à prouver à Google que la compromission est réellement finie.
J’ai déjà vu des cas où le site était “nettoyé” en surface, puis réinfecté quelques jours plus tard. La cause n’était pas forcément un nouveau malware, parfois c’était une porte restée ouverte: un fichier réinjecté, un plugin abandonné, un utilisateur créé pour maintenir l’accès, ou un thème custom modifié sans qu’on le remarque. L’objectif n’est donc pas uniquement de supprimer le code malveillant visible, mais de restaurer un état cohérent, contrôlé, et durable.
Comprendre ce que Google attend vraiment
Google ne demande pas une explication technique de votre incident. Il cherche une preuve pragmatique: votre site ne sert plus de contenu malveillant et ne présente plus de comportements dangereux pour les utilisateurs. Dans la pratique, cela passe par deux choses.
D’abord, l’état du site après nettoyage doit être stable, sans changements “suspects” qui reviennent. Ensuite, la requête de réexamen (via Google Search Console) doit s’appuyer sur un récit crédible: ce que vous avez identifié, ce que vous avez supprimé, ce que vous avez réparé, et comment vous empêchez une récidive.
Un point qui surprend souvent: Google ne “devine” pas. Si vous supprimez des fichiers infectés mais laissez un vecteur de compromission (une combinaison mot de passe réutilisée, une API de plugin exposée, un accès admin non sécurisé, un cron mal configuré), le site peut redevenir dangereux avant même que la demande soit traitée.
Les signaux d’une compromission sur WordPress
Les symptômes les plus fréquents se ressemblent, mais les causes varient. Sur un WordPress compromis, on rencontre notamment:
- des redirections invisibles au navigateur, parfois uniquement sur certaines zones géographiques ou sur des user-agents spécifiques; des pages “déposées” dans l’arborescence, ou du contenu injecté dans des thèmes et des templates; des injections dans la base de données, souvent via des champs qui ne devraient pas contenir de code; des comptes administrateurs créés sans votre intervention; des scripts qui tournent via wp-cron ou des tâches planifiées, et qui réécrivent des fichiers.
Ce qui rend le diagnostic délicat, c’est que le site peut fonctionner “à peu près”, avec une petite différence visuelle, voire aucune différence côté front. Le malware peut cibler l’indexation, l’exploration par les crawlers, ou des actions déclenchées (clic, chargement d’un script, interrogation d’un endpoint). En clair, vous ne pouvez pas vous contenter de “ça a l’air propre”.
Préparer une décontamination qui ne vous piégera pas
Avant de modifier quoi que ce soit, je recommande presque systématiquement de créer une copie de travail. Dans un incident réel, on a tendance à vouloir aller vite, et c’est compréhensible. Le problème, c’est que des modifications successives rendent l’enquête plus dure et augmentent la probabilité d’oublier un élément.
Une approche solide consiste à séparer trois environnements mentaux, même si techniquement vous n’en créez que deux:
1) l’environnement “preuves”, où vous conservez des éléments consultables (exports, listes de fichiers, captures, logs); 2) l’environnement “nettoyage”, où vous remplacez, supprimez, réécrivez; 3) l’environnement “production”, où vous ne repoussez en ligne qu’une fois que le site est cohérent.
Concrètement, une copie complète des fichiers et un dump de la base suffisent souvent. L’idée n’est pas d’être paranoïaque, mais d’éviter le scénario où vous supprimez le mauvais fichier et vous perdez tout moyen de revenir en arrière.
Étape 1: diagnostiquer sans aggraver
Une fois la copie faite, vous pouvez investiguer, mais sans tomber dans le “tout supprimer tout de suite”. Sur WordPress, il y a des endroits classiques où des compromissions laissent des traces.
Je commence généralement par les journaux et les signaux qui ont du sens pour votre incident. Même si les logs exacts dépendent de votre hébergeur, vous pouvez souvent accéder à des traces de requêtes HTTP, d’erreurs PHP, ou d’accès au panneau d’administration. L’objectif est de repérer un vecteur. Exemple: tentatives de connexion échouées, pics de trafic sur des endpoints inhabituels, erreurs répétées sur une zone de fichiers.
Ensuite, je vérifie l’accès. Les comptes créés discrètement sont fréquents. Un utilisateur avec un rôle élevé peut servir à réinstaller du code après votre premier nettoyage. Si vous n’avez pas le contrôle de ces comptes, vous nettoyez contre un mur.
Enfin, je passe en revue les fichiers. On cherche des éléments qui ne “devraient” pas être là, mais aussi des modifications sur des chemins attendus: certains malwares altèrent un thème ou injectent du code dans des fichiers qui chargent des scripts, même si le front semble normal.
Ce diagnostic n’est pas forcément long, mais il doit être méthodique. L’erreur classique, c’est de scanner, supprimer, re-scan, puis constater que la menace revient, sans comprendre d’où.
Étape 2: supprimer malware WordPress avec une stratégie “remplacement” plutôt que “patch”
Sur WordPress, la tentation est de nettoyer au fil de l’eau, fichier par fichier, injection après injection. Ça peut fonctionner, mais seulement si vous maîtrisez exactement ce que vous supprimez et pourquoi. En pratique, une stratégie de “remplacement” est souvent plus robuste.
L’approche que j’applique dans les incidents où le niveau de doute est élevé ressemble à ceci: vous repartez d’une base propre (WordPress, thèmes, plugins), puis vous réintroduisez votre contenu https://gardewp.fr/ et vos personnalisations de manière contrôlée.
Techniquement, cela implique:
- remplacer les fichiers WordPress du noyau par une version saine (celle qui correspond à votre version); remplacer les thèmes et plugins par des versions issues de sources officielles, ou par vos versions validées; réinstaller les fichiers custom seulement si vous pouvez prouver qu’ils n’ont pas été modifiés.
Je sais que ce n’est pas toujours possible, notamment si vous avez beaucoup de customisations dans un thème. Mais même dans ce cas, vous pouvez souvent isoler les changements, comparer le contenu, et reconstruire les parties critiques.
Le vrai piège est l’illusion du “c’est nettoyé”. Si un malware a modifié un fichier que vous remettez à jour, il peut aussi avoir laissé des scripts ailleurs. D’où l’importance https://gardewp.fr/nettoyage-malware-wordpress/ de re-scanner après chaque grande étape.
Étape 3: nettoyer la base de données sans casser votre site
Les compromissions qui touchent la base sont souvent plus sournoises que les fichiers. Des malwares peuvent injecter des liens, des iframes, du JavaScript, ou créer des champs qui contiennent du code. Parfois, ils modifient des options WordPress, des métadonnées de pages, ou des données liées à des plugins.
Le nettoyage de la base est délicat, car vous ne voulez pas effacer des contenus légitimes. Le bon réflexe est de comparer ce qui a changé pendant l’incident et ce qui devrait exister.
Dans une approche raisonnable, je me limite à:
- supprimer les entrées clairement malveillantes ou inattendues; rétablir des options critiques à leur état normal si elles ont été altérées; recalculer la cohérence du site une fois les changements faits.
Je préfère faire cela avec une logique “avant/après” et en gardant la copie du dump. Si vous n’avez pas de copie, vous perdez la possibilité de revenir.
Étape 4: vérifier les accès persistants
Le malware sur WordPress ne se contente pas toujours de survivre avec un fichier modifié. Il peut aussi persister via un accès.
Les mécanismes courants incluent la création d’utilisateurs, la modification de rôles, et parfois la mise en place d’extensions ou de webhooks via des plugins ou des scripts. Sur certains hébergements, on voit aussi des mécanismes de type cron ou des appels périodiques.
La vérification que je fais en priorité:
- la liste des utilisateurs, en regardant qui a été créé récemment; les rôles et capacités, pour détecter un admin inattendu; l’existence de scripts ou de tâches planifiées non documentés.
La difficulté ici est que WordPress vous montre des choses, mais pas forcément tout. Il peut y avoir des accès “hors WP”, liés au système d’hébergement, ou des scripts stockés dans des dossiers qui ne sont pas intuitifs à inspecter.
Étape 5: re-scanner avec prudence
Après suppression, on réexamine. L’idée n’est pas de croire aveuglément un outil, mais d’utiliser plusieurs angles. Un scanner ne voit pas tout, et surtout un scanner peut signaler des faux positifs si vous avez modifié des fichiers légitimes.
Je traite les résultats en deux catégories:
- alertes “directement destructrices” (fichiers et injections clairement malveillantes); alertes “à investiguer” (extensions, signatures ambiguës, patterns trop génériques).
Si un motif revient, c’est rarement un détail. Ça signifie qu’il y a encore un vecteur actif. Dans ce cas, je reviens en arrière sur l’accès, puis sur les fichiers réinstallés, puis sur la base. C’est plus lent, mais c’est le genre de lenteur qui évite deux semaines de ping-pong.
Durcir le site pour que la décontamination tienne
Une fois le site nettoyé, c’est là que beaucoup d’équipe ou de site personnel relâche la pression. Pourtant, la décontamination sans durcissement, c’est comme remplacer une serrure, puis laisser une fenêtre ouverte.
Je mets généralement l’accent sur la surface d’attaque et sur la capacité à détecter les anomalies tôt. Les compromis existent. Par exemple, imposer une politique de mots de passe plus stricte peut casser certains usages internes si vous avez des comptes partagés, mais c’est souvent acceptable après une communication claire.
Voici une mini check-list de durcissement efficace que je réutilise souvent (et qui tient en quelques points, sans promesse magique):
- mettre à jour WordPress, thèmes et plugins, en commençant par ceux qui ont accès au backend; supprimer ou désactiver les plugins obsolètes, surtout ceux qui ne sont plus maintenus; renforcer l’authentification (mots de passe uniques, et idéalement une double authentification si possible); limiter l’exposition, en évitant les comptes inutiles et en surveillant les accès admin.
Selon vos contraintes, vous pouvez aller plus loin, mais si vous ne faites déjà que ces quatre actions, vous réduisez fortement la probabilité de récidive.
Restaurer le site et contrôler les comportements
Avant de toucher à la soumission à Google, je vérifie que le site se comporte correctement.
Cela inclut:
- navigation normale des pages clés; chargement des scripts côté front, en regardant s’il y a des chargements vers des domaines inattendus; absence de redirections bizarres sur différentes machines ou navigateurs.
Le test n’a pas besoin d’être spectaculaire. Il doit être réaliste. J’utilise par exemple un navigateur “profil normal”, un mode navigation privée, et je teste quelques pages sensibles comme l’accueil, une page de contact, et une page qui a souvent été modifiée (par exemple un template de blog).
Si vous observez encore une redirection, un script injecté ou un contenu qui change à la volée, ne lancez pas la soumission à Google. Vous risquez un rejet et, pire, vous donnez un faux sentiment de sécurité à l’équipe.
Préparer la soumission à Google Search Console
Quand vous êtes prêt, la soumission à Google intervient dans un flux de travail clair: vous demandez une réévaluation, et Google recrawle le site pour constater si la menace a disparu.
Avant de soumettre, je recommande de préparer votre dossier mental. Google vous demandera généralement un récit, une description de l’action entreprise. Il faut rester factuel et cohérent, sans théâtre.
Dans mon expérience, le récit le plus utile suit une logique simple: “ce qui s’est passé”, “ce que j’ai identifié”, “ce que j’ai supprimé”, “ce que j’ai réparé”, “ce que j’ai mis en place pour éviter le retour”.
Il ne s’agit pas de lister toutes les lignes supprimées, mais d’expliquer le principe de votre correction.
Écrire une demande crédible de réexamen
Beaucoup de gens écrivent une demande trop courte, ou trop technique, ou au contraire trop vague. Le bon milieu se situe dans la précision opérationnelle.
Par exemple, au lieu de dire “nous avons scanné et nettoyé”, il vaut mieux préciser l’action. “Réinstallation du core WordPress”, “suppression des fichiers injectés”, “suppression des comptes ajoutés”, “correction des plugins compromis et mise à jour”, “vérification des redirections”.
Je vous conseille aussi d’indiquer la nature des modifications, même si vous ne donnez pas chaque détail. Google n’a pas besoin de l’adresse exacte d’un fichier, mais il a besoin de comprendre que vous avez fait plus qu’un nettoyage superficiel.
Une phrase que je trouve utile dans les demandes est celle qui relie le nettoyage au contrôle: “nous avons restauré une version saine et supprimé les mécanismes de persistance”. C’est exactement ce que Google essaie d’éviter de voir réapparaître.
Délais et attentes réalistes après soumission
Après la demande, vous aurez probablement des délais. Il faut les intégrer dans votre plan de reprise, surtout si votre site génère du chiffre d’affaires ou des leads.
Ce que j’observe le plus souvent, c’est que le statut peut mettre un certain temps à évoluer, même après un nettoyage réussi. Les raisons sont variées: recrawl, priorités côté Google, fréquence, état de la menace, charge globale.
En pratique, je recommande de surveiller:
- l’évolution des rapports dans Search Console; l’apparition ou la disparition d’avertissements; le comportement de votre site dans le temps.
Et surtout, de ne pas rouvrir toutes les modifications en parallèle. Si vous changez des thèmes, des plugins, ou des paramètres de sécurité au même moment, vous rendez le diagnostic des effets plus difficile.
Scénarios fréquents de “nettoyage qui ne tient pas”
On voit souvent trois types d’échec.
Le premier, c’est la persistance. Vous supprimez les fichiers visibles, mais un compte admin ou un cron continue de réécrire du contenu.
Le second, c’est un vecteur côté plugin. Un plugin compromis peut réinjecter, même après nettoyage. Si vous remettez le plugin infecté, vous replantez la menace.
Le troisième, c’est la réinfection par un élément que vous n’avez pas remplacé. Un thème custom, un fichier uploads, un script dans une arborescence peu surveillée. Le code malveillant est parfois minuscule, mais actif.
Dans ces cas, la soumission à Google devient presque un “test de résistance”. Google recrawle, et si la menace revient, votre demande risque d’être invalidée ou retardée.
Ce que j’utilise comme méthode “propre” quand il faut aller vite
Quand l’urgence est forte et que vous manquez de temps, une méthode pragmatique consiste à viser la cohérence avant l’exhaustivité.
Je fais en gros:
- sauvegarde; remplacement contrôlé (core, thèmes, plugins); reconstitution du contenu légitime; vérification de l’accès et des redirections; scan final; soumission à Google.
Ce n’est pas une méthode “magique”, mais elle a un avantage. Elle limite la surface où le malware peut se cacher. Plus votre site est cohérent, plus il est simple pour vous et pour Google de comprendre ce qui a changé.
Après la décontamination, que surveiller au quotidien
Votre site n’est pas “fini” le jour de la correction. C’est fini le jour où vous observez, pendant un temps suffisant, qu’il ne revient pas à l’état compromis.
Je recommande un suivi régulier, sans vous noyer dans des alertes. Par exemple, regarder les événements d’accès admin, garder un œil sur les plugins ajoutés, et surveiller les rapports de sécurité. Beaucoup de compromis commencent avec une tentative d’accès, puis passent à l’étape injection.
Si vous avez un monitoring, servez-vous-en, mais gardez une lecture humaine: une alerte brute peut masquer un comportement normal, ou inversement, vous donner un faux positif qui retarde l’action.
Et si vous réutilisez un site compromis en “le laissant en ligne pour ne pas perdre de trafic”, faites-le avec prudence. Mettre un site instable ou infecté en ligne augmente les risques pour vos visiteurs et complique votre réexamen.
Un mot sur l’hébergement et les limites de votre contrôle
Il y a un détail qu’on sous-estime: sur WordPress, beaucoup de compromis viennent d’un point d’accès, d’un mot de passe, d’un vecteur via un plugin, mais l’hébergement joue aussi un rôle.
Si vous avez accès aux logs système, aux réglages cron, aux règles de filtrage, ou à une couche WAF, vous pouvez réduire les opportunités. Si votre hébergeur propose des sauvegardes automatiques et un retour rapide, cela accélère la reprise.
Mais attention: une sauvegarde ne remplace pas la correction. Restaurer un backup “d’avant infection” est utile, à condition que la cause ait disparu. Sinon, vous revenez à l’état compromis, simplement à une autre date.
Liste courte de décisions à prendre avant de soumettre à Google
Avant d’appuyer sur “demander une réévaluation”, je vérifie trois décisions. Je les formule comme des critères, parce que c’est plus facile à trancher qu’à décrire.
- Le site charge des pages normales sans redirections ni injections visibles. Les fichiers et plugins ont été remis dans un état contrôlé, pas juste “patchés”. Les comptes, tâches et éléments de persistance ont été examinés et neutralisés.
Si une seule de ces conditions n’est pas vraiment satisfaite, la soumission devient un pari. Et un pari, en sécurité, coûte cher, même si vous ne le payez pas en argent.
Dernier point: documenter votre “preuve” interne
Après un incident, vous gagnez beaucoup à garder une trace des actions menées. Pas pour faire joli, pour vous-même. Quand vous devrez expliquer, ou quand vous verrez un signal inattendu dans Search Console, vous saurez quoi corréler.
Cela peut être un simple journal: date de scan, principaux éléments supprimés, plugins remplacés, restauration core, vérification des utilisateurs. Si vous travaillez en équipe, c’est aussi utile pour éviter que quelqu’un relance le même plugin ou réimporte un thème non validé.
Au fond, supprimer malware WordPress et demander une réévaluation à Google, c’est un mélange de technique et de preuve. La technique vous sort du danger. La preuve vous permet d’en sortir officiellement.
Si vous avez des éléments concrets à partager sur votre situation (message Search Console, type de pages touchées, présence de redirections, plugins récemment ajoutés), je peux vous proposer une logique de diagnostic adaptée à votre cas, sans partir dans une chasse aux sorcières.