Pages japonaises ou spam dans Google après un piratage WordPress : que faire ?

Vous recherchez le nom de votre entreprise dans Google et découvrez des pages en japonais, en chinois, consacrées au casino, à des médicaments ou à des produits que vous ne vendez pas ? Vous voyez peut-être aussi des URL inconnues apparaître dans Search Console, alors que ces pages n’existent pas dans le menu de WordPress.

Ce symptôme correspond souvent à une injection de pages spam après un piratage WordPress. Le cas le plus connu est le « Japanese keyword hack », qui génère des pages dans des répertoires aléatoires afin de profiter de l’autorité du domaine. Mais le même principe peut produire des contenus en plusieurs langues, des pages de faux produits, des annonces pharmaceutiques, des jeux d’argent ou des redirections.

La présence d’un résultat suspect dans Google ne signifie toutefois pas toujours que l’infection est encore active. La page peut toujours répondre avec du contenu spam, afficher un contenu différent à Google, rediriger, renvoyer une fausse page 404 avec un code 200, ou avoir déjà été supprimée sans que l’index ait encore été actualisé.

La bonne méthode consiste donc à vérifier l’état actuel des URL, nettoyer la source du piratage, corriger les réponses HTTP puis laisser Google constater la disparition. Supprimer les résultats dans Search Console sans corriger WordPress ne traite pas la cause.

Ce guide explique quoi faire lorsque des pages spam apparaissent dans Google pour votre site WordPress, comment éviter les erreurs de désindexation et quand demander un audit SEO après piratage.

À quoi reconnaît-on une injection de pages spam dans Google ?

L’injection SEO ne prend pas toujours la même forme. Le contenu peut être directement visible sur le site, réservé aux robots d’exploration ou déclenché seulement pour certains visiteurs.

Des titres en japonais, chinois ou dans une langue sans rapport avec le site

Les résultats peuvent présenter des caractères japonais ou chinois, des noms de marques, des prix et des descriptions commerciales alors que le site est normalement rédigé en français. Le « Japanese keyword hack » est une forme documentée de cette attaque, mais la langue n’est qu’un indice : des campagnes similaires utilisent l’anglais, le russe ou des textes générés automatiquement.

Des pages casino, pharmacie, contrefaçon ou faux produits

Le spam peut cibler des requêtes très éloignées de votre activité : paris sportifs, médicaments, crédits, produits de luxe, téléchargements ou contenus adultes. Certaines pages affichent votre logo ou des éléments du thème afin de paraître légitimes.

Des URL aux chemins inhabituels

Vous pouvez voir des répertoires aléatoires, des suites de chiffres, des extensions de fichier inattendues, des paramètres étranges ou des URL qui ne correspondent pas à la structure habituelle de WordPress. Le nombre de pages peut aller de quelques unités à plusieurs milliers.

Un contenu différent selon le visiteur

En ouvrant l’URL directement, vous pouvez voir la page d’accueil, une erreur ou une page apparemment normale, tandis que Google affiche un contenu spam. Cette différence peut provenir d’un cache ancien, mais aussi d’une technique de dissimulation qui adapte la réponse au robot, au référent, à l’adresse IP, au terminal ou à la localisation.

Une hausse soudaine des impressions sur des requêtes inconnues

Le rapport Performances de Search Console peut faire apparaître des mots-clés étrangers, des noms de produits ou des expressions sans rapport avec votre activité. Les pages associées permettent souvent de repérer des familles d’URL qui n’étaient pas visibles dans la navigation du site.

Une page suspecte dans Google prouve-t-elle que WordPress est encore piraté ?

Pas nécessairement. Elle prouve que Google connaît ou a connu cette URL, mais pas toujours que le contenu malveillant est encore servi aujourd’hui. Il faut distinguer l’état du résultat de recherche de l’état technique actuel de la page.

