Migrations de site

En bref — Une migration est un changement important qui peut déplacer vos URL ou modifier la manière dont Google lit votre site : nouveau domaine, HTTPS, nouvelle plateforme, réorganisation des dossiers ou refonte. Protégez le trafic avec une redirection 301 de chaque ancienne page vers sa nouvelle page équivalente, et conservez ces redirections longtemps. Une baisse temporaire est normale ; si elle persiste, quelque chose a probablement été mal implémenté.

Qu’est-ce qu’une migration de site ?

Une migration est toute modification significative susceptible d’affecter la découverte, l’exploration, l’indexation ou le classement des pages. Passer de http:// à https://, déplacer blog.example.com vers example.com/blog/, changer de CMS ou refaire les modèles tout en gardant les mêmes URL sont autant de migrations. Elles partagent les mêmes risques et la même méthode de travail.

La règle la plus importante

Lorsqu’une URL change, envoyez-la vers sa destination la plus proche au moyen d’une redirection permanente 301. Google indique que les redirections permanentes ne font pas perdre de PageRank. Preuve à l’appui de cette affirmation Google says 301 and other permanent redirects do not cause a loss in PageRank. Portée : Google Search handling of permanent redirects during site moves; this does not guarantee unchanged rankings after a migration. Niveau de confiance : élevé · Vérifié : 2026-07-14 Google Search Central: Site move with URL changes

Ne redirigez pas toutes les pages vers l’accueil. Sans équivalent réel, choisissez la catégorie pertinente ou renvoyez un vrai 404/410. Une destination sans rapport peut être traitée comme une soft 404.

Erreurs fréquentes

• Les redirections permanentes ne font pas perdre le « jus de lien ».
• L’outil Changement d’adresse informe Google ; il ne crée pas la migration.
• Une fluctuation de trafic pendant le retraitement est normale. Preuve à l’appui de cette affirmation Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Portée : Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Niveau de confiance : élevé · Vérifié : 2026-07-14 Google Search Central: Site move with URL changes
• Les redirections doivent rester en place bien au-delà de quelques mois.

Ne changez qu’une chose à la fois

Cumuler nouveau domaine, nouvelle plateforme et nouvelle structure d’URL multiplie les risques. Séparez ces changements lorsque c’est possible.

En bref — Risque = quantité de changement × nombre de changements simultanés. Les 301/308 constituent l’ossature de la migration ; les canonicals, hreflang, sitemaps, liens internes et l’outil Changement d’adresse renforcent le signal. Faites une correspondance ancienne→nouvelle URL en 1:1, évitez les chaînes et conservez les redirections. Une baisse durable révèle souvent un blocage de staging, un noindex, un canonical/hreflang supprimé ou une mauvaise destination.

Ce guide couvre la classification, les principes, le risque, les décisions par type et le diagnostic. Pour l’exécution détaillée, utilisez la liste de contrôle de migration.

Ce qu’est réellement une migration — et ses 7 types

Les numéros correspondent aux sections détaillées ci-dessous ; le tableau est classé par risque. Évitez de cumuler les changements.

Le processus universel de migration

Phase 1 — Planification

• Identifiez tous les types de migration concernés et leur risque cumulé.
• Prévenez la direction qu’une fluctuation temporaire est probable.
• Définissez un plan de retour arrière avec des critères précis.
• Lancez pendant une période de faible trafic, de préférence quand l’équipe est là.
• Nommez un responsable SEO et suivez toutes les dépendances.

Phase 2 — Mesures de référence et crawl de l’ancien site

Conservez un crawl complet avant le lancement : codes HTTP, titres, descriptions, canonicals, hreflang, titres de section, liens internes et Core Web Vitals. Sauvegardez les classements, les données GSC/GA4, les pages qui reçoivent des backlinks, les règles de redirection provenant du CMS, du CDN et du serveur, ainsi que les problèmes existants. Ce référentiel rend possible une comparaison après lancement.

