Pourquoi mon site WordPress redirige-t-il vers des sites de spam ?

Votre site WordPress envoie les visiteurs vers des pages de spam ou d’arnaque ? Découvrez pourquoi cela arrive, pourquoi vous ne le voyez peut-être pas vous-même et quelles vérifications faire d’abord sans risque.

Ouvrir un ticket de support

Si des visiteurs vous disent que votre site les envoie vers un autre site, comme une fausse page de gain, un site de jeux d’argent ou de pharmacie, un avertissement « votre appareil est infecté » ou une page qui leur demande d’autoriser les notifications, votre site WordPress redirige très probablement le trafic sans votre accord.

La redirection peut toucher :

  • tous les visiteurs
  • uniquement les visiteurs sur téléphone mobile
  • uniquement les personnes qui arrivent depuis Google ou les réseaux sociaux
  • uniquement les nouveaux visiteurs
  • uniquement certaines pages
  • les visiteurs qui ne sont pas connectés à WordPress

Ce dernier point est important. Beaucoup de redirections malveillantes sont conçues pour se cacher du propriétaire du site. Vous ouvrez peut-être le site, constatez que tout semble normal et en concluez que le client s’est trompé. Souvent, ce n’est pas le cas.

Une redirection de ce type est généralement le signe que quelque chose a été ajouté au site : un script, une règle, une entrée dans la base de données ou un fichier. Cela ne signifie pas forcément que votre contenu, vos commandes ou les données de vos clients ont été perdus. Elle doit cependant être traitée comme un incident de sécurité tant que la cause n’a pas été trouvée.

Ce guide explique pourquoi la redirection peut vous être invisible, où elle se cache généralement, quelles causes légitimes écarter d’abord, ce que vous pouvez vérifier sans risque et quand il vaut mieux demander un support technique.

Que signifie une redirection de WordPress vers du spam ?

Une redirection demande au navigateur de quitter la page demandée pour ouvrir une autre adresse. Les redirections sont normales quand une page change d’adresse, qu’un site passe en HTTPS ou qu’un domaine change.

Le problème commence quand la redirection :

  • envoie les visiteurs vers un domaine qui ne vous appartient pas
  • n’a pas été créée par vous ou votre équipe
  • n’apparaît que dans certaines conditions
  • change de destination au fil du temps
  • revient après que vous pensiez l’avoir supprimée

Dans la plupart des cas, c’est la partie visible d’une compromission. Quelqu’un a trouvé un moyen d’ajouter du code au site, et il utilise votre trafic pour envoyer des personnes vers des pages qui lui rapportent de l’argent ou qui tentent de tromper les visiteurs.

Pourquoi cela fonctionne pour moi mais pas pour mes clients ?

C’est la source de confusion la plus fréquente.

Les redirections malveillantes sont souvent écrites pour ne s’activer que pour certains visiteurs. Cette technique s’appelle le cloaking. Le but est de ne pas être remarqué par le propriétaire du site, le développeur et parfois les scanners de sécurité, afin que la redirection reste active plus longtemps.

Le code peut vérifier :

  • si le visiteur est connecté à WordPress
  • si le visiteur utilise un téléphone ou un ordinateur
  • si le visiteur arrive d’un moteur de recherche ou d’un réseau social
  • si le visiteur est déjà venu sur le site, souvent grâce à un cookie
  • le pays ou l’adresse IP du visiteur
  • l’heure de la journée, ou un simple tirage au sort

Ainsi, la personne la plus susceptible de tester le site, un administrateur connecté qui le visite souvent et tape l’adresse directement, est justement celle qui a le moins de chances de voir la redirection.

« Ça marche pour moi » ne prouve pas que le site est sain.

Prenez au sérieux les signalements des clients et demandez-leur des détails : quel appareil, quel navigateur, comment ils sont arrivés sur le site et où ils ont atterri.

Écartez d’abord les causes légitimes

Toute redirection inattendue n’est pas un malware. Avant d’imaginer le pire, vérifiez si l’une de ces situations s’applique.

Un plugin ou une règle de redirection a été mal configuré

Beaucoup de sites utilisent un plugin pour gérer les redirections, par exemple après une refonte. Une règle avec une faute de frappe, un joker qui correspond à trop de pages ou une ancienne règle pointant vers un domaine expiré depuis peuvent envoyer les visiteurs vers une destination inattendue.

