5 erreurs de migration de site SEO à éviter avec Sara Moccand

Publié: 2022-06-27

Avez-vous déjà été impliqué dans une migration de site Web catastrophique ? Peut-être avez-vous été amené à participer à un projet pour faire face aux effets d'une migration de site Web mal pensée.

Aujourd'hui, nous allons discuter de cinq erreurs clés à éviter lors de la migration de votre site Web avec une dame qui l'année dernière a cédé et s'est abonnée à Netflix et Disney Plus. Elle est co-animatrice du meetup SEO Nerds Switzerland et spécialiste SEO chez Liip, une agence de développement web et mobile avec six bureaux en Suisse. Bienvenue au podcast In Search SEO, Sara Moccand.

Les erreurs à éviter sont :

Mauvaise planification
Ne pas tester les redirections
Ne pas auditer la mise en scène
Migrer en période de forte demande
Faire indexer la mise en scène

5 conseils de migration de site à surveiller

Sara : Salut.

D : Salut, Sara. Vous pouvez retrouver Sara sur liip.ch. Alors Sara, pourquoi la migration de sites Web est-elle un si gros problème pour les référenceurs ?

S : Principalement parce que vous pouvez perdre tout le trafic organique qui est la source de revenus, je dirais. C'est la raison principale, donc tout le monde doit être très prudent dans la migration de son site Web.

D : Alors aujourd'hui, nous parlons des cinq principales erreurs à éviter lors de la migration de votre site Web. En commençant par le numéro un, une mauvaise planification.

1. Mauvaise planification

S : Oui, l'une des plus grosses erreurs est une mauvaise planification. J'ai quelques exemples. Une mauvaise planification peut commencer dès le début. Par exemple, en agence, vendre le mauvais nombre de jours, ce qui oblige à re-discuter du budget, ce qui le rend extrêmement compliqué. Il existe plusieurs exemples mais commençons par les principaux problèmes. De toute évidence, vous n'obtenez pas les choses mises en œuvre comme vous le souhaitez si vous ne planifiez pas correctement. Le deuxième problème, comme je l'ai déjà dit, est la perte de trafic. C'est le scénario catastrophique, la perte de trafic, et la solution à cela est d'apprendre le nom de toutes les personnes impliquées. C'est le secret. Apprenez qui est le développeur, qui est le front-end, le backend, le concepteur, etc. Apprenez tout ce que vous pouvez sur leurs noms et ce qu'ils font afin de pouvoir toujours les contacter.

Chaque migration de site Web est comme un nouveau projet. Vous avez donc le projet, qui a ensuite un plan. Et c'est là que vous pouvez voir exactement où le SEO peut interagir. C'est important à garder à l'esprit. Par exemple, au début, les développeurs savent quoi faire, ils choisiront la technologie avec laquelle travailler. Il est donc intéressant pour un référenceur de savoir quelle technologie il compte utiliser. Et peut-être pouvez-vous également influencer la technologie utilisée. Parfois, pas très souvent, mais parfois. Ceci est juste un exemple pour apprendre la planification globale et déterminer où vous pouvez interagir.

D : Il y a beaucoup de choses que vous pouvez inclure dans un plan, bien sûr, mais y a-t-il des éléments standard que vous intégreriez dans un plan ? Ou chaque projet est-il assez unique ?

S : Je dirais qu'il y a trois choses standard. En sachant quand la technologie est choisie, en sachant quand le concepteur commencera à concevoir l'architecture du site Web et en sachant à quel moment il sera mis en ligne, vous pouvez analyser la mise en scène pour vous assurer qu'ils seront mis en ligne. Cela m'amène à la répartition de la migration du site Web. Vous avez votre plan, puis vous le décomposez en phases. La première est la phase de préparation, où vous interagissez avec les développeurs. Et là-dedans, vous devez également analyser comment se porte le site Web, quelles pages sont importantes, etc. Et vous préparerez également votre carte de redirection. La phase suivante consiste à avoir la phase de test où vous testez tout parce que tout ce qui est en scène ira à 100% en direct donc s'il y a un problème là-bas, il y aura un problème après.

D : Vous avez également mentionné les URL. Je suppose que certaines migrations de sites Web sont plus faciles que d'autres. Certains d'entre vous pourraient migrer des serveurs et conserver la même technologie, le CMS, les mêmes URL éventuellement aussi… Que se passe-t-il si vous modifiez chaque URL ou la majorité des URL parce que vous devez le faire ? Peut-être que vous passez de quelque chose qui contient ASP, par exemple, à la fin des URL à une URL assez simple ? Est-il possible de conserver tous vos classements et de changer d'URL en même temps ?

