Établir ce qui est réellement ancien
Vous venez de connecter un nouveau domaine à un site WordPress migré. Le navigateur ouvre bien le domaine attendu, mais la page affiche encore l’ancienne version. Le même symptôme peut venir d’une adresse DNS ancienne, d’un mauvais rattachement sur le nouveau serveur, d’une redirection ou d’une copie de page en cache. Avant de changer un réglage, notez l’adresse saisie, l’adresse qui reste dans la barre du navigateur et ce qui vous permet de distinguer les deux versions. Par exemple, l’ancien accueil dit « Bureau du quai », tandis que la copie validée dit « Bureau de la gare ».
Choisissez deux pages qui devraient être différentes entre les serveurs, dont l’accueil et une page intérieure. Regardez-les sans connexion, puis relevez la date, le réseau utilisé et le nom exact, avec ou sans www. Un favori, une redirection enregistrée ou une page vue dans l’administration peut faire croire que le navigateur a demandé une adresse différente. Notez séparément la destination réseau observée et le contenu renvoyé. Deux sites peuvent partager une même adresse IP et le serveur choisit alors le site à présenter en fonction du nom demandé.
Préparez le retour avant de faire une correction. Dans les interfaces auxquelles vous avez accès, conservez les enregistrements du nom, le rattachement au site et les règles de redirection concernées. Relevez les modifications récentes à préserver sur l’instance qui reçoit encore des visites. Gardez les deux serveurs disponibles pendant le diagnostic si vous en avez la maîtrise. Si les visiteurs peuvent commander ou publier sur les deux versions, déterminez où ces écritures arrivent avant de déplacer davantage de trafic.
Interroger les noms qui servent réellement le site
Comparez les réponses DNS du domaine nu et du nom avec www si vous publiez les deux. Pour chacun, relevez les enregistrements A et AAAA qui existent, ainsi que la cible CNAME s’il y en a une. Une correction de l’adresse IPv4 laisse un problème si des visiteurs atteignent toujours l’ancien serveur par IPv6. Si le fournisseur utilise un alias à la racine, le panneau peut afficher une cible logique et les résolveurs une ou plusieurs adresses calculées. Cherchez la configuration effective plutôt que de comparer uniquement les intitulés du panneau.
Sous Windows, les commandes ci-dessous interrogent le résolveur du poste. Remplacez les noms fictifs par ceux du site. Sur un autre système, les requêtes A, AAAA et CNAME sont disponibles avec dig si cet outil est installé. Une absence d’enregistrement AAAA peut être normale si le service ne publie pas d’IPv6. En cas d’écart, contrôlez aussi les serveurs de noms qui font autorité pour la zone et les valeurs dans le panneau de la zone réellement déléguée. Un panneau chez le bureau d’enregistrement peut encore contenir une ancienne zone qui ne répond plus aux requêtes. Pour vérifier directement une réponse, ajoutez par exemple -Server 192.0.2.53 à la première commande et remplacez cette IP fictive par celle d’un serveur de noms autoritaire pour la zone.
Resolve-DnsName -Name nouveau.example.test -Type A -DnsOnly
Resolve-DnsName -Name nouveau.example.test -Type AAAA -DnsOnly
Resolve-DnsName -Name www.nouveau.example.test -Type CNAME -DnsOnlyLire les écarts entre la zone et ce que voient les visiteurs
Si les serveurs de noms autoritaires publient encore l’ancienne destination et que le nouveau serveur est prêt, vous avez un enregistrement ou un alias à corriger. Si la zone publiée est déjà exacte mais que votre résolveur conserve une ancienne réponse, comparez avec un autre réseau et notez la durée de vie restante de la réponse, lorsqu’elle est disponible. Réduire le TTL maintenant ne raccourcit pas la durée d’une réponse déjà en cache. Évitez de modifier plusieurs fois la zone pendant cette comparaison. Cela rendrait difficile l’attribution du résultat à une seule modification.
Si le domaine passe par un réseau de diffusion ou un proxy, une adresse DNS qui diffère de l’IP du serveur est souvent attendue. Vérifiez dans l’interface du proxy à quelle origine le nom est rattaché et comment les noms avec ou sans www sont traités. Le test direct ci-dessous sert à comparer une origine que vous êtes autorisé à tester. Certaines origines n’acceptent que les requêtes du proxy ou utilisent un certificat prévu pour cette liaison. Un échec direct peut donc être cohérent avec le déploiement. Conservez la configuration publique normale et utilisez la prévisualisation de l’hébergeur ou les journaux autorisés si l’origine ne reçoit pas les connexions directes.
Pour comparer plusieurs relevés, donnez à chaque ligne un nom, une source et une heure. Par exemple, notez « www, résolveur du bureau, ancienne adresse » puis « www, serveur autoritaire, nouvelle adresse ». Vérifiez ensuite si les deux accès HTTPS servent vraiment la même page. Le DNS explique où une connexion peut aller. L’en-tête de redirection et le contenu montrent ce que le serveur ou le proxy en fait.
Comparer les deux serveurs sans publier un changement DNS
Si vous connaissez l’adresse de chaque serveur et que vous pouvez les interroger directement, utilisez le même nom dans les deux requêtes. L’option --resolve de curl associe ce nom et ce port à l’IP choisie pour la commande. L’adresse HTTPS de la requête reste le nouveau domaine. Le nom demandé dans la négociation TLS et l’en-tête HTTP restent donc ceux du site, ce qui permet de tester l’hôte virtuel attendu. Ouvrir l’IP dans un navigateur ou changer seulement l’en-tête HTTP d’une requête HTTPS peut conduire au mauvais certificat ou au mauvais site.
Remplacez les deux IP de documentation par les destinations approuvées, et le nom par celui que vous gérez. Les sorties mettent de côté le contenu et affichent les en-têtes ainsi que l’IP réellement contactée. Si un proxy local est normalement imposé, demandez à l’équipe réseau une méthode autorisée pour comparer les origines. Les commandes désactivent l’usage d’un proxy pour ce seul nom et conviennent à un accès direct autorisé. Sous Windows, appelez curl.exe si votre shell interprète curl comme une autre commande. Gardez la vérification TLS active. Si elle échoue, notez l’erreur de nom ou de chaîne de certificats avant de modifier le DNS. Le serveur cible doit être préparé pour le nom selon le mode d’hébergement choisi.
curl --noproxy nouveau.example.test --resolve nouveau.example.test:443:192.0.2.10 -sS -D - -o ancien.html -w "IP %{remote_ip} HTTP %{http_code}\n" https://nouveau.example.test/
curl --noproxy nouveau.example.test --resolve nouveau.example.test:443:192.0.2.20 -sS -D - -o nouveau.html -w "IP %{remote_ip} HTTP %{http_code}\n" https://nouveau.example.test/Comparer les en-têtes avant de suivre une redirection
Les commandes ne suivent pas la réponse automatiquement. Un 301 ou un 302 accompagné d’un en-tête Location vers l’ancien nom prouve qu’une redirection est émise pour cette requête. Il faut encore identifier sa source. Comparez la racine et une page intérieure. Regardez la règle du domaine dans le panneau d’hébergement, puis celle du proxy ou du réseau de diffusion s’il y en a un. Sur le serveur cible, consultez les réglages du site WordPress et les règles propres à ce nom. L’ancien domaine peut rester configuré comme adresse principale alors que la connexion réseau atteint bien le nouveau serveur.
Dans l’essai local, deux serveurs HTTPS ont accepté le même domaine fictif et servi chacun un marqueur différent. Le choix de l’IP avec --resolve a déterminé le marqueur lu. Le nouveau serveur a aussi renvoyé un 302 vers l’ancien domaine sur un chemin préparé à cet effet. Refaire la requête vers la première IP a reproduit la réponse initiale. Le test s’est déroulé sur des adresses de boucle locale, avec un certificat de test, sans modifier une zone DNS. Il permet de vérifier la méthode de comparaison. Il ne mesure pas ce que les résolveurs des visiteurs ont en cache.
Si le nouveau serveur répond 200 mais présente la page par défaut ou le site d’un autre nom, vérifiez le rattachement du domaine à l’installation et au répertoire réellement utilisés. Si la réponse est celle de la bonne installation mais que son texte reste ancien, comparez sur une page témoin le contenu servi directement et celui servi par l’accès normal. Ne modifiez le cache qu’après avoir identifié lequel garde le contenu. Une purge ne corrige pas un enregistrement DNS ou une redirection erronée.
Corriger une destination en auto-hébergement
Dans le panneau du nouvel hébergement, affectez d’abord le domaine et le nom avec www, s’il est utilisé, au site migré. Vérifiez le répertoire ou l’installation sélectionnée et le certificat attendu. Refaites le test direct autorisé pour ces noms et deux chemins. Si la destination est prête et que l’autorité DNS publie encore l’ancienne valeur, modifiez uniquement les enregistrements de site nécessaires dans la zone active. Par exemple, changez l’adresse A du nom concerné et traitez l’AAAA s’il pointe vers une adresse obsolète. N’ajoutez une adresse IPv6 que si le nouvel hébergeur vous l’a fournie pour ce service.
Conservez les enregistrements de courrier et de validation. Une migration de site ne demande généralement pas de changer les MX, les TXT de messagerie ni les serveurs de noms si la zone actuelle est utilisable. Si l’hébergeur exige une délégation de toute la zone, inventoriez les autres services avant de l’appliquer. Suivez la méthode qu’il documente pour le certificat et le proxy. En particulier, vérifiez que les pages du site principal ne sont pas publiées par erreur depuis une copie réservée.
Après le changement, interrogez d’abord la zone active et comparez avec les valeurs prévues. Vérifiez ensuite l’accès normal depuis deux réseaux, en notant ce qui varie. Pour revenir en arrière, remettez les valeurs enregistrées dans cette zone et rétablissez le rattachement précédent seulement s’il a été modifié. Une réponse déjà distribuée peut rester en cache jusqu’à expiration. Gardez donc les deux destinations en état de répondre et coordonnez la reprise des écritures avec la personne qui gère les données.
Corriger le rattachement sur WordPress.com
Si la destination est WordPress.com, ouvrez le tableau de bord d’hébergement et sélectionnez d’abord le site qui contient la version attendue. Dans Domaines, repérez le nom exact. Un nom ajouté au mauvais site doit être rattaché au bon site selon le parcours de transfert entre sites. Définir un domaine comme adresse principale sur l’ancien site ne déplace pas son contenu vers la nouvelle installation. Avant toute modification, ouvrez l’adresse actuelle de chacun des sites et confirmez lequel contient les pages de référence.
Pour un domaine enregistré ailleurs, utilisez la procédure de connexion et les valeurs affichées pour ce domaine. Vérifiez la méthode choisie avant de changer des serveurs de noms ou des enregistrements. Si le panneau demande encore une validation ou signale un certificat en cours de préparation, notez ce statut et vérifiez d’abord les conditions de connexion. Lorsqu’il est prêt, utilisez le menu du domaine pour le définir comme adresse principale du site voulu, si c’est l’adresse que les visiteurs doivent voir. Contrôlez ensuite l’adresse finale après redirection, l’accueil et une page intérieure sans être connecté.
En cas d’échec, remettez l’adresse principale précédente si ce changement est la cause confirmée et si elle est toujours opérationnelle. Si vous avez aussi modifié la zone au bureau d’enregistrement, rétablissez séparément les valeurs utiles d’après le relevé. La plateforme gère les associations et certificats de ses sites. Évitez de transposer les commandes de configuration d’hôte virtuel d’un serveur auto-hébergé à ce tableau de bord.
Traiter le cas où le bon serveur renvoie vers l’ancien domaine
Sur une installation auto-hébergée, si l’IP et le rattachement sont corrects mais que le premier saut renvoie vers l’ancien nom, cherchez le propriétaire de ce saut. Si le proxy est déjà configuré pour réécrire l’adresse, commencez par sa règle. Si la redirection provient de WordPress, vérifiez Réglages → Général, notamment l’adresse de WordPress et l’adresse du site. Elles peuvent être différentes lorsqu’une installation se trouve dans un sous-répertoire. Si les champs sont verrouillés, demandez à la personne qui maintient la configuration de vérifier WP_HOME et WP_SITEURL dans wp-config.php ou dans la configuration fournie par l’environnement. Conservez les deux valeurs avant de les modifier.
Testez d’abord la correction sur la copie. Ouvrez le nouveau domaine, un chemin intérieur et l’accès d’administration prévu. Vérifiez le premier saut et la destination finale, puis essayez l’ancien domaine si vous le conservez en redirection. Vous recherchez une destination exacte, une connexion HTTPS valable et un parcours qui ne revient jamais vers un saut déjà observé. Si une règle provoque une boucle, retirez uniquement le changement testé, puis relevez le premier en-tête Location de chaque chemin pour déterminer qui envoie la redirection suivante.
Si seuls certains liens envoient vers l’ancien domaine après un clic, ouvrez le code source de la page pour lire leur adresse. Un lien enregistré dans le contenu demande une correction dans WordPress ou dans le composant qui l’a produit. Une révision DNS n’en modifie pas la valeur. Vérifiez ce cas séparément du test d’arrivée sur l’accueil.
Clore la bascule avec un point de retour utilisable
Une fois la destination corrigée, refaites le même relevé pour le domaine nu, le nom avec www et les chemins de contrôle. Comparez le résultat depuis deux réseaux et, si le service propose IPv6, vérifiez que cette voie mène au même site. En cas de CDN, confirmez aussi que la requête publique passe encore par le service prévu. Assurez-vous que le nom attendu reste dans la barre d’adresse et que le certificat présenté est accepté sans exception. Contrôlez la page qui distinguait les deux versions et vérifiez que l’accès d’administration appartient à la bonne installation.
Conservez un petit journal avec les anciennes valeurs, les nouvelles, l’heure de la dernière modification et le contrôle qui a réussi. Si la version cible perd le certificat, publie le mauvais site ou rencontre une panne importante, appliquez le retour préparé. Si le site a déjà reçu des commandes ou de nouvelles publications sur la cible, suspendez les écritures le temps de relever ces données avant de renvoyer du trafic vers l’ancienne instance. Un retour DNS change le chemin d’accès, sans transférer la base ni les fichiers produits depuis la bascule. N’arrêtez l’ancien serveur qu’une fois les accès et la reprise des données vérifiés.
Si www et le domaine nu ouvrent deux sites différents
Comparez exactement le même chemin sur les deux noms. Dans l’exemple, nouveau.example.test/contact/?origine=menu ouvre le site attendu et www.nouveau.example.test/contact/?origine=menu affiche une autre installation. Relevez pour chaque réponse le certificat, le premier statut HTTP, la valeur de Location s’il y a une redirection, puis un texte propre au site reçu. L’égalité des réponses DNS ne règle pas le choix du site. Une même IP peut servir deux hôtes virtuels différents selon le nom demandé.
Choisissez le nom public à conserver et vérifiez que les deux noms désignent bien le même site avant de les réunir. Si le nom secondaire affiche volontairement un autre site, gardez ce rattachement. En auto-hébergement, préparez le nom principal sur l’installation voulue et le nom secondaire dans son propre rattachement ou comme alias, selon le panneau. Le certificat doit couvrir les deux noms HTTPS, y compris celui qui va rediriger. Le navigateur vérifie le certificat du nom secondaire avant de recevoir la redirection. Sur WordPress.com, vérifiez que le domaine est associé au bon site, puis utilisez son réglage d’adresse principale et les options de domaine proposées. Si le nom secondaire est rattaché à un autre site, vérifiez son usage avant de modifier cette association.
Sur une copie, configurez d’abord une redirection temporaire du seul nom secondaire vers le principal. Utilisez le champ de redirection de l’hébergeur ou du proxy responsable du premier saut. Demandez la conservation du chemin et de la requête lorsque cette option est disponible. La règle doit vérifier le nom de départ, pour que le nom principal serve directement la page. Les commandes suivantes relèvent les réponses HTTPS initiales. Remplacez les noms fictifs par ceux de la copie et gardez le chemin entre guillemets. Reprenez ensuite le test avec -L --max-redirs 4 pour suivre la redirection et vérifier la destination finale. Pour tester l’origine sans changer le DNS, utilisez aussi le mécanisme --resolve présenté plus haut, avec une entrée pour chacun des noms.
curl -sS -D - -o sans-www.html "https://nouveau.example.test/contact/?origine=menu"
curl -sS -D - -o avec-www.html "https://www.nouveau.example.test/contact/?origine=menu"Valider les deux noms et préparer l’annulation
Le résultat attendu est une page correcte sur le nom principal et un saut du nom secondaire vers le même chemin sur le nom principal. Dans l’essai local, curl a été configuré pour joindre la même IP de test avec les deux noms, qui servaient au départ deux contenus différents. Après correction de la règle, le nom avec www a renvoyé un 302 vers le domaine nu en conservant /contact/?origine=menu. Suivre ce saut a donné HTTP 200 et le contenu attendu. Retirer la règle a reproduit le comportement initial.
Sur votre copie, testez aussi la racine et un second chemin. Si vous acceptez les entrées HTTP, vérifiez qu’elles aboutissent au nom HTTPS choisi sans boucle. Si le chemin devient systématiquement l’accueil, revenez à la configuration sauvegardée et corrigez la règle avant de la rendre permanente. Une fois le comportement validé et le choix du domaine durable, utilisez la redirection permanente proposée par votre infrastructure. Si la bascule échoue, remettez la règle ou le rattachement initial et recontrôlez les deux noms. Une redirection permanente déjà mise en cache peut continuer à s’appliquer chez certains clients.