Phase 3 — Correspondance des URL

Créez une table chaque ancienne URL → sa nouvelle URL la plus pertinente. Les pages supprimées avec un équivalent proche doivent y être redirigées ; celles sans équivalent doivent renvoyer 404 ou 410, jamais l’accueil.

Phase 4 — Stratégie de redirection

• Utilisez des 301 ou 308 côté serveur pour les déplacements permanents.
• Les redirections permanentes ne font pas perdre de PageRank. Preuve à l’appui de cette affirmation Google says 301 and other permanent redirects do not cause a loss in PageRank. Portée : Google Search handling of permanent redirects during site moves; this does not guarantee unchanged rankings after a migration. Niveau de confiance : élevé · Vérifié : 2026-07-14 Google Search Central: Site move with URL changes
• Faites pointer directement l’ancienne URL vers la destination finale. Google conseille au plus 3 redirections, et moins de 5.
• Redirigez aussi les images, PDF et autres ressources.
• Réservez 302/307 aux situations réellement temporaires.
• Conservez les redirections au moins un an, et idéalement tant que les anciennes URL reçoivent des liens ou du trafic. Preuve à l’appui de cette affirmation Google recommends keeping site-move redirects as long as possible, generally for at least one year. Portée : Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Niveau de confiance : élevé · Vérifié : 2026-07-14 Google Search Central: Site move with URL changes

Phase 5 — Staging et tests avant lancement

Bloquez l’indexation du staging, testez chaque redirection, comparez le crawl au référentiel, vérifiez canonicals, hreflang, données structurées, robots, liens et performances. Confirmez aussi GA4/GSC, les parcours de conversion et l’accès de Googlebot. Notez tous les blocages temporaires : ils doivent disparaître au lancement.

Phase 6 — Lancement

• Supprimez immédiatement tous les blocages de crawl et noindex de staging.
• Activez les redirections permanentes en même temps.
• Soumettez un sitemap de production contenant uniquement les nouvelles URL canoniques. Un sitemap d’anciennes URL, s’il aide le suivi, doit être distinct et temporaire. Voir le guide Google.
• Inspectez des URL dans GSC ; utilisez Changement d’adresse seulement pour un domaine entier et IndexNow pour Bing.
• Prévoyez la hausse temporaire du crawl sur le nouveau serveur.

Phase 7 — Suivi après lancement

Attendez-vous à une fluctuation temporaire. Un site moyen peut demander quelques semaines pour que la majorité des pages basculent dans l’index. Si la baisse persiste, contrôlez d’abord les redirections, les directives, hreflang, les canonicals et les liens internes. Recrawlez toutes les anciennes URL, observez la sélection canonique, les rapports GSC, les classements et les journaux serveur.

Mesurer l’effet des redirections sans se tromper

Comparez les mêmes cohortes à 7, 14, 30 et 90 jours, en excluant le jour du changement. Conservez les mêmes métriques et notez les autres événements : versions, campagnes, saisonnalité, mesure et mises à jour confirmées de Google. L’absence de changement peut être une réussite : le rôle d’une redirection est souvent de préserver les signaux et les conversions.

Les 7 types de migration

Type 1 — Changement de domaine ou de marque

Toutes les URL passent de oldbrand.com à newbrand.com. C’est le risque le plus élevé. Ne combinez pas domaine, refonte et structure d’URL ; vérifiez l’historique du nouveau domaine ; gardez l’ancien domaine et ses redirections ; n’enchaînez pas A→B→C.

L’outil Changement d’adresse agit pendant 180 jours, uniquement pour un déplacement strict 1:1 de domaine ou sous-domaine. Il exige des propriétés GSC admissibles et ne s’applique pas aux dossiers, fusions ou déplacements partiels. Consultez les conditions et les propriétés admissibles. Il est facultatif et ne remplace jamais les redirections, qui doivent durer plus longtemps que cette fenêtre.

