Checklist de migration SEO : avant, pendant et après une refonte

La checklist d'une migration SEO tient en trois temps : avant la refonte, inventorier toutes les URL et associer chacune à sa nouvelle adresse ; le jour de la bascule, activer des redirections 301 directes et lever les blocages de préproduction ; ensuite, suivre l'indexation et le trafic dans la Search Console, en gardant les redirections au moins un an.

La liste de vérification qui suit reprend la documentation de Google sur les migrations de sites, mise à jour le 11 septembre 2026, et l'aide de la Search Console. Elle vaut pour une refonte, un changement de CMS, de domaine ou de protocole.

Quel type de migration préparez-vous ?

Pour Google, la question décisive est simple : les adresses des pages changent-elles ? Une refonte qui reprend l'existant sans le casser peut garder toutes ses URL, ou toutes les modifier.

Une refonte qui garde ses adresses mérite les mêmes contrôles de contenu. Un modèle de page qui perd sa balise title, son texte principal ou ses données structurées change ce que Google indexe, même si l'URL reste identique.

Le changement d'hébergeur seul a sa propre page dans la documentation de Google. Pour un transfert d'hébergement sans changement d'adresse, Google conseille d'abaisser la durée de vie (TTL) des enregistrements DNS à quelques heures au moins une semaine avant, puis de garder l'ancien serveur tant que ses journaux montrent du trafic.

Avant la bascule : préparer la correspondance des URL

Tout se décide ici : le jour de la bascule ne fait qu'appliquer ce qui a été préparé.

Inventorier toutes les adresses

Google cite quatre sources pour retrouver les anciennes URL : les sitemaps, les journaux du serveur, l'outil de mesure d'audience et les données de liens de la Search Console. Le menu du site n'en montre qu'une partie. Ajoutez les images et les documents PDF hébergés sur le site, que Google demande aussi de transférer.

Gardez à part la liste des sites qui pointent vers vos pages. Après la bascule, Google conseille de leur demander de mettre à jour leurs liens.

Relever l'état de départ

Exportez, page par page, les clics, les impressions, le taux de clics et la position moyenne depuis le rapport sur les performances de la Search Console. Notez aussi le nombre de pages indexées dans le rapport sur l'indexation des pages. Sans cet état de départ, personne ne pourra dire honnêtement ce que la migration a changé.

Construire le fichier de correspondance

Un tableur suffit : une colonne pour l'ancienne URL, une pour la nouvelle, une pour le statut prévu. Trois règles le guident.

1. Une ancienne page, une page équivalente. Chaque URL qui a un équivalent redirige vers lui, directement.
2. Pas d'équivalent, pas de redirection. Google demande que les contenus supprimés renvoient un code 404 ou 410 sur le nouveau site.
3. Jamais tout vers l'accueil. Google prévient que rediriger de nombreuses anciennes URL vers une seule destination sans rapport, comme la page d'accueil, peut dérouter les visiteurs et être traité comme une erreur soft 404.

Quand plusieurs anciennes pages sont fusionnées en une seule, elles peuvent toutes rediriger vers cette page, puisqu'elle reprend leur contenu. Les règles de redirection s'écrivent ensuite dans le serveur ou le CMS, à partir de ce fichier.

Préparer la nouvelle version en préproduction

1. Balise canonical. Google demande que chaque nouvelle URL porte une balise rel="canonical" qui pointe vers elle-même.
2. Liens internes. Ils doivent viser les nouvelles URL, pas les anciennes : Google rappelle que les redirections ralentissent les visiteurs.
3. Balises hreflang. Sur un site multilingue, elles doivent être mises à jour avec les nouvelles adresses.
4. Balises et données structurées. Title, meta description, titre principal et données structurées sont repris ou améliorés, puis contrôlés avec le test des résultats enrichis de Google.
5. Robots.txt et noindex. Le robots.txt du nouveau site ne doit bloquer que ce qui doit l'être. Si la préproduction utilise des règles noindex, Google conseille de préparer la liste des URL où elles seront retirées.
6. Capacité du serveur. Après une migration, Google explore temporairement le nouveau site plus intensément que d'habitude.
7. Search Console. Validez toutes les variantes de l'ancien et du nouveau site : avec et sans www, en HTTP et en HTTPS.
8. Deux sitemaps. L'un liste les anciennes URL, l'autre les nouvelles.

Checklist du jour de la bascule

