Arrêter le parcours avant de modifier le site
Vous ouvrez votre site WordPress et le navigateur aboutit à une adresse que vous ne reconnaissez pas. Il peut s’agir d’une règle oubliée après une migration, d’un outil tiers ou d’un accès non autorisé. L’objectif est d’identifier le premier endroit qui envoie vers cette destination, puis de corriger cette cause sans effacer les traces ni désorganiser les autres pages.
Ne saisissez aucun identifiant sur la destination inconnue, ne téléchargez rien et n’acceptez pas ses demandes de notification. Si une alerte de sécurité apparaît, ne la contournez pas. Prévenez le responsable du site et l’hébergeur par leurs coordonnées habituelles.
Une fuite vers une page frauduleuse demande un confinement rapide, même si l’origine reste à établir. Les comparaisons de navigation décrites ici concernent les situations sans destination manifestement dangereuse. Pour une page signalée comme infectée, confiez l’observation technique à l’hébergeur sans la rouvrir dans votre navigateur habituel.
Décrire précisément le scénario observé
Notez l’adresse de départ, l’adresse finalement affichée et l’heure avec le fuseau. Conservez une capture déjà disponible plutôt que de répéter le trajet. Distinguez le domaine, qui identifie le site, du chemin de la page. Une ancienne page déplacée vers une nouvelle rubrique n’est pas le même problème qu’un départ vers un autre domaine.
Précisez comment la visite a commencé : favori, lien de recherche, lien dans un courriel ou saisie directe. Indiquez si le déplacement est immédiat, survient après quelques secondes ou suit un clic. Ces éléments orientent le diagnostic sans identifier automatiquement un responsable.
Relevez les appareils et comptes concernés à partir des signalements reçus. Un administrateur connecté peut ne pas voir ce qu’un visiteur déconnecté rencontre. Ne demandez pas aux lecteurs de multiplier les essais sur une page douteuse ; recueillez les circonstances déjà constatées et faites examiner les autres variantes dans un environnement approprié.
Préserver les preuves et savoir qui peut intervenir
Avant les changements, faites préserver l’état des fichiers, de la base et des réglages concernés. Demandez à l’hébergeur de conserver les journaux disponibles. Gardez séparément une copie antérieure et la copie observée pendant l’incident : cette dernière peut contenir des données utiles et le défaut recherché, sans constituer un état sain.
Pour les règles d’un service intermédiaire, conservez une capture privée de la condition, de la destination et de l’ordre d’exécution. Notez ensuite chaque changement avec son auteur et son heure. Une purge globale ou une restauration immédiate peut supprimer des indices sans fermer le moyen d’accès responsable.
Identifiez les accès disponibles : administration WordPress, compte d’hébergement, gestion du domaine et éventuel CDN, un service placé devant le serveur. Le rôle administrateur WordPress ne donne pas automatiquement accès aux autres panneaux. Sans autorisation sur la couche concernée, transmettez les observations à son responsable ; n’essayez pas de contourner ses permissions.
Relevez aussi la version de WordPress, le type d’hébergement et les composants récemment modifiés, depuis les écrans disponibles ou avec le responsable.
Choisir entre trois approches
La première approche concerne un phénomène limité à un navigateur ou à un appareil. Elle vérifie le point de départ réel, les extensions du navigateur et les réglages locaux, sans modifier WordPress. Un seul résultat différent reste un indice : le site peut aussi réserver son comportement à certains visiteurs.
La deuxième approche recherche une redirection légitime mal configurée. Elle convient si le problème suit une migration, une règle de domaine ou un changement de composant identifié. Vous comparez alors la configuration voulue et celle effectivement appliquée, avant une correction ciblée.
La troisième approche traite un comportement non autorisé ou dangereux. Si personne ne reconnaît la destination, si des comptes inconnus apparaissent ou si les modifications reviennent, associez le propriétaire et l’hébergeur. La priorité devient de limiter les dommages et d’établir comment le site a été modifié. Ne testez pas les trois parcours en changeant simultanément tous les réglages.
Approche 1 : isoler le navigateur sans effacer vos repères
Si le phénomène reste limité à votre appareil et qu’aucune alerte de malveillance n’impose l’arrêt, commencez par vérifier le favori utilisé. L’adresse mémorisée peut déjà être celle d’un service externe ou d’un ancien domaine. Comparez-la avec les documents du propriétaire, sans remplacer ce favori par une destination seulement supposée correcte.
Pour une comparaison autorisée, utilisez un profil de navigateur distinct, à jour, sans extension supplémentaire. Une fenêtre privée n’élimine pas nécessairement toutes les extensions. Préservez d’abord les textes non enregistrés dans les onglets de travail. N’effacez pas toutes les données du navigateur comme première manipulation.
Si plusieurs sites sans rapport présentent des fenêtres ou des redirections semblables, faites examiner l’appareil selon la procédure de sécurité de votre organisation. Une différence entre profils ne suffit pas à déclarer WordPress sain. Arrêtez les essais dès qu’une destination frauduleuse ou un téléchargement inattendu apparaît ; le responsable technique peut poursuivre sans exposer votre session administrative.
Lire le premier déplacement plutôt que seulement l’arrivée
Un responsable technique peut examiner la première réponse du site sans suivre automatiquement la destination. Une réponse HTTP de redirection utilise notamment un statut 301, 302, 307 ou 308 et un en-tête Location indiquant la cible. Une redirection peut aussi être déclenchée par du HTML ou du JavaScript dans une page reçue : l’absence de statut 3xx ne l’exclut donc pas.
Si un journal réseau d’une visite déjà faite est disponible dans Chrome, ouvrez Réseau dans les outils de développement et consultez la première requête de document. La fonction Conserver le journal garde les requêtes entre navigations ; elle ne reconstitue pas une visite qui n’a pas été enregistrée. Relevez statut, destination et moment du changement, sans rejouer la requête.
Ne transmettez pas un export réseau intégral publiquement : il peut contenir des cookies ou des paramètres privés. Si aucune trace n’existe et que la page est suspecte, demandez une capture technique au prestataire plutôt que de la rouvrir pour obtenir un journal.
Approche 2 : retrouver une règle voulue mais incorrecte
Avec un accès autorisé au panneau d’hébergement, consultez la rubrique de redirection du domaine. Vérifiez le domaine sélectionné, la destination, les conditions et les éventuels chemins conservés. Une règle prévue pour une ancienne rubrique peut viser accidentellement tout le site. Demandez qui l’a créée avant de la retirer.
Si Cloudflare est utilisé, le responsable ouvre les règles de redirection du domaine dans son tableau de bord. Il examine les règles individuelles et les listes de redirections, ainsi que leur ordre. La première règle applicable peut déterminer la destination ; modifier une règle plus bas ne change donc pas forcément le résultat.
Conservez la configuration initiale et comparez une adresse touchée à une adresse qui doit rester inchangée. Le simulateur de règles, si le rôle du compte y donne accès, aide à comprendre une condition sans constituer une preuve de fonctionnement du serveur d’origine. Ne désactivez pas l’ensemble du CDN ou du pare-feu pour cette vérification.
Vérifier les adresses WordPress et le composant concerné
Dans WordPress autohébergé, un administrateur fiable peut lire Réglages, puis Général, et relever l’adresse de WordPress et celle du site. La première peut contenir un sous-dossier légitime. Les deux champs ne doivent donc pas être rendus identiques par principe. Des valeurs imposées dans la configuration peuvent également rendre les champs non modifiables.
Comparez ces adresses au domaine validé par le propriétaire. Si une valeur pointe vers un domaine inconnu sans intervention reconnue, préservez-la puis passez au traitement d’incident. Une simple correction du champ ne suffit pas à expliquer comment il a changé.
Examinez aussi les réglages de redirection, de maintenance ou de campagne d’une extension déjà installée, uniquement si les indices la concernent. L’en-tête X-Redirect-By peut fournir une indication, mais sa valeur est modifiable : il n’identifie pas à lui seul le composant responsable. N’installez pas un gestionnaire supplémentaire pour masquer la destination sans retrouver son origine.
Appliquer une correction limitée et garder le retour arrière
Une règle légitime dont la destination erronée est confirmée peut être corrigée par son responsable. Notez l’ancienne condition et l’ancienne cible, puis changez seulement la valeur concernée ou désactivez cette seule règle. Préférez une correction vérifiable à une nouvelle redirection inverse qui allongerait la chaîne ou créerait une boucle.
Après modification, contrôlez l’adresse de départ et un chemin intérieur représentatif. Vérifiez que le visiteur arrive au contenu voulu et que les chemins qui ne devaient pas changer fonctionnent toujours. Si le résultat ne correspond pas à la décision du propriétaire, restaurez le réglage conservé et réexaminez la couche en cause.
Une modification des adresses WordPress peut faire perdre l’accès au tableau de bord. Avant de l’effectuer, prévoyez avec l’hébergeur le moyen de rétablir l’ancienne valeur. Si vous n’avez pas cet accès de secours ou si l’origine est douteuse, demandez l’intervention plutôt que de cliquer pour essayer.
Approche 3 : contenir un comportement non autorisé
Lorsque le propriétaire ne reconnaît ni la destination ni la modification, ouvrez un ticket d’incident depuis le compte client habituel de l’hébergeur. Donnez les adresses de départ touchées et les circonstances observées. Demandez quelles mesures peuvent interrompre le comportement dangereux tout en préservant les éléments nécessaires à l’analyse.
Le confinement peut demander une restriction de l’administration, une isolation du site ou une suspension temporaire de certaines fonctions. Sa portée appartient au responsable de l’environnement, surtout sur un hébergement partagé. Une page de maintenance ne garantit pas que le code malveillant ou les accès techniques ont cessé de fonctionner.
Faites examiner les accès capables de modifier le site : comptes WordPress, hébergement, transferts de fichiers et intégrations. Un compte inconnu doit être vérifié sans suppression immédiate de son contenu. Le changement des secrets et la fermeture des accès doivent être coordonnés depuis un appareil fiable ; retirer seulement le lien visible ne ferme pas nécessairement l’entrée utilisée.
Faire examiner fichiers et composants sans effacement général
L’hébergeur ou le mainteneur compare l’installation avec des copies de confiance et les changements documentés. Sur Apache, une redirection peut venir de la configuration ou d’un fichier .htaccess ; sur Nginx, la configuration du serveur peut contenir des règles de retour ou de réécriture. Remplacer .htaccess ne corrige pas une règle Nginx et peut supprimer des protections utiles.
Le comportement peut aussi provenir d’un thème, d’une extension, d’un composant obligatoire ou d’une ressource externe. Faites déterminer ce qui charge la redirection avant une intervention ciblée. Une recherche de chaînes de code suspectes fournit des pistes, pas une liste de fichiers à supprimer.
Un contrôle d’intégrité du cœur WordPress compare les fichiers concernés aux références officielles. Il ne certifie ni la base, ni les extensions, ni l’hébergement entier. Si un composant doit être remis en place, exigez une sauvegarde, la version appropriée et un contrôle des personnalisations. Une restauration ancienne ne doit pas écraser sans préparation les commandes et contenus récents.
Comprendre une redirection intermittente ou réservée aux visiteurs
Un résultat normal chez l’administrateur n’invalide pas un signalement précis. Le comportement peut dépendre de l’origine de la visite, de l’appareil, d’un cookie ou d’une condition du service intermédiaire. Donnez ces différences au prestataire au lieu de provoquer des visites répétées sur la destination.
Demandez une comparaison des réponses selon les scénarios effectivement signalés, dans un cadre technique maîtrisé. La destination visible dans un moteur et la page actuellement servie ne décrivent pas toujours le même instant. Les exemples d’URL d’un outil de sécurité ne constituent pas non plus un inventaire complet des pages touchées.
Après une correction démontrée, un cache peut encore conserver une réponse ancienne. Faites invalider seulement les entrées concernées au niveau identifié, puis contrôlez de nouveau. Avant cette correction, une purge générale peut masquer temporairement le phénomène ou faire disparaître des indices. Si le défaut revient à chaque remplissage du cache, cherchez ce qui recrée la mauvaise réponse.
Adapter la recherche à WordPress.com et au multisite
Sur WordPress.com, vérifiez avec le propriétaire si une fonction Site Redirect a été configurée pour l’ancienne adresse .wordpress.com. Dans le tableau d’hébergement du site concerné, Réglages puis Site redirect permet de lire sa destination. Une redirection de domaine personnalisé relève d’un autre réglage ; n’achetez pas de service pour diagnostiquer un départ inattendu.
Relevez la valeur et l’autorisation avant toute correction. Si la destination n’est pas reconnue ou si le réglage est inaccessible, demandez l’intervention du support. N’annulez pas un abonnement ou un domaine simplement pour interrompre un trajet dont la cause reste inconnue.
En multisite, confirmez le sous-site visé, son domaine et la portée des composants réseau. Le responsable du réseau doit participer si la règle ou le code agit sur plusieurs sites. Une correction locale peut être insuffisante ; une désactivation réseau peut, à l’inverse, affecter des sites intacts. Faites documenter cette portée et le retour arrière avant l’opération.
Vérifier plusieurs parcours après la correction
Le contrôle commence après la correction identifiée et, en cas d’incident, après les mesures de sécurité décidées. Vérifiez l’accueil, une ancienne adresse touchée et une page intérieure qui devait rester intacte. Comparez les scénarios des signalements, notamment visite directe et arrivée depuis un moteur, sans poursuivre une destination encore douteuse.
Vérifiez le statut et la cible des redirections attendues, pas seulement l’aspect final de la page. Sur une boutique, ne relancez pas un paiement ou une commande pour reproduire le problème. Réservez les parcours qui écrivent ou envoient des messages à une copie isolée, avec effets externes neutralisés.
Si Search Console contient un problème de sécurité, sa réévaluation est distincte de la correction locale. Consultez le rapport avec le propriétaire et demandez un examen seulement lorsque les problèmes indiqués ont été traités. Un avertissement qui persiste ne justifie pas de contourner le navigateur. À l’inverse, sa disparition ne constitue pas une garantie d’absence de tout autre accès.
Conserver un dossier de résolution et prévenir le retour
Le dossier final indique le scénario initial, la couche responsable, la règle ou le composant corrigé, les horaires et les contrôles effectués. Gardez les anciens réglages et les copies préservées dans un emplacement privé pendant la durée définie par le responsable. Les preuves ne doivent pas être placées dans la médiathèque publique pour faciliter leur partage.
Si la cause reste inconnue, formulez clairement la limite : le symptôme a peut-être cessé sans que son origine soit expliquée. Demandez au prestataire la prochaine vérification, les journaux encore disponibles et les critères de surveillance. Une réapparition justifie de reprendre l’enquête sur les accès et les autres couches, pas d’empiler de nouvelles redirections.
Pour la suite, tenez un registre des changements de domaine, de CDN et des règles importantes. Associez chaque intégration à un responsable et réexaminez ses accès à la fin d’une mission. Une redirection utile doit avoir une destination reconnue, une portée comprise et une façon documentée de la retirer.
