Si votre site a été victime d'une attaque par « keyword hack » japonais, le nettoyage des fichiers ne représente que la moitié du travail. Les URL de spam restent dans l'index de Google même après la suppression du logiciel malveillant, et elles continuent d'apparaître sous votre domaine jusqu'à ce que Google les réindexe une à une et constate qu'elles ne sont plus actives.
Cet article porte sur cette deuxième partie : quel signal de suppression envoyer, comment utiliser l'outil « Suppressions » sans tomber dans ses deux pièges, et comment vérifier le nettoyage maintenant que l'outil vers lequel le guide de Google vous orientait n'existe plus.
Principaux enseignements
- Le « hack par mots-clés japonais » insère des pages de spam en japonais générées automatiquement dans des répertoires portant des noms aléatoires sur votre site, les monétise à l'aide de liens d'affiliation vers des contrefaçons, puis les masque afin que les robots d'indexation puissent les voir, mais pas vous.
- Le nettoyage des fichiers ne supprime pas les pages de Google. Chaque URL indésirable doit renvoyer un code d'erreur 404 ou 410, puis faire l'objet d'une nouvelle exploration avant d'être retirée de l'index.
- Le code 410 s'applique à une URL créée par un pirate informatique qui n'a jamais existé légitimement ; le code 404 convient lorsque le code 410 n'est pas applicable. Google indique que ces deux codes rendent la suppression définitive.
- Ne bloquez pas les chemins menant au spam dans le fichier robots.txt. Dans ce cas, Googlebot ne pourra pas les récupérer, ne verra jamais la réponse 404 ni la balise « noindex », et ces URL risquent de rester indéfiniment dans l'index.
- L'outil « Removals » constitue une mesure temporaire d'une durée d'environ six mois. La documentation officielle de Google recommande aux propriétaires de sites piratés de l'utiliser pour cibler les URL des pirates, et non l'ensemble du site.
- Le guide de Google sur le piratage informatique recommande toujours de vérifier le résultat de votre nettoyage à l'aide de « Fetch as Google », une fonctionnalité qui n'est plus disponible dans Search Console. C'est le test en direct de l'outil d'inspection d'URL qui l'a remplacée.
Qu'est-ce que l'astuce des mots-clés japonais ?
Le « hack par mots-clés japonais » est une attaque visant à compromettre un site et à créer des milliers de pages en japonais générées automatiquement sur votre domaine, généralement dans un répertoire dont le nom est aléatoire, tel que /ltjmnjp/341.html. Ces pages génèrent des revenus grâce à des liens d'affiliation vers des boutiques vendant des contrefaçons de produits de marque, et elles apparaissent dans les résultats de recherche Google sous votre nom.
Le guide de Google lui-même le décrit presque en ces termes, et cette description est exacte ; il n'y a donc pas lieu d'en débattre ici :
Le « hack » par mots-clés japonais consiste généralement à créer, sur votre site, de nouvelles pages contenant du texte en japonais généré automatiquement, dans des répertoires dont les noms sont générés aléatoirement (par exemple, http://example.com/ltjmnjp/341.html). Ces pages sont monétisées à l'aide de liens d'affiliation vers des boutiques vendant des contrefaçons de produits de marque, puis apparaissent dans les résultats de recherche Google.
Google, Corriger le « hack » des mots-clés japonais
site : Recherche sur un domaine piraté, où les pages en japonais injectées apparaissent dans les résultats naturels à côté des véritables pages du site. Crédit image : Google, “ Fix the Japanese keyword hack ”, utilisée sous licence Creative Commons Attribution 4.0.Les fournisseurs de solutions de sécurité désignent généralement ce phénomène sous le nom de « spam SEO japonais » ; si vous cherchez de l'aide, vous tomberez donc sur ces deux appellations. Certaines autres caractéristiques sont suffisamment récurrentes pour que la plupart des articles s'accordent sur celles-ci, et il est utile de les connaître car chacune d'entre elles constitue un point à vérifier.
- Il adapte son affichage en fonction de l'agent utilisateur. Le code vérifie l'identité de la personne qui effectue la requête ; ainsi, un robot d'indexation reçoit un texte commercial en japonais, tandis que vous accédez à votre page habituelle. C'est pourquoi votre propre navigateur ne constitue pas une preuve sur un site piraté.
- Cela réécrit
.htaccess. Une règle de réécriture redirige ces noms de fichiers fictifs vers un script ; c'est ainsi que des milliers d'URL peuvent exister sans qu'il y ait pour autant des milliers de fichiers. - Il ajoute son propre plan du site. Le pirate souhaite que ces pages de spam soient repérées rapidement ; il fournit donc à Google une carte les répertoriant.
- Il se cache dans du code PHP obscurci. Noms Google
base64_decode,rot13,eval,strrevetgzinflatecomme les éléments révélateurs habituels, généralement intégrés dansindex.php,wp-load.php,404.phpetview.php. - L'attaquant se connecte souvent à Search Console. Selon le guide de Google, le pirate informatique “ se désigne généralement comme propriétaire du site dans Search Console, afin d'augmenter ses profits en manipulant les paramètres de votre site, tels que le ciblage géographique ou les plans de site ”.”
Le 30 juillet 2026, Joe Youngblood, spécialiste du référencement, a indiqué que cette faille se propageait rapidement sur les sites WordPress et que les plugins de sécurité standard ne la détectaient pas. J'ai cherché une confirmation indépendante concernant le contournement des plugins, mais je n'en ai trouvé aucune ; considérez donc cette information comme le témoignage d'un professionnel plutôt que comme un fait avéré. La vague d'attaques est toutefois suffisamment réelle pour que vous preniez le temps de lire cet article avant que cela ne devienne votre problème.
Comment savoir si mon site web a été piraté ?
Lancer un site:votredomaine.com Faites une recherche et parcourez quelques pages, puis soumettez l'une des URL inhabituelles au test en temps réel de l'outil d'inspection d'URL. Ces deux vérifications prennent environ une minute et permettent de détecter ce que votre navigateur ne peut pas voir, car le piratage décide du contenu à afficher en fonction de l'utilisateur qui en fait la demande.
Il existe un troisième indice qui ne coûte rien. Si Search Console vous envoie un e-mail vous informant qu'une personne que vous ne connaissez pas a vérifié la propriété de votre site, considérez cela comme une intrusion jusqu'à preuve du contraire.
Commencez par nettoyer les fichiers, car le fait de supprimer les URL d'une infection active ne fait que les réapparaître.
Tout ce qui suit part du principe que l'infection a disparu. Si ce n'est pas le cas, les demandes de suppression sont inutiles, car le piratage régénère les URL plus vite que vous ne pouvez les signaler.
Je vais être clair dès le départ : nous sommes un cabinet de conseil en référencement, pas un prestataire de services de sécurité, et nous n'avons jamais nous-mêmes nettoyé un site piraté. Il ne s'agit donc pas d'un tutoriel sur la suppression des logiciels malveillants, et un tutoriel à moitié correct serait pire que pas de tutoriel du tout. Pour cette partie, suivez les étapes décrites dans Les étapes de nettoyage proposées par Google ou faire appel à une société de sécurité. Voici en bref en quoi consiste cette partie, pour que vous puissiez déterminer si vous êtes prêt à vous lancer :
- Mettre le site hors ligne ou le verrouiller pendant que vous travaillez, afin que le pirate ne puisse pas vous observer pendant que vous nettoyez le système et ne puisse pas le réinfecter à votre insu.
- Modifier tous les mots de passe et toutes les clés, notamment l'hébergement, le FTP, les bases de données et les comptes administrateurs, car un identifiant oublié peut réduire à néant tout le travail accompli.
- Supprimer les propriétaires et les utilisateurs inconnus de la Search Console, car un pirate disposant d'un accès de type « propriétaire » peut continuer à manipuler votre géolocalisation et vos plans de site même après que vous ayez corrigé les fichiers.
- Remplacer
.htaccessavec un exemplaire vierge, car c'est cette règle de réécriture qui permet aux URL inventées d'être résolues. - Réinstaller le cœur, les extensions et les thèmes à partir des sources officielles plutôt que d'essayer de repérer à l'œil nu chaque ligne modifiée.
- Rechercher le code PHP obfusqué dans les fichiers et la base de données mentionnés ci-dessus, et supprimez les messages indésirables que le pirate aurait pu insérer dans vos tables de contenu.
Une fois cette opération véritablement effectuée, vous vous retrouvez avec un site « propre » mais un index « sale ». C'est le problème dont presque personne ne parle, et c'est justement celui qu'un spécialiste du référencement est le mieux placé pour résoudre.
Pourquoi les pages de spam restent-elles dans Google alors que les fichiers ont disparu ?
En effet, l'index de Google est un enregistrement stocké, et non un miroir en temps réel de votre serveur. La suppression des fichiers modifie le contenu affiché par votre site, mais ne change en rien ce que Google a déjà en sa possession. Chaque URL indésirable conserve son entrée dans l'index jusqu'à ce que Googlebot récupère à nouveau cette URL spécifique et reçoive un signal lui indiquant que la page n'existe plus.
C'est tout le principe, et cela explique le délai qui agace tant de gens. Vous avez nettoyé le site en un après-midi, mais Google a des milliers d'URL à réexplorer, dont la plupart sont sans intérêt et qu'il n'a aucune raison de traiter en priorité.
Le travail se divise donc en deux aspects que vous pouvez contrôler : envoyer le bon signal pour chaque URL de spam et vous assurer que Googlebot puisse accéder à ce signal.
Les URL piratées doivent-elles renvoyer un code 404 ou 410 ?
Utilisez le code 410 dès que possible, car le répertoire d'un pirate correspond exactement au cas décrit par le code 410 : une URL qui ne vous a jamais appartenu légitimement et qui ne sera pas rétablie. Utilisez le code 404 lorsque le code 410 n'est pas applicable, ce qui sera le cas dans la plupart des configurations de CMS.
La documentation de Google relative aux demandes de suppression mentionne ces deux méthodes comme moyens de rendre une suppression définitive, et elle ne précise pas que l'une d'entre elles serait traitée plus rapidement ; je ne le ferai donc pas non plus.
Voici la liste complète des instruments et leur emplacement exact. J'ai abordé plus en détail le fonctionnement des trois derniers dans Comment désindexer une page sur Google ?; ce tableau indique lequel convient à un site piraté.
| Signal | À utiliser lorsque | Ce qu'en dit Google |
|---|---|---|
| 410 Disparu | Cette URL n'a jamais légitimement existé sur votre site, ce qui est le cas de tous les chemins d'accès créés par des pirates. | Mentionné aux côtés du code 404 comme moyen de supprimer définitivement la page. |
| 404 Page introuvable | Un code 410 n'est pas envisageable, ou bien votre plateforme ne le générera pas sans intervention supplémentaire. | Répertorié aux côtés du 410, même effet de permanence. |
| noindex | L'URL doit effectivement continuer à renvoyer une page valide. C'est rare lors du nettoyage après un piratage. | Considérée comme “ moins sûre que les autres méthodes ”.” |
| Outil de suppression | Il faut que le spam disparaisse des résultats de recherche dès aujourd'hui, alors que les erreurs 404 ou 410 se multiplient. | “ Une demande acceptée n'est valable que pendant environ six mois. ” |
| robots.txt | Jamais, pour ce poste. | “ N'utilisez pas le fichier robots.txt comme mécanisme de blocage. ” |
C'est cette dernière ligne qui, sans qu'on s'en rende compte, fait perdre des mois aux gens. Bloquer le répertoire de spam dans le fichier robots.txt semble être la solution la plus rapide, et c'est la seule mesure qui garantit que les URL resteront indexées.
La raison est simple une fois qu'on l'a comprise. Une instruction « disallow » dans le fichier robots.txt empêche complètement Googlebot d'accéder à l'URL ; il ne voit donc jamais votre code 404, votre code 410 ou votre balise « noindex », et l'entrée qu'il détient déjà ne dispose d'aucun élément permettant de la mettre à jour. Google l'indique clairement sur la page dédiée aux suppressions, et c'est ce même piège qui fait que des pages ordinaires restent indexées après une tentative de désindexation ratée.
Que fait exactement l'outil « Removals » sur un site piraté ?
Cette fonctionnalité masque les URL dans les résultats de recherche pendant environ six mois, le temps que votre solution définitive fasse effet. Elle ne supprime rien et constitue la première étape d'une suppression définitive, plutôt que la suppression elle-même. Google se montre exceptionnellement clair quant à son utilisation sur un site piraté, et cela vaut la peine d'être cité, car presque personne ne le fait :
Si votre site a été piraté et que vous souhaitez supprimer les URL indésirables qui ont été indexées, utilisez l'outil de blocage d'URL pour bloquer toutes les nouvelles URL créées par le pirate […]. Nous vous déconseillons toutefois de bloquer l'intégralité de votre site ou de bloquer des URL que vous souhaiterez éventuellement voir indexées. Nettoyez plutôt les traces du piratage et laissez-nous réexplorer votre site.
Google, Outil de suppression et de signalement SafeSearch (la partie omise correspond à l'URL fournie à titre d'exemple par Google)
Cette mesure prise dans la précipitation, qui consiste à bloquer l'ensemble du domaine pour mettre fin à cette situation embarrassante, est justement celle contre laquelle Google met explicitement en garde. Dirigez l'outil uniquement vers les chemins d'accès du pirate. Le Fonctionnement étape par étape de l'outil « Removals » sont les mêmes que pour tout autre déménagement, je ne les répéterai donc pas ici.
Il convient de rappeler les deux pièges qui figurent dans la fenêtre d'avertissement de Google sur cette page, car ils modifient l'ordre dans lequel vous effectuez les opérations.
- Commencez par bloquer, puis supprimez. Google précise que si l'URL est inaccessible au moment où vous déposez votre demande, “ il considérera que la page n'existe plus et votre demande de blocage expirera ”. La démarche instinctive, qui consiste à supprimer les fichiers indésirables puis à déposer des demandes de suppression pour accélérer le processus, est en réalité contre-productive.
- Si vous avez déjà bloqué avant le nettoyage, débloquez puis bloquez à nouveau. La liste de contrôle de Google relative à la permanence mentionne explicitement cette étape, qui sert à supprimer une entrée qui a été réexplorée alors que le blocage était en vigueur. C’est le genre de détail qui n’apparaît jamais dans les guides consacrés aux sites piratés et qui explique discrètement la persistance d’une URL.
Une petite chose à noter lorsque vous consultez cette page : Google mentionne “ environ six mois ” dans le texte et “ 180 jours ” dans son propre tableau comparatif. C'est la même chose, ce sont deux chiffres, alors ne considérez pas cette différence comme significative.
Comment vérifier le nettoyage maintenant que la fonctionnalité « Fetch as Google » n'existe plus ?
Utilisez l'outil d'inspection d'URL et cliquez sur « Tester l'URL en direct » pour les chemins de spam. Un test en direct récupère l'URL à l'instant même en tant que Googlebot, ce qui correspond exactement à ce dont vous avez besoin, car un rapport basé sur la version mise en cache continuerait à vous indiquer la présence d'une infection.
Si je tiens à le préciser, c'est parce que le guide le mieux classé sur ce sujet vous conseille de procéder autrement. La page de Google elle-même se termine par une étape de vérification reposant sur « Fetch as Google », un outil que Search Console a supprimé il y a plusieurs années, et la page indique comme date de dernière mise à jour le 1er janvier 2015.
Je ne soulève pas ce point pour marquer un point. C'est justement au stade de la vérification qu'un propriétaire de site inquiet jette l'éponge, et que la page la plus fiable sur le sujet le redirige vers une page qui n'existe pas. Ce même guide mentionne à juste titre l'« Inspection d'URL » bien plus tôt, lors de la vérification du cloaking, puis l'oublie au moment où cela devient crucial.
L'ancienneté de la page transparaît également à d'autres endroits. Elle cite “ une étude récente ” sur les taux de réinfection sans en préciser le titre, ce qui, pour une page datant d'il y a onze ans, n'est pas un chiffre que l'on devrait reprendre à son compte ; de plus, elle renvoie toujours vers le site désactivé google.com/webmasters/tools/ URL.
Voici la vérification que j'effectuerais à la place, dans cet ordre.
- Recueillez entre cinq et dix URL de spam à partir de votre
site :La recherche porte sur plusieurs répertoires injectés, et non pas uniquement sur un seul ; ainsi, le fait qu'un seul dossier ait été omis ne vous permettra pas de réussir le test. - Soumettez chacune d'entre elles à l'outil d'inspection d'URL, puis cliquez sur « Tester l'URL en direct ». C'est le test en direct qui compte ; la vue par défaut peut dater de plusieurs semaines.
- Vérifiez que le test en production indique que l'URL est introuvable. plutôt que d'afficher une page. Si l'une d'entre elles s'affiche encore, cela signifie qu'il vous manque un fichier ou une règle de réécriture, et que la mise en place de l'index est prématurée.
- Vérifiez le code HTML généré sur une page qui s'affiche correctement, car le « cloaking » signifie que le test en direct peut afficher du texte en japonais sur une URL que votre navigateur affiche normalement. C'est le moyen le plus rapide de confirmer que l'infection est toujours active.
- Soumettre un plan du site valide et supprimez tout plan du site ajouté par le piratage. Si Search Console renvoie une erreur de récupération concernant le nouveau fichier, le Le plan du site habituel n'a pas pu être récupéré : causes c'est le cas, mais c'est rarement aussi spectaculaire qu'il n'y paraît.
- Relancez le
site :recherche hebdomadaire, après avoir parcouru quelques pages, et comptez. Ce décompte est le seul indicateur de progrès qui ait vraiment de l'importance.
Pourquoi le nombre de pages indexées continue-t-il d'augmenter après le nettoyage ?
En général, c'est parce que vous consultez le rapport d'indexation des pages en pensant qu'il est mis à jour quotidiennement, alors que ce n'est pas le cas. Nous avons vérifié cela sur notre propre site : le rapport fournit des aperçus globaux couvrant plusieurs jours plutôt que des données quotidiennes actualisées. Ainsi, un graphique que vous actualisez chaque matin peut afficher un chiffre en retard de plusieurs jours par rapport à l'activité réelle de votre site.
La remise en état d'un site piraté est la pire situation imaginable pour mal interpréter ce graphique. Vous nettoyez tout, vous voyez le nombre d'indexés continuer à grimper pendant trois jours supplémentaires, et vous en concluez que le nettoyage a échoué. Souvent, il s'agit simplement du rapport qui prend le temps de prendre en compte les explorations effectuées avant que vous n'ayez corrigé quoi que ce soit.
En pratique, il convient d'évaluer la reprise en fonction de la site : tenir compte des tests d'inspection d'URL en temps réel et considérer le graphique d'indexation des pages comme une confirmation à retard plutôt que comme un tableau de bord en temps réel. Si vous souhaitez en savoir plus sur l'ampleur de ce retard, j'ai détaillé cela dans Baisse du nombre de pages indexées dans Search Console : réévaluation ou désindexation réelle ?.
Autre élément auquel il faut s'attendre : vos pages légitimes risquent de se retrouver dans exploré, non indexé pour le moment pendant un certain temps après un compromis. C'est gênant, mais ce n'est pas inhabituel lorsque Google réévalue un domaine qu'il vient de constater comme hébergeant des milliers de pages de spam.
Pourquoi WordPress est-il si souvent piraté ?
Principalement parce que ce problème est omniprésent, et que l'ampleur du phénomène favorise l'automatisation. Les pirates ne ciblent pas votre site en particulier ; ils recherchent une version vulnérable connue d'un plugin parmi des millions d'installations et s'emparent de tout ce qu'ils trouvent. C'est aussi pour cette raison que la liste de prévention est rébarbative, mais qu'elle fonctionne.
- Mettez à jour le cœur, les extensions et les thèmes dès que possible, car les analyses recherchent les versions présentant des failles de sécurité connues, et un plugin non mis à jour constitue le vecteur d'attaque le plus courant.
- Utilisez des mots de passe uniques et l'authentification à deux facteurs sur l'hébergement, le FTP, la base de données et tous les comptes administrateur, de sorte qu'une seule fuite d'identifiants ne permette pas d'accéder à l'ensemble du système.
- Supprimez les extensions et les thèmes que vous n'utilisez pas, car un plugin désactivé conserve toujours des fichiers sur le disque et peut donc toujours faire l'objet d'une analyse.
- Conservez les sauvegardes hors site que vous avez déjà restaurées au moins une fois, car une sauvegarde que vous n'avez jamais testée n'est qu'une hypothèse, et ce n'est pas cette semaine qu'il faut s'en rendre compte.
- Surveiller la propriété de Search Console, et considérez tout e-mail de vérification inattendu comme un incident plutôt que comme une simple curiosité.
Alors, combien de temps faudra-t-il pour que le spam lié au « keyword hack » japonais disparaisse de Google ?
Honnêtement, cela prend plus de temps que le nettoyage, mais moins longtemps qu’on ne le pense, et la durée dépend presque entièrement du fait que vous ayez ou non envoyé à Googlebot un signal qu’il a pu effectivement détecter. Les sites qui renvoient un code 410 aux chemins d’accès utilisés par le pirate, qui les laissent accessibles à l’exploration et qui suppriment les fichiers dans le bon ordre ont tendance à constater que le site : leur nombre diminue régulièrement. Les sites qui bloquent le répertoire dans le fichier robots.txt parce qu'ils estimaient que c'était une mesure décisive peuvent encore héberger ces URL plusieurs mois plus tard.
Ce sur quoi je ne suis pas d'accord, c'est l'idée qu'il s'agit d'une intervention de sécurité que l'on confie à quelqu'un puis que l'on laisse se dérouler toute seule. La suppression des logiciels malveillants relève de la sécurité, et vous devriez faire appel à un professionnel pour cela. Tout ce qui suit relève du référencement, et si personne ne s'en charge activement, les pages de spam continueront de représenter votre marque sur Google bien après que votre serveur ait été entièrement nettoyé.
Questions fréquentes sur l'astuce des mots-clés japonais
La technique dite du « hack de mots-clés japonais » est-elle identique au spam SEO japonais ?
Dans la pratique, oui. La documentation de Google parle de « Japanese keyword hack » (astuce des mots-clés japonais) et la plupart des éditeurs de solutions de sécurité l'appellent « Japanese SEO spam » (spam SEO japonais) ; ces deux termes désignent les mêmes pages d'affiliation japonaises injectées. Si vous cherchez de l'aide, essayez ces deux termes.
Puis-je supprimer l'intégralité de mon site de Google et repartir de zéro après un piratage ?
C'est possible, mais Google le déconseille : sa documentation sur la suppression d'URL indique qu'il ne faut pas bloquer l'intégralité de votre site ni les URL que vous souhaiterez éventuellement faire indexer. Vous perdriez ainsi l'historique d'indexation de toutes les pages légitimes pour masquer un ensemble d'URL que vous pouvez supprimer individuellement.
Dois-je attendre la levée d'une sanction manuelle après un piratage de mots-clés japonais ?
À condition que Search Console en signale effectivement un. Bon nombre de ces violations sont détectées avant même que Google ne prenne des mesures ; dans ce cas, il n'y a rien à contester et la restauration se résume simplement à une nouvelle exploration du site. Vérifiez les rapports « Problèmes de sécurité » et « Actions manuelles » avant de tirer des conclusions dans un sens ou dans l'autre.
Travailler avec WpConsults
Vous voyez toujours ces URL indésirables dans Google ?
Si les fichiers sont corrects et que l'indexation ne se fait pas, envoyez-moi le nom de domaine et je vous indiquerai quel signal manque et dans quel ordre procéder pour y remédier.
Vous souhaitez que nos publications apparaissent plus souvent sur Google ?
En un clic, Google affichera ce site dans votre rubrique « À la une ».
Budget d'exploration pour les sites de commerce électronique : ce que la nouvelle version du document de Google change pour votre boutique
Audit des chaînes de redirection : comment identifier et aplatir toutes les chaînes de redirection de votre site
Comment vérifier si votre CDN met réellement vos pages en cache
