Migrer un nom ou un domaine : redirections, continuité éditoriale et rollback

Cartographier chaque ancienne route

Chaque page utile possède une destination équivalente. Une redirection page à page conserve l’intention ; une redirection globale vers l’accueil perd le contexte et déçoit le lecteur. Les paramètres de campagne sont retirés, tandis que les identifiants publics nécessaires suivent un contrat explicite.

Les routes sans équivalent peuvent rester en archive noindex avec explication, ou renvoyer vers le dossier le plus proche seulement si celui-ci répond réellement au besoin. La décision est inscrite dans une table de migration.

Préparer la cible

La cible est construite avec les mêmes contenus validés, les nouvelles métadonnées, le canonical et le sitemap attendus. Les liens internes pointent directement vers la nouvelle origine afin d’éviter de dépendre des redirections. Les assets disposent d’URL stables ou versionnées et les mentions de l’ancien nom ne subsistent que dans la note de continuité nécessaire.

Le certificat, la racine et le sous-domaine www sont vérifiés. Une preview noindex permet la recette avant bascule lorsque l’hébergeur le permet.

Gate avant promotion

Le gate cible les pages touchées : accueil, un guide profond, fiche produit, mentions et vraie 404. Il vérifie le rendu mobile, les liens, canonicals, hreflang, données structurées et absence de fuite. La comparaison fonctionnelle porte sur le contenu utile, pas sur un hash lorsque les URL changent légitimement.

Le rollback immédiat est relevé juste avant la promotion. L’artefact validé est celui déployé ; aucune reconstruction différente n’est intercalée.

Redirections et codes HTTP

Une migration définitive utilise une redirection permanente après validation. Une preview ou maintenance temporaire n’emploie pas ce signal. Le nombre de sauts est minimisé : ancien domaine vers domaine canonique, sans chaîne via une origine technique intermédiaire.

Les requêtes HTTP et HTTPS, apex et www sont traitées explicitement. Une redirection conserve le chemin et les paramètres autorisés, mais retire les paramètres dangereux ou obsolètes. Les erreurs impossibles à mapper répondent avec une vraie 404 utile.

Observation après promotion

Le contrôle public vérifie que le domaine canonique sert la bonne version, que l’ancienne URL arrive sur la route équivalente et que le site ne crée pas de boucle. Les journaux agrégés surveillent les 404 et chaînes de redirection sans conserver de paramètres privés.

La période d’observation est définie avant migration. Elle ne justifie pas la suppression automatique de l’ancien projet : l’origine reste une capacité de retour tant que la politique de conservation l’exige.

Quand revenir en arrière

Un défaut critique — contenu absent, mauvaise identité, boucle de redirection, fuite de donnée, inscription cassée annoncée comme ouverte — déclenche le rollback. Une variation esthétique mineure peut être corrigée additivement sans bascule. Les critères sont écrits avant le déploiement pour éviter une décision improvisée.

Le rollback restaure le déploiement précédent ou la configuration DNS documentée. Il n’efface pas le candidat en échec, qui reste disponible pour diagnostic hors canonical.

Checklist de migration

La checklist s’applique route par route et distingue source, cible et preuve.

• Inventaire des noms, domaines, routes et CTA.
• Table de correspondance sans redirection générique abusive.
• Nouvelle cible publiée additivement et noindex en preview.
• Canonicals, sitemap, hreflang et JSON-LD alignés.
• Liens internes mis à jour directement.
• Apex, www, TLS et 404 vérifiés.
• Rollback et critères de retour écrits.
• Contrôle public court après promotion.
• Anciennes versions conservées.