Checklist SEO de migration de site

Une migration de site est un changement contrôlé apporté à la plateforme, au domaine, au protocole, à l’architecture de l’information, à la structure des URL ou au système de rendu d’un site. Elle n’est complète que lorsque les utilisateurs, les robots d’exploration et les analytics peuvent atteindre le contenu prévu via des routes stables et que l’équipe peut prouver que la visibilité importante a été préservée.

Checklist : SEO de migration de site. Période : commencez 6 à 12 semaines avant le lancement pour un site de taille moyenne ; réservez les 5 derniers jours ouvrés pour un gel des modifications, le jour du lancement pour une validation avec personnel dédié, et au moins 4 semaines pour une surveillance active. Responsable : un chef de projet de migration unique, responsable de l’ensemble de la publication, soutenu par des responsables nommés pour l’ingénierie, le SEO, les analytics, le contenu et l’infrastructure.

Pourquoi cette checklist existe et pourquoi elle s’exécute ici

Cette couche de contrôle de publication dans le Processus SEO consomme les preuves d’exploration et d’indexation issues de l’Audit technique de référence , les décisions de conservation/fusion/suppression issues de l’Inventaire et audit de contenu , et la hiérarchie de destination issue de la Carte thématique et architecture de l’information . Ces livrables doivent exister avant que les redirections ou le staging puissent être évalués.

Exécutez-la après l’approbation de la structure de destination mais avant le gel des routes de production. Si elle est exécutée trop tôt, l’équipe mappe des redirections vers des destinations qui peuvent encore changer. Si elle est exécutée trop tard, le routage, les templates, les analytics ou les communications de lancement peuvent déjà être trop coûteux à corriger en toute sécurité.

Le plan de redirection est le livrable le plus risqué car il fait le lien entre les anciennes et les nouvelles routes. Chaque ancienne URL importante doit être mappée en un-à-un vers la destination la plus proche qui préserve son objectif. N’utilisez jamais la page d’accueil comme fourre-tout : cela frustre les visiteurs et masque les destinations manquantes.

Entrées et sorties

Les sorties sont le contrat avec les opérations de lancement. Un tableur sans responsables, preuves ou conditions d’acceptation n’est pas une remise.

La checklist

Chaque élément indique quoi, pourquoi, comment, outil et une condition observable d’achèvement. Ne remplacez un seuil que par une règle plus stricte ou une règle documentée basée sur la référence.

Phase 1 : inventaire pré-migration

1. Construire l’inventaire complet des URL. Quoi : combiner chaque ancienne URL découvrable provenant des explorations, des sitemaps XML, des analytics, de la Search Console, des exportations de backlinks, des enregistrements CMS, des campagnes payantes et des journaux serveur. Pourquoi : aucune source unique ne contient toutes les URL importantes ou demandées ; une page absente de la navigation peut encore avoir des liens, du trafic ou une importance contractuelle. Comment : normaliser le protocole, l’hôte, la casse, la barre oblique finale, les paramètres et les caractères encodés tout en conservant la valeur source brute. Dédupliquer uniquement après avoir enregistré où chaque URL a été trouvée. Outil : explorateur, export CMS, analytics, Search Console, données de backlinks et journaux. Fait quand : chaque source est datée, chaque ligne a une URL normalisée et une source de découverte, les doublons sont résolus et les totaux des sources correspondent à l’inventaire final.

2. Classifier la disposition de chaque URL. Quoi : étiqueter chaque URL comme conserver, déplacer, fusionner, supprimer ou investiguer. Pourquoi : les redirections ne peuvent pas être mappées correctement tant que la décision de contenu n’est pas explicite. Comment : combiner le trafic, les conversions, les backlinks, l’état d’indexation, la qualité du contenu, le besoin métier et l’intention ; enregistrer les preuves et le responsable approbateur. Outil : classeur d’inventaire et audit de contenu. Fait quand : 100 % des URL dans le périmètre ont une disposition, un responsable, une destination ou une raison de suppression, et aucune ligne « investiguer » non résolue ne subsiste au moment du gel.

