Enlever virus WordPress : que faire si votre site affiche une redirection

Voir son site WordPress basculer vers une autre page, ou afficher une redirection “bizarre”, est souvent le premier signal qu’il se passe quelque chose d’anormal. Parfois, ce n’est qu’un souci de configuration (plugin de redirection mal réglé, URL forcées, cache de CDN). Mais dans d’autres cas, c’est la jambe de bois classique d’un site compromis: du code injecté, une règle de redirection en htaccess, un script malveillant ajouté dans un plugin ou un thème, ou un compte administrateur utilisé à votre insu.

Je l’ai déjà vu sur des sites où la redirection apparaissait seulement sur mobile, ou uniquement après connexion. Dans ces cas-là, chercher “trop vite” le mauvais fichier fait perdre des heures. L’objectif, c’est de stopper l’hémorragie, puis d’assainir proprement. Et surtout, de ne pas “nettoyer” sans vérifier l’origine, sinon le site revient à l’état infecté dès le prochain déclencheur.
Comprendre ce que signifie “redirection” sur un site WordPress
Une redirection, ce n’est pas un diagnostic en soi. C’est un symptôme. La page “cassée” peut être renvoyée vers une URL externe, parfois avec des paramètres étranges, parfois en boucle. Le plus important est de situer le point de bascule.

Sur un WordPress, une redirection peut venir de plusieurs couches:
le serveur web (Apache, Nginx, règles dans le fichier de configuration, htaccess) WordPress (réécritures, hooks, options dans la base, scripts injectés) un plugin ou un thème (fonction PHP qui fait wp_redirect, balises de script dans le header) un service intermédiaire (Cloudflare, CDN, WAF, plugin de cache) le navigateur (extension, DNS, ou cache local), plus rarement mais ça existe
Dans la pratique, je commence toujours par distinguer redirection “côté serveur” et redirection “côté navigateur”. Un simple test en navigation privée aide, mais ce n’est pas suffisant. Il faut observer l’URL de destination, le statut HTTP, et la présence d’indices dans la page reçue.

Si la redirection envoie vers un domaine sans rapport, si des paramètres ressemblent à du tracking agressif, ou si vous voyez du JavaScript injecté, il faut traiter le problème comme une tentative de compromission jusqu’à preuve du contraire. C’est exactement le cas où l’on parle d’enlever virus WordPress, même si, techniquement, le mot “virus” ne décrit pas toujours la méthode utilisée.
Les premiers signes qui orientent vers une compromission
Certaines redirections sont “propres” et légitimes, par exemple après une modification de permaliens ou une règle de redirection SEO. D’autres sentent l’infection.
Signes fréquents (et assez parlants)
La redirection s’accompagne souvent de un ou plusieurs de ces comportements:
des URL de destination externes, sans lien avec votre marque ou votre thème des pages “fantômes” qui n’existent pas dans votre médiathèque ni dans votre base des comptes utilisateurs qui semblent avoir été créés “toute seuls” des fichiers PHP modifiés récemment dans des emplacements inattendus (thème enfant, uploads, plugins) une montée inhabituelle de requêtes vers des endpoints, parfois visible via les logs
Si vous observez au moins deux de ces éléments, je ne perds pas de temps à espérer que “ça va passer”. Je mets le site en mode de stabilisation, puis je fais le tri.
Stopper l’incident avant de courir partout
Avant d’ouvrir tous les fichiers comme un chirurgien pressé, vous voulez réduire la surface de l’infection. Souvent, la redirection est déclenchée par une règle ou un morceau de code qui s’exécute à chaque requête. Chaque minute où le site reste accessible augmente les risques: nouvelles modifications, réindexation par les moteurs de recherche, et diffusion involontaire de contenu indésirable.

Le bon réflexe dépend de votre niveau de contrôle, mais l’idée reste la même: isoler, sauvegarder, puis assainir.
Un mini plan d’urgence à suivre sans se compliquer la vie
Voici l’approche que je recommande dans l’immédiat, même si vous n’avez pas encore identifié la source exacte:
Mettez le site en maintenance (ou limitez l’accès à certains IP si possible) Faites une sauvegarde complète, fichiers et base de données, avant toute modification Bloquez temporairement l’exécution de PHP non nécessaire si vous savez le faire (sans casser le site) Changez les mots de passe et déconnectez les sessions, une fois la sauvegarde en place Vérifiez les redirections depuis un navigateur en navigation privée, puis notez la destination exacte
Cette séquence évite le piège classique, “j’ai nettoyé, puis je ne comprends plus ce qui a changé”. Une sauvegarde préalable vous rend serein.
Repérer la source de la redirection: où est le déclencheur ?
La meilleure question à vous poser est simple: “qu’est-ce qui décide de renvoyer vers l’autre URL ?” Sur WordPress, j’y réponds en observant trois éléments: la destination, le code source de la page renvoyée (ou le HTML de la réponse), et les règles serveur.
Observer la réponse réelle, pas seulement le rendu
La redirection peut être une réponse HTTP 301 ou 302, ou un affichage qui charge un script qui redirige ensuite. Si vous ne regardez que ce que vous voyez à l’écran, vous pouvez passer à côté d’une injection de script.

