Pourquoi Google insiste-t-il pour isoler les migrations de site de toute autre refonte ?

Pourquoi Google met-il tant l'accent sur l'isolation des changements ?

La logique est celle du diagnostic médical : si vous changez dix variables en même temps et que le patient meurt, bonne chance pour identifier la cause. Une migration de site déplace des milliers d'URLs d'un domaine A vers un domaine B. Chaque URL doit être redirigée individuellement vers sa nouvelle adresse.

Si, dans le même temps, vous modifiez votre arborescence, refondez vos templates, changez votre CMS et réécrivez tous vos contenus, vous créez un brouillard total. Quand le trafic organique plonge de 40 %, vous ne saurez jamais si c'est à cause d'une redirection cassée, d'un crawl budget explosé, d'un maillage interne dévasté ou d'un temps de chargement multiplié par trois.

Qu'est-ce qu'une migration de site au sens strict ?

Google parle ici de migration d'URLs : passage de domaine-a.com vers domaine-b.com, ou de HTTP vers HTTPS, ou d'une structure /categorie/produit/ vers /produit/. L'objectif est de faire comprendre aux crawlers que la page X est maintenant accessible à l'adresse Y, et non plus à l'adresse X.

Techniquement, cela repose sur des redirections 301 permanentes (ou 308 pour les requêtes POST, mais c'est anecdotique en SEO). Chaque ancienne URL doit pointer vers une nouvelle URL équivalente en termes de contenu et d'intention utilisateur. Pas de redirection générique vers la homepage, pas de chaînage de redirections, pas d'approximation.

• Mapping exhaustif : liste complète avant/après de toutes les URLs indexées (crawl Screaming Frog, export Search Console)
• Redirections 1-to-1 : chaque ancienne page redirige vers son équivalent exact, pas vers une catégorie parente ou la homepage
• Monitoring post-migration : vérification quotidienne des codes HTTP, des erreurs 404, du trafic organique par landing page
• Déclaration de changement d'adresse : si migration de domaine, outil dédié dans Google Search Console

Concrètement, quels autres changements faut-il éviter ?

Tout ce qui modifie autre chose que l'URL. Une refonte graphique change les templates, le DOM, les balises sémantiques, le poids des pages, les temps de chargement. Une réarchitecture de contenu modifie la profondeur de crawl, le maillage interne, la distribution du jus de lien. Un changement de CMS transforme la gestion des balises meta, des canonical, du sitemap, du robots.txt.

Chacun de ces chantiers a un impact SEO propre. Si vous les empilez avec une migration d'URLs, vous ne pourrez jamais isoler la cause d'une dégradation. Google ne dit pas que ces projets sont interdits — il dit qu'il faut les séquencer. Migrez d'abord, stabilisez les positions pendant 2-3 mois, puis lancez la refonte.

Cette recommandation est-elle réaliste dans un contexte d'entreprise ?

Soyons honnêtes : en théorie, c'est parfaitement sensé. En pratique, c'est rarement respecté. Les directions marketing et IT synchronisent souvent refonte, changement de plateforme et migration de domaine pour des raisons budgétaires ou politiques. Vendre en interne trois projets séquencés sur 18 mois est infiniment plus difficile que de vendre un seul « grand chantier digital ».

Le problème, c'est que cette réalité organisationnelle ne change rien aux lois techniques. Quand une migration groupée échoue — et statistiquement, elles échouent plus souvent — l'équipe SEO passe six mois à jouer aux détectives sans jamais identifier la vraie cause. Le trafic ne remonte jamais complètement, et la direction conclut que « le SEO ne marche plus ».

Quels sont les cas où l'isolation est techniquement impossible ?

Un changement de CMS force souvent une modification d'architecture. Passer de Magento à Shopify, par exemple, impose une nouvelle gestion des URLs produit, des filtres, des variantes. Dans ce cas, l'isolation pure est illusoire — mais vous pouvez au moins documenter chaque variable. Créez un mapping détaillé des modifications : URLs, templates, balises, vitesse, maillage.

Vous ne pourrez pas séparer les impacts, mais vous pourrez les hiérarchiser. Si 90 % de vos redirections fonctionnent correctement mais que les fiches produit perdent 50 % de trafic, le problème est probablement dans les nouveaux templates Shopify (balises manquantes, temps de chargement, balisage schema.org dégradé), pas dans les redirections elles-mêmes.

Quelle est la principale erreur observée sur le terrain ?

Le mapping approximatif. Les équipes projet créent un fichier Excel avec « anciennes URLs / nouvelles URLs », mais ce fichier ne couvre que 60 % du site. Le reste est géré « en règle générique » via des regex dans le .htaccess ou le serveur. Résultat : des milliers de pages redirigent vers des destinations incorrectes, ou vers des 404.

Deuxième erreur classique : ne pas tester les redirections avant la bascule. Vous pouvez parfaitement déployer votre nouveau site sur un domaine de staging, configurer toutes les redirections, puis tester avec un crawl Screaming Frog en simulant le domaine de production (réécriture dans le fichier hosts). Si vous découvrez des problèmes après la mise en production, il est souvent trop tard pour réagir proprement.

Que faut-il faire avant de lancer une migration de site ?

D'abord, crawler l'ancien site dans son intégralité. Screaming Frog, Oncrawl, Botify — peu importe l'outil, mais vous devez avoir la liste exacte de toutes les URLs indexées ou indexables. Ensuite, comparez cette liste avec les données Search Console (URLs ayant généré du trafic organique sur les 16 derniers mois). Certaines pages mortes dans le crawl peuvent encore avoir des backlinks puissants ou du trafic résiduel.

Créez ensuite un mapping 1-to-1 : chaque ancienne URL doit avoir une destination précise sur le nouveau site. Si une page disparaît sans équivalent, redirigez vers la catégorie parente la plus pertinente — jamais vers la homepage. Documentez chaque exception, chaque choix de regroupement. Ce fichier sera votre bible post-migration.

• Crawler l'ancien site (Screaming Frog, Oncrawl) pour obtenir la liste complète des URLs
• Exporter les données Search Console (trafic, impressions, clics par URL sur 16 mois)
• Créer un fichier de mapping avant/après avec une ligne par URL (pas de regex générique sans vérification manuelle)
• Tester les redirections sur un environnement de staging avant la mise en production
• Configurer les outils de monitoring : uptime, codes HTTP, trafic organique par landing page
• Déclarer le changement d'adresse dans Google Search Console (si migration de domaine)
• Vérifier que les sitemaps XML pointent vers les nouvelles URLs, pas les anciennes
• Conserver l'ancien site accessible (sans indexation) pendant au moins 6 mois pour comparaison

Quelles erreurs éviter absolument pendant la migration ?

Ne jamais bloquer le crawl de l'ancien site avec un robots.txt ou une balise noindex avant que Google ait eu le temps de découvrir toutes les redirections. Si vous désindexez l'ancien site trop vite, les crawlers ne passeront jamais par les redirections, et les nouvelles URLs mettront des mois à être indexées.

Évitez également les chaînes de redirections (A → B → C). Google suit jusqu'à 5 sauts, mais cela dilue le PageRank et ralentit le crawl. Chaque redirection doit pointer directement vers la destination finale. Et surtout, ne changez rien d'autre : pas de refonte des templates, pas de réécriture de contenus, pas de modification de l'arborescence au-delà de ce qu'impose la nouvelle structure d'URLs.

Comment monitorer efficacement après la migration ?

Installez des alertes automatiques sur les codes HTTP (hausse des 404, apparition de 500), le trafic organique global (baisse de plus de 10 % en semaine), et le nombre de pages indexées (chute brutale). Comparez quotidiennement les performances des nouvelles URLs avec celles des anciennes sur la même période l'année précédente.

Si une page perd 50 % de trafic post-migration, vérifiez d'abord la redirection (fonctionne-t-elle ? pointe-t-elle vers la bonne destination ?), puis le statut d'indexation de la nouvelle URL (est-elle dans l'index ? a-t-elle des erreurs dans Search Console ?). La plupart des problèmes se détectent dans les 7 premiers jours — mais certains impacts (dilution de PageRank, perte de positions sur longue traîne) mettent 2-3 mois à se stabiliser.