3. Capturer la référence signée. Quoi : préserver les sessions organiques, clics, impressions, conversions, revenus, URL indexées, erreurs d’exploration, codes de réponse, disponibilité et performances pré-lancement pour les templates et répertoires prioritaires. Pourquoi : sans point de comparaison daté, les variations normales et les dommages de migration se ressemblent. Comment : exporter au moins 28 jours comparables, annoter les campagnes et la saisonnalité, et identifier les URL prioritaires nécessitant un examen quotidien. Outil : analytics, Search Console, explorateur, données de classement et surveillance. Fait quand : la référence est en lecture seule, reproductible, segmentée, horodatée et approuvée par les responsables SEO et analytics.

Phase 2 : mapping des redirections

4. Mapper les sources un-à-un autant que possible. Quoi : attribuer chaque ancienne URL déplacée ou fusionnée à la nouvelle URL la plus proche ayant la même intention principale. Pourquoi : une destination précise préserve la continuité pour le visiteur et donne aux robots d’exploration un signal de remplacement cohérent. Comment : comparer le sujet, le produit, la géographie, la langue et la tâche ; mapper les fusions vers la page survivante et documenter les suppressions délibérées. Ne jamais mapper les URL non appariées vers la page d’accueil. Outil : classeur du plan de redirection, inventaire et exploration des destinations. Fait quand : chaque source modifiée a exactement un résultat approuvé, chaque destination est pertinente et dans le périmètre, et les mappings fourre-tout vers la page d’accueil sont égaux à zéro.

5. Valider les mécanismes de redirection avant le lancement. Quoi : tester les codes de statut, les destinations, le comportement des paramètres, les variantes de casse, le protocole, les sous-domaines, les barres obliques finales, les fichiers et les URL de campagne. Pourquoi : un tableur d’apparence correcte peut encore produire des boucles, des chaînes, des wildcards qui engloutissent des pages valides, ou des destinations qui retournent des erreurs. Comment : générer les règles de staging ou de proxy, requêter chaque source, suivre les sauts, et comparer l’URL finale avec le plan approuvé. Outil : test HTTP automatisé, explorateur et revue de configuration serveur. Fait quand : 100 % des sources mappées atteignent la destination 200 approuvée en un seul saut de redirection permanent ; les boucles, chaînes, redirections temporaires et destinations en erreur sont à zéro.

6. Concilier les canoniques, liens et sitemaps avec les redirections. Quoi : faire pointer l’URL canonique , les liens internes, les références hreflang, les données structurées, les flux et les sitemaps XML directement vers les URL finales. Pourquoi : rediriger les anciennes URL tout en continuant à les publier crée des signaux de migration contradictoires et gaspille des requêtes d’exploration. Comment : explorer chaque source de référence et comparer les cibles normalisées avec le plan de redirection. Outil : explorateur, HTML rendu, analyseur de sitemap et diff de configuration. Fait quand : les pages finales s’auto-canonicalisent sauf exception approuvée, les références internes vers les URL redirigées sont à zéro, et les nouveaux sitemaps contiennent uniquement des URL 200 canoniques.

Phase 3 : validation du staging

7. Tester le staging sans le rendre indexable publiquement. Quoi : explorer l’ensemble de la version de staging tout en empêchant les moteurs de recherche d’indexer l’environnement. Pourquoi : l’équipe a besoin de preuves au niveau de l’exploration sans permettre à un site dupliqué d’apparaître dans les résultats de recherche. Comment : utiliser le contrôle d’accès pour les robots externes, puis exécuter une exploration interne authentifiée avec rendu JavaScript là où le site de production en dépend. Considérer un blocage de staging comme une configuration temporaire de publication, pas quelque chose à copier aveuglément en production. Outil : explorateur authentifié, navigateur et inspection des en-têtes de réponse. Fait quand : l’inventaire attendu du staging est explorable par l’équipe de test, l’indexation publique non autorisée est bloquée, et la checklist de lancement en production supprime explicitement les contrôles propres au staging.