Ce que vous observez	Interprétation possible	Vérification prioritaire
La page affiche encore du spam avec un code 200	L’injection est active ou le contenu n’a pas été nettoyé	Contenu, base de données, fichiers, règles serveur et générateur des URL
La page redirige vers un site tiers	Redirection malveillante encore active ou conditionnelle	Chaîne de redirection, fichiers serveur, thème, extensions et scripts
La page semble absente mais renvoie 200	Fausse page 404 ou soft 404	Code HTTP réel et contenu reçu par Google
La page renvoie 404 ou 410	La correction permanente peut être en place, mais Google n’a pas encore retraité l’URL	Date du dernier crawl, liens et sitemap résiduels
La page est propre mais le titre Google reste ancien	L’extrait ou la version indexée n’a pas encore été actualisé	Inspection de l’URL et dernier crawl
La page diffère entre votre navigateur et Google	Cache ancien ou dissimulation	Version indexée, test en direct et réponse selon le contexte

Un résultat ancien peut donc rester visible après le nettoyage. À l’inverse, une URL qui affiche une erreur dans votre navigateur peut encore servir du spam à Google. C’est pourquoi la vérification doit combiner Search Console, les réponses HTTP, les journaux et l’analyse de WordPress.

Les vérifications à mener pendant la première heure

Période	Objectif	Actions prudentes
0 à 10 minutes	Préserver les exemples	Copier les URL, requêtes, titres, captures, dates et éventuels messages Search Console
10 à 20 minutes	Qualifier l’état des URL	Inspecter plusieurs pages représentatives et relever les codes HTTP, redirections et versions indexées
20 à 30 minutes	Contrôler Search Console	Vérifier Problèmes de sécurité, propriétaires, utilisateurs, sitemaps, performances et indexation
30 à 45 minutes	Préserver l’environnement	Créer une copie ou un snapshot, conserver les journaux et suspendre les changements non indispensables
45 à 60 minutes	Définir le périmètre	Regrouper les URL par modèle, identifier les fonctions critiques et préparer le diagnostic

Si le site présente aussi des comptes administrateurs inconnus, des fichiers suspects, des e-mails anormaux ou des redirections, appliquez le protocole général Site WordPress piraté : que faire ?.

Où trouver l’étendue réelle des pages injectées ?

Aucun rapport isolé ne fournit toujours une liste complète. Il faut recouper plusieurs sources afin d’identifier les modèles d’URL, les dates et les mécanismes de génération.

Le rapport Problèmes de sécurité

Le rapport Problèmes de sécurité de Search Console peut signaler une injection d’URL, une injection de contenu, du code malveillant ou des pages trompeuses. Les URL affichées ne constituent qu’un échantillon : l’absence d’exemple ne signifie pas nécessairement que le site est sain.

L’outil d’inspection d’URL

L’inspection d’URL permet de comparer la version indexée et la page publiée, de vérifier la réponse obtenue, la possibilité d’exploration et la date du dernier crawl. Inspectez plusieurs URL appartenant à des familles différentes plutôt qu’un seul exemple.

Les rapports Performances et Indexation des pages

Filtrez les requêtes, pays, pages et périodes pour repérer une hausse anormale d’impressions ou de clics. Le rapport d’indexation peut révéler des volumes inhabituels d’URL indexées, explorées, redirigées ou classées comme soft 404.

Les sitemaps

Vérifiez les sitemaps déclarés dans Search Console, les fichiers XML présents sur le serveur et les URL réellement incluses. Une campagne de spam peut modifier un sitemap existant ou en ajouter un nouveau afin d’accélérer la découverte des pages parasites.

Les propriétaires et utilisateurs Search Console

Contrôlez les propriétaires vérifiés, les utilisateurs et les méthodes de validation. Certaines variantes du piratage par mots-clés japonais ajoutent un propriétaire inconnu ou un jeton de vérification afin de manipuler les sitemaps et les paramètres du site.

Les recherches de type site:

Une recherche `site:votredomaine.fr` associée à des termes inhabituels peut faire ressortir des pages inconnues. Elle constitue un outil d’exploration, pas un inventaire exhaustif ni un compteur fiable. Les décisions doivent s’appuyer sur les données techniques et Search Console.

Les fichiers, la base de données et les journaux

