J’avais écrit il y a quelques années un post avec un ensemble d’étapes à suivre pour la migration de son site en référencement (suite à quelques expériences menées pour des migrations. Aujourd’hui, j’avais surtout envie de partager avec vous les raisons qui font que ma dernière grosse migration a réussi.

L’été passé, le nouveau site de mon client (eCommerce qui vend à l’international) a été mis en ligne. Cette nouvelle version, principalement sur le plan technique, nécessitait des changements d’URL pour des pages cruciales d’un point de vue business.

A cela s’est ajouté d’autres modifications qui ont impacté indirectement les performances SEO (nouveau framework JS, nouveaux DNS et nouveau CDN).

2 postes en 1 pour encore + de fun

En manque de ressource, la direction a décidé de me mettre gestionnaire de produit (product owner) en plus du SEO pour ce nouveau site. « Arnaud, t’es le seul de l’équipe qui comprend la technique et le marketing donc on a besoin de toi là-dessus ». Ce cadeau empoisonné m’ayant rajouté beaucoup de responsabilités sur le dos m’a également permis de faire un bon en avant côté compétences puisqu’il fallait pouvoir jouer un bonhomme à deux casquettes.

Pour être honnête avec vous, j’ai même aimé ce post et tout ce qui va avec, à tel point que j’ai passé et obtenu ma certification PSPO.

Travaillant dans un environnement agile avec une équipe de 8 développeurs et 1 scrum master, je ne vous cache pas que mes journées étaient bien remplies. Je ne t’ennuyais jamais et j’ai vite réalisé que le site web allait un peu devenir mon « bébé à développer ».

Gestion des priorités au niveau des incréments, savoir piloter le « scrum meeting planning », le « scrum meeting retrospective » et le « scrum meeting review », batailler avec les stackholders, protéger le scope du produit comme un requin, ajuster le scope en fonction des besoins internes/clients et assister l’équipe lorsqu’elle en avait besoin faisait partie de mon quotidien.

Vous vous imaginez que je courais un peu dans tous les sens, qu’il fallait être précis dans mes paroles, qu’il fallait dealer avec les différents individus et surtout différents caractères et enfin qu’il fallait considérer le produit dans son intégralité.

Les collaborateurs les plus chiants ont été les rares qui tentaient de contourner l’organisation du développement du produit pour intégrer leur fonctionnalité de merde en forçant le tout alors qu’on partait sur du « featured parity »… Les bon relouds de la boîte qui vivent encore en mode tunnel et pensent juste à leur pomme avant de penser au développement de la business.

En tant que product owner, un des challenge est de réussir à mettre tout le monde sur le même bateau et de les faire ramer à la même vitesse, en respectant les règles, tout en évitant que certains s’enfuient avec des barques ou tentent d’alourdir de façon avec des trucs inutiles.

Ce n’était pas facile mais durant 7 mois, j’ai beaucoup appris et je me suis confronté à pas mal de nouveautés dans mon quotidien.

Bref, le but de ce post n’est pas de vous parler de la méthodologie agile et de SCRUM mais + de vous mettre un peu le contexte (car je vois que ça fait pas mal de paragraphe que je vous parle de ça). Et surtout, j’étais assis avec l’équipe de développement et ça, ça fait une différence considérable dans tes chances de réussite d’un point de vue SEO et produit.

Ce qui a fait que la migration SEO s’est faite sans embûche

Avant de démarrer, voici un schéma résumant la phase de transition depuis le canal organique (j’ai exclu volontairement le trafic organique pointant vers la homepage) :

A peine 3 semaines pour revenir à la normale et même faire mieux : victory !

 

Ce genre de migration est pour moi ce que j’appelle une transition réussie d’un point de vue SEO. On lance le nouveau site avec toutes les règles de redirections, on constate une phase de transition avec une petite baisse de 9-10% et quelques semaines plus tard, ça revient à la normale.

D’un point de vue concret, voici les éléments qui ont fait que cette migration a été une réussite :

1. Savoir rédiger les besoins de façon fonctionnelle ET avec précision (et une petite couche de technique si nécessaire)

La gestion du backlog faisant partie de mes tâches, le fait d’avoir un background 50% technique / 50% Marketing m’a énormément aidé pour formuler l’ensemble des besoins de ce nouveau site et pouvoir les prioriser. Quand une équipe de dév trouve que ton backlog respire la clarté, tu pars déjà du bon pied.

J’ajouterais également que j’ai été 100% honnête avec tous les développeurs de mon équipe sur tous les changements apportés en SEO. Pour certains, le bénéfice étaient évident, pour d’autres, avouer qu’il s’agit d’un test n’a rien de honteux, surtout lorsque l’équipe avec laquelle vous travaillez n’y connait rien et souhaite juste comprendre comme Google fonctionne.

Je ne surprendrai personne en disant qu’en SEO, on teste, on teste et on re-teste. Bien sûr, avec l’expérience, certains changements seront plus faciles à évaluer mais il y a toujours des cas spécifiques pour lesquels il faudra découvrir post-launch les effets générés par ce que vous avez fait.

Par exemple : pour tout ce qui concerne l’implémentation des hreflang (le site SSENSE vendant à l’international), j’ai fait plusieurs tests, pas mal de recherches et je sais déjà que l’implémentation actuelle est bonne mais sûrement pas parfaite… Mais elle a le mérite de générer des résultats convenables. Regardez bien sur le web, vous verrez, il y a plein d’approches différentes pour ça, ce qui rend la chose assez intéressante à étudier malgré les recos de chez Google (mouarf).

Ca a l’air simple lorsqu’on voit cette capture. Mais quand les règles changent radicalement selon le type de page, les filtres, le pays, le nombre de produit il y a un peu de réflexion qui se fait, surtout pour éviter d’avoir des balises qui entrent en conflit et d’indexer ce qui ne mérite pas d’être indexé.

 

2. Entendre et comprendre les défis techniques des développeurs et trouver des alternatives.

Ce point a été d’une importance capitale dans la réussite de la migration. Plusieurs fois, les dévs étaient exposés à des problématiques techniques. Ils me les décrivaient à leur façon en détaillant bien le contexte technique. Voyant que j’arrivais à comprendre la grande majorité de ce qu’ils m’expliquaient, ça devenait tout de suite plus agréable pour eux comme pour moi. Et en tant qu’expert, tu en profites pour en apprendre davantage sur la structure du site, les limites du backend et aussi la flexibilité de la techno qu’on utilise.

Je me souviens encore des règles de canonical, noindex-follow, noindex-nofollow et autre alternate à intégrer. Quand tu es SEO, ça te semble logique mais quand tu es un développeur, tu vois ça comme une charge et je prenais le temps de leur expliquer pourquoi je faisais ça : après tout de suite, ça se passait beaucoup mieux.

Et aussi, la proximité physique aidait grandement à créer un meilleur lien avec eux.

3. Préparer un plan de migration des URL le plus tôt possible dans le projet 

Le classique et fameux plan de redirections qui va permettre de mapper les anciennes et URL. Changer les URL étant nécessaire (contrainte technique), on a d’abord listé tous les patterns. Ensuite, j’ai commencé à faire un scénario pour tester rapidement quelques URL des différents patterns et voir si la logique fonctionnait. Faites-vous des scripts car tester tout à la main en 2017, « no thank you ».

Enfin, avoir un fichier de test avec une liste exhaustive d’URL pour voir s’il n’y a pas de problèmes isolés (en s’assurant de prendre les URL avec caractères spéciaux, accents, etc…) est nécessaire.

4. Dénicher les exceptions comportementales et trouver des solutions avec l’équipe

Plusieurs fois, il est arrivé de détecter des comportements étranges du nouveau site : filtre oublié, mal géré, problème de CSS sur mobile, gestion des accents, il y a toujours des petites réparations à faire à droite et à gauche.

En SEO, j’ai eu pas mal de va-et-vient à faire au niveau de la gestion de l’indexation et du suivi des pages de résultats (recréer des règle d’indexation et les faire correctement appliquer, désindexation du contenu dupliqué obligatoire pour le site, souci de linking interne entre les pages…). Le fait de pouvoir gérer ça de A à Z avec les développeurs m’a permis d’avoir le contrôle total sur la structure du site et sur la volonté de ce que l’on souhaite indexer ou pas. Et une fois de plus, les changements étaient vite intégrés vu qu’on était assis ensemble.

5. Tester et vérifier tout ce qui est produit, même si une personne dédiée au QA existe

Le QA est essentiel mais en SEO, on sait qu’avoir une logique qui fonctionne ne suffit pas. Il faut toujours s’assurer que tout marche au poil, que ce soit dans l’affichage des infos, l’insertion des règles d’indexation, les redirections, le chargement de la page, la duplication de contenus, et j’en passe.

Même si le nouveau site ne comportait pas de nouvelles fonctionnalités, le fait de changer de technologie a réussi à créer des petites surprises qui ont été maîtrisées avant la sortie. Bien sûr, on en a profité pour faire quelques améliorations internes (logique de linkbuilding, meilleur moteur de recherche…) mais pas de changement majeur.

6. S’assurer que LES REDIRECTIONS FONCTIONNENT LE PREMIER JOUR

La règle d’or ! J’ai pour principe d’annoncer à la direction que les redirections doivent fonctionner le jour du lancement. Si ça plante, je nous donne quelques heures pour résoudre le tout. Dans le cas contraire, s’attendre à un belle perte du trafic organique sur notre site qui mettra longtemps, voire très longtemps à récupérer (je parle en années).

Alors évidemment, quand je dis ça, certaines personnes ont commencé à me dire « Sérieux Arnaud, vous êtes trop rigides vous les SEO » ou encore « Non mais au pire on fixera les redirections dans les jours à venir » . Être flexible est une chose mais mettre en péril le trafic organique car on ne donne pas les bonnes indications à Google au bon moment, ça non, je refuse de prendre le risque.

Vous voulez une bonne façon de faire accepter votre rigueur extrême par tous ? Partagez juste le chiffre d’affaires générés par le trafic organique, ainsi que celui générés par toutes les pages qui vont changer d’URL : généralement, ça permet de mettre tout le monde d’accord.

Je considère que faire les redirections 301 dans les prochains jours = tuer le trafic SEO, tout simplement. Et attention, je parle de pages clés de la business, des pages qui sont régulièrement trouvées et bien positionnées dans les SERP donc hors de question de faire de la merde avec ça, surtout lorsqu’on vit dans un milieu bien compétitif comme c’est le cas pour SSENSE : les vêtements de luxe et fashion sont vendus par pas mal de monde en ligne.

Sachant que rien n’est jamais garanti le 1er jour (y a toujours un truc qui pète), j’ai mis au point une phase de transition en douceur :

  1. Jour 1 : toutes les redirections fonctionnent mais au lieu d’avoir des 301, ce sont des 302 (comme ça, si jamais il doit y avoir un rollback au bout de quelques heures, je n’aurai pas d’URL nouvelles et cassées qui s’indexeront)
  2. On se donne jusqu’à 36h pour autoriser un rollback : pendant ce laps de temps, tous les stackholders redécouvre la nouvelle version du site en production et nous font part d’éventuels glitchs qu’ils trouvent (en relativisant bien sûr).
  3. Si au bout de 36h, tout est beau, alors on bascule toutes les 302 en 301 et nos milliers de redirections deviennent alors des redirections permanentes.

Comme vous pouvez le voir dans le screenshot Google Analytics plus haut, ça s’est bien passé et j’ai remercié toute l’équipe d’avoir respecté ma rigueur dans l’implantation du plan de redirections 301 : transition « smooth » comme ils disent ici.

L’autre bonne nouvelle dans tout ça, c’est qu’à force de travailler avec moi, toute mon équipe de développeurs a mangé un peu de SEO chaque matin et dorénavant, ils sont bien conscients que changer les URL doit se faire dans un cas extrême où ils n’auront vraiment pas le choix.

Bref, une fois de plus, la migration d’un site est une étape cruciale en référencement et non un nice to have, sauf si votre client se fout littéralement du SEO et de sa business. Gardez en tête qu’être ami-ami avec la technique va grandement vous aider et que démarrer le plan de migration le plus tôt possible vous permettra d’éviter un maximum de problèmes spécifiques de redirections le jour de la mise en ligne.