Pourquoi vos classements ne récupèrent-ils pas après un changement de domaine ?

Qu'implique réellement un changement de domaine du point de vue de Google ?

Une migration de domaine n'est jamais une simple opération administrative. Pour Google, c'est un signal que l'ensemble des URLs d'un site changent d'adresse, ce qui nécessite une refonte complète du mapping dans l'index. Les redirections 301 indiquent au crawler que le contenu a déménagé de façon permanente, tandis que la notification via Search Console accélère la prise en compte de ce changement.

Le problème, c'est que cette opération n'est jamais instantanée. Google doit re-crawler l'ancien domaine, découvrir les redirections, suivre les nouvelles URLs, réévaluer les signaux (backlinks, autorité, comportement utilisateur) et redistribuer les positions. Si un maillon de cette chaîne casse — redirections mal configurées, crawl budget insuffisant, balises canonical contradictoires — la récupération des classements peut échouer partiellement ou totalement.

Les redirections 301 suffisent-elles à garantir le transfert des positions ?

En théorie, oui. En pratique, c'est rarement aussi simple. Les redirections 301 transfèrent environ 90-95% du PageRank selon les observations terrain, mais ce n'est pas une garantie absolue que les positions suivront mécaniquement. D'autres facteurs entrent en jeu : la vitesse à laquelle Google détecte et suit les redirections, la qualité du nouveau domaine, et surtout son historique.

Si le domaine cible a été utilisé auparavant pour du spam, des contenus de mauvaise qualité, ou s'il a été pénalisé, Google peut appliquer une forme de défiance qui ralentit ou bloque la récupération des classements. C'est là que l'affirmation de Mueller prend tout son sens : il ne suffit pas de migrer techniquement, il faut aussi s'assurer que le domaine de destination est propre.

Pourquoi Google insiste-t-il sur « l'historique de domaine » ?

Parce que les domaines ont une mémoire. Un nom de domaine qui a déjà servi peut porter des pénalités résiduelles, des backlinks toxiques, ou simplement une absence totale d'autorité. Google ne repart pas de zéro : il inspecte le profil de liens existant, l'historique d'indexation, les éventuelles actions manuelles passées.

Concrètement, acheter un domaine expiré pour une migration sans vérifier son passé est une erreur fréquente. Des outils comme Wayback Machine, Ahrefs ou SEMrush permettent de remonter le temps et de détecter des signaux d'alerte. Si le domaine a hébergé un site de casino douteux il y a deux ans, mieux vaut l'éviter.

• Redirections 301 : indispensables, mais pas suffisantes si mal configurées (chaînes de redirections, boucles, erreurs 404 intercalées).
• Notification Search Console : accélère la détection, mais ne compense pas un problème technique sous-jacent.
• Historique du domaine cible : un facteur souvent négligé qui peut saboter toute la migration si le domaine est « sale ».
• Crawl budget : après migration, Google doit re-crawler massivement. Un site lent ou mal structuré ralentit la récupération.
• Backlinks : ils doivent être mis à jour progressivement vers le nouveau domaine pour maximiser le transfert d'autorité.

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, globalement. Les migrations de domaine qui échouent présentent presque toujours l'un des deux problèmes identifiés par Mueller : soit une erreur technique (redirections incomplètes, mauvaise configuration du sitemap, balises canonical pointant encore sur l'ancien domaine), soit un domaine cible problématique. Les SEO seniors ont déjà tous vécu le cas d'une migration impeccable techniquement mais qui plafonne à cause d'un historique de domaine pourri.

Ce qui manque dans cette déclaration, c'est la dimension temporelle. Combien de temps faut-il attendre avant de conclure qu'une migration a échoué ? Google ne donne aucun chiffre, mais on observe terrain que 2 à 4 semaines suffisent généralement pour voir les premiers signaux de récupération. Si après 6 semaines rien ne bouge, c'est qu'il y a un problème structurel. [A vérifier] : Google n'a jamais communiqué de délai officiel.

Quels sont les cas limites que cette déclaration ne couvre pas ?

Mueller reste vague sur certains scénarios complexes. Par exemple : que se passe-t-il lors d'une migration partielle où seule une section du site change de domaine ? Ou lors d'une fusion de deux domaines en un seul ? Dans ces cas, les redirections deviennent un casse-tête, et la notion de « récupération des classements » devient floue, car il n'y a pas de correspondance 1:1 entre anciennes et nouvelles URLs.

