Checklist de migration de site (PDF)

Une checklist de validation de migration de site imprimable : phases avant lancement, jour du lancement et post-lancement, avec cases à cocher et lignes de signature des responsables pour que rien ne parte sans vérification.

Utilisez cette checklist comme feuille de validation imprimable pour une migration de site, la page que chaque responsable coche et signe avant et après le go-live. Chaque variante est une phase, de la planification et des sauvegardes au jour du lancement, jusqu'au suivi post-lancement, se terminant par une validation formelle. Imprimez-la, parcourez-la phase par phase et n'avancez pas tant que le responsable n'a pas validé la phase. Cela rend une migration responsable au lieu de reposer sur la mémoire et les bonnes intentions.

6 variantes prêtes à l'emploi

Phase 1 : Planifier et sauvegarder

Verrouillez le plan et réalisez des sauvegardes complètes avant que quiconque ne modifie une seule URL.

Objectif : s'assurer que la migration est réversible et entièrement planifiée avant le début du travail.

Cochez avant de commencer

☐ Sauvegarde complète du site actuel (fichiers et base de données) réalisée et restauration testée
☐ Crawl complet de l'ancien site exporté et enregistré
☐ Mapping d'URL (ancien vers nouveau) ébauché pour chaque page
☐ Point de référence analytics et Search Console enregistré : [instantané trafic / positions]
☐ Plan de rollback rédigé et validé avec le responsable dev
☐ Fenêtre de lancement planifiée aux heures de faible trafic : [Date / heure]

Validation phase 1
Responsable : [Nom] Date : [Date] Signé : [Signature]

Phase 2 : QA sur staging

Vérifiez le nouveau site sur staging pour que les problèmes soient repérés avant qu'ils ne deviennent publics.

Objectif : confirmer que le nouveau site est correct et explorable tant qu'il est encore privé.

Cochez sur staging

☐ Redirections testées sur staging et renvoyant les codes attendus
☐ Titres, meta descriptions et en-têtes présents sur les pages clés
☐ Balises canonical pointant vers les nouvelles URL
☐ Liens internes mis à jour vers les nouvelles URL, aucun lien vers l'ancien domaine
☐ robots.txt autorisera l'exploration au lancement (noindex de staging retiré au go-live)
☐ Sitemap XML généré avec les nouvelles URL et validé
☐ Rendu mobile et vitesse des pages vérifiés sur les templates clés

Validation phase 2
Responsable : [Nom] Date : [Date] Signé : [Signature]

Phase 3 : Jour du lancement

La séquence de go-live, cochée dans l'ordre à mesure que chaque étape s'achève.

Objectif : exécuter la bascule proprement et confirmer l'essentiel au moment où le site est en ligne.

Cochez pendant le lancement

☐ noindex / protection par mot de passe de staging retirés
☐ Redirections déployées en production
☐ robots.txt en ligne et autorisant l'exploration du nouveau site
☐ Nouveau sitemap soumis dans la Search Console
☐ Analytics et tags de suivi confirmés comme se déclenchant sur le nouveau site
☐ Un échantillon d'anciennes URL haute priorité confirmé manuellement en redirection
☐ Certificat SSL valide sur l'ensemble du nouveau domaine

Validation phase 3
Lancé par : [Nom] Heure de mise en ligne : [Heure] Signé : [Signature]

Phase 4 : Premières 48 heures

Attrapez les erreurs qui n'apparaissent qu'une fois qu'un vrai trafic atteint le site en ligne.

Objectif : trouver et corriger les pannes du jour du lancement avant qu'elles ne coûtent des positions.

Cochez sous 2 jours

☐ Crawl complet du site en ligne effectué ; 404 et redirections cassées consignées
☐ Chaînes et boucles de redirection vérifiées et éliminées
☐ Search Console vérifiée pour les erreurs d'exploration et les avertissements de couverture
☐ Taux d'erreurs serveur et temps de chargement surveillés : [statut]
☐ Pages haute priorité confirmées indexables et renvoyant 200
☐ Tout contenu perdu lors du déplacement restauré ou signalé : [notes]

Validation phase 4
Responsable : [Nom] Date : [Date] Signé : [Signature]

Phase 5 : Suivi des semaines 1 à 4

Observez la stabilisation des positions, de l'indexation et du trafic pour traiter tôt les vraies baisses.

Objectif : confirmer que la migration a tenu et agir sur tout ce qui a glissé.

Cochez au cours du premier mois

☐ Indexation des nouvelles URL en progression dans la Search Console
☐ Positions des mots-clés prioritaires comparées au point de référence d'avant lancement
☐ Trafic organique suivi par rapport à la même période du cycle précédent : [tendance]
☐ Toute page ayant perdu des positions examinée et corrigée
☐ Backlinks pointant vers d'anciennes URL se résolvant encore via les redirections
☐ Ancien sitemap retiré une fois les nouvelles URL indexées