Les URL peuvent être générées par un fichier PHP, une règle serveur, un thème, une extension, une tâche planifiée, une table de base de données ou un mécanisme qui recrée les pages après suppression. Les journaux d’accès et d’erreurs aident à relier les requêtes aux fichiers exécutés et à la chronologie de l’incident.

Classer les URL avant de décider de leur traitement

Toutes les URL suspectes ne doivent pas recevoir la même réponse. La bonne action dépend de leur nature et de l’état que vous souhaitez conserver.

Type d’URL	État souhaité après correction	Traitement adapté
Fausse page créée uniquement par le pirate	Disparition définitive	Supprimer le générateur et renvoyer 404 ou 410
Page légitime dont le contenu a été remplacé	Conserver la page	Restaurer le contenu propre, conserver 200 et vérifier la canonique
URL parasite redirigée vers l’accueil	Disparition définitive	Supprimer la redirection générique et renvoyer 404 ou 410
Page utile déplacée vers un vrai équivalent	Transmettre vers l’équivalent	Redirection 301 uniquement vers la page réellement correspondante
Page qui doit rester accessible mais pas indexée	Accessible hors Google	200 avec noindex, en laissant Google l’explorer
URL qui affiche une erreur avec un code 200	Erreur reconnue comme telle	Corriger le serveur pour renvoyer un véritable 404 ou 410

Le traitement doit être cohérent pour toute une famille d’URL. Si le même chemin produit parfois du spam, parfois une redirection et parfois une page normale, l’infection ou la règle de génération n’est probablement pas totalement corrigée.

Nettoyer WordPress avant de chercher à désindexer

La suppression des résultats Google intervient après la correction technique. Tant que le site génère encore les pages, toute demande de retrait restera temporaire et de nouvelles URL pourront remplacer les précédentes.

Un diagnostic complet doit notamment contrôler :

• l’intégrité des fichiers du cœur WordPress ;
• les extensions, thèmes et composants non utilisés ;
• les répertoires `uploads`, `mu-plugins` et les fichiers de configuration ;
• les règles `.htaccess`, la configuration serveur et les redirections ;
• les utilisateurs WordPress et les comptes administrateurs ;
• la base de données, les options, contenus, widgets et injections de scripts ;
• les tâches planifiées WordPress et serveur ;
• les sitemaps, fichiers de vérification et propriétaires Search Console ;
• les accès à l’hébergement, SFTP, SSH, base de données et services tiers ;
• les journaux disponibles et la chronologie des modifications.

Le nettoyage ne consiste pas seulement à supprimer les pages visibles. Il faut retirer le code qui les crée, fermer le point d’entrée, révoquer les accès non autorisés et vérifier la persistance. Consultez le guide consacré au nettoyage d’un site WordPress piraté pour comprendre le périmètre de cette intervention.

Comment supprimer durablement les pages spam de Google ?

1. Supprimer le contenu et le mécanisme qui le génère

Une URL parasite ne doit plus servir de contenu spam, de redirection malveillante ni de page générée dynamiquement. Vérifiez plusieurs variantes du même modèle, y compris des URL qui n’ont jamais été indexées, afin de confirmer que la règle de génération a disparu.

2. Renvoyer le bon code HTTP

Pour une fausse page définitivement supprimée, un véritable code 404 ou 410 indique que le contenu n’existe plus. Une page qui affiche « introuvable » tout en renvoyant 200 risque d’être traitée comme une soft 404 et de continuer à être explorée.

3. Conserver les pages légitimes avec un contenu propre

Si le pirate a modifié une page réelle, ne la supprimez pas par réflexe. Restaurez son contenu, sa balise title, sa méta description, ses données structurées, ses liens et sa canonique. Elle doit continuer à répondre 200 si elle reste utile.

4. Retirer les URL parasites des sitemaps et du maillage

Les sitemaps ne doivent contenir que les URL canoniques que vous souhaitez voir indexées. Supprimez également les liens injectés dans les menus, widgets, articles, modèles, flux ou données structurées.

5. Laisser Google explorer les URL supprimées

