En tant que professionnels du référencement, nous ne sommes pas étrangers aux migrations et aux différents niveaux de volatilité qu’elles peuvent apporter. Les migrations sont des événements naturels dans le cycle de vie des entreprises numériques à mesure que la technologie et les objectifs commerciaux avancent. Les migrations peuvent prendre différentes formes, definition seo mais les plus courantes que nous rencontrons incluent: Changer les noms de domaine. Fusion de plusieurs propriétés de domaine ensemble. Le niveau de risque et les variables changent considérablement entre les différents types de migration, ainsi que les variables et les nuances dans la pile technologique du client, ce qui signifie qu’il est presque impossible de fournir une portée standard. Dans l’industrie, nous entendons parler de migrations qui vont mal, à savoir quand elles commencent à avoir un impact sur le monde en dehors du référencement. Perdre du trafic et quelques classements n’est pas la une des journaux, mais les entreprises ferment des magasins et licencient du personnel. Des exemples de cela incluent la migration HTTPS de Homebase (comme couvert en détail par Omi Sido ici), et le plus récent changement de nom de Logojoy vers Looka, qui, en regardant à travers les yeux des outils tiers, montre une diminution du classement des mots-clés de 25 000 (150k à 125k). Étendue d’une migration SEO Pour moi, obtenir la portée d’une migration correcte est essentiel au succès du processus de migration dans son ensemble, et éviter des situations comme celle-ci: Exemple d’une migration de site où la consultation SEO a été effectuée trop tard et après que toutes les décisions clés ont été prises. Un élément clé de la portée et des spécifications est qu’il doit être réalisable à la fois pour les développeurs et les parties prenantes plus larges: Réduire le pourquoi.  » L’ambiguïté crée un risque. Moins il y a de place pour une mauvaise interprétation, mieux c’est. Dans le document de cadrage, il est essentiel d’établir: Les raisons de la migration en cours (du client). Parties prenantes primaires et secondaires. L’étendue des activités et des responsabilités de chaque partie prenante (maintenir le trafic et les classements n’est pas une responsabilité, c’est un objectif). Le calendrier des activités, ainsi que les ressources post-migration. Objectifs convenus (par toutes les parties) de la migration. Fréquence et profondeur des rapports. À partir de là, vous pouvez commencer à créer un programme d’activités pour réduire le plus de risques possible. Atténuation des risques Pour l’essentiel, l’atténuation des risques au cours de toute migration consiste à réaliser ce qui est pour de nombreuses activités de migration générales. Cependant, chaque activité est conçue pour réduire les éléments de risque et travailler à la réalisation des objectifs convenus. Redirige Il va de soi que les redirections font partie de presque toutes les migrations. Cependant, après avoir effectué un certain nombre d’audits de baisse du trafic après la migration, voici quelques erreurs courantes commises lors de la définition de la portée et de la mise en œuvre des redirections. JS, CSS, paramètres et fichiers multimédias non redirigés Plus souvent qu’autrement, lorsque la migration est effectuée, les gens se concentrent sur la redirection des URL, car ce sont ces classements, mais vous devriez également envisager de rediriger vos fichiers JS, CSS, URL de paramètres et fichiers multimédias (images, vidéos) si nécessaire . Beaucoup de gens remettent en question la valeur de la redirection des images, mais une URL est une URL et Google l’aura explorée. Google a même recommandé de rediriger les URL des images. Changements d’environnement Lors de la migration vers une nouvelle plate-forme, de la refonte des modèles ou de la mise à jour de la structure du site, il est important de s’assurer que le nouvel environnement reflète au minimum les qualités SEO de la précédente. Souvent, la nouvelle plate-forme est mise en ligne et beaucoup de contenu est caché derrière les zones extensibles JavaScript, et avec NoScript ou JS désactivé, elle reste cachée, ou d’autres éléments clés ont été manqués, il est donc important d’auditer le nouvel environnement pour vérifier que: Les métadonnées ont été correctement transférées. Les données structurées ont été mises en œuvre et sont validées. Les canoniques sont corrects. La liaison interne a été reportée et pointe 200 URL. Les plans de site XML et HTML sont présents. Hreflang est correctement configuré (si vous êtes un site Web international). Les redirections ont été testées. Votre page 404 renvoie un code de réponse 404. Certaines choses comme la vitesse du site nécessiteront des tests de site en direct, sauf si les environnements de pré-production et de pré-production sont sur des piles en miroir (afin que vous puissiez émuler les mêmes performances), mais le plus souvent, ils ne sont pas sur des serveurs axés sur les performances. Comprendre pourquoi les migrations vont mal Souvent, lorsqu’une migration se passe mal, elle peut être identifiée pour au moins l’une des sept raisons, à savoir: Stratégie de référencement incorrecte / objectifs peu clairs. Mauvaise planification et délimitation des ressources et du calendrier. Modifications UX / conception imprévues qui ont un impact sur le contenu ou le code. Impliquer l’agence SEO trop tard / après que des décisions clés ont déjà été gravées dans le marbre. Mauvais ou manque de tests suffisants. Réponses lentes et faible priorité de développement aux corrections de bugs post-migration. Variables incontrôlables (par exemple, mise à jour Google). Mauvaise stratégie Il est essentiel de comprendre pourquoi la migration a lieu et les résultats souhaités afin de définir des critères de réussite mesurables. » Pour la plupart des migrations, l’objectif est de maintenir les performances SEO, puis d’utiliser cette stabilité comme fondement de la croissance. Cependant, chaque type de migration a son propre ensemble de risques. Ceux-ci doivent être communiqués au client et aux parties prenantes plus larges. Si vous déplacez un hébergement ou une plate-forme mais que vous maintenez des structures d’URL, cela devrait être transparent, mais si vous changez de marque et changez le nom de domaine, attendez-vous à une période de turbulence. Mauvaise planification et cadrage Concevoir une portée et un plan de projet détaillés dès le début peut aider à éviter les retards en cours de route en définissant les attentes quant à la durée des processus et des tâches de référencement. Cela vous permet également de prendre en compte ce qui est et n’est pas dans la portée du projet afin que vous puissiez planifier et allouer les ressources de manière adéquate. En établissant un plan, vous pouvez également identifier les obstacles potentiels, tels que les jours fériés ou les périodes de pointe des ventes. Par exemple, en tant que détaillant en ligne, vous ne lanceriez pas de site Web dans les jours précédant l’Action de grâces, car des bugs majeurs pourraient mettre en danger votre Black Friday / Cyber ​​Week / Noël. Participation tardive Les migrations SEO ne se font pas du jour au lendemain. Cependant, le support SEO est souvent recherché trop tard dans la feuille de route avec de nombreuses décisions critiques prises à l’avance qui auront un impact sur les performances de la recherche organique. Parfois, la participation tardive peut être une grâce salvatrice, tant qu’il y a de la place dans le calendrier pour que des changements soient apportés, mais c’est rarement le cas et vous ne pouvez que regarder et vous préparer à l’autopsie. Cela signifie également qu’il y a un manque de tests suffisants (d’un point de vue SEO) Temps de réponse au développement lents C’est le plus souvent un problème avec l’entreprise elle-même, et ce n’est pas quelque chose que les professionnels du référencement peuvent contrôler. Je me suis déjà retrouvé dans des situations où immédiatement après que la ressource de développement de la migration a été entièrement dédiée à une autre partie de l’entreprise, ne laissant pas de temps pour des corrections de bogues urgentes ou ad hoc. Plus souvent qu’autrement, ce n’est pas la faute du développeur mais plutôt un symptôme d’une mauvaise planification de la part des acteurs de la prise de décision. J’ai déjà vu des sites Web en ligne avec un noindex sur tout le site (car le mauvais compartiment avait été déployé), quelque chose que nous avons signalé presque immédiatement – seulement 4 jours pour que la ressource soit allouée pour le supprimer.

 

Comments are closed.