Migration SEO : la checklist pour ne pas perdre votre trafic

Pour réussir une migration SEO sans perdre votre trafic, chaque ancienne URL doit renvoyer directement vers sa nouvelle équivalente par une redirection permanente côté serveur (301 ou 308). Gardez les contenus, levez les blocages de la préproduction au lancement et passez canonical, hreflang, liens internes et sitemap sur les nouvelles adresses. Conservez ensuite les redirections au moins un an et suivez la Search Console pendant des semaines. Nous illustrons chaque étape avec notre propre site : en octobre 2026, nous avons changé 35 de nos URL et relevé les réponses du serveur et de Google.

Migration ou refonte : ce qui se passe pour Google

Une refonte peut signifier un nouveau design, un nouveau CMS, un nouveau domaine, le passage au HTTPS, de nouvelles URL ou des contenus réécrits. Pour le référencement, un nouveau design sur les mêmes URL est un petit changement ; une nouvelle structure d'URL est une migration.

Le guide de Google « Migrer un site » décrit la suite : Googlebot doit accéder au moins une fois à toutes les anciennes et nouvelles URL, et la migration se fait une URL après l'autre. Les signaux, comme les liens, passent par les redirections, et Google précise que les redirections 301 et autres redirections permanentes n'entraînent pas de baisse du PageRank. Ses trois règles de base : une seule modification à la fois (d'abord le domaine, ensuite la mise en page), une période de faible trafic, et des fluctuations de classement à prévoir pendant que Google réexplore le site.

Notre propre cas : 35 URL changées en deux jours

Polytested est devenu indexable le 13 octobre 2026 ; quelques heures plus tard, nous avons renommé la page de l'auteur. Le 14 octobre, nos neuf guides en allemand ont reçu des slugs plus longs et plus descriptifs le jour même de leur mise en ligne, puis nos 25 guides en anglais, environ un jour après le lancement. Aucune de nos adresses en français n'a changé.

Le 17 octobre, les 35 anciennes URL répondaient toutes par une 308 vers la bonne adresse, et toutes les nouvelles adresses répondaient 200. Nos limites : ces anciennes URL n'avaient que quelques heures ou un jour, presque sans liens. Nous montrons la mécanique et les premiers jours dans la Search Console, pas un effet durable sur le classement. Nous avons changé ces adresses tôt exprès : plus une URL vieillit, plus elle accumule de liens et de signaux.

Étape 1 : recenser toutes les anciennes URL

On ne redirige que les adresses que l'on connaît, et aucune source n'est complète. Google conseille de croiser :

• les sitemaps XML de l'ancien site ;
• les journaux du serveur, sur une période qui couvre les pages saisonnières ;
• votre outil d'analyse d'audience, pour les pages les plus visitées ;
• le rapport sur les liens de la Search Console (tableaux limités à 1 000 lignes) ;
• votre CMS ;
• une exploration de l'ancien site : la version gratuite de Screaming Frog SEO Spider va jusqu'à 500 URL.

Google cite aussi les images, les vidéos et les fichiers JavaScript et CSS, et les PDF peuvent avoir leur propre trafic. Sauvegardez enfin l'état de départ : clics, impressions et position par page dans le rapport sur les performances, titres et meta descriptions. Sans ces chiffres, impossible de savoir ensuite quelle page a perdu du trafic.

Étape 2 : construire le plan de redirection

Le plan de redirection tient en deux colonnes, ancienne et nouvelle URL, avec quelques règles :

1. Une pour une : chaque ancienne page pointe vers la nouvelle page équivalente ; des pages fusionnées pointent vers la page commune.
2. Supprimée : sans équivalent, l'ancienne URL renvoie 404 ou 410. Google traite toutes les erreurs 4xx de la même manière, sauf la 429.
3. Pas tout vers l'accueil : Google déconseille les redirections en masse vers une même destination sans rapport, qui peuvent être traitées comme des erreurs « soft 404 ».
4. Directement vers la cible : chaque règle vise l'URL finale, jamais une adresse qui redirige à nouveau.

Chez nous, le plan vit dans le fichier next.config.ts du site : une paire ancien slug, nouveau slug par ligne, chacune déclarée permanente. Ces règles sont datées et versionnées, mais elles ne passent en ligne qu'avec un déploiement ; un slug modifié seulement dans le CMS aurait renvoyé une 404 entre-temps. Vérifiez si votre CMS crée lui-même les redirections.

301, 308, 302 ou 307 : quelle redirection choisir ?

Avec une redirection permanente, Google affiche la nouvelle cible dans ses résultats ; avec une temporaire, la page source.

Pour une migration, c'est donc 301 ou 308. La différence se joue hors référencement : selon la norme HTTP RFC 9110, un client peut transformer une requête POST en GET après une 301 ou une 302, pas après une 307 ou une 308. C'est pourquoi Next.js, qui fait tourner notre site, utilise la 308. Les redirections JavaScript restent un dernier recours.

Méfiez-vous des réglages par défaut : sous Apache, une directive Redirect sans statut donne une 302 ; dans Next.js, permanent: false donne une 307 ; et beaucoup d'hébergeurs laissent choisir le code d'une redirection de domaine dans leur interface. Bing recommande la 301 pour un déplacement permanent et la 302 seulement pour un changement de moins de deux jours.

Bloquer la préproduction sans saboter le lancement

Le nouveau site se construit en général sur un environnement de préproduction qui doit rester hors des résultats. Sur trois verrous courants, deux sont fiables :

• Le robots.txt ne suffit pas. Selon Google, il ne sert pas à empêcher une page de figurer dans ses résultats ; une URL bloquée peut être indexée si d'autres pages pointent vers elle.
• Le noindex ne fonctionne que si Google peut explorer la page, en balise meta ou en en-tête X-Robots-Tag. Derrière un blocage robots.txt, il reste invisible.
• Un mot de passe est le verrou le plus sûr.

Le vrai risque, c'est le déverrouillage. Un noindex ou un Disallow: / oublié au lancement fait disparaître le nouveau site, et Google place ces restes en tête de son tableau des erreurs fréquentes de migration. Préparez donc le robots.txt du lancement et la liste des noindex à retirer.

Nous avons utilisé un seul interrupteur. Jusqu'au lancement, chaque réponse portait l'en-tête X-Robots-Tag: noindex, nofollow, et le robots.txt autorisait l'exploration sans annoncer le sitemap : Google voyait la règle noindex. Le jour du lancement, une variable d'environnement et une reconstruction du site ont supprimé l'en-tête et ajouté le sitemap, sans rien à retirer à la main.

Canonical, hreflang, liens internes et sitemap

Tout ce que Google lit sur le nouveau site doit pointer vers les nouvelles adresses :

• Canonical : chaque nouvelle page pointe vers elle-même, pas vers son ancienne adresse (voir notre guide sur la balise canonical).
• hreflang : toutes les versions linguistiques pointent vers les nouvelles URL, dans les deux sens, comme le précise le guide de Google. Quand nos URL anglaises ont changé, nos pages en allemand, en français et en espagnol devaient elles aussi viser les nouvelles adresses anglaises. Notre guide de la balise hreflang détaille le fonctionnement.
• Liens internes : directement vers les nouvelles URL ; chaque lien qui passe par une redirection coûte du temps de chargement et de l'exploration.
• Sitemap : uniquement les nouvelles URL canoniques.

Chez nous, les quatre ont basculé automatiquement, car ils sont générés à partir du CMS. Les liens internes sont enregistrés comme des références à la clé d'un article et reçoivent le slug actuel à l'affichage. Notre guide hreflang en français indique désormais les nouveaux slugs anglais et allemands, et le 17 octobre, ni notre sitemap anglais ni notre sitemap allemand ne contenait la moindre ancienne URL. Pour un site en plusieurs langues ou pays, notre guide du SEO international compare les structures d'URL.

Pour l'ancien sitemap, Google décrit l'envoi d'un sitemap des anciennes URL à côté du nouveau pendant un temps, pour voir ses pages indexées tomber à zéro, tandis que Bing demande de retirer vite les URL redirigées des sitemaps. Notre conseil : un sitemap public avec les seules nouvelles URL, et un sitemap des anciennes dans la Search Console uniquement de façon temporaire, comme instrument de mesure.

Tester les redirections : curl, navigateur et crawler

Le plus fiable reste la réponse brute du serveur. L'outil en ligne de commande curl est préinstallé sous Windows 11 et macOS, et sur la plupart des systèmes Linux :

# Code d'état et en-tête Location de la première réponse
curl -sI https://exemple.fr/ancienne-page

# Suivre toute la chaîne et afficher les en-têtes de chaque saut
curl -sIL https://exemple.fr/ancienne-page

# Une ligne par URL : code d'état et cible, pratique pour une liste
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://exemple.fr/ancienne-page

Sous Windows, écrivez NUL au lieu de /dev/null ; dans Windows PowerShell 5.1, tapez curl.exe, car curl tout court y désigne l'applet Invoke-WebRequest.

Testez aussi les variantes par lesquelles arrivent visiteurs et robots (http, www, majuscules) : c'est là que se cachent les sauts en trop. Voici notre rubrique SEO en français appelée ainsi :

Notre site renvoie toute URL contenant des majuscules vers sa version en minuscules, pour que /Blog et /blog ne servent pas deux copies de la même page. Une ancienne URL de nos guides anglais se comporte de la même façon : un saut quand on l'appelle directement en https, deux en http, trois en http avec www.

Googlebot suit jusqu'à 10 sauts, mais Google recommande de rediriger directement vers la destination finale, sinon idéalement pas plus de 3 sauts, et moins de 5 au pire. Empilez les redirections d'une migration sur d'anciennes redirections de protocole et de domaine, et la limite arrive vite. Les règles peuvent aussi jouer en votre faveur : /Blog/SRT-File atteint le nouveau slug en un seul saut, car la règle de l'ancien slug s'applique d'abord. Seul un test le montre.

Le navigateur, en revanche, est un mauvais outil de test. D'après la documentation de Next.js, une 308 demande aux clients de garder la redirection en cache pour toujours ; nos redirections envoient Cache-Control: public, max-age=0, must-revalidate, mais testez quand même avec curl. Et une fois que Chrome sait qu'un site utilise HSTS, comme le nôtre, il passe lui-même les liens http en https : lors de notre vérification du 14 octobre 2026, son journal réseau affichait « 307 Internal Redirect » pour HSTS, alors que notre serveur n'a jamais envoyé de 307.

Pour beaucoup d'URL, faites tourner curl sur un fichier texte des anciennes adresses ou utilisez le mode liste d'un crawler. Cherchez toute 302 ou 307 qui devrait être permanente, toute 404 qui devrait rediriger et toute chaîne en https. L'outil d'inspection d'URL convient mal : son aide indique que le test en ligne suit les redirections sans le signaler, alors qu'une autre page de Google affirme que les outils d'inspection ne les suivent pas.

Après le lancement : la Search Console et des délais réalistes

Trois rapports montrent si la migration avance :

• Indexation des pages : « Page avec redirection » est l'état attendu pour les anciennes URL. Surveillez « Introuvable (404) » pour des pages qui ont seulement déménagé, « Erreur "soft 404" » (souvent une redirection vers l'accueil), « Erreur liée à des redirections » (chaîne trop longue, boucle, URL incorrecte) et, sur les nouvelles pages, « URL bloquée par le fichier robots.txt » ou « URL marquée "noindex" ».
• Statistiques sur l'exploration (paramètres de la propriété) : une 308 compte comme « Déplacement permanent (301) », une 307 comme « Déplacement temporaire (302) », et chaque saut comme une demande distincte. Si la part des redirections temporaires monte, un mauvais réglage est actif.
• Sitemaps : URL envoyées et indexées, sitemap par sitemap.

