Site WordPress piraté : que faire, dans l'ordre, pour sauver votre référencement

Jeudi matin, message d’une cliente. Son site déraille : une page s’affiche en chinois, des centaines de commentaires publicitaires sont apparus, et Google vient de lui envoyer une alerte incompréhensible à propos de « fiches de marchand ».

Elle n’a jamais rien vendu en ligne de sa vie. C’est un site de services : quatre pages, un blog, un formulaire.

Sa première question a été celle de tout le monde : « est-ce qu’on m’a volé mes données ? »

La réponse est non. Et c’est précisément ce qui rend ce piratage intéressant, parce qu’on lui a volé autre chose, à quoi elle n’avait jamais pensé.

Ce que le pirate est vraiment venu chercher

Votre nom de domaine a une valeur aux yeux de Google.

S’il existe depuis des années, s’il n’a jamais posé de problème, s’il publie du contenu sérieux, Google lui fait confiance. Cette confiance s’accumule lentement, et elle ne s’achète pas.

Un pirate, lui, peut la voler. S’il arrive à publier ses propres pages sur votre site, elles héritent d’une partie de votre bonne réputation. Elles se positionnent dans Google bien plus vite que sur un site neuf que personne ne connaît.

Imaginez que quelqu’un installe discrètement une boutique dans le hall de votre immeuble, en profitant de la bonne adresse et de la clientèle du quartier. C’est exactement ça.

Sur le site de ma cliente, l’attaquant avait installé :

des dizaines de pages en japonais, cachées sous des adresses que personne ne visite jamais, faites pour capter du trafic sur des produits cosmétiques ;
un faux plan du site déclaré à Google, annonçant 901 pages alors que le site légitime en compte 12 ;
un balisage de fiche produit injecté sur la page d’accueil, si bien que Google affichait un prix et des étoiles d’avis pour un site de conseil.

C’est ce dernier détail qui a déclenché l’alerte. Un site de services qui reçoit un avertissement Google réservé aux boutiques en ligne, c’est un signal d’infection à 100 %.

Ce qu’il faut retenir : votre référencement est un actif. Il vaut de l’argent, il met des années à se construire, et il se pille comme un fichier client. À la différence près que personne ne pense à le protéger.

Comment savoir si votre site est touché

Sept signaux. Aucun ne demande de compétence technique, et les trois premiers prennent deux minutes.

Tapez site:votredomaine.fr dans Google. Vous voyez la liste des pages que Google connaît chez vous. Vous devez toutes les reconnaître. Une seule adresse bizarre ou en langue étrangère, et vous avez votre réponse.
Ouvrez Google Search Console, l’outil gratuit qui vous dit comment Google voit votre site, et regardez la liste des personnes qui y ont accès. Un nom inconnu, c’est une alerte rouge.
Regardez la liste de vos comptes administrateurs dans votre site. Vous devez pouvoir mettre un visage sur chacun.
Une alerte Google sans rapport avec votre activité (des fiches produit sur un site de services, par exemple).
Un afflux de commentaires publicitaires, souvent en langue étrangère.
Votre site est brusquement plus lent, sans raison.
Une page s’affiche différemment de ce que vous avez écrit.

Un point important : dans ce dossier, l’alerte n’est pas venue de la propriétaire du site. Elle est venue de Google. Un site vitrine que personne ne regarde peut rester infecté pendant des mois.

Les trois erreurs qui font perdre le plus de temps

Vous ne ferez probablement pas le nettoyage vous-même. Mais ces trois erreurs sont celles de beaucoup de prestataires, et vous pouvez les repérer.

Erreur 1 : supprimer ce qu’on voit

Il y avait deux comptes administrateurs pirates sur ce site, pas un. Le premier portait un nom d’outil technique pour se fondre dans le décor. Le second n’avait été repéré par personne.

C’est fait exprès. Vous trouvez le premier, vous le supprimez, vous vous croyez tranquille. Le second le recrée pendant la nuit.

Même logique du côté de Google : l’attaquant ne s’était pas contenté de s’ajouter comme utilisateur dans Search Console, il s’était déclaré propriétaire du site. Supprimer l’utilisateur ne change rien, il revient. Il faut supprimer sa preuve de propriété, sur toutes les variantes de votre adresse (avec et sans www, en http et en https).

Un pirate qui reste propriétaire de votre Search Console voit vos statistiques et peut demander à Google de supprimer vos pages. C’est l’urgence numéro un.

Erreur 2 : nettoyer pendant que le cambrioleur est encore dans la maison

Pendant l’intervention, un fichier infecté que je supprimais réapparaissait en quelques secondes. Toujours identique, toujours au même endroit.