Le cas du domaine expiré mérite d’être noté : si une redirection pointe vers un domaine que personne n’a renouvelé, quelqu’un d’autre a pu l’enregistrer et le remplir de spam.

L’adresse du site est incorrecte après une migration

WordPress enregistre deux adresses : l’adresse web de WordPress et l’adresse web du site. Si une migration ou un changement de domaine n’a pas été mené correctement, le site peut continuer à envoyer les visiteurs vers un ancien domaine, une adresse de staging ou une URL d’hébergement temporaire.

Cela touche généralement tous les visiteurs, vous compris, ce qui permet de distinguer plus facilement ce cas d’une redirection malveillante.

Une régie publicitaire ou un script tiers

Si votre site affiche des publicités, une annonce peut parfois ouvrir une autre page ou rediriger les visiteurs. Les widgets intégrés, les outils de chat, les scripts de suivi et d’autres codes externes peuvent faire de même si le service qui les fournit est compromis.

Dans ce cas, vos fichiers WordPress peuvent être parfaitement sains, mais le problème se trouve tout de même sur vos pages et doit être traité.

Une règle du CDN, de l’hébergement ou du DNS

Les redirections peuvent aussi être configurées en dehors de WordPress : dans le panneau d’hébergement, dans un CDN comme Cloudflare ou chez le registraire du domaine. Une règle ajoutée à cet endroit, par erreur ou par une personne ayant accès à ce compte, s’applique avant même que WordPress n’intervienne.

Si aucune de ces causes n’explique ce que décrivent les visiteurs, traitez la redirection comme malveillante.

Où se cache généralement une redirection malveillante ?

Vous n’avez pas besoin de trouver le code vous-même, mais il est utile de savoir qu’une redirection peut se trouver à plusieurs endroits. C’est aussi pourquoi supprimer un seul élément ne suffit souvent pas.

Les emplacements courants sont :

  • du JavaScript injecté dans des pages, des articles, des widgets ou des réglages du thème, souvent chargé depuis un domaine externe
  • des règles serveur dans le fichier .htaccess, qui peuvent rediriger les visiteurs selon leur appareil ou le site d’où ils viennent
  • des réglages en base de données, comme l’adresse web de WordPress et l’adresse web du site, ou des options de thèmes et de plugins qui stockent des scripts
  • un plugin malveillant, parfois avec un nom convaincant, parfois masqué dans la liste des plugins
  • des fichiers de thème modifiés, comme l’en-tête ou le fichier functions.php
  • des fichiers du cœur de WordPress modifiés ou des fichiers supplémentaires placés parmi eux
  • des tâches planifiées qui remettent la redirection en place après sa suppression
  • des comptes administrateur inconnus qui permettent à l’attaquant de revenir

Un même incident utilise souvent plusieurs de ces moyens. Par exemple, un script en base de données peut effectuer la redirection, tandis qu’un fichier caché ailleurs remet le script en place chaque fois qu’il est supprimé.

Que peut-on vérifier sans risque ?

Ces vérifications ne demandent aucune compétence technique et ne modifient rien sur le site.

Essayer de reproduire la redirection comme un visiteur

Testez dans des conditions proches de celles d’un vrai visiteur :

  • déconnectez-vous de WordPress, ou utilisez une fenêtre privée ou de navigation incognito
  • utilisez un téléphone mobile, idéalement en données mobiles plutôt que sur le Wi-Fi de votre bureau
  • recherchez votre entreprise sur Google et cliquez sur votre propre résultat au lieu de taper l’adresse
  • essayez plusieurs pages, pas seulement la page d’accueil
  • demandez à un collègue ou à un ami de tester depuis son propre appareil

Si la redirection apparaît, n’interagissez pas avec la page de destination. N’autorisez pas les notifications, ne téléchargez rien et ne saisissez aucune information. Fermez l’onglet et notez l’adresse affichée si vous le pouvez.

Notez ce qui l’a déclenchée : appareil, navigateur, façon d’arriver sur le site et page concernée.

Consulter Google Search Console

Si votre site est connecté à Google Search Console, ouvrez :

Security & Manual Actions → Security Issues

(dans l’interface en français : Sécurité et actions manuelles → Problèmes de sécurité)

Google peut y signaler du contenu piraté, des malwares ou des pages trompeuses, avec des exemples d’URL. Ce sont des échantillons, pas une liste complète.

L’outil d’inspection d’URL peut aussi être utile. Tester l’URL en ligne montre comment Google récupère la page, ce qui peut différer de ce que vous voyez dans votre navigateur.

