Nettoyage malware WordPress : corriger le spam SEO et pages créées

Quand on parle de “malware WordPress”, on pense souvent au pire scénario, celui qui corrompt le site, vole des données ou ferme l’accès. Dans la vraie vie, il y a un autre cas très fréquent, plus silencieux, plus sournois, et souvent plus pénible à démêler: le spam SEO. Des pages sont créées, des contenus sans cohérence apparaissent, parfois avec des liens sortants ou des ancres ciblées, et le site commence à attirer des visites bizarres, puis à perdre du trafic, puis à être signalé.

Le plus dur, ce n’est pas seulement de supprimer des pages. Le plus dur, c’est de comprendre comment elles ont été générées, d’identifier la faille ou le point d’accès utilisé, puis de corriger sans casser le site légitime. J’ai déjà vu des “nettoyages” faits trop vite, où l’on supprime 200 URLs, mais où le mécanisme reste en place. Résultat: le lendemain, 200 autres pages apparaissent, parfois avec un contenu légèrement différent pour contourner les filtres.

Dans ce guide, je vous détaille une démarche réaliste, pensée pour des sites WordPress compromis par du spam SEO et des pages créées, avec des décisions concrètes à prendre au bon moment.

Les signes qui orientent vers du spam SEO automatisé

Un malware classique “fait du bruit”: fichiers modifiés, accès admin étranges, redirections visibles, alertes de sécurité. Le spam SEO, lui, peut rester discret pendant des jours. La première alerte arrive souvent par des indices SEO ou par des anomalies dans la Search Console.

Sur un WordPress compromis, vous pouvez voir:

• des pages qui n’existent pas dans vos menus, pourtant indexées;
• des titres et snippets qui semblent “optimisés” pour des requêtes précises;
• des URLs dans des répertoires inattendus, parfois avec des paramètres ou des structures régulières;
• des redirections en cascade quand vous tentez d’accéder à certaines pages, alors que l’interface d’administration semble fonctionner.

Ce qui m’a le plus aidé, c’est de traiter les URLs suspectes comme une enquête. Quand les pages ont des patterns clairs, par exemple même modèle de contenu, variations d’un mot clé, ou répétition de mêmes sections, on peut suspecter une génération automatisée côté serveur. À l’inverse, si les contenus ressemblent à un “vrai” travail éditorial, avec des images et des paragraphes cohérents, on doit envisager du spam post-compte, c’est-à-dire un auteur compromis ou un compte ayant publié.

Comprendre le “mécanisme”, pas seulement les symptômes

Avant de toucher aux fichiers, je recommande presque toujours de répondre à une question simple: “ces pages ont été créées comment?”

Le mécanisme le plus courant dans le spam SEO est un compromis de l’accès WordPress, par exemple via:

• un compte admin ou éditeur dont les identifiants ont été pris;
• un plugin vulnérable, qui donne une exécution de code ou permet de déposer des fichiers;
• un thème modifié ou un script injecté dans un fichier “témoin” (un header, un template, un include);
• une injection de type “webshell” ou charge utile masquée dans un répertoire.

Il existe aussi des cas où l’on croit avoir une génération de pages, mais en réalité ce sont des pages légitimes qui affichent du contenu injecté à la volée, via du code dans les templates. Dans ce scénario, supprimer les pages ne règle pas la cause, et vous verrez le même spam réapparaître.

C’est pour cela que le nettoyage malware WordPress efficace se fait en deux temps: stopper la génération et corriger la cause d’entrée, puis seulement ensuite nettoyer proprement.

Étape 1: isoler l’incident sans casser le site

La première décision, c’est d’éviter de “faire tourner” la compromission pendant le nettoyage. Si vous supprimez des fichiers en production et que le mécanisme recommence, vous risquez d’avoir une phase interminable.

Selon votre niveau de risque et votre organisation, vous avez trois options réalistes:

• mettre le site en maintenance, le temps de la phase d’investigation et des suppressions majeures;
• bloquer temporairement l’accès front aux zones où le spam est visible;
• créer un clonage de sauvegarde, et travailler en local ou sur un environnement de staging.

Le bon compromis dépend de votre traffic. Si le site reçoit peu de visiteurs, la maintenance pendant quelques heures ou un jour complet est souvent préférable, parce que vous réduisez l’impact et vous gagnez du temps à analyser des logs sans pression.

Une anecdote fréquente: j’ai vu une équipe supprimer des pages indexées immédiatement, tout en gardant le site en ligne. Les robots revenaient, le mécanisme tournait, et la Search Console signalait de nouvelles URLs en continu. C’est décourageant, et c’est surtout inutile si la cause d’entrée n’est pas neutralisée.

