Migrer son site vers un nouveau nom de domaine sans perdre son référencement : la checklist complète

Ce qui se transmet vraiment d'un domaine à l'autre (et ce qui se perd)

Changer de nom de domaine, ça arrive plus souvent qu'on ne le croit. Un rebranding qui aboutit enfin après deux ans de discussions internes. Un rachat. Une raison sociale qui change. Ou tout simplement l'envie d'en finir avec un nom de domaine à rallonge bourré de mots-clés, du type plombier-chauffagiste-lyon-pas-cher.fr, qui faisait sens en 2012 et qui plombe aujourd'hui l'image de l'entreprise.

Le vrai risque, dans une migration de nom de domaine, ce n'est pas de perdre des positions. Ça, c'est prévu, et on va y revenir avec des chiffres. Le vrai risque, c'est de perdre des positions définitivement, parce qu'une matrice de redirection bâclée aura envoyé quinze ans d'autorité dans le vide. Et là, on ne parle plus d'un creux de six semaines mais d'un redémarrage à zéro.

Voici donc la checklist complète, organisée en trois temps : ce qu'on prépare avant, ce qu'on exécute le jour J, ce qu'on surveille après. Avec les seuils d'alerte concrets qui doivent faire lever un sourcil.

Commençons par une mise au point que peu d'articles font clairement. Parce que la redirection 301 a bon dos, et qu'on lui prête des pouvoirs qu'elle n'a pas.

Ce que la redirection 301 transmet

La redirection permanente transmet l'essentiel des signaux de liens. PageRank, autorité accumulée, historique d'indexation, associations sémantiques entre une URL et les requêtes sur lesquelles elle se positionnait. Google a confirmé depuis plusieurs années qu'il n'y a plus de perte de PageRank annoncée sur une 301, contrairement à ce qu'on lisait partout dans les années 2010.

Attention quand même : « pas de perte » ne veut pas dire « transmission instantanée ». Google doit recrawler l'ancienne URL, constater la redirection, crawler la nouvelle, la traiter, puis progressivement basculer ses signaux. Sur un site de 200 pages, ça prend quelques jours. Sur un catalogue e-commerce de 40 000 références, comptez plusieurs semaines, avec un ordre de passage qui suit la fréquence de crawl de chaque URL. Les pages profondes, celles qui reçoivent la visite du robot une fois par mois, seront traitées... une fois par mois.

Ce qui ne se transmet pas

La liste est plus longue qu'on ne l'imagine.

• Les signaux de marque. Si des milliers d'internautes tapaient l'ancien nom dans Google chaque mois, ce volume ne migre pas. Il faut le reconstruire, et ça prend des mois, parfois des années sur un nom bien installé.
• Les mentions non liées. Toutes les citations de votre ancien domaine en texte brut, dans des articles, des forums, des PDF, des commentaires. Elles restent attachées à l'ancien nom.
• La confiance des utilisateurs. Un visiteur qui reconnaissait le nom dans les résultats de recherche ne le reconnaît plus. Le taux de clic en prend un coup, souvent de manière durable.
• Les données Search Console. Deux domaines, deux propriétés distinctes, deux historiques séparés. Aucune fusion possible. C'est pour cette raison qu'un export préalable est non négociable.
• Certains liens. Les liens en nofollow, ceux placés sur des sites morts ou non recrawlés, ceux dont l'éditeur nettoie régulièrement les redirections. Une partie du profil de liens s'évapore mécaniquement.

Le coût réel d'une migration réussie

Voilà le chiffre que personne n'aime annoncer en réunion. Sur une migration propre, c'est-à-dire préparée, testée, avec une correspondance d'URL au cas par cas, il faut s'attendre à un creux de 10 à 20 % de visibilité organique pendant 4 à 8 semaines.

Pas 0 %. Pas de migration invisible. Ce creux est normal, il correspond au temps de digestion de Google.

Ensuite, le retour au niveau initial se fait généralement entre la sixième et la douzième semaine. Et il n'est pas rare de finir au-dessus, quand l'occasion a servi à corriger une structure d'URL bancale ou à supprimer 300 pages vides qui diluaient le budget de crawl. Une migration, c'est un grand ménage forcé. Autant en profiter, mais avec méthode, et le paragraphe sur les erreurs vous dira pourquoi il ne faut surtout pas tout faire en même temps.