Si vous n’avez pas accès à Search Console, demandez à la personne qui gère le site ou son marketing.

Rechercher des signes évidents dans le tableau de bord WordPress

Si vous pouvez vous connecter, recherchez :

  • des plugins que vous ne reconnaissez pas dans Plugins → Installed Plugins (Extensions → Extensions installées)
  • des administrateurs que vous ne reconnaissez pas dans Users → All Users
  • des règles de redirection ajoutées récemment dans le plugin de redirection que vous utilisez
  • l’adresse web de WordPress et l’adresse web du site dans Settings → General (Réglages → Général)

Notez ce que vous trouvez, mais ne supprimez rien pour l’instant. Les utilisateurs et plugins inconnus sont des preuves, et les supprimer peut rendre plus difficile la compréhension de ce qui s’est passé.

Que pouvez-vous essayer sans risque ?

La bonne approche dépend de ce que vous avez trouvé et de l’importance du site pour votre activité.

Option 1 : corriger une redirection légitime

Si la cause est clairement une règle de redirection créée par vous ou votre équipe, une mauvaise adresse de site après une migration ou une règle dans le CDN ou le panneau d’hébergement, la corriger peut suffire.

Faites une seule modification, puis testez à nouveau depuis une fenêtre privée et un appareil mobile.

Si vous n’êtes pas totalement sûr que la redirection est légitime, ne vous arrêtez pas là : traitez-la comme malveillante jusqu’à preuve du contraire.

Option 2 : contacter votre hébergeur

Votre hébergeur peut peut-être vous dire :

  • si son scanner a signalé des fichiers sur votre compte
  • si des fichiers suspects ont été mis en quarantaine
  • si d’autres sites du même compte sont touchés
  • s’il existe un backup antérieur au problème

Le support de l’hébergeur peut aider à contenir l’incident, mais il ne nettoiera pas forcément WordPress en entier et ne trouvera pas forcément comment l’attaquant est entré.

Option 3 : limiter les dégâts pendant l’enquête

Si beaucoup de visiteurs sont touchés, envisagez de mettre en pause les publicités payantes et les campagnes e-mail qui envoient du trafic vers le site, et prévenez votre équipe pour qu’elle puisse rassurer les clients. Ce sont des précautions, pas une solution.

Option 4 : envisager un backup, avec prudence

Restaurer un backup antérieur au début de la redirection peut supprimer le code malveillant. Mais cela peut aussi :

  • ramener la même vulnérabilité qui a permis à l’attaquant d’entrer
  • contenir du code déjà présent mais pas encore actif
  • écraser des commandes, des saisies de formulaires ou des contenus récents
  • effacer les traces de ce qui s’est passé

Ne restaurez pas de backup avant de savoir à peu près quand le problème a commencé et quelles données seraient perdues. Après toute restauration, il faut encore trouver et fermer le point d’entrée d’origine.

Qu’est-ce qu’il vaut mieux éviter ?

Évitez de :

  • supposer que les signalements sont faux parce que vous ne voyez pas la redirection
  • cliquer jusqu’au site de spam pour « voir ce que c’est »
  • supprimer des fichiers ou des plugins au hasard
  • supprimer uniquement le script que vous avez trouvé et vous arrêter là
  • installer plusieurs plugins de sécurité en même temps
  • modifier de nombreux réglages en même temps
  • publier des logs, des captures d’écran de réglages ou des identifiants sur des forums publics
  • envoyer des mots de passe par simple e-mail

Modifiez une seule chose à la fois, gardez une trace de ce que vous avez fait et testez après chaque étape.

En cas de doute, s’arrêter est plus sûr que continuer. D4Hub peut prendre le relais à n’importe quel moment, y compris après une tentative de nettoyage qui n’a pas fonctionné.

Quand demander un support technique ?

Un support technique est recommandé lorsque :

  • vous ne trouvez pas d’explication légitime à la redirection
  • des clients continuent de la signaler après vos modifications
  • Google Search Console signale un problème de sécurité
  • vous avez trouvé des administrateurs, des plugins ou des fichiers inconnus
  • la redirection revient après avoir été supprimée
  • le site gère des paiements, des abonnements ou des données personnelles
  • plusieurs sites partagent le même compte d’hébergement
  • vous n’avez pas de backup récent et sain
  • vous n’êtes pas à l’aise avec les fichiers ou la base de données

