Site WordPress piraté avec redirection : trouver la cause et l'arrêter

Un client vous prévient : en cliquant sur votre site dans Google, il est arrivé sur un casino, une boutique douteuse ou une page qui lui annonce qu'il a gagné un téléphone. Vous tapez votre adresse, tout est normal. Vous recommencez sur votre ordinateur, toujours rien. Votre site est pourtant piraté, et la redirection est réglée pour épargner la seule personne capable de la supprimer : vous.

La cause peut tenir en trois lignes d'un fichier .htaccess, en une valeur changée dans la base de données ou en un script caché dans une extension que WordPress n'affiche pas. Voici comment constater la redirection, en déduire sa cause, la retirer dans le bon ordre et faire lever les sanctions de Google.

Les quatre formes d'une redirection pirate

Google le décrit dans ses règles concernant le spam : le code injecté par un pirate redirige les internautes, et le type de redirection dépend parfois de l'URL de provenance, du user-agent ou de l'appareil. En pratique, on rencontre quatre formes, et chacune oriente vers une cause différente.

• Seulement depuis Google. Le visiteur qui tape votre adresse voit votre site ; celui qui clique sur un résultat de recherche part ailleurs. Le code lit la provenance de la visite, le « referer » : il exploite votre trafic tout en restant invisible pour vous.
• Seulement sur mobile. L'ordinateur reste sur votre site, le téléphone est redirigé. Le code lit le type d'appareil annoncé par le navigateur.
• Une seule fois par visiteur. Le premier passage redirige, les suivants non : un cookie ou un stockage dans le navigateur mémorise que la victime a déjà été envoyée. Vous testez deux fois, la seconde est propre, et vous concluez à tort à une fausse alerte.
• Pour tout le monde, ou pour Google seul. Le site entier part ailleurs, parfois jusqu'à la page de connexion, ou bien seul le robot de Google est redirigé : vos visiteurs ne voient alors rien et c'est Google qui vous alerte.

Ce tri entre les visiteurs, Google l'appelle cloaking. Notre article sur le cloaking subi par un site piraté en détaille les mécanismes ; ici, on s'occupe de la redirection.

Constater la redirection vous-même

Commencez par vous déconnecter de WordPress : beaucoup de codes malveillants épargnent les administrateurs connectés.

1. Sur votre téléphone, en 4G plutôt que sur le wifi du bureau, ouvrez une fenêtre de navigation privée.
2. Cherchez votre entreprise dans Google et cliquez sur le résultat, au lieu de taper l'adresse.
3. Recommencez avec une autre page, puis le lendemain dans une nouvelle fenêtre privée : une redirection « une fois par visiteur » ne se rejoue pas.

Notez l'adresse d'arrivée, votre meilleur indice, et ne remplissez rien sur cette page. Les autres contrôles, de la recherche site: au Test des résultats enrichis, sont dans notre article pour vérifier si votre site est piraté.

Si vous êtes à l'aise avec un terminal, faites ce que recommande l'aide de Google sur les problèmes de sécurité : interroger le site avec cURL en changeant la provenance et le user-agent. La première commande se présente comme un iPhone venu de Google, la seconde comme un ordinateur qui tape l'adresse :

# Mobile, arrivé depuis Google
curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) AppleWebKit/605.1.15 Safari/604.1" \
     -e "https://www.google.com/" https://votresite.fr/ | grep -iE "^HTTP|^location"

# Ordinateur, accès direct
curl -sI -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/130.0 Safari/537.36" \
     https://votresite.fr/ | grep -iE "^HTTP|^location"

Deux lectures possibles :

• Une réponse 301 ou 302 avec une ligne location: vers un domaine inconnu : la redirection est faite par le serveur, par un .htaccess, un fichier PHP ou la configuration de WordPress. Si la réponse ne porte aucune trace de PHP, le .htaccess est le premier suspect.
• Une réponse 200 dans les deux cas, alors que le téléphone part ailleurs : la redirection se fait dans le navigateur, par du JavaScript. Retirez I de la commande pour télécharger la page, et cherchez dans le résultat window.location, location.replace, document.referrer ou un long bloc illisible appelant atob ou eval.

Écarter les fausses alertes

Toutes les redirections inattendues ne sont pas des piratages. Trois situations nous ont déjà trompés :

• Une extension qui envoie toutes les erreurs 404 vers l'accueil. Chaque adresse morte répond par une redirection, ce qui ressemble à un détournement sans en être un.
• Un WordPress multisite qui renvoie vers wp-signup.php?new=… : sa réponse normale à un nom de domaine qu'il ne connaît pas. Une erreur de configuration.
• Une redirection vers un autre site de votre propre entreprise, posée un jour par un prestataire et oubliée.

Le critère qui tranche : un domaine que personne chez vous ne connaît, et un comportement qui change selon l'appareil ou la provenance.

Du symptôme à la cause probable

Les causes une par une, et où les trouver

Les fichiers .htaccess, à tous les niveaux