Ne bloquez pas immédiatement les anciens chemins dans `robots.txt`. Google doit pouvoir les revisiter pour constater le code 404, 410 ou la directive noindex. Un blocage d’exploration peut empêcher la lecture du nouvel état et prolonger la présence d’une URL connue.

6. Inspecter des URL représentatives

Testez plusieurs modèles : une ancienne page japonaise, une URL casino, une URL avec paramètre et une page légitime restaurée. Vérifiez le code, le contenu, la canonique et l’absence de redirection conditionnelle.

7. Mettre à jour les sitemaps propres

Une fois le site stabilisé, conservez dans le sitemap les URL légitimes et actualisées. Il n’est pas nécessaire d’ajouter les URL en erreur au sitemap pour demander leur suppression.

8. Demander un examen si Google signale un problème de sécurité

Lorsque le rapport Problèmes de sécurité contient une alerte, ne demandez l’examen qu’après avoir corrigé tout le site, pas seulement les exemples fournis. Décrivez le problème, les mesures prises, la cause corrigée et les contrôles réalisés.

404 ou 410 : quel code utiliser pour les fausses pages ?

Les deux codes conviennent pour signaler qu’une URL n’existe plus. Le code 410 exprime explicitement qu’une ressource a été supprimée de manière définitive ; le code 404 indique qu’elle n’a pas été trouvée. Dans la pratique, Google traite les erreurs 4xx — à l’exception de 429 — comme un signal d’absence pour son pipeline d’indexation.

Il ne faut donc pas transformer la question en faux choix absolu. Utilisez 410 lorsque vous contrôlez clairement une famille de pages parasites supprimées et que votre infrastructure le permet. Un 404 réel, stable et cohérent reste parfaitement adapté.

Le point déterminant est surtout d’éviter :

• un code 200 avec une page d’erreur visuelle ;
• une redirection systématique vers l’accueil ;
• une réponse différente selon le robot ou le référent ;
• le retour intermittent du contenu spam ;
• des liens internes ou sitemaps qui continuent à présenter l’URL comme valide.

Faut-il utiliser l’outil de suppression de Search Console ?

L’outil Retraits de Search Console peut masquer rapidement une URL ou un préfixe dans les résultats. Il est utile lorsqu’une page de phishing, un faux produit ou un résultat portant atteinte à la marque doit disparaître rapidement pendant que Google retraite la correction permanente.

Ce retrait reste temporaire. Il ne supprime ni le fichier, ni la règle qui génère la page, ni l’URL de l’infrastructure. Si la page répond encore 200 ou redevient accessible, elle peut réapparaître après l’expiration du retrait.

Utilisez cet outil de manière ciblée :

• pour les URL particulièrement visibles ou dangereuses ;
• pour une famille clairement délimitée par un préfixe, après avoir vérifié qu’aucune page légitime ne partage ce chemin ;
• en complément d’un 404, 410 ou noindex permanent, jamais à leur place ;
• après avoir sauvegardé la liste des URL et les preuves nécessaires au diagnostic.

Pourquoi ne faut-il pas rediriger toutes les pages spam vers l’accueil ?

Une redirection 301 est destinée à signaler qu’une ressource a été déplacée vers un contenu équivalent. Une fausse page japonaise, casino ou pharmacie n’a généralement aucun équivalent sur votre site. La rediriger vers l’accueil crée une correspondance artificielle et peut être interprétée comme une soft 404.

Cette pratique présente plusieurs risques :

• elle conserve inutilement une chaîne d’URL parasites ;
• elle complique le diagnostic en masquant l’état réel des pages ;
• elle peut envoyer des visiteurs vers l’accueil alors qu’ils attendaient un contenu frauduleux ;
• elle ne garantit pas la transmission d’une quelconque valeur SEO ;
• elle empêche de distinguer les vraies migrations des suppressions de sécurité.

Réservez les redirections aux pages légitimes qui disposent d’un véritable remplacement. Pour les URL créées par le pirate, renvoyez 404 ou 410.

Comment demander un réexamen de sécurité à Google ?

