Faut-il vraiment tout rediriger lors d'une migration de site ?

Pourquoi Google recommande-t-il de tout rediriger sans exception ?

La logique est simple : Google doit comprendre que l'ancien domaine est mort et que le nouveau le remplace intégralement. Si certaines pages restent actives sur l'ancien site, les crawlers vont continuer à les indexer et à distribuer le PageRank entre deux domaines.

Le résultat ? Une dilution du signal. Au lieu de transférer proprement l'autorité accumulée, vous fractionnez votre capital SEO. Google ne sait plus si l'ancien domaine est encore actif ou s'il doit basculer vers le nouveau. Cette ambiguïté ralentit — voire bloque — la migration dans Search Console.

Que se passe-t-il si on laisse trainer quelques pages orphelines ?

Les pages oubliées sur l'ancien domaine vont continuer à être crawlées. Google va perdre du temps et du budget de crawl à visiter des URLs qui n'ont plus lieu d'exister. Pendant ce temps, le nouveau site reçoit moins d'attention, et l'indexation des nouvelles pages prend du retard.

Pire encore : si ces pages orphelines génèrent encore du trafic ou des backlinks, vous créez une compétition interne. Les utilisateurs atterrissent sur l'ancien domaine, rebondissent, et Google interprète cela comme un signal négatif pour le nouveau site. Une situation absurde mais courante.

Comment éviter les oublis dans une migration complexe ?

La réponse tient en un mot : cartographie exhaustive. Avant de toucher à quoi que ce soit, extrayez la liste complète des URLs indexées via Search Console, votre sitemap XML, et un crawl complet avec Screaming Frog ou Botify. Croisez ces sources pour identifier les écarts.

Ensuite, établissez une matrice de redirection 1:1 entre ancien et nouveau domaine. Chaque URL source doit pointer vers une destination pertinente — pas vers la homepage par facilité. Si une page ancienne n'a pas d'équivalent direct, redirigez vers la catégorie parente ou la page la plus proche sémantiquement.

• Auditez l'intégralité des URLs indexées avant de migrer — pas seulement celles du sitemap
• Créez une table de correspondance entre ancien et nouveau domaine, validée manuellement
• Testez les redirections en staging avant de basculer en production
• Surveillez les erreurs 404 et les chaînes de redirections post-migration via Search Console
• Maintenez les redirections pendant au moins 12 mois pour laisser à Google le temps de tout transférer

Cette consigne est-elle aussi absolue qu'elle en a l'air ?

Sur le papier, oui. Dans la réalité, la complexité des sites réels impose parfois des compromis. Un site de plusieurs centaines de milliers de pages avec des sections obsolètes ou du duplicate massif ne mérite pas forcément que chaque URL orpheline soit redirigée.

Soyons honnêtes : toutes les pages n'ont pas la même valeur SEO. Une page sans backlink, sans trafic, sans indexation depuis des années n'apporte rien au transfert de PageRank. La rediriger vers une nouvelle URL peut même diluer la pertinence thématique si la correspondance est forcée. Dans ce cas, un 410 Gone ou un 404 peut être plus propre qu'une redirection artificielle.

Quels sont les risques d'une approche trop rigide ?

Premier écueil : les redirections inutiles gonflent la charge serveur et ralentissent le site. Un fichier .htaccess avec 50 000 règles de redirection peut devenir un cauchemar de maintenance et impacter les performances.

Deuxième écueil : rediriger massivement vers des pages non pertinentes envoie des signaux confus à Google. Si vous redirigez 500 anciennes fiches produits disparues vers une seule catégorie générique, vous créez un soft 404 déguisé. Google finit par ignorer ces redirections et les traite comme des erreurs. [A vérifier] : Google n'a jamais publié de seuil précis au-delà duquel une masse de redirections devient suspecte, mais les observations terrain montrent qu'un ratio supérieur à 20:1 (20 anciennes URLs vers 1 nouvelle) déclenche souvent une dévaluation.

Dans quels cas peut-on déroger à la règle du tout-rediriger ?

Cas numéro un : les pages zombies. Pages techniques sans contenu, URLs générées automatiquement par un CMS mal configuré, paramètres de session ou de tracking — autant de URLs indexées par erreur. Les rediriger n'a aucun sens. Mieux vaut les bloquer en robots.txt ou les renvoyer en 410.

Cas numéro deux : les contenus obsolètes ou non conformes. Une section de blog datant de 2008 avec des conseils SEO dépassés, des pages événementielles périmées, ou des produits retirés du marché. Si le nouveau site ne couvre plus ces thématiques, forcer une redirection crée une incohérence. Un 404 propre avec une page d'erreur bien designée est parfois plus honnête.

Que faut-il faire concrètement avant la bascule ?

Première étape : crawler l'ancien domaine de fond en comble. Pas seulement le sitemap XML — celui-ci ne reflète que ce que le CMS veut bien afficher. Utilisez Screaming Frog, Botify, ou Oncrawl pour extraire toutes les URLs découvertes, y compris celles sans lien interne.

Deuxième étape : croisez ce crawl avec les données Search Console. Exportez la liste des pages indexées et celle des pages recevant du trafic sur les 12 derniers mois. Vous allez découvrir des écarts — des pages indexées mais non crawlées, ou inversement. Ces anomalies doivent être résolues avant la migration.

Comment structurer le plan de redirection sans se perdre ?

La méthode qui tient la route : un tableau Excel ou Google Sheets avec trois colonnes minimum : URL source, URL destination, code HTTP (301 ou 410). Ajoutez des colonnes pour le trafic organique, le nombre de backlinks, et le statut de validation.

Ensuite, segmentez par type de contenu : articles de blog, fiches produits, pages catégories, pages institutionnelles. Chaque segment suit une logique de redirection différente. Les fiches produits doivent pointer vers leurs nouvelles versions ; les articles de blog peuvent être regroupés par thématique si la structure a changé.

Quelles erreurs éviter absolument post-migration ?

Erreur classique : les chaînes de redirections. Vous redirigez A vers B, puis B vers C. Google suit les chaînes, mais cela dilue le PageRank à chaque saut et ralentit le crawl. Vérifiez que chaque ancienne URL pointe directement vers sa destination finale.

Deuxième erreur : ne pas monitorer les 404 dans Search Console. Après la migration, consultez le rapport de couverture toutes les semaines. Chaque 404 signalé est une redirection manquée. Corrigez-les au fur et à mesure — ne laissez pas s'accumuler des centaines d'erreurs.

• Crawlez l'ancien domaine intégralement et extrayez toutes les URLs indexées
• Créez une matrice de redirection avec URL source, URL destination, et validation manuelle
• Testez les redirections en environnement de staging avant le go-live
• Activez la redirection de domaine dans Search Console dès la mise en ligne
• Surveillez les erreurs 404 et les chaînes de redirections pendant au moins 3 mois
• Maintenez les redirections actives pendant 12 à 18 mois pour laisser à Google le temps de tout transférer