Changer de nom de domaine ne consiste pas seulement à afficher une nouvelle adresse. Il faut permettre aux clients, aux anciens liens et aux moteurs de retrouver chaque contenu utile. Un changement de marque, une fusion ou une réorganisation peuvent justifier cette opération ; le simple espoir de gagner des positions grâce à un autre nom ne suffit pas.
Une migration préparée réduit les erreurs évitables. Elle ne garantit pas un trafic constant : Google doit découvrir et traiter les nouvelles adresses. L'objectif est de conserver des chemins fonctionnels, des contenus cohérents et des données permettant d'expliquer ce qui se passe.
Ce qui change réellement lors d'une migration
Distinguez trois opérations. Le changement de domaine remplace l'adresse publique du site. Le transfert de registrar change le bureau qui gère l'enregistrement, sans nécessairement changer cette adresse. Le changement d'hébergement déplace les fichiers et la base de données. Ces opérations peuvent être liées, mais elles n'ont pas les mêmes risques ni les mêmes procédures.
Lors d'un changement de domaine, les pages, images et documents peuvent recevoir de nouvelles URL. Des liens entrants, favoris, campagnes et signatures continuent de pointer vers l'ancien site. Votre préparation doit partir de ces usages réels : pages qui génèrent des demandes, documents transmis aux clients, produits encore commandés ou articles consultés depuis longtemps.
Les scores d'« autorité de domaine » d'outils SEO ne sont pas des comptes de points administrés par Google. Évitez donc les promesses de transfert de 95 % d'autorité ou de récupération automatique en huit semaines. Google indique qu'une migration peut provoquer des fluctuations temporaires ; son traitement dépend notamment de la taille du site et de l'exploration. Documentation Google sur les migrations avec changement d'URL.
Construire le plan de correspondance avant de toucher au site
Établissez un tableau qui rapproche chaque ancienne URL de sa destination prévue. Croisez le crawl du site, les sitemaps, les pages connues dans Search Console, les entrées de votre outil de mesure et les liens entrants disponibles. Aucun de ces inventaires ne suffit seul : une page orpheline peut recevoir du trafic alors qu'elle n'apparaît plus dans les menus.
| Situation | Décision à documenter | Contrôle |
|---|---|---|
| Même contenu, même chemin | Redirection vers ce chemin sur le nouveau domaine | Destination pertinente et accessible |
| Page renommée | Correspondance explicite vers sa nouvelle URL | Aucune étape intermédiaire inutile |
| Plusieurs pages regroupées | Redirection vers la page qui reprend réellement leurs informations | Les anciens besoins restent couverts |
| Contenu supprimé sans équivalent | Réponse 404 ou 410 adaptée | Pas de renvoi trompeur vers l'accueil |
| PDF ou image encore utilisé | Conservation de l'accès ou redirection du fichier | Fichier complet, bon type de contenu |
Attribuez un responsable à chaque ligne importante. Notez pourquoi une destination a été choisie, puis gardez une version datée du tableau. Ce document sert à configurer la migration, à la tester et à corriger rapidement un oubli après le lancement.
Choisir une redirection permanente et la tester réellement
Une redirection HTTP 301 ou 308 exprime un déplacement permanent. Google distingue ces signaux forts des redirections temporaires 302 ou 307. Cela ne permet pas d'affirmer qu'une 302 ferait systématiquement perdre toute l'historique SEO : le problème est surtout d'envoyer un signal cohérent avec le changement définitif. Une balise canonical n'est pas un remplacement pratique de la redirection pour un visiteur qui utilise une ancienne adresse. Google : redirections et recherche.
La règle doit s'exécuter là où arrive la requête pour l'ancien domaine : serveur, proxy, service de redirection ou application encore accessible. Un plugin installé uniquement sur le nouveau site ne peut pas intercepter une requête qui n'atteint jamais cet hébergement. Vérifiez également le certificat HTTPS de l'ancien domaine ; une connexion TLS en échec peut empêcher le visiteur d'atteindre la redirection.
Exemple Apache lorsque les chemins restent identiques
Sur un hébergement Apache autorisant ces règles dans un fichier .htaccess, le principe peut s'écrire ainsi. Les domaines ci-dessous sont des exemples à remplacer, pas une configuration prête pour tous les sites :
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?ancien-domaine\.example$ [NC]
RewriteRule ^ https://nouveau-domaine.example%{REQUEST_URI} [R=301,L,NE]Cette règle conserve le chemin demandé ; les paramètres doivent aussi faire partie des tests. Des adresses historiques avec des caractères encodés, des applications différentes ou un proxy peuvent demander une configuration adaptée. Pour des chemins modifiés, placez les correspondances précises avant la règle générale et évitez de mélanger plusieurs mécanismes sans vérifier leur ordre. La documentation Apache sur la redirection et le remappage explique les contextes d'utilisation de mod_rewrite.
Un service fourni par le registrar peut convenir s'il renvoie bien un code permanent, conserve les chemins nécessaires et prend en charge HTTPS. Une « redirection masquée » qui affiche le nouveau site dans un cadre n'a pas le même fonctionnement. Contrôlez la réponse HTTP et l'adresse finale, pas seulement l'aspect de la page.
Maîtriser le domaine, les accès et les DNS
Le domaine doit être rattaché à un compte que l'entreprise contrôle, avec des coordonnées de récupération utilisables et des responsabilités documentées. Vérifiez qui reçoit les alertes de renouvellement, qui peut modifier les DNS et qui conserve les codes nécessaires. Activez la protection du compte et prévoyez un accès de secours organisé.
Un transfert vers un autre bureau d'enregistrement peut simplifier cette gestion. Pour voir les étapes proposées par un registrar, consultez cette page. Comparez aussi les conditions de renouvellement, les fonctions DNS et le support : transférer un domaine ne transfère pas automatiquement les boîtes mail, le site ou tous les services associés.
Le code d'autorisation, les verrous et les délais dépendent de l'extension et de la situation. Pour les domaines concernés, la politique de transfert de l'ICANN prévoit notamment des restrictions liées à certains événements récents. La formule « toute modification impose 60 jours d'attente » est trop générale. Faites confirmer les conditions applicables à votre domaine avant de modifier son titulaire ou de programmer un transfert.
Exportez la zone DNS et repérez ses usages : site, messagerie, sous-domaines, vérification de services. Une adresse de site peut fonctionner tandis que les courriels cessent d'arriver. Traitez donc les tests de réception et d'envoi comme un chantier distinct. Ne supprimez pas l'ancien hébergement avant d'avoir déterminé quels services il rend encore.
Préparer la bascule : contenu, technique et retour arrière
Fixez une période compatible avec l'activité et la disponibilité des intervenants. Une plage calme est utile seulement si quelqu'un peut surveiller le lancement et corriger un incident. Un calendrier de préparation dépend du volume, des dépendances et de la complexité ; un horaire universel de migration n'a pas de sens.
- Sauvegardes : conservez fichiers, base, configuration et DNS ; vérifiez qu'un retour arrière est réalisable, avec les changements récents pris en compte.
- Copie de travail : protégez son accès et empêchez les actions externes involontaires : courriels, paiements ou tâches planifiées en double.
- Parcours : testez formulaires, réservation, achat, téléchargements et affichage mobile avec des données de test identifiables.
- Adresses internes : préparez menus, liens du corps, canonicals, versions linguistiques et sitemaps sur le domaine définitif.
- Mesure : vérifiez les événements utiles, le consentement et les destinations de conversion, sans multiplier les balises.
- Inventaire des dépendances : repérez licences, callbacks, API et outils qui autorisent uniquement un domaine précis.
Évitez d'empiler le même jour changement de domaine, arborescence entièrement nouvelle, remplacement du CMS et réécriture générale. Si plusieurs chantiers sont indispensables, séparez leurs étapes et leurs preuves de validation. Vous pourrez mieux identifier l'origine d'un problème.
Le jour du changement : vérifier avant d'annoncer
Déployez les destinations finales, contrôlez leur accès public, puis activez le plan de redirection. Testez un échantillon représentatif et toutes les URL commerciales prioritaires : anciennes variantes avec et sans www, HTTP et HTTPS, pages profondes, URL renommées et fichiers. Relevez le code initial, chaque étape et la destination finale.
Vérifiez que les protections temporaires ont été retirées uniquement du site destiné au public. Une page qui répond 200 peut encore porter un noindex ou une canonical vers la copie de travail. À l'inverse, ne bloquez pas l'exploration des anciennes URL si Google doit y découvrir les redirections.
Pour un changement de domaine éligible, utilisez ensuite l'outil Changement d'adresse de Search Console, avec la propriété des sites concernés vérifiée. L'outil contrôle certains prérequis et ne remplace pas les redirections. Il ne sert pas à un simple passage HTTP vers HTTPS ou au déplacement d'un répertoire. Soumettez aussi le sitemap du nouveau site et actualisez campagnes, profils et documents de communication.
Suivre la migration sans confondre incident et fluctuation
Gardez une référence antérieure au changement : clics et impressions par groupe de pages, demandes reçues, ventes si pertinentes et erreurs techniques. Comparez ensuite les deux domaines ensemble. La baisse du seul ancien domaine est attendue ; elle ne décrit pas la performance globale. Tenez compte de la saisonnalité, des jours d'ouverture et des changements de campagnes.
Au début, examinez fréquemment les erreurs serveur, les redirections et les parcours commerciaux. Suivez ensuite les nouvelles URL découvertes, les pages retenues dans l'index et les requêtes importantes. Une perte concentrée sur un répertoire appelle une investigation de ce répertoire ; elle ne se traite pas en publiant au hasard davantage d'articles.
Conservez les redirections durablement : la documentation de migration de Google recommande généralement au moins un an, et leur maintien plus long peut rester utile aux visiteurs et aux liens anciens. Le renouvellement de l'ancien domaine doit être planifié en conséquence. Continuez à demander la mise à jour des liens importants pour éviter une dépendance permanente aux redirections.
La validation finale porte sur des faits : anciennes entrées utiles toujours exploitables, nouvelles pages accessibles, demandes qui arrivent, mesure cohérente et suivi confié à quelqu'un. Aucun pourcentage de récupération ni délai de retour des positions ne peut être promis à partir du seul plan technique.
Questions fréquentes
Faut-il changer de registrar pour changer de nom de domaine ?
Non. Le changement d’adresse publique et le transfert de gestion vers un autre registrar sont deux opérations distinctes. Vous pouvez enregistrer le nouveau domaine chez le même prestataire ou ailleurs. Vérifiez séparément les DNS, l’hébergement et les courriels.
Combien de temps faut-il conserver l’ancien domaine ?
Prévoyez au minimum la durée nécessaire aux redirections : Google recommande généralement au moins un an pour une migration. Un maintien plus long peut être utile aux liens anciens et aux clients. Organisez le renouvellement et vérifiez que les redirections restent actives, y compris en HTTPS.
Peut-on rediriger toutes les anciennes pages vers la nouvelle page d’accueil ?
Seulement si cette destination répond réellement au besoin de chaque ancienne page, ce qui est rarement le cas. Associez chaque contenu à un équivalent pertinent. Un document supprimé sans équivalent peut conserver une réponse 404 ou 410 plutôt qu’une redirection trompeuse.
Une migration bien préparée garantit-elle de garder toutes ses positions ?
Non. La préparation réduit les erreurs, mais le moteur doit traiter les nouvelles URL et la concurrence peut évoluer. Contrôlez l’accès aux pages et les conversions, puis analysez les deux domaines ensemble au lieu de promettre une récupération chiffrée.
Le changement de domaine modifie-t-il aussi les adresses e-mail ?
Pas automatiquement. Le site et la messagerie dépendent de configurations distinctes. Si les adresses e-mail changent également, prévoyez les boîtes, les redirections, l’authentification et les tests de réception et d’envoi avant d’abandonner les anciens services.