Migration de site dans Search Console : changement d'adresse, redirections et suivi du trafic après le déménagement

De quel type de déménagement s'agit-il ?

Google traite un changement de domaine, un passage à HTTPS et une nouvelle structure d'URL comme le même type de chantier : un déménagement de site avec changement d'URL, où chaque ancienne URL doit avoir une redirection permanente vers la nouvelle. L'outil Changement d'adresse n'est qu'une partie de ce chantier, et seulement pour certains déménagements ; mieux vaut donc savoir dans quelle ligne de ce tableau vous vous trouvez avant de planifier quoi que ce soit. Tout ce qu'il contient vient du guide de Google sur les déménagements de site et de sa page d'aide Changement d'adresse.

Google demande aussi de ne changer qu'une chose à la fois. Si vous prévoyez un nouveau domaine, un nouveau CMS et un nouveau design, son guide recommande de les faire l'un après l'autre, et la page Changement d'adresse prévient que combiner un déménagement avec une nouvelle structure d'URL fera « probably » perdre un peu de trafic le temps que Google réapprenne chaque page. Choisissez une période calme si votre trafic est saisonnier : moins de visiteurs subissent les problèmes de rodage et il reste plus de capacité serveur pour Googlebot.

Avant le déménagement : ce qu'il faut configurer dans Search Console

1. Validez les deux propriétés, toutes les variantes. Le guide de Google demande de « valider toutes les variantes de l'ancien et du nouveau site », par exemple www et non-www, et HTTP et HTTPS si vous utilisez HTTPS. Une propriété de domaine couvre tous les sous-domaines et les deux protocoles d'un coup, et nécessite une validation DNS. L'outil Changement d'adresse ajoute une règle plus stricte : vous devez être propriétaire des deux propriétés et utiliser le même compte Google pour gérer les deux. Vérifiez aussi que la validation survit au déménagement : un fichier de validation HTML doit être copié sur le nouveau site, et une balise meta doit figurer dans les nouveaux gabarits.
2. Reportez les réglages et contrôlez un domaine racheté. Si vous avez importé un fichier de désaveu pour l'ancien site, Google recommande de le réimporter dans la nouvelle propriété. Si le nouveau domaine a été acheté d'occasion, cherchez des actions manuelles et des suppressions d'URL laissées par l'ancien propriétaire, « en particulier une suppression d'URL à l'échelle du site ».
3. Construisez la table de correspondance des URL. Notez où va chaque ancienne URL. Google suggère de partir de vos sitemaps, de vos logs serveur ou de votre outil d'analytics, du rapport Liens de Search Console et de votre CMS, et rappelle d'inclure les images, les vidéos, les fichiers JavaScript et CSS, qui se déplacent comme n'importe quelle autre URL. Ajoutez toutes les pages qui ont reçu des clics dans le rapport Performances, mais notez que l'interface de Search Console n'exporte que 1 000 lignes par tableau : sur un site plus grand, il vous faut l'API pour tout récupérer (voir la limite de 1 000 lignes).
4. Crawlez l'ancien site. Un crawl complet avec un crawler de bureau vous donne le code de statut de chaque ancienne URL avant tout changement, les liens internes à mettre à jour, et la liste contre laquelle vous testerez les redirections le jour du lancement. Google cite lui-même Screaming Frog pour vérifier que les redirections fonctionnent comme prévu. Conservez la liste des sites qui font un lien vers vous, tirée du rapport Liens tant que l'ancienne propriété l'affiche, pour pouvoir demander plus tard aux plus précieux de mettre leurs liens à jour.
5. Exportez une référence. Exportez les clics, les impressions et la position par page et par requête sur au moins les 28 derniers jours, et sur les mêmes semaines de l'an dernier si votre trafic est saisonnier. Après le déménagement, les chiffres de l'ancienne propriété s'effacent, et Search Console ne conserve que 16 mois de données (voir la conservation des données) : cet export vous permettra de savoir au troisième mois si le nouveau site est revenu au niveau de l'ancien.
6. Préparez les nouvelles pages. Chaque nouvelle URL a besoin d'une balise canonique auto-référencée, les annotations hreflang doivent pointer vers les nouvelles URL, les liens internes doivent viser directement les nouvelles URL, et un sitemap des nouvelles URL doit être prêt à soumettre. Si le nouveau site était masqué par un noindex ou un blocage robots.txt pendant le développement, dressez dès maintenant la liste de ce qu'il faudra retirer le jour du lancement. Les pages supprimées ou fusionnées sans remplaçante doivent répondre 404 ou 410.