Vous n’avez pas besoin de reproduire la redirection ni d’identifier le code avant de demander de l’aide. Une description claire de ce que vivent les visiteurs suffit pour commencer.

Quelles informations rassembler ?

Les éléments utiles sont :

  • l’URL du site
  • la destination vers laquelle les visiteurs sont envoyés, si elle est connue
  • les appareils et navigateurs concernés
  • la façon dont les visiteurs sont arrivés sur le site, par exemple depuis Google
  • si vous avez pu la reproduire
  • la date du premier signalement
  • toute notification de Search Console
  • les changements récents sur le site, l’hébergement ou le DNS
  • si WordPress est accessible et si un backup récent existe
  • les mesures déjà prises

N’envoyez pas de mots de passe, de clés privées ou d’identifiants complets par des canaux non sécurisés. D4Hub peut vous expliquer comment partager un accès en toute sécurité.

Comment D4Hub peut vous aider

L’objectif n’est pas seulement d’arrêter la redirection aujourd’hui, mais de s’assurer qu’elle ne revienne pas la semaine prochaine.

Selon la situation, D4Hub peut vous aider à :

  • reproduire la redirection dans les conditions décrites par les visiteurs
  • écarter les causes légitimes comme les règles de redirection, les migrations, les réglages du CDN ou les publicités
  • vérifier les fichiers WordPress, la base de données, les utilisateurs et les tâches planifiées
  • examiner les règles serveur, y compris le fichier .htaccess
  • repérer les plugins malveillants, les modifications du thème et les scripts injectés
  • supprimer la redirection et tout ce qui la réinstalle
  • trouver et fermer le point d’entrée d’origine
  • mettre à jour les composants vulnérables et sécuriser les comptes
  • évaluer les backups et planifier une restauration sans perdre les données récentes
  • faire le lien avec votre hébergeur
  • accompagner une demande de réexamen auprès de Google si un avertissement a été émis

Vous pouvez demander de l’aide à n’importe quelle étape : au premier signalement d’un client, après l’analyse du site par votre hébergeur ou après un nettoyage qui n’a pas tenu.

Ouvrir un ticket de support

Pour les utilisateurs autonomes : traquer la redirection

Les vérifications suivantes s’adressent aux personnes à l’aise avec la ligne de commande, WP-CLI, les gestionnaires de fichiers d’hébergement et SFTP.

Avant de commencer, faites un backup complet des fichiers et de la base de données, et conservez-le à part du site en ligne. Il préserve les preuves et vous donne un moyen de revenir en arrière. La plupart des vérifications ci-dessous se contentent de lire des informations, mais traitez chaque modification de fichier ou de base de données avec prudence, et modifiez une seule chose à la fois.

Vérifier les réglages d’adresse du site

Comparez les deux adresses enregistrées dans la base de données :

wp option get siteurl
wp option get home

Les deux doivent afficher votre propre domaine, avec le protocole attendu. Un domaine inconnu à cet endroit est un signe fort de problème.

Vérifiez aussi dans wp-config.php la présence de ces constantes, qui prennent le pas sur les valeurs de la base de données lorsqu’elles existent :

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Si elles existent et pointent vers une destination inattendue, notez-le avant de modifier quoi que ce soit.

Examiner le fichier .htaccess

Sur les serveurs Apache et LiteSpeed, ouvrez le fichier .htaccess dans le dossier racine de WordPress. Un bloc WordPress standard ressemble à ceci :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Les versions récentes peuvent inclure une ligne supplémentaire pour HTTP_AUTHORIZATION, et les plugins de cache ou de sécurité ajoutent souvent leurs propres sections clairement identifiées.

Méfiez-vous des règles qui vérifient HTTP_REFERER ou HTTP_USER_AGENT puis redirigent vers un domaine externe. Vérifiez aussi la présence de fichiers .htaccess dans les sous-dossiers, comme wp-content/uploads/.

Les sites sous Nginx n’utilisent pas .htaccess. Les règles de redirection se trouvent alors dans la configuration du serveur, ce qui demande généralement l’intervention de votre hébergeur.

Reproduire les redirections masquées avec curl

Vous pouvez demander une page en vous faisant passer pour un visiteur mobile qui arrive depuis Google :

curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1" -e "https://www.google.com/" https://example.com/