Ce chiffrage de 10 à 20 % est votre référence pour toute la suite. Gardez-le en tête, c'est lui qui va déterminer si ce que vous observez en semaine 3 est normal ou alarmant.

Phase 1 : la préparation, entre 4 et 6 semaines avant

C'est ici que tout se joue. Une migration ratée n'est presque jamais une migration mal exécutée, c'est une migration mal préparée. Quatre à six semaines, ce n'est pas du confort, c'est le minimum pour faire les choses dans l'ordre sans travailler dans l'urgence.

Figer un état des lieux exploitable

Première étape : savoir exactement ce qu'on possède. Et « exactement » ne veut pas dire « à peu près ».

Il faut croiser quatre sources, parce qu'aucune n'est complète à elle seule :

• Le rapport de couverture Search Console, pour les URL réellement indexées
• Le ou les sitemaps XML, pour les URL déclarées
• Un crawl complet du site, pour les URL accessibles depuis le maillage
• Les logs serveur, sur trois à six mois si possible

Ce dernier point est celui qu'on saute le plus souvent, et c'est dommage. Les logs révèlent des URL qui reçoivent encore du trafic ou des visites de Googlebot alors qu'elles n'apparaissent nulle part ailleurs. D'anciennes landing pages oubliées, des URL avec paramètres, des pages orphelines qui ont perdu leurs liens internes mais gardé leurs backlinks. Sur une migration récente pour un site industriel, l'analyse de logs a fait remonter 340 URL absentes du crawl comme du sitemap. Dont une douzaine avec des liens entrants de qualité. Sans les logs, elles partaient en 404.

Cartographier le patrimoine de liens

Vos backlinks sont l'actif le plus difficile à reconstruire. Traitez-les comme tel.

Exportez le profil complet, puis triez par valeur réelle : autorité du domaine référent, trafic de la page qui vous lie, pertinence thématique. Ensuite, séparez en deux piles.

La première, ce sont les liens qu'on peut faire modifier à la source. Partenaires, clients, annuaires professionnels dont vous gérez la fiche, sites d'associations, plateformes où vous avez un compte. Un simple e-mail suffit souvent. Sur les 20 ou 30 domaines référents les plus importants, ça vaut vraiment le coup de prendre le téléphone.

La seconde pile, c'est tout le reste. Ces liens-là reposeront à 100 % sur vos redirections, pour toujours. Ce qui explique pourquoi on ne coupe jamais l'ancien domaine, mais patience, on y arrive.

Prendre un instantané de référence

Un point zéro daté, horodaté, archivé. Sans lui, aucun diagnostic post-migration n'est possible, et vous passerez les huit semaines suivantes à répondre « je ne sais pas » aux questions de la direction.

Ce qu'il faut figer, la veille du basculement :

• Les positions sur l'intégralité du champ suivi, pas seulement le top 20
• Le trafic organique page par page, sur 3 mois et sur 12 mois
• Les clics et impressions par requête, exportés depuis Search Console
• Le nombre d'URL indexées
• Le taux de conversion organique, par type de page

Ce dernier indicateur est souvent oublié. Or c'est celui qui parle à la direction générale. Une perte de 15 % de trafic sur des pages qui ne convertissaient pas, c'est un non-événement. Une perte de 5 % sur les trois pages qui font le chiffre d'affaires, c'est autre chose.

Construire la matrice de redirection

Le livrable central. Un tableau, une ligne par URL, deux colonnes minimum : URL source et URL cible. C'est fastidieux, ça n'a rien de glorieux, et c'est précisément ce qui fait la différence entre une migration qui remonte en six semaines et une qui ne remonte jamais.

URL source	URL cible	Cas
ancien.fr/nos-services/depannage	nouveau.fr/services/depannage	Correspondance directe
ancien.fr/actu/article-2019	nouveau.fr/blog/article-2019	Changement de segment
ancien.fr/promo-ete-2021	nouveau.fr/services/depannage	Page supprimée, report thématique
ancien.fr/panier	nouveau.fr/panier	Hors index, redirection technique

Trois règles à poser dès maintenant, et à ne jamais négocier.

Jamais de redirection en masse vers l'accueil. Google traite ce type de redirection comme un soft 404 et n'en transmet à peu près rien. C'est l'équivalent d'une suppression pure et simple, avec l'illusion du travail bien fait en prime.