Étape 2: inventorier les pages créées et repérer les patterns

Avant de supprimer, prenez des notes. Pas besoin de faire une thèse, mais il faut être précis.

Commencez par collecter:

• la liste des URLs suspectes (ou au moins un échantillon représentatif);
• les dates approximatives d’apparition;
• les types de contenu (pages statiques, posts, pages avec un modèle spécifique, URL en /tag/ ou /category/ artificielles, etc.);
• la présence de liens sortants caractéristiques, ancres répétées, ou textes rédigés de manière “mécanique”.

Si vous avez accès aux journaux (logs) côté serveur, cherchez aussi les requêtes qui déclenchent la création, ou les patterns d’accès. Souvent, on voit des requêtes périodiques, avec des user agents atypiques, ou des appels à des endpoints pas utilisés dans votre fonctionnement normal.

L’objectif ici n’est pas d’avoir “toute la preuve” pour un rapport externe. L’objectif est de savoir où chercher en premier.

Étape 3: vérifier l’intégrité WordPress et détecter ce qui a été modifié

Le nettoyage malware WordPress commence rarement par “supprimer le spam dans l’interface”. Il commence par vérifier l’intégrité, parce que le spam SEO repose souvent sur un point de contrôle dans le code.

Concrètement, je me base sur trois axes:

• Fichiers WordPress core, thèmes et plugins:
• comparer avec une version connue saine quand c’est possible (surtout pour le thème et les plugins);
• regarder les dates de modification des fichiers;
• rechercher du code “incongru” dans des fichiers qui ne devraient pas contenir de logique: par exemple du PHP injecté dans des templates ou des includes.

• Base de données:
• vérifier les utilisateurs (nouveaux comptes, rôles élevés, noms d’auteur nouveaux);
• inspecter les options (certains compromis déposent des URLs de redirection ou des paramètres de génération);
• repérer des posts/pages créés en masse, souvent en peu de temps, avec un auteur spécifique ou “admin” comme créateur.

• Comportements:
• tester plusieurs pages suspectes pour voir si le contenu est injecté à la volée;
• chercher si le code s’exécute même quand on désactive un plugin.

Quand vous avez le bon indicateur, vous pouvez réduire drastiquement la surface à analyser. Par exemple, si les pages sont toutes créées en masse et que l’auteur WordPress associé est le même, il y a de fortes chances que l’attaquant ait utilisé un compte (compromis de session ou jetons). Si, à l’inverse, les pages semblent calculées à la demande, le code se trouve probablement dans les templates ou des includes.

Étape 4: neutraliser la cause d’entrée avant de supprimer

C’est le point qui évite la boucle “ça revient”.

Si vous constatez un compte compromis, commencez par:

• changer les mots de passe de tous les utilisateurs à accès élevé;
• invalider les sessions (déconnexion partout si l’option existe, sinon via une mise à jour ou une action équivalente côté hébergement);
• vérifier la sécurité de la connexion (2FA si vous l’utilisez, et activer immédiatement si possible).

Si vous suspectez un plugin ou un thème modifié, la séquence dépend de votre marge https://gardewp.fr/ de sécurité. En pratique, je recommande souvent de:

• désactiver temporairement les plugins non essentiels;
• conserver le thème actuel si vous pensez que c’est lui le vecteur, mais l’évaluer avec méthode;
• comparer les fichiers modifiés avec ceux d’une version officielle.

Attention à un piège: désactiver trop de choses peut casser votre site, mais cela peut aussi vous aider à isoler le coupable. L’idéal est de travailler en staging si possible.

Si vous détectez des fichiers “bizarres” dans wp-content, surtout des fichiers PHP dans des emplacements inhabituels, ne faites pas uniquement semblant de les supprimer. Pensez à supprimer le mécanisme et à nettoyer les références, car certains compromis gardent un auto-update interne.

Étape 5: supprimer les pages créées sans effacer la preuve utile

Une fois la cause neutralisée, vous pouvez nettoyer les pages créées.

Je recommande une stratégie prudente:

• commencez par supprimer ou mettre en brouillon les pages et posts spam côté WordPress;
• vérifiez les taxonomies créées (catégories, tags artificiels) si elles ont servi à construire des URL;
• nettoyez les contenus associés, comme des médias inutilisés ou des champs extraits.