Essayez de regarder le statut HTTP et l’en-tête location si c’est disponible dans votre outil navigateur (devtools), ou dans un utilitaire de test HTTP. Si vous voyez un Location: https://... externe, on est probablement sur une redirection côté serveur ou côté PHP.

Ensuite, regardez le contenu renvoyé. Si la page contient des bouts de JavaScript en haut de page, souvent cachés, ou des chaînes base64, c’est un indice d’injection. Sur WordPress, ces injections finissent fréquemment dans:
des fichiers de thème ou de plugins infectés le fichier index.php ou functions.php, mais aussi parfois des fichiers annexes des options stockées dans la base qui ajoutent du contenu via hooks Vérifier les règles dans .htaccess (si Apache)
Beaucoup de sites compromis ajoutent des lignes dans le fichier .htaccess. Parfois, ce n’est même pas énorme. Une seule règle suffit à déclencher une redirection vers un domaine malveillant.

Ce que je cherche, c’est:
des règles RewriteRule vers un domaine externe des conditions basées sur user-agent des règles qui s’activent seulement sur certaines routes des patterns “bizarres” autour de WordPress (par exemple des blocs qui commencent et finissent sans logique claire)
Attention, le fichier peut contenir des directives normales liées à vos permaliens. C’est pour ça que je m’appuie sur la sauvegarde et sur la comparaison avec une version saine si vous en avez une.
Contrôler aussi les configurations Nginx
Si votre serveur est en Nginx, vous ne verrez pas .htaccess. Dans ce cas, la redirection peut venir d’un fichier de configuration ou d’une règle ajoutée dans le panneau d’administration du serveur. Si vous avez accès via un panneau d’hébergement, regardez les “redirections” gérées côté hébergeur, puis les conf du vhost.

Quand on ignore cette couche, on passe du temps à inspecter WordPress alors que le déclencheur est ailleurs. Ce genre de décalage arrive plus souvent qu’on ne le croit.
Nettoyage: enlever virus WordPress sans casser le site
Assainir sans perdre l’intégrité du site, ça demande méthode. Il y a un moment où on doit “couper” pour rétablir la confiance, même Regardez plus d'informations https://gardewp.fr/nettoyage-malware-wordpress/ si c’est inconfortable.
La première décision: isolation du plugin et du thème
Quand un site se met à rediriger après une mise à jour ou l’ajout d’un plugin, on a souvent un coupable. Mais si l’infection est déjà là, ce n’est pas le plugin le plus récent qui est forcément la porte d’entrée. Il peut juste être le vecteur.

Le réflexe le plus sûr, c’est:
désactiver tous les plugins (via l’interface si elle marche, sinon par renommage du dossier) basculer sur un thème par défaut si possible vérifier si la redirection disparaît
Si la redirection ne se produit plus après désactivation, vous avez gagné un diagnostic. Ensuite, vous réactivez en lot pour trouver l’élément fautif, sans repartir de zéro.
Rechercher les fichiers modifiés, avec une logique simple
Sans tomber dans le perfectionnisme, je compare les fichiers récemment modifiés, surtout dans:
wp-content/plugins/ wp-content/themes/ wp-content/uploads/ (certains attaquants déposent des fichiers ou des scripts) les fichiers PHP à la racine si quelque chose a changé là
Vous ne cherchez pas “le virus”, vous cherchez “l’anomalie”. La plupart du temps, on repère un fichier avec une date de modification récente, ou un contenu qui contient des fonctions de redirection inhabituelles, des appels vers eval, base64_decode, gzinflate, ou des chaînes qui ressemblent à du téléchargement distant.

Si vous trouvez un fichier PHP modifié, ne le “corrigez” pas à la volée. Le plus propre consiste à le remplacer par une version saine, provenant de la source officielle (ou du ZIP de votre déploiement), puis à vérifier que le fichier n’est pas réinjecté.
Quand remplacer est plus rapide que réparer
Réparer à la main peut sembler rapide, mais ça peut aussi créer un mélange impossible à maintenir. Par exemple, un plugin peut contenir une petite injection au milieu d’un fichier. Vous supprimez la partie suspecte, ça marche une journée, puis l’injection revient car la logique malveillante était ailleurs (autre fichier inclus, cron, option base).