Nos propres données montrent à quel point le mouvement est progressif :

Google n'avait presque pas vu les anciennes URL allemandes, et les neuf nouvelles étaient indexées deux jours plus tard. Beaucoup d'URL anglaises étaient déjà indexées sous leur ancienne adresse : deux jours après le changement, quatre nouvelles pages, dont notre guide sur les fichiers SRT, affichaient « Page en double : Google a choisi une autre URL canonique que l'utilisateur ». Ce n'est pas une erreur, c'est la migration URL par URL que décrit Google, et une bonne raison de changer ses adresses tôt.

Combien de temps faut-il ? Selon Google, quelques semaines pour la majorité des pages d'un site de petite à moyenne taille, davantage pour les grands sites, selon surtout le nombre d'URL et la rapidité du serveur. Dans une vidéo de 2022 rapportée par Search Engine Land, John Mueller, de Google, expliquait que le traitement complet d'un changement d'URL peut prendre plusieurs mois. Comptez en semaines pour l'essentiel, en mois pour le reste, et mesurez.

Durée des redirections et outil de changement d'adresse

Google est clair : « Conservez les redirections aussi longtemps que possible, généralement au moins un an. » Du point de vue des utilisateurs, il conseille même de les garder indéfiniment ; nos 35 redirections n'ont pas de date de fin. Deux moments les mettent en danger : la refonte suivante, quand plus personne ne sait à quoi servent les anciennes règles (documentez-les avec une date et une raison), et le nettoyage des chaînes. Si une deuxième migration crée une chaîne de A vers B puis C, faites pointer A directement vers C, sans jamais supprimer A.