Sur un serveur Apache, le .htaccess s'applique au dossier où il se trouve et à ses sous-dossiers. Celui de WordPress ne contient normalement qu'un bloc délimité par # BEGIN WordPress et # END WordPress, dont la documentation de WordPress donne le contenu standard. Tout ce qui se trouve en dehors est à justifier. Une ligne RewriteCond %{HTTP_REFERER} qui teste « google » ou RewriteCond %{HTTP_USER_AGENT} qui teste « android|iphone », suivie d'une RewriteRule vers un domaine extérieur, signe une redirection pirate.

Ne vous arrêtez pas à la racine. Les pirates déposent aussi des .htaccess dans wp-content/, wp-includes/, wp-admin/, uploads/, et dans le dossier parent du site sur certains hébergements. Si vous avez un accès SSH, listez-les tous avec leur date :

find . -name ".htaccess" -exec ls -l {} \;
grep -rniE "HTTP_REFERER|HTTP_USER_AGENT|RewriteRule .*https?://" --include=".htaccess" .

Gardez une copie du fichier piraté avant de le corriger : sa date de modification est souvent la seule date fiable du piratage.

L'adresse du site dans la base de données

WordPress stocke son adresse dans deux réglages de la table wp_options : siteurl et home. Il est aussi possible de la fixer dans wp-config.php avec les constantes WP_HOME et WP_SITEURL, comme l'explique la documentation sur le changement d'adresse. Un pirate qui modifie l'une de ces valeurs envoie tout le site, liens et ressources compris, vers son domaine. C'est brutal, visible de tous, et rapide à vérifier.

Le JavaScript injecté

C'est la cause des redirections « depuis Google » ou « sur mobile » qui répondent 200. Le script peut se trouver dans le thème (header.php, footer.php, functions.php), dans le contenu des articles, dans un widget, ou dans une option que le thème ou une extension affiche sur chaque page : zone « scripts d'en-tête », code de suivi, réglages du constructeur de pages. Il est généralement chiffré pour échapper aux recherches simples : le meilleur fil à tirer reste le domaine de destination noté plus haut.

L'extension fantôme et le mu-plugin

Une fausse extension au nom plausible peut se retirer elle-même de la liste affichée dans l'administration. Les « mu-plugins », placés dans wp-content/mu-plugins/, sont plus discrets encore : selon la documentation de WordPress, ils sont activés automatiquement, ne se désactivent pas depuis l'administration et n'apparaissent pas dans la liste habituelle des extensions. Un seul fichier y suffit pour rediriger et tout réinstaller après chaque nettoyage.

Une règle cachée dans votre extension de redirection

Si vous utilisez une extension de redirections, un pirate qui a obtenu un accès administrateur peut y ajouter sa propre règle, au milieu des vôtres. Elle ne touche alors qu'une adresse ou deux, souvent vos pages les mieux placées dans Google. L'extension Redirection range ses règles dans la table wp_redirection_items, Rank Math dans wp_rank_math_redirections : triez-les par date et relisez les plus récentes.

index.php, wp-config.php et les drop-ins

Le fichier index.php de la racine ne fait normalement que quelques lignes qui chargent WordPress : une version longue, avec du code chiffré, est piratée. Même examen pour le haut et le bas de wp-config.php. Enfin, WordPress charge automatiquement certains fichiers placés directement dans wp-content/, les drop-ins : object-cache.php et db.php à chaque chargement, advanced-cache.php quand le cache est activé. Un drop-in qu'aucune de vos extensions n'a installé n'a rien à faire là.

Tout passer en revue avec WP-CLI

Si vous avez un accès SSH et WP-CLI, lisez d'abord wp-config.php : WP-CLI le charge, et exécuterait le code qui s'y cache. Ajoutez ensuite --skip-plugins --skip-themes à chaque commande, pour que le code des extensions et du thème ne fausse pas les réponses. Une limite que la documentation de WP-CLI précise : même avec cette option, les mu-plugins sont chargés. Regardez donc ce dossier en premier.

