La question qui revient à chaque fois que je discute avec un responsable e-commerce ou un rédacteur web qui vient de changer de CMS : « pourquoi mon trafic s'est effondré alors que mes redirections sont en place ? » La réponse tient rarement à une erreur spectaculaire. Elle tient à une somme de petits oublis qui, mis bout à bout, coûtent des mois de visibilité.
Une migration de site web, c'est un déménagement. On peut avoir les clés du nouveau logement, les meubles livrés et les cartons étiquetés, si l'on a oublié de dire à la poste où transférer le courrier, les factures n'arrivent plus. Le référencement naturel fonctionne exactement pareil : le contenu est là, mais les moteurs ne savent plus où le chercher. Voici la checklist que j'utilise désormais, avec les erreurs que j'ai commises pour arriver à la version actuelle.
Points clés à retenir
- Inventorier les URL avant toute bascule, avec un crawl complet et une exportation des statistiques sur 12 mois.
- Chaque URL qui générait du trafic ou recevait des liens doit avoir une destination, idéalement en 301 directe, jamais via une chaîne de redirections.
- Le protocole de recette se fait sur un environnement de préproduction protégé par mot de passe, pas sur le site en ligne.
- La Search Console « changement d'adresse » n'est utile que pour un changement de domaine, pas pour une refonte interne.
- Les redirections doivent rester en place au moins un an, en pratique de façon permanente.
- La surveillance post-bascule se mesure en semaines, pas en jours.
La checklist SEO d'une migration de site web qui ne fait pas perdre de trafic
Une migration réussie ne se joue pas le jour J. Elle se joue dans les trois semaines qui précèdent. La bascule d'un site, dans mon expérience, c'est 20 % de technique et 80 % de préparation documentaire. Un de mes clients, une PME industrielle, a divisé son trafic organique par presque deux après une refonte menée sans inventaire préalable. Nous avons mis onze semaines à revenir au niveau antérieur, uniquement parce que 340 URL n'avaient pas de correspondance et retombaient sur la page d'accueil.
Étape 1 — inventorier ce que vous avez, vraiment
Avant de toucher à quoi que ce soit, exportez. Toutes les URL connues, avec leurs statistiques de clics et d'impressions sur les douze derniers mois, ainsi que leurs liens entrants. Un crawler comme Screaming Frog ou Sitebulb fait le travail en une heure sur un site de quelques milliers de pages, à condition d'être paramétré pour inclure les balises canoniques, les codes de réponse et les directives de robots.
Le piège classique : ne crawler que les pages du menu. Les pages orphelines, celles qui ne sont liées par aucun menu mais qui captent du trafic par les liens externes, sont précisément celles qu'on oublie. Sur un ancien projet de blog, 60 % de mon trafic venait de billets que je n'avais pas mis en avant. Aucun n'apparaissait dans la navigation principale.
Étape 2 — construire la table de correspondance URL à URL
C'est la pièce centrale du dossier. Un tableur, deux colonnes : ancienne URL, nouvelle URL. Chaque ligne doit être justifiée. Trois cas se présentent :
- La page existe à l'identique : redirection 301 vers son nouvel emplacement.
- La page fusionne avec une autre : choisissez la destination qui conserve le plus de contenu et de liens entrants.
- La page disparaît : décidez entre une 410 (assumée, propre) et une redirection vers la page la plus proche thématiquement. Dans les deux cas, documentez le choix.
J'ai longtemps cru qu'une chaîne de redirections A → B → C était acceptable. Elle ne l'est pas : chaque saut dilue le signal et ralentit le chargement. Les redirections doivent aller directement de l'ancienne URL vers la destination finale.
Étape 3 — la recette technique sur environnement de test
Voilà l'étape que presque tous les guides survolent. Concrètement, on ne teste pas sur le site en ligne. On prépare un environnement de préproduction, protégé par mot de passe, et on y vérifie une série de points précis :
- Le fichier robots.txt ne bloque pas l'indexation par erreur (l'oubli le plus fréquent, et le plus coûteux).
- Les balises canoniques pointent vers les bonnes URL, en version absolue.
- Les codes de réponse de chaque URL testée correspondent au mapping.
- Les balises hreflang, si le site est multilingue, se correspondent bien entre elles.
- Le sitemap XML est généré et ne contient aucune URL en erreur.
- Les pages critiques (accueil, catégories, fiches produit, articles) s'affichent correctement sur mobile.
Sur un site multilingue, la gestion du hreflang est souvent la partie qui casse. Chaque version linguistique doit avoir sa propre URL, et les déclarations doivent se répondre mutuellement. Une version anglaise qui pointe vers une version française qui ne la déclare pas en retour, et les moteurs interprètent le tout comme un doublon.
Changement de domaine ou refonte à URL constante : deux checklists distinctes
La confusion entre ces deux scénarios est une source d'erreurs fréquentes. Une refonte graphique qui conserve le domaine et l'arborescence d'URL ne nécessite pas de déclaration de changement d'adresse dans la Search Console. Un changement de domaine, si. Et un changement de domaine sans conservation des anciennes URL exige les deux dispositifs.
| Scénario | Déclaration Search Console | Redirections 301 | Durée de maintien |
|---|---|---|---|
| Refonte, URL conservées | Non | Aucune nécessaire | — |
| Refonte, URL modifiées | Non | Oui, page par page | Permanent |
| Changement de domaine | Oui, outil dédié | Oui, toutes les URL | Au moins 12 mois |
La déclaration de changement d'adresse reste une formalité déclarative : elle aide, mais ne remplace jamais le travail de redirection. J'ai vu des équipes cocher la case dans la Search Console et considérer le sujet réglé. Le trafic n'est jamais revenu.
Le jour J et les premières semaines : ce qu'il faut surveiller
Une fois la bascule faite, la première chose à vérifier n'est pas le classement, c'est l'indexation. Le lendemain, contrôlez que les nouvelles URL apparaissent bien dans les résultats de recherche, et que les anciennes renvoient bien un code 301. Si vous voyez des 302, des 404 ou des boucles de redirection, corrigez immédiatement. Un moteur qui rencontre une mauvaise redirection la mémorise parfois pour plusieurs semaines.
Ensuite, surveillez trois indicateurs pendant au moins six semaines : le nombre de pages indexées, les impressions par page, et les erreurs d'exploration signalées. Un retour progressif au niveau antérieur prend souvent entre quatre et douze semaines, selon l'ancienneté du site et la densité de liens internes. C'est frustrant, mais c'est normal. Le réflexe de tout modifier en urgence dès la première baisse est souvent contre-productif.
Faut-il prévoir un plan de retour arrière ?
Oui, et ce point est rarement abordé. Avant la bascule, assurez-vous de pouvoir revenir à l'ancienne version en quelques minutes. Conservez une copie complète du site précédent, avec ses URL et ses redirections prêtes à être réactivées. Si les erreurs détectées dans les premières 48 heures sont trop importantes, un retour arrière rapide limite les dégâts. J'ai dû l'utiliser une fois : un module de paiement cassé, détecté trois heures après la mise en ligne. Nous avons réactivé l'ancien site le temps de corriger, et la perte de trafic a été quasi nulle.
Que faire des pages supprimées qui n'ont pas d'équivalent ?
Deux options se défendent. La redirection vers la page la plus proche thématiquement préserve le signal, à condition que le contenu soit réellement proche. Sinon, une réponse 410 indique clairement que la page n'existe plus, et le moteur la retire plus rapidement qu'avec une 404 maintenue en place. Le bon choix dépend du contenu : une page devenue obsolète sans équivalent mérite une 410 ; une fiche produit remplacée par une autre mérite une 301.
Combien de temps faut-il garder les redirections actives ?
Permanent signifie permanent. Je recommande de les conserver indéfiniment pour les URL qui ont reçu des liens externes. Les moteurs traitent la 301 comme un transfert définitif, mais les liens qui pointent encore vers l'ancienne adresse ne disparaissent pas par magie. Supprimer les redirections au bout d'un an revient à couper un pont que des visiteurs empruntent encore.
La migration d'un site ne s'évalue pas sur le jour de la bascule. Elle s'évalue six mois plus tard, quand on regarde les courbes et qu'on constate, presque à sa surprise, que plus rien ne bouge. C'est à ce moment-là qu'on peut vraiment fermer le dossier.