Le déménagement : redirections 301, changement d'adresse et sitemaps

Redirigez chaque ancienne URL, une à une, avec une 301

Google recommande des redirections permanentes côté serveur, HTTP 301 ou 308, de chaque ancienne URL vers la nouvelle URL de votre table. Sa documentation sur les redirections explique pourquoi le type compte : avec une redirection permanente, « le pipeline d'indexation utilise la redirection comme un signal indiquant que la cible de la redirection doit être canonique », alors qu'avec une redirection temporaire 302, 303 ou 307 ce n'est pas le cas, et l'ancienne URL peut rester dans les résultats. Pointez chaque ancienne URL directement vers sa destination finale. Googlebot suit jusqu'à 10 sauts, mais Google conseille de limiter une chaîne à « idéalement pas plus de 3 et moins de 5 », et une redirection directe est encore préférable. N'envoyez pas de nombreuses anciennes URL vers une seule page sans rapport, comme la nouvelle page d'accueil, ce qui « peut être traité comme une soft 404 » selon Google, même si plusieurs anciennes pages regroupées en une seule nouvelle page peuvent toutes y être redirigées. Google précise aussi que les 301 et les autres redirections permanentes « n'entraînent pas de perte de PageRank ».

Testez les redirections dès qu'elles sont en ligne. Google suggère l'outil d'inspection d'URL pour les URL isolées et des outils en ligne de commande ou des scripts pour un grand nombre, et cite les redirections vers des URL inexistantes du nouveau site parmi les erreurs de migration les plus courantes. Activez ensuite ce que vous aviez préparé : retirez les noindex et les blocages robots.txt de développement, et vérifiez que les balises canoniques du nouveau site utilisent les nouvelles URL.

Comment utiliser l'outil Changement d'adresse

N'utilisez-le qu'une fois le site déplacé et les redirections en ligne ; la page d'aide de Google dit « utilisez cet outil une fois votre site déplacé et redirigé ». Les conditions requises, d'après cette page :

• Vous êtes propriétaire de l'ancienne et de la nouvelle propriété, avec le même compte Google.
• L'ancienne propriété est au niveau du domaine (example.com, m.example.com ou http://example.com), et non d'un chemin comme http://example.com/petstore/.
• Une 301 redirige l'ancienne page d'accueil vers la nouvelle page d'accueil. Google recommande aussi des 301 pour les pages canoniques de l'ancien site, et l'outil vérifie la présence de 301 sur quelques pages avant d'accepter la demande.

Les étapes elles-mêmes sont courtes. Ouvrez l'ancienne propriété, allez dans Paramètres → Changement d'adresse, choisissez la nouvelle propriété sous Sélectionner le nouveau site et cliquez sur Valider & mettre à jour. L'outil exécute ses vérifications préalables : une vérification critique en échec doit être corrigée avant de continuer, tandis qu'une vérification non critique en échec affiche un avertissement et laisse passer la demande. Une fois la demande acceptée, les deux propriétés affichent un avis indiquant que le déménagement est en cours pendant 180 jours. Répétez la demande pour chaque variante de l'ancien domaine que vous avez validée, car l'outil déplace tous les protocoles de la propriété que vous nommez mais aucun des sous-domaines situés en dessous, www compris.

La version courte de ces mêmes étapes figure dans la FAQ Comment utiliser l'outil Changement d'adresse.

Ce que fait l'outil Changement d'adresse, et ce qu'il ne couvre pas

Selon Google, un changement d'adresse indique à Google d'explorer et d'indexer le nouveau site de préférence à l'ancien, transmet les signaux de l'ancien site au nouveau et fait préférer le nouveau site lors du choix des pages canoniques, pendant 180 jours à compter de la demande. Il ne remplace aucune partie du travail de redirection, et il a des limites claires :

Si vous changez d'avis, une demande peut être annulée dans ces 180 jours : supprimez les redirections de l'ancien vers le nouveau site, ajoutez des redirections du nouveau site vers l'ancien, et cliquez sur Annuler le déplacement dans l'outil Changement d'adresse de l'ancienne propriété.

Sitemaps pour les anciennes et les nouvelles URL