1. Activer les redirections en même temps que le nouveau site, côté serveur et permanentes : Google recommande les codes 301 ou 308, et réserve les redirections côté navigateur aux cas où rien d'autre n'est possible.
2. Retirer les règles noindex et les blocages robots.txt qui ne servaient qu'à la préproduction.
3. Tester les redirections. Google cite l'outil d'inspection d'URL pour quelques adresses, et des scripts ou la ligne de commande pour les tester en nombre. Rejouez le fichier de correspondance en entier : code de réponse, destination finale, nombre de redirections traversées.
4. Envoyer les deux sitemaps dans la Search Console. Au début, celui des nouvelles URL n'a aucune page indexée et celui des anciennes en a beaucoup : c'est l'état de départ que décrit Google.
5. Changement de domaine uniquement : déclarer le changement d'adresse dans la propriété de l'ancien site. L'outil exige d'être propriétaire des deux propriétés dans la Search Console et une redirection 301 de l'ancienne page d'accueil vers la nouvelle.
6. Rejouer les parcours qui rapportent : formulaire de contact, panier, paiement, création de compte. Une migration propre côté Google ne compense pas un formulaire qui ne part plus.

Après la bascule : le calendrier de contrôle

Google prévient que le classement peut fluctuer pendant une migration, et que pour un site de taille moyenne, il peut s'écouler quelques semaines ou plus avant que les nouvelles URL apparaissent progressivement. Voici le calendrier de contrôle que nous appliquons.

Le rapport sur l'indexation des pages permet de filtrer par sitemap : on y voit les anciennes URL sortir de l'index pendant que les nouvelles y entrent. Si des pages importantes disparaissent sans être remplacées, la méthode pour diagnostiquer un site que Google n'indexe plus prend le relais.

Les pièges qui coûtent du trafic

1. Les redirections en chaîne. Googlebot peut suivre jusqu'à 10 redirections successives, mais Google conseille de rediriger directement vers la destination finale. Une chaîne apparaît par exemple quand les règles d'une refonte précédente n'ont pas été mises à jour.
2. Les redirections temporaires. Avec une redirection permanente (301, 308), Google affiche la nouvelle adresse dans ses résultats. Avec une redirection temporaire (302, 303, 307), il affiche la page source.
3. Le noindex de préproduction resté en ligne. Une seule balise oubliée dans un modèle de page suffit à exclure toutes les pages qui l'utilisent.
4. Les redirections retirées trop tôt. Google demande de les conserver aussi longtemps que possible, généralement au moins un an, le temps de transférer les signaux vers les nouvelles URL.
5. La migration d'un petit site par morceaux. Pour les sites petits ou moyens, Google recommande de migrer toutes les URL en même temps. Google ne présente le découpage par section que comme une option pour les gros sites.
6. L'outil de changement d'adresse utilisé à tort. Il ne sert ni au passage en HTTPS, ni au passage de www à sans www, ni au déplacement de pages dans un même domaine.

Questions fréquentes

Combien de temps garder les redirections après une migration ?

Au moins un an selon Google, qui conseille de les conserver aussi longtemps que possible, et même indéfiniment du point de vue des visiteurs. Pour un changement de domaine déclaré dans l'outil de changement d'adresse, l'aide de la Search Console demande de les garder au moins 180 jours, voire plus.

Une baisse de trafic après une migration est-elle normale ?

Une fluctuation temporaire, oui : Google l'annonce dans sa documentation. Une chute nette et durable sur des pages précises n'est pas une fluctuation. Commencez par rejouer les redirections de ces pages et par vérifier qu'elles ne portent pas de règle noindex.

Faut-il utiliser l'outil de changement d'adresse pour passer en HTTPS ?

Non. Google le réserve aux changements de domaine ou de sous-domaine. Le passage de HTTP à HTTPS se traite par des redirections permanentes de chaque adresse et par des balises canonical à jour.

Combien coûte une migration SEO ?

Chez CZSyn, une migration SEO démarre à 990 € HT et comprend l'inventaire des URL, la table de correspondance, les redirections 301 testées une à une et le suivi. Le montant exact est fixé au devis, selon le site.

CZSyn est une agence web basée à Marseille. Elle conçoit, développe et maintient des sites internet, des boutiques en ligne, des applications web et mobiles et des logiciels sur mesure pour les TPE et PME de toute la francophonie, et dépanne les sites 24 h/24, 7 j/7.

Vous préparez une refonte ? Envoyez-nous l'adresse du site actuel : le pré-audit est offert, il relève l'indexation et les erreurs bloquantes, et vous recevez le devis de la migration avec.

Sources

1. Google Search Central, « Migrer un site » (migrations de sites avec changement d'URL), mise à jour 2026, developers.google.com.
2. Google Search Central, « Changement d'hébergement », 2025, developers.google.com.
3. Google Search Central, « La recherche Google et les redirections d'URL », 2026, developers.google.com.
4. Aide Search Console, « Outil Changement d'adresse », 2026, support.google.com.
5. Aide Search Console, « Rapport sur l'indexation des pages », 2026, support.google.com.
6. Aide Search Console, « Rapport sur les performances (résultats de la Recherche) : vue d'ensemble et configuration de base », 2026, support.google.com.

Nous développons ce type de projet : voir nos réalisations et notre offre de développement web fullstack.