L'outil de changement d'adresse de la Search Console ne sert qu'à passer d'un domaine ou sous-domaine à un autre, par exemple d'un .fr à un .com. Il n'est pas fait pour le passage au HTTPS, le déplacement de pages au sein d'un site ni le passage de www à sans www : notre cas n'en a pas besoin. Pour un vrai changement de domaine, faites la demande pour chaque variante validée de l'ancien domaine, www compris. La notification reste affichée 180 jours ; gardez les redirections au moins aussi longtemps, plus si elles amènent encore du trafic depuis Google, et payez l'ancien domaine au moins un an pour que personne ne le rachète à des fins malveillantes.

La checklist de migration SEO

Avant le lancement

1. Décidez de ce qui change, sans tout modifier en même temps.
2. Recensez toutes les anciennes URL, images et PDF compris, et sauvegardez l'état de départ.
3. Construisez le plan de redirection : une pour une, 404 ou 410 pour le supprimé, rien en masse vers l'accueil.
4. Choisissez la 301 ou la 308, côté serveur, directement vers l'URL finale ; vérifiez les réglages par défaut.
5. Verrouillez la préproduction (mot de passe ou noindex) et préparez le déverrouillage.
6. Contrôlez canonical, hreflang, liens internes et nouveau sitemap.
7. Validez toutes les variantes du site dans la Search Console et prévoyez la charge : Google explore davantage après une migration.

Le jour du lancement

8. Activez les redirections et levez les verrous en même temps.
9. Vérifiez le robots.txt : s'il renvoie une erreur serveur, Google cesse d'explorer le site pendant les 12 premières heures.
10. Testez chaque ancienne URL, variantes http et www comprises.
11. Envoyez le nouveau sitemap dans la Search Console et dans Bing Webmaster Tools.
12. Changement de domaine uniquement : demandez le changement d'adresse.
13. Mettez à jour vos propres liens et demandez aux sites qui vous envoient le plus de visites de corriger les leurs.

Après le lancement

14. Chaque semaine : indexation des pages, statistiques sur l'exploration, sitemaps ; corrigez les 404 et « soft 404 » des pages déplacées.
15. Résolvez les chaînes en visant directement l'URL finale.
16. Gardez les redirections au moins un an, idéalement pour toujours, et documentez-les.