Jamais de chaîne à plus d'un saut. Si votre ancienne structure contenait déjà des redirections, mettez-les à plat : l'URL d'origine doit pointer directement vers la destination finale. Une chaîne de trois sauts, c'est de la dilution et du budget de crawl gaspillé.

Correspondance sémantique stricte. Une page « installation de pompe à chaleur » redirige vers « installation de pompe à chaleur ». Pas vers la catégorie chauffage, pas vers le blog. Si l'équivalent exact n'existe pas, on choisit la page la plus proche thématiquement, et on documente ce choix dans une troisième colonne.

Pour les pages sans aucun équivalent, deux options seulement : redirection vers la page parente pertinente, ou 410 assumée. Ce qu'il ne faut pas faire, c'est laisser le cas non traité et découvrir en semaine 2 que le serveur applique une règle par défaut dont personne n'a discuté.

Vérifier la santé du domaine d'arrivée

Étape rapide, mais qui a déjà sauvé des projets entiers.

Si le nom de domaine que vous achetez a déjà vécu, il faut savoir ce qu'il a fait de sa vie. Un passage par les archives du web, un contrôle du profil de liens existant, une recherche du nom entre guillemets. On cherche des traces de réseaux de sites, de contenus douteux, de pénalité manuelle. Un domaine qui a servi de PBN pendant trois ans n'est pas un cadeau, c'est un passif.

Vérifiez aussi la cohérence globale : extension adaptée au marché visé, orthographe non ambiguë à l'oral, absence de conflit de marque. Ce dernier point relève du juridique, mais un domaine attaqué six mois après la migration, c'est une seconde migration à financer.

Phase 2 : le jour J, l'exécution technique

Un conseil avant de commencer : choisissez un mardi ou un mercredi matin. Pas un vendredi soir, pas la veille d'un pont. Vous voulez que l'équipe soit disponible dans les 48 heures qui suivent, pas en train de répondre depuis un téléphone au bord d'une piscine.

Les redirections 301, une par une

La matrice devient du code. Selon votre configuration, ce sera un fichier de règles côté serveur, une table de correspondance en base, ou une extension dédiée.

Testez l'intégralité avant l'ouverture au public. Pas un échantillon, pas « les 50 URL les plus importantes » : l'intégralité. Un script qui parcourt la liste et vérifie deux choses pour chaque ligne : le code de statut réel renvoyé (301, et pas 302 ni 200), et l'URL finale d'arrivée après résolution complète.

Parce que oui, une redirection peut très bien vous amener sur la bonne page tout en renvoyant un code 302. Visuellement, tout va bien. Pour Google, rien n'est transmis.

Les canoniques et les balises internes

Sur le nouveau domaine, chaque page doit porter une balise canonical en URL absolue pointant vers elle-même, sur le nouveau nom de domaine. Ça paraît évident. C'est pourtant l'un des bugs les plus fréquents lors d'une migration : le CMS conserve l'ancien domaine en dur dans sa configuration, et toutes les canoniques du nouveau site désignent... l'ancien. Google suit consciencieusement, et vous vous retrouvez avec un nouveau domaine qui refuse obstinément de s'indexer.

Dans la foulée, mettez à jour les annotations hreflang si le site est multilingue, ainsi que les données structurées. Le champ url et l'identifiant @id des schémas Organization, LocalBusiness ou Article contiennent souvent l'ancien domaine.

Reprendre le maillage interne à la source

Point critique, systématiquement négligé, et pourtant très simple à comprendre : vos liens internes ne doivent pas passer par les redirections.

Un site où tous les liens internes pointent vers l'ancien domaine reste techniquement fonctionnel. Chaque clic déclenche une 301, l'utilisateur arrive à bon port. Sauf que Googlebot dépense son budget de crawl à traverser des redirections au lieu d'explorer votre contenu, que la vitesse de chargement s'en ressent, et que le signal envoyé est confus : ce site se lie lui-même via un ancien nom, il n'a donc pas vraiment déménagé ?

Un simple rechercher-remplacer en base de données règle 95 % des cas. Attention à traiter aussi les liens dans les images, les fichiers CSS et JS, les PDF téléchargeables, les modèles d'e-mails transactionnels et les blocs de configuration.

