---
title: "Site WordPress qui redirige vers une pub : couper la redirection"
description: "Une redirection vers un site de publicité, de casino ou de pharmacie vient presque toujours d’un code injecté dans votre WordPress. Plus rarement, elle est posée au niveau du serveur, du DNS ou du compte d’hébergement, auquel cas rien de ce qui suit ne la trouvera. Ce code se cache dans 6 emplacements possibles, dont […]"
url: "https://kentin-canelas.fr/site-wordpress-redirige-vers-pub/"
author: "Kentin Canelas"
date: "2026-08-17T08:03:32+00:00"
modified: "2026-08-17T08:38:11+00:00"
lang: "fr_FR"
categories: ["WordPress"]
---

# Site WordPress qui redirige vers une pub : couper la redirection

Une redirection vers un site de publicité, de casino ou de pharmacie vient presque toujours d’un code injecté dans votre WordPress.

Plus rarement, elle est posée au niveau du serveur, du DNS ou du compte d’hébergement, auquel cas rien de ce qui suit ne la trouvera. Ce code se cache dans 6 emplacements possibles, dont un qu’aucun des 6 guides concurrents que j’ai lus ne mentionne : le dossier `mu-plugins`, chargé automatiquement et invisible dans la liste des extensions.

La redirection est souvent conditionnelle, elle ne se déclenche que pour certains visiteurs, ce qui explique que vous ne la voyiez pas alors que vos clients la subissent. Couper le code ne suffit pas : il reste la porte d’entrée à fermer et les traces à effacer dans Google.

À retenir- La redirection se déclenche selon le terminal, le navigateur ou la provenance du visiteur : testez depuis un résultat Google, sur mobile, en navigation privée.
- 6 emplacements à vérifier : `.htaccess`, `wp\_options`, le thème, les extensions, `mu-plugins`, la base de données.
- Un fichier `.php` déposé dans `mu-plugins` s’exécute **sans aucune activation**, dans un onglet séparé que personne ne regarde.
- Retirer le code sans fermer la porte d’entrée conduit à une réinfection, souvent en quelques jours.
- Un nettoyage complet démarre à **290 euros HT**, avec une garantie de re-intervention de 30 jours.

## Ce qui se passe quand votre site redirige vers une publicité

Un visiteur ouvre votre site et se retrouve sur une page de casino, de pharmacie en ligne ou de contenu adulte. Votre WordPress exécute alors du code qui n’est pas le vôtre, déposé par un tiers qui monétise votre trafic.

Ce que ce code fait, concrètement : il intercepte la requête avant que votre page ne s’affiche, puis envoie le visiteur ailleurs. La destination change souvent d’un jour à l’autre, parce que les domaines utilisés sont bloqués au fil de l’eau et remplacés.

Les signes qui accompagnent le problème :

- Vos visiteurs vous signalent la redirection alors que le site vous paraît normal.
- Un écran rouge apparaît dans Chrome ou Firefox avant votre page.
- Des pages que vous n’avez jamais écrites apparaissent dans Search Console.
- Votre trafic depuis Google chute d’un coup, sans changement de votre côté.
- Vos e-mails partent en indésirable, si le serveur a aussi servi à envoyer du spam.

Ce qui rend cette infection coûteuse, ce n’est pas la redirection en elle-même : c’est sa durée. Un site qui redirige pendant 48 heures perd des visiteurs. Un site qui redirige pendant 3 semaines perd ses positions, parce que Google explore les pages générées par l’infection, les indexe, et peut finir par appliquer une action manuelle.

Une distinction utile. Si votre site affiche un message d’erreur au lieu de rediriger, vous n’avez pas le même problème : c’est une [panne technique ou une intrusion d’un autre type](/erreur-critique-wordpress/), qui se diagnostique différemment. Et si vous cherchez à mettre en place une redirection volontaire après un changement de domaine, rien de ce qui suit ne vous concerne : c’est une manipulation légitime, qui se fait depuis une extension dédiée.