Mais surtout, avant suppression massive, assurez-vous que vous n’effacez pas la seule indication qui vous permettra de confirmer la neutralisation. Par exemple, si vous aviez identifié un auteur compromis, documentez-le, puis supprimez le contenu après que vous avez changé les identifiants et invalidé les sessions.

Dans un cas réel, nous avions supprimé les pages directement, puis seulement après vérifié la base de données. Le lendemain, les pages avaient recommencé, mais avec une structure modifiée, car l’attaquant avait un second canal, plus discret. Une fois que le second canal a été identifié, le nettoyage a enfin tenu.

Étape 6: corriger les redirections, injecteurs et templates

Le spam SEO ne passe pas toujours par des créations de pages “dans l’administration”. Il peut passer par des injections dans des fichiers de template, ou par des redirections.

Voici un scénario typique: le site charge normalement, mais certaines requêtes reçoivent une version “forcée”, avec des mots clés ajoutés, ou une redirection silencieuse. Dans ce cas, il faut:

• identifier le point d’injection dans les templates;
• supprimer le code malveillant;
• reconstruire le thème si nécessaire, ou réinstaller le thème à partir d’une base saine.

Je garde un réflexe: quand un thème a été modifié sans raison claire, je préfère réinstaller le thème (ou restaurer à partir d’une version saine) plutôt que de corriger ligne par ligne si le niveau de confiance est faible. Les thèmes utilisent parfois des surcharges, et je préfère éviter d’accumuler des “rustines” qui risquent de laisser une partie du mécanisme.

Pour les plugins, même logique: si vous avez un doute sérieux, réinstaller plutôt que de “nettoyer à la main”.

Étape 7: traiter les effets SEO côté Search Console

Une fois le site nettoyé, le spam côté SEO ne disparaît pas toujours instantanément. Il faut aussi aider les moteurs.

Ce que vous pouvez faire sans faire de surpromesse:

• surveiller les rapports d’indexation et de pages détectées;
• demander une revalidation et suivre la disparition progressive des URLs;
• si vous avez des demandes de suppression, respecter la mécanique de la Search Console.

Ne vous attendez pas à un résultat immédiat, surtout si les URLs ont été massivement crawlées. Le moteur a besoin de détecter que les pages ne répondent plus comme avant.

J’ai vu des sites qui ont récupéré du trafic en quelques semaines, parfois plus, surtout si les signaux étaient fortement dégradés. Le timing dépend de la fréquence de crawl, du nombre d’URLs, et du comportement post-nettoyage.

Étape 8: durcir WordPress pour que ça ne revienne pas

Après un incident, la tentation est de remettre en ligne “le plus vite possible”. Je comprends. Pourtant, dans la plupart des cas, le malware WordPress revient parce que la faille initiale n’a pas été corrigée, ou parce que le site n’a pas été renforcé.

C’est ici que des mesures simples font souvent la différence, sans tomber dans des superstitions.

D’abord, mettez à jour les composants. Même si vous pensez avoir corrigé le vecteur, une version vulnérable laissée en place est un risque.

Ensuite, renforcez l’accès:

• Mots de passe robustes, uniques.
• Désactivation des comptes inutiles.
• Limitation des tentatives de connexion, via des réglages d’hébergement ou de sécurité.
• Activation de la double authentification si vous pouvez.

Enfin, contrôlez ce qui entre et ce qui sort:

• limiter les droits d’édition aux personnes qui en ont besoin;
• surveiller les nouvelles installations de plugins et les changements de thèmes;
• surveiller les changements de fichiers (au moins un contrôle visuel régulier, et des alertes si votre hébergeur le permet).

Si vous avez eu un spam SEO massif, je traite souvent cela comme un signal que la sécurité globale était trop “souple”. Pas forcément par manque d’effort, mais parfois par héritage: identifiants partagés, plugins oubliés, maintenance non planifiée.

Une check-list courte avant de remettre en ligne

Voici la vérification rapide que je fais quand j’ai neutralisé la cause et que je veux éviter une reprise du spam. C’est volontairement “courte”, sinon on finit par bâcler.

• Vérifier que les pages suspectes ne sont plus générées, sur un intervalle d’observation (au moins quelques heures, parfois une journée selon le contexte).
• Confirmer que les comptes à privilèges ont des identifiants changés et des accès cohérents.
• Vérifier les thèmes et plugins suspects, en comparant avec des versions saines et en supprimant ce qui a été modifié.
• Contrôler la base de données pour s’assurer qu’il n’y a pas de nouveaux posts/pages ajoutés pendant l’investigation.
• Surveiller les logs d’accès pour repérer des tentatives répétées ou des endpoints inattendus.