Type 2 — HTTP → HTTPS

Le protocole change pour chaque URL. N’utilisez pas Changement d’adresse : faites des 301 URL par URL. Corrigez le contenu mixte, les certificats et les cookies Secure. Google préfère HTTPS sauf en présence de signaux contradictoires. Activez HSTS progressivement, une fois TLS fiable, en commençant par un max-age faible.

Type 3 — Changement de plateforme ou de CMS

Un changement de pile technique entraîne souvent des variations d’URL, de modèles, de liens et de rendu. Planifiez la correspondance avant de choisir la plateforme, recopiez toutes les anciennes règles, réimplémentez les données structurées, testez le rendu JavaScript, les performances mobiles, les slashs finaux, GA4 et GSC.

Type 4 — Restructuration des URL ou du site

Le domaine reste identique mais les chemins changent. Mettez à jour directement les liens internes, canonicals, navigation, pied de page, fil d’Ariane et sitemaps. Les anciens liens peuvent retarder la sélection de la nouvelle URL canonique. L’outil Changement d’adresse ne s’applique pas.

Type 5 — Refonte du site avec les mêmes URL

Le risque est plus faible, mais titres, descriptions, structure des titres, contenu, données structurées, liens internes et Core Web Vitals peuvent régresser. Comparez chaque modèle et la version mobile avec le référentiel avant/après.

Type 6 — Sous-domaine ↔ sous-dossier

Par exemple blog.example.com → example.com/blog/. Traitez chaque URL comme déplacée, utilisez des 301 directes, mettez à jour les liens et réconciliez les propriétés GSC ainsi que le suivi GA4. Changement d’adresse n’est pas le mécanisme d’un déplacement hôte/chemin au sein de la même racine.

Type 7 — Consolidation ou fusion de domaines

Réunir plusieurs sites est un projet à très haut risque, sans déplacement 1:1 global. Changement d’adresse ne fonctionne pas. Dédupliquez les contenus avant la fusion, choisissez une page canonique par sujet et redirigez chaque URL vers son véritable équivalent, jamais tout un domaine vers l’accueil. Surveillez chaque propriété GSC.

Choisir le guide spécialisé

• Migration d’hébergement — serveur, CDN ou DNS, URL stables.
• Migration de CMS — plateforme, modèles, rendu et parité des données.
• Migration de structure d’URL — chemins, taxonomie ou dossiers.
• Scission de site — déplacement d’une section vers une autre propriété.
• Intégration après acquisition — intégration des marques, sites et contenus acquis.
• Perte de trafic après migration — diagnostic d’une visibilité qui ne revient pas.

Place dans l’ensemble

Une migration touche les redirections, les canonicals, HTTPS, hreflang et parfois Changement d’adresse. Son ossature reste la même : correspondance 1:1, redirections permanentes, conservation de celles-ci et surveillance des bons signaux.

Résumé IA

• Le risque dépend de l’ampleur et du nombre de changements simultanés.
• Les 7 types vont de la refonte à URL stables jusqu’à la fusion de plusieurs domaines.
• Le processus : planifier → mesurer/crawler → faire la correspondance 1:1 → préparer les redirections → tester le staging → lancer → surveiller.
• Les 301/308 transmettent les signaux ; canonicals, liens, sitemaps et Changement d’adresse les complètent.
• Évitez les redirections vers l’accueil et les chaînes ; gardez les redirections durablement.
• Une fluctuation temporaire est attendue. Une baisse persistante exige un diagnostic.
• Changement d’adresse concerne seulement un domaine entier déplacé en 1:1, pas HTTPS, les chemins ou les fusions. Pour Bing, utilisez IndexNow.

Documentation officielle

Google

• Déplacement avec changement d’URL
• Déplacement sans changement d’URL
• Redirections et Google Search
• Outil Changement d’adresse
• Consolider les URL en double
• Canonicalisation
• Activer HTTPS