8. Vérifier les templates et les parcours prioritaires. Quoi : tester des pages représentatives de chaque template ainsi que la navigation, la recherche, les formulaires, l’inscription, le paiement, la localisation, la pagination, les filtres et les pages d’erreur. Pourquoi : un test réussi de la page d’accueil ne peut pas révéler un bug canonique sur les pages produit ni un état de consentement cassé qui supprime les analytics. Comment : créer une matrice appareil-par-template, tester les sessions propres et les sessions de retour, et enregistrer des captures d’écran ou des preuves de réponse pour chaque résultat. Outil : navigateur, vérificateur d’accessibilité, validateur de données structurées, débogueur analytics et tests transactionnels. Fait quand : chaque template et parcours principal dans le périmètre est validé sur les navigateurs et appareils convenus, avec zéro défaut critique ouvert.

9. Comparer le staging avec les contrats approuvés. Quoi : différencier les titres, descriptions, en-têtes, canoniques, directives robots, données structurées, liens internes, codes de réponse, contenu et balises analytics par rapport à l’ancien site et au cahier des charges des destinations. Pourquoi : les migrations de plateforme perdent souvent des métadonnées ou modifient le rendu même lorsque la copie visible semble intacte. Comment : explorer l’ancienne production et le staging avec des paramètres identiques, segmenter les différences par template, et n’approuver que les changements intentionnels. Outil : rapport de diff d’exploration et inspection des sources. Fait quand : chaque différence significative est soit corrigée, soit listée comme changement approuvé avec responsable et raison ; les modifications accidentelles de noindex, canoniques, contenu et suivi sont à zéro.

10. Geler le candidat à la publication. Quoi : geler l’inventaire des URL, le plan de redirection, les définitions de routes, les règles canoniques et robots, la génération de sitemaps, la configuration analytics et consentement, le plan DNS/CDN, et les déploiements de production sans rapport. Pourquoi : un résultat de test ne s’applique qu’à la version testée. Comment : étiqueter les livrables de publication, restreindre les modifications à la voie d’incident, et exiger un nouveau test de tout ce qui est affecté par une modification d’urgence. Outil : système de déploiement, journal des modifications et registre d’approbation. Fait quand : un candidat immuable est nommé, l’accès est restreint, toutes les exceptions ont un responsable, et chaque modification post-gel est accompagnée d’un résultat de test.

Phase 4 : jour du lancement

11. Exécuter un runbook sous responsabilité unique. Quoi : déployer le routage, l’application, le DNS/CDN, les analytics, les sitemaps et les moniteurs dans l’ordre approuvé. Pourquoi : des changements parallèles non séquencés rendent les défaillances difficiles à isoler et le rollback risqué. Comment : un chef de projet de migration appelle chaque étape, l’opérateur désigné enregistre l’achèvement, et les validateurs testent les preuves avant l’étape dépendante suivante. Outil : runbook, journaux de déploiement, vérifications DNS et canal d’incident partagé. Fait quand : chaque ligne a un horaire effectif, un opérateur, un résultat et un lien vers la preuve, et aucune dépendance n’est marquée comme complète sur la seule base d’une confirmation verbale.

12. Exécuter le test de fumée post-lancement. Quoi : tester la page d’accueil, le fichier robots, les sitemaps, au moins une URL par template, chaque parcours prioritaire, la réception analytics, et un échantillon stratifié des sources de redirection. Pourquoi : la réponse rapide la plus sûre vient de la détection d’une défaillance large avant que les caches et les robots d’exploration ne la propagent. Comment : tester depuis l’extérieur du réseau de production, utiliser le desktop et le mobile, vérifier à la fois le HTML servi par le serveur et le rendu généré, et comparer avec les attentes gelées. Outil : explorateur, navigateur, client HTTP, vue temps réel des analytics et moniteur transactionnel. Fait quand : les pages critiques retournent le statut et le contenu attendus, les redirections prioritaires atteignent leurs destinations exactes, les événements analytics arrivent avec les bonnes URL, et toutes les vérifications bloquantes du lancement sont réussies.

