Pour faire une redirection 301, il faut une réponse HTTP émise par un serveur, un reverse proxy, un CDN ou un service de redirection. Le DNS intervient avant cette réponse : il indique seulement à quelle adresse le navigateur doit se connecter.

La bonne approche consiste donc à faire pointer l’ancien domaine vers une couche qui accepte la connexion HTTPS, conserve le chemin demandé, puis renvoie un code 301 vers le nouveau domaine.

Ce que fait vraiment le DNS dans une redirection 301 DNS

Le DNS traduit un nom en cible technique. Un enregistrement A pointe vers une IPv4, AAAA vers une IPv6, CNAME vers un autre nom, et certains fournisseurs ajoutent des services de forwarding au-dessus du DNS.

Cette distinction est essentielle. Quand un visiteur demande https://ancien-domaine.fr/page, son navigateur résout d’abord le nom. Ensuite seulement il ouvre une connexion TLS et envoie une requête HTTP.

Un CNAME peut être utile pour envoyer le trafic vers une plateforme. Il ne remplace pas une règle de redirection, surtout quand le domaine racine, HTTPS ou les chemins applicatifs sont en jeu.

Les risques à éviter avant une migration de domaine

Le premier risque est de croire qu’un changement DNS suffit. Les visiteurs peuvent arriver sur le mauvais virtual host, recevoir une erreur certificat ou perdre le chemin demandé.

Le deuxième risque est la redirection partielle. Une page d’accueil redirigée mais des anciennes URLs en 404 produisent une mauvaise expérience et diluent le signal de migration.

Le troisième risque concerne les boucles. Un proxy mal configuré peut rediriger vers lui-même, mélanger HTTP et HTTPS, ou ignorer l’en-tête host envoyé par le client.

Trois architectures fiables pour rediriger un domaine

Pour une PME ou une plateforme SaaS, le choix dépend surtout du niveau de contrôle attendu. Une redirection unique peut rester chez le registrar. Une migration critique mérite une configuration versionnée et testée.

Voici un exemple Nginx volontairement simple. Il conserve le chemin et la query string, puis redirige vers le nouveau domaine.

server {
    listen 80;
    server_name ancien-domaine.fr www.ancien-domaine.fr;
    return 301 https://nouveau-domaine.fr$request_uri;
}

server {
    listen 443 ssl http2;
    server_name ancien-domaine.fr www.ancien-domaine.fr;

    ssl_certificate /etc/letsencrypt/live/ancien-domaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ancien-domaine.fr/privkey.pem;

    return 301 https://nouveau-domaine.fr$request_uri;
}

Mini-lab : valider la redirection sans risque

Ce test vérifie le comportement sans toucher à la production. Il utilise une résolution locale temporaire et des commandes faciles à supprimer.

# 1. Tester la réponse HTTP attendue
curl -I http://ancien-domaine.test/demo?src=audit

# Résultat attendu
HTTP/1.1 301 Moved Permanently
Location: https://nouveau-domaine.fr/demo?src=audit

# 2. Vérifier qu'il n'y a pas de boucle
curl -IL --max-redirs 5 http://ancien-domaine.test/demo

# 3. Contrôler les logs Nginx
sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

Le rollback est simple tant que le DNS public n’est pas modifié. Supprimez l’entrée locale, désactivez le virtual host de test, puis rechargez Nginx.

sudo nginx -t
sudo systemctl reload nginx
sudo rm /etc/nginx/sites-enabled/redirection-test.conf
sudo systemctl reload nginx

Checklist de migration avant mise en production

Erreurs courantes et dépannage

Plan de mise en production sans surprise

Une redirection de domaine paraît simple quand elle est testée sur une page. Elle devient sensible dès que des campagnes, des APIs, des webhooks ou des anciens liens clients dépendent de l’ancien nom.

La première étape consiste à inventorier les chemins réellement utilisés. Les logs du serveur existant, l’analytics et les URLs partagées dans les outils métiers donnent souvent une image plus fiable que la seule page d’accueil.

La deuxième étape consiste à abaisser le TTL DNS avant la bascule. Cela ne rend pas la migration instantanée, mais limite la durée pendant laquelle certains résolveurs gardent l’ancienne cible.

La troisième étape consiste à préparer une fenêtre de surveillance. Pendant les premières heures, suivez les codes HTTP, les erreurs TLS, les hits sur l’ancien domaine et les chemins qui ne redirigent pas correctement.

Un bon test inclut aussi les robots et les intégrations. Une application peut appeler encore l’ancien domaine avec un host précis, un webhook signé ou une méthode HTTP différente de GET.

Pour les APIs, évitez de transformer automatiquement toutes les méthodes en GET. Vérifiez le comportement attendu pour POST, PUT et DELETE, ou annoncez une coupure propre aux consommateurs concernés.

Cas métiers où la redirection doit être plus stricte

Dans un contexte e-commerce, la priorité est de conserver les fiches produits et les catégories. Une redirection globale vers la nouvelle page d’accueil crée de la frustration et complique le suivi SEO.

Dans un contexte SaaS, les pages de documentation, de connexion et de callback OAuth méritent un contrôle séparé. Certaines URLs ne doivent pas seulement rediriger : elles doivent être migrées dans la configuration applicative.

Dans un contexte infrastructure, les noms utilisés par des scripts, agents ou sondes de supervision doivent être listés avant changement. Une redirection HTTP ne corrigera pas un client qui attend une connexion TCP directe.

Pour aller plus loin sur l’exploitation Linux

FAQ sur la redirection 301 DNS