Ce n’était pas une porte dérobée que j’aurais ratée. C’était un programme malveillant encore en train de tourner sur le serveur, qui surveillait ses propres fichiers et les remettait en place.

Tant qu’il tourne, on nettoie dans le vide. On peut y passer la nuit.

La solution est simple : redémarrer le serveur pour tuer ce programme, puis recommencer le nettoyage.

Le test à faire : supprimez un fichier infecté, attendez trente secondes, actualisez. S’il est revenu, il faut redémarrer avant d’aller plus loin.

Erreur 3 : comparer à une sauvegarde

Celle-là est de moi, et c’est la plus instructive.

Après un premier passage, j’avais conclu que le cœur du site était sain et que l’infection restait limitée. Cette conclusion reposait sur une comparaison avec une sauvegarde.

Sauf que la sauvegarde était incomplète.

J’ai tout repris autrement : au lieu de comparer le site à une sauvegarde, je l’ai comparé aux fichiers d’origine officiels de WordPress et de chaque extension, dans leur version exacte.

Le résultat a renversé ma conclusion. Là où j’annonçais un cœur sain, il y avait 31 fichiers piégés, dont 8 copies du même outil de prise de contrôle à distance, plus 6 fichiers d’origine modifiés.

La règle que j’en tire : on ne compare jamais un site piraté à une sauvegarde. Une sauvegarde peut être incomplète, ou déjà infectée sans qu’on le sache. On le compare aux fichiers d’origine officiels, jamais à autre chose.

C’est la question à poser à votre prestataire, et elle suffit à jauger son sérieux.

La marche à suivre, dans l’ordre

L’ordre compte autant que les étapes.

Fermer le site au public le temps de l’intervention. Un site infecté qui reste ouvert continue de servir du spam à Google.
Tout sauvegarder avant d’y toucher : fichiers, base de données, journaux de connexion du serveur. C’est indispensable si une plainte ou une déclaration suit. On ne nettoie pas la scène avant de l’avoir photographiée.
Lire les journaux du serveur pour comprendre par où le pirate est entré. Sans ça, vous rouvrez une porte que vous n’avez pas refermée.
Redémarrer, pour tuer tout programme malveillant encore actif.
Réinstaller entièrement WordPress, le thème et chaque extension depuis leur source officielle. On ne répare pas un fichier infecté, on le remplace.
Nettoyer la base de données : comptes pirates, commentaires indésirables, tâches programmées ajoutées par le pirate. Point critique, souvent oublié : tant que la base n’est pas propre, l’infection peut repartir à la réouverture.
Changer tous les mots de passe et tous les accès, y compris ceux de l’hébergeur. Attention aux accès temporaires que votre hébergeur a pu générer : ils peuvent rester valides plusieurs semaines.
Rouvrir, puis surveiller pendant quelques semaines.

Nettoyer le site ne suffit pas

Voilà le point que presque tout le monde rate.

Votre site est propre. Mais Google, lui, est passé pendant l’infection. Sa mémoire contient toujours vos fausses pages et vos faux prix. Le nettoyage technique n’efface rien de tout ça.

Deux réflexes coûtent cher à ce stade.

Rediriger les pages du pirate vers votre accueil. C’est tentant, et c’est une mauvaise idée : vous transférez tous leurs mauvais signaux vers la page la plus importante de votre site. Il faut au contraire répondre à Google « cette page est définitivement supprimée », ce qui la fait disparaître beaucoup plus vite qu’un simple « introuvable ».

Interdire aux robots de Google de visiter ces pages. Là encore, ça semble logique. C’est l’erreur la plus courante. Une page que Google n’a plus le droit de visiter est une page dont il ne pourra jamais constater la disparition. Elle reste donc affichée dans les résultats, indéfiniment. Il faut le laisser venir voir qu’elles sont mortes.

Ensuite, dans Search Console, quatre actions :

retirer le pirate de la liste des propriétaires, et supprimer sa preuve de propriété ;
vérifier la rubrique « Problèmes de sécurité », et demander un examen si un avertissement apparaît ;
déclarer à nouveau votre vrai plan de site, et supprimer celui du pirate ;
demander une réactualisation de vos pages principales. C’est ce qui remplace le plus vite la version empoisonnée.

Comptez ensuite quatre à six semaines de surveillance : les fausses pages sortent progressivement des résultats, et vos positions doivent rester stables.

Le point juridique que beaucoup oublient

Un site piraté peut constituer une fuite de données personnelles au sens du RGPD. Si des données ont pu être consultées, vous avez l’obligation de prévenir la CNIL sous 72 heures. Pour une profession réglementée, tenue au secret professionnel, l’enjeu est encore plus sérieux.

