Quand un WordPress se met à “faire n’importe quoi”, les premiers soupçons ne sont pas toujours là où on les cherche. Le scénario est souvent le même, mais la chronologie varie: une page d’accueil qui affiche un contenu étrange, des redirections vers des domaines sans rapport, puis, sur Google et dans les navigateurs, des traces de piratage. Dans ce chaos, deux fichiers reviennent très vite dans les enquêtes: .htaccess et robots.txt.
Dans cet article, je vais te guider sur une méthode de nettoyage pragmatique pour supprimer malware WordPress, en particulier via la réécriture d’URL, les redirections et les comportements cachés que l’on retrouve dans .htaccess, et via les consignes dans robots.txt. Je m’appuie sur des cas réels fréquents, avec les erreurs classiques qui font perdre du temps, ou pire, qui déclenchent une récidive.
Pourquoi .htaccess et robots.txt sont des points d’entrée
WordPress s’appuie sur un serveur web qui interprète la configuration avant même d’exécuter PHP. Sur Apache, .htaccess donne des règles qui peuvent:
- forcer des redirections permanentes (HTTP 301) vers un domaine malveillant, masquer certaines URL, ou au contraire en exposer d’autres, injecter des règles de réécriture qui “capturent” le trafic, modifier le comportement d’accès à des fichiers sensibles.
Un malware en environnement WordPress n’a pas toujours besoin de “voler des données” en silence. Il peut aussi chercher à monétiser le trafic. Une redirection invisible, un changement de trajectoire des requêtes, ou une page 404 qui devient une page proxy, c’est souvent suffisant pour que le site soit rapidement contaminé dans la perception des visiteurs et des moteurs.
robots.txt, lui, n’exécute rien. Mais il oriente le comportement des moteurs de recherche. Un attaquant peut le modifier pour:
- bloquer l’indexation et faire disparaître la trace du problème, ou au contraire donner des indications compatibles avec des objectifs de référencement frauduleux, ou encore “mentir” en laissant croire que certaines zones doivent être explorées, ce qui facilite la mise en avant de pages mal intentionnées.
Dans beaucoup d’incidents, la modification de ces fichiers arrive à la suite d’une compromission plus large. Nettoyer ces deux éléments aide énormément, mais ce n’est pas une baguette magique si la porte dérobée existe encore.
Le premier réflexe: ne pas “réparer en aveugle”
Le piège le plus fréquent, c’est de modifier .htaccess et robots.txt alors que le site est encore compromis, sans avoir de sauvegarde lisible. Résultat: tu supprimes ce qui fait “le bruit”, mais l’injection réapparaît, parfois dans une autre forme, parfois via un fichier de reprise.
Avant de toucher, je recommande de travailler dans cet ordre:
- garder une copie de .htaccess et de robots.txt tels quels, identifier si d’autres fichiers ont été modifiés récemment (sans chercher à tout répertorier au hasard), vérifier si le site réagit différemment selon les pages, ce qui aide à localiser l’injection.
Si tu as accès à un outil de type “journaux d’accès” ou aux logs d’erreurs, même sommaires, c’est un plus. Les redirections sont parfois visibles en lecture rapide: au lieu de renvoyer vers /wp-admin, tu verras souvent un saut vers un domaine externe.
Comprendre l’ossature d’un .htaccess WordPress “sain”
Un .htaccess WordPress “classique” contient généralement des règles pour les permaliens, l’accès à certains dossiers, et parfois des restrictions. Selon la version et les réglages, le contenu varie, mais l’idée est simple: il n’y a pas de raison d’y trouver des blocs PHP ou des snippets de redirection complexes vers des domaines inconnus.
Sur beaucoup de sites, le bloc de permaliens ressemble à une configuration de type “RewriteBase” et des règles de réécriture vers index.php. La forme exacte dépend du contexte, mais l’ensemble est cohérent.
Ce que tu cherches, ce sont des marqueurs d’injection. Sans entrer dans des signatures trop spécifiques, voilà les motifs que j’ai vus revenir:
- des règles qui ajoutent des redirections vers un autre domaine (souvent avec R=301 ou R=302), des conditions RewriteCond %HTTP_HOST ou RewriteCond %REQUEST_URI orientées vers des chemins “volés”, des références à des fichiers temporaires ou à des chemins incohérents, une profusion de règles “métier” qui n’ont rien à voir avec WordPress, des commentaires ou balises inhabituelles dans le fichier.
Si tu repères un gros bloc illisible, ou un ajout récent, tu ne réécris pas “à la main” sans garde-fou. L’objectif est de remettre .htaccess dans un état minimal et compatible, puis de vérifier.
Diagnostiquer les redirections cachées: méthode courte et efficace
Quand un malware utilise .htaccess, le comportement est souvent reproductible. Tu peux généralement observer:
- une redirection systématique à partir de la racine, /, des redirections spécifiques sur certaines catégories, tags ou pages, des redirections aléatoires selon le navigateur, l’IP, ou l’agent utilisateur (ça, c’est un vrai classique).
L’une des approches les plus utiles consiste à comparer deux versions de navigation:
- une navigation “normale” dans le navigateur, une navigation en mode privé, pour limiter l’influence des cookies, et, si possible, un essai avec un outil qui n’embarque pas de comportement utilisateur particulier.
Tu peux aussi relever le domaine de destination exact. Ce détail est précieux pour confirmer que c’est bien .htaccess et pas un plugin ou un fichier PHP.
Nettoyer .htaccess sans casser WordPress
Le nettoyage doit préserver les permaliens. C’est le point de bascule. Un .htaccess “trop nettoyé” peut rendre les liens cassés, provoquer des 404, et te faire croire que le malware est encore là. Donc, tu veux une version saine, minimaliste, qui maintient WordPress.
Je te propose une démarche prudente, et volontairement “courte”, car trop d’étapes augmentent le risque d’oublier un détail:
- commencer par sauvegarder le .htaccess actuel, ouvrir le fichier et repérer les sections non standard (notamment celles qui parlent de redirection vers des hôtes externes), conserver uniquement la partie permaliens et les règles d’accès manifestement liées à WordPress, supprimer les blocs suspects, puis tester les URL importantes.
Pour éviter l’erreur la plus classique, je conseille de faire un test avant de finaliser: après modification, vérifie la page d’accueil, une page avec permalien, et l’accès à /wp-admin/. Si tu perds l’accès à l’administration, ce n’est pas forcément lié au malware, mais cela indique que les règles d’accès ont été trop agressives.
Voici un mini-plan de vérification, simple mais efficace:
- page d’accueil et un article avec permalien accès à /wp-admin/ (authentification et chargement) erreurs 404 inattendues sur des pages internes absence de redirection externe sur les tentatives
Si tout est bon, tu as déjà éliminé une grosse partie du “chemin de nuisance”.
Quand le malware “revient”: comprendre le mécanisme de persistance
Un malware WordPress ne se contente pas toujours de modifier .htaccess. Il peut aussi déposer un mécanisme de persistance ailleurs, puis réécrire .htaccess à intervalles réguliers, ou déclencher une réécriture au chargement.
Dans ce cas, nettoyer .htaccess ressemble à essuyer une flaque sur un sol qui continue de fuir. Tu peux temporairement assainir, mais si la cause reste active, tu revois le problème.
Les causes typiques que j’ai rencontrées:
- plugin compromis (parfois “réellement” compromis, parfois un plugin légitime mais modifié), thème compromis, compte admin créé à ton insu, fichiers PHP ajoutés dans des emplacements inattendus, tâches planifiées ou hooks qui restaurent les règles.
La conséquence pratique est simple: après avoir nettoyé .htaccess, vérifie l’intégrité globale du site. Même si tu veux rester focalisé sur .htaccess et robots.txt, tu dois au moins confirmer que la source de la récidive n’est pas ailleurs.
Exemple de contenu à traiter dans .htaccess (et comment le raisonner)
Sans fournir de “recette universelle” car chaque injection a sa forme, je peux te donner un cadre de lecture.
Si tu vois un bloc de redirection qui envoie vers http://domaine-externe/..., c’est presque toujours suspect. Dans un .htaccess WordPress, tu n’as pas besoin de rediriger vers un autre domaine. Les redirections “saines” existent, mais elles sont typiquement liées à des migrations que tu connais, et elles sont généralement documentées.
Si tu vois des règles de réécriture qui “cachent” wp-content, changent des chemins, ou déclenchent des réponses particulières selon User-Agent, c’est aussi un signal fort. Un attaquant aime viser certains navigateurs ou certains robots, ce qui complique la détection manuelle.
Le bon réflexe n’est pas de “comprendre chaque règle”. Le bon réflexe est de reconstruire l’essentiel. Tu remets les permaliens, tu laisses ce qui est nécessaire, et tu coupes le reste. Ensuite, tu surveilles.
Cas particulier: serveurs autres que Apache et gestion de .htaccess
.htaccess est une convention surtout Apache et compatibles. Si ton hébergement utilise Nginx (avec un reverse proxy), la stratégie de contamination et les fichiers pertinents peuvent changer. La question à te poser est simple: ton site exploite bien .htaccess pour les permaliens? Si oui, tu peux avancer comme ici. Si non, chercher dans .htaccess peut donner un faux sentiment de sécurité.
Une autre nuance: certains hébergeurs ou modules modifient la configuration serveur en plus de .htaccess. Donc, même si tu nettoies, d’autres couches peuvent continuer à rediriger. D’où l’importance des tests de navigation avec plusieurs URL.
Nettoyer robots.txt après un incident
robots.txt se nettoie avec une logique différente. Là, l’enjeu n’est pas de maintenir un fonctionnement, mais de retirer toute consigne incohérente et de rétablir une visibilité normale du site.
Un robots.txt WordPress peut être absent, minimal, ou généré de manière spécifique selon les configurations. Certains sites ajoutent une règle pour empêcher l’indexation du développement. D’autres n’ajoutent rien.
Ce que tu dois viser, c’est un contenu cohérent avec ta stratégie:
- si ton site a été compromis, tu ne veux pas de blocage d’indexation “silencieux” qui masque le problème, tu ne veux pas non plus de directives qui laissent croire à des pages à explorer alors qu’elles sont douteuses, tu veux enfin une version simple qui ne contredit pas ce que tu fais côté WordPress.
En pratique, après incident, je recommande de comparer ton robots.txt actuel avec la version d’avant. Si tu n’as pas d’historique, tu pars sur un fichier simple, sans règles étranges. Mais attention: si tu as volontairement bloqué l’indexation auparavant (par exemple lors d’un lancement), il faut tenir compte de ce contexte, sinon tu fais remonter le site Trouver plus d'informations à Google trop tôt.
Vérifier les signaux dans robots.txt
Le malware peut y ajouter des directives qui semblent “logiques” mais qui, combinées à .htaccess, créent une trajectoire de référencement frauduleux.
Si tu vois des règles qui bloquent tout le site, puis que tu constates quand même des contenus indexés ou des redirections, tu as probablement une manipulation en parallèle. À l’inverse, si tu vois un robots.txt qui autorise tout alors que ton site affiche des pages injectées, ce n’est pas la cause directe du piratage, mais c’est un risque de visibilité supplémentaire.
Réparer proprement: une approche en quatre décisions
Pour supprimer malware WordPress de manière durable, je pense qu’il faut prendre quatre décisions, pas juste modifier deux fichiers.
Voici la manière dont je l’organise sur des interventions réelles, en restant pragmatique:
Réduire la surface de nuisance en nettoyant .htaccess pour arrêter les redirections et réécritures malveillantes. Restaurer la politique de recherche via robots.txt, de façon cohérente et minimale. Traquer la source de la persistance en vérifiant plugins, thèmes et utilisateurs, pas seulement les fichiers de configuration. Empêcher la ré-exploitation en corrigeant les vulnérabilités et en renforçant les comptes, sans quoi le malware revient.À partir de là, les modifications sur .htaccess et robots.txt deviennent un “pansement utile”, pas une finalité.
Éviter les erreurs qui aggravent la situation
Dans les incidents, j’ai vu plusieurs erreurs récurrentes. Elles ne viennent pas de la mauvaise volonté, plutôt d’une compréhension partielle du serveur et de WordPress.
La première erreur, c’est de copier-coller un .htaccess “trouvé sur internet” pour “fixer les permaliens”. Ça marche parfois, mais dès que ton hébergeur a des particularités, ou que ton site a des réglages différents, tu te retrouves avec des redirections ou des règles qui se contredisent.
La deuxième erreur, c’est de supprimer trop de lignes sans lire la structure. Par exemple, un bloc de sécurité ou des règles liées à l’accès à certains dossiers peut être en réalité nécessaire pour ton environnement.
La troisième erreur, c’est de considérer robots.txt comme un fichier “sans risque”. Il n’exécute rien, mais il influence ce que les moteurs voient. Si tu le modifies sans logique, tu peux ruiner une stratégie de référencement, ou masquer la progression du nettoyage.
Enfin, la quatrième erreur, c’est de “se contenter du nettoyage” sans vérifier la compromission ailleurs. .htaccess et robots.txt sont souvent des conséquences. En les nettoyant, tu corriges la symptomatologie. Mais tu dois aussi traiter la cause.
Comment tester que le nettoyage est réellement efficace
Le test n’a pas besoin d’être compliqué, mais il doit être assez ciblé pour couvrir les comportements typiques d’un malware.
Je fais en général ces vérifications:
- vérifier qu’aucune URL ne redirige vers un domaine externe quand on utilise le protocole attendu (http ou https, selon le cas), tester une URL d’article et une URL d’administration, essayer une navigation en session privée pour éviter un faux positif dû à des caches de redirection ou à des cookies, contrôler visuellement le HTML retourné sur les pages clés, notamment l’absence de scripts injectés.
Pour aller plus loin, les logs côté serveur valent de l’or. En quelques minutes, tu peux souvent voir si les requêtes reçoivent une réponse 301 ou 302 vers l’externe, et si ça disparaît après ton nettoyage.
Sécuriser après le nettoyage: la partie que beaucoup repoussent
Nettoyer est une étape. Sécuriser évite que le problème revienne.
Sans transformer ça en audit complet, il y a quelques actions à forte rentabilité, parce qu’elles réduisent la probabilité de réinfection:
- remettre à jour WordPress, thèmes et plugins, en commençant par ceux qui sont souvent ciblés, vérifier la liste des utilisateurs, supprimer les comptes inconnus, et forcer un changement de mot de passe pour les comptes légitimes, désactiver temporairement les plugins récemment installés ou suspects, vérifier la présence de fichiers inconnus dans l’arborescence.
Si tu veux une liste courte de contrôle post-nettoyage, voilà celle que j’utilise le plus souvent:
- vérifier la présence de nouveaux comptes admin et supprimer ceux non reconnus mettre à jour WordPress, thèmes et plugins désactiver les plugins que tu ne reconnais pas ou ceux installés juste avant l’incident contrôler rapidement l’arborescence pour trouver des fichiers PHP suspects
Cette approche n’est pas “propre” au sens académique, mais elle est robuste en terrain réel.
Et si le site continue d’être redirigé malgré le nettoyage ?
Si tu nettoies .htaccess et que la redirection revient, il faut envisager plusieurs pistes:
- un fichier généré dynamiquement qui réécrit .htaccess, un plugin ou un thème qui injecte des règles ou exécute un redirigeur, un autre niveau de configuration serveur (selon l’hébergement), une cascade de scripts côté navigateur, où la redirection ne vient pas du serveur mais d’un contenu injecté (dans ce cas, tu verras du code anormal dans le HTML).
La démarche, c’est de réduire la zone: tu désactives les plugins, tu testes. Si la redirection disparaît, la source est probablement un plugin. Si elle reste, tu regardes côté thème et fichiers principaux. Et si aucun changement local ne corrige, il faut envisager une couche serveur ou un comportement à bas niveau.
Parfois, il faut restaurer entièrement le fichier .htaccess d’origine via l’interface d’hébergement, puis reconstruire progressivement. Ce n’est pas élégant, mais quand l’incident est installé, la reconstruction guidée est plus fiable que la réparation manuelle.
Restaurer une version saine de .htaccess et de robots.txt
Il y a un moment où, plutôt que de lutter avec un .htaccess “sale”, tu gagnes à repartir d’une base connue. Sur WordPress, cette base dépend de tes permaliens, de ton mode d’hébergement, et de tes besoins.
La logique que j’applique:
- .htaccess doit contenir les règles nécessaires aux permaliens et rien d’autre qui ne s’explique pas, robots.txt doit être minimal, cohérent avec ton intention d’indexation, et exempt de consignes anormales, tout le reste doit être traité ailleurs, dans les fichiers WordPress compromis, les plugins, ou la sécurisation des comptes.
Si tu disposes de sauvegardes, utilise-les comme point de référence. Si tu n’en as pas, tu peux utiliser l’hébergement pour retrouver la configuration par défaut, puis recalculer les permaliens depuis WordPress, en testant au fur et à mesure.
Quand demander une aide externe devient rationnel
Il existe des situations où rester seul augmente le risque de dissémination, de perte d’accès, ou de réindexation par les moteurs de recherche pendant que tu “bricoles”.
Fais-toi aider si:
- tu n’as plus accès à /wp-admin/, le site redirige vers des domaines externes et tu n’arrives pas à stopper le comportement malgré plusieurs nettoyages, tu vois des signes d’injection dans plusieurs fichiers à la fois, tu n’as pas de sauvegarde exploitable, et tu hésites entre réparation et restauration.
Une intervention externe peut aussi te faire gagner du temps sur la cartographie du problème, surtout quand les logs sont nombreux et que l’environnement est complexe.
Une méthode mentale pour ne pas tourner en rond
Pour finir, je te propose une grille de lecture simple, qui évite de se perdre dans des détails.
Quand tu suspectes un malware, pose-toi deux questions:
Qu’est-ce qui répond au navigateur? Si les redirections se produisent très tôt, .htaccess est probable. Si le contenu injecté est dans le HTML, c’est plutôt PHP ou un fichier de template. Qu’est-ce qui empêche la persistance? Si la modification de .htaccess “tient” pendant une heure puis revient, c’est un processus de réécriture ailleurs.Avec ces deux angles, tu nettoies le bon endroit, tu testes le bon symptôme, et tu ne confonds pas la cause et l’effet.
Nettoyer .htaccess et robots.txt est souvent la partie la plus visible, et parfois la plus spectaculaire. Mais pour supprimer malware WordPress durablement, l’étape suivante est toujours la même: trouver ce qui a permis l’injection, puis fermer la porte. C’est cette combinaison, nettoyage ciblé et correction de la source, qui transforme un site “redevenu utilisable” en site réellement fiable.