Que vérifier après un changement d’hébergeur : messagerie, SSL, redirections et formulaires

Vérifiez que le domaine et www pointent vers la nouvelle IP depuis des résolveurs publics du monde entier avec le vérificateur de propagation DNS, et que le site y répond réellement avec Mon domaine est-il basculé ?. Un ancien enregistrement AAAA (IPv6) est le reste classique : les visiteurs en IPv6 continuent d’arriver chez l’ancien hébergeur et voient du contenu périmé.

Si vous avez transféré le DNS chez un autre fournisseur, comparez l’ancienne et la nouvelle zone avec le Comparateur DNS. Un enregistrement TXT ou CNAME manquant casse des choses sans bruit : la vérification du domaine pour Google ou Microsoft, la signature des e-mails ou un sous-domaine utilisé par un service tiers.

Beaucoup d’hébergeurs n’émettent le certificat qu’une fois le domaine pointé vers eux : vérifiez-le donc après le basculement du DNS. Le vérificateur SSL affiche l’émetteur, la date d’expiration, les noms couverts par le certificat et si les navigateurs font confiance à la chaîne. Assurez-vous qu’il couvre example.com et www.example.com, ainsi que tous les autres noms d’hôte que vous servez.

Si vous avez testé avec un lien d’aperçu DNSPeek en mode Ignorer la vérification, passez-le en mode Vérifier après la migration : l’aperçu échoue alors à la moindre erreur de certificat, ce qui constitue une confirmation rapide. Voir modes SSL.

La configuration du serveur ne suit pas toujours les fichiers. Les règles .htaccess ne fonctionnent pas sur nginx, et un nouvel hébergeur peut gérer www différemment. Lancez le vérificateur de redirections sur votre domaine : http:// doit atteindre la page https:// finale en une ou deux étapes, avec des redirections permanentes (301 ou 308) et sans boucle.

Lancez ensuite la vérification des en-têtes de sécurité. HSTS, Content-Security-Policy et les en-têtes similaires sont définis par le serveur ou le CDN et se perdent facilement lors d’une migration. Comparez la note avec celle d’avant.

C’est sur la messagerie que les migrations échouent le plus discrètement : le site a l’air parfait, et personne ne remarque pendant des jours que les e-mails sont rejetés ou finissent en spam.

Faites ensuite un vrai test : écrivez à une boîte du domaine depuis une adresse externe, puis répondez. Si la messagerie était hébergée sur l’ancien serveur, vérifiez que les messages reçus pendant la bascule ont été recopiés.

Les formulaires de contact, réinitialisations de mot de passe et confirmations de commande envoient souvent les e-mails depuis le serveur web lui-même. Sur un nouveau serveur, la fonction PHP mail() peut être désactivée, le port 25 bloqué (fréquent sur les VPS cloud) ou la nouvelle IP absente du SPF. Envoyez chaque formulaire et déclenchez une réinitialisation de mot de passe. Si les messages n’arrivent pas, passez par un service SMTP authentifié plutôt que par la messagerie locale du serveur.

• Tâches cron et tâches planifiées : sauvegardes, flux, préchauffage du cache et files d’envoi de newsletters. Recréez-les sur le nouveau serveur et vérifiez que l’ancien ne les exécute plus, sinon elles tourneront deux fois.
• Listes d’IP autorisées : passerelles de paiement, API, pare-feu et bases de données distantes qui n’acceptent que l’IP de l’ancien serveur.
• Webhooks : les services qui appellent votre site, comme les prestataires de paiement, continuent de fonctionner via le DNS, mais vérifiez leurs journaux de livraison à la recherche d’erreurs autour de la bascule.
• Permissions des fichiers et envois : envoyez une image ou un fichier via le CMS.
• Cache : videz les caches de pages et du CDN pour que les visiteurs ne reçoivent pas de pages générées sur l’ancien serveur.

Un réglage de préproduction resté en place peut masquer tout le site aux moteurs de recherche. Cherchez une balise meta robots noindex ou un en-tête X-Robots-Tag, un robots.txt qui interdit tout, et des URL canoniques qui pointent vers un hôte temporaire. Vérifiez que la balise de statistiques se déclenche toujours et que le sitemap est accessible. Un rapport QA DNSPeek signale ces restes liés aux moteurs de recherche, ainsi que les pages cassées, les fichiers manquants et le contenu mixte.

Si vous avez testé le nouveau serveur avec un lien d’aperçu DNSPeek avant la bascule, activez les alertes de propagation DNS pour ce lien (forfaits payants). Une fois le domaine propagé, DNSPeek relance le rapport QA sur le domaine en production et le compare au dernier rapport d’avant la bascule : pages cassées, redirigées ailleurs ou ayant perdu leur titre. Voir Après la bascule DNS.

1. 1

   Étape 1 : Confirmer que le DNS a basculé

   Vérifiez le domaine et www depuis des résolveurs publics et confirmez que le site répond depuis la nouvelle IP.

2. 2

   Étape 2 : Vérifier le certificat

   Contrôlez l’émetteur, l’expiration et les noms d’hôte couverts avec le vérificateur SSL.

3. 3

   Étape 3 : Tester les redirections et les en-têtes

   Suivez http:// jusqu’à la page finale avec le vérificateur de redirections et comparez les en-têtes de sécurité avec l’ancienne configuration.

4. 4

   Étape 4 : Vérifier les enregistrements de messagerie et envoyer un test

   Consultez MX, SPF et DMARC, confirmez DKIM chez votre prestataire de messagerie, puis envoyez et recevez un message de test.

5. 5

   Étape 5 : Envoyer chaque formulaire

   Envoyez chaque formulaire de contact et une réinitialisation de mot de passe, et confirmez que les e-mails arrivent sans être marqués comme spam.

6. 6

   Étape 6 : Vérifier les tâches planifiées et les intégrations

   Recréez les tâches cron, mettez à jour les listes d’IP autorisées, vérifiez les journaux des webhooks et videz les caches.

7. 7

   Étape 7 : Vérifier les réglages SEO et garder brièvement l’ancien hébergeur

   Supprimez les règles noindex de préproduction, vérifiez robots.txt et le sitemap, et gardez l’ancien hébergement jusqu’à ce que ses journaux ne montrent plus de visiteurs.