Une demande d’examen est pertinente lorsque Search Console signale un problème de sécurité. Elle ne remplace pas la désindexation naturelle des URL et n’est pas nécessaire simplement parce qu’un ancien résultat apparaît encore sans alerte active.

Avant d’envoyer la demande, vérifiez que :

• tous les types de problèmes signalés ont été corrigés ;
• les exemples fournis et les autres URL du même modèle ont été traités ;
• le code ou la règle qui générait les pages a disparu ;
• les propriétaires et sitemaps inconnus ont été supprimés ;
• les accès ont été sécurisés et le point d’entrée probable corrigé ;
• plusieurs URL de contrôle renvoient l’état attendu ;
• aucune nouvelle page parasite n’apparaît dans les journaux ou les rapports.

Dans le formulaire, expliquez concrètement la nature de l’injection, les zones nettoyées, les accès révoqués, la vulnérabilité corrigée et les vérifications réalisées. Une demande vague envoyée trop tôt risque d’être refusée et de retarder la récupération.

Comment suivre la désindexation et la récupération SEO ?

La correction technique peut être immédiate, mais la mise à jour de l’index dépend du nouveau passage de Google sur chaque URL. Un site qui a généré des milliers de pages peut demander davantage de temps qu’un incident limité à quelques URL.

Indicateur	Ce que vous devez observer	Signal d’alerte
Problèmes de sécurité	Alerte résolue après examen ou absence de nouveau problème	Nouvelle catégorie de problème ou exemples supplémentaires
Inspection d’URL	404/410 pour les pages supprimées, 200 propre pour les pages légitimes	Contenu différent, redirection ou code 200 inattendu
Indexation des pages	Diminution progressive des URL parasites indexées	Hausse continue des URL découvertes ou soft 404
Performances	Baisse des impressions sur les requêtes spam	Nouvelles requêtes étrangères ou nouvelles familles d’URL
Sitemaps	Uniquement les URL légitimes	Sitemap inconnu ou pages parasites encore soumises
Journaux	Absence de recréation et baisse du crawl des anciennes URL	Nouvelles réponses 200 sur des chemins parasites

Ne promettez pas une date précise de disparition totale. Les URL peuvent être retraitées à des rythmes différents, et la récupération des positions légitimes dépend aussi de la durée de l’incident, des pages touchées, des avertissements de sécurité et de la confiance reconstruite.

Pour une vision plus large des impacts et du suivi, consultez Piratage WordPress et SEO.

Les erreurs qui ralentissent la résolution

Supprimer uniquement les résultats dans Search Console

Le retrait masque temporairement la visibilité, mais le site peut continuer à générer des pages et Google à les explorer. La cause doit être supprimée sur WordPress et l’hébergement.

Bloquer les URL dans robots.txt avant leur retraitement

Google ne peut alors plus lire le code 404, 410 ou noindex. L’URL peut rester connue plus longtemps, parfois avec un extrait limité.

Rediriger toutes les URL vers l’accueil

Cette redirection ne correspond pas à un déplacement réel et peut être traitée comme une soft 404. Elle brouille aussi la mesure du nombre de pages encore actives.

Passer tout le site en noindex

Une directive globale peut faire disparaître vos pages légitimes et aggraver la perte de visibilité. Le traitement doit viser les URL parasites ou les pages précisément concernées.

Supprimer les comptes et journaux sans conserver de traces

Les propriétaires Search Console, dates, fichiers de vérification, adresses IP et journaux peuvent aider à comprendre le point d’entrée. Exportez les informations utiles avant révocation ou purge.

Nettoyer les URL visibles seulement

Les exemples de Google ne sont pas exhaustifs. Recherchez les modèles, les variantes et le mécanisme de génération sur tout le site.

Demander un examen avant la fin du nettoyage

Une page oubliée, une règle persistante ou un propriétaire inconnu peut suffire à faire échouer la demande. Validez plusieurs URL et toutes les catégories de problèmes avant l’envoi.

Attendre que Google corrige un site encore infecté