Regardez la ligne de statut et l’éventuel en-tête Location:. Un 301 ou 302 pointant vers un domaine qui ne vous appartient pas confirme une redirection côté serveur. Comparez avec la même commande sans -A ni -e.

Certains codes malveillants ne réagissent qu’à une requête complète, et non à la requête limitée aux en-têtes envoyée par -I. Pour enregistrer plutôt la page complète :

curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1" -e "https://www.google.com/" https://example.com/ -o page.html

Beaucoup de redirections se font en JavaScript après le chargement de la page, ce que curl n’exécute pas. Ouvrez page.html dans un éditeur de texte, pas dans un navigateur, et recherchez des scripts chargés depuis des domaines inconnus ou de longs blocs de code illisible.

Rechercher des scripts injectés dans la base de données

WP-CLI peut chercher dans la base de données sans la modifier :

wp db search '<script' --all-tables

Attendez-vous à de nombreux résultats légitimes, par exemple liés aux outils d’analyse, aux constructeurs de pages ou aux formulaires intégrés. Recherchez les balises script qui pointent vers des domaines que vous ne reconnaissez pas, ou du code fortement obfusqué. Vous pouvez aussi rechercher un domaine vers lequel des visiteurs ont été envoyés :

wp db search 'suspicious-domain.example' --all-tables

Ne lancez pas wp search-replace et ne supprimez pas de lignes sur la base de ces résultats si vous n’êtes pas certain du rôle de chaque entrée. Les données sérialisées des options de plugins peuvent être corrompues si elles sont modifiées à la main.

Vérifier les fichiers du cœur et des plugins

Ces commandes comparent vos fichiers avec les versions officielles :

wp core verify-checksums
wp plugin verify-checksums --all

La vérification des plugins ne fonctionne que pour ceux du répertoire WordPress.org. Les plugins premium et sur mesure seront signalés comme non vérifiables, ce qui n’est pas en soi un signe d’infection.

Regardez aussi dans wp-content/mu-plugins/. Les plugins placés à cet endroit se chargent automatiquement et n’apparaissent pas dans la liste normale des plugins.

Examiner les administrateurs et les tâches planifiées

wp user list --role=administrator
wp cron event list

Notez les comptes inconnus ou les événements planifiés inhabituels, avec leurs dates, avant de supprimer quoi que ce soit. Une tâche planifiée peut être ce qui remet la redirection en place après sa suppression.

Si vous trouvez quelque chose que vous ne comprenez pas, arrêtez-vous et demandez. D4Hub peut examiner les résultats avec vous ou reprendre l’investigation.

Questions fréquentes

Pourquoi je ne vois pas la redirection quand je visite mon propre site ?

Les redirections malveillantes ignorent souvent les administrateurs connectés, les visiteurs réguliers ou les personnes qui tapent l’adresse directement. Testez depuis une fenêtre privée, sur un appareil mobile en données mobiles, et en cliquant sur votre site dans les résultats de recherche Google.

Mon site est-il piraté s’il redirige vers du spam ?

Si vous avez écarté les plugins de redirection, les migrations, les règles du CDN et les scripts publicitaires, une compromission est l’explication la plus probable. Elle doit faire l’objet d’une investigation comme un incident de sécurité.

J’ai supprimé le script et la redirection est revenue. Pourquoi ?

Quelque chose d’autre sur le site la remet en place. C’est fréquent : un fichier caché, une tâche planifiée, un plugin malveillant ou un compte administrateur inconnu peut réinstaller la redirection. Il faut vérifier l’ensemble du site, pas seulement le script visible.

Google peut-il signaler mon site comme dangereux ?

Oui. Les redirections vers des pages trompeuses ou nuisibles sont une raison fréquente des avertissements de sécurité de Google. Consultez Search Console et traitez la cause avant de demander un réexamen.

Dois-je mettre le site hors ligne ?

Pas toujours. Si beaucoup de visiteurs sont redirigés et que la cause ne peut pas être stoppée rapidement, le mode maintenance peut limiter les dégâts pendant l’investigation. Pour une boutique ou un site d’adhésion, mettez cela en balance avec les commandes et les accès perdus.

D4Hub peut-il aider si je n’arrive pas à reproduire la redirection ?

Oui. Transmettez ce que les clients ont signalé, y compris les appareils et la façon dont ils sont arrivés sur le site. D4Hub peut essayer de la reproduire dans ces conditions et rechercher sur le site le code qui en est à l’origine.

Ressources associées

Services et technologies associés