![Les 4 tests pour reproduire une redirection malveillante conditionnelle](https://kentin-canelas.fr/wp-content/uploads/2026/08/02-redirection-wordpress-4-tests.webp)## Pourquoi vous ne voyez pas la redirection que vos visiteurs subissent

Parce que le code ne se déclenche pas pour tout le monde. C’est le point qui bloque le plus de dirigeants, et c’est aussi ce qui fait perdre des jours avant le diagnostic.

Le code injecté teste en général 3 choses avant de s’activer : d’où vient le visiteur, quel appareil il utilise, et s’il est déjà venu. Google documente ce comportement dans ses règles anti-spam : le visiteur qui arrive depuis un résultat de recherche est redirigé, celui qui tape l’adresse directement dans son navigateur ne l’est pas ([règles anti-spam Google](https://developers.google.com/search/docs/essentials/spam-policies)).

Le cas le plus courant vise les mobiles. Google a publié un guide dédié à ces redirections mobiles furtives, où le site reste normal sur ordinateur et bascule sur téléphone ([Search Central](https://developers.google.com/search/blog/2015/10/detect-and-get-rid-of-unwanted-sneaky)).

Voici comment reproduire la redirection vous-même, en 4 tests :

1. **Cherchez votre site dans Google** et cliquez sur le résultat, au lieu de taper l’adresse.
2. **Refaites-le depuis un téléphone**, sur le réseau mobile, pas sur votre wifi.
3. **Ouvrez une fenêtre de navigation privée** : si un cookie a été posé pour ne vous rediriger qu’une fois, il ne sera pas là.
4. **Demandez à quelqu’un d’extérieur** de tester, depuis sa connexion et son matériel.

Si l’un des 4 déclenche la redirection, vous avez la confirmation. Si aucun ne la déclenche alors que vos clients la signalent, ne concluez pas trop vite : la redirection peut cibler une zone géographique ou un opérateur que vous n’utilisez pas.

## Les 6 endroits où se cache le code qui redirige

Le code se loge presque toujours dans les mêmes endroits. Voici les 6 à vérifier en premier, l’ordre dans lequel les regarder, et ce que vous devez y voir quand tout est sain. La liste n’est pas exhaustive : `wp-config.php`, les fichiers de cache de `wp-content` et le dossier `uploads` peuvent aussi héberger du code, mais ils viennent après ces 6 là en fréquence.

| Emplacement | Comment vérifier | Ce qui est normal | Ce qui doit alerter |
|---|---|---|---|
| `.htaccess` à la racine | FTP, afficher les fichiers cachés | Le bloc `# BEGIN WordPress`, plus les blocs nommés de vos extensions de cache ou de sécurité, placés en dehors | Une ligne très longue et illisible, une `RewriteRule` vers un domaine inconnu, un bloc sans nom ajouté récemment |
| `wp\_options` | phpMyAdmin, lignes `siteurl` et `home` | Vos adresses à vous : identiques dans le cas courant, différentes si WordPress est installé dans un sous-dossier | Un domaine que vous ne reconnaissez pas |
| Le thème actif | FTP, `functions.php` et `header.php` | Du code lisible, indenté, cohérent avec le reste | Une ligne très longue en fin de fichier, du texte encodé illisible, un `eval` sur une variable |
| Les extensions | FTP, dates de modification du dossier | Des dates cohérentes avec vos mises à jour | Un dossier modifié à une heure où personne ne travaillait |
| **`mu-plugins`** | FTP, `wp-content/mu-plugins` | Vide, absent, ou les **modules de votre hébergeur** | Un fichier `.php` au **nom aléatoire**, non revendiqué |
| Le contenu en base | Recherche de `<script` dans `wp\_posts` | Vos scripts connus, ou aucun | Du script en fin d’article, identique sur plusieurs pages |

**Le dossier `mu-plugins`** mérite une explication, parce qu’il est absent de tous les guides que j’ai lus sur ce sujet. Les extensions qu’il contient sont chargées automatiquement par WordPress, avant les extensions normales, et **elles ne peuvent pas être désactivées depuis l’administration**. Elles n’apparaissent pas dans la liste habituelle des extensions, mais dans un onglet séparé « Indispensables » que personne ne consulte. Et surtout : il suffit d’y déposer un fichier `.php` **à la racine du dossier** pour qu’il s’exécute, sans jamais se connecter au tableau de bord. WordPress ne regarde que les fichiers PHP placés directement dans `mu-plugins`, pas ceux rangés dans un sous-dossier ([documentation WordPress](https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/)).

Pour un attaquant qui a déjà un accès en écriture, c’est l’endroit le plus discret du site.

⚠️ **Ne videz pas ce dossier sans regarder ce qu’il contient.** Les hébergeurs infogérés y déposent leurs propres modules de cache ou de supervision, en général préfixés de leur nom. Les supprimer casse des fonctions de l’hébergement. Ce qui doit alerter, c’est un fichier au nom aléatoire, récent, que ni vous ni votre hébergeur ne revendiquez. En cas de doute, demandez à votre hébergeur avant de toucher à quoi que ce soit.

![Les 6 emplacements où se cache le code d’une redirection malveillante WordPress](https://kentin-canelas.fr/wp-content/uploads/2026/08/03-redirection-wordpress-6-cachettes.webp)## Couper la redirection, dans l’ordre

L’ordre compte : commencez par ce qui est réversible, gardez une trace de tout, et ne supprimez rien sans copie.

1. **Sauvegardez l’état actuel** avant de toucher quoi que ce soit. Fichiers et base. C’est cette copie qui permettra de comprendre l’origine si le nettoyage tourne mal.
2. **Passez le site en maintenance** si vous le pouvez, pour ne plus exposer vos visiteurs pendant l’opération.
3. **Traitez les 6 emplacements** du tableau, dans l’ordre du tableau. Notez ce que vous trouvez à chaque étape.
4. **Changez tous les mots de passe** : administration WordPress, FTP, base de données, hébergement. Sans cette étape, le reste ne sert à rien.
5. **Retirez les comptes administrateurs** que vous ne reconnaissez pas, après avoir vérifié auprès de vos collaborateurs.
6. **Retestez avec les 4 tests** de la section précédente, pas seulement en tapant votre adresse.

2 points sur le `.htaccess`, parce qu’ils font perdre du temps. Le contenu situé **entre** les marqueurs `# BEGIN WordPress` et `# END WordPress` est régénéré par WordPress : ce que vous y écrivez sera écrasé à la prochaine mise à jour des permaliens ([documentation WordPress](https://developer.wordpress.org/reference/functions/insert_with_markers/)). Les règles légitimes de vos extensions se trouvent donc normalement **en dehors** de ce bloc, dans leurs propres blocs nommés. Ce qui doit vous alerter n’est pas leur position, c’est une ligne illisible ou un domaine que vous ne reconnaissez pas.

Une limite à connaître : si votre hébergement mutualise plusieurs sites sur le même compte, nettoyer un seul site ne suffit pas. Le code peut se rétablir depuis un site voisin resté infecté.

## Vérifier qu’elle ne revient pas

Une redirection qui réapparaît après nettoyage signifie que la porte d’entrée est restée ouverte. C’est la situation la plus fréquente sur les dossiers que je reprends.

Le mécanisme est le suivant. L’attaquant ne se contente pas d’injecter la redirection : il dépose aussi une **porte dérobée**, un fichier qui lui permet de revenir indépendamment de la faille d’origine. Retirer la redirection sans retirer la porte dérobée revient à repeindre une porte qu’on laisse déverrouillée.

Sur un dossier de nettoyage portant sur 12 sites hébergés au même endroit, j’ai retiré **27 portes dérobées actives**. Sur ce dossier précis, aucune n’avait été remontée par les scanners installés, parce qu’un scanner compare à des signatures connues et qu’un fichier écrit sur mesure n’en a pas.

> **Avant de considérer un site propre**, je vérifie : plus aucun fichier modifié à une date incohérente, plus aucun compte administrateur inconnu, plus aucune tâche planifiée non identifiée, et les 4 tests de redirection négatifs pendant 72 heures.

Si la redirection revient après un nettoyage sérieux, arrêtez les frais et faites intervenir quelqu’un : chaque jour supplémentaire aggrave la partie Google, qui est la plus longue à réparer. C’est le cœur de mon offre de [nettoyage de site WordPress piraté](/nettoyage-site-wordpress-pirate/). Une fois le site assaini, un [forfait de maintenance](/maintenance-wordpress/) sert précisément à ce que la situation ne se reproduise pas.

![Schéma montrant qu’une porte dérobée survit à la suppression de la redirection](https://kentin-canelas.fr/wp-content/uploads/2026/08/04-redirection-wordpress-porte-derobee.webp)## Ce qui reste à régler côté Google

Couper la redirection remet votre site en état pour vos visiteurs. Cela ne répare pas ce que Google a enregistré pendant l’infection, et c’est la partie la moins traitée par les guides concurrents : 2 sur les 6 que j’ai lus s’y arrêtent, en une phrase chacun.

3 choses restent à traiter, dans cet ordre.

**Les pages indésirables indexées.** Une infection par redirection s’accompagne souvent de pages générées automatiquement, indexées à votre nom. Elles se repèrent dans Search Console, section Indexation, et se comptent parfois par centaines.

Supprimer les fichiers ne les fait pas disparaître des résultats : Google conserve ce qu’il a indexé jusqu’à son prochain passage. 2 leviers existent. L’outil de suppression d’URL de Search Console masque une adresse pendant 6 mois, ce qui traite l’urgence mais pas le fond. Le traitement définitif consiste à renvoyer un code 410 sur ces adresses, qui indique une suppression définitive, puis à attendre le recrawl.

Tant que ces pages sont là, elles continuent d’apparaître sur des requêtes qui n’ont rien à voir avec votre activité, et elles diluent la perception que Google a de votre site.

**L’alerte de sécurité.** Si Google a marqué le site comme dangereux, l’écran rouge du navigateur persiste après le nettoyage jusqu’à un nouveau contrôle. Le rapport Sécurité de Search Console indique l’état exact et permet de demander ce contrôle. Cet écran ne vient pas que de Google : il s’appuie sur Google Safe Browsing, que Chrome consulte, et dont Firefox télécharge la liste toutes les 30 minutes environ ([Mozilla](https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work)). Une seule alerte coupe donc l’accès sur plusieurs navigateurs à la fois, y compris pour les visiteurs qui tapent votre adresse directement.

**La demande de réexamen.** Quand une action manuelle a été appliquée, elle ne se lève pas toute seule : il faut la contester depuis le rapport Actions manuelles, en décrivant ce qui a été fait ([documentation Search Console](https://support.google.com/webmasters/answer/2604723)). Une demande envoyée avant que le site soit réellement propre est rejetée, et la suivante est examinée plus lentement.

Cette partie relève du référencement plus que de l’administration système, et c’est pour cette raison qu’elle est souvent absente des interventions techniques. Elle s’appuie sur le même travail que celui d’un [consultant SEO WordPress](/technos-cms/consultant-seo-wordpress/) : lire Search Console en profondeur et piloter une désindexation.

Sur les délais, je ne peux rien vous garantir, et personne ne le peut : le retour dans les résultats dépend de la fréquence à laquelle Google recrawle votre site, qui varie d’un site à l’autre.

![Résultats Google avant et après désindexation des pages indésirables](https://kentin-canelas.fr/wp-content/uploads/2026/08/05-redirection-wordpress-avant-apres-google.webp)## Le faire soi-même ou déléguer

Les 6 vérifications de cet article sont à votre portée si vous avez un accès FTP et un accès à la base de données. Sur une infection simple, limitée au `.htaccess` ou au thème, il n’y a aucune raison de payer quelqu’un.

3 situations changent ce calcul :

- **La redirection revient après nettoyage.** Il reste une porte dérobée, et la chercher demande de comparer l’intégralité des fichiers à une version saine.
- **Le site est marchand.** Le coût d’une journée de redirection vers un concurrent ou une publicité, vous le connaissez mieux que moi.
- **Google a déjà réagi.** Pages indésirables indexées ou action manuelle : la remise en état demande du travail de référencement, pas seulement du nettoyage de fichiers.

Dans ces cas, envoyez-moi l’adresse de votre site via le [formulaire de contact](/contact/). Le formulaire prend moins de 2 minutes à remplir. Vous recevez un premier diagnostic sous 24 à 72 heures ouvrées, sans engagement, avec le périmètre constaté et un devis ferme si une intervention se justifie.

Un nettoyage complet démarre à **290 euros HT**, forfait fixe connu avant les travaux, avec une garantie de re-intervention de 30 jours. Cette garantie s’appuie sur une logique technique : une porte dérobée résiduelle non détectée se réactive dans la majorité des cas sous 30 jours. Au-delà, une nouvelle infection est presque toujours liée à une nouvelle cause, et relève donc d’un nouveau dossier. C’est un engagement de moyens renforcé, pas une garantie de résultat.

Si votre besoin est surtout d’éviter que cela se reproduise, regardez plutôt [ce que couvre la maintenance et ce qu’elle coûte](/maintenance-site-internet-prix/).

## Questions fréquentes

Mon site redirige seulement sur mobile, est-ce vraiment un piratage ?Oui, dans l’immense majorité des cas. Une redirection qui ne se déclenche que sur téléphone est un comportement documenté par Google comme une technique de spam : le code teste l’appareil du visiteur avant de s’activer, précisément pour rester invisible au propriétaire du site, qui travaille sur ordinateur. Aucune configuration WordPress normale ne produit ce comportement.

J’ai supprimé le code dans le `.htaccess` et la redirection est revenue, pourquoi ?Parce que le fichier a été réécrit par un code encore présent ailleurs. Le `.htaccess` est le symptôme, pas la source. Regardez les 5 autres emplacements du tableau, en particulier `mu-plugins` et les extensions, puis changez tous les mots de passe : tant que l’accès reste ouvert, le fichier sera réécrit autant de fois que nécessaire.

Est-ce que mon hébergeur peut nettoyer le site à ma place ?Certains hébergeurs proposent une restauration à une date antérieure, ce qui est utile mais insuffisant : si l’intrusion date de plusieurs semaines, la sauvegarde contient déjà le code. Peu d’hébergeurs prennent en charge la partie référencement, qui est celle qui reste après le nettoyage. Demandez précisément ce qui est inclus avant de vous engager.

Combien de temps mon site va-t-il rester déclassé dans Google ?Il n’existe pas de réponse honnête à cette question sous forme de délai. La remise en état dépend de la vitesse de recrawl de votre site, du fait qu’une action manuelle ait été appliquée ou non, et du nombre de pages indésirables à désindexer. Ce que je peux dire : plus le nettoyage tarde, plus cette partie s’allonge, parce que Google continue d’indexer les pages générées entre-temps.

Dois-je prévenir mes visiteurs ou mes clients ?Si la redirection les a exposés à des pages frauduleuses, la transparence vaut mieux que le silence, surtout en B2B. Et si le site traite des données personnelles et qu’une fuite est possible, la notification à la CNIL sous 72 heures s’applique. Une redirection seule n’implique pas nécessairement une fuite de données, mais elle prouve un accès en écriture au site : la question mérite d’être posée à votre conseil.

Sources- WordPress Developer Resources, must-use plugins : chargement automatique, impossibilité de les désactiver depuis l’administration, activation par simple dépôt de fichier : [developer.wordpress.org](https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/)
- Google Search Central, règles anti-spam, section sur les redirections furtives et le déclenchement selon le référent ou l’appareil : [developers.google.com](https://developers.google.com/search/docs/essentials/spam-policies)
- Google Search Central, détecter et supprimer les redirections mobiles furtives, publié en octobre 2015 : [developers.google.com](https://developers.google.com/search/blog/2015/10/detect-and-get-rid-of-unwanted-sneaky)
- Search Console, rapport sur les actions manuelles et procédure de demande de réexamen : [support.google.com](https://support.google.com/webmasters/answer/2604723)
- WordPress, `insert\_with\_markers()` : le contenu entre les marqueurs du `.htaccess` est généré dynamiquement et écrasé à chaque réécriture : [developer.wordpress.org](https://developer.wordpress.org/reference/functions/insert_with_markers/)
- Search Console, outil de suppression d’URL : le masquage dure environ 6 mois et n’est pas définitif : [support.google.com](https://support.google.com/webmasters/answer/9689846)
- Mozilla, fonctionnement de la protection contre l’hameçonnage et les logiciels malveillants dans Firefox : [support.mozilla.org](https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work)

---

*Source : [kentin-canelas.fr](https://kentin-canelas.fr/site-wordpress-redirige-vers-pub/)*