Autre angle mort : le comportement utilisateur post-migration. Si le nouveau domaine est moins mémorisable, moins crédible visuellement, ou génère un taux de rebond plus élevé, Google peut interpréter cela comme un signal de qualité dégradée, indépendamment de la qualité technique de la migration. Mueller ne mentionne pas cette dimension UX, pourtant déterminante.

Faut-il toujours privilégier un domaine neuf pour une migration ?

Pas nécessairement, mais c'est souvent plus sûr. Un domaine expiré avec un bon historique peut apporter un boost initial grâce à son profil de backlinks existant et son ancienneté. Mais le risque est élevé : si vous ratez l'audit pré-achat, vous héritez de pénalités invisibles ou de liens toxiques qui plombent la migration.

La vraie question, c'est : avez-vous les moyens de vérifier méticuleusement l'historique ? Si oui, un domaine expiré propre peut être un atout. Sinon, un domaine brandable neuf reste le choix le plus prudent, quitte à sacrifier un peu de vitesse de démarrage.

Que faut-il faire concrètement avant de migrer un domaine ?

Avant même de pointer le moindre DNS, il faut auditer le domaine cible. Utilisez Wayback Machine pour remonter son historique, Ahrefs ou Majestic pour analyser son profil de backlinks, et Google Search Console (si vous avez accès à l'ancien propriétaire) pour détecter d'éventuelles actions manuelles. Un domaine qui a hébergé du spam ou des contenus douteux est une bombe à retardement.

Ensuite, cartographiez l'intégralité de vos URLs avec un crawler (Screaming Frog, Sitebulb) et préparez un plan de redirection 1:1. Chaque ancienne URL doit pointer vers sa nouvelle version la plus pertinente. Les redirections en cascade (301 → 301 → 200) diluent le PageRank et ralentissent le crawl. Testez ce plan sur un environnement de staging avant de passer en production.

Comment vérifier que la migration s'est bien déroulée ?

Une fois les redirections en place, notifiez immédiatement Google via Search Console (Paramètres > Changement d'adresse). Puis surveillez trois métriques clés : le taux de crawl sur l'ancien domaine (il doit baisser progressivement), le taux de crawl sur le nouveau (il doit monter), et l'évolution des positions sur vos requêtes stratégiques.

Dans les 48 premières heures, vous devriez voir les nouvelles URLs commencer à apparaître dans l'index. Si après une semaine Google crawle encore majoritairement l'ancien domaine, c'est qu'il y a un problème : redirections non détectées, robots.txt bloquant, ou sitemap XML non mis à jour. Vérifiez aussi que vos backlinks stratégiques ont bien été redirigés : contactez les sites référents pour qu'ils mettent à jour leurs liens.

Quelles erreurs éviter absolument lors d'une migration de domaine ?

Première erreur classique : laisser l'ancien domaine en 404 ou en page blanche au lieu de maintenir les redirections 301. Google a besoin de temps pour transférer l'autorité, et si vous coupez les redirections trop tôt (avant 6-12 mois), vous perdez une partie du PageRank. Deuxième erreur : oublier de mettre à jour les balises canonical sur le nouveau domaine. Si elles pointent encore vers l'ancien, Google va s'emmêler les pinceaux.

Troisième erreur : ne pas gérer le crawl budget post-migration. Un gros site avec des milliers d'URLs peut saturer Googlebot. Nettoyez les URLs parasites (paramètres inutiles, pagination infinie, facettes) et priorisez le crawl des pages stratégiques via le sitemap XML. Enfin, ne sous-estimez jamais l'impact UX : si le nouveau domaine dégrade l'expérience utilisateur (temps de chargement, ergonomie mobile), les classements peuvent chuter indépendamment de la qualité technique de la migration.

• Auditer l'historique du domaine cible (Wayback Machine, Ahrefs, Majestic) avant achat ou configuration.
• Mapper toutes les URLs et créer un plan de redirection 1:1 sans chaînes ni boucles.
• Tester les redirections sur un environnement de staging avant la mise en production.
• Notifier Google via Search Console dès que les redirections sont actives.
• Surveiller le crawl et les positions pendant 4 à 6 semaines minimum.
• Maintenir les redirections 301 actives pendant au moins 6 à 12 mois.