Sitemaps et robots.txt

Publiez un sitemap propre sur le nouveau domaine, contenant uniquement les nouvelles URL en 200. Et conservez temporairement l'ancien sitemap accessible sur l'ancien domaine, avec les anciennes URL : ça accélère nettement la découverte des redirections par Google. Deux à trois semaines suffisent, ensuite on le retire.

Puis vérifiez le robots.txt du nouveau domaine. Vérifiez-le vraiment, ouvrez-le dans un navigateur, lisez-le.

Parce que si le nouveau site a été préparé sur un environnement de recette, il y a de fortes chances qu'il traîne un Disallow: / hérité de la phase de développement. C'est l'erreur la plus banale du métier, et de très loin la plus coûteuse : le site est parfait, les redirections impeccables, et Google n'a le droit d'explorer strictement rien. Une semaine à ce régime et la chute est brutale.

Déclarer le changement d'adresse

Search Console propose un outil de changement d'adresse. Il faut l'utiliser, mais en comprenant ce qu'il fait et ce qu'il ne fait pas.

Ce qu'il fait : il signale explicitement à Google que le site déménage, ce qui accélère le transfert des signaux et limite la durée du creux.

Ce qu'il ne fait pas : il ne remplace aucune redirection. C'est un signal complémentaire, pas un substitut. Les conditions d'éligibilité sont strictes, notamment la présence de redirections 301 effectives entre les deux domaines, et une validation de propriété sur les deux côtés.

D'où l'ordre d'exécution, qui compte : créer et valider la nouvelle propriété avant le basculement, garder l'ancienne active et vérifiée. Une propriété validée par balise HTML sur l'ancien site devient invalide dès que le site est redirigé. Passez par le DNS ou par un fichier, c'est plus robuste.

Les à-côtés qu'on oublie

La partie SEO ne représente qu'une moitié du chantier. Voici la liste de ce qui casse quand on n'y pense pas :

• Le certificat SSL du nouveau domaine, installé et actif avant l'ouverture
• Les redirections www/non-www et http/https, à combiner proprement avec celles de la migration, sans créer de chaîne
• Les adresses e-mail, avec une période de double fonctionnement d'au moins six mois
• La fiche Google Business Profile, dont l'URL doit être mise à jour le jour même
• Les profils sociaux, les signatures d'e-mail, les documents commerciaux
• Les plateformes tierces : places de marché, comparateurs, annuaires payants, plateformes d'avis
• Les outils connectés : Analytics, tags publicitaires, CRM, outils de tracking d'appels
• Les campagnes publicitaires en cours, dont les URL de destination vont partir en redirection

Sur ce dernier point, une remarque : les redirections fonctionnent, donc les campagnes tournent toujours. Mais un compte publicitaire dont toutes les destinations passent par une 301 finit par voir ses scores de qualité se dégrader. Autant les mettre à jour tout de suite.

Phase 3 : la surveillance, les huit semaines qui suivent

La migration n'est pas terminée quand le site bascule. Elle est terminée quand la courbe est revenue à son niveau d'avant. Entre les deux, il y a huit semaines pendant lesquelles il faut regarder, et surtout savoir quoi regarder.

Le calendrier de contrôle

Un découpage qui fonctionne bien en pratique :

Période	Fréquence	Points de contrôle
Jours 1 à 7	Quotidienne	Erreurs d'exploration, codes 404, indexation des nouvelles URL, trafic temps réel
Semaines 2 à 4	Hebdomadaire	Courbes d'indexation croisées, positions sur le champ suivi, clics Search Console
Semaines 5 à 8	Hebdomadaire allégée	Trajectoire de récupération, comparaison au point zéro, conversions

La première semaine est la plus intense, et c'est normal : c'est là qu'on rattrape les oublis de la matrice. Chaque 404 remontée par Search Console est une ligne manquante à ajouter.

Les indicateurs et leurs seuils d'alerte

Le signal le plus fiable, celui qu'on regarde en premier, c'est le croisement des deux courbes d'indexation. Sur l'ancienne propriété, le nombre d'URL indexées doit descendre. Sur la nouvelle, il doit monter. Et surtout, les deux doivent bouger ensemble.