Dans ces cas, remplacer le plugin ou le thème par une version saine est souvent plus fiable. Ensuite, vous inspectez les options et la base, et vous regardez comment l’attaquant a réussi à modifier le site.
Nettoyage dans la base: les options et utilisateurs sont souvent le vrai problème
Même si la redirection semble venir de .htaccess ou d’un fichier PHP, le contrôle revient souvent à des données dans la base. Un attaquant peut:
ajouter un utilisateur admin modifier des options WordPress insérer du contenu via la table des options ou de certains plugins créer des “scheduled events” pour réinjecter le contenu Vérifier les utilisateurs et les rôles
Je commence par la liste des utilisateurs. Si je vois des noms inconnus, des emails bizarres, ou des utilisateurs récents avec des rôles élevés, c’est un signal fort. Dans une stratégie de remédiation réaliste, je supprime ceux qui ne devraient pas exister.

Mais attention à un détail vécu: parfois, vous avez un utilisateur légitime que vous reconnaissez, mais il a été compromis. Dans ce cas, le problème n’est pas seulement l’utilisateur. Il faut vérifier la source de compromission, puis changer les identifiants et vérifier si des sessions ou des clés API ont été générées.
Surveiller les événements planifiés
WordPress a un système d’événements planifiés (WP-Cron). Une infection peut utiliser ça pour réinjecter du code ou modifier des options à intervalles réguliers. Si la redirection revient alors que vous avez remplacé plusieurs fichiers, pensez à WP-Cron.

Vous pouvez inspecter les cron jobs via des plugins d’administration ou via des outils, selon votre environnement. L’idée est de repérer des actions “fantômes” et de les supprimer, puis de supprimer aussi la cause.
Vérifier les vecteurs d’entrée: pourquoi l’infection est arrivée
Vous pouvez enlever virus WordPress et tout nettoyer, mais si vous laissez la porte ouverte, vous serez de nouveau attaqué. C’est là que la partie “post-mortem” devient utile.

Les causes les plus fréquentes que je rencontre sur des sites WordPress comprennent:
mots de passe faibles ou réutilisés thème ou plugin obsolète avec une vulnérabilité connue mots de passe volés via phishing, ou accès compromis à l’hébergement permissions de fichiers trop larges manque de mise à jour, ou absence de surveillance
Un détail qui revient souvent: quand l’accès initial arrive via un plugin, le site peut rester “fonctionnel” pendant un temps. Ce n’est que lorsque l’attaquant déclenche son script de redirection que vous le remarquez.
Protéger après nettoyage: sécuriser sans immobiliser votre site
Une fois le site assaini, l’étape suivante consiste à réduire les chances de récidive. La sécurité WordPress n’est pas un interrupteur marche-arrêt, c’est un ensemble de barrières. L’objectif est d’éviter les failles faciles, et de détecter vite ce qui se passe.
Renforcer les identifiants et l’accès
Changez les mots de passe de tous les comptes administrateur. Si vous utilisez la double authentification, réactivez-la. Déconnectez les sessions, surtout si vous avez remarqué une activité anormale.

Si vous avez des accès via FTP, SSH, ou via un panneau d’hébergement, changez aussi ces identifiants. L’attaquant peut ne pas viser WordPress directement. Il vise souvent le système, et WordPress n’est que le terrain.
Mettre à jour, mais avec discernement
Mettre à jour “tout” est utile, mais j’ai déjà vu des mises à jour qui cassent un site de production à cause d’une dépendance fragile. La solution équilibrée, c’est:
mettre à jour cœur WordPress mettre à jour plugins et thèmes, au moins ceux qui sont actifs et ceux qui ont des vulnérabilités connues tester sur un environnement de staging si vous en avez un
Si votre site ne peut pas être mis en staging, vous mettez à jour par lots et vous surveillez la page pendant quelques heures. Ça paraît moins sexy, mais en pratique ça évite les régressions pendant la période où vous êtes déjà sous tension après une infection.
Mettre en place une surveillance utile
La surveillance a deux buts: détecter vite et fournir des preuves. Une surveillance “au doigt mouillé” ne sert pas. Ce que vous voulez, ce sont des alertes sur:
nouveaux utilisateurs modifications de fichiers sensibles pics de trafic vers des URLs anormales erreurs HTTP inhabituelles
Si votre hébergeur propose des logs et alertes, utilisez-les. Sinon, vous pouvez combiner un outil de sécurité WordPress et une surveillance serveur.

Je préfère aussi garder un historique. Un simple suivi des dates de modification des plugins actifs aide. Quand quelque chose change, vous savez quoi regarder.
Cas concrets: trois scénarios typiques et ce que j’ai fait
Pour rendre tout ça moins abstrait, voici des situations réelles qui ressemblent à ce que vous pouvez vivre.
Scénario 1: redirection uniquement sur certaines pages
Le site renvoyait vers une page externe uniquement pour des URLs de type “produit” ou “article ancien”. En inspectant la réponse, la redirection venait de fonctions ajoutées dans le thème. La correction n’était pas de “retirer la redirection visible”, mais de remplacer le thème par sa version saine, puis d’enlever des hooks ajoutés dans un fichier différent que le code de redirection appelait ensuite.

