Quand un site WordPress se met à rediriger ses visiteurs, la première idée consiste souvent à chercher un plugin “bizarre”, un fichier injecté, ou un problème de thème. Oui, dans beaucoup de cas, c’est bien ça. Mais les redirections liées au malware SEO ont une particularité qui rend l’opération plus délicate: elles peuvent être conditionnelles, difficiles à reproduire en navigation “classique”, et invisibles à l’œil nu tant qu’on ne déroule pas le bon scénario (agent utilisateur, pays, cache CDN, chargement asynchrone, récupération différée).
J’ai vu des sites qui “avaient l’air” sains en surfant depuis le navigateur du propriétaire, mais qui renvoyaient les visiteurs depuis Google, depuis certains réseaux, ou après quelques secondes de latence. Sur un mandat récent, on a découvert la redirection non pas sur la page d’accueil, mais sur un fichier texte chargé après le rendu du DOM. Résultat, les logs faisaient apparaître des séquences incompréhensibles, et le CMS restait parfaitement “normal” pour les utilisateurs authentifiés.
L’objectif de ce guide est de vous donner une méthode solide pour nettoyer un site WordPress infecté par des redirections, comprendre comment ces infections fonctionnent, et éviter les “faux nettoyages” qui finissent par réinfecter votre infrastructure ou votre SEO.
Les redirections malware SEO: pourquoi ça marche
Le malware SEO cherche rarement la destruction. Il cherche surtout le trafic. Le mécanisme est souvent le suivant: le site est compromis, puis des scripts ou des fichiers sont modifiés pour envoyer certains visiteurs vers des pages parasites, fréquemment hébergées ailleurs. On retrouve deux logiques très fréquentes.
La première est la redirection côté serveur. Un fichier PHP détourné renvoie une URL différente selon des conditions. Vous tapez votre domaine, et au lieu de servir votre page, le serveur renvoie une réponse 301, 302, voire une réponse au comportement hybride. La seconde est côté client. Dans ce cas, le navigateur récupère un script ou une ressource injectée, et la redirection s’effectue en JavaScript. L’utilisateur “voit” la page quelques secondes, puis bascule.
Ce qui complique la chasse, c’est la conditionnalité. Un même site peut être clean pour votre session, mais rediriger pour un bot. Sur beaucoup d’incidents, les filtres ressemblent à ça, en termes d’intention (je simplifie volontairement): ne pas rediriger si l’utilisateur est connecté, ne pas rediriger si le referer ne correspond pas à une liste, rediriger uniquement si l’utilisateur arrive depuis un moteur de recherche, ou encore, rediriger uniquement certains User-Agent.
Enfin, il y a la couche infrastructure: cache, CDN, WAF, plugins de performance. Une redirection injectée peut être servie depuis un cache pendant des heures, même après suppression du code malveillant. Et à l’inverse, certains outils de diagnostic peuvent “nettoyer” le symptôme en vous testant dans des conditions différentes (sans cookies, sans cache identique, ou avec un navigateur qui n’exécute pas le script de la même façon).
Premiers réflexes: sécuriser avant de nettoyer
Avant de modifier quoi que ce soit dans WordPress, votre priorité est d’éviter d’aggraver la compromission. On a tendance à vouloir “supprimer tout ce qui semble bizarre” immédiatement. Le problème, c’est que vous pouvez casser une logique d’authentification, ou pire, détruire des traces utiles pour comprendre l’origine de l’infection.
Sur un site compromis par redirections, j’applique un enchaînement simple, parce que ça limite le risque de perte de données et accélère le diagnostic. D’abord, je passe le site en mode maintenance ou je limite l’accès à l’administrateur, le temps de travailler. Ensuite, je conserve une copie des fichiers et de la base de données, ou au minimum un export de la base et un backup complet du répertoire WordPress, media compris.
Si votre hébergeur propose un snapshot avant intervention, c’est souvent le meilleur compromis. En pratique, un “clean” trop tôt, sans capture de l’existant, finit souvent en réinfection plus lente à comprendre. Et si l’incident s’est déjà étendu (compte admin ajouté, utilisateur créé, clé API modifiée, tâches planifiées), l’absence de copie vous prive d’indices.
Pendant cette phase, changez aussi les mots de passe, mais pas de façon brutale sur l’intégralité “à l’aveugle” si vous n’avez pas encore identifié le vecteur. Idéalement, vous commencez par les comptes à privilèges (administrateur, éditeur si vous leur faites confiance, comptes ayant accès au FTP ou à l’hébergement), puis vous vérifiez les sessions en cours et les clés d’API. Si vous avez le moindre doute sur des credentials FTP ou SFTP, je conseille de les invalider côté hébergeur.
Comprendre ce que WordPress sert réellement
Une infection par redirection peut être placée à plusieurs endroits. Le “bon” endroit à chercher dépend de la symptomatique.
Si vous observez des HTTP 30x, regardez d’abord les en-têtes et la chaîne de redirection. Un diagnostic efficace consiste à relever la réponse exacte, le statut, et l’URL cible telle qu’elle est renvoyée. Ensuite, vérifiez si la redirection intervient dès la première requête ou après un chargement de ressource (par exemple un script chargé depuis /wp-content/…).
Si vous observez des redirections “visuelles” qui arrivent après quelques secondes, suspectez fortement un script injecté dans un fichier chargé au front: header.php, footer.php, un fichier dans un thème enfant, ou une ressource ajoutée via wp enqueuescript. Dans ces cas, les fichiers malveillants peuvent être obfusqués: noms de variables minimaux, concaténations, base64 encodée, ou fonctions de décodage déclenchées uniquement si certains cookies ou paramètres existent.
Un piège classique: les modifications ne sont pas forcément dans un fichier PHP “principal”. Parfois, c’est un fichier inclus depuis un emplacement discret: un modèle de page, un fichier d’option, ou un bootstrap chargé par une action. Et parfois, la redirection se fait via un fichier ajouté au hasard dans wp-content ou même dans la racine, si l’attaquant a obtenu assez de droits pour écrire n’importe où.
Reproduire le symptôme comme le ferait un visiteur ciblé
Pour nettoyer correctement un site WordPress infecté, il faut arriver à reproduire le comportement. Beaucoup d’interventions échouent parce que l’équipe ne vérifie le site que depuis son propre poste, sans cookies équivalents, sans cache similaire, et parfois sans exécuter les scripts.
Je recommande de tester au moins trois scénarios réalistes:
- Un test “navigateur normal” en session non connectée (cookies de session propres). Un test en “mode privé” ou avec un profil isolé, pour s’affranchir des cookies persistants. Un test qui simule les conditions d’un moteur de recherche, avec un accès direct à la page qui redirige.
Selon les hébergeurs, la redirection peut aussi dépendre du pays ou de l’IP. Si votre trafic est géographiquement concentré, testez aussi depuis un réseau différent. Sur un cas précédent, la redirection ne s’activait que depuis une plage IP “partenaire” utilisée par une partie des visiteurs, ce qui rendait le bug presque invisible au propriétaire.
Vous pouvez aussi analyser le navigateur en inspecteur, onglet “Network”, pour identifier la ressource qui provoque la bascule. Quand vous voyez un script de taille inhabituelle, un fichier nommé sans logique, ou une requête vers une URL externe qui n’a rien à faire là, vous tenez enfin la piste.
Nettoyer site WordPress infecté: la méthode qui évite la réinfection
Le nettoyage doit être méthodique. Le but n’est pas seulement de supprimer ce que vous voyez, c’est de revenir à un état maîtrisé, puis de vérifier l’absence de persistance.
La méthode la plus sûre, quand le site est suffisamment important, consiste à combiner deux approches: restauration et audit. Restauration veut dire remettre les fichiers WordPress “de base” et les thèmes/plugins à des versions connues, mais seulement après avoir compris ce qui a été modifié et pourquoi. L’audit veut dire vérifier aussi le reste: utilisateurs, options, fichiers uploadés, et planification.
Dans les infections par redirections, je commence souvent par les zones où l’on trouve le plus de persistance:
- fichiers PHP dans le thème, le thème enfant, et parfois dans wp-includes ou la racine plugins installés ou mises à jour récentes, surtout ceux qui modifient le head, le footer, ou injectent du JavaScript injections dans la base: options, meta, ou configurations qui déclenchent un script malveillant tâches cron (WordPress pseudo-cron) ou scripts système si l’attaquant a réussi à planifier des exécutions
Le choix entre “désinstaller tout” et “supprimer uniquement le mal” dépend de votre contexte. Si vous avez beaucoup de plugins, une désinstallation massive peut casser le site et retarder la remise en ligne. En revanche, supprimer “uniquement le fichier suspect” sans vérifier la persistance est une erreur fréquente: vous nettoyez la redirection, mais un mécanisme de régénération peut réécrire le code à la prochaine requête ou via une tâche.
Signes qui orientent la recherche
Voici les signaux les plus utiles en pratique, ceux que je surveille avant même de plonger dans les fichiers.
- Redirection déclenchée uniquement quand l’utilisateur n’est pas connecté ou quand le navigateur est celui d’un bot Fichiers récemment modifiés avec des timestamps incohérents, particulièrement dans wp-content Scripts obfusqués ou ressources externes ajoutées sans rapport avec votre thème ou vos plugins Présence d’utilisateurs ou de rôles admin ajoutés sans intervention Incohérences entre l’interface WordPress et le contenu servi (fichier modifié, mais page affichée “normalement” une partie du temps)
Ces indices ne confirment rien à eux seuls, mais ils réduisent énormément la surface.
Où regarder en priorité sur un WordPress compromis
Sans faire une liste exhaustive (la chasse aux infections peut devenir interminable), je vous donne les zones où j’ai trouvé le plus de modifications lors d’incidents de redirection.
Commencez par comparer les fichiers actuels aux versions attendues. Si vous avez un thème custom, vous ne pouvez pas remplacer aveuglément. Mais pour le cœur WordPress, vous pouvez quasiment toujours restaurer à une base saine. Les redirections sont rarement dans les fichiers core “par accident”, elles sont presque toujours le résultat d’une écriture après compromission.
Ensuite, inspectez les fichiers PHP des thèmes et plugins actifs et récents. Dans beaucoup d’attaques, le code malveillant se cache dans un des fichiers qui s’exécutent pendant le rendu: un template, un hook d’action, ou un fichier d’options. Sur certains cas, j’ai vu l’ajout de quelques lignes qui semblent anodines, mais qui charge une fonction de décodage et déclenchent une redirection selon une condition.
Pour la base de données, WordPress stocke beaucoup de configuration dans des options et des postmeta. Une injection peut aussi viser un champ meta de page, qui ajoute ensuite du JavaScript via un hook. Il arrive que la page “affiche” votre contenu, mais que l’on ajoute un script à la fin via un champ d’éditeur, ou via une routine qui lit un champ spécifique.
Ne négligez pas non plus wp-config.php. Une redirection peut être déclenchée via la configuration, même si c’est moins fréquent. Si l’attaquant change des clés, modifie des variables, ou injecte un chargement conditionnel, vous devez traiter cela comme un indice majeur.
Enfin, regardez les uploads. Certains malwares SEO ajoutent des fichiers dans wp-content/uploads, images ou fichiers texte camouflés. https://gardewp.fr/nettoyage-malware-wordpress/ La redirection peut alors passer par un fichier externe ou un script stocké “comme un asset”.
Nettoyage concret: approche d’intervention
Le moment de supprimer du code et de restaurer les composants demande une discipline. Voici comment je procède, sans improviser.
D’abord, j’isole. Le site passe en maintenance, et je coupe si nécessaire les accès publics. Ensuite, je fais un inventaire rapide: plugins installés, thème actif, date de dernière modification, comptes admin, et toute tâche planifiée visible dans WordPress. Je vérifie aussi les journaux de l’hébergement si vous y avez accès, en particulier les pics d’erreurs 404 inhabituels, ou les appels répétés à un fichier suspect.
Ensuite, je remplace ce qui est remplaçable. Pour le cœur WordPress, je restaure le set standard. Pour les thèmes, je distingue thème custom et thème standard. Si un thème custom est fortement modifié, je n’ai pas de recette universelle, mais je compare avec votre version de source si vous la conservez, ou j’élimine les morceaux non justifiés.
Puis, je nettoie la base. Sans “sur-nettoyer” et casser vos contenus, je supprime les options et entrées qui servent de déclencheurs, pas vos posts. C’est là que les copies et les exports sont utiles, vous pouvez revenir en arrière.
Le “mini plan” que je teste à chaque fois
Mettre le site en maintenance et sauvegarder fichiers + base Identifier la ressource ou le fichier qui déclenche la redirection (test navigateur + network) Restaurer WordPress core et éliminer les modifications dans thèmes/plugins suspects Vérifier utilisateurs, rôles, options et éventuels cron cachés Refaire un test “session non connectée” après purge cache/CDNCe plan évite le principal piège, le nettoyage partiel: vous supprimez un script, mais la persistance reste active.
Surveiller la persistance après suppression
Nettoyer un site WordPress infecté par des redirections, ce n’est pas seulement “supprimer le mauvais fichier”. C’est aussi vérifier que personne ne peut le régénérer.
Les attaquants utilisent parfois une persistance via:
- un plugin malveillant qui se réinstalle, ou qui réécrit des fichiers via init hooks un compte admin caché, qui remet le code au prochain login une modification d’options, qui injecte à nouveau du code via un hook un cron qui appelle un script externe ou un endpoint interne
Pour détecter la régénération, je surveille les timestamps des fichiers suspects après plusieurs chargements. Si, en quelques minutes, un fichier revient ou change à nouveau, vous avez un mécanisme de réécriture. Dans ce cas, vous coupez la capacité d’exécution du point de persistance avant de continuer à restaurer.
Si vous utilisez un CDN, n’oubliez pas la purge. Le cache peut servir une redirection même après correction. Et pire, un cache peut masquer une erreur corrigée, ce qui vous pousse à “modifier encore” et à casser. Je recommande une purge ciblée après correction, puis un test immédiat sans cache.
Sécuriser après nettoyage: le vrai coût évite la rechute
Un nettoyage réussi, sans sécurité renforcée, se transforme en exercice répétitif. Les infections par redirection reviennent souvent pour une raison simple: la faille d’origine n’a pas été fermée.
Les causes fréquentes que je vois dans les incidents de ce type:
- identifiants compromis (mot de passe réutilisé, fuite, mot de passe faible) exploitation d’une vulnérabilité plugin ou thème obsolète configuration WordPress ou hébergement permissive, permettant l’écriture ou l’exécution indésirable FTP/SFTP avec comptes trop ouverts, sans séparation stricte des droits
La bonne sécurisation ne doit pas être trop “théorique”. Elle doit être actionnable. Par exemple, activez l’authentification à deux facteurs si c’est possible, surtout pour les comptes admin. Mettez à jour les plugins et thèmes, et supprimez ceux qui ne servent plus. Vérifiez aussi les rôles: un éditeur n’a pas besoin de droits d’installation de plugins, ni d’accès aux zones techniques.
Sur le plan technique, un pare-feu applicatif ou des règles spécifiques peuvent aider, mais la logique reste la même: même si vous bloquez la redirection une fois, une compromission peut se produire à nouveau si la porte d’entrée existe.
Vérifications finales avant remise en ligne
Avant de republier et de laisser le site ouvert, je fais des tests que je peux répéter. Le but n’est pas d’avoir l’impression que “ça marche”, c’est d’être certain que le symptôme est parti dans les conditions où il revient.
Après nettoyage, je revalide au minimum:
- accès sans session (cookies propres) pages types qui étaient redirigées comportement sur mobile et desktop, car certains malwares conditionnent le script absence de redirections 30x inattendues absence de chargements externes non justifiés
Si votre site avait été repéré par des navigateurs ou signalé par des outils de sécurité, surveillez les symptômes sur une période un peu plus longue. Les caches et les indexing moteurs peuvent continuer à afficher des signaux pendant un moment. L’important est de rétablir un état stable.
Et vos performances SEO dans tout ça?
Quand le malware SEO redirige, il peut aussi laisser des traces indirectes: contenu indexé qui n’existe plus, variations de pages servies temporairement, ou signaux de comportement qui font baisser la confiance côté moteurs. Les moteurs peuvent mettre du temps à reconsidérer la situation, même si vous avez nettoyé vite.
Ce que je conseille, c’est d’attendre un rétablissement stable avant de pousser des changements SEO en masse. Une période de stabilisation, avec logs et vérifications, vaut souvent plus qu’une série de modifications éditoriales pendant que le site recompose son comportement.
Si vous utilisez des outils de type Search Console et que vous avez eu des alertes, surveillez la reprise d’un état normal. Le nettoyage en lui-même ne suffit pas à rétablir la confiance, mais il est la condition obligatoire. Tout le reste doit venir après, quand vous pouvez prouver que les redirections ont cessé dans les conditions de test attendues.
Cas particuliers: redirections qui ne se voient pas en “simple navigation”
Parfois, vous ne reproduisez pas le problème en tapant l’URL. Ça peut arriver quand:
- la redirection ne s’active que sur des pages spécifiques, rarement visitées la redirection dépend d’un header, ou d’un referer la redirection dépend de la résolution ou de la capacité du navigateur le site n’injecte le script malveillant qu’après un délai le cache CDN sert une version différente de celle que vous testez
Dans ces cas, l’inspection “Network” devient votre meilleure alliée. Cherchez une ressource qui n’existait pas avant, un script qui arrive avec une URL externe inhabituelle, ou un fichier chargé depuis votre domaine mais dont le contenu n’a pas de sens.
La bonne posture, c’est de partir du symptôme mesurable. Une redirection exploite presque toujours un point observable: une réponse 30x, une requête réseau, un script injecté, une modification de template. Si vous restez bloqué, ce n’est pas parce que l’infection est introuvable, c’est parce que vous ne suivez pas la même chaîne de requête que l’attaque.
Garder une longueur d’avance
Après un incident, j’ai pris l’habitude d’un suivi simple. Sans transformer votre site en usine de monitoring, je garde:
- une routine de vérification des fichiers récemment modifiés une revue périodique des plugins et des mises à jour une check rapide des comptes avec privilèges une trace des changements de configuration une stratégie de backups testés, pas seulement “faits”
Ce sont des mesures modestes, mais elles changent le jeu. Si demain vous constatez à nouveau une redirection, vous identifiez beaucoup plus vite ce qui a changé entre hier et aujourd’hui.
Si vous êtes en train de nettoyer, l’étape la plus importante est de ne pas se limiter au “symptôme visible”. Les redirections malware SEO sont conçues pour vous détourner vers le mauvais fichier, ou pour n’apparaître que dans certaines conditions. Un nettoyage sérieux combine reproduction du comportement, identification du point d’injection, restauration des éléments contrôlables, puis validation de l’absence de persistance, avec tests en session non connectée et purge des caches. C’est cette discipline qui fait la différence entre un site “qui semble revenu” et un site réellement réparé.