Mon site redirige vers un autre site : trouver où ça se cache

Ce que « mon site redirige ailleurs » veut dire

Un 301/302 HTTP, un `meta refresh`, un `location.href` JS, un `window.location` après un test mobile, un iframe plein écran : le visiteur « part ». Parfois tout le monde, parfois seulement iPhone, parfois seulement depuis Google. D’où le diagnostic raté : « chez moi ça va ». L’article marche chez moi pose les tests. Ici : où ça se cache, concrètement.

Notez l’URL d’arrivée (domaine tiers, souvent jeux, pharma, support, adulte). Elle oriente parfois la campagne, rarement le fichier. Le fichier, lui, est chez vous. La page métier site qui redirige résume. Les deux articles suivants déplient mobile-only et referer Google.

Une redirect « légitime » (www, HTTPS, page déplacée) a le même symptôme visuel. L’horloge et la cible (un casino) tranchent. Ne videz pas htaccess pour un www mal réglé — mais ne rangez pas un casino dans « on a changé de thème ».

• Code HTTP (onglet réseau) : 301/302 vs 200 + JS.
• Qui est touché : tous / mobile / SERP / pays.
• URL d’arrivée capturée.

Reproduire avant de fouiller le FTP

Privée, 4G, clic depuis `site:` ou une SERP, user-agent iPhone, parfois un VPN pays. curl avec `-A` et `-e https://www.google.com/`. Sans reproduction, vous allez « corriger » un htaccess propre et rater le JS en option. Dix minutes de tests évitent deux heures de FTP.

Si vous ne reproduisez pas et que trois clients envoient la même URL d’arrivée : croyez-les, cherchez conditionnel, ne concluez pas « résolu ».

Copiez avant de retirer des lignes. Une redirect, c’est encore un incident : premiers gestes.

Piste 1 — le serveur (`.htaccess`, Nginx)

Cherchez `RewriteRule`, `Redirect`, `RewriteCond %{HTTP_USER_AGENT}`, `RewriteCond %{HTTP_REFERER}`. Une ligne vers un host que vous ne connaissez pas. Parfois obfusquée (hex). Isoler ces lignes, garder le stub permalien WP. Ne pas vider le fichier.

Nginx : `return 302`, `if ($http_user_agent)`. Chez l’hébergeur, fichier vhost, pas toujours éditable. Demandez un diff de conf si vous n’avez pas sudo.

Cloudflare / page rules / workers : la redirect peut ne plus être dans votre home. Ouvrez le dashboard. Un worker « marketing » oublié, ou un compte CF compromis. DNS : un A qui ne pointe plus chez vous — ce n’est plus une injection, c’est un takeover DNS. Vérifiez.

Piste 2 — le JavaScript (thème, base, GTM)

View-source visiteur (privée) vs view-source admin : ils diffèrent souvent. Un `<script>` en footer, un `eval`, un domaine inconnu. Origines : `header.php` / `footer.php`, widget, `wp_options` (theme_mods, widgets), plugin cache qui a figé le HTML sale, GTM détourné, JS inconnu pied de page.

Le script teste `screen.width`, `mobile`, `document.referrer`. D’où l’absence chez vous. Cherchez ces chaînes dans la base (`%referrer%`, `%location.href%`) via phpMyAdmin, pas seulement dans les fichiers.

Retirer le JS du thème et oublier l’option : la redirect revient au prochain chargement de widget. Les deux côtés.

Piste 3 — le PHP qui lit l’user-agent

`index.php` gonflé, mu-plugin, prepend `.user.ini`, un `include` dans `wp-blog-header.php`, un fichier à la racine appelé par auto_prepend. Le PHP décide avant même le thème : 302 ou echo d’un JS. Dates de modification, grep `HTTP_USER_AGENT`, `HTTP_REFERER`, `mobile`.

C’est la piste la plus « invisible » dans l’admin. Le site WP a l’air normal, les fichiers cœur sont sales. Comparez au zip. Backdoor.

Un seul des trois pistes corrigée : les deux autres tiennent. Checklist des trois, toujours, même si la première ligne htaccess « expliquait tout ».

Couper la ligne, pas tout le routing

Isoler, tester la reproduction (elle doit cesser sur le canal qui marchait), garder le stub. Une maintenance globale n’est pas nécessaire sauf phishing / exe. Couper ou pas.

Le cache : flush après retrait, sinon les visiteurs gardent le JS. Copiez une page sale avant le flush, pour le constat.

CDN : purge. Sinon vous « avez coupé » et le Texas voit encore le casino.

Google a déjà indexé la cible

`site:` et les titres. Inspection : un 301 encore servi à Googlebot. Après coupure, 200 sur vos vraies pages, 404/410 sur d’éventuelles URL pont. Désindexation des préfixes si un générateur a créé des chemins chez vous. Horloge 3 : délais.

Réexamen Safe Browsing seulement s’il y a une alerte, et seulement propre. Une redirect encore conditionnelle = refus.

Ne changez pas de domaine pour « échapper » aux snippets. Vous perdez l’historique, l’attaquant recommence.

Refermer l’entrée, sinon ce soir

Une redirect est un symptôme. Extension, admin, FTP, voisin. Secrets. Surveillance 48 h : la redirect revient = porte. C’est le motif du second appel « on avait pourtant enlevé la ligne ».

Les trois pistes, une checklist écrite. Puis WordPress pour les portes. Puis filet, pas pendant.

Page site qui redirige si vous voulez le déroulé court + déclaration de dossier.