Sur WordPress, le “SEO spam injecté” a une signature assez reconnaissable: des pages qui n’étaient pas là hier, des blocs de texte qui n’ont aucun rapport avec votre site, parfois des liens en cascade vers des domaines sans cohérence éditoriale, et une hausse brutale des requêtes à des URLs étranges dans les logs. Le pire, ce n’est pas seulement le contenu visible, c’est le mélange de vecteurs possibles: fichiers modifiés, scripts cachés dans le thème, base de données polluée, ou injection au moment de l’affichage.
J’ai déjà vu des sites qui avaient l’air “normaux” en frontal, mais qui injectaient le spam uniquement pour certains navigateurs, certaines plages d’IP, ou via des requêtes faites par des robots. Dans ces cas, vous pouvez croire que tout va bien jusqu’au moment où Google recalcule. Et là, vous vous retrouvez avec des pages indexées qui n’ont rien à voir avec votre activité.
L’objectif de cet article est simple: vous aider à identifier l’origine, nettoyer proprement, et réduire les risques de récidive. Je vais parler des scénarios les plus courants et des gestes qui comptent vraiment, sans transformer ça en recette magique.
Comprendre ce que “l’injection SEO” vise réellement
Le contenu SEO spam injecté cherche généralement trois effets:
D’abord, capter du trafic “longue traîne” via des requêtes ciblées. Ensuite, créer des liens sortants pour gonfler artificiellement la popularité de domaines tiers. Enfin, parfois, tenter un détournement de page: votre URL garde la même apparence globale, mais le contenu textuel est remplacé ou noyé.
Techniquement, l’injection peut se faire à plusieurs niveaux:
- au niveau du thème ou d’un fichier d’extension, qui ajoute du HTML ou des liens avant d’envoyer la page au niveau de la base de données, via des options, des métadonnées, ou du contenu ajouté en base dans des tables inattendues au niveau de scripts dissimulés, parfois via des obfuscations dans un fichier “banal” (un PHP dont la taille ou la date de modification ne correspond pas à votre historique) au niveau d’un mécanisme plus subtil, comme un affichage conditionnel, où le spam s’affiche selon l’User-Agent ou certaines conditions de requête
Ce point est important parce qu’un nettoyage superficiel, par exemple supprimer quelques pages visibles, ne traite pas forcément la cause. Si vous retirez le contenu mais laissez le déclencheur dans le thème ou un fichier modifié, l’injection reviendra.
Les premiers indices à repérer, avant de toucher aux fichiers
Quand on me confie une désinfection, la première question n’est pas “où est le spam”, mais “comment il s’insère”. On commence par observer, calmement, sans encore supprimer.
Voici ce que je regarde en priorité, parce que ça donne souvent la piste la plus rapide:
1) Le comportement du site en navigation “normale” et “propre”. Je teste avec un navigateur classique, puis en navigation privée, et parfois depuis un mobile. Si le spam apparaît seulement dans un cas, c’est un indice de conditionnement.
2) L’évolution récente. Beaucoup de sites sont infectés après une mise à jour, une installation de thème nullement relue, ou un plugin “gratuit” chargé trop vite. Il arrive aussi que l’infection survienne sans changement visible, mais la date de modification de certains fichiers raconte souvent l’histoire.
3) Les logs et la logique des requêtes. Quand vous voyez une rafale vers des URLs non pertinentes, des paramètres bizarres, ou des hits sur des fichiers rarement utilisés, ça oriente le diagnostic. Sur certains hébergements, les logs sont compressés ou partiels, mais même une fenêtre sur quelques jours aide.
4) Le contenu en HTML. Si vous inspectez la page (voir le code source), vous repérez parfois des blocs ajoutés, des commentaires HTML, ou des liens en sortie qui ne ressemblent pas à ce que produisent vos templates.
Une anecdote utile: sur un site, le spam apparaissait surtout sur les pages d’archives, jamais sur la page d’accueil. En regardant le code, on voyait une chaîne de fonctions déclenchées uniquement dans archive.php ou via wp_head. Une modification minime cachée dans le thème suffisait à générer le contenu. Le retrait des pages ajoutées ne faisait rien, tant que la logique d’injection restait.
Mettre le site en sécurité avant toute désinfection
Avant de supprimer quoi que ce soit, l’étape la plus “ennuyeuse” est souvent la plus rentable: figer la situation pour éviter d’aggraver ou d’aveugler le diagnostic.
Je recommande de prévoir trois actions:
- Faire une sauvegarde complète, incluant fichiers et base de données. Ne vous contentez pas d’un export partiel si le problème touche à la structure. Restreindre temporairement l’accès au site si possible (mode maintenance ou protection par IP), surtout si vous craignez une exploitation active. Changer les accès avec des identifiants sûrs une fois l’incident cadré. Le point clé: si vous changez les mots de passe immédiatement, vous coupez l’accès à l’attaquant, mais vous risquez aussi de perdre des traces si vous modifiez l’environnement de façon désordonnée.
Il y a un compromis. Parfois, un site est en production et totalement public, et vous avez besoin d’agir vite. Dans ce cas, vous pouvez commencer par limiter l’exposition, tout en travaillant sur une copie. L’important est de ne pas faire “au hasard” sur l’installation originale.
Diagnostiquer la source: fichiers, base de données, ou les deux
Dans la pratique, les infections SEO injectées mélangent souvent deux couches. On nettoie mieux quand on sait ce qui a été altéré.
Fichiers: thème, plugins, ou scripts “orphelins”
Quand vous examinez la base de votre WordPress, cherchez ce qui peut être altéré, puis comparez avec votre état attendu.
Le dossier qui trahit souvent le problème, c’est le thème actif. Vous pouvez trouver un fichier PHP dans le thème avec une date de modification récente, ou un contenu qui ne ressemble pas à une mise à jour normale.
Les symptômes dans le code sont typiques: concaténations étranges, utilisation de eval, base64_decode, gzinflate, ou parsing de contenus injectés dans wp_head, wp_footer, ou via des hooks inattendus.
Les plugins sont l’autre zone fréquente. Parfois, un plugin a été installé puis supprimé côté administration, mais son fichier malveillant reste dans le répertoire, ou alors il est remplacé.
Enfin, il y a les fichiers “orphelins” à la racine, des noms peu explicites, des tailles très particulières, ou des chemins que WordPress n’utilise pas.
Base de données: contenu ajouté et options polluées
Quand l’infection s’appuie sur la base de données, vous pouvez avoir du contenu injecté directement dans l’admin ou ajouté via requêtes.
Je regarde en priorité:
- les articles et pages récemment créés, surtout s’ils ont des slugs sans cohérence les champs “custom” qui deviennent soudainement énormes les options et transients qui contiennent des morceaux de HTML inattendus des métadonnées stockées dans des tables liées aux thèmes ou aux pages
Un piège classique est de supprimer les contenus, puis de découvrir que la logique ajoute à nouveau le bloc au prochain chargement, car un champ en base déclenche l’injection. Dans ce scénario, le nettoyage doit viser le point de déclenchement, pas uniquement l’affichage.
Stratégies de désinfection fiables, selon le scénario
Il n’y a pas une seule méthode universelle qui marche à chaque fois, mais il existe des stratégies robustes, testées sur des cas différents.
Option la plus sûre: re-déployer un WordPress propre
Quand on veut réduire le risque de laisser un détail, la méthode la plus fiable consiste à reconstruire:
- remplacer les fichiers “WordPress core” par une version saine remplacer le thème et les plugins par des versions obtenues depuis des sources fiables conserver uniquement ce qui est attendu (uploads, médias, éventuellement un thème custom si on a vérifié)
Le point délicat est le thème custom. Si vous avez développé sur mesure, vous ne pouvez pas simplement remplacer le thème sans précautions, sinon vous perdez du code légitime. Dans ce cas, la bonne approche est de récupérer votre thème depuis votre historique (repo, archive, sauvegarde) et de comparer ce qui a changé.
Sur beaucoup de sites infectés, le cœur du problème se trouve dans un thème ou un plugin modifié. Repartir propre diminue drastiquement les zones à risque.
Option “patch” ciblée: utile quand le site est complexe
Parfois, vous n’avez pas la possibilité de remplacer tout de suite, parce que le site a des intégrations spécifiques, un thème sur mesure très modifié, ou des dépendances peu documentées.
Dans ce cas, la désinfection ciblée fonctionne, mais elle exige discipline:
- identifier les fichiers ou hooks responsables supprimer uniquement ce qui est malveillant vérifier qu’il n’y a pas d’autres points de déclenchement confirmer le résultat sur plusieurs types de pages
C’est là que l’obsession du détail paie: j’ai vu des injections qui étaient d’abord évidentes sur une page, mais la logique était partagée via un include commun. Si vous corrigez une seule branche sans traiter l’include, l’injection revient ailleurs.
Le plan d’action concret, sans se perdre
Voici une démarche que j’utilise quand il faut aller vite, tout en évitant les “nettoyages” qui laissent une bombe à retardement.
1) Mettre le site en maintenance et faire une sauvegarde complète (fichiers + base), sur un état figé.
2) Vérifier les derniers changements dans le thème et les plugins: date de modification, tailles inhabituelles, présence de fonctions obfuscées, ajouts de code autour de wp_head, wp_footer, the_content, init. 3) Inspecter la base: rechercher les contenus récemment créés, les options contenant du HTML inattendu, et les transients ou meta qui semblent piloter une injection. 4) Remplacer core, thème et plugins par des versions saines, ou au minimum reconstruire ceux qui sont touchés. 5) Recontrôler l’affichage sur plusieurs pages et plusieurs profils de navigation, puis vérifier qu’aucun contenu spam n’est re-injecté après quelques minutes.Cette suite a un avantage: elle force à diagnostiquer, puis à neutraliser, pas juste à “effacer ce qui se voit”.
Comment repérer une injection dans le code PHP (sans devenir expert en malware)
Si vous n’avez jamais lu un code infecté, vous pouvez vous sentir perdu au début. Le secret, c’est de ne pas chercher “du texte malveillant” au hasard, mais des signaux.
Les signaux les plus fréquents que j’ai rencontrés:
- des lignes qui décodent une chaîne et la réinjectent dans la sortie des hooks qui ne correspondent pas à la logique attendue de votre thème des conditions liées à l’User-Agent, à des paramètres GET, ou à l’IP des fichiers qui semblent “utiles” mais ne font rien de normal
Si vous avez accès à une comparaison Git ou à une sauvegarde d’avant incident, comparez directement. C’est souvent plus rapide que de lire chaque fichier à la main.
Attention toutefois: supprimer “ce qui est étrange” sans comprendre peut casser votre site. C’est pour cela qu’on commence par sauvegarder, et qu’on vise les zones responsables.
Nettoyer proprement le contenu SEO spam visible
Une fois la source neutralisée, le contenu visible doit disparaître. Ici, le piège est de confondre affichage et stockage.
Si l’infection ajoute des pages entières en base, vous allez devoir:
- supprimer les pages, articles, ou termes créés pour le spam nettoyer les caches éventuels, car certaines couches peuvent garder l’ancien rendu vérifier les redirections ou liens injectés qui pointent vers des domaines externes
Si le spam ne crée pas de pages, mais injecte directement du HTML lors du rendu, alors vous n’aurez peut-être pas des articles “spams” à supprimer. Dans ce cas, le nettoyage se fait en traitant le code d’injection, puis vous constatez la disparition.
Après nettoyage, je conseille de vérifier la console de recherche (ou les outils équivalents selon votre moteur). Les résultats ne changent pas en quelques minutes, et c’est normal. Ce qui compte est la disparition de la production de contenu et l’absence de réinfection.
Vérifier les comptes administrateur et supprimer l’accès persistant
Un site infecté n’est pas seulement un site “abîmé”, c’est parfois un site qui a été rendu réutilisable par l’attaquant.
Deux choses à faire:
- Revoir les utilisateurs WordPress: comptes inconnus, rôles élevés, tentatives de connexion suspectes. Vérifier que les clés et identifiants de sécurité côté hébergement (si vous avez un panel) n’ont pas été compromis.
Changez les mots de passe, puis vérifiez les sessions. Selon votre configuration, vous pouvez invalider les sessions en forçant une reconnexion. C’est un geste simple, mais il coupe souvent la persistance.
Je mets aussi une vigilance sur les thèmes et plugins installés à un moment où vous n’avez rien demandé. Même si vous nettoyez le contenu, un plugin mal installé peut rester et recommencer l’injection.
Refaire une passe de sécurité, parce que la désinfection ne suffit pas
Après un incident, les habitudes comptent autant que les fichiers.
Quelques mesures pragmatiques, qui réduisent la probabilité de retomber dans le même piège:
- Mettre à jour WordPress, les thèmes et plugins. Le but n’est pas “tout de suite toutes les mises à jour sans vérifier”, mais garder le parc à jour quand c’est faisable. Supprimer les thèmes et plugins inutilisés. Moins vous avez d’extensions, moins vous avez de surface d’attaque. Limiter les droits: éviter des comptes admin utilisés au quotidien, préférer des rôles éditorials restreints. Surveiller les alertes de sécurité et les logs d’erreurs. Les injections laissent souvent des traces, mêmes si elles ne sont pas visibles à l’œil.
Le point le plus sous-estimé est la qualité des extensions. Beaucoup d’infections “SEO” démarrent par un plugin qui a été installé pour une petite fonctionnalité, puis qui n’a jamais été validé. Une fois qu’il est en place, il peut devenir le point d’entrée.
Quand demander de l’aide, et quoi exiger
Si vous gérez un site critique, ou si vous n’avez ni le temps ni l’habitude de lire du code PHP suspect, appeler une aide externe peut être la meilleure décision.
Dans ce cas, je recommande de cadrer la demande, pour éviter le nettoyage superficiel. Vous pouvez exiger:
- une analyse des fichiers modifiés et une justification des suppressions une vérification de la base de données (au moins sur les zones plausibles: contenus récents, options, hooks liés) des preuves que l’accès persistant a été neutralisé (comptes, sessions, éléments de persistance) un contrôle post-désinfection sur plusieurs pages
Je préfère aussi une méthode “reconstruction” plutôt qu’un “patch rapide” quand https://gardewp.fr/nettoyage-malware-wordpress/ la confiance dans le code est faible. Repartir propre prend du temps, mais évite de revenir dans deux semaines.
Effets secondaires possibles et compromis à gérer
Le nettoyage n’est pas toujours “transparent”. Selon votre site, vous pouvez rencontrer des effets secondaires:
- cache qui affiche encore du contenu ancien mise en page cassée si un hook de thème a été modifié plugins qui ne fonctionnent plus si vous avez remplacé une version sans tenir compte des dépendances
C’est un des coûts de l’incident. La bonne approche est de tester après désinfection, sur les zones stratégiques: pages types, recherche interne si vous en avez, formulaires, et une lecture complète sur mobile.
Autre compromis: conserver des fichiers custom. Les injections peuvent parfois se cacher dans un petit ajout dans le thème custom. Remplacer tout le thème peut supprimer des fonctionnalités légitimes. Ici, le mieux est une comparaison et un nettoyage ciblé, tant que vous savez ce que vous supprimez.
Petit guide de contrôle après désinfection
Une fois la désinfection terminée, je fais une série de contrôles qui ne prennent pas des heures, mais qui évitent des mauvaises surprises.
Je vérifie que le rendu est propre sur plusieurs types de pages, que le code source ne contient plus de fragments qui ressemblent à de l’injection, et que les logs ne montrent pas de réapparition de comportements suspects.
Je surveille aussi la base: absence de nouveaux contenus créés automatiquement, absence d’options modifiées à https://gardewp.fr/ nouveau, et pas de nouveaux fichiers récemment ajoutés ou modifiés dans les zones sensibles.
Enfin, si vous utilisez un plugin de cache ou un CDN, purgez le cache et vérifiez depuis plusieurs contextes. Sinon, vous pouvez croire que le spam revient alors qu’il ne fait que persister via un cache.
Deux erreurs qui font perdre du temps
La première, c’est supprimer uniquement le contenu visible, sans neutraliser le mécanisme d’injection. Résultat: le spam revient, parfois avec d’autres mots-clés, et vous perdez du temps à “corriger” au lieu de “traiter”.
La seconde, c’est remplacer des fichiers sans vérifier ce qui a été gardé. Si la base de données reste polluée et que le code d’injection s’appuie sur des options, vous pouvez restaurer des fichiers propres, mais l’injection continue via la base.
Le bon réflexe est de lier les deux: source de l’injection et état de la base.
Points clés à retenir pour supprimer durablement l’injection
La désinfection d’un WordPress infecté par du SEO spam n’est pas seulement une question de propreté. C’est une restauration de confiance technique.
Si vous deviez garder quelques principes, ce sont ceux-ci: sauvegarder et isoler, diagnostiquer le point de déclenchement, neutraliser l’accès persistant, puis reconstruire proprement les zones modifiées. Ensuite seulement, vous supprimez les contenus et vous contrôlez la réinfection.
Désinfection WordPress, au quotidien, c’est moins spectaculaire qu’on l’imagine. Souvent, c’est une succession de détails bien observés: une date de modification inhabituelle, un hook discret, une option de base de données qui contient du HTML, un compte oublié, un cache qui ment, et une règle de sécurité qui manque.
Si vous êtes confronté à ce type d’incident, vous gagnerez en efficacité si vous abordez le problème comme un enquêteur, pas comme un pompier. Agir vite est nécessaire, mais comprendre ce qui a été altéré vous évite de revenir à zéro.