# Persistance : mu-plugins et drop-ins
ls -la wp-content/mu-plugins/
ls -la wp-content/*.php

# Adresse du site
wp option get siteurl --skip-plugins --skip-themes
wp option get home --skip-plugins --skip-themes
grep -nE "WP_HOME|WP_SITEURL" wp-config.php

# Fichiers de WordPress et des extensions comparés aux originaux
wp core verify-checksums --skip-plugins --skip-themes
wp plugin verify-checksums --all --skip-plugins --skip-themes

# Administrateurs, y compris ceux masqués dans l'interface
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themes

# Le domaine de destination et les scripts, partout dans la base et les fichiers
wp db search "domaine-de-destination" --all-tables --skip-plugins --skip-themes
wp db search "<script" --all-tables --skip-plugins --skip-themes
grep -rl "domaine-de-destination" wp-content/ index.php wp-config.php

# Règles de l'extension Redirection, les plus récentes d'abord (adaptez le préfixe wp_)
wp db query "SELECT id, url, action_data FROM wp_redirection_items ORDER BY id DESC LIMIT 20" --skip-plugins --skip-themes

wp core verify-checksums compare les fichiers de WordPress à ceux de WordPress.org : tout fichier modifié est suspect. Une extension premium introuvable sur WordPress.org n'est pas malveillante pour autant ; une extension que vous n'avez jamais installée, si.

Corriger dans le bon ordre

Supprimer la redirection en premier est le réflexe naturel, et la raison pour laquelle elle revient.

1. Copier l'état piraté, fichiers et base de données, hors du serveur. C'est votre preuve, et le seul moyen de dater l'entrée.
2. Retirer la persistance : mu-plugins inconnus, fausses extensions (supprimer le dossier, pas seulement désactiver), drop-ins injustifiés, administrateurs inconnus.
3. Retirer la redirection : remettre le .htaccess au bloc standard de WordPress et supprimer ceux des sous-dossiers qui n'ont rien à y faire, corriger siteurl et home, enlever le script du thème, des contenus et des options, supprimer les règles ajoutées dans l'extension de redirection.
4. Remplacer le cœur de WordPress par des fichiers propres (wp core download --force --skip-content), puis réinstaller extensions et thème depuis leurs sources officielles.
5. Couper les accès du pirate : nouveaux mots de passe pour l'hébergement, le FTP, la base de données et chaque administrateur, nouvelles clés de sécurité (wp config shuffle-salts), suppression des mots de passe d'application inconnus.
6. Vider tous les caches : extension de cache, cache de l'hébergeur (Varnish par exemple), CDN. Une page mise en cache pendant le piratage continue de rediriger.
7. Recontrôler avec les commandes cURL plus haut et un téléphone qui n'a jamais visité le site. Une redirection 301 peut être conservée par les navigateurs : la norme HTTP la déclare mise en cache par défaut. Les visiteurs déjà redirigés peuvent donc l'être encore quelque temps après la correction.

Reste à trouver par où le pirate est entré : compte d'ancien prestataire, extension en retard de mises à jour, licence premium expirée. Tant que cette porte reste ouverte, tout recommence. Notre guide pour nettoyer un site WordPress piraté détaille cette recherche et la fouille du dossier uploads.

Chez OVH : les sauvegardes ne remontent pas loin

Sur un hébergement mutualisé OVHcloud, les sauvegardes automatiques de l'espace FTP couvrent le jour même, la veille, l'avant-veille, le dimanche précédent et le dimanche de deux semaines avant ; OVHcloud précise ne pas pouvoir fournir plus ancien. Au-delà, pas de version saine chez l'hébergeur. Elles restent utiles : on peut s'y connecter en lecture seule pour récupérer un .htaccess ou un index.php d'avant le piratage et le comparer à l'actuel, sans tout écraser.

Faire lever les sanctions de Google

Une redirection pirate peut déclencher deux choses dans Search Console : un signalement dans Problèmes de sécurité, avec parfois un avertissement rouge dans les navigateurs, et une action manuelle pour redirections trompeuses, y compris dans sa version propre au mobile. Une fois le site propre sur toutes ses pages, et seulement à ce moment, cliquez sur Demander un examen en décrivant ce que vous avez trouvé et corrigé. Google annonce un délai de quelques jours à quelques semaines, et déconseille d'envoyer une nouvelle demande avant d'avoir la réponse.

Si le site entier a été redirigé, soumettez de nouveau votre sitemap et demandez l'indexation de vos pages principales avec l'outil d'inspection d'URL. Le détail de la démarche est dans notre article sur les problèmes de sécurité dans Search Console.

Ne pas en arriver là

Ces redirections durent des semaines parce que le propriétaire tape son adresse, sur son ordinateur, souvent connecté à WordPress : il est le mieux placé pour ne rien voir. Une surveillance qui teste le site de l'extérieur, comme un téléphone qui arrive de Google, la détecte dès le premier jour. Ajoutez des mises à jour suivies, des comptes administrateurs retirés à la fin de chaque mission, la double authentification et des sauvegardes hors de l'hébergement.

C'est le contenu de notre maintenance à 200 € HT par mois. Pour d'autres symptômes, notre guide site piraté rassemble les familles de piratage, dont les pages de casino et de paris sportifs, les mots-clés japonais et le faux CAPTCHA Cloudflare.

Le faire vous-même ou le confier

Tout ce qui précède est faisable seul avec un accès SSH, du temps et de la méthode. L'erreur classique est de corriger le .htaccess, de constater que le site remarche, et de s'arrêter là : la redirection revient quelques jours plus tard, parce qu'un mu-plugin ou une fausse extension la réinstalle. Si vous préférez le confier, nous faisons ce parcours jusqu'au contrôle final, porte d'entrée comprise, avec un rapport écrit. BetterCallBil est référencé sur la plateforme Cybermalveillance.gouv.fr ; notre méthode décrit ce que nous vérifions avant toute intervention.

Bilal Destouches

Fondateur de BetterCallBil, prestataire référencé sur la plateforme Cybermalveillance.gouv.fr. Plus de dix ans de sites web, 200 sites gérés, et depuis 2026 une veille quotidienne des sites français qui servent du spam à Google. Notre méthode · Mentions légales