Site WordPress qui redirige vers un autre site : trouver la redirection

Vos visiteurs atterrissent sur une page de loterie, de pharmacie ou de faux support, et vous voyez votre site normalement. C'est la signature d'une redirection injectée, le plus souvent conditionnelle. Ce guide explique comment la reproduire, la trouver dans les fichiers ou la base de données, et fermer l'accès qui a servi à la poser.

Publié le 21 septembre 2026 Lecture : 10 minutes

Tous les guides

L'essentiel

  1. Reproduisez la redirection comme un visiteur : navigation privée, téléphone en données mobiles, arrivée par un résultat de recherche.
  2. Faites une copie complète du site en l’état, fichiers et base de données, avant de modifier quoi que ce soit.
  3. Changez les mots de passe de l'hébergement, du FTP, de la base de données et des administrateurs WordPress, puis renouvelez les clés de sécurité de wp-config.php.
  4. Cherchez la redirection à quatre endroits : .htaccess, les fichiers PHP, la base de données, les réglages d’adresse du site.
  5. Retirez aussi l'accès qui l'a posée : comptes administrateurs inconnus, fichiers PHP dans wp-content/uploads, extensions à réinstaller ou à supprimer.
  6. Consultez le rapport « Problèmes de sécurité » de Google Search Console et demandez un examen si le site y figure.

Pourquoi vous ne voyez pas la redirection

Une redirection posée lors d'un piratage choisit à qui elle s'applique. Elle épargne le plus souvent la personne qui gère le site, pour rester en place le plus longtemps possible. Les conditions les plus courantes :

Un message de client qui dit « votre site m'envoie ailleurs » se prend donc au sérieux, même si tout s'affiche correctement chez vous.

Reproduire la redirection

Placez-vous dans la situation du visiteur qui la subit :

  1. Ouvrez une fenêtre de navigation privée, cherchez le nom de votre entreprise dans un moteur de recherche et cliquez sur votre résultat.
  2. Recommencez depuis un téléphone, en données mobiles plutôt qu’en Wi-Fi.
  3. Notez l'adresse de destination, l'heure et l'appareil : ces trois informations servent à l'hébergeur et, plus tard, à la demande d'examen auprès de Google.

Si vous avez accès à un terminal, cette commande demande votre page d’accueil en se présentant comme un iPhone arrivé depuis Google :

Terminal (sous Windows, tapez curl.exe à la place de curl)
curl -s -i -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://www.google.com/" https://www.votre-site.com/

Lisez les premières lignes de la réponse. Un code 301 ou 302 suivi d'une ligne Location: vers une adresse inconnue signale une redirection faite par le serveur : elle vit dans .htaccess ou dans un fichier PHP. Un code 200 alors que le navigateur est redirigé signale une redirection faite dans la page, en JavaScript : elle vit le plus souvent dans la base de données ou dans un fichier du thème.

Avant de toucher au site : trois gestes

  1. Une copie complète en l'état. Fichiers et base de données, datée, rangée hors du serveur. Elle sert de preuve, de point de comparaison, et de filet si un nettoyage retire quelque chose d'utile.
  2. Les mots de passe, depuis un appareil sain. Espace client de l'hébergeur, comptes FTP ou SFTP, utilisateur de la base de données (reportez le nouveau dans wp-config.php, constante DB_PASSWORD), puis chaque compte administrateur WordPress.
  3. Les clés de sécurité. Remplacez les huit lignes AUTH_KEY à NONCE_SALT de wp-config.php par un jeu neuf, généré sur https://api.wordpress.org/secret-key/1.1/salt/. Toutes les sessions ouvertes sont fermées, celle de l'intrus comprise.
Avec WP-CLI, le troisième geste tient en une commande
wp config shuffle-salts

Où se cache la redirection

1. Le fichier .htaccess

À la racine du site, et parfois dans un sous-dossier, .htaccess peut recevoir des règles de réécriture ajoutées par l'intrus. Le bloc que WordPress écrit lui-même est court, encadré par # BEGIN WordPress et # END WordPress :