Le retour de l’infection s’était produit une fois, parce que la correction avait été partielle. Remplacer complètement a réglé le problème.
Scénario 2: boucle de redirection après mise à jour
Sur un autre site, la redirection en boucle apparaissait après une mise à jour, alors que l’équipe était persuadée d’avoir “tout mis à jour proprement”. Le déclencheur était finalement un plugin de cache qui utilisait une logique de redirection interne. En désactivant temporairement le plugin, tout revenait normal, mais une analyse plus poussée a montré que des entrées dans l’option de redirection avaient été modifiées.

Ici, le site n’avait pas été “infecté” au sens strict du terme, mais le symptôme imite très bien une compromission. La méthode d’observation de la réponse et la vérification des options a évité une fausse conclusion.
Scénario 3: redirection après connexion administrateur
Le site paraissait normal pour le public, puis redirigeait l’administrateur vers un domaine externe après connexion. C’est un cas fréquent quand l’attaquant a modifié un profil ou a ajouté une règle conditionnelle. Dans ce scénario, les fichiers principaux n’étaient pas les plus modifiés. Le déclencheur était une logique liée à un hook exécuté seulement pour certains rôles.

Le nettoyage complet a nécessité:
retrait du code injecté dans un fichier de thème remplacement du plugin lié à la personnalisation suppression d’un utilisateur et changement de mots de passe
Ce genre de cas m’apprend une règle, si vous ne testez qu’en navigation anonyme, vous pouvez rater une condition.
Questions fréquentes avant de “réinstaller” WordPress
Beaucoup de gens pensent que la solution consiste à réinstaller WordPress par-dessus. Ce n’est pas faux, mais ce n’est pas toujours suffisant.

Si la redirection vient de la base, réinstaller sans nettoyer la base ne règle pas le fond. Si la redirection vient d’un plugin infecté, réinstaller WordPress n’empêche pas le plugin infecté de réactiver le comportement.

La bonne approche, c’est de traiter le site comme compromis jusqu’à preuve du contraire, de supprimer ce qui est anormal, puis de vérifier les données.
Quand demander de l’aide rapidement
Si vous n’avez aucune idée de ce que vous allez inspecter, ou si le site est vital pour votre activité, vous pouvez gagner du temps en sollicitant un professionnel. Non pas pour “faire joli”, mais parce que la séquence la plus efficace dépend de votre hébergeur, de votre stack, et de la nature exacte de la redirection.

Je recommande d’accélérer l’escalade si:
la redirection revient après nettoyage vous avez des comptes compromis, ou des identifiants possiblement exfiltrés vous voyez une infection qui touche plusieurs plugins à la fois votre site est blacklisté ou vous avez des signaux Google Search Console (sans promettre de résultat immédiat) vous suspectez une compromission d’hébergement, pas seulement WordPress
Le coût du “on réinstalle et on verra” est parfois plus élevé que celui d’une remise en état structurée.
Checklist de vérification après correction (la partie qu’on oublie)
Après avoir enlevé la cause apparente, je fais toujours une série de vérifications avant de rouvrir complètement le site au public. Cette étape évite d’annoncer “c’est bon” trop tôt.

Je fais ces contrôles en navigation privée, sur plusieurs appareils, et je surveille quelques heures, puis 24 heures si possible. Je vérifie aussi que les permaliens et les redirections internes fonctionnent, pour éviter une confusion entre redirection malveillante et redirection “légitime” liée à votre configuration.

Si tout semble normal, je reviens ensuite vers une vérification plus précise:
fichiers et thèmes revenus à une version saine plugins actifs cohérents utilisateurs et rôles stables cron jobs nettoyés si anomalie absence de nouvelles modifications immédiates
C’est souvent cette dernière étape qui révèle que l’infection n’a pas été entièrement éradiquée, par exemple via un mécanisme encore actif.
Conclusion de l’approche: agir vite, vérifier la cause, puis verrouiller
Une redirection sur WordPress est un symptôme bruyant. Ce qui compte, c’est la source du déclencheur et la persistance. En pratique, enlever virus WordPress dans ce contexte ne se limite pas à “effacer du code”. C’est stopper l’incident, sauvegarder, analyser où la redirection naît, remplacer ce qui est corrompu, puis sécuriser l’accès pour empêcher le retour.

Si vous voulez, dites-moi ce que vous observez exactement: la destination de la redirection (domaine, protocole), le moment où elle apparaît (au chargement de la page, après connexion, uniquement sur mobile), et si elle ressemble à une redirection HTTP (301/302) ou à un script. Avec ces éléments, je peux vous guider vers le chemin d’enquête le plus probable, sans vous faire perdre du temps.