Migration SEO
Ce que Google documente vraiment : les durées, l’outil de changement d’adresse, et le contrôle qui attrape ce que les redirections ne voient pas.
Une migration SEO est le transfert d’un site vers de nouvelles URL, un nouveau domaine ou une nouvelle infrastructure, conduit de façon à conserver ses positions. Google en distingue deux familles au traitement très différent : les déplacements avec changement d’URL, qui reposent sur un plan de redirections, et les changements d’hébergement sans changement d’URL, qui reposent sur le DNS. La conservation des signaux n’est ni instantanée ni définitive : elle s’étale sur des mois et suppose que les redirections restent en place.
Quelles sont les deux familles de migration ?
Google publie deux guides distincts, et les confondre coûte cher. Le premier couvre les déplacements avec changement d’URL : nouveau nom de domaine, nouvelle structure de chemins, passage d’un sous-domaine à un autre. Tout y repose sur une correspondance explicite entre chaque ancienne URL et sa remplaçante, puis sur des redirections permanentes côté serveur. Le second couvre les changements d’infrastructure sans changement d’URL : nouvel hébergeur, mise derrière un réseau de diffusion de contenu. Aucune redirection n’y intervient, le sujet est le DNS et la disponibilité pendant la bascule. Une refonte graphique qui conserve les URL n’appartient à aucune des deux : elle ne déplace rien, et c’est précisément ce qui la rend dangereuse, puisque les contrôles habituels de migration n’y détectent rien.
Quelles étapes Google recommande-t-il ?
Cinq, dans un ordre qui ne se réorganise pas. Connaître les bonnes pratiques générales, préparer et tester le nouveau site, établir la table de correspondance des anciennes vers les nouvelles URL, lancer la migration par les redirections, puis surveiller le trafic. La table de correspondance est la seule étape irremplaçable : sans elle, une redirection globale vers la page d’accueil transforme chaque ancienne URL en page sans équivalent, ce que Google ne traite pas comme un déplacement. Sur le rythme, Google tranche selon la taille. Pour un site de petite ou moyenne taille, il recommande de déplacer toutes les URL simultanément plutôt que section par section. Pour un grand site, la migration par sections successives reste possible, dans le but de repérer les problèmes plus tôt.
Quelle redirection utiliser, et pourquoi ?
Une redirection permanente côté serveur, et Google explique ce que ce choix change. Les codes 301 et 308 sont permanents : Google les suit et les lit comme un signal que la cible doit devenir l’URL canonique. Les codes 302, 303 et 307 sont temporaires : Google les suit également, mais ne s’en sert pas pour désigner la page canonique, et l’ancienne URL peut rester indexée si d’autres signaux la désignent. La méthode compte autant que le code. Google classe les implémentations par fiabilité décroissante : côté serveur d’abord, puis la balise meta refresh, dont la version instantanée est traitée comme permanente et la version temporisée comme temporaire, puis JavaScript en dernier recours, parce que le rendu peut échouer et la redirection ne jamais être vue. Enfin, la longueur des chaînes se surveille : Googlebot suit jusqu’à 10 sauts, et une migration qui empile ses redirections sur celles d’une opération précédente atteint cette limite plus vite qu’on ne le croit.
| Code | Nature | Effet sur la canonique |
|---|---|---|
| 301, 308 | Permanente | La cible devient l’URL canonique |
| 302, 303, 307 | Temporaire | Suivie, mais sans transfert de canonicité |
| Meta refresh instantanée | Assimilée permanente | Acceptée, moins fiable qu’une redirection serveur |
| JavaScript | Dernier recours | Peut ne jamais être vue si le rendu échoue |
À quoi sert l’outil de changement d’adresse ?
À déclarer un déménagement de domaine, et à rien d’autre. L’aide de Search Console en délimite l’usage : il s’emploie quand le site passe d’un domaine ou d’un sous-domaine à un autre. Il ne couvre ni le passage de HTTP à HTTPS, ni le choix entre www et sans www, ni un changement de chemins à l’intérieur du même domaine. Ce qu’il fait est décrit sans ambiguïté : il demande à Google de privilégier l’exploration et l’indexation du nouveau site, il transmet différents signaux de l’ancien vers le nouveau, et il indique de préférer le nouveau site pour le choix des pages canoniques. Il ne remplace pas les redirections, il les accompagne. La documentation ajoute que les migrations de domaine fonctionnent mieux lorsque toutes les variantes du site, www comprise, sont déclarées.
Combien de temps dure une migration ?
Trois durées documentées se superposent, et ce sont elles qui commandent le calendrier. La première est celle de l’affichage : pour un site de petite ou moyenne taille, Google annonce quelques semaines ou davantage avant de commencer à montrer progressivement les nouvelles URL. La deuxième est celle de la reconnaissance : les actions déclenchées par le changement d’adresse se poursuivent pendant 180 jours, et passé ce délai Google ne reconnaît plus aucune relation entre l’ancien et le nouveau site, qu’il traite alors comme un site sans rapport s’il est encore accessible. La troisième est celle des redirections : Google demande de les maintenir au moins 180 jours, plus longtemps tant qu’un trafic subsiste, et recommande de les conserver au moins un an pour laisser le temps aux liens externes d’être réexplorés et réattribués. La conséquence pratique est directe : un contrat d’hébergement de l’ancien domaine résilié à six mois coupe le transfert des signaux au moment précis où il est encore actif.
Les 180 jours ne sont pas un délai au bout duquel la migration est acquise. C’est la durée pendant laquelle Google accepte de faire le lien. Ce qui n’a pas été transféré dans cette fenêtre ne le sera plus, et l’ancien domaine encore en ligne devient alors un site tiers, avec le risque de contenu dupliqué qui va avec.
Et si les URL ne changent pas ?
Le sujet devient la propagation DNS et la continuité de service. Google recommande d’abaisser la valeur de durée de vie des enregistrements DNS à une valeur basse, quelques heures par exemple, et de le faire au moins une semaine avant la bascule, pour que le changement se propage vite le jour venu. L’ancien serveur se conserve jusqu’à ce que les journaux montrent un trafic nul vers l’ancien hébergeur, pas jusqu’à une date fixée à l’avance. Pendant la transition, les journaux des deux serveurs se lisent en parallèle, et le rapport de couverture de l’index dans Search Console sert de contrôle. Google prévient enfin qu’une baisse temporaire du rythme d’exploration juste après la bascule est normale, suivie d’une remontée progressive sur plusieurs jours : ce creux n’est pas un symptôme.
Comment préparer une migration avant la mise en production ?
En traitant le fichier robots.txt et les certificats comme des livrables, pas comme des détails d’exploitation. Google demande de préparer le robots.txt que le nouveau site devra servir une fois la migration lancée, en tenant compte du fait que beaucoup de sites bloquent l’indexation de leur environnement de préproduction. Il demande également de préparer la liste des URL à désindexer si une règle noindex a été utilisée pendant le développement, et d’obtenir puis de configurer les certificats TLS nécessaires sur le nouveau serveur avant la bascule. Ces trois éléments partagent la même propriété : ils sont invisibles pour un contrôle visuel du site, et ce sont eux qui produisent les migrations où le site est parfait à l’écran et absent des moteurs de recherche.
Que surveiller dans Search Console après la bascule ?
Trois rapports, lus ensemble et dans cet ordre. Le rapport des sitemaps, pour suivre en parallèle l’indexation des anciennes et des nouvelles URL : Google conseille de soumettre le nouveau sitemap au moment de la bascule pour accélérer la découverte des adresses. Le rapport de couverture de l’index ensuite, où le mouvement attendu est un double mouvement, baisse des anciennes URL indexées et hausse des nouvelles. Les performances de recherche enfin, pour vérifier que les nouvelles URL commencent à recevoir des impressions et des clics. Google précise que les avertissements portant sur les anciennes URL peuvent être ignorés pendant la transition, puisqu’ils décrivent la migration elle-même, mais qu’il faut contrôler régulièrement l’apparition d’erreurs d’exploration inattendues. Pour vérifier les redirections une par une, il renvoie à l’outil d’inspection d’URL, et à des outils en ligne de commande ou des scripts dès qu’il s’agit d’en tester un grand nombre.
Comment éviter la perte de trafic ?
En mesurant avant, pas seulement après, et en mesurant autre chose que les codes HTTP. Trois relevés se prennent sur l’ancienne version et se rejouent à l’identique sur la nouvelle : la liste complète des URL indexées avec leur trafic, le titre et la méta description réellement servis dans le code HTML de chaque page, et les balises canoniques et directives d’indexation. Le premier relevé alimente la table de correspondance. Le deuxième attrape les pertes invisibles, celles qui ne changent aucune URL. Le troisième attrape la panne classique de recette, une consigne noindex laissée en place au passage en production. La surveillance après bascule suit ensuite les mêmes objets, sur un pas hebdomadaire, jusqu’à retour au niveau antérieur.
Cas observé en refonte
Erreur observée. Sur la refonte d’un site vitrine de prestations, aucune URL ne changeait. Il n’y avait donc ni table de correspondance à établir, ni plan de redirections, et un contrôle des codes HTTP page par page ne montrait rien : toutes les pages répondaient 200 avant comme après. L’extension SEO a pourtant été remplacée pendant l’opération, et les titres et méta descriptions qu’elle stockait dans ses propres champs sont partis avec elle. Le site est resté entièrement accessible, avec des titres reconstruits par défaut à partir du nom des pages. Le contrôle qui aurait attrapé la perte n’est pas celui des URL mais la lecture du titre réellement servi dans le HTML, relevée avant la bascule et rejouée après. Enseignement transposable : une refonte sans changement d’URL n’est pas une migration à faible risque, c’est une migration dont les contrôles usuels sont aveugles.
Faire expliquer ce terme par une IA
Ouvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
Sources
- 1Google Search Central, Site moves with URL changes : les cinq étapes et le rythme selon la taille
- 2Google Search Central, Site moves without URL changes : TTL DNS et surveillance
- 3Google Search Central, Redirects and Google Search : codes, méthodes et canonicité
- 4Aide Search Console, Outil de changement d’adresse : périmètre et durée de 180 jours
- 5Google Search Central, HTTP status codes : limite de 10 sauts de redirection
Questions fréquentes
Combien de temps garder les redirections après une migration ?−
Au moins 180 jours selon l’aide Search Console, plus longtemps tant que Google Search y envoie du trafic, et si possible au moins un an. Ce délai laisse à Google le temps de réexplorer et de réattribuer les liens externes qui pointent encore vers les anciennes URL.
Faut-il migrer toutes les URL en une fois ?+
Pour un site de petite ou moyenne taille, oui : Google recommande de déplacer toutes les URL simultanément plutôt que section par section. Pour un grand site, la migration par sections successives reste possible et permet de repérer les problèmes plus tôt.
L’outil de changement d’adresse sert-il pour un passage en HTTPS ?+
Non. L’aide Search Console limite son usage au passage d’un domaine ou d’un sous-domaine à un autre. HTTP vers HTTPS, www vers sans www et les changements de chemins sur le même domaine n’entrent pas dans son périmètre.
Quel code de redirection utiliser pour une migration ?+
Une redirection permanente côté serveur, 301 ou 308. Google la lit comme un signal que la cible doit devenir l’URL canonique. Les codes 302, 303 et 307 sont suivis mais ne transfèrent pas la canonicité.
Combien de temps avant de revoir ses positions ?+
Google annonce quelques semaines ou davantage pour un site de petite ou moyenne taille avant de commencer à montrer progressivement les nouvelles URL. Un grand site demande plus longtemps, sans durée chiffrée.
Une refonte sans changement d’URL est-elle une migration ?+
Elle n’entre dans aucun des deux guides de Google, mais elle en présente le risque principal. Comme les URL ne bougent pas, les contrôles de migration ne détectent rien : les pertes portent sur les balises, les directives d’indexation et le contenu, pas sur les adresses.
Damien Hernandez
Consultant SEO senior, 17 ans d’expérience (Accor, Louvre Hotels, Infopro Digital). Spécialiste SEO technique, analyse de logs et optimisation pour les moteurs génératifs (GEO).