Validation phase 5
Responsable : [Nom] Date : [Date] Signé : [Signature]

Phase 6 : Validation finale

Clôturez le projet une fois la migration vérifiée comme stable et responsable.

Objectif : clôturer formellement la migration avec chaque responsable de phase redevable.

Confirmez avant de clôturer

☐ Toutes les phases précédentes validées
☐ Aucune 404 en suspens ni redirection cassée sur les pages prioritaires
☐ Trafic et positions dans une fourchette acceptable par rapport au point de référence, ou en récupération conforme au plan
☐ Problèmes ouverts consignés avec responsables et échéances : [liste]
☐ Rapport post-migration partagé avec les parties prenantes

Validation du projet

Responsable SEO : [Nom] Date : [Date] Signé : [Signature]

Responsable dev : [Nom] Date : [Date] Signé : [Signature]

Approbateur : [Nom] Date : [Date] Signé : [Signature]

Comment utiliser ce modèle

Imprimez la checklist et attribuez un responsable nommé à chaque phase avant tout début de travail.
Terminez la phase 1 : réalisez et testez une sauvegarde complète, enregistrez les points de référence et validez un plan de rollback.
Traitez la phase 2 entièrement sur staging pour que redirections, métadonnées et explorabilité soient vérifiées en privé.
Exécutez la séquence de lancement de la phase 3 dans l'ordre et confirmez redirections et suivi au moment de la mise en ligne.
Sous 48 heures, crawlez le site en ligne à la recherche de 404 et de problèmes de redirection et corrigez-les vite.
Surveillez l'indexation, les positions et le trafic sur les semaines 1 à 4 et examinez tout ce qui glisse.
Exigez que le responsable de phase signe chaque phase avant que la migration ne passe à la suivante.
Ne finalisez la validation finale qu'une fois les pages prioritaires propres et le rapport remis aux parties prenantes.

Conseils pro

Traitez chaque ligne de signature comme une vraie porte, pas une formalité : une phase non signée signifie que le travail n'est pas vérifié, et le travail non vérifié est là où les migrations perdent du trafic.
Réalisez et testez la restauration de votre sauvegarde avant de toucher à quoi que ce soit ; un plan de rollback que vous n'avez jamais testé est un espoir, pas un plan.
Planifiez le lancement à des heures vraiment creuses pour que les inévitables correctifs de la première heure touchent le moins d'utilisateurs possible.
Continuez la surveillance pendant un mois entier ; les positions et l'indexation se stabilisent progressivement, et les pires baisses surgissent souvent une à deux semaines après le lancement, pas le premier jour.

Questions fréquentes

Pourquoi un PDF imprimable plutôt qu'un tableur ?

Une feuille de validation concerne la responsabilité, pas les données. L'imprimer et faire cocher et signer chaque responsable impose un arrêt délibéré à chaque porte. Elle se marie bien avec un tableur de mapping d'URL, qui gère le détail ligne par ligne, tandis que cette feuille confirme que chaque phase a bien été réalisée et assumée.

Combien de temps avant le lancement la phase 1 doit-elle démarrer ?

Commencez la planification et les sauvegardes bien avant la fenêtre de lancement, idéalement des semaines à l'avance pour un grand site. Précipiter le plan et le mapping est à l'origine de la plupart des dommages évitables d'une migration. Plus tôt le crawl, le mapping et le plan de rollback existent, moins de pression retombe le jour du lancement.

Quelle est la phase la plus importante ?

Honnêtement, le QA sur staging de la phase 2 et le crawl à 48 heures de la phase 4 attrapent le plus. Tester les redirections avant le lancement et recrawler juste après couvre les plus grandes sources de perte de trafic. Cela dit, sauter la sauvegarde en phase 1 est la seule erreur que vous ne pouvez vraiment pas défaire.

Dois-je m'attendre à une baisse de trafic après la migration ?

Une brève baisse pendant que les moteurs de recherche recrawlent et réindexent est courante, même sur une migration propre. Ce qui compte, c'est que la tendance se rétablisse en quelques semaines. Une baisse qui continue de s'aggraver pointe généralement vers des redirections cassées, du contenu perdu ou des problèmes d'indexation que la phase de suivi est conçue pour attraper.

Qui doit signer chaque phase ?

La personne réellement responsable de ce travail : généralement un développeur pour le lancement et les redirections, et un responsable SEO pour le QA et le suivi. Un approbateur final signe l'ensemble du projet. De vrais noms sur chaque ligne indiquent clairement qui a vérifié quoi, si quelque chose doit être réexaminé plus tard.

Puis-je réutiliser ceci pour un changement plus petit comme une refonte ?

Oui, même si vous pouvez sauter les phases qui ne s'appliquent pas. Une refonte qui garde les URL inchangées demande moins de travail de redirection mais bénéficie tout de même du QA sur staging, d'une sauvegarde et d'un suivi post-lancement. Réduisez la feuille aux phases qui correspondent à la portée de votre changement précis.