Faut-il vraiment supprimer l'ancien site après une migration SEO ?

Pourquoi Google insiste-t-il sur la suppression de l'ancien site ?

La position de Google est claire : l'ancien site doit disparaître une fois la migration bouclée. La raison invoquée ? Éviter que les utilisateurs tombent sur des contenus différents selon la version qu'ils consultent.

Cette recommandation vise surtout les cas où l'ancien domaine reste accessible, avec du contenu actif qui n'a pas été redirigé proprement. Le risque : un utilisateur atterrit sur l'ancienne version via un lien obsolète, trouve une info périmée, puis découvre une version contradictoire sur le nouveau site. Mauvaise expérience garantie.

Que signifie concrètement « nettoyer » l'ancien site ?

Nettoyer ne veut pas nécessairement dire effacer brutalement toutes les pages. Dans la pratique, cela implique de mettre en place des redirections 301 vers les nouvelles URLs correspondantes, puis de désactiver progressivement l'ancien environnement.

Si certaines pages de l'ancien site n'ont pas d'équivalent sur le nouveau — ce qui arrive fréquemment lors de refonte avec rationalisation du contenu — il faut décider : rediriger vers la page la plus proche sémantiquement, ou renvoyer un 410 Gone pour signaler la suppression définitive.

Quels sont les points essentiels à retenir ?

• L'ancien site ne doit pas coexister avec le nouveau de manière permanente
• Les redirections 301 doivent couvrir l'ensemble des URLs stratégiques
• Les informations contradictoires entre versions nuisent à l'expérience utilisateur
• Google peut être confus si les deux versions restent indexées simultanément
• Le nettoyage fait partie intégrante du processus de migration, pas une étape optionnelle

Cette recommandation est-elle vraiment nouvelle ?

Non. Tout professionnel SEO sait depuis des années qu'une migration propre implique de désactiver l'ancien site après transfert. Ce qui est intéressant ici, c'est l'angle choisi par Mueller : l'accent est mis sur la confusion utilisateur, pas sur les problématiques techniques SEO habituelles.

On aurait pu s'attendre à une justification centrée sur le duplicate content, la dilution du PageRank ou les signaux mixtes envoyés aux crawlers. Au lieu de ça, Google cadre la recommandation sous l'angle UX. Pragmatique, mais ça laisse certaines zones d'ombre sur les implications algorithmiques réelles.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Il existe des scénarios où maintenir temporairement l'ancien site fait sens. Par exemple, lors d'une migration progressive où seules certaines sections basculent en premier — une approche courante pour les sites complexes avec millions de pages.

Dans ces cas, l'ancien site reste partiellement actif pendant une phase de transition, avec des redirections sélectives. L'important : éviter que les deux versions d'une même page restent accessibles et indexées simultanément. Si vous devez garder l'ancien site temporairement, utilisez des canonicals, des noindex stratégiques, ou bloquez carrément l'indexation via robots.txt. [A vérifier] : Google ne précise pas combien de temps cette coexistence peut durer sans impact négatif.

Quelles nuances faut-il apporter pour les cas réels ?

La réalité terrain est plus complexe que « supprime l'ancien site ». Les grandes migrations impliquent souvent des environnements de staging accessibles par erreur, des sous-domaines oubliés, des versions mobiles séparées historiques, ou des sites multi-pays avec migrations décalées.

Le vrai risque n'est pas tant l'existence temporaire de l'ancien environnement, mais plutôt les liens internes cassés, les sitemaps non mis à jour, les balises hreflang pointant vers les anciennes URLs, ou les campagnes publicitaires qui renvoient encore vers l'ancienne version. C'est là que la « confusion » devient réellement problématique — pour Google comme pour les utilisateurs.

Que faut-il faire concrètement lors d'une migration ?

Première étape : mapper exhaustivement toutes les URLs de l'ancien site et leurs équivalents sur le nouveau. Pas juste les pages principales — toutes les URLs qui ont du trafic ou des backlinks. Utilisez vos logs serveur et votre historique Search Console pour identifier les pages réellement visitées.

Mettez ensuite en place des redirections 301 permanentes. Testez-les avant la bascule avec des outils comme Screaming Frog ou OnCrawl pour vérifier qu'aucune chaîne de redirections ne se crée (A→B→C) et qu'il n'y a pas de boucles.

Une fois la migration effective et les redirections validées en production, désactivez progressivement l'ancien environnement. Gardez les redirections actives — elles doivent rester en place au minimum un an, idéalement indéfiniment pour les URLs stratégiques.

Quelles erreurs éviter absolument ?

• Laisser l'ancien site actif sans redirections — Google indexe les deux versions et dilue vos signaux
• Rediriger toutes les pages vers la homepage du nouveau site — chaque URL doit pointer vers son équivalent sémantique
• Supprimer l'ancien site avant d'avoir vérifié que les redirections fonctionnent
• Oublier de mettre à jour les backlinks internes dans vos contenus
• Ne pas monitorer la Search Console pour détecter les erreurs 404 post-migration
• Négliger la mise à jour du sitemap XML qui doit pointer uniquement vers les nouvelles URLs

Comment vérifier que la migration est propre ?

Contrôlez que l'ancien domaine ne génère plus de trafic organique dans Analytics après quelques semaines. Si vous voyez encore des visites significatives, c'est qu'il reste des points d'entrée actifs — liens externes non mis à jour, vieilles campagnes, ou pages mal redirigées.

Utilisez la Search Console pour surveiller les erreurs d'exploration. Un pic de 404 post-migration est normal, mais il doit décroître rapidement. Si les erreurs persistent, identifiez les sources (backlinks cassés, sitemaps obsolètes) et corrigez.

Lancez un crawl complet du nouveau site pour vérifier qu'aucun lien interne ne pointe vers l'ancien domaine. C'est un détail souvent négligé qui crée des redirections inutiles et ralentit le crawl.