13. Soumettre et vérifier les signaux de découverte. Quoi : publier les sitemaps finaux, confirmer le comportement robots et canonique, et demander l’inspection d’un petit ensemble d’URL prioritaires. Pourquoi : des signaux de découverte propres aident les robots d’exploration à rencontrer l’ensemble des destinations sans traiter la soumission comme une garantie d’indexation. Comment : soumettre chaque sitemap de production une fois, inspecter les nouvelles URL représentatives, et enregistrer le canonique et l’état d’indexation rapportés par Google. Outil : Sitemaps et indexation et Inspection d’URL . Fait quand : les sitemaps sont accessibles et contiennent l’inventaire canonique gelé, les inspections représentatives ne montrent aucun blocage de production ni canonique erroné, et chaque avertissement a un responsable.

Phase 5 : surveillance post-lancement

14. Surveiller les premières 72 heures comme une fenêtre d’incident. Quoi : surveiller la disponibilité, les 5xx, 4xx, les échecs de redirection, la latence, le volume d’exploration, la réception analytics, les conversions, le traitement des sitemaps et les parcours prioritaires en continu ou à l’intervalle le plus court possible. Pourquoi : les défauts d’infrastructure et de routage apparaissent rapidement, tandis que les performances de recherche prennent plus de temps et ne devraient pas être le seul indicateur d’alerte au lancement. Comment : comparer avec la référence signée, segmenter par template et répertoire, et acheminer les alertes vers un responsable d’astreinte. Outil : journaux, analytics, explorateur, Moniteurs de disponibilité et tableau de bord d’incidents. Fait quand : le tableau de bord n’a aucune alerte critique inexpliquée liée au lancement, chaque incident a un responsable et un horodatage, et les revues à 24, 48 et 72 heures sont signées.

15. Poursuivre la surveillance de la recherche et de l’indexation après la stabilisation. Quoi : suivre les clics par page, les impressions, l’état d’indexation, les canoniques sélectionnés, les erreurs d’exploration, les performances par répertoire et les résultats de conversion pendant au moins quatre semaines. Pourquoi : l’exploration, la sélection canonique et le remplacement dans l’index accusent un retard par rapport à la validation de l’infrastructure. Comment : comparer des fenêtres comparables, séparer les URL déplacées des témoins inchangés, et investiguer les tendances plutôt que de réagir au total d’une seule journée. Outil : Pages Google Search , Vue par répertoire , Inspection d’URL, analytics et journaux. Fait quand : les destinations prioritaires sont découvrables et indexables, les anciennes URL résolvent systématiquement vers les destinations approuvées, les pertes inexpliquées ont des tickets, et la responsabilité passe dans le cadre de reporting normal.

Outils dans AmICited

AmICited fournit des surfaces de preuve de lancement et de surveillance ; le plan de redirection approuvé et les journaux de déploiement restent la source de vérité opérationnelle.

Règles de décision

Ce sont des garde-fous de publication, pas des seuils universels de moteurs de recherche. Convenez-en avant le lancement et renforcez-les là où le risque l’exige.

Le rollback rétablit un état de service connu et fonctionnel ; il n’inverse pas les fluctuations normales de recherche. L’autorité de lancement applique les règles convenues et enregistre les preuves.

Livrable

Remettez un pack de contrôle de migration versionné accessible à l’ingénierie et au SEO. Utilisez un classeur ou une base de données pour les enregistrements par ligne, un runbook pour les actions de lancement et un tableau de bord pour les mesures en direct.

Il doit contenir l’inventaire gelé et la réconciliation des sources ; le plan de redirection approuvé avec responsables et tests ; les explorations appariées de l’ancien site, du staging et du nouveau site ; les différences de métadonnées, canoniques, robots, sitemaps, hreflang, données structurées, liens et analytics ; la référence signée et les cohortes prioritaires ; le runbook de lancement et la procédure de récupération ; les règles numériques de rollback et le décideur ; ainsi que les preuves à 24, 48 et 72 heures avec la responsabilité de surveillance sur quatre semaines.

Le chef de projet de migration doit être capable d’identifier la version exacte de la publication, de prouver chaque test critique, de reconstruire chaque décision de routage et d’attribuer chaque exception. Sinon, le pack est incomplet.

Ce qui peut mal tourner

Le plan de redirection n’utilise que le sitemap actuel. Les orphelins, les URL de campagne, les backlinks et les routes précédemment indexées disparaissent, donc chaque ligne du tableur est valide alors que les requêtes réelles échouent.

