Le jour de la migration, les contrôles voient surtout ce qui casse fort : 5xx, boucles, certificats, pages sans contenu ou canonicals restés sur l’ancien domaine. Deux semaines plus tard, les défauts résiduels sont plus discrets. Des robots continuent de demander une ancienne famille d’URL, quelques redirections aboutissent à une catégorie générique et certaines nouvelles pages ne sont découvertes que par leur ancien chemin.
La douleur apparaît lorsque ces requêtes s’accumulent sans propriétaire. Le dashboard global semble stable, mais les logs montrent une longue traîne de 404, des chaînes et des hits sur des sitemaps retirés. Chaque équipe suppose que le phénomène disparaîtra avec le recrawl. Au jour 60, les mêmes pertes subsistent, les exceptions se sont multipliées et personne ne sait lesquelles touchent encore le revenu, les liens ou l’indexation.
Le vrai enjeu des 90 jours consiste à transformer les requêtes résiduelles en décisions fermées. Le pilotage SEO technique après migration associe chaque ancienne URL à un état, une cause, une valeur et une action. Les logs ne prédisent pas le classement ; ils prouvent qu’un agent a demandé une URL et ce que l’infrastructure lui a répondu.
Ce qui compte vraiment est la trajectoire par cohorte. Si une ancienne route décroît tandis que sa destination gagne des hits et reste conforme, l’observation peut continuer. Si la demande stagne, que les chaînes persistent ou que les URL prioritaires échouent, alors la migration conserve une dette active. La fenêtre de 90 jours organise le travail, mais ne remplace jamais le mécanisme observé.
Savoir dans quels cas suivre les URL pendant 90 jours
La période commence à l’activation du mapping, pas à la date de lancement du projet. Elle poursuit quatre objectifs : confirmer le transfert des routes historiques, détecter les pertes invisibles au crawl interne, mesurer la découverte des destinations et retirer la dette transitoire. Chaque objectif possède une source et une condition de fermeture. Sans cette définition, quatre-vingt-dix jours deviennent une attente passive.
Le périmètre couvre les anciennes et nouvelles propriétés, tous les hôtes concernés, les variantes HTTP et HTTPS, les sous-domaines d’assets et les routes historiques connues. Le suivi sépare pages HTML, images, PDF, API publiques et ressources critiques. Une requête vers un ancien JavaScript ne porte pas la même décision qu’une page produit encore citée par des backlinks.
Le programme établit aussi ce qu’il ne peut pas prouver. Un log ne dit pas pourquoi Google indexe ou non une page ; il ne représente pas tous les systèmes de Google et peut être échantillonné par le fournisseur. Il permet en revanche de localiser une demande, un statut, une latence et une chaîne. Cette frontière évite de transformer une corrélation temporelle en diagnostic certain.
Le dispositif est particulièrement utile lors d’un changement de domaine, d’arborescence, de moteur de rendu ou de CDN, car plusieurs couches peuvent conserver les anciens chemins à des rythmes différents. Par exemple, un PDF partenaire peut encore envoyer vers une URL retirée alors que le maillage du site est déjà propre. À l’inverse, une correction isolée sur cinq pages ne justifie pas nécessairement trois mois de pipeline : une cohorte bornée, un contrôle après déploiement et une date de clôture peuvent suffire.
Réconcilier les logs de toutes les couches
Le CDN, le load balancer, le proxy et l’application peuvent chacun raconter une partie différente du parcours. Une réponse servie au bord ne figure pas toujours dans les logs d’origine ; un retry interne peut doubler le volume applicatif ; une redirection mise en cache peut survivre après correction. Le pipeline conserve donc l’heure, l’hôte, le chemin brut, les paramètres, le statut, la destination, le user-agent, l’adresse réseau, le temps de réponse, le cache status et l’identifiant de release.
Les horloges et formats sont normalisés avant toute agrégation. La requête brute reste disponible pour auditer un regroupement. Les paramètres de suivi peuvent être retirés de la clé analytique, tandis que ceux qui modifient le contenu ou le routage restent distincts. Une normalisation trop agressive fusionne des problèmes différents ; une normalisation absente transforme chaque campagne en nouvelle URL.
La qualification des robots ne repose pas uniquement sur le nom du user-agent. La documentation Google explique comment vérifier Googlebot au moyen des plages publiées ou d’une vérification DNS directe et inverse. Les visites non vérifiées restent dans une catégorie séparée afin que les faux bots ne dictent ni priorité ni capacité.
La rétention suit le besoin d’enquête : les événements détaillés restent disponibles assez longtemps pour rejouer une anomalie, tandis que les agrégats prolongent la lecture des tendances. Les accès sont limités et les adresses sont traitées selon la politique de sécurité. Ce compromis préserve la preuve utile sans transformer le programme SEO en stockage indéfini de données techniques.
Construire un tableau d’état par ancienne URL
Chaque URL historique rejoint une ligne de décision. La ligne contient la destination prévue, le statut observé, le nombre de sauts, le canonical final, la présence dans les liens et sitemaps, les hits vérifiés, la dernière visite, la valeur business et les liens externes connus. La version du mapping permet de distinguer un défaut initial d’une correction déployée plus tard.
Quatre états opérationnels suffisent. « Transfert conforme » signifie que l’ancienne URL redirige directement vers une destination équivalente qui répond en 200 et s’affirme canonique. « Demande résiduelle normale » décrit une ancienne URL encore visitée mais décroissante. « Perte active » couvre 4xx injustifiés, boucle, mauvaise destination, contenu vide ou cible non indexable. « Retrait assumé » documente une absence correcte en 404 ou 410 lorsqu’aucun remplaçant utile n’existe.
Le tableau ne masque pas les exceptions dans un taux. Une cohorte à 99 % peut échouer sur les pages qui concentrent marge, liens et demande. Les sentinelles restent nommées, avec leur dernière réponse et leur owner. Le total aide à mesurer la charge ; la liste permet de décider.
Prioriser les pertes par impact et mécanisme
Le triage commence par les défauts qui empêchent un parcours ou contredisent le mapping : 5xx, boucle, redirection vers un autre pays, destination sans contenu, canonical vers l’ancien site. Viennent ensuite les pertes de découverte et de consolidation : chaînes, liens internes historiques, nouvelles URL absentes du sitemap ou seulement connues grâce aux redirections. Les 404 légitimes et les bots non vérifiés arrivent après, sauf volume susceptible d’épuiser la capacité.
La priorité croise fréquence, criticité, confiance et effort. Un seul hit Googlebot sur une page de paiement cassée mérite une action immédiate ; dix mille requêtes d’un scraper vers un espace inexistant peuvent relever du WAF. Le volume brut n’est donc jamais le seul classement. La source de demande et la réponse attendue déterminent le risque.
La causalité s’appuie sur un mécanisme reproductible. Une baisse de clics simultanée à des 404 sur les mêmes anciennes pages renforce l’hypothèse, mais ne suffit pas seule. Le test rejoue la route, inspecte la chaîne, vérifie le mapping et compare une cohorte témoin. La correction ne part qu’après localisation du composant responsable.
Lire la décroissance sans calendrier arbitraire
La demande des anciennes URL ne tombe pas à zéro de façon uniforme. Les pages souvent explorées changent vite ; une ressource saisonnière ou citée dans un PDF peut revenir plusieurs mois plus tard. Le suivi utilise des fenêtres glissantes comparables, distingue jours ouvrés et week-ends, puis marque les campagnes et incidents qui modifient le trafic.
Les jours 7, 30, 60 et 90 sont des portes de revue, pas des promesses de transfert. La documentation Google rappelle qu’un déplacement est traité URL par URL et que sa durée dépend notamment du volume et de la capacité de crawl. La fermeture d’une cohorte exige une destination conforme, une demande historique décroissante et l’absence de nouvelle source interne vers l’ancien chemin.
En réalité, une hausse temporaire des anciennes URL peut être positive si elle provient d’un recrawl accéléré et se transforme en hits sur les destinations. À l’inverse, un volume stable de 301 peut cacher un maillage jamais corrigé. La tendance n’a de sens qu’avec le référent, le robot, la destination et la version du site.
Décision et arbitrages : corriger, observer ou fermer
Corriger une perte dont la cause est démontrée
Une mauvaise destination, une chaîne évitable, un 5xx ou une page vide possède une action technique. L’équipe modifie une seule règle, rejoue la même cohorte et compare avant/après. Elle met à jour le mapping signé afin que le correctif ne devienne pas une exception invisible dans le CDN.
Le correctif inclut les liens internes et les sitemaps lorsque ceux-ci alimentent encore l’ancien chemin. Réparer uniquement la redirection traite le symptôme sans supprimer sa source. La définition de done exige la disparition mesurée de la référence obsolète.
Observer un transfert encore cohérent
Une redirection correcte et décroissante n’appelle pas une intervention quotidienne. Elle reste surveillée avec une prochaine date de revue, une plage de variabilité et une condition d’escalade. Cette retenue protège les équipes contre les changements opportunistes qui brouillent la lecture du transfert.
L’observation ne signifie pas abandon. Les sentinelles, les nouvelles erreurs et les demandes sans décroissance génèrent toujours une alerte. Le tableau distingue clairement le stock accepté de la perte active.
Fermer une cohorte et retirer la dette
La cohorte ferme lorsque les destinations restent conformes, les sources internes ont été mises à jour et les exceptions temporaires peuvent être supprimées. Les redirections permanentes utiles restent en place ; ce sont les doubles sitemaps, règles conditionnelles, dashboards de migration et accès temporaires qui doivent disparaître.
La clôture conserve un export du mapping et des preuves. Elle documente les anciennes URL qui peuvent réapparaître saisonnièrement. Ainsi, un futur hit ne relance pas toute l’enquête et peut être comparé au verdict précédent.
- À valider : Le mécanisme, la cohorte, la destination et l’owner de chaque décision.
- À bloquer : Les corrections massives fondées uniquement sur un volume agrégé.
- À corriger : Les sources internes qui entretiennent une route historique déjà migrée.
Implémenter un pipeline de triage reproductible
Implémentation. L’entrée du pipeline rassemble les journaux CDN, proxy et application ; la sortie est une table d’URL enrichie du mapping et du verdict. Un owner data garantit la responsabilité du schéma, l’instrumentation compte hits, statuts, chaînes et latence, tandis que la journalisation conserve la version et la traçabilité de chaque transformation. Le seuil d’anomalie est versionné avec la règle qui le calcule.
Exploitation. Le runbook décrit dépendances, retard d’ingestion, repli vers les logs bruts, retry idempotent et file de reprise. Le monitoring alerte sur absence de données autant que sur hausse des erreurs. La CI et la QA testent parsing, normalisation et jointure ; un contrôle de rendu HTML, JavaScript, SSR et hydratation vérifie les routes dont le canonical diverge, tandis que les logs de Googlebot relient crawl, indexation, cache et TTFB.
Les données sensibles sont minimisées et leur conservation bornée. L’adresse IP n’est gardée que selon les besoins de sécurité et de vérification autorisés ; les identifiants utilisateurs sont retirés ou pseudonymisés. Les équipes SEO consultent des agrégats et les requêtes nécessaires au diagnostic, avec une politique d’accès explicite.
Éprouver les décisions avec des cas simulés
Cas simulé 1. Sur 60 000 anciennes fiches, 98,8 % redirigent correctement. Pourtant 240 URL à forte marge aboutissent à une catégorie générique et reçoivent encore 35 % des hits organiques du lot. Si plus de 0,5 % des sentinelles ont une destination non équivalente, alors le lot reste en correction. Le score global ne peut pas acheter l’acceptation des pages prioritaires.
Cas simulé 2. Au jour 30, les requêtes vérifiées vers un ancien répertoire baissent de 40 %, mais les hits sur les nouvelles URL ne progressent pas et les logs montrent une chaîne à deux sauts. Le seuil interne exige une destination directe pour 99,5 % de la cohorte. L’équipe corrige la règle intermédiaire, met à jour les liens puis mesure la nouvelle pente sur quatorze jours comparables.
Un troisième signal protège l’attribution : si le lot migré et la cohorte témoin subissent la même hausse de 5xx, alors l’incident d’origine reste une hypothèse concurrente. Le triage gèle les corrections de mapping jusqu’à ce que les logs de service localisent la dépendance. Cette contre-épreuve évite de modifier des redirections saines pendant une panne générale.
Erreurs fréquentes : volumes, robots et attribution
La première erreur classe les lignes par hits sans distinguer robots vérifiés, scrapers, utilisateurs et retries internes. La deuxième agrège les chemins après décodage destructif et fusionne des URL réellement différentes. La troisième compare deux périodes sans conserver les jours, incidents, campagnes ou capacités d’ingestion. Ces raccourcis produisent des priorités précises en apparence mais impossibles à défendre.
Une autre erreur consiste à considérer toute ancienne requête comme une anomalie. Les redirections existent justement pour recevoir ces demandes et transmettre vers une destination. Le défaut naît lorsque la réponse est fausse, lente, en chaîne, non équivalente ou entretenue par une source contrôlable. L’objectif n’est pas zéro hit historique à n’importe quel prix.
Enfin, les équipes ferment parfois le dashboard sans retirer les mécanismes transitoires. Les anciens sitemaps, règles CDN conditionnelles, accès de debug et doubles pipelines deviennent alors une architecture permanente. Chaque exception reçoit une date, un owner et une preuve de retrait dans les logs.
Plan d’action : piloter les jours 1 à 90
Jours 1 à 7 : protéger les parcours et la preuve
Vérifier l’ingestion de toutes les couches et la qualité des horodatages. Contrôler les sentinelles, 5xx, boucles, mauvaises destinations, canonicals et réponses vides. Comparer les logs à un crawl externe, au mapping et aux sondes de parcours. Geler toute extension si un seuil rouge est franchi, puis corriger une dépendance à la fois.
Conserver le dernier état sain, les règles activées et les premières réponses dégradées. Créer les cohortes par répertoire, template, langue et criticité. Nommer l’owner de chaque perte et dater la prochaine revue. Les URL retirées sans équivalent sont documentées séparément afin que leurs 404 ou 410 corrects ne polluent pas le backlog.
Jours 8 à 30 : corriger les sources persistantes
Mesurer la décroissance des anciennes demandes et la découverte des destinations. Réparer les liens internes, sitemaps, canonicals, hreflang et références d’assets encore historiques. Réduire les chaînes, vérifier les anciens domaines et rapprocher Search Console des mécanismes observés sans exiger une synchronisation instantanée.
Organiser une revue hebdomadaire fondée sur les exceptions, pas seulement sur le taux global. Chaque correction cite la cause, le diff et l’effet attendu. Les lignes dont la demande reste stable sans source interne connue passent en analyse de backlinks, campagnes, documents ou intégrations externes.
Jours 31 à 90 : démontrer la stabilisation et fermer
Comparer les fenêtres, réviser les seuils si le trafic a changé et fermer les cohortes conformes. Retirer les doubles sitemaps, règles temporaires et dashboards sans owner. Maintenir les redirections permanentes utiles aussi longtemps que nécessaire, mais supprimer les étapes intermédiaires et mettre à jour les liens contrôlables.
Au jour 90, produire un registre des pertes fermées, des risques acceptés et des URL saisonnières encore surveillées. Transformer les incidents récurrents en tests de non-régression. La direction reçoit une décision par cohorte, le coût résiduel et les conditions de réouverture, pas une promesse abstraite que tout recrawl est terminé.
- Collecter : Réconcilier les couches sans perdre le journal brut.
- Qualifier : Vérifier robots, destinations, valeurs et mécanismes.
- Décider : Corriger, observer ou fermer avec un owner.
- Mesurer : Comparer les cohortes sur des fenêtres homogènes.
- Retirer : Supprimer la dette transitoire après preuve de stabilisation.
Sources officielles et ressources liées
La documentation Google sur les migrations avec changement d’URL recommande de surveiller anciennes et nouvelles URL, de tester les redirections et de les conserver durablement. La procédure officielle de vérification de Googlebot permet de séparer visites authentiques et usurpations.
Le dossier sur la migration de domaine et de CMS fournit le contrat global. L’analyse du crawl et de l’indexation aide à interpréter les logs sans confondre demande serveur et présence dans l’index.
- Conserver faits, interprétations et hypothèses dans des champs distincts.
- Relier chaque seuil interne à sa source et à une action.
- Auditer la qualité du pipeline avant d’expliquer une variation métier.
Conclusion : fermer une perte, pas seulement une alerte
Les logs donnent une preuve précieuse après migration : ils montrent quelles anciennes URL restent demandées et ce que le système répond. Leur valeur apparaît lorsque cette preuve rejoint le mapping, les sources internes, la criticité et un verdict. Sans ce rapprochement, le volume produit du bruit et prolonge les exceptions.
La fenêtre de 90 jours discipline le suivi sans prétendre dicter le rythme des moteurs. Certaines cohortes ferment tôt ; d’autres restent ouvertes parce que leur demande saisonnière ou leurs backlinks le justifient. Le programme réussit lorsqu’il sait expliquer cette différence et retirer les mécanismes devenus inutiles.
Pour construire le pipeline, hiérarchiser les pertes et fermer les cohortes avec une preuve partageable, l’accompagnement d’un expert SEO technique coordonne SEO, plateforme, data et métier pendant toute la stabilisation.