C’est pour ça que l’étape « tout sauvegarder » vient avant l’étape « nettoyer ».

Dans ce dossier, une vérification technique de dix minutes a considérablement allégé le sujet : le site n’avait en réalité aucun formulaire actif. Les outils de formulaire étaient bien installés, mais rien n’était déployé, et aucune demande n’avait jamais été enregistrée. Aucune donnée personnelle n’avait donc pu transiter par le site.

Avant de rédiger une déclaration, faites vérifier ce point précis. Il peut transformer un incident majeur en incident mineur documenté.

Le résultat : zéro trafic perdu

L’infection a été détectée et traitée en moins de 48 heures. Les chiffres, mesurés dans Search Console :

trafic intact, positions stables ;
les fausses pages du pirate n’ont récolté qu’une ou deux apparitions chacune dans Google ;
aucune pollution des mots-clés sur lesquels le site ressort.

Et c’est la vraie leçon de ce dossier.

Ce n’est pas la qualité du nettoyage qui a sauvé le référencement. C’est le délai de détection. Le même piratage, découvert trois mois plus tard, aurait produit des centaines de pages indexées, attiré des liens douteux, et probablement déclenché une sanction de Google.

48 heures, c’est un week-end de travail. Trois mois, c’est un site à reconstruire.

Ce qui aurait tout évité

Rien d’exotique, et c’est bien le problème.

Mettre à jour WordPress et vos extensions sans attendre. La quasi-totalité des intrusions exploitent une faille déjà corrigée depuis des mois.
Supprimer les extensions inutilisées. Une extension désactivée reste exécutable sur le serveur. Désactiver n’est pas supprimer.
Limiter les comptes administrateurs. Quelqu’un qui rédige des articles n’a pas besoin des clés du coffre.
Activer la double authentification sur votre site, votre hébergeur et votre Search Console.
Vérifier Search Console une fois par mois, en particulier la liste des propriétaires. Trente secondes, et c’est le point d’entrée le plus souvent oublié.
Avoir des sauvegardes complètes et externalisées. Une sauvegarde qu’on n’a jamais testée n’est pas une sauvegarde, et une sauvegarde partielle peut vous faire conclure l’inverse de la réalité. J’en ai fait l’expérience plus haut.

Si vous n’en retenez qu’une : la vérification mensuelle de Search Console. C’est la moins coûteuse et la plus rentable.

Pour votre prestataire : le détail technique

Cette section s’adresse à la personne qui interviendra sur le site. Vous pouvez la lui transmettre telle quelle.

Vecteur d’entrée, inventaire de l’infection et procédure complète

Vecteur d’entrée, confirmé par les logs. 2102 requêtes POST sur /?rest_route=/batch/v1 et /wp-json/batch/v1, toutes en statut 207, depuis plusieurs dizaines d’IP, dont une concentrant 1731 requêtes. Exploitation en masse de l’API REST batch en préauthentification, doublée d’un brute force sur la connexion. À rechercher dans les logs d’accès : batch/v1 et xmlrpc.php.

Persistance. Deux comptes administrateurs (wpenginebot, wphiddenbot), un mu-plugin, une tâche cron malveillante, et un processus résident lancé via exec/shell_exec, réactivés par un php.ini déposé par le kit. Le processus régénérait index.php (20651 octets, lecture seule) dans les secondes suivant sa suppression. Un fichier .nfs ouvert depuis 4h27 trahissait sa présence. Redémarrage obligatoire avant tout nettoyage.

Inventaire, établi par diff exhaustif contre les sources officielles (WordPress dans la version exacte du site, et chaque extension dans sa version exacte) :

Zone	Trouvé
Cœur WordPress	31 fichiers malveillants
Webshell	ALFA (ALFA TEaM Shell), 1,05 Mo, 8 copies dans `wp-includes/blocks/loginout/` sous les extensions `.php56`, `.php8`, `.PhP7`, dont une nommée `wp-login.php`
Uploaders	13 fichiers `wp_XXXXXX.php` à noms aléatoires, sur `file_put_contents($_POST[...])`
Fichiers du cœur modifiés	6 : `functions.php`, `pluggable.php`, `plugin.php`, `cron.php`, `general-template.php`, `template-loader.php`
Extensions	Backdoors nichées dans trois extensions légitimes très répandues, même signature à chaque fois : dossier dupliqué contenant un `index.php` loader obfusqué (`$_REQUEST["of"]` + `@include_once`), un `cache.php`, et la charge utile déguisée en archive (`flv_.zip`, `mp4_.zip`)
Camouflage	Fichiers déguisés en `.png` et `.ttf`, dossiers dupliqués du type `network/network`