Google peut exclure certains contenus piratés, mais il ne nettoie pas WordPress. Tant que le code malveillant reste actif, les pages peuvent réapparaître et le nombre d’URL augmenter.

Les informations à préparer pour un diagnostic

Pour accélérer l’analyse, rassemblez :

• l’URL principale du site et les propriétés Search Console utilisées ;
• cinq à dix exemples d’URL parasites appartenant à plusieurs modèles ;
• les captures des résultats Google et les requêtes associées ;
• la date du premier signal et l’évolution observée ;
• les messages du rapport Problèmes de sécurité ;
• les codes HTTP et redirections constatés sur quelques URL ;
• les propriétaires, utilisateurs et sitemaps présents dans Search Console ;
• les actions déjà menées dans WordPress, l’hébergement et Search Console ;
• la date des sauvegardes disponibles ;
• les extensions, thèmes ou modifications récentes ;
• l’impact sur les pages stratégiques, le trafic, les formulaires et les ventes.

Ne transmettez pas vos mots de passe dans le formulaire initial. Les accès éventuels doivent être demandés séparément, limités au strict nécessaire puis révoqués ou modifiés après l’intervention.

Questions fréquentes

Pourquoi des pages japonaises apparaissent-elles sur mon site dans Google ?

Une campagne de spam peut exploiter une faille, un accès compromis ou une règle serveur pour générer automatiquement des pages sous votre domaine. Le but est de profiter de son ancienneté et de son autorité afin de positionner des faux produits ou des liens affiliés.

Search Console ne signale aucun problème de sécurité : le site peut-il quand même être compromis ?

Oui. Le rapport est un signal important, mais il ne détecte pas nécessairement chaque infection ni chaque URL. Examinez les pages, les codes HTTP, les propriétaires, les sitemaps, les fichiers, la base de données et les journaux.

Le site est nettoyé, mais les pages spam restent dans Google : est-ce normal ?

Cela peut arriver tant que Google n’a pas revisité les URL. Vérifiez qu’elles renvoient durablement 404 ou 410, qu’elles ne figurent plus dans les sitemaps et qu’aucun mécanisme ne les recrée.

Faut-il utiliser 404 ou 410 ?

Les deux conviennent pour des URL définitivement absentes. Le 410 exprime une suppression volontaire, tandis que le 404 indique que la ressource n’a pas été trouvée. La stabilité de la réponse et l’absence de contenu parasite comptent davantage que la recherche d’un avantage théorique.

Puis-je mettre toutes les pages en noindex ?

Non. Le noindex est adapté à une page qui doit rester accessible mais ne pas apparaître dans Google. Pour des milliers de fausses URL créées par un pirate, supprimez le générateur et renvoyez 404 ou 410. Un noindex global peut faire disparaître les pages légitimes.

L’outil Retraits de Search Console peut-il supprimer des milliers d’URL ?

Il peut masquer des URL ou un préfixe, mais son effet est temporaire et la portée doit être vérifiée avec prudence. Pour un grand volume, la correction permanente repose surtout sur les réponses HTTP cohérentes, les sitemaps propres et le nouveau crawl de Google.

Un pirate peut-il s’ajouter comme propriétaire Search Console ?

Oui, certaines variantes du piratage par mots-clés japonais ajoutent un propriétaire ou un jeton de validation. Supprimez l’accès inconnu et le mécanisme de vérification associé, puis contrôlez les fichiers et règles serveur.

Combien de temps faut-il pour supprimer toutes les pages spam de Google ?

Il n’existe pas de délai garanti. Quelques URL fréquemment explorées peuvent disparaître rapidement, tandis qu’un corpus de milliers de pages peut demander plusieurs cycles de crawl. Le retrait temporaire peut accélérer la disparition visuelle des résultats les plus urgents.

Les positions SEO du site vont-elles revenir après le nettoyage ?

Une récupération est possible, mais elle dépend de la durée de l’incident, des pages légitimes touchées, des avertissements de sécurité, de la qualité du nettoyage et du temps nécessaire à Google pour réévaluer le site. Évitez toute promesse de retour immédiat ou complet.