Comment des attaques invisibles peuvent saboter votre visibilité sans que vous le sachiez
Cet article s’adresse aux auteurs indépendants qui gèrent eux-mêmes leur site.
Il ne vise pas des experts en informatique, mais des créateurs qui ont besoin de comprendre les risques réels et les actions concrètes pour protéger leur travail.
Comme le sitemap — souvent perçu comme un simple détail technique — certains aspects invisibles d’un site conditionnent pourtant sa cohérence, sa lisibilité par les moteurs de recherche, et sa capacité à rester visible dans le temps.
WordPress n’est pas un problème en soi.
Il est une cible, précisément parce qu’il est largement utilisé.
L’objectif est simple : expliquer comment un site d’auteur peut être parasité sans symptôme visible, et comment mettre en place des protections minimales suffisantes pour sortir du champ des attaques de masse.
Quand Google voit un autre site que celui que vous croyez gérer
Sur un précédent site, j’ai découvert une anomalie presque par hasard.
En effectuant une recherche simple dans Google :
site:votresite.com
des centaines de pages apparaissaient, alors que je ne les avais jamais créées.
Il s’agissait notamment :
- de pages de vente,
- de contenus en japonais ou en anglais,
- d’URLs inconnues.
Dans l’administration WordPress, tout semblait normal.
Aucun article suspect, aucun contenu visible.
Pourtant, Google indexait autre chose.
Ce phénomène est connu sous le nom de hack japonais (Japanese SEO spam).
Le hack japonais : comprendre la logique
Pourquoi cette attaque existe
Ce type d’attaque ne cherche pas à détruire un site visuellement.
Il exploite la réputation existante du domaine.
Un site déjà indexé, crédible et actif constitue un support idéal pour :
- injecter du contenu parasite,
- détourner le budget de crawl,
- propager du spam via un domaine perçu comme légitime.
Les contenus sont souvent en japonais parce que ces marchés sont très concurrentiels et rentables, et surtout parce qu’un domaine ayant déjà une réputation propre est exploré et indexé plus rapidement par Google qu’un domaine neuf ou suspect.
Pourquoi Google indexe ces pages
Du point de vue du moteur :
- l’URL existe,
- le serveur répond correctement,
- le contenu est accessible,
- le domaine est reconnu.
Aucun signal immédiat n’indique une fraude.
Conséquence :
- dilution thématique du site,
- perte de cohérence sémantique,
- association à du spam,
- baisse progressive de visibilité.
Ce que cela signifie concrètement pour un auteur
Le danger principal n’est pas l’attaque elle-même, mais le temps pendant lequel elle reste invisible.
Dans mon cas :
- l’injection de contenu n’a pas été détectée immédiatement ;
- même après sécurisation,
- plusieurs mois ont été nécessaires pour que Google cesse d’afficher ces pages parasites.
Pendant ce temps, Google cessait progressivement d’afficher mon site sur les recherches réellement pertinentes pour mon contenu.
C’est là le cœur du problème : le site est perçu comme non pertinent et devient invisible sur le web, quand il ne s’agit pas d’une désindexation pure et simple.
Le site existe toujours, les contenus sont toujours là, mais ils ne sont plus visibles.
C’est précisément ce phénomène qui pousse de nombreux auteurs à abandonner : ils continuent à écrire et à publier, sans retour ni visibilité, et finissent par croire que leur travail n’intéresse personne.
Symptôme à surveiller
Pour vérifier si votre site est touché, il suffit de faire une recherche dans Google :
site:votresite.com
Si des pages apparaissent que vous n’avez jamais créées, votre site est concerné.
C’est le signal d’alerte principal.
Exemples concrets de protections simples et efficaces
Les protections suivantes consistent à agir à des endroits précis du site pour supprimer des accès évidents.
Environnement concerné
Les exemples ci-dessous s’appliquent à un site WordPress hébergé dans un environnement LAMP ou WAMP :
- Linux ou Windows
- Apache
- MySQL / MariaDB
- PHP
C’est le cas de la grande majorité des hébergements mutualisés.
Les règles utilisant .htaccess supposent donc un serveur Apache.
Sur un autre environnement (par exemple Nginx), les principes restent valables mais la mise en œuvre diffère.
Protéger la page de connexion (brute force)
Problème
La page wp-login.php est une cible classique d’attaques par force brute.
Où agir
Dans le fichier .htaccess à la racine du site.
Exemple
<Files "wp-login.php">
Require all denied
Require ip 123.456.789.000
</Files>
Remplacez l’adresse IP par la vôtre.
Effet
Seule votre IP peut accéder à la page de connexion.
Bloquer l’exécution de scripts dans le dossier des médias
Problème
Des fichiers exécutables peuvent être injectés dans /wp-content/uploads.
Où agir
Créer un fichier .htaccess dans le dossier :
/wp-content/uploads/
Exemple
<FilesMatch "\.(php|phtml|php3|php4|php5|phar)$">
Require all denied
</FilesMatch>
Effet
Les fichiers sont stockés, mais aucun script ne peut être exécuté.
Désactiver des fonctions WordPress inutiles
Désactiver l’édition de fichiers
Où agir
Dans wp-config.php.
define('DISALLOW_FILE_EDIT', true);
Désactiver XML-RPC
Où agir
Dans .htaccess.
<Files "xmlrpc.php">
Require all denied
</Files>
XML-RPC est parfois utilisé par certaines applications ou services tiers.
En l’absence de besoin identifié, le désactiver réduit fortement la surface d’attaque.
Contrôler ce que Google indexe
Problème
Google peut indexer des pages techniques sans valeur éditoriale.
Où agir
Dans le fichier robots.txt.
Exemple
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /feed/
Disallow: /*?*
Effet
Google se concentre sur le contenu éditorial, pas sur l’infrastructure.
Note
Si certaines pages techniques ont déjà été indexées, robots.txt ne suffit pas toujours.
D’autres mécanismes existent (noindex via balise meta ou en-tête HTTP), mais ils sortent volontairement du cadre de cet article.
Journaux et erreurs : un point critique souvent ignoré
Le problème concret
Par défaut, WordPress n’écrit pas de fichier debug.log.
En revanche, dès que le mode debug ou le logging est activé (volontairement ou non), un fichier peut apparaître ici :
/wp-content/debug.log
S’il est accessible publiquement, il peut révéler :
- des chemins internes,
- des noms de fichiers,
- des informations exploitables.
Vérification immédiate
Essayez d’accéder à :
https://votresite.com/wp-content/debug.log
Si le fichier s’affiche, le problème est réel.
Mesures concrètes
Empêcher l’écriture par défaut
Dans wp-config.php :
define('WP_DEBUG_LOG', false);
Rediriger les logs hors du site
@ini_set(
'error_log',
'/home/USERNAME/logs/site-runtime.log'
);
Le chemin doit être hors du répertoire web.
Bloquer l’accès serveur par sécurité
Dans .htaccess :
<Files "debug.log">
Require all denied
</Files>
<FilesMatch "\.(log|error_log|php_error\.log)$">
Require all denied
</FilesMatch>
Accéder aux fichiers du site : le minimum indispensable
Les réglages évoqués nécessitent un accès aux fichiers du site, généralement via FTP ou SFTP, fourni par l’hébergeur.
Cet accès permet notamment de modifier :
- le fichier
.htaccess, - le fichier
wp-config.php, - certains répertoires sensibles.
La plupart des hébergeurs fournissent les identifiants nécessaires et indiquent les outils compatibles.
Il existe de nombreux outils gratuits pour établir une connexion SFTP ; une recherche simple ou la documentation de l’hébergeur suffit à les identifier.
Conclusion
Un site d’auteur n’est pas seulement un support de publication.
C’est un actif.
Lorsqu’il est parasité, ce n’est pas seulement la visibilité qui est touchée, mais la continuité même du travail.
Comprendre ces mécanismes et appliquer quelques protections ciblées permet :
- d’éviter des mois d’efforts perdus,
- de préserver la cohérence éditoriale,
- de travailler sur des bases saines.
Synthèse
- Des attaques invisibles existent.
- Elles exploitent des configurations courantes.
- Quelques réglages suffisent à sortir du profil vulnérable.
- Ce déplacement suffit, dans la majorité des cas, à être laissé tranquille.