Soumettez le sitemap des nouvelles URL dans la nouvelle propriété le jour du lancement. Le guide de Google suggère aussi de soumettre un second sitemap qui liste les anciennes URL, comme jauge : au début, le nouveau sitemap n'a aucune page indexée et l'ancien en a beaucoup ; avec le temps, le nombre de pages indexées de l'ancien tombe à zéro pendant que celui du nouveau monte. Search Console avertira que les URL de l'ancien sitemap sont redirigées, et Google dit « c'est normal et vous pouvez ignorer ces avertissements ». C'est la seule exception à la règle habituelle selon laquelle un sitemap ne liste que des URL finales (voir Page avec redirection), et elle est temporaire : dès que le nombre de pages indexées de l'ancien sitemap est proche de zéro, supprimez-le et ne gardez que le nouveau.

Gardez les redirections en place longtemps. Le guide des déménagements de site dit « généralement au moins 1 an » pour que tous les signaux puissent être transférés, et suggère de les conserver indéfiniment pour les utilisateurs ; la page Changement d'adresse fixe un minimum de 180 jours, davantage si les anciennes URL reçoivent encore du trafic de la Recherche Google, et recommande de payer l'ancien domaine pendant au moins un an pour que personne d'autre ne puisse l'acheter et en faire un mauvais usage.

Après le déménagement : quoi vérifier dans Search Console, semaine par semaine

Les conseils de Google sur le suivi se résument à un schéma : « Idéalement, le trafic de l'ancien site baissera, tandis que celui du nouveau site augmentera. » Le calendrier ci-dessous est la façon dont je répartis ces contrôles sur les premiers mois. Les délais relèvent de ma pratique, pas de Google ; Google dit seulement qu'un site de petite ou moyenne taille « peut demander quelques semaines pour que la plupart des pages soient déplacées » et que les sites plus grands prennent plus de temps, selon le nombre d'URL et la vitesse du serveur.

Indexation de l'ancien par rapport au nouveau. Le rapport d'indexation des pages (le guide de Google l'appelle encore Couverture de l'index) doit montrer le nombre de pages indexées qui baisse sur l'ancienne propriété et monte sur la nouvelle. Sur l'ancienne propriété, le statut attendu est Page avec redirection, que Google définit comme « une URL non canonique qui redirige vers une autre page », en ajoutant qu'une telle URL « ne sera pas indexée » alors que sa cible « peut être indexée ou non ». Ce statut signifie que le déménagement fonctionne, pas qu'il y a une panne. Ceux sur lesquels agir sont Erreur de redirection, que Google décrit comme une chaîne trop longue, une boucle de redirection, une URL de redirection qui dépasse la longueur maximale ou une URL incorrecte ou vide dans la chaîne, et un nombre inhabituel d'URL Introuvable (404) sur le nouveau site, ce qui signifie généralement des redirections vers des pages qui n'existent pas. Pour une URL isolée, l'outil d'inspection d'URL indique si Google a vu la redirection et quelle canonique il a retenue ; le playbook sur l'indexation technique couvre les autres statuts.

Le trafic qui passe d'une propriété à l'autre. Search Console garde les deux propriétés séparées : le rapport Performances ne montre donc jamais le déménagement comme une seule courbe. L'ancienne propriété perd des clics pendant que la nouvelle en gagne, et vous les additionnez vous-même, jour par jour, pour voir si le total tient. Comparez jour par jour plutôt que période par période, car les fenêtres avant et après le lancement ont rarement la même durée, et laissez de côté les deux ou trois derniers jours, que Search Console est encore en train de remplir. Si l'ancienne propriété collecte toujours une grande part des impressions un mois après le lancement, les redirections manquent ou Google n'a pas encore réexploré ces URL ; l'avis de changement d'adresse dans la nouvelle propriété indique aussi « d'autres sites sont en cours de déplacement vers ce site », et Google explique que son trafic augmente à mesure que les utilisateurs sont redirigés depuis l'ancien.

Charge serveur. Google prévient qu'après une migration, il explorera le nouveau site « plus intensément que d'habitude », parce que les explorations de l'ancien site sont redirigées en plus de l'exploration normale. Le rapport Statistiques sur l'exploration sous Paramètres montre cette charge, et une hausse des erreurs serveur y signale que le nouvel hébergeur a besoin de plus de capacité.