Cas limites qui compliquent le nettoyage

Le nettoyage “propre” est rarement linéaire. Voici quelques cas où il faut ajuster son approche.

Quand le spam vient d’un compte “plausible”

Parfois, l’auteur du spam n’est pas un compte créé le jour même. Il peut s’agir d’un utilisateur ancien, avec un profil qui ressemble à un profil légitime. Dans ce cas, vous devez considérer deux hypothèses: compromission de session, ou récupération de mot de passe via un vecteur externe (phishing, réutilisation de mot de passe).

Dans ce scénario, vous ne pouvez pas vous contenter de supprimer les pages. Il faut sécuriser le compte et vérifier l’ensemble des identifiants associés, parfois aussi au niveau de l’hébergement.

Quand les pages “se ressemblent” mais ne sont pas générées par le même mécanisme

On peut voir des pages variées, avec des modèles proches mais pas identiques. Ça peut venir d’une génération par lots, ou d’un mécanisme qui s’adapte. J’ai déjà vu des pages en deux vagues: la première ajoutait des contenus, la seconde ajoutait des redirections ou modifiait des templates pour renforcer l’efficacité SEO.

Si vous avez eu plusieurs vagues, faites attention à l’ordre des corrections. Le premier nettoyage n’a pas toujours “éteint” le deuxième mécanisme.

Quand le site est “propre” mais les URLs restent indexées

Après un bon nettoyage, il est possible que les pages restent visibles dans les résultats. C’est frustrant, mais ce n’est pas un signe que le site est encore compromis. Le signal est surtout dans la https://gardewp.fr/nettoyage-malware-wordpress/ capacité du site à regénérer ces pages ou à injecter du contenu.

Dans ce cas, je me concentre sur la stabilité et sur la preuve technique: pas de nouveaux contenus, pas de code injecté, pas de génération. Ensuite, j’accompagne la désindexation.

Comment je documente l’incident pour éviter de repartir de zéro

Je conseille souvent de garder une trace simple, même pour une petite équipe. Pas besoin d’un dossier judiciaire. Juste assez pour retrouver vite ce qui a été fait.

Ce que je note, typiquement:

• période estimée de l’infection;
• nombre et types de pages créées (fourchette si vous n’avez pas la totalité);
• vecteur probable (compte, plugin, thème, injection);
• actions effectuées, dans l’ordre, avec les dates;
• état actuel, “ce qui a été stoppé” et “ce qui reste à surveiller”.

Cela réduit le temps si, malheureusement, une nouvelle alerte arrive. Et surtout, ça empêche la confusion entre le nettoyage SEO et la correction de la faille.

Une stratégie finale: reconstruire plutôt que bricoler

Quand le site a été modifié en profondeur, bricoler peut devenir dangereux. Le bon réflexe est parfois de reconstruire proprement:

• réinstaller WordPress core;
• restaurer le thème à partir d’une version saine, en réintégrant seulement les personnalisations nécessaires;
• réinstaller les plugins utilisés, en vérifiant chacun un par un;
• reconstruire les paramètres importants.

Je ne dis pas que c’est toujours la meilleure option, mais quand l’incertitude grandit, la reconstruction devient un choix rationnel. Elle réduit le risque de laisser une petite charge utile ou une modification inattendue.

Le coût, c’est du temps, et parfois des ajustements de configuration. Mais l’alternative, c’est une base de “doute permanent”.

Surveiller après le nettoyage: le vrai test

Le test le plus honnête, ce n’est pas la suppression des pages. C’est la période d’observation après remise en ligne.

Je recommande de surveiller au moins:

• la génération de nouveaux contenus suspects dans WordPress;
• les changements de fichiers dans wp-content;
• les accès admin inhabituels;
• la cohérence des logs et des tentatives de connexion.

Le spam SEO est parfois lent, parfois “pulsé”. Une compromission peut rester en sommeil, puis réactiver la création quand elle a suffisamment de temps ou quand certains signaux sont détectés.

Dans la plupart des cas, une vigilance sur quelques jours donne une réponse beaucoup plus fiable que l’impression “c’est bon, tout a été supprimé”.

Si vous me décrivez votre cas (nombre approximatif de pages créées, si des comptes ont été ajoutés, quels plugins/thèmes étaient en place, et si vous voyez une régénération après nettoyage), je peux vous aider à prioriser les vérifications pour un nettoyage malware WordPress ciblé, plutôt que de faire un “nettoyage complet” au hasard.