Si l'ancienne descend sans que la nouvelle ne monte, il y a un problème de blocage sur le nouveau domaine. Si la nouvelle monte sans que l'ancienne ne descende, les redirections ne sont probablement pas vues comme telles. Ces deux courbes racontent en un coup d'œil ce qui se passe.

Ensuite, les seuils. Concrètement :

• Baisse de trafic organique inférieure à 20 %, sur moins de 6 semaines : c'est le scénario nominal. On surveille, on ne touche à rien.
• Baisse comprise entre 20 et 30 % : zone de vigilance. On recontrôle la matrice, on cherche les pages fortes qui n'ont pas repris leur position.
• Baisse supérieure à 30 %, ou qui dure au-delà de 6 semaines sans amorce de remontée : ce n'est plus un creux de migration. C'est un problème technique à diagnostiquer immédiatement.

Ce dernier seuil est le plus important de tout cet article. Passé six semaines, l'excuse « Google est en train de digérer » ne tient plus. Quelque chose bloque, et plus on attend, plus la remise en route est longue.

Diagnostiquer quand ça ne remonte pas

Un arbre de décision court, à dérouler dans l'ordre. Les causes sont presque toujours dans cette liste.

1. Le robots.txt et les balises meta robots. Toujours commencer par là. C'est la cause la plus fréquente et la plus rapide à vérifier.
2. Les canoniques. Pointent-elles vers le nouveau domaine ? Un test sur dix pages au hasard, en lisant le code source.
3. Les redirections manquantes. Recroisez la liste des URL indexées avant migration avec les 404 remontées. Chaque écart est une perte sèche.
4. Les chaînes de redirection. Un outil de crawl les détecte en quelques minutes. Aplatissez tout ce qui dépasse un saut.
5. Le contenu modifié en même temps. Si les textes, les titres ou la structure ont bougé pendant la migration, vous ne pouvez plus isoler la cause. C'est exactement le piège décrit plus bas.
6. L'ancien domaine. Est-il toujours actif ? Le renouvellement automatique est-il en place ? A-t-on coupé l'hébergement pour économiser 4 € par mois ?

Combien de temps garder l'ancien domaine

Recommandation ferme, et pas négociable : un an minimum, avec les redirections actives. Et honnêtement, tant qu'il existe des liens externes pointant vers l'ancien nom, autant le garder indéfiniment.

Faisons le calcul. Un nom de domaine coûte entre 10 et 20 € par an. L'hébergement d'un simple serveur de redirection, quelques euros par mois. Total : une cinquantaine d'euros annuels, disons cent en étant large.

En face, la perte : tous les backlinks accumulés depuis la création du site, plus le trafic direct des visiteurs qui ont gardé l'ancienne adresse en favori. Sur un site installé, ça se chiffre en milliers d'euros de valeur.

Le pire scénario ? Un ancien domaine qui expire, qui est racheté par un tiers, et qui redirige un an plus tard vers un site de jeux d'argent. Tous vos anciens backlinks alimentent désormais quelqu'un d'autre, et votre marque est associée à un contenu que vous ne contrôlez pas. Ça arrive plus souvent qu'on ne le pense, et le rachat n'est jamais aussi simple qu'espéré.

Les erreurs qui coûtent le plus cher

Elles reviennent toutes avec une régularité déprimante. Voici les six qui font le plus de dégâts, avec ce qu'elles coûtent réellement.

Rediriger toutes les URL vers l'accueil. La tentation est forte : une seule règle, cinq minutes de travail, aucune 404. Sauf que Google interprète ces redirections comme des soft 404 et ne transmet quasiment rien. Résultat observé sur ce type de configuration : une perte de 60 à 80 % de la visibilité, sans remontée spontanée. Il faut alors reconstruire la matrice après coup, et le rattrapage prend deux à trois fois plus de temps que si le travail avait été fait dès le départ.

Cumuler migration de domaine et refonte. Nouveau nom, nouveau design, nouvelle arborescence, contenus réécrits : tout en même temps. Le problème n'est pas tant le cumul des risques que l'impossibilité totale de diagnostiquer. Quand le trafic chute de 40 %, est-ce la redirection, la nouvelle structure, les contenus raccourcis, ou le temps de chargement qui a doublé ? Impossible de trancher. La règle : migrer d'abord, laisser stabiliser six à huit semaines, refondre ensuite.