Bing / Microsoft

• Migration de site avec Bing
• IndexNow

Citations des sources

Déclarations officielles de Google, conservées dans leur langue originale pour ne pas altérer leur formulation :

• “301 and other permanent redirects don’t cause a loss in PageRank.” — source
• “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5” — source
• “Keep the redirects for as long as possible, generally at least 1 year.” — source
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page” — source
• “Expect temporary fluctuation in site ranking during the move.” — source
• “a medium-sized website can take a few weeks for most pages to move in our index” — source
• “Check your redirects from the old site to the new one. We frequently see people redirecting to the wrong (non-existent) URLs.” — source
• “Maintain the redirects for at least 180 days—longer if you still see any traffic to them from Google Search.” — source
• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” — source
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” — source
• “Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” — source
• “it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days.” — source
• Relisez aussi les exigences complètes de l’outil Changement d’adresse et les conseils de Bing sur les migrations.

Liste de contrôle principale

Avant : classer les types, nommer les responsables, fixer les seuils et le retour arrière, crawler l’ancien site, sauvegarder GSC/GA4/classements/backlinks/redirections, construire et réviser la table 1:1.

Staging : bloquer temporairement l’indexation, vérifier l’équivalence du contenu, tester redirections, canonicals, hreflang, robots, schéma, liens, mobile, vitesse, analytics et accès Googlebot.

Lancement : retirer les blocages, activer les 301/308, mettre à jour liens et sitemaps, soumettre les signaux admissibles, vérifier les URL prioritaires et la capacité serveur.

Après : recrawler l’inventaire complet, suivre indexation, canonicals, trafic, classements et journaux à 7/14/30/90 jours, corriger les chaînes et conserver les redirections ainsi que l’ancien domaine.

Contrôles propres à chaque type

• Domaine : historique propre, propriétés GSC, Changement d’adresse admissible.
• HTTPS : certificats, contenu mixte, HSTS progressif, aucun retour vers HTTP.
• CMS : parité des modèles, schéma, rendu JS, analytics et anciennes règles.
• Chemins : liens internes, canonicals, navigation et sitemaps mis à jour.
• Refonte : titres, contenu, maillage, données structurées et performances.
• Sous-domaine : propriétés et analytics réconciliés, liens directs.
• Fusion : déduplication, correspondances page par page, suivi de chaque domaine.

Modèles mentaux

1. Risque = ampleur × simultanéité. Séparez les changements indépendants.
2. Les redirections transportent ; les autres signaux confirment. Un sitemap ne répare pas une mauvaise 301.
3. L’équivalence prime sur la couverture. Une 404/410 vaut mieux qu’une redirection non pertinente vers l’accueil.
4. La migration est une expérience mesurée. Référentiel, cohortes fixes, checkpoints et événements parasites documentés.
5. Une baisse est un symptôme. Cherchez d’abord accessibilité, directives, correspondances, canonicals, liens, rendu et capacité.

Aide-mémoire de migration

Quel type de migration — et Changement d’adresse s’applique-t-il ?

Plan d’action : le trafic ne remonte pas après le lancement

1. Confirmez la baisse sur les mêmes pages, requêtes, marchés et définitions de mesure.
2. Vérifiez robots.txt, meta robots, X-Robots-Tag, authentification, pare-feu, DNS et codes HTTP ; retirez tout blocage de staging.
3. Retestez toute la table ancienne→nouvelle, en commençant par les pages les plus liées et fréquentées ; corrigez 404, boucles, chaînes et destinations non pertinentes.
4. Comparez au référentiel canonicals, hreflang, titres, contenu, schéma, liens et HTML rendu. Corrigez d’abord les défauts de modèle.
5. Vérifiez les URL auto-canoniques, les liens directs et les sitemaps de nouvelles URL.
6. Consultez Crawl Stats et les journaux pour détecter erreurs, lenteur ou limitation.
7. N’utilisez le retour arrière que pour une régression prouvée atteignant le seuil convenu, pas pour la volatilité normale du premier jour.