S : Comme je travaille dans une société de développement, les gens viennent pour ça. Ils ne viennent pas juste changer un peu le serveur. C'est exactement ce qu'ils veulent faire. Ils veulent tout changer. C'est mon problème. Alors oui, ça marche. Vous devez faire vos redirections, vous devez faire votre carte de redirection, et vous avez le temps où les moteurs de recherche doivent s'adapter un peu. La plupart du temps, cela fonctionne bien, car lorsque vous faites votre carte de redirection, le but est de le faire intelligemment. Par exemple, vous savez que si une page se classe pour quelque chose de spécifique, vous la redirigerez vers le même sujet. Ensuite, vous devez être un peu prudent dans votre carte de redirection, et puis ça marche. Encore une fois, le scénario le plus courant que j'ai vu est exactement celui où ils ont tout changé.

D : Une autre question de suivi par rapport à ce que vous avez dit. Vous avez dit que les moteurs de recherche ont parfois besoin d'un peu de temps pour s'adapter. Combien de temps est-il raisonnable d'accorder aux moteurs de recherche avant de voir les mêmes classements qu'avant ?

S : Non, je voulais dire avant que tu ne paniques. Je dirais que ça dépend, mais j'ai vu des moments où ils ne changent pas tout, mais ils changent pas mal et ils s'adaptent assez vite. Je dirais un mois maximum, un mois et demi. Et si après ça ne s'adapte pas, c'est qu'il y a un problème quelque part.

D : Passons au numéro deux, sans tester les redirections.

2. Ne pas tester les redirections

S : Oui. Faisons quelques exemples sur le mur de la honte où j'ai mal fait. Je me souviens qu'au début, j'ai organisé ma carte de redirection, et chaque fichier était correct. Ensuite, je l'ai donné au développeur pour préparer tout ce que j'ai testé. Et j'ai dit que tout allait bien. Ensuite, il a été mis en ligne. Et quand nous sommes allés en direct, je me demandais ce qui se passait. Et puis j'ai réalisé qu'il générait une chaîne de redirection, ce qui m'a un peu surpris. J'ai donc eu la chance d'avoir une très bonne relation avec les développeurs, qui ont pu régler ça sur place. C'était un scénario de cas où j'ai testé mais je n'ai pas assez bien testé, parce que je ne m'en étais pas rendu compte avant de passer en direct.

Une autre fois sur le mur de la honte et pour être conscient de l'importance de tout tester parfaitement. Je me souviens qu'il y avait un site Web avec de nombreux pays, mais il y avait un rôle spécifique pour l'URL. J'ai donc demandé au développeur de m'aider à faire un script pour moi afin que nous allions plus vite. Il a fait le script, puis j'ai réservé une demi-journée avec le développeur pour faire le test, mais il a ensuite dit : "Hé, Sara, je l'ai testé." Fantastique. Si vous l'avez déjà fait, fantastique. Mais permettez-moi d'essayer un pays. Alors je l'ai testé aux États-Unis et j'ai dit : "Tout fonctionne. Super. Merci. Au revoir. Tape la!" Puis nous sommes allés vivre. J'ai tout vérifié et quand j'ai vérifié, j'étais : « Que se passe-t-il ? C'est quoi sauter ? Où sont le Japon et le Koweït ? Je vois donc que nous avons tout migré, mais il nous manquait le Japon et le Koweït, ce que je n'avais pas réalisé avant qu'ils ne soient mis en ligne. Et encore une fois, j'ai eu de la chance car ils m'ont aidé à le récupérer immédiatement donc il n'y a pas eu de réelles répercussions car c'est arrivé le jour où on a tout corrigé. Mais c'est un problème. Vous devez tester.

D : Je suppose que cela concerne également le point 3, car le point 3 n'est pas la vérification de la mise en scène.

3. Ne pas auditer la mise en scène

S : Oui, cela fait partie du troisième point. Au début, j'avais mes billets, je les vérifiais, et tout allait bien dans la mise en scène. Fantastique. Les billets sont mis en œuvre. Mais ensuite, j'ai réalisé que je n'auditais pas comme j'auditerais normalement un site Web. Par exemple, vous commencez à voir des choses bizarres. Je me souviens de ce site Web, qui s'est produit récemment et côté serveur, il s'affichait parfaitement. Je pouvais tout voir dans le code de la console. J'étais donc heureux. Mais j'ai un problème avec les éléments cachés, je vérifie toujours les éléments cachés. Ce qui s'est passé, c'est que JavaScript se comportait de manière super bizarre. Il supprimait tous les textes de l'élément caché. Vous pouvez donc le voir mais pas dans le code. C'est un exemple de l'importance d'auditer la mise en scène du site Web et de vérifier toute la mise en œuvre.

