La checklist migration SEO que je tiens le jour de la bascule ressemble à celle de n'importe quel développeur : sauvegarde, redirections, SSL, robots.txt, sitemap, Search Console, contrôle du lendemain. Mais ce qui change, c'est ce que je fais de chaque ligne avant de la cocher. Une case cochée sans test ne protège rien ; elle donne juste l'illusion que le travail est fait, jusqu'au moment où un client ou Google découvre le contraire.
Ce qui se décide avant la bascule relève du plan de migration et du fichier de correspondance entre anciennes et nouvelles adresses. Ici, je vérifie : le jour J, et le lendemain matin.
La checklist migration SEO en un tableau
| Case | Test pour la cocher | Symptôme si elle est ratée |
|---|---|---|
| Sauvegarde | Restauration sur une copie | Archive illisible le jour où il faut l'ouvrir |
| Redirections 301 | Rejouer chaque ancienne adresse | 404 et visiteurs renvoyés vers l'accueil |
| SSL | Vérifier toutes les variantes d'adresse | Alerte de sécurité dans le navigateur |
| robots.txt et indexation | Lire le fichier en ligne | Site entier bloqué pour les robots |
| Sitemap | Ouvrir le fichier XML envoyé | Erreur ou pages absentes dans Search Console |
| Search Console | Confirmer la propriété du nouveau domaine | Données qui n'arrivent plus |
| Contrôle du lendemain | Comparer indexation et trafic à J+1 | Chute silencieuse découverte trop tard |
Imprimez ce tableau, donnez le stylo à une seule personne, et faites en sorte que chaque case porte une preuve.
1. Sauvegarde : la restaurer sur une copie
Lancer une sauvegarde ne prouve rien ; elle peut être incomplète, corrompue, ou trop ancienne sans que personne ne s'en aperçoive avant d'en avoir besoin. Le test consiste à restaurer cette sauvegarde sur une copie du site, fichiers et base de données ensemble, et à vérifier qu'elle porte bien la date de la veille de la bascule.
Le symptôme d'une case ratée est précis : une archive qui existe sur le disque mais qui refuse de s'ouvrir, ou qui restaure un site vieux de plusieurs mois, le jour où la migration tourne mal et qu'il faut revenir en arrière dans l'urgence.
2. Redirections 301 : rejouer la liste ligne par ligne
Le fichier de correspondance ne sert à rien tant que personne ne l'a testé adresse par adresse. Le test : rejouer chaque ancienne URL listée dans le mapping, vérifier que le code retourné est bien 301, qu'il n'y a qu'un seul saut vers la nouvelle adresse, et que cette destination répond en 200.
Le symptôme se voit tout de suite dans les pages les plus visitées : des 404 à la place de la page attendue, ou pire, une redirection qui atterrit systématiquement sur l'accueil. C'est le signe d'un mapping pensé mais jamais vérifié, et ce sont des visiteurs qui repartent sans trouver ce qu'ils cherchaient.
3. SSL : le cadenas sur toutes les variantes d'adresse
Un certificat valide sur une seule version de l'adresse ne protège pas le site entier. Le test couvre toutes les variantes : avec www et sans www, en forçant le passage de http vers https, sur le nouveau domaine complet.
Le symptôme d'échec arrive en pleine figure : une alerte de sécurité dans le navigateur, ce message rouge qui déconseille de continuer. Un visiteur qui voit ça ne remplit pas de formulaire et ne passe pas commande ; il ferme l'onglet.
4. robots.txt et noindex : ouvrir la porte à Google
Un fichier qui bloque tout, et Google n'a plus rien à explorer. Le test se fait en ouvrant l'adresse du robots.txt servie en production, celle du nouveau site. Vous devez y lire une autorisation d'exploration ; une seule ligne qui interdit tout suffit à fermer le site entier aux robots. Ensuite, dans le code des pages qui comptent (accueil, catégories, fiches qui vendent), cherchez la balise noindex. Elle ne doit pas y être. Le symptôme d'une case ratée ne fait pas de bruit : pas d'erreur, pas d'alerte visible tout de suite. Les pages sortent de Google une par une, sans message d'échec. Le noindex oublié depuis la préproduction est une des façons les plus simples de sortir un site entier de Google sans le savoir.
5. Sitemap : le fichier qui liste les nouvelles adresses
Le sitemap dit à Google où regarder. S'il pointe encore vers l'ancien site, vous envoyez Google explorer des pages qui n'existent plus. Le test tient en trois points. Le fichier répond quand vous l'ouvrez dans le navigateur. Chaque adresse qu'il contient renvoie un code 200, sans redirection ni erreur. Et aucune ancienne URL ne traîne dedans. Le symptôme d'un sitemap mal généré se lit dans Search Console : des adresses explorées qui sont en réalité des redirections, ou pire, des pages mortes que Google continue de visiter parce que personne ne lui a dit d'arrêter.
6. Search Console : la propriété, l'envoi, le changement d'adresse
Sans Search Console, vous pilotez à l'aveugle le jour où tout bouge. Le test : la propriété du nouveau domaine existe et elle est vérifiée. Le sitemap y est envoyé, et Search Console indique qu'il a été lu. Si le domaine change (et seulement dans ce cas), l'outil de changement d'adresse est lancé depuis l'ancienne propriété vers la nouvelle. Le symptôme d'une case ratée est un silence complet : aucune donnée qui remonte, aucun signal, pendant que le trafic réel, lui, bouge déjà. Vous découvrez donc le problème plus tard, quand il est devenu plus difficile à corriger.
7. Le contrôle du lendemain matin
C'est la case qu'on oublie parce qu'on pense que le travail est fini la veille au soir. Le lendemain matin, vous ouvrez Search Console et vous regardez les 404 qui remontent. Vous relancez un crawl du site et vous comparez. Puis vous ouvrez une par une les pages qui rapportent, celles qui amènent des demandes. Et vous envoyez un vrai formulaire de contact, jusqu'à recevoir le mail dans votre boîte. Le symptôme d'une case ratée ici ne s'affiche nulle part : c'est une demande de devis qui part dans le vide, parce qu'un formulaire pointe vers une adresse qui n'existe plus, et que personne ne le sait avant qu'un client s'en plaigne, ou pire, ne s'en plaigne jamais. Les rendez-vous suivants, à sept jours puis à trente jours, sont décrits dans le plan de migration SEO.
Qui coche la checklist migration SEO
Chaque case doit porter un nom, celui de la personne qui a fait le test. C'est ce qui permet de savoir, le lendemain, ce qui a vraiment été vérifié. Plus de dix ans de terrain et plus de cinquante projets menés de bout en bout m'ont appris qu'une case sans signature finit toujours par être remise en question au mauvais moment. Chez Ad Majoris, plus de mille pages WooCommerce ont migré sans perte de référencement. Chez Skinobs, plus de cinq mille articles WordPress ont migré, sans perte de référencement non plus. Si votre migration accompagne une refonte, je tiens cette checklist dans le projet : parlons de votre refonte de site web.