Chaque semaine, quelqu'un se présente en voulant migrer un vrai site — un site avec du trafic, des liens entrants, quelques années de confiance accumulée auprès de Google. Pas une idée toute fraîche, pas un prototype. Une entreprise existante qui a quelque chose à perdre. C'est un exercice différent que de partir d'une invite vierge, et la majeure partie des difficultés que j'ai observées vient du fait de traiter les deux cas de la même manière.
Il y a trois façons de se tromper, si fréquentes que je peux prédire le ticket d'assistance avant même d'avoir fini de lire l'objet. La bonne méthode n'a rien de sophistiqué. C'est simplement ce à quoi on arrive une fois qu'on a cessé de commettre ces trois erreurs.
Erreur numéro un : déverser l'ancien contenu tel quel en espérant que la structure s'organise d'elle-même
L'instinct est compréhensible. Vous avez un site, il contient du texte, alors vous collez ce texte dans le chat et demandez au créateur de site de « l'améliorer ». Ce qui en ressort est généralement un site qui a l'air neuf mais qui se lit comme l'ancien — les mêmes paragraphes de service interminables, les mêmes trois titres qui font le travail de quinze, désormais enveloppés dans un plus joli modèle. Le créateur de site a fait ce que vous lui avez demandé. Vous lui avez demandé de redécorer, pas de repenser.
Les dégâts apparaissent environ six semaines plus tard, quand le classement du nouveau site se retrouve exactement là où était l'ancien, voire légèrement en dessous. Rien ne s'est amélioré car rien n'a réellement changé dans l'architecture de l'information : la même page plate pour un service qui aurait dû être réparti sur trois pages, le même contenu de FAQ manquant sur lequel le site d'un concurrent se positionne depuis un an. Un coup de peinture neuf sur une maison mal agencée reste une maison mal agencée.
J'ai eu une cliente avec une page « Services » de 4 000 mots couvrant onze offres distinctes. Elle voulait la migrer telle quelle car « ça a toujours marché ». Ça n'avait jamais marché — elle ne se positionnait sur rien de précis parce qu'elle parlait de tout à la fois. La migrer fidèlement n'aurait fait qu'obtenir une plus jolie version de la même page qui ne se classait nulle part.
Ce qui fonctionne réellement, c'est de traiter la migration comme un audit avant d'en faire une construction. Injectez l'ancien contenu, mais demandez d'abord un inventaire du contenu : quelles pages existent, sur quoi chacune tente réellement de se positionner, où deux sujets sont entassés dans une seule URL et où un seul sujet est étalé trop finement sur cinq. Cet inventaire devient le plan. L'ancien site est une source, pas un modèle à reproduire.
Erreur numéro deux : oublier que les URL sont la chose que Google fait réellement confiance
C'est l'erreur qui coûte cher. Une migration de site qui change la structure des URL sans faire correspondre les anciennes adresses aux nouvelles — même quand le nouveau contenu est réellement meilleur — jette aux orties des années de signal accumulé. Les liens entrants pointent vers une erreur 404. Google doit re-crawler et regagner la confiance de pages qu'il avait déjà accordée à une adresse différente. Le trafic direct issu de favoris ou de signatures d'e-mails aboutit dans une impasse.
J'ai vu des gens s'en apercevoir seulement après le lancement, quand le tableau de bord analytique affiche une chute plutôt qu'un pic. À ce stade, la solution consiste à ajouter des redirections après coup, ce qui récupère une partie de la perte mais pas la totalité — l'écart entre « l'URL a changé » et « quelqu'un s'en est aperçu et l'a corrigé » se mesure en semaines de capital perdu qu'on ne récupère jamais.
| Ancienne approche | Ce qui se casse | Ce qu'il faut faire à la place |
|---|---|---|
| Laisser le créateur de site générer la structure d'URL qui convient au nouveau design | Chaque lien entrant et favori pointe désormais vers une erreur 404 | Exporter d'abord le sitemap de l'ancien site, faire correspondre chaque URL existante à son équivalent avant de commencer la construction |
| Ne rediriger que la page d'accueil et laisser les pages internes en 404 | Les pages profondes portent chacune leur propre capital de liens — les perdre une à une s'accumule | Rediriger en 301 chaque URL significative de l'ancien site, même celles fusionnées dans une page plus large |
| Ajouter les redirections « plus tard, une fois le site en ligne » | Les robots d'indexation et les utilisateurs qui cliquent tombent sur des impasses précisément pendant la période où le trafic est le plus volatile | Les redirections passent en ligne au même moment que le nouveau site, pas après |
Rien de tout cela n'a rien d'exotique. C'est un tableur à deux colonnes, préparé avant que quiconque ne touche au créateur de site. C'est simplement l'étape que les gens sautent parce qu'elle est ennuyeuse et que la construction elle-même est la partie amusante.
Erreur numéro trois : la bascule brutale et sans retour en arrière possible
Le troisième mode d'échec ne concerne ni le contenu ni les URL — il concerne la manière dont le basculement se produit réellement. Quelqu'un construit le nouveau site, apprécie ce qu'il voit en prévisualisation, et pointe le domaine vers ce site l'après-midi même. Aucune période de préproduction, aucune comparaison côte à côte sous trafic réel, aucun plan pour le cas où quelque chose serait cassé sans que la prévisualisation ne l'ait détecté — un formulaire de contact qui échoue silencieusement, un tunnel de paiement qui fonctionne en test mais s'étouffe sous un volume de transactions réel, une page qui s'affiche parfaitement sur ordinateur mais casse précisément sur le modèle de téléphone qu'utilise la moitié de vos clients.
Les dégâts, ici, sont du genre le plus bruyant car ils sont immédiats. Les boîtes de réception du support se remplissent. Quelqu'un rafraîchit les statistiques toutes les dix minutes en regardant un graphique évoluer dans le mauvais sens, et revenir en arrière signifie repointer le DNS à nouveau, ce qui prend du temps à se propager, ce qui signifie que la mauvaise expérience persiste même après avoir décidé de faire marche arrière.
La solution n'a rien de glorieux : abaisser le TTL du DNS un jour ou deux avant la bascule pour que tout retour en arrière se propage rapidement si nécessaire, faire tourner le nouveau site sur un sous-domaine de prévisualisation ou de préproduction et l'utiliser réellement comme le ferait un client, et conserver l'hébergement de l'ancien site actif et intact pendant au moins deux semaines après la bascule plutôt que de le démonter dès que le nouveau est en ligne. Ce dernier point coûte quelques dollars d'hébergement pour une véritable assurance. Les gens sautent cette étape parce qu'annuler l'ancien forfait donne l'impression de boucler la boucle, et boucler une boucle donne l'impression d'avancer.
À quoi ressemble réellement la bonne méthode
Mis bout à bout, rien de tout cela ne représente plus de travail que les mauvaises versions — c'est la même quantité de travail, simplement dans un ordre différent. Auditer avant de reconstruire. Faire correspondre les URL avant de lancer. Préproduire avant de basculer, et garder un moyen de revenir en arrière pendant quelques semaines après l'avoir fait. Le site qui en ressort n'a pas seulement l'air plus récent. Il conserve tout ce que l'ancien avait déjà gagné, ce qui était tout l'intérêt de migrer plutôt que de repartir de zéro.