L'autre chose que vous devez faire est d'avoir votre propre liste de contrôle, de réparer la liste de contrôle, avec toutes les tâches, exactement comme un audit, puis vous pouvez toujours ajouter une colonne. Par exemple, si vous utilisez une feuille de calcul Google, ayez une colonne pour cette tâche, j'ai un ticket, pour ces tâches, ce n'est pas obligatoire, je pourrais le prendre. Par exemple, pour le cas JavaScript que j'ai donné, vous n'ouvrez pas de ticket, vous ne l'ouvrez qu'en cas de problème. Et puis vous donnez votre liste de priorités sur une autre colonne, le statut. Quelle URL de statut faire en cours, puis vous commentez. Les commentaires sont super importants, tout le monde les enlève, mais les commentaires sont importants car vous devez savoir pourquoi quelque chose est bloqué. Par exemple, si une personne bloque ou si un autre ticket bloque, vous devez savoir comment le bloquer. Il s'agit un peu de vérifier la mise en scène et son importance. Cela dépend, mais certains développeurs utiliseront aussi, par exemple, le noindex sur toutes les pages, dans le code. Et puis ils oublieront de le retirer lorsqu'ils seront mis en ligne. Le problème est que vous devez être conscient qu'ils l'utilisent afin que vous puissiez leur demander de ne pas oublier de supprimer le noindex avant de passer en direct, s'il vous plaît.

D : Et le quatrième point à éviter est la migration en période de forte demande.

4. Migrer dans une période de forte demande

S : Oui. Cela devrait être évident car vous avez ce problème de perte de trafic, ou du moins pendant une courte période, ce n'est pas toujours comme ça. Encore une fois, cela dépend de la migration du site Web, mais il y a un risque de temps d'adaptation. Et puis si vous avez du temps pour d'autres activités… Disons que vous êtes dans le eCommerce. Entre probablement octobre et fin décembre, vous ne souhaitez pas migrer votre site Web car Noël approche et de nombreuses personnes achèteront via votre boutique en ligne. Le client sait normalement que pendant cette période, il a une forte demande. Ainsi, vous pouvez vérifier avec le client ses analyses pour éviter un problème.

D : Vous avez mentionné plus tôt que certains développeurs pourraient même mettre noindex sur chaque page pour essayer d'éviter que les pages soient indexées. L'erreur numéro cinq est d'avoir indexé la mise en scène. Conseilleriez-vous cette balise noindex sur chaque page de l'environnement de staging pour éviter ce genre de chose ?

5. Faire indexer la mise en scène

S : Non, la protection par mot de passe est toujours la solution. Vous pouvez faire noindex mais, comme dans mon exemple, vous pourriez oublier quand vous allez vivre. À la fin, la meilleure solution qui fonctionne toujours est d'être protégé par un mot de passe, point final. Je me souviens une fois que la mise en scène a été indexée il y a quelques années, et ce fut probablement l'expérience la plus choquante que j'ai eue. La mise en scène a été indexée et le problème était… vous pouviez acheter des billets sur le site Web et le problème était que les personnes qui essayaient d'acheter les billets sur le site Web de mise en scène étaient un peu catastrophiques. Pouvez-vous imaginer des gens essayant d'acheter sur le site de mise en scène ? Ils m'ont donc contacté en me disant qu'ils avaient ce problème. Et nous avons pu le résoudre car il est relativement facile à résoudre. C'est probablement l'un des points principaux pour moi. Une fois que les développeurs ont mis en place une protection par mot de passe et mis le noindex. Je dois donc faire attention non seulement à vérifier qu'il est protégé par un mot de passe, mais également à vérifier le noindex.

D : Je suis sûr que vous auriez pu étendre cette conversation à 101 erreurs à éviter lors de la migration de notre site Web, mais j'espère que nous avons votre top cinq ici. Comme toujours, c'est du super truc de la part de Sara. Terminons avec le Pareto Pickle. Pareto dit que vous pouvez obtenir 80 % de vos résultats à partir de 20 % de vos efforts. Quelle est l'activité de référencement que vous recommanderiez qui fournit des résultats incroyables pour des niveaux d'effort modestes ?

Le cornichon de Pareto - Planification de la migration du site Web

S : Pour moi, dans une migration de site Web, c'est la planification. Prenez un peu de temps pour planifier. Ce n'est pas énormément de temps par rapport au travail que vous avez à faire. Si vous avez une structure, alors vous ne faites pas d'erreurs, et puis vous gagnez beaucoup de temps parce que pour chaque erreur, vous devez demander du temps pour vous remettre des erreurs donc certainement planifier.

D : Planifiez correctement. J'ai été votre hôte, David Bain. Vous pouvez retrouver Sara sur liip.ch. Sara, merci beaucoup d'être sur le podcast The In Search SEO.

S : Merci.

D : Et merci pour votre écoute.