Le bloc que WordPress en français écrit pour un site installé à la racine du domaine
# BEGIN WordPress
# Les directives (lignes) entre « BEGIN WordPress » et « END WordPress » sont générées
# dynamiquement, et doivent être modifiées uniquement via les filtres WordPress.
# Toute modification des directives situées entre ces marqueurs sera surchargée.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Une règle RewriteCond qui teste %{HTTP_REFERER} (google, bing, facebook) ou %{HTTP_USER_AGENT} (android, iphone, mobile), suivie d'une RewriteRule vers une adresse extérieure, est la redirection. Les extensions de cache et de sécurité écrivent aussi leurs propres blocs, balisés à leur nom : rapprochez chaque bloc de la liste de vos extensions avant de le retirer.

2. Les fichiers PHP

WP-CLI compare les fichiers du cœur de WordPress et des extensions aux sommes de contrôle publiées par WordPress.org, et liste chaque fichier modifié ou ajouté :

Terminal, à la racine du site
wp core verify-checksums
wp plugin verify-checksums --all

La seconde commande couvre les extensions distribuées par le répertoire WordPress.org. Une extension achetée chez son éditeur se compare à une copie fraîche téléchargée depuis votre compte chez lui. C'est un cas fréquent : sur les 540 sites de PME sous WordPress de notre relevé du 1er septembre 2026, 66 % portent au moins une extension absente du répertoire public.

Sans WP-CLI, deux recherches donnent un premier tri :

Terminal, à la racine du site
find . -name "*.php" -mtime -30
find wp-content/uploads -name "*.php"

La première liste les fichiers PHP modifiés ces 30 derniers jours, la seconde les fichiers PHP rangés dans le dossier des médias, où ils sont suspects par défaut (certaines extensions y posent un index.php vide, qui est légitime). Une date de modification se falsifie : un fichier ancien reste à examiner s'il est au mauvais endroit.

Ouvrez en priorité wp-config.php, le index.php de la racine, le functions.php et le header.php du thème actif, et le dossier wp-content/mu-plugins : les extensions qui s'y trouvent se chargent d'office et ne se désactivent pas depuis l'administration. Les signes à chercher : eval(, base64_decode(, gzinflate(, str_rot13(, de longues chaînes illisibles, ou window.location suivi d'une adresse que vous ne connaissez pas.

3. La base de données

Une redirection en JavaScript s'insère volontiers dans le contenu des pages ou dans les réglages, où aucun fichier ne la montre. WP-CLI cherche une chaîne dans toutes les tables de WordPress :

Terminal
wp db search "<script"
wp db search "fromCharCode"

Sans WP-CLI, les mêmes recherches se lancent dans phpMyAdmin, onglet SQL :

SQL (remplacez wp_ par le préfixe défini dans wp-config.php, variable $table_prefix)
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';

Certains résultats sont légitimes : un outil de mesure d'audience, un bandeau de cookies ou un widget posé par vous. Ce qui ne correspond à rien de ce que vous avez installé est à examiner, en particulier un script qui construit une adresse à partir de codes de caractères.

4. Les réglages d'adresse et les comptes

Dans Réglages > Général, « Adresse web de WordPress (URL) » et « Adresse web du site (URL) » doivent porter votre domaine. Les mêmes valeurs peuvent être imposées dans wp-config.php par les constantes WP_HOME et WP_SITEURL : vérifiez les deux endroits.

Terminal
wp option get home
wp option get siteurl
wp user list --role=administrator

Quand les constantes sont définies, les deux premières commandes renvoient leur valeur. La dernière liste les administrateurs, avec leur date d'inscription ; dans l'administration, la même liste s'obtient depuis le menu Comptes, filtré sur le rôle administrateur. Un compte que personne ne reconnaît se supprime, en attribuant ses contenus à un compte légitime.

Retirer la redirection, puis l'accès qui l'a posée

