Comment migrer un domaine sans faire chuter vos classements de recherche

Changer de domaine fait partie des rares projets SEO où une petite erreur technique peut devenir très visible très rapidement. Une redirection manquante, un chemin d’exploration bloqué ou une balise canonical oubliée peuvent transformer un rebranding simple en plusieurs semaines de volatilité des classements.

Un certain mouvement est normal. Les moteurs de recherche ont besoin de temps pour explorer les anciennes URL, découvrir les redirections, traiter les signaux et installer le nouveau domaine dans l’index. L’objectif n’est pas d’éviter chaque baisse. L’objectif est de rendre la migration sans histoire : une ancienne URL pointe vers une nouvelle URL équivalente, le serveur répond clairement, et rien d’important ne disparaît.

Commencez par un inventaire, pas par une règle de redirection

L’échec le plus courant d’une migration consiste à la traiter comme une tâche de configuration serveur. Ce n’en est pas une. C’est une tâche d’architecture de l’information qui se termine par hasard dans la configuration serveur.

Avant de toucher au DNS, dressez la liste des URL qui comptent :

• Les URL qui reçoivent du trafic organique
• Les URL qui ont des backlinks externes
• Les URL qui convertissent, génèrent des leads ou soutiennent des campagnes
• Les URL canoniques actuellement présentes dans votre sitemap XML
• Les PDF, images et fichiers téléchargeables liés depuis l’extérieur
• Les URL historiques à forte valeur qui peuvent ne plus apparaître dans la navigation actuelle

Pour chaque ancienne URL, attribuez une destination sur le nouveau domaine. Dans la plupart des cas, cette destination doit être la même page, avec la même intention. Si /pricing devient https://newdomain.com/pricing, c’est simple. Si trois anciennes pages produit sont fusionnées en un nouveau guide, documentez cette décision volontairement.

Évitez le schéma paresseux : rediriger tout vers la nouvelle page d’accueil. C’est pratique, mais cela fait perdre la pertinence. Les moteurs de recherche comme les utilisateurs s’attendent à ce que la destination réponde au même besoin que l’URL d’origine.

Préservez la structure des URL lorsque vous le pouvez

Une migration de domaine est plus simple lorsque les chemins restent stables. Passer de oldsite.com/blog/example à newsite.com/blog/example est beaucoup plus propre que de changer en même temps de domaine, de CMS, de slugs, de structure de dossiers et de contenu.

Parfois, une refonte ou une migration de CMS rend les changements d’URL inévitables. Dans ce cas, séparez les décisions :

1. Qu’est-ce qui change parce que le domaine change ?
2. Qu’est-ce qui change parce que la structure du site change ?
3. Qu’est-ce qui est supprimé, fusionné ou réécrit ?

Plus vous introduisez de variables, plus il devient difficile de diagnostiquer les problèmes par la suite. Si la migration est importante et que le site actuel performe bien, envisagez de déplacer le domaine d’abord, puis de refondre le site plus tard.

Utilisez des redirections permanentes en un seul saut

Pour une vraie migration de domaine, utilisez des redirections côté serveur 301 ou 308 depuis les anciennes URL vers leurs équivalents nouveaux. Les redirections temporaires sont destinées aux situations temporaires. Les redirections JavaScript, les meta refresh et les redirections souples sont des signaux plus faibles et plus faciles à casser.

Vos objectifs de redirection sont simples :

• Chaque ancienne URL importante renvoie une redirection permanente.
• Chaque redirection mène directement à la destination finale.
• HTTP redirige proprement vers HTTPS.
• Les variantes www et sans www sont gérées de manière cohérente.
• Les redirections ne dépendent pas d’un comportement fragile des query strings, sauf si nécessaire.

Une mauvaise chaîne ressemble à ceci :

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Cela peut finir par arriver sur la bonne page, mais c’est lent, plus difficile à explorer et plus susceptible de masquer des erreurs. Visez un seul saut depuis chaque ancienne variante vers la nouvelle URL finale.

Lorsque vous validez le comportement, inspectez les réponses HTTP réelles plutôt que de faire confiance à ce que le navigateur affiche. Notre guide sur le débogage des redirections et des en-têtes HTTP en production est utile ici, car les navigateurs sont trop polis : ils suivent la chaîne et cachent les parties désordonnées.

