Pages non indexées après migration de site : guide de récupération complet
Ta migration de site s'est bien déroulée dans le navigateur, mais Google peine à reconnaître tes nouvelles URLs. Comprends la fenêtre critique de 90 jours et corrige les problèmes de redirection, de canonical et de vérification qui bloquent l'indexation après migration.
Dans ce guide
Les migrations de site sont parmi les opérations les plus risquées en SEO. Que tu déménages vers un nouveau domaine, changes ta structure d'URL, migres de HTTP à HTTPS, passes d'une plateforme CMS à une autre, ou consolides plusieurs sites en un seul, la migration perturbe fondamentalement la compréhension qu'a Google de ton site. Des pages indexées pendant des années peuvent soudainement disparaître des résultats de recherche. De nouvelles URLs censées remplacer les anciennes restent bloquées dans la file de crawl. Les classements chutent partout pendant que Google réévalue tout ton site dans sa nouvelle forme.
Les 90 premiers jours après une migration sont critiques. Pendant cette période, Google explore activement ton site, traite les redirections, évalue les nouvelles URLs et décide si la nouvelle structure du site mérite la même couverture d'indexation et les mêmes classements que l'ancienne. Les erreurs pendant cette fenêtre peuvent entraîner des mois de trafic perdu. Mais même les migrations bien exécutées connaissent communément des écarts d'indexation où certaines pages sur le nouveau site ne sont pas indexées tandis que leurs équivalents d'anciennes URLs ont été retirés de l'index.
Les problèmes d'indexation post-migration diffèrent des problèmes d'indexation normaux parce qu'ils impliquent une transition entre deux états. Google doit traiter simultanément la suppression des anciennes URLs et l'ajout des nouvelles, transférer l'autorité des anciennes pages vers les nouvelles via les redirections, et réconcilier sa compréhension existante du contenu de ton site avec la nouvelle structure. Cela crée des opportunités de confusion, de signaux perdus et d'écarts d'indexation qui ne se produisent pas dans les opérations normales du site.
Ce guide couvre les problèmes d'indexation spécifiques qui surviennent pendant et après les migrations de site, les étapes de diagnostic pour les identifier et les corrections pour les résoudre rapidement et minimiser la perte de trafic pendant la période de transition.
La fenêtre critique de 90 jours post-migration
La réponse de Google à une migration de site se déroule sur environ 90 jours, bien que le calendrier exact varie en fonction de la taille du site, de la fréquence de crawl et de l'étendue des changements. Comprendre ce calendrier aide à définir des attentes et à identifier quand les délais d'indexation sont normaux versus quand ils indiquent un problème.
Dans les une à deux premières semaines après la migration, Google commence à découvrir les changements. Si tu as mis en place des redirections 301 des anciennes URLs vers les nouvelles, Google rencontre ces redirections lors de son crawl normal de tes anciennes URLs. Chaque redirection dit à Google que l'ancienne URL a définitivement déménagé vers un nouvel emplacement. Google traite ces redirections et commence à ajouter les nouvelles URLs à sa file de crawl. Pendant cette phase, tu verras un mélange d'anciennes et de nouvelles URLs dans les résultats de recherche, ce qui est normal.
Dans les semaines deux à quatre, Google intensifie le crawl des nouvelles URLs. Si tu as soumis un nouveau sitemap avec la nouvelle structure d'URL et vérifié le nouveau domaine dans Google Search Console, Google accélère son exploration du nouveau site. Tu devrais voir le ratio d'anciennes à nouvelles URLs dans l'index se déplacer vers les nouvelles URLs. Certaines anciennes URLs apparaîtront encore dans les résultats de recherche car Google n'a pas encore exploré et traité toutes les redirections.
Dans les semaines quatre à huit, le gros de la transition devrait être terminé. La plupart des anciennes URLs devraient rediriger correctement, la plupart des nouvelles URLs devraient être indexées, et les classements devraient commencer à se stabiliser à des niveaux proches ou égaux à ceux d'avant la migration. Si les classements sont significativement plus bas qu'auparavant, il peut y avoir des problèmes de redirection, des changements de contenu ou des problèmes techniques sur le nouveau site affectant les signaux de qualité.
Dans les semaines huit à douze, la confiance de Google dans le nouveau site se solidifie. Toutes les anciennes URLs restantes qui sont toujours indexées devraient être traitées. Les classements devraient récupérer aux niveaux d'avant la migration en supposant que la migration a été exécutée correctement. Si des pages spécifiques ne sont toujours pas indexées à ce stade, elles ont des problèmes individuels qui nécessitent un dépannage ciblé.
Pendant cette fenêtre de 90 jours entière, évite de faire des changements majeurs supplémentaires sur ton site. Ne redessine pas le nouveau site, ne restructure pas les URLs à nouveau et ne change pas significativement le contenu. Chaque changement supplémentaire réinitialise des parties du processus d'évaluation de Google et étend le calendrier de récupération. Traite les 90 jours après la migration comme une période de stabilisation où tes seuls changements devraient être des correctifs pour les problèmes liés à la migration.
Chaînes de redirections 301, boucles et lacunes de mappage
L'implémentation des redirections est le facteur le plus important pour l'indexation post-migration. Chaque ancienne URL qui avait des classements, du trafic ou des backlinks doit rediriger vers la page la plus pertinente sur le nouveau site. Les erreurs dans l'implémentation des redirections sont responsables de la majorité des échecs d'indexation post-migration.
Les chaînes de redirection se produisent quand une redirection pointe vers une autre redirection, qui pointe vers une autre. Par exemple, http://old-domain.com redirige vers https://old-domain.com, qui redirige vers https://new-domain.com/page. Google peut suivre les chaînes de redirection, mais chaque saut dans la chaîne introduit de la latence et peut perdre une partie de l'équité de lien. Google a déclaré qu'il transmet le PageRank complet via une seule redirection 301 mais a été moins clair sur les chaînes. La meilleure pratique est de minimiser les chaînes à un maximum de deux sauts et idéalement d'implémenter des redirections directes à un saut de chaque ancienne URL vers sa destination finale.
Les boucles de redirection se produisent quand l'URL A redirige vers l'URL B, et l'URL B redirige vers l'URL A. Cela empêche Google d'atteindre jamais une page de destination finale et entraîne une erreur de crawl. Les boucles se produisent couramment quand HTTP redirige vers HTTPS et que la version HTTPS a également une règle de redirection qui renvoie certains chemins vers HTTP, ou quand les redirections www et non-www entrent en conflit. Teste l'implémentation des redirections en utilisant un vérificateur de chaîne de redirection qui suit le chemin complet de redirection pour chaque URL.
Les lacunes de mappage sont d'anciennes URLs qui n'ont aucune redirection vers une nouvelle URL. Quand Google explore une ancienne URL et reçoit une erreur 404 au lieu d'une redirection, il retire cette URL de l'index. Si la page équivalente existe sur le nouveau site mais n'a pas été mappée dans le plan de redirection, Google n'a aucun moyen de connecter l'autorité de l'ancienne page à la nouvelle page. La nouvelle page doit gagner l'indexation à partir de zéro, perdant tous les signaux de classement accumulés.
Pour identifier les lacunes de mappage, compare ta liste complète d'anciennes URLs indexées (exportée depuis Google Search Console avant la migration ou d'un crawl pré-migration) à ton fichier de mappage de redirection. Toute ancienne URL sans redirection correspondante est une lacune. Pour les anciennes URLs qui n'ont pas d'équivalent direct sur le nouveau site, redirige-les vers la page parente ou catégorie la plus pertinente plutôt que de les laisser en 404. Une redirection vers une page quelque peu pertinente est toujours mieux qu'un 404 du point de vue de l'équité de lien.
Après la migration, surveille Google Search Console pour les erreurs de crawl sur les anciennes URLs. Un pic d'erreurs 404 sur les motifs d'anciennes URLs indique des redirections manquantes. Vérifie régulièrement la liste des erreurs 404 pendant les 90 premiers jours et ajoute des redirections pour toutes les anciennes URLs à fort trafic ou à forte autorité qui retournent des erreurs.
Vérification Google Search Console et gestion de sitemap
Une configuration appropriée de Google Search Console est critique pour l'indexation post-migration. Si ta migration implique un changement de domaine, un changement de structure d'URL ou un changement de protocole, ta configuration Search Console a besoin de mises à jour spécifiques pour aider Google à traiter la transition correctement.
Pour les migrations de domaine (old-domain.com vers new-domain.com), tu dois avoir l'ancien et le nouveau domaine vérifiés dans Google Search Console. Ne supprime pas l'ancienne propriété de domaine. Tu en as besoin pour surveiller comment Google traite la transition depuis les anciennes URLs et pour utiliser l'outil de Changement d'Adresse. Dans la propriété Search Console de l'ancien domaine, navigue vers Paramètres et utilise la fonctionnalité Changement d'Adresse pour notifier formellement Google que le site a déménagé vers le nouveau domaine. Cela accélère le traitement par Google du changement de domaine et aide à préserver les signaux de classement pendant la transition.
Pour le nouveau domaine, vérifie-le comme propriété de Domaine dans Search Console immédiatement à la migration. Soumets un nouveau sitemap XML contenant toutes les nouvelles URLs. Le nouveau sitemap devrait lister uniquement la nouvelle structure d'URL. N'inclus pas d'anciennes URLs dans le nouveau sitemap. Si ton ancien sitemap est toujours accessible sur l'ancien domaine, laisse-le en place temporairement. Google explorera l'ancien sitemap, rencontrera les redirections pour chaque URL et les suivra vers les nouvelles URLs, ce qui aide à la découverte.
Pour les changements de structure d'URL sur le même domaine (par exemple, changer /blog/post-title en /articles/post-title), soumets un sitemap mis à jour avec les nouveaux motifs d'URL. Utilise l'outil d'inspection d'URL pour demander le re-crawl de tes nouvelles URLs les plus importantes. Google devrait découvrir les changements d'URL via les redirections lors du crawl normal, mais la soumission de sitemap accélère le processus.
Pour les migrations HTTP vers HTTPS, ajoute et vérifie la version HTTPS de ton domaine dans Search Console si tu ne l'as pas déjà fait. Soumets un nouveau sitemap avec les URLs HTTPS. Google traite généralement les migrations HTTPS en douceur, mais surveille l'indexation des URLs HTTPS au cours des semaines suivantes pour t'assurer qu'elles remplacent les URLs HTTP dans l'index.
Une erreur courante est de soumettre un sitemap avec des anciennes URLs depuis le nouveau site. Après la migration, audite ton sitemap pour t'assurer que chaque URL qu'il contient est une URL valide et non-redirigeante sur le nouveau site. Un sitemap qui référence d'anciennes URLs ou des URLs redirigeantes envoie des signaux mixtes à Google et peut retarder l'indexation de ta nouvelle structure d'URL.
Changements de contenu et de template qui affectent l'indexation post-migration
De nombreuses migrations de site impliquent plus qu'un simple changement d'URL. Elles coïncident souvent avec une refonte, un changement de CMS, une restructuration de contenu ou une mise à jour de template. Ces changements au niveau du contenu peuvent causer indépendamment des problèmes d'indexation qui s'ajoutent aux défis de migration d'URL.
Quand un changement de CMS modifie la façon dont les pages sont rendues, il peut introduire des problèmes de rendu JavaScript qui n'existaient pas auparavant. Si tu as migré d'un CMS rendu côté serveur comme WordPress vers un framework JavaScript comme React ou Vue, les pages qui étaient auparavant rendues côté serveur peuvent maintenant être rendues côté client. Google doit maintenant attendre que sa file de rendu JavaScript traite des pages qu'il pouvait auparavant indexer depuis le HTML initial. Cela seul peut ajouter des jours au calendrier d'indexation pour chaque page.
Les changements de template peuvent altérer la structure de liens internes de ton site. Une nouvelle conception avec une navigation différente, des widgets de barre latérale différents, des liens de pied de page différents ou des sections de contenu connexes différentes change quelles pages lient vers quelles autres pages. Si des liens internes importants ont été supprimés pendant la refonte, certaines pages peuvent devenir orphelines sur le nouveau site même si elles avaient de forts liens internes sur l'ancien site. Crawle ton nouveau site et compare le graphe de liens internes à l'ancien site pour identifier les pages qui ont perdu leur support de liens internes.
Les changements de contenu pendant la migration, même bien intentionnés, peuvent affecter l'indexation. Si tu as réécrit les titres de page, combiné ou divisé des pages, ajouté ou supprimé des sections de contenu, ou changé les structures d'en-tête, Google évalue ceux-ci comme nouveau contenu plutôt que de les reconnaître comme des versions mises à jour de l'ancien contenu. Des changements de contenu significatifs peuvent amener Google à réévaluer la qualité de la page depuis le début plutôt que de reporter l'autorité de l'ancienne page via la redirection.
L'approche de migration la plus sûre sépare la migration d'URL de la migration de contenu/conception. D'abord, migre les URLs et les redirections sans changer aucun contenu ou template. Laisse Google traiter le changement d'URL et stabiliser l'indexation sur quatre à six semaines. Puis, fais des changements de conception et de contenu progressivement. Cette approche par étapes facilite le diagnostic des problèmes parce que tu sais exactement quel changement a causé quel effet. Tout faire en même temps rend le dépannage presque impossible parce que les problèmes d'URL, de contenu et techniques sont tous entrelacés.
Guide étape par étape
Vérifier l'implémentation des redirections pour toutes les anciennes URLs
Exporte la liste complète des URLs indexées de ton ancien site (depuis un crawl pré-migration ou une exportation Search Console). Teste chaque redirection en utilisant un outil de vérification de redirections en masse. Vérifie que chaque ancienne URL redirige avec un 301 (pas un 302) vers la bonne nouvelle URL. Identifie et corrige les chaînes de redirection (plus d'un saut), les boucles de redirection (redirections circulaires) et les lacunes de mappage (anciennes URLs retournant 404). Priorise la correction des redirections pour les pages avec le plus de trafic, le plus de backlinks et les classements les plus forts. Chaque redirection manquante ou cassée est un signal de classement qui fuit.
Configurer Google Search Console pour le nouveau site
Vérifie le nouveau domaine ou la nouvelle structure d'URL dans Google Search Console comme propriété de Domaine. Garde la propriété de l'ancien domaine active. Si tu migres de domaine, utilise l'outil de Changement d'Adresse dans la propriété Search Console de l'ancien domaine pour notifier Google du déménagement. Soumets un nouveau sitemap XML à la nouvelle propriété contenant uniquement la nouvelle structure d'URL. Vérifie que le sitemap est lu avec succès par Google dans les 48 heures de la soumission. Vérifie tout problème de sécurité ou action manuelle sur la nouvelle propriété qui pourrait bloquer l'indexation.
Auditer le nouveau sitemap pour l'exactitude
Télécharge ton nouveau sitemap et vérifie chaque URL qu'il contient. Chaque URL devrait retourner un code de statut 200, ne pas rediriger vers une autre URL, et ne pas porter de balise noindex. Croise le sitemap avec ta liste complète de pages sur le nouveau site pour t'assurer qu'aucune page ne manque. Retire toutes les URLs du sitemap qui redirigent ou retournent des erreurs. Si ton CMS génère automatiquement le sitemap, vérifie qu'il a été configuré pour la nouvelle structure d'URL et ne génère pas encore d'anciens motifs d'URL. Soumets le sitemap nettoyé à Google Search Console.
Vérifier les blocages techniques sur le nouveau site
Vérifie que le robots.txt du nouveau site autorise le crawl de toutes les pages importantes. Vérifie qu'aucune balise noindex globale n'a été laissée de l'environnement de staging ou de développement. De nombreuses plateformes CMS appliquent noindex aux environnements de staging, et ce paramètre peut persister après la migration vers l'URL de production. Teste le rendu du nouveau site en utilisant l'outil d'inspection d'URL sur cinq à dix pages à travers différentes sections. Vérifie que le contenu de la page se rend correctement et qu'aucune erreur JavaScript ou de chargement de ressources n'empêche Google de voir le contenu. Vérifie la validité du certificat SSL si tu migres vers HTTPS.
Surveiller la transition d'indexation dans Search Console
À partir du moment immédiat après la migration, surveille le rapport Pages dans Google Search Console pour les anciennes et nouvelles propriétés quotidiennement pendant les deux premières semaines, puis hebdomadairement pendant les dix semaines suivantes. Suis le nombre de pages indexées sur la nouvelle propriété (devrait augmenter), le nombre de pages indexées sur l'ancienne propriété (devrait diminuer), le nombre d'erreurs de crawl sur les deux propriétés, et toute nouvelle raison « non indexée » qui apparaît. Crée un tableur suivant ces métriques au fil du temps pour identifier les tendances et les blocages dans le processus de transition.
Demander l'indexation pour les nouvelles URLs hautement prioritaires
Identifie tes 50 à 100 pages les plus importantes (plus de trafic, plus de revenus, plus de backlinks) et vérifie qu'elles sont indexées sur les nouvelles URLs. Pour toutes celles qui ne sont pas encore indexées, utilise l'outil d'inspection d'URL pour demander l'indexation individuellement. Pour les sites plus grands avec des centaines ou des milliers de pages importantes, utilise IndexBolt pour soumettre les nouvelles URLs en masse pour une indexation plus rapide. Priorise les pages qui avaient de forts classements avant la migration, car ce sont les pages où une indexation retardée a le plus grand impact business.
Enquêter et corriger les écarts d'indexation persistants après 30 jours
Après 30 jours, toute page qui n'est toujours pas indexée sur la nouvelle URL a probablement un problème spécifique au-delà de la transition de migration normale. Pour chaque page non indexée, vérifie : la redirection depuis l'ancienne URL fonctionne-t-elle correctement ? La nouvelle URL retourne-t-elle un code de statut 200 ? Le contenu sur la nouvelle URL est-il substantiellement le même que sur l'ancienne URL ? Y a-t-il de nouveaux problèmes de canonical, noindex ou rendu sur la nouvelle URL ? La page reçoit-elle des liens internes depuis d'autres pages indexées sur le nouveau site ? Aborde chaque problème individuellement et resoumets pour indexation. Les pages encore non indexées après 60 jours sans problèmes techniques identifiables peuvent nécessiter une amélioration de contenu pour répondre aux seuils de qualité actuels.
Problèmes courants et comment les résoudre
Anciennes URLs apparaissant encore dans les résultats de recherche des mois après la migration
Cause : Google n'a pas encore exploré et traité les redirections pour ces URLs. C'est courant pour les anciennes URLs qui étaient peu fréquemment explorées avant la migration ou pour les sites avec un très grand nombre d'URLs. Cela peut aussi indiquer que les redirections retournent 302 (temporaire) au lieu de 301 (permanent), ce qui fait que Google garde l'ancienne URL dans l'index tout en traitant la redirection comme temporaire.
Solution : Vérifie que les redirections sont 301 (permanent) plutôt que 302 (temporaire). Utilise l'outil d'inspection d'URL dans la propriété Search Console de l'ancien domaine pour demander le re-crawl des anciennes URLs persistantes, ce qui forcera Google à rencontrer la redirection et à la traiter. Si tu utilises l'outil de Changement d'Adresse, vérifie qu'il est configuré correctement. Pour les grands sites, utilise IndexBolt pour soumettre directement les nouvelles URLs, ce qui ajoute les nouvelles pages à l'index en parallèle du traitement des redirections.
Nouvelles URLs affichées comme « Explorée, actuellement non indexée » après la migration
Cause : Google a exploré les nouvelles URLs mais a déterminé qu'elles ne répondent pas au seuil de qualité pour l'indexation. Cela peut arriver quand la migration a impliqué des changements de contenu significatifs, quand le nouveau template fournit moins de contenu que l'ancien (par exemple, en retirant le contenu de barre latérale ou les sections d'articles connexes), ou quand l'évaluation de qualité de Google du nouveau site est plus faible que de l'ancien site en raison de problèmes techniques comme une vitesse de page lente ou des problèmes de rendu.
Solution : Compare le contenu sur la nouvelle URL à la version mise en cache de l'ancienne URL. Identifie quel contenu a été retiré ou modifié. Restaure tout contenu unique qui a été supprimé pendant la migration. Vérifie la vitesse de page et les Core Web Vitals sur le nouveau site, car une dégradation significative de performance peut affecter les signaux de qualité. Vérifie que les liens internes depuis la navigation du nouveau site atteignent ces pages. Si le contenu est équivalent, soumets les URLs via IndexBolt pour pousser Google à réévaluer.
Pic massif d'erreurs 404 dans Search Console après la migration
Cause : Les anciennes URLs que Google explorait précédemment retournent maintenant 404 parce que les redirections n'ont pas été implémentées pour elles. Cela arrive couramment quand le mappage de redirection était incomplet, couvrant uniquement les pages les plus importantes plutôt que toutes les anciennes URLs. Cela arrive aussi quand l'ancien serveur ou hébergement est mis hors ligne avant que Google ait complètement traité la migration.
Solution : Audite la liste des erreurs 404 dans Search Console pour la propriété de l'ancien domaine. Priorise l'implémentation de redirections pour les URLs 404 qui avaient un trafic significatif, des backlinks ou des classements (vérifie par rapport à tes données pré-migration). Pour les URLs sans trafic ou backlinks, un 404 est acceptable car Google les retirera naturellement de l'index. Garde l'hébergement et la configuration de redirection de l'ancien domaine actifs pendant au moins six mois après la migration pour t'assurer que Google a le temps de traiter toutes les redirections. N'arrête pas l'hébergement de l'ancien domaine prématurément.
Les classements ont chuté significativement après la migration et ne récupèrent pas
Cause : Bien que ce ne soit pas strictement un problème d'indexation, les chutes de classement accompagnent souvent les problèmes d'indexation pendant la migration. Les causes courantes incluent les chaînes de redirection qui diluent l'équité de lien, les redirections manquantes pour les pages avec des backlinks, les changements de contenu significatifs que Google évalue moins favorablement, une vitesse de page plus lente sur le nouveau site, des problèmes d'utilisabilité mobile sur la nouvelle conception, et la perte de données structurées ou de résultats enrichis qui ont stimulé les taux de clics sur l'ancien site.
Solution : Effectue une comparaison complète entre les anciens et nouveaux sites. Vérifie la profondeur des chaînes de redirection et corrige toute chaîne plus longue qu'un saut. Vérifie que toutes les pages avec des backlinks ont des redirections directes. Compare les Core Web Vitals entre les anciens et nouveaux sites. Compare l'implémentation des données structurées. Compare l'utilisabilité mobile. Aborde chaque déficit. Si le nouveau site est techniquement solide et équivalent en contenu, les classements récupèrent typiquement dans 60 à 90 jours à mesure que la confiance de Google dans le nouveau site se construit. Des chutes de classement persistantes au-delà de 90 jours indiquent une différence de qualité substantielle qui nécessite une enquête.
Pages indexées simultanément sur les anciennes et nouvelles URLs
Cause : Google est en cours de transition mais n'a pas encore complètement traité la redirection pour ces pages. Cela résulte en le même contenu apparaissant sur deux URLs dans l'index, ce qui peut causer de la confusion de classement et un fractionnement du trafic entre les anciennes et nouvelles URLs. Cela se résout typiquement naturellement dans quatre à six semaines mais peut persister si les redirections sont implémentées en 302 au lieu de 301.
Solution : Vérifie que toutes les redirections sont 301 (permanent). Si tu utilises des redirections 302, change-les en 301 immédiatement. Utilise l'outil d'inspection d'URL pour vérifier les anciennes et nouvelles URLs. Si l'ancienne URL apparaît comme indexée avec une redirection, Google la traite mais n'a pas encore terminé la transition. C'est normal pendant les premières semaines. Si cela persiste au-delà de six semaines, demande le re-crawl de l'ancienne URL pour forcer Google à traiter la redirection. Assure-toi que les balises canonical sur les nouvelles URLs sont auto-référencées (pointant vers elles-mêmes) et ne pointent pas vers les anciennes URLs.
Astuces pro
Ne laisse pas une migration de site effacer des mois de progrès SEO. IndexBolt soumet tes nouvelles URLs directement à Google, accélérant la transition de l'ancien au nouveau et minimisant l'écart d'indexation. Soumets ta liste complète de nouvelles URLs immédiatement après la migration et fais indexer tes nouvelles pages en quelques heures au lieu d'attendre des semaines que Google traite chaque redirection.
100 crédits gratuits. Aucune carte bancaire requise. Résultats en moins de 24 heures.
Questions fréquentes
Combien de temps une migration de site complète devrait-elle prendre pour se compléter du point de vue de Google ?+
La plupart des migrations de site sont entièrement traitées par Google dans 60 à 90 jours. Pendant les deux premières semaines, tu verras un mélange d'anciennes et de nouvelles URLs dans l'index. À la semaine quatre, la plupart des nouvelles URLs devraient être indexées et la plupart des anciennes URLs devraient rediriger. À la semaine huit, la transition devrait être substantiellement terminée avec seulement des cas marginaux restants. Les très grands sites (millions de pages) peuvent prendre plus de temps parce que la capacité de crawl de Google est finie. Si ta migration ne s'est pas substantiellement terminée dans 90 jours, il y a probablement des problèmes techniques (redirections cassées, crawl bloqué ou problèmes de rendu) qui nécessitent une enquête.
Devrais-je utiliser des redirections 301 ou 302 pour une migration de site ?+
Utilise toujours des redirections 301 (permanentes) pour les migrations de site. Les redirections 301 disent à Google que le déménagement est permanent, ce qui amène Google à transférer les signaux de classement vers la nouvelle URL et éventuellement à retirer l'ancienne URL de l'index. Les redirections 302 (temporaires) disent à Google que le déménagement pourrait être inversé, ce qui amène Google à garder l'ancienne URL dans l'index et à ne pas transférer entièrement l'autorité. Bien que Google ait déclaré qu'il finit par traiter les 302 de longue date de manière similaire aux 301, utiliser 301 dès le départ évite les délais et l'ambiguïté. La seule raison d'utiliser 302 est si la redirection est véritablement temporaire et que tu prévois de restaurer l'ancienne URL.
Je migre de HTTP à HTTPS. Dois-je toujours faire toutes ces étapes ?+
Oui, bien que les migrations HTTP vers HTTPS soient le type le plus simple et que Google les gère le plus en douceur. Tu dois toujours implémenter des redirections 301 de toutes les URLs HTTP vers leurs équivalents HTTPS, mettre à jour ton sitemap pour utiliser des URLs HTTPS, vérifier la propriété HTTPS dans Google Search Console et mettre à jour les balises canonical pour utiliser HTTPS. L'avantage principal d'une migration HTTPS est que Google l'encourage activement, donc le traitement tend à être plus rapide. La plupart des migrations HTTPS sont entièrement traitées dans trois à quatre semaines. Cependant, les mêmes exigences de mappage de redirection, de sitemap et de surveillance s'appliquent.
Qu'arrive-t-il à mes backlinks quand je migre vers un nouveau domaine ?+
Les backlinks vers ton ancien domaine continuent de transmettre de la valeur à ton nouveau domaine via les redirections 301, mais il y a une certaine perte de valeur dans le processus. Google a confirmé que les redirections 301 transmettent la majorité de l'équité de lien, mais le montant exact n'est pas divulgué. Certaines études SEO suggèrent une perte de 10-15 % par saut de redirection. Pour maximiser la préservation de la valeur des backlinks, implémente des redirections 301 directes à un saut de chaque ancienne URL vers son nouvel équivalent. Pour tes backlinks les plus importants (depuis les domaines à plus forte autorité), envisage de contacter le site liant et de lui demander de mettre à jour le lien pour pointer directement vers ta nouvelle URL, contournant entièrement la redirection.
Puis-je migrer mon site par phases, en faisant une section à la fois ?+
La migration par phases est possible mais ajoute de la complexité. Migrer une section à la fois (par exemple, /blog/ d'abord, puis /products/, puis le reste) signifie que Google doit traiter plusieurs rounds de changements plutôt qu'un changement complet. L'avantage est que cela limite le rayon d'impact de toute erreur. Si quelque chose se passe mal avec la migration du blog, tes pages de produits ne sont pas affectées. Le désavantage est que le calendrier total de migration est plus long, et gérer les redirections devient plus complexe quand certaines sections sont sur la nouvelle structure tandis que d'autres sont encore sur l'ancienne. Pour la plupart des sites, une seule migration bien planifiée est préférable à une approche par phases.