Le .htaccess du kit interdisait l’exécution de tous les fichiers PHP sauf une liste blanche : filefuns.php, adminfuns.php, classfuns.php, connects.php, memberfuns.php, userfuns.php, postnews.php, system_log.php, et une trentaine d’autres. Objectif : neutraliser les scripts de sécurité tout en gardant les backdoors opérationnelles. Effet secondaire utile : cette liste donne l’inventaire nominatif des portes dérobées.

Injection sans passage par la base. Le contenu doorway et la page « en chinois » n’étaient pas stockés en base. Un scan complet des contenus n’a trouvé aucun lien malveillant : tout était injecté à la volée par le moteur doorway logé dans index.php et par une injection JS du mu-plugin. La page est redevenue normale d’elle-même après nettoyage des fichiers.

Remédiation SEO.

Règles .htaccess renvoyant un 410 Gone sur /contents/*, /jukyuban/, /oracle et le motif ^[0-9]{4,}-[a-z]+/. Le 410 désindexe nettement plus vite que le 404, et évite de transmettre les signaux négatifs comme le ferait une redirection.
Ne pas bloquer ces URL dans robots.txt : une URL non crawlable ne peut jamais être constatée comme supprimée, elle reste indexée.
robots.txt assaini (le kit y avait déclaré son sitemap et imposé un Crawl-delay: 3), sitemap_index.xml resoumis, sitemap pirate supprimé de la liste dans Search Console.
Vérification anti-cloaking : contenu servi à Googlebot identique à celui servi aux visiteurs.
Suppressions temporaires dans Search Console en complément seulement (6 mois), jamais en remplacement du 410.

Questions fréquentes

Comment savoir si mon site WordPress est piraté ?

Le test le plus rapide : tapez site:votredomaine.fr dans Google et vérifiez que vous reconnaissez toutes les pages affichées. Ensuite, contrôlez la liste des utilisateurs et des propriétaires dans Google Search Console, puis vos comptes administrateurs. Les autres signaux classiques sont un afflux de commentaires publicitaires, une alerte Google sans rapport avec votre activité, ou un site brusquement plus lent.

Faut-il restaurer une sauvegarde plutôt que nettoyer ?

C’est souvent la meilleure option, à deux conditions : disposer d’une sauvegarde complète antérieure à l’infection, et connaître la date exacte de l’intrusion. Deux réserves : la sauvegarde peut être déjà infectée sans que vous le sachiez, et surtout la restauration ne referme pas la faille par laquelle le pirate est entré. Il faut dans tous les cas mettre à jour et changer tous les accès juste après.

Mes données clients ont-elles été volées ?

Sur un site vitrine, généralement non : ces attaques visent le référencement, pas les données. Mais cela se vérifie, ça ne se suppose pas. Il faut contrôler les demandes enregistrées via vos formulaires, les comptes utilisateurs et les journaux de connexion. Si des données personnelles ont pu être exposées, le RGPD impose de prévenir la CNIL sous 72 heures.

Combien de temps pour retrouver mon référencement ?

Si l’infection est traitée en quelques jours, le trafic ne bouge quasiment pas et les fausses pages sortent des résultats en deux à six semaines. Si elle a duré des mois, comptez plusieurs mois, avec un risque de sanction de Google à faire lever par une demande d’examen.

Combien coûte un nettoyage ?

Cela dépend entièrement de l’ampleur et de l’ancienneté de l’infection. Un site pris à temps, c’est l’affaire de quelques jours de travail. Un site infecté depuis des mois demande en plus un chantier de récupération du référencement qui s’étale sur plusieurs semaines. C’est la raison pour laquelle la détection rapide est le seul vrai levier d’économie.

WordPress est-il moins sûr qu’un autre système ?

Non, il est simplement le plus répandu, donc le plus scanné par les robots. Le risque vient surtout des extensions : chacune ajoute du code écrit par un tiers à votre site. Moins d’extensions, tenues à jour, c’est déjà l’essentiel de la sécurité.

Ce que je retiens

Trois choses.

Un pirate ne veut pas forcément vos données. Il veut votre réputation aux yeux de Google, et c’est un actif auquel personne ne pense.

Un nettoyage se juge sur ce qu’on compare, pas sur ce qu’on supprime. Les fichiers d’origine officiels, jamais une sauvegarde.

Et le délai de détection compte plus que la qualité du nettoyage. C’est la seule variable sur laquelle vous avez la main, et elle tient en une vérification par mois.

Un doute sur l’état de votre site, ou simplement envie de savoir ce que Google affiche de vous en ce moment ? Réservez un premier échange, on regarde ensemble. Le contrôle est rapide, et il vaut mieux le faire un mardi tranquille qu’un dimanche en panique.