Supprimer la ligne qui redirige arrête le symptôme. L'accès utilisé par l'intrus, lui, reste ouvert tant qu'il n'a pas été trouvé, et la redirection revient dans les jours qui suivent. L'ordre qui tient :

  1. Remplacez les fichiers du cœur par une copie neuve : supprimez les dossiers wp-admin et wp-includes, puis lancez wp core download --skip-content --force, qui réécrit le cœur sans toucher à vos extensions, thèmes et médias. La commande écrase les fichiers existants mais ne supprime aucun fichier ajouté : c'est pourquoi les deux dossiers se suppriment d'abord, et pourquoi les fichiers PHP inconnus de la racine se retirent à la main.
  2. Réinstallez le thème et chaque extension depuis leur source officielle, et supprimez ceux que le site n’utilise plus, désactivés compris : leurs fichiers restent sur le serveur.
  3. Retirez les fichiers PHP étrangers de wp-content/uploads, les règles ajoutées à .htaccess et les scripts trouvés dans la base.
  4. Contrôlez les tâches planifiées avec wp cron event list : une tâche au nom inconnu peut reposer le code.
  5. Mettez WordPress, le thème et les extensions à jour.
  6. Refaites les tests du début, depuis plusieurs appareils et pendant plusieurs jours.

Si le site conserve des données personnelles (formulaires, comptes clients, commandes), notez l'heure à laquelle vous avez constaté le piratage. Dans l'Union européenne, le RGPD prévoit de notifier une violation de données à caractère personnel à l'autorité de contrôle dans les 72 heures après en avoir pris connaissance, à moins qu'elle ne soit pas susceptible d'engendrer un risque pour les droits et libertés des personnes concernées.

Google, et ce que voient vos visiteurs

Quand Google détecte la redirection, Chrome peut afficher une page rouge « Site dangereux » avant d'ouvrir le site, et Google peut écrire sous votre résultat « Il est possible que ce site ait été piraté ». Le rapport Problèmes de sécurité de Google Search Console dit ce qui a été relevé et sur quelles adresses. Une fois le site nettoyé, le bouton Demander un examen lance la vérification.

Un site repris et tenu, après la redirection

Une redirection retirée laisse une question : qui tient le site ensuite ? Simafri reprend votre site WordPress, le remet en ligne sur une base que nous hébergeons, sécurisons et tenons à jour, et s'en occupe mois après mois. Vous gardez votre nom de domaine et votre contenu.

Faire reprendre mon site

Questions fréquentes

Pourquoi mon site redirige-t-il seulement sur mobile ?

Le code injecté lit le User-Agent du navigateur et ne redirige que les téléphones. La personne qui gère le site, souvent sur ordinateur, ne voit rien. Testez depuis un téléphone en données mobiles, ou avec curl en envoyant l'identifiant d'un navigateur mobile.

Réinstaller WordPress suffit-il à supprimer la redirection ?

Réinstaller le cœur réécrit les fichiers de WordPress, sans supprimer ceux qu'un intrus a pu y ajouter. La base de données, le thème, les extensions et le dossier des médias restent tels quels, et c'est là que la redirection et l'accès de l'intrus se trouvent le plus souvent. Le cœur neuf est une étape du nettoyage, à compléter par la base, les extensions, les comptes et les mots de passe.

Le site a été nettoyé, pourquoi la redirection revient-elle ?

Parce que l'accès qui a servi à la poser est encore là : un compte administrateur ajouté, un fichier PHP caché dans les médias, une tâche planifiée, une extension vulnérable. Chacun permet de reposer le code après le nettoyage. Vérifiez les comptes, le dossier wp-content/uploads, les tâches planifiées et les versions des extensions, puis changez à nouveau les mots de passe.

Comment savoir si Google a repéré la redirection ?

Ouvrez Google Search Console, puis le rapport Problèmes de sécurité : il liste les problèmes détectés et des exemples d'adresses. Si le site n'est pas encore validé dans Search Console, la validation par enregistrement DNS couvre tout le domaine.

Contactez-nous