Utiliser des 302 « le temps de tester ». Ça part d'une bonne intention et ça finit toujours pareil : la redirection temporaire reste en place, personne ne repasse dessus, et Google continue de considérer l'ancienne URL comme la version de référence. Six mois plus tard, le nouveau domaine n'a toujours pas récupéré son autorité. Une 301 se teste très bien en préproduction, il n'y a aucune raison de passer par une 302.

Laisser expirer l'ancien domaine. Voir plus haut. C'est irréversible dans les faits.

Migrer en haute saison. Un e-commerce qui bascule mi-novembre, un site de location de vacances qui migre en avril, un spécialiste de la climatisation qui change de nom en juin. Le creux normal de 10 à 20 % tombe pile sur la période qui fait l'année. La bonne fenêtre, c'est le creux d'activité, quand une baisse temporaire ne se traduit pas en manque à gagner critique.

Oublier de valider la nouvelle propriété avant le basculement. Erreur de séquence, pas de méthode. Sans les deux propriétés validées simultanément, l'outil de changement d'adresse est inutilisable, et vous perdez le seul levier d'accélération dont Google vous fait cadeau. Cinq minutes de travail, à faire au bon moment.

La checklist récapitulative

À imprimer, à cocher, à coller au mur du bureau. Elle se suffit à elle-même.

Avant : 4 à 6 semaines

• Export complet des URL indexées, croisant Search Console, sitemap, crawl et logs serveur
• Export du profil de backlinks, tri par valeur, liste des domaines à contacter
• Prise de contact avec les 20 à 30 référents prioritaires pour modification à la source
• Instantané daté : positions, trafic par page, requêtes, indexation, conversions
• Matrice de redirection complète, une ligne par URL, cas particuliers documentés
• Contrôle de l'historique du nouveau domaine (archives, profil de liens, pénalités)
• Nouvelle propriété Search Console créée et validée, de préférence par DNS
• Date de bascule fixée hors haute saison, en début de semaine

Le jour J

• Redirections 301 déployées et testées à 100 %, code de statut vérifié ligne par ligne
• Aucune chaîne de redirection supérieure à un saut
• Balises canonical en absolu vers le nouveau domaine
• Hreflang et données structurées mis à jour
• Maillage interne réécrit vers les nouvelles URL, sans passer par les 301
• Chemins des images, fichiers CSS/JS et documents mis à jour
• Nouveau sitemap publié, ancien sitemap conservé 2 à 3 semaines
• Robots.txt du nouveau domaine vérifié à l'œil, pas de Disallow: /
• Certificat SSL actif, redirections www et https intégrées sans chaîne
• Changement d'adresse déclaré dans Search Console
• Google Business Profile, réseaux sociaux, plateformes tierces, outils de tracking
• URL de destination des campagnes publicitaires mises à jour

Après : 8 semaines

• Contrôle quotidien la première semaine : 404, erreurs d'exploration, indexation
• Ajout immédiat des redirections manquantes révélées par les 404
• Suivi croisé des deux courbes d'indexation, elles doivent bouger ensemble
• Contrôle hebdomadaire des positions et du trafic, comparé au point zéro
• Seuil d'alerte : plus de 30 % de baisse, ou plus de 6 semaines sans remontée
• Ancien domaine et redirections conservés au minimum un an, renouvellement automatique activé
• Refonte éventuelle repoussée à au moins 8 semaines après stabilisation

En résumé

Une migration réussie n'est pas une migration bien exécutée. C'est une migration bien préparée, dont l'exécution n'est plus qu'une formalité de deux heures un mardi matin.

La différence entre les deux tient dans un tableau. La matrice de redirection, cette liste ingrate de plusieurs centaines de lignes que personne n'a envie de construire, contient à elle seule l'essentiel du risque et l'essentiel de la valeur. Tout le reste, l'outil Search Console, les sitemaps, les canoniques, ce sont des accélérateurs. Utiles, mais secondaires.

Reste que le changement de nom de domaine appartient à cette catégorie d'opérations où l'erreur ne se voit pas tout de suite, et se paie pendant des mois. Une relecture externe de la matrice avant le jour J prend quelques heures. La correction d'une migration ratée, elle, se compte en trimestres, et parfois le retour au niveau d'avant n'a jamais lieu.

Autant faire relire le tableau.