La page d’accueil devient la destination par défaut. Les utilisateurs atterrissent quelque part sans rapport, les signaux pour les robots deviennent ambigus, et le contenu manquant est masqué comme une progression de l’implémentation.

Les redirections fonctionnent, mais les références restent anciennes. La navigation, le hreflang, les canoniques, les données structurées et les sitemaps continuent d’envoyer les robots d’exploration à travers des sauts inutiles et des destinations contradictoires.

La protection du staging atteint la production. Un noindex copié, une règle d’authentification, un blocage robots ou une politique CDN détruit l’indexabilité . Exigez une étape de suppression explicite et un test externe.

L’équipe ne valide que la page d’accueil. Un template partagé peut mal configurer des milliers de pages alors que la page d’accueil est valide. Échantillonnez chaque template et explorez les règles à grande échelle.

Des publications sans rapport sont livrées ensemble. Lorsque la plateforme, les analytics, le consentement, la navigation, le paiement et les changements CDN partagent une même fenêtre, les défaillances deviennent difficiles à isoler ou à inverser.

La recherche est jugée trop tôt ou trop largement. Les totaux du site masquent les répertoires défaillants et une journée volatile provoque des correctifs inutiles. Comparez les cohortes déplacées, les témoins inchangés, les répertoires et les fenêtres appariées.

Le rollback est débattu pendant l’interruption. Un bon plan nomme les seuils, le décideur, le temps de récupération, les commandes, les conséquences sur les données et la séquence de validation avant le lancement.

Phase suivante

Une fois les premières 72 heures stabilisées, l’étape suivante est l’actualisation et l’itération continues . Cela nécessite la référence signée, le mapping final des URL, les annotations de lancement, les cohortes par répertoire, les exceptions connues, l’historique des incidents et les responsables nommés issus de cette checklist. Sans ces éléments, une perte de trafic ultérieure ne peut pas être séparée de manière fiable entre dommage de migration, variation normale de la demande, dégradation du contenu ou défaillance de mesure.

Conservez le plan de redirection et l’annotation de migration en permanence. Déplacez les constats non critiques dans le cycle de reporting normal avec une gravité, une hypothèse, un responsable, une date d’échéance et une méthode de vérification.

Foire aux questions

Quand l’équipe SEO doit-elle rejoindre une migration de site ?

Avant que les routes, les templates et les contraintes de plateforme soient figées. Le SEO a besoin de suffisamment de temps pour inventorier les URL actuelles, préserver les destinations importantes, influencer la nouvelle architecture de l’information, définir le comportement des redirections, et convenir de règles mesurables de lancement et de rollback.

Les anciennes URL doivent-elles rediriger vers la page d’accueil lorsqu’il n’y a pas de remplacement direct ?

Non. Redirigez une ancienne URL vers la page la plus proche qui satisfait la même intention utilisateur. Si aucune destination pertinente n’existe et que le contenu ne doit pas être conservé, retournez un honnête code 404 ou 410 plutôt que d’envoyer les utilisateurs et les robots d’exploration vers une page d’accueil sans rapport.

Combien de temps les redirections de migration doivent-elles rester en place ?

Conservez les redirections permanentes aussi longtemps que les anciennes URL peuvent encore recevoir des visites, des liens, des favoris ou des requêtes de robots. Traitez-les comme une infrastructure de routage durable, et non comme un échafaudage de lancement à retirer après quelques semaines.

Que faut-il figer avant le lancement de la migration ?

Gelez l’inventaire des URL approuvé, le plan de redirection, les règles canoniques et robots, la génération de sitemaps, la configuration des analyses et du consentement, les modifications DNS et CDN, ainsi que les publications de production sans rapport avec la migration. Les correctifs d’urgence suivent la procédure de gestion des changements désignée.

Quand une migration doit-elle être annulée (rollback) ?

Utilisez des critères convenus avant le lancement. Effectuez un rollback pour des défaillances telles qu’une indisponibilité prolongée, des réponses 5xx généralisées, des parcours principaux rompus, une absence d’analytics, ou des défauts de routage qui affectent une part significative des URL prioritaires et ne peuvent pas être corrigés en toute sécurité dans la fenêtre de récupération convenue.