Préparez le DNS et les certificats avant le lancement

Le DNS ne transfère pas directement les classements, mais un mauvais DNS peut donner l’impression qu’une migration est cassée. Réduisez les valeurs TTL avant la fenêtre de lancement afin que les changements se propagent de manière plus prévisible. Confirmez que le nouveau domaine dispose des bons enregistrements pour le trafic web, l’e-mail et tous les sous-domaines requis.

Vous avez aussi besoin de certificats TLS valides pour les deux domaines. C’est facile à oublier. L’ancien domaine doit encore servir des redirections HTTPS après la migration. Si son certificat expire, les utilisateurs et les robots d’exploration peuvent rencontrer des avertissements du navigateur avant même d’atteindre le nouveau site.

Si le changement affecte l’e-mail, ne le traitez pas comme un détail de dernière minute. Les changements de domaine cassent souvent SPF, DKIM, DMARC, les enregistrements MX, les liens de suivi et les e-mails transactionnels. Pour un rappel sur les enregistrements qui comptent, consultez notre guide orienté développeurs sur MX, SPF, DKIM et DMARC.

Vérifiez les balises canonical, les liens internes et les sitemaps

Après le lancement, le nouveau domaine doit se comporter comme s’il avait toujours été le domicile canonique du contenu.

Cela signifie :

• Les balises canonical pointent vers les nouvelles URL, pas vers l’ancien domaine.
• Les liens internes utilisent le nouveau domaine ou des chemins relatifs à la racine.
• Les sitemaps XML ne contiennent que des URL finales, indexables et nouvelles.
• Les annotations hreflang, si elles sont utilisées, référencent les nouvelles URL.
• Open Graph, les données structurées et les liens alternate sont mis à jour.
• Robots.txt ne bloque pas les sections importantes.

Ne publiez pas un sitemap rempli d’anciennes URL en vous attendant à ce que les redirections fassent le ménage. Un sitemap doit être une liste d’URL que vous voulez voir indexées. Après une migration, cela signifie des URL finales sur le nouveau domaine.

Surveillez aussi les contradictions canonical. Une page qui redirige de l’ancien vers le nouveau domaine, mais dont la canonical pointe vers l’ancien domaine, envoie des signaux contradictoires. Les moteurs de recherche peuvent généralement gérer un certain niveau d’incohérence, mais vous ne devriez pas le leur demander.

Ne changez pas tout le jour du lancement

Une migration est déjà un événement suffisamment important. Si possible, évitez de la combiner avec un élagage massif de contenu, des réécritures de templates, des changements de navigation, des changements de rendu JavaScript ou un nouveau profil de performance.

Ce n’est pas de la superstition. C’est de la discipline de débogage. Si les classements chutent après le lancement, vous devez savoir si la cause est la correspondance des redirections, l’accès à l’exploration, le contenu modifié, un rendu plus lent, des données structurées manquantes ou autre chose.

Gardez le lancement initial aussi proche que possible de l’ancien site. Une fois le nouveau domaine stable, apportez les changements éditoriaux et de design plus importants par lots plus petits.

Dites aux moteurs de recherche ce qui a changé

Dans Google Search Console, vérifiez à la fois l’ancien et le nouveau domaine. Utilisez ensuite l’outil Changement d’adresse lorsque le déplacement concerne le domaine dans son ensemble et que le contenu migre vers un nouveau domaine. Soumettez le nouveau sitemap après le lancement.

Cela ne remplace pas les redirections. Cela les soutient. Les moteurs de recherche ont toujours besoin de redirections persistantes et explorables pour comprendre la correspondance au niveau des URL.

Pour Bing et les autres moteurs de recherche, utilisez leurs outils pour webmasters lorsqu’ils sont disponibles. Mettez aussi à jour les emplacements que vous contrôlez : profils sociaux, fiches d’entreprise, destinations publicitaires, signatures d’e-mail, documentation, liens partenaires et références canoniques dans le contenu syndiqué.

Tous les liens externes ne seront pas mis à jour, et ce n’est pas grave. Mais les plus importants devraient l’être. Si un partenaire majeur, une place de marché d’applications, un portail de documentation ou une page presse pointe vers l’ancien domaine, demandez une mise à jour.

Surveillez les bonnes choses après le lancement

Les premiers jours après la migration doivent être consacrés au suivi actif, pas à la célébration.