Comment GSC Wizard vous aide : Migration Compare

Search Console montre chaque propriété séparément, ce qui rend justement une migration difficile à juger. Le rapport Migration Compare de GSC Wizard réunit l'ancienne configuration (côté A, avant la date de mise en ligne) et la nouvelle (côté B, après) dans une seule analyse. Il se trouve sous Analyse de site dans le menu de gauche d'une propriété et dans le menu principal, et gère trois types de déménagement : Property vs property pour un changement de domaine ou un passage à HTTPS entre deux propriétés, URL prefixes pour un déplacement de dossier au sein d'une propriété, et Regex patterns pour une nouvelle structure d'URL. Rien n'est récupéré tant que vous n'avez pas cliqué sur Run analysis.

• Un verdict par rapport à une migration sur la bonne voie. Avec une date de mise en ligne, le bandeau Migration health indique la récupération (les clics par jour du nouveau côté en pourcentage de ceux de l'ancien avant la mise en ligne), le rythme par rapport à l'étape attendue, l'élan, un score de risque de 0 à 100 et le taux de réussite des URL, avec un statut Healthy, Recovering, At risk, Critical ou Insufficient data. Les étapes attendues sont des règles empiriques que j'ai intégrées au rapport, comme 60 % des anciens clics au jour 56 et 90 % au jour 180, pas une promesse pour un site donné. La page santé, récupération et risque explique chaque chiffre.
• Votre table d'URL, vérifiée sur le serveur en production. Importez la table ancien vers nouveau en CSV (jusqu'à 10 000 lignes par fichier, jusqu'à 50 000 par analyse) et cliquez sur Verify redirects. GSC Wizard interroge chaque ancienne URL, suit jusqu'à cinq sauts, respecte le robots.txt et donne à chaque correspondance un verdict : Migrated, Redirect chain, Temporary redirect, Wrong target, Not redirected, Broken target, Old URL broken, Redirect loop, Kept ou Unknown. Il signale aussi les redirections vers la page d'accueil, les cibles en noindex et les canoniques qui pointent encore vers l'ancien site. Voir tables de redirections et vérification.
• La vision de Google sur le déménagement. Le bouton Inspect in Google lance l'inspection d'URL sur les 20 à 200 principales paires ancienne et nouvelle URL et place chaque paire à une étape de transfert, de Redirect not seen yet à Canonical moved.
• Où est passé le trafic. Pages, requêtes, sections d'URL, pays, appareils et types de recherche avant et après, plus une checklist de lancement et jusqu'à 12 recommandations classées par nombre de clics en jeu. Quand le domaine a changé et que les anciennes URL continuent de collecter des impressions, l'une de ces recommandations est de déposer le Changement d'adresse dans Search Console.
• Alertes après le lancement. Enregistrez la migration et activez Alerts : une nouvelle vérification quotidienne contrôle à nouveau les redirections et publie dans Slack, Microsoft Teams ou un webhook quand de nouveaux problèmes de redirection apparaissent, ou quand la récupération stagne ou recule. Voir enregistrement, partage et alertes.

Migration Compare est inclus dans toutes les formules, et toutes les formules commencent par un essai gratuit de 7 jours (voir les tarifs). Il aide aussi à résoudre le problème de référence de l'étape de préparation : une propriété stockée dans GSC Wizard conserve jusqu'à 10 ans d'historique au lieu des 16 mois de Search Console, si bien que la fenêtre précédant le déménagement d'un ancien domaine reste disponible bien après que Google l'a supprimée.

Interroger un assistant IA sur la migration

Quand GSC Wizard est connecté à Claude, ChatGPT ou un autre client MCP, la même analyse est disponible sous forme d'outils : un assistant répond à partir des données mesurées au lieu de deviner.

Les outils MCP lisent les vérifications de redirections enregistrées par l'app ; ils n'en lancent pas de nouvelles eux-mêmes, donc cliquez d'abord sur Verify redirects dans l'app. La documentation du MCP liste tous les outils.

List my saved migrations, then run a health check on the shop
replatform. Tell me which three fixes matter most, with the clicks
at stake for each, and state the go-live date and both windows.

Questions fréquentes

Comment migrer un site web vers une nouvelle URL dans Search Console ?

Validez l'ancien et le nouveau site comme propriétés dans Search Console, y compris chaque variante que vous utilisez, et redirigez chaque ancienne URL vers son équivalent avec une redirection permanente côté serveur (301 ou 308). Soumettez un sitemap des nouvelles URL dans la nouvelle propriété. Si le domaine ou le sous-domaine change, ouvrez l'outil Changement d'adresse dans les Paramètres de l'ancienne propriété, sélectionnez le nouveau site et lancez Valider et mettre à jour. Surveillez ensuite les deux propriétés : l'indexation et le trafic doivent baisser sur l'ancienne et monter sur la nouvelle.

Ai-je besoin de l'outil Changement d'adresse pour passer de HTTP à HTTPS ?

Non. La page d'aide de Google dit de ne pas utiliser l'outil pour un passage de http à https : suivez le guide des déménagements de site et Google déduira lui-même le changement. L'outil ne sert pas non plus pour passer de www à non-www sur le même domaine, pour déplacer des chemins au sein d'un site, ni pour un changement d'hébergement ou de CDN sans changement d'URL.

Puis-je utiliser Changement d'adresse pour déplacer un sous-dossier ?

Pas comme source. L'outil ne fonctionne que sur des propriétés au niveau du domaine, comme example.com, m.example.com ou http://example.com, et Google précise qu'on ne peut pas déplacer des propriétés au niveau du chemin, comme http://example.com/petstore/. L'autre sens est autorisé : un domaine entier peut être déplacé vers un chemin d'un autre domaine, par exemple example.com vers example3.com/new/location/. Un déplacement de dossier au sein d'un même site n'exige que des redirections et des sitemaps mis à jour.

Combien de temps une migration de site met-elle à apparaître dans Search Console ?

Le guide de Google sur les déménagements de site indique qu'un site de petite ou moyenne taille peut mettre quelques semaines pour que la plupart des pages soient déplacées, et que les sites plus grands prennent plus de temps, selon le nombre d'URL et la vitesse du serveur. Le déplacement se fait URL par URL et n'est terminé que lorsque Googlebot a visité au moins une fois chaque ancienne et nouvelle URL. Une demande de changement d'adresse reste active pendant 180 jours.

Combien de temps garder les redirections 301 après un déménagement de site ?

Le guide de Google sur les déménagements de site dit en général au moins un an, pour que tous les signaux puissent être transférés, et suggère de les conserver indéfiniment pour les utilisateurs. La page d'aide Changement d'adresse fixe un minimum de 180 jours, davantage si les anciennes URL reçoivent encore du trafic de la Recherche Google, et recommande de payer l'ancien domaine pendant au moins un an pour que personne d'autre ne puisse l'acheter et en faire un mauvais usage.

Dois-je garder l'ancien sitemap après une migration de domaine ?

Pendant un temps, comme outil de mesure. Google suggère de soumettre un sitemap des anciennes URL à côté du nouveau, pour voir le nombre de pages indexées de l'ancien baisser vers zéro pendant que celui du nouveau monte, et précise que les avertissements de redirection sur l'ancien sitemap sont normaux. Dès que le nombre de l'ancien est proche de zéro, supprimez-le et ne gardez que le sitemap des nouvelles URL.

Pourquoi mon ancien site apparaît-il encore dans Google après le déménagement ?

Parce que le déplacement se fait URL par URL et qu'une ancienne URL ne disparaît qu'après que Googlebot l'a réexplorée et a vu la redirection. Google précise aussi que l'outil Changement d'adresse n'efface pas l'ancien site de l'index, et que les anciennes URL peuvent continuer à s'afficher quand elles n'ont pas de page équivalente sur le nouveau site. Des redirections et des balises canoniques auto-référencées sur les nouvelles pages réduisent le nombre d'anciennes URL affichées.

GSC Wizard peut-il déposer le Changement d'adresse à ma place ?

Non. Le changement d'adresse se déclare à la main dans Search Console. GSC Wizard mesure la migration : son rapport Migration Compare lit l'ancienne et la nouvelle propriété autour de la date de mise en ligne, vérifie sur le serveur en production chaque redirection de votre table de correspondance, évalue la récupération et le risque, et peut vous alerter dans Slack, Microsoft Teams ou via un webhook lorsque des redirections cassent ou que la récupération stagne.

Playbook suivant

Une fois la migration stabilisée, repérez les pages qui ne se sont jamais complètement rétablies et celles que Google peine encore à indexer : corriger les problèmes techniques d'indexation →