Recevoir une alerte de Google du type “site WordPress infecté” est un choc, puis très vite une urgence opérationnelle. Le plus difficile, c’est que l’alerte arrive souvent sans mode d’emploi: parfois c’est une détection réelle, parfois c’est une alerte liée à des pages compromises qui viennent d’être nettoyées, parfois c’est une mauvaise interprétation d’un chargement tiers. Dans tous les cas, votre objectif immédiat n’est pas de “réparer WordPress”, c’est de comprendre ce qui est touché, limiter les dégâts, puis remettre le site dans un état propre et vérifiable.
Je vous propose une approche pragmatique, pensée pour un site WordPress, avec des décisions concrètes, des pièges classiques, et des choix qui tiennent compte du temps, du coût et du risque.
D’abord, clarifier l’alerte: quoi exactement Google signale
Avant d’ouvrir votre panneau d’administration en mode panique, prenez quelques minutes pour qualifier le signal. Selon l’origine de l’alerte, les actions prioritaires ne sont pas les mêmes.
Si vous voyez le message via Google Search Console, vous avez généralement plus de contexte: ce qui est détecté, quand, et parfois des URLs concernées. Si l’alerte apparaît dans Chrome (ou dans une navigation test), vous n’avez pas toujours de détails techniques, mais vous savez que le navigateur de l’utilisateur a vu un comportement suspect.
Ce point change tout pour une raison simple: un “site infecté” peut vouloir dire “malware détecté”, “phishing”, “redirection”, “téléchargement forcé”, “tromperie”, ou même une compromission qui injecte du code dans certaines pages. Sur WordPress, l’injection se fait souvent via un plugin compromis, un thème modifié, un fichier ajouté à la racine, ou une faiblesse côté identifiants (mot de passe réutilisé, compte administrateur pris, session persistante).
Quand vous commencez par identifier le type d’alerte, vous évitez de passer deux jours à mettre à jour des plugins pendant que le vrai problème reste actif.
Ne pas aggraver la situation: sécuriser l’accès avant toute “chirurgie”
Le premier réflexe que j’ai vu fonctionner sur des incidents réels consiste à verrouiller l’accès, pas à toucher au code tout de suite. Sur un site compromis, chaque minute où l’attaquant conserve un accès peut permettre de remettre le malware dès que vous “nettoyez” à l’arrache.
Voici ce que je ferais dans l’ordre, sans hypothèse excessive:
1) Mettre le site en mode limitation temporaire (ou en maintenance) si le trafic est significatif ou si vous avez des pages qui redirigent.
2) Couper l’accès aux comptes compromis: forcer la réinitialisation des mots de passe, vérifier la liste des utilisateurs, et supprimer les comptes inconnus. 3) Vérifier si des fichiers “atypiques” apparaissent encore côté hébergement, car une injection peut revenir dès qu’un plugin est réactivé.Vous n’avez pas besoin d’un plan parfait dès la première heure. Vous avez besoin d’empêcher la persistance.
Une mini-checklist “urgence” (avant les suppressions)
Si vous voulez quelque chose de faisable rapidement, voici une courte liste. Elle reste volontairement générale, parce que le bon détail dépend de votre hébergeur et de votre architecture.
Vérifier la source de l’alerte (Search Console, navigateur, autre) et noter la date. Mettre WordPress en maintenance ou limiter l’accès au site si le risque de redirection est élevé. Réinitialiser tous les mots de passe WordPress et des comptes ayant accès à l’hébergement. Contrôler les utilisateurs WordPress et retirer ceux qui ne sont pas identifiés.Cette phase n’est pas glamour, mais elle fait gagner un temps énorme quand l’attaquant a déjà mis en place une persistance.
Identifier ce qui a été modifié: la méthode qui évite de “nettoyer au hasard”
Sur WordPress, l’erreur la plus coûteuse consiste à supprimer “les fichiers suspects” sans savoir comment ils se déclenchent. Cela peut casser votre site et, pire, laisser une autre porte d’entrée intacte.
Le point de départ le plus utile est l’analyse des modifications:
- Plugins et thèmes: lequel a été modifié récemment, lequel contient du code non attendu, ou des fichiers incomplets. Fichiers à la racine: certains scripts se placent au même niveau que wp-config.php ou dans des chemins qui ne servent pas à WordPress. Cron et planificateurs: une tâche planifiée peut exécuter une injection ou créer du contenu. Fichiers uploadés: l’attaquant peut exploiter un fichier image ou un fichier media pour appeler un script ou charger du code.
Si vous avez accès à un historique (sauvegarde, contrôle de version, snapshots d’hébergement), c’est un avantage majeur. Sans historique, vous pouvez quand même travailler avec une logique: comparer les versions des plugins et thèmes actuellement installés à celles qui sont censées être là, et repérer les fichiers modifiés en dernier.
Un repère utile, c’est de regarder les fichiers qui ont une date de modification “trop récente” par rapport à votre activité légitime. Les attaques laissent souvent des traces temporelles même quand elles essaient d’imiter des changements.
Mettre de côté un mythe: “mettre à jour WordPress” ne suffit pas
Je l’ai https://gardewp.fr/ déjà vu: quelqu’un met à jour WordPress, PHP et les plugins, puis pense que l’alerte Google va disparaître. Parfois ça marche, si le site était seulement exposé à une vulnérabilité et que la compromission n’a jamais eu lieu.
Mais dès qu’il y a eu injection de contenu ou exécution de code malveillant, la mise à jour est une étape, pas une fin. Vous pouvez corriger la vulnérabilité, tout en gardant une porte d’entrée actuelle via un plugin compromis, un thème modifié, un compte administrateur illégitime, ou une redirection injectée dans un fichier de template.
La règle simple: on met à jour après avoir retiré les composants compromis, ou au moins après avoir vérifié qu’ils ne contiennent plus de code anormal.
Les cas typiques sur WordPress quand Google alerte
Sans inventer des diagnostics universels, il y a des scénarios fréquents qui guident les investigations.
1) Plugin ou thème compromis
Très souvent, l’attaquant ajoute du code dans un fichier précis qui s’exécute à des étapes ciblées (chargement du front, sauvegarde, ajout d’un shortcode, exécution sur certaines pages). Le code est parfois “obfusqué”, parfois simplement trop inattendu pour être légitime.
Symptôme opérationnel: vous avez une logique de redirection ou une injection seulement sur certaines URLs, parfois celles indexées par Google.
2) Comptes et sessions
Un site peut être “infecté” au sens large alors que les fichiers ne semblent pas catastrophiques. Un compte admin compromis peut réinstaller des plugins, ajouter du code dans un thème, ou publier des pages d’apparence propre mais orientées vers le phishing.
Dans ce cas, vous pouvez https://gardewp.fr/nettoyage-malware-wordpress/ nettoyer les fichiers et voir l’alerte réapparaître parce que la persistance reste dans l’accès.
3) Fichiers uploadés exploitables
WordPress est basé sur l’upload de médias. Si l’attaquant a réussi à déposer un fichier exploitable, même “dans les médias”, il peut déclencher du code selon des configurations serveur.
À ce stade, le piège est de supprimer le contenu visible sans traiter le déclenchement. Il faut vérifier comment le contenu est servi (et ce que le serveur exécute ou non).
4) Redirections côté serveur ou via dépendances
Parfois ce n’est pas WordPress qui est “infecté”, mais une règle serveur ou un proxy dans la chaîne qui redirige. Sur les plateformes hébergées, des modifications dans des fichiers de configuration peuvent déclencher l’alerte même si WordPress est propre.
Là, l’analyse doit inclure l’hébergement, le CDN, le pare-feu applicatif si vous en avez un.
Restaurer un état propre: la stratégie la plus sûre quand vous doutez trop
Quand on ne sait pas exactement ce qui a été modifié, la meilleure décision est souvent de repartir d’une base propre, plutôt que de “pêcher” dans des fichiers au feeling.
La stratégie la plus robuste consiste à restaurer WordPress à partir d’une version connue (version exacte de WordPress, thèmes, plugins propres) puis à réintégrer uniquement ce qui est légitime. Cela demande une organisation, mais elle réduit fortement le risque de laisser une petite bombe.
Deux approches existent:
- Reconstitution “tout neuf”: vous réinstallez WordPress, vous remplacez les thèmes et plugins par des versions saines, vous inspectez la base de données et vous ne gardez que les contenus dont vous êtes sûr. Réparation ciblée: vous identifiez les fichiers et configurations compromis et vous les remplacez, vous conservez le reste.
Je privilégie la première quand l’alerte est grave, quand plusieurs URLs sont touchées, ou quand vous n’avez pas confiance dans l’historique. La seconde marche si l’analyse est nette et que la compromission est isolée.
Un point pratique sur la base de données
Même après avoir remplacé les fichiers, une base de données peut contenir du code injecté dans des options, des posts, des pages, des widgets, des shortcodes ou des champs bizarres. Si l’attaquant a ajouté des entrées dans wp_options ou des contenus publiés, Google peut continuer à voir des pages “malveillantes”.
Donc, restaurer n’est pas uniquement un sujet “fichiers”. Il faut traiter la base, et idéalement comparer avec une sauvegarde saine datant d’avant l’incident.
Après le nettoyage: durcir, sinon vous allez revisiter le problème
Une fois que le site est propre, vous devez rendre la compromission plus difficile. Sinon, vous nettoyez une fois, puis vous recommencez quand une faille ou un identifiant faible est encore en place.
Sur WordPress, les durcissements qui payent le plus sont souvent ceux qui réduisent le risque d’accès non autorisé et de persistance:
- mots de passe uniques et robustes, limitation des tentatives de connexion, retrait des comptes non nécessaires, mises à jour planifiées, réduction des privilèges.
Là aussi, il y a des compromis. Par exemple, ajouter une sécurité très restrictive peut bloquer des actions légitimes (formulaires, intégrations, bots de monitoring). Le bon ajustement dépend de votre trafic et de vos flux.
Vérifier en local et sur le front avant d’attendre Google
Avant de demander une re-vérification ou de penser “c’est bon”, testez.
Je vous recommande de faire des contrôles concrets:
- Ouvrir le site depuis un navigateur “neuf” (ou une session privée) pour voir s’il y a redirection ou contenu injecté. Tester les pages les plus susceptibles d’être indexées ou impactées. Si Search Console mentionne des URLs, ce sont elles la priorité. Surveiller les logs d’accès et, si possible, les logs d’erreurs. Une injection active laisse parfois des signatures de requêtes répétées.
Le but est de constater l’absence du comportement suspect avant que Google ne re-crawl.
Soumettre à Google et gérer le calendrier de retour
Quand vous avez nettoyé et confirmé la propreté, vous devez traiter la partie “demande de réexamen” si elle est disponible dans votre console. Les délais varient, parce que la re-crawling dépend de multiples facteurs.
Ce que je conseille en pratique: préparez votre preuve et votre logique de diagnostic. Si on vous demande “qu’avez-vous fait pour corriger”, vous devez pouvoir expliquer sans jargon inutile. Google n’attend pas une analyse de laboratoire, il veut comprendre que vous avez arrêté la propagation et réparé le vecteur.
Un autre point: évitez de rouvrir le site à tout le monde trop tôt si vous n’êtes pas sûr. Une re-publication immédiate, puis un retour en nettoyage, peut rallonger le cycle.
Où les gens se trompent le plus souvent
Il y a plusieurs erreurs qui reviennent avec une régularité frustrante:
D’abord, confondre “nettoyer des pages visibles” et “éradiquer la persistance”. Si un fichier d’injection revient au prochain chargement, l’utilisateur et Google continueront de tomber sur le problème.
Ensuite, restaurer sans vérifier les plugins. Si un plugin compromis est réintroduit par accident, le site peut redevenir suspect très vite.
Enfin, ignorer la couche d’accès. J’ai déjà vu des cas où le code était nettoyé mais un compte restait actif, avec les mêmes droits, et l’attaquant a pu reposer le problème après coup.
Pour éviter ça, la bonne approche est celle que vous construisez au fil des décisions, pas celle que vous appliquez après coup.
Une procédure de triage guidée, quand vous ne savez pas par où commencer
Si votre priorité est de ne pas vous disperser, vous pouvez suivre un fil logique. Je le formule ici en ordre de décisions, pas en “tous les cas identiques”.
- Si Search Console pointe des URLs précises, votre premier axe est de reproduire le comportement et de tracer d’où il vient. Si vous n’avez aucun détail utile, votre premier axe devient la sécurité d’accès et la comparaison des fichiers modifiés récemment. Si plusieurs composants sont potentiellement touchés, votre axe devient la restauration structurée avec des éléments propres, plutôt que l’éradication “à l’aveugle”.
L’expérience montre une chose: plus vous attendez en essayant de “deviner”, plus le risque de persistance augmente, surtout si l’attaque est automatisée.
Mini-plan d’action (simple, mais sérieux)
Verrouiller les accès et limiter l’exposition. Identifier le vecteur probable (fichiers, plugins, thèmes, base, tâches planifiées). Remplacer ce qui est compromis par des versions propres, puis contrôler la base. Tester sur des pages ciblées et soumettre la re-vérification à Google si disponible.C’est un plan court, mais il couvre les éléments qui, en pratique, font la différence.
Cas particuliers: hébergement, CDN, pare-feu, et WordPress “innocent”
Parfois, WordPress n’est pas l’origine. Un CDN peut injecter du contenu si sa configuration est compromise, un pare-feu applicatif peut rediriger via une règle mal configurée, et un module de caching peut servir des versions corrompues.
Si vous utilisez un CDN ou un reverse proxy, vérifiez:
- est-ce que le comportement suspect apparaît aussi quand vous contournez le cache, est-ce que les headers et le contenu renvoient à WordPress ou à un tiers, est-ce que les fichiers servent toujours la même sortie après revalidation.
Ce diagnostic demande un peu de méthode, mais il évite de détruire une installation saine pendant que le vrai problème est ailleurs.
Comment éviter le “faux positif” sans baisser la garde
Il existe des scénarios où l’alerte est liée à un incident antérieur qui a cessé. Par exemple, si du code malveillant a été supprimé mais que les signaux de crawl n’ont pas encore mis à jour.
Même dans ce cas, je traite l’alerte comme un incident réel jusqu’à preuve du contraire. La preuve du contraire, ce n’est pas un ressenti, c’est un ensemble de contrôles: absence de redirection, pages cohérentes, fichiers propres, accès sécurisés, logs calmes, et test depuis un environnement vierge.
Si après un nettoyage vérifié et des tests, l’alerte persiste, il faut alors pousser l’investigation: soit il reste un composant, soit un contenu en base subsiste, soit le serveur ou un service intermédiaire participe.
Checklist finale mentale, avant de considérer l’incident réglé
Vous n’avez pas besoin d’un tableau de bord complexe, mais vous devez pouvoir répondre mentalement à ces questions:
- Le vecteur de compromission est-il retiré, ou au moins neutralisé ? Les comptes et accès sont-ils assainis, pas seulement les fichiers ? Les pages les plus visées par Google sont-elles testées de manière fiable ? Avez-vous revalidé en conditions proches d’un utilisateur réel ? Pouvez-vous expliquer ce que vous avez changé, de façon cohérente ?
Une alerte “site WordPress infecté” ne se résout pas par un acte unique. C’est une chaîne de décisions où l’ordre compte.
Et si vous êtes bloqué, à quel moment demander de l’aide?
Si vous avez une équipe technique, vous pouvez gérer l’essentiel en interne. Si vous n’avez pas l’habitude de l’investigation, il y a un moment où demander de l’aide devient rationnel.
Je le formulerais comme un critère de compétence, pas de budget: si vous ne pouvez pas identifier le vecteur avec une méthode claire, si vous ne savez pas quoi vérifier dans la base de données, ou si vous avez déjà remplacé des éléments sans être sûr du résultat, un spécialiste peut vous faire gagner des jours et éviter un nouveau cycle de réinfection.
Le bon prestataire vous demandera des éléments concrets, comme l’accès à l’hébergement ou la nature de l’alerte, et vous proposera une stratégie de validation. Méfiez-vous de ceux qui promettent une “suppression immédiate” sans expliquer comment ils vérifient la persistance.
Dernier point: communiquer sans créer de panique
Pendant que vous nettoyez, il faut aussi gérer la communication interne et externe. Si vous avez des utilisateurs, des clients, ou une page de vente qui tourne, vous évitez de multiplier les messages contradictoires.
Le plus utile est d’indiquer un statut factuel: site en maintenance temporaire si c’est le cas, ou “incident de sécurité en cours de traitement” sans sur-promesse. Dès que vous avez une confirmation de test et une re-vérification en cours, vous pouvez préciser, plus calmement.
La cohérence rassure plus que la vitesse.
Un “site WordPress infecté” n’est pas une fatalité, mais c’est un signal que la sécurité a été contournée, soit par une faille, soit par un accès compromis. La clé est de travailler par étapes: qualifier l’alerte, sécuriser l’accès, éliminer le vecteur, puis valider et durcir. Quand ces pièces s’alignent, Google finit par refléter l’état réel, et vous récupérez un socle sain pour repartir.