Vérifiez :

• Les logs serveur pour l’activité d’exploration sur les anciens et nouveaux domaines
• Les 404 et les erreurs 5xx inattendues
• Les chaînes et boucles de redirection
• L’état d’indexation dans Search Console
• La découverte et le traitement des sitemaps
• Les pages d’atterrissage organiques et les tendances de requêtes
• Les parcours de conversion qui dépendent des anciennes URL
• Les filtres d’analytics et les exclusions de référents

Attendez-vous à du bruit dans les rapports. Certains outils d’analytics traitent le nouveau domaine comme une nouvelle propriété s’ils ne sont pas configurés correctement. Certains tableaux de bord comparent le trafic de l’ancien domaine à celui du nouveau domaine et donnent une image plus négative de la migration qu’elle ne l’est réellement.

La visibilité en recherche peut fluctuer pendant quelques semaines. Ce que vous ne voulez pas, c’est un schéma où des anciennes URL à forte valeur sont explorées à répétition sans être correctement redirigées, ou où de nouvelles pages sont découvertes mais marquées comme doublons de l’ancien domaine.

La performance ne doit pas non plus être ignorée. Si le nouveau domaine est lancé avec des templates plus lourds, une mise en cache cassée ou des assets non optimisés, les utilisateurs peuvent ressentir la migration comme un ralentissement. Si vous utilisez Lighthouse dans vos vérifications, lisez-le avec les priorités en tête ; notre article sur la manière de lire un rapport Lighthouse sans paniquer explique comment distinguer les problèmes significatifs du bruit.

Gardez l’ancien domaine longtemps

Ne laissez pas l’ancien domaine expirer après que la migration “fonctionne”. Gardez-le enregistré, gardez les certificats valides et maintenez les redirections actives aussi longtemps que possible. En pratique, cela signifie souvent des années.

Les anciens liens continuent d’exister dans les articles de blog, les favoris, la documentation, les PDF, les e-mails et les publications sociales. Les redirections sont le pont entre cette empreinte historique et le nouveau domaine. Les désactiver trop tôt casse les parcours des utilisateurs et gaspille les signaux accumulés.

Conservez aussi une copie de votre plan de redirection et de vos notes de lancement. Six mois plus tard, lorsque quelqu’un demandera pourquoi une URL historique se comporte d’une certaine manière, vous serez heureux de l’avoir documenté.

<!-- tool-cta:start -->

💡 Essayez ceci : Après la bascule, tracez vos anciennes URL avec Redirect Checker afin de confirmer que chacune aboutit en un seul saut 301 à la bonne nouvelle page.

<!-- tool-cta:end -->

Une checklist de migration raisonnable

Avant le lancement :

• Vérifiez les deux domaines dans Search Console.
• Explorez le site actuel et exportez les URL importantes.
• Construisez un plan de redirection un à un.
• Réduisez les TTL DNS.
• Préparez les certificats TLS pour l’ancien et le nouveau domaine.
• Mettez à jour les balises canonical, les liens internes, hreflang, les données structurées et les sitemaps.
• Testez les redirections en staging ou dans un environnement contrôlé.

Le jour du lancement :

• Déployez les redirections.
• Confirmez le comportement HTTP vers HTTPS.
• Testez des échantillons d’URL importantes pour chaque type de template.
• Soumettez le nouveau sitemap.
• Utilisez l’outil Changement d’adresse lorsque c’est approprié.
• Surveillez les erreurs serveur, les boucles de redirection et les ressources bloquées.

Après le lancement :

• Surveillez les erreurs d’exploration et les rapports d’indexation.
• Mettez à jour les liens externes importants lorsque vous le pouvez.
• Comparez le trafic par intention de page d’atterrissage, pas seulement par totaux de domaine.
• Gardez les redirections actives indéfiniment.
• Reportez les refontes ou expérimentations de contenu sans rapport jusqu’à ce que le déplacement soit stabilisé.

Les migrations de domaine ne sont pas sans risque, mais elles sont gérables. Les classements souffrent généralement lorsque la migration envoie des signaux flous : redirections manquantes, contenu modifié, balises canonical contradictoires, robots d’exploration bloqués ou ancien domaine oublié. Donnez aux moteurs de recherche et aux utilisateurs une carte claire, et le déplacement devient beaucoup moins dramatique.