Mythes qui provoquent de vrais échecs

• « Les redirections permanentes perdent du PageRank. » Faux : le risque vient surtout d’une mauvaise destination, chaîne, boucle ou impasse.
• « Changement d’adresse déplace le site. » Faux : c’est un signal facultatif et limité ; les redirections font le travail.
• « Toute baisse prouve un échec. » Faux : mesurez et diagnostiquez la persistance au lieu de réagir à la fluctuation normale.
• « On peut supprimer les redirections après quelques mois. » Faux : les liens, favoris, bots et utilisateurs peuvent continuer à employer les anciennes URL.

Outils pour préparer et vérifier une migration

• Générateur de table de redirection — propose des correspondances, niveaux de confiance, URL sans équivalent, 410 et exports.
• Cartographie des chaînes de redirection — suit chaque saut et révèle les règles de protocole, hôte ou slash qui se cumulent.
• Vérificateur de redirection — contrôle rapidement une URL ou un petit lot ; un crawler reste nécessaire pour l’inventaire complet.
• Un crawler complet, Google Search Console et les journaux d’accès serveur complètent l’analyse du rendu, des signaux et du comportement des robots.

Prouver que la migration respecte la table approuvée

Test complet des anciennes URL

Crawler tout l’inventaire de phase 2. Chaque URL déplacée doit produire une seule 301/308 côté serveur vers l’équivalent prévu ; les suppressions doivent renvoyer le 404/410 planifié. Une boucle, chaîne, destination non pertinente ou 404 imprévu indique que la règle n’a pas été livrée correctement. Testez au lancement puis après correction. Inspectez les échecs avec la cartographie des chaînes ou le vérificateur de redirection.

Test d’indexabilité et de canonical

Les nouvelles pages doivent répondre 200, ne pas être bloquées ni noindex, et déclarer la nouvelle canonical attendue. Contrôlez des pages importantes dans Inspection d’URL. Un blocage global ou un canonical de staging peut justifier un retour arrière s’il ne peut pas être corrigé rapidement.

Test des liens et sitemaps

Les liens internes doivent viser directement les nouvelles URL et les sitemaps de production ne contenir que des URL canoniques valides. Un sitemap d’anciennes URL doit rester séparé, temporaire et associé à une condition de suppression.

Ressources utiles

Mes articles associés

• Une migration exige plus qu’une checklist
• Guide des redirections pour le SEO
• Peut-on supprimer les 301 après un an ?
• Guide de la canonicalisation
• Guide débutant du SEO technique

Sources officielles et complémentaires

• Déplacement avec changement d’URL
• Outil Changement d’adresse
• Migration avec Bing
• r/TechSEO
• Conseils de Mueller
• Le coût d’une migration bâclée
• 301 pour HTTP vers HTTPS
• Éviter les pièges d’un changement de domaine
• Activer HTTPS

Google recommande de conserver les redirections au moins un an. Preuve à l’appui de cette affirmation Google recommends keeping site-move redirects as long as possible, generally for at least one year. Portée : Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Niveau de confiance : élevé · Vérifié : 2026-07-14 Google Search Central: Site move with URL changes Une fluctuation temporaire et quelques semaines de retraitement sont normales. Preuve à l’appui de cette affirmation Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Portée : Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Niveau de confiance : élevé · Vérifié : 2026-07-14 Google Search Central: Site move with URL changes Changez une grande chose à la fois lorsque c’est possible. Preuve à l’appui de cette affirmation Google recommends changing one major thing at a time during a site move when possible. Portée : Google Search migration guidance intended to simplify diagnosis and processing; business constraints may require combined changes. Niveau de confiance : élevé · Vérifié : 2026-07-14 Google Search Central: Site move with URL changes

Testez vos connaissances : migrations de site