Replateformer sans perdre son référencement

Toute boutique finit par dépasser sa plateforme. Le catalogue devient trop gros, le tunnel de commande ne bouge plus sans développeur, la vitesse traîne en bas de chaque rapport, et quelqu’un finit par prononcer le mot : replateformer. (Si la question encore ouverte est quelle plateforme, c’est une décision de contraintes, pas de fonctionnalités.)

Puis, quelques mois après la mise en ligne, le trafic organique a chuté — mettons de quarante pour cent — et personne ne sait dire quand cela a commencé.

Ce dénouement est assez fréquent pour être tenu pour une fatalité. Il ne l’est pas. Presque tout se ramène à des décisions prises dans les semaines précédant le lancement, par des gens qui ignoraient alors qu’ils prenaient des décisions de référencement.

Le trafic n’a jamais été dans la plateforme

Premier point à intégrer : les moteurs ne classent pas votre plateforme. Ils classent des URL, et ils ont accumulé beaucoup d’informations sur les vôtres — lesquelles existent, ce qu’elles contiennent, lesquelles reçoivent des liens, laquelle répond à quelle requête.

Une migration menace cela de trois façons, par ordre décroissant de dégâts :

Les URL changent sans prévenir personne. C’est la catastrophe. Chaque lien externe, chaque signal de classement accumulé, chaque favori pointe vers une adresse qui renvoie désormais une 404. L’autorité accumulée par ces pages ne se transfère pas : elle s’évapore.

Le contenu s’appauvrit. Les descriptions de catégories sautent parce que le nouveau thème n’a pas de place pour elles. Les textes produits sont tronqués pour entrer dans un gabarit. La page existe toujours, mais il y a moins dessus qu’avant — et elle se classe en conséquence.

Les signaux techniques régressent. Le nouveau site est plus lent, ou affiche en JavaScript des produits que l’ancien servait en HTML, ou publie des données structurées subtilement fausses — précisément les régressions qu’un audit SEO technique mené avant la bascule sert à repérer.

Seul le premier est spectaculaire. Les deux autres sont silencieux, et ce sont eux qui produisent l’hémorragie lente que personne n’attribue à la migration.

Commencez par un inventaire, pas par une maquette

Le premier livrable correct d’un projet de replateformage n’est pas une maquette. C’est la liste complète de chaque URL servie par le site actuel et atteinte par quelqu’un.

Construisez-la à partir de quatre sources, car aucune n’est complète seule :

Le crawl. Tout ce qu’on atteint en suivant les liens depuis l’accueil.
La Search Console. Tout ce qui a reçu une impression sur seize mois. Cela rattrape les pages que le crawl manque faute de liens entrants internes — souvent d’anciennes pages de campagne qui se positionnent encore.
Les logs serveur ou l’analytics. Tout ce qui a reçu une visite. Cela rattrape les pages sans lien et sans position, mais que quelqu’un a mises en favori.
Le profil de liens entrants. Tout ce que d’autres sites pointent, y compris des pages mortes depuis des années. Une 404 qui reçoit des liens est de la valeur récupérable.

Dédoublonnez, et vous tenez ce que toute la migration devra respecter.

Attribuez une décision à chaque URL

Chaque URL de l’inventaire reçoit exactement un verdict parmi quatre, et aucun ne s’appelle « on verra » :

Conserver l’adresse. Le résultat le plus sûr. Si la nouvelle plateforme peut servir le même chemin, laissez-la faire. Chaque URL non modifiée est une redirection que vous n’avez pas à réussir.

Rediriger vers l’équivalent le plus proche. Une 301 permanente vers la page qui répond au même besoin. « Le plus proche » signifie une page qu’un visiteur venu de cette recherche jugerait raisonnable — pas l’accueil, pas une catégorie générique.

Rediriger vers le parent. Pour un produit arrêté sans successeur, la catégorie est la destination honnête.

Laisser mourir. Certaines URL doivent disparaître : combinaisons de filtres dupliquées, promotions expirées, bruit de paramètres de session. Le décider délibérément n’a rien à voir avec le découvrir après coup.

L’erreur classique est de rediriger en masse vers l’accueil tout ce qui est incertain. Les moteurs traitent une redirection massive vers la racine comme une soft 404 et écartent le signal : vous obtenez la même perte qu’en ne faisant rien, plus le travail.

Protégez la parité de contenu

Avant la mise en ligne, comparez l’ancien et le nouveau page par page sur celles qui comptent — vos meilleures URL en chiffre d’affaires et en organique, qui forment rarement la même liste.

Pour chacune, vérifiez que le titre et la structure de titres expriment toujours le même sujet, que le corps n’a pas été discrètement rogné par un gabarit, que les données structurées valident encore, que les liens internes vers elle existent toujours, et que les images ont gardé leur texte alternatif.

La troncature par gabarit est la plus sournoise. Une description de catégorie qui tenait en quatre paragraphes devient deux lignes dans un design qui n’a pas prévu la place, et la page cesse silencieusement d’être la meilleure réponse à sa requête.

Le lancement est une séquence, pas un instant

L’ordre compte plus que la vitesse :

Placez le nouveau site derrière une authentification, pour qu’il soit explorable par vous et personne d’autre. Un site de préproduction indexé par accident crée du contenu dupliqué contre votre propre boutique.
Testez le plan de redirection contre l’inventaire. Chaque URL, de façon automatisée. Vérifiez une 301 et la destination attendue, pas seulement une absence de 404 : une chaîne qui se résout en quatre sauts perd quand même du temps et du signal.
Basculez. Gardez la couche de redirection au niveau du serveur, pas dans le code applicatif, pour qu’elle survive à un retour arrière.
Resoumettez le sitemap immédiatement et laissez l’ancien accessible quelques semaines. C’est ainsi que les robots trouvent les URL à réévaluer.
Surveillez les 404 dans les logs chaque jour pendant la première quinzaine. Le trafic réel trouve des URL que votre inventaire a manquées. Chacune est une redirection encore ajoutable.

Les douze semaines suivantes

Les positions oscillent après une migration, même parfaitement exécutée. Les robots doivent revisiter chaque URL, suivre chaque redirection, réévaluer. Cela prend des semaines, et pendant ce temps les positions bougent dans les deux sens.

Le savoir est important, car l’erreur la plus coûteuse d’un replateformage est de paniquer en troisième semaine et d’annuler un changement qui fonctionnait.

Jugez sur trois indicateurs plutôt que sur un suivi quotidien de positions : le nombre de pages indexées remonte-t-il vers le niveau précédent, les 404 dans les logs tendent-elles vers zéro, et les pages identifiées comme meilleures URL organiques tiennent-elles. Si ces trois-là sont saines, l’oscillation est normale.

Si les pages indexées continuent de baisser après six semaines, quelque chose cloche dans le plan de redirection, et il vaut mieux relancer l’inventaire contre les données de crawl réelles avant de toucher à autre chose.

Ce qui rend l’opération sûre

Une migration qui conserve ses positions paraît ennuyeuse vue de l’extérieur. Rien de spectaculaire ne se produit le soir du lancement, parce que le travail difficile a eu lieu des semaines plus tôt, dans un tableau que personne n’avait envie de construire.

La boutique qui perd ses quarante pour cent est rarement celle au design le plus faible ou à la plateforme la moins solide. C’est celle où personne n’a fait l’inventaire des URL, et où chaque décision de redirection a été improvisée la dernière semaine par quelqu’un qui ignorait quelles pages portaient la structure.

C’est aussi pourquoi l’inventaire est le premier livrable de chaque migration e-commerce que nous menons — pas une faveur faite à l’équipe SEO, mais le filet de sécurité du projet.