Qu’est-ce qu’une migration de site ?

Une migration de site est un terme largement utilisé par les professionnels du SEO pour décrire tout événement par lequel un site Web subit des changements substantiels dans les zones qui peuvent affecter considérablement la visibilité des moteurs de recherche — change généralement l’emplacement, la plate-forme, la structure, contenu, la conception ou ux.

La documentation de Google sur les migrations sur site ne les couvre pas en profondeur et minimise le fait que si souvent ils entraînent des pertes de trafic et de revenus importantes, qui peuvent durer de quelques semaines à plusieurs mois – en fonction de l’étendue du classement des moteurs de recherche ont été affectés, ainsi que le temps qu’il faudra à l’entreprise concernée pour déployer un plan de redressement réussi.

Index

Liste de contrôle de migration du site (8 pages PDF)
Exemples de migration de site
Types de migration de site
Les pièges communs de la migration des sites
Processus de migration du site
1. Portée et planification
2. Préparation avant le lancement
3. Essais de pré-lancement
4. Actions de jour de lancement
5. Tests post-lancement
6. Examen du rendement
Annexe: Outils utiles

Exemples de migration de site

La section suivante examine comment les migrations réussies et infructueuses du site semblent et explique pourquoi il est possible de sortir d’une migration de site sans subir de pertes importantes.

Démystifier le mythe de la « baisse de trafic prévue »

Quiconque a été impliqué dans une migration de site a probablement entendu la théorie répandue qu’il entraînera de facto le trafic et la perte de revenus. Même si cette affirmation contient une certaine vérité pour certains cas très spécifiques (c’est-à-dire passer d’un domaine établi à un domaine tout nouveau), elle ne devrait pas être traitée comme un évangile. Il est tout à fait possible de migrer sans perdre de trafic ou de revenus; vous pouvez même profiter d’une croissance significative juste après le lancement d’un site Web remanié. Toutefois, cela ne peut être réalisé que si chaque étape a été bien planifiée et exécutée.

Exemples de migrations de sites infructueuses

Le graphique suivant illustre la migration bâclée d’un grand détaillant britannique où le site a perdu 35 de sa visibilité deux semaines après être passé de HTTP à HTTPS. Il leur a fallu environ six mois pour récupérer complètement, ce qui a dû avoir un impact significatif sur les revenus de la recherche biologique. Il s’agit d’un exemple typique d’une mauvaise migration de site, peut-être causée par une mauvaise planification ou mise en œuvre.

Exemple d’une migration de site pauvre – récupération a pris 6 mois!

Mais la récupération n’est pas toujours possible. Le graphique de visibilité ci-dessous provient d’un autre grand détaillant britannique, où le basculement http à HTTPS a entraîné une perte de visibilité permanente de 20.

Un autre exemple d’une migration de site pauvres – aucun signe de récupération 6 mois plus tard!

En fait, il est tout à fait possible de migrer de HTTP à HTTPS sans perdre autant de trafic et pour une si longue période, en dehors des premières semaines où il ya une forte volatilité que Google découvre les nouvelles URL et mises à jour des résultats de recherche.

Exemples de migrations réussies sur les sites

À quoi ressemble une migration réussie sur un site ? Cela dépend en grande partie du type de migration du site, des objectifs et des KPI (plus de détails plus tard). Mais dans la plupart des cas, une migration réussie du site montre au moins l’une des caractéristiques suivantes :

Perte de visibilité minimale au cours des premières semaines (objectif à court terme)
Croissance de la visibilité par la suite — selon le type de migration (objectif à long terme)

Le rapport de visibilité suivant est tiré d’une migration http à HTTPS site, qui a également été accompagnée d’améliorations significatives des temps de chargement de la page du site.

Le rapport de visibilité suivant provient d’une révision complète du site, avec laquelle j’ai eu la chance d’être impliqué plusieurs mois à l’avance et soutenu pendant les phases de stratégie, de planification et de test, qui étaient toutes tout aussi importantes.

Comme il arrive généralement sur place des projets de migration, la date de lancement a dû être repoussée à quelques reprises en raison des risques de lancement prématuré du nouveau site et avant que les principaux obstacles techniques ne soient pleinement surmontés. Mais comme vous pouvez le voir sur le graphique de visibilité ci-dessous, l’attente en valait la peine. Non seulement la visibilité organique n’a pas baissé (comme la plupart s’y attendraient normalement), mais en fait, elle a commencé à croître dès la première semaine.

La croissance de la visibilité un mois après la migration a atteint 60, tandis que la croissance organique du trafic deux mois après le lancement a dépassé 80.

Exemple d’une migration de site très réussie — croissance instantanée après le lancement du nouveau site!

Il s’agissait d’une migration assez complexe que le nouveau site A été re-conçu et construit à partir de zéro sur une nouvelle plate-forme avec une taxonomie du site améliorée qui comprenait de nouvelles pages de destination, une structure d’URL mise à jour, beaucoup de redirections pour préserver l’équité lien, plus un passage à partir de HTTP à HTTPS.

En général, l’introduction de trop de changements en même temps peut être difficile parce que si quelque chose va mal, vous aurez du mal à comprendre ce qui est exactement en faute. Mais dans le même temps, laisser des changements majeurs pour une période ultérieure n’est pas idéal non plus car il faudra plus de ressources. Si vous savez ce que vous faites, faire plusieurs changements positifs à la fois peut être très rentable.

Avant d’entrer dans le nitty-gritty de la façon dont vous pouvez transformer un projet de migration de site complexe en un succès, il est important de courir à travers les principaux types de migration du site ainsi que d’expliquer les principales raisons pour lesquelles tant de migrations de site échouent.

Types de migration de site

Il existe de nombreux types de migration de sites. Tout dépend de la nature des changements qui ont lieu.

La documentation de Google couvre principalement les migrations avec des changements de localisation du site, qui sont classés comme suit :

Le site se déplace avec des modifications d’URL
Le site se déplace sans modifications d’URL

Migrations de déplacement de site

Ceux-ci se produisent généralement quand un site se déplace vers une URL différente en raison de l’un des ci-dessous:

Modification du protocole

Un exemple classique est lors de la migration de HTTP à HTTPS.

Modification de sous-domaine ou de sous-dossier

Très fréquent dans le SEO international où une entreprise décide de déplacer un ou plusieurs ccTLDs dans des sous-domaines ou des sous-dossiers. Un autre exemple courant est celui où un site mobile qui se trouve sur un sous-domaine ou un sous-dossier distinct devient réactif et les URL de bureau et mobiles sont en uniforme.

Changement de nom de domaine

Se produit généralement lorsqu’une entreprise est rebranding et doit passer d’un domaine à l’autre.

Changement de domaine de haut niveau

Ceci est commun quand une entreprise décide de lancer des sites Web internationaux et doit passer d’un ccTLD (domaine de code de pays de haut niveau) à un gTLD (domaine générique de haut niveau) ou vice versa, par exemple passer de .co.uk à .com, ou passer de .com à .co.uk et ainsi de suite.

Modifications de la structure du site

Il s’agit de modifications apportées à l’architecture du site qui affectent habituellement la structure interne de liaison et d’URL du site.

Autres types de migrations

Il existe d’autres types de migration qui sont déclenchés par des modifications du contenu, de la structure, de la conception ou de la plate-forme du site.

Replatforming (Replatforming)

C’est le cas lorsqu’un site Web est déplacé d’une plate-forme/CMS à une autre, par exemple en migrant de WordPress à Magento ou simplement en passant à la dernière version de la plate-forme. La replatforming peut, dans certains cas, également entraîner des modifications de conception et d’URL en raison de limitations techniques qui se produisent souvent lors du changement de plates-formes. C’est pourquoi les migrations de re-plateforme donnent rarement lieu à un site Web qui ressemble exactement au précédent.

Migrations de contenu

Les modifications majeures du contenu telles que les réécritures de contenu, la consolidation de contenu ou l’élagage de contenu peuvent avoir un impact important sur la visibilité organique d’un site en matière de recherche, selon l’échelle. Ces changements peuvent souvent affecter la taxonomie, la navigation et les liaisons internes du site.

Modifications de configuration mobile

Avec autant d’options disponibles pour le déplacement de configuration mobile d’un site, l’indexation d’applications, la construction d’un site AMP ou la construction d’un site Web PWA peuvent également être considérées comme des migrations partielles du site, en particulier lorsqu’un site mobile existant est remplacé par une application, une AMP ou une PWA.

Changements structurels

Ceux-ci sont souvent causés par des changements majeurs à la taxonomie du site qui ont un impact sur la navigation du site, les liaisons internes et les déplacements des utilisateurs.

Refonte du site

Ceux-ci peuvent varier de changements majeurs de conception dans l’apparence et la sensation à une refonte complète du site Web qui peut également inclure des modifications importantes des médias, du code et de la copie.

Migrations hybrides

En plus de ce qui précède, il existe plusieurs types de migration hybride qui peuvent être combinés de pratiquement toutes les façons possibles. Plus il y a de changements introduits en même temps, plus la complexité et les risques sont élevés. Même si le fait d’apporter trop de changements en même temps augmente les risques que quelque chose ne tourne pas rond, il peut être plus rentable du point de vue des ressources si la migration est très bien planifiée et exécutée.

Les pièges communs de la migration des sites

Même si chaque migration de site est différente, il ya quelques thèmes communs derrière les catastrophes les plus typiques de migration du site, avec le plus grand étant le suivant:

Mauvaise stratégie

Certaines migrations de sites sont vouées à l’échec bien avant le lancement du nouveau site. Une stratégie fondée sur des objectifs peu clairs et irréalistes a beaucoup moins de chances d’apporter du succès.

Il est essentiel d’établir des objectifs mesurables pour mesurer l’impact de la migration post-lancement. Pour la plupart des migrations de sites, l’objectif principal devrait être la rétention du trafic actuel du site et des niveaux de revenus. Dans certains cas, la barre pourrait être relevée, mais en général, l’anticipation ou la prévision de la croissance devrait être un objectif secondaire. Cela permettra d’éviter de créer des attentes irréalistes.

Mauvaise planification

L’arrivée d’un plan de projet détaillé le plus tôt possible permettra d’éviter les retards en cours de route. Tenez compte du temps et des ressources supplémentaires pour faire face aux circonstances imprévues qui pourraient survenir. Peu importe à quel point votre plan est bien pensé et détaillé, il est très peu probable que tout se passe comme prévu. Soyez flexible avec votre plan et acceptez le fait qu’il y aura presque certainement des retards. Planifiez toutes les dépendances et sensibiles toutes les parties prenantes.

Évitez de planifier le lancement du site près de vos pics saisonniers, car si quelque chose tourne mal, vous n’aurez pas assez de temps pour corriger les problèmes. Par exemple, les détaillants devraient éviter de lancer un site près de septembre/octobre pour éviter de mettre en péril la période occupée d’avant Noel. Dans ce cas, il serait beaucoup plus sage de lancer pendant les mois d’été plus calmes.

Manque de ressources

Avant de vous engager dans un projet de migration du site, estimez le temps et les efforts nécessaires pour en faire un succès. Si votre budget est limité, appelez pour savoir s’il vaut la peine d’aller de l’avant avec une migration qui est susceptible d’échouer à atteindre ses objectifs établis et de causer des pertes de revenus.

En règle générale, essayez d’inclure un tampon d’au moins 20 dans la ressource supplémentaire que vous pensez initialement que le projet exigera. Ce tampon supplémentaire vous permettra plus tard d’aborder rapidement tous les problèmes dès qu’ils se présentent, sans compromettre le succès. Si vos ressources sont trop serrées ou si vous commencez à couper les coins ronds à ce stade précoce, la migration du site sera menacée.

Absence de consultation SEO/UX

Lorsque des changements ont lieu sur un site Web, chaque décision doit être pondérée à la fois du point de vue de l’UX et du référencement. Par exemple, la suppression de grandes quantités de contenu ou de liens pour améliorer ux peut nuire à la capacité du site à cibler les mots clés critiques ou entraîner des problèmes d’exploration et d’indexation. Dans les deux cas, de tels changements pourraient endommager la visibilité organique du site en matière de recherche. D’autre part, avoir trop de copie de texte et peu d’images peut avoir un impact négatif sur l’engagement de l’utilisateur et endommager les conversions du site.

Pour éviter les risques, nommez des consultants expérimentés en référencement et en UX afin qu’ils puissent discuter des conséquences potentielles de chaque changement avec les principaux acteurs de l’entreprise qui comprennent les subtilités de l’entreprise mieux que quiconque. Les avantages et les inconvénients de chaque option doivent être pesés avant de prendre une décision.

Participation tardive

Les migrations de sites peuvent s’étendre sur plusieurs mois, nécessiter une grande planification et suffisamment de temps pour les tests. Chercher un soutien professionnel en retard est très risqué parce que des étapes cruciales peuvent avoir été manquées.

Manque de tests

En plus d’une excellente stratégie et d’un plan réfléchi, consacrez du temps et des efforts à des tests approfondis avant de lancer le site. Il est beaucoup plus préférable de retarder le lancement si les tests ont identifié des problèmes critiques plutôt que de précipiter une mise en œuvre sommaire dans la production. Il va sans dire que vous ne devriez pas lancer un site Web si elle n’a pas été testée par les deux équipes expertes SEO et UX.

L’attention aux détails est également très importante. Assurez-vous que les développeurs sont pleinement conscients des risques associés à une mauvaise mise en œuvre. Éduquer les développeurs sur l’impact direct de leur travail sur le trafic d’un site (et donc les revenus) peut faire une grande différence.

Réponse lente à la correction de bogue

Il y aura toujours des bogues à corriger une fois que le nouveau site sera mis en ligne. Cependant, certains bogues sont plus importants que d’autres et peuvent avoir besoin d’une attention immédiate. Par exemple, le lancement d’un nouveau site seulement pour constater que les araignées de moteur de recherche ont du mal à ramper et l’indexation du contenu du site nécessiterait une correction immédiate. Une réponse lente aux grands obstacles techniques peut parfois être catastrophique et prendre beaucoup de temps à se remettre.

Échelle sous-estimée

Souvent, les intervenants des entreprises ne prévoient pas que les migrations des sites prennent autant de temps et de ressources. Il n’est pas rare que les intervenants supérieurs exigent que le nouveau site soit lancé le jour prévu, qu’il soit prêt ou non à 100. La devise « lançons dès que possible et réparons plus tard » est une erreur classique. Ce que la plupart des intervenants ignorent, c’est qu’il ne peut prendre que quelques jours pour que la visibilité organique des recherches soit effectuée pour s’en sortir, mais la récupération peut prendre plusieurs mois.

Il incombe au consultant et au chef de projet d’éduquer les clients, de les faire passer à travers toutes les différentes phases et scénarios, et d’expliquer ce que chacun implique. Les parties prenantes sont alors en mesure de prendre des décisions plus éclairées et leurs attentes devraient être plus faciles à gérer.

Processus de migration du site

Le processus de migration du site peut être divisé en six phases essentielles principales. Ils sont tous tout aussi importants et sauter l’une des tâches ci-dessous pourrait entraver le succès de la migration à des degrés divers.

Phase 1 : Portée et planification

Élaborer la portée du projet

Quelles que soient les raisons d’un projet de migration de site, vous devez être très clair sur les objectifs dès le début, car ceux-ci aideront à définir et à gérer les attentes. Déplacer un site de HTTP à HTTPS est très différent de passer par une révision complète du site, d’où les deux devraient avoir des objectifs différents. Dans un premier temps, l’objectif devrait être de maintenir les niveaux de trafic du site, alors que dans le second, vous pourriez potentiellement viser la croissance.

Une migration de site est une excellente occasion de s’attaquer aux problèmes hérités. L’inclusion du plus grand nombre possible de ces projets dans la portée du projet devrait être très rentable, car il faudra beaucoup plus de ressources pour régler ces problèmes après le lancement.

Cependant, dans tous les cas, identifier les aspects les plus critiques pour que le projet soit couronné de succès. Identifier tous les risques qui pourraient avoir un impact négatif sur la visibilité du site et déterminer les précautions à prendre. Idéalement, préparez quelques scénarios de prévision en fonction des différents risques et opportunités de croissance. Il va sans dire que les scénarios de prévision devraient être préparés par des consultants expérimentés en migration des sites.

Le fait d’inclure le plus grand nombre possible d’intervenants à ce stade précoce vous aidera à mieux comprendre les plus grands défis et opportunités entre les divisions. Demandez des commentaires de vos équipes de contenu, de référencement, d’UX et d’analyse et dressez une liste des plus grands problèmes et opportunités. Vous devez alors établir ce que le retour sur investissement potentiel de traiter chacun de ces serait. Enfin, choisissez l’une des options disponibles en fonction de vos objectifs et des ressources disponibles, qui formeront votre stratégie de migration de site.

Vous devriez maintenant vous retrouver avec une liste prioritaire d’activités qui devraient avoir un retour sur investissement positif, si elle est mise en œuvre. Ceux-ci devraient ensuite être communiqués et discutés avec toutes les parties prenantes, de sorte que vous fixez des objectifs réalistes, vous convenez sur le projet, la portée et fixez les bonnes attentes dès le départ.

Préparer le plan de projet

La planification est tout aussi importante parce que les migrations de sites peuvent souvent être des projets très complexes qui peuvent facilement s’étendre sur plusieurs mois. Pendant la phase de planification, chaque tâche a besoin d’un propriétaire (c.-à-d. consultant en référence, consultant UX, éditeur de contenu, développeur web) et d’une date de livraison prévue. Toute dépendance doit être identifiée et incluse dans le plan de projet afin que tout le monde soit au courant de toutes les activités qui ne peuvent pas être remplies en raison de la dépendance des autres. Par exemple, les redirections ne peuvent pas être testées à moins que la cartographie de redirection ait été terminée et que les redirections aient été mises en œuvre sur la mise en scène.

Le plan de projet devrait être partagé avec toutes les personnes concernées le plus tôt possible afin qu’il y ait suffisamment de temps pour des discussions et des clarifications. Chaque activité doit être décrite en détail, afin que les parties prenantes soient conscientes de ce que chaque tâche impliquerait. Il va sans dire qu’une gestion de projet sans faille est nécessaire pour organiser et mener à bien les activités requises selon le calendrier.

Une partie cruciale du plan de projet consiste à obtenir la bonne date de lancement prévue. Idéalement, le nouveau site devrait être lancé à une époque où le trafic est faible. Encore une fois, évitez de vous lancer avant ou pendant une période de pointe, car les conséquences pourraient être dévastatrices si les choses ne se passent pas comme prévu. Une chose à garder à l’esprit est que les migrations de site ne vont jamais entièrement à planifier, un certain degré de flexibilité sera nécessaire.

Phase 2 : Préparation préalable au lancement

Il s’agit notamment de toutes les activités qui doivent être menées pendant que le nouveau site est encore en cours de développement. À ce stade, les exigences du nouveau site SEO devrait avoir été capturé déjà. Vous devriez être en liaison avec les concepteurs et les architectes de l’information, en fournissant des commentaires sur les prototypes et les images filaires bien avant que le nouveau site devient disponible sur un environnement de mise en scène.

Examen de Wireframes

Examinez les prototypes ou les images filaires du nouveau site avant le début du développement. L’examen des modèles principaux du nouveau site peut aider à identifier les problèmes de référencement et d’UX à un stade précoce. Par exemple, vous pouvez constater que de grandes parties du contenu ont été supprimées des pages de catégorie, qui doivent être instantanément signalées. Ou vous pouvez découvrir que certaines pages de trafic de trafic élevé n’apparaissent plus dans la navigation principale. Tout changement radical dans la conception ou la copie des pages doit être examiné en profondeur pour les problèmes potentiels de SEO.

Préparation des spécifications techniques de SEO

Une fois que les prototypes et les fils ont été examinés, préparer une spécification technique détaillée de POINTD. L’objectif de ce document vital est de saisir toutes les exigences essentielles du référencement dont les développeurs doivent être conscients avant d’élaborer la portée du projet en termes de travail et de coûts. C’est à cette étape que les budgets sont approuvés; si les exigences de SEO ne sont pas incluses, il peut être impossible de les inclure plus tard sur la ligne.

La spécification technique SEO doit être très détaillée, mais écrit de telle sorte que les développeurs peuvent facilement transformer les exigences en actions. Ce n’est pas un document pour expliquer pourquoi quelque chose doit être mis en œuvre, mais comment il devrait être mis en œuvre.

Assurez-vous d’inclure des exigences spécifiques qui couvrent au moins les domaines suivants :

Structure URL
Données Meta (y compris les valeurs par défaut générées de manière dynamique)
Données structurées
Directives canoniques et méta robots
Copie et titres
Navigation principale et secondaire
Liaison interne (sous quelque forme que ce soit)
Pagination (Pagination)
XML sitemap(s)
Carte de site HTML
Hreflang (s’il y a des sites internationaux)
Configuration mobile (y compris le site app, AMP ou PWA)
Redirige
Page personnalisée 404
JavaScript, CSS et fichiers d’images
Temps de chargement de la page (pour bureau et mobile)

La spécification devrait également inclure des zones de la fonctionnalité CMS qui permet aux utilisateurs de :

Spécifiez les URL personnalisées et dépassez les URL par défaut
Mise à jour des titres de page
Mise à jour des descriptions de méta
Mettre à jour tous les titres h1-h6
Ajouter ou modifier l’étiquette canonique par défaut
Définir les attributs méta-robots à index/noindex/follow/nofollow
Ajouter ou modifier le texte alt de chaque image
Inclure les champs De graphiques ouverts pour la description, urL, image, type, nom de site
Inclure les champs Twitter Open Graph pour la carte, urL, titre, description, image
Téléchargement en vrac ou modification des redirections
Mise à jour du fichier robots.txt

Il est également important de s’assurer que lors de la mise à jour d’un attribut particulier (p. ex. un h1), d’autres éléments ne sont pas affectés (c.-à-d. le titre de la page ou les menus de navigation).

Identifier les pages prioritaires

L’un des plus grands défis avec les migrations de sites est que le succès dépendra en grande partie de la quantité et de la qualité des pages qui ont été migrées. Par conséquent, il est très important de s’assurer que vous vous concentrez sur les pages qui comptent vraiment. Ce sont les pages qui ont été la conduite du trafic vers le site hérité, les pages qui ont accumulé des liens, des pages qui se convertissent bien, etc.

Pour ce faire, vous devez :

Crawl le site de l’héritage
Identifier toutes les pages indexables
Identifier les pages les plus performantes

Comment explorer le site hérité

Crawl l’ancien site Web de sorte que vous avez une copie de toutes les URL, titres de page, méta données, en-têtes, redirections, liens cassés, etc. Indépendamment de l’application de chenille de choix (voir Annexe), assurez-vous que le crawl n’est pas trop restrictif. Portez une attention particulière aux paramètres du chenil avant de ramper sur le site hérité et demandez-vous si vous devez :

Ignorer robots.txt (au cas où des pièces vitales sont accidentellement bloquées)
Suivez les liens internes “nofollow” (pour que le chenil arrive à plus de pages)
Crawl tous les sous-domaines (selon la portée)
Crawl dossier de démarrage extérieur (selon la portée)
Changer l’agent utilisateur en Googlebot (bureau)
Changer l’agent utilisateur en Googlebot (smartphone)

Astuce Pro: Conservez une copie des données d’analyse de l’ancien site (dans un fichier ou sur le nuage) pendant plusieurs mois après la migration a été terminée, juste au cas où vous avez jamais besoin de l’une des données de l’ancien site une fois que le nouveau site a été mis en ligne.

Comment identifier les pages indexables

Une fois l’analyse terminée, travaillez à l’identification des pages indexées du site hérité. Il s’agit de toutes les pages HTML avec les caractéristiques suivantes:

Retourner une réponse de 200 serveurs
N’ont pas d’étiquette canonique ou ont une URL canonique auto-référencée
Ne pas avoir un méta robots noindex
Ne sont pas exclus du fichier robots.txt
Sont liés en interne à partir d’autres pages (pages non orphelines)

Les pages indexables sont les seules pages qui ont le potentiel de générer du trafic vers le site et doivent donc être priorisées aux fins de la migration de votre site. Ce sont les pages qui valent la peine d’être optimisations (si elles existent sur le nouveau site) ou de les rediriger (si elles n’existent pas sur le nouveau site).

Comment identifier les pages les plus performantes

Une fois que vous avez identifié toutes les pages indexables, vous devrez peut-être effectuer plus de travail, surtout si le site hérité se compose d’un grand nombre de pages et l’optimisation ou la redirection de tous les sont impossibles en raison de temps, de ressources ou de contraintes techniques.

Si tel est le cas, vous devez identifier les pages les plus performantes du site hérité. Cela aidera à établir la priorité des pages sur qui se concentrer au cours des étapes ultérieures.

Il est recommandé de préparer une feuille de calcul qui comprend les champs ci-dessous :

URL héritée (inclure uniquement les indexables des données de l’urne)
Visites organiques au cours des 12 derniers mois (Analytics)
Chiffre d’affaires, conversions et taux de conversion au cours des 12 derniers mois (Analytics)
Pages vues au cours des 12 derniers mois (Analytics)
Nombre de clics des 90 derniers jours (Console de recherche)
Top pages liées (Majestic SEO/Ahrefs)

Avec les informations ci-dessus en un seul endroit, il est maintenant beaucoup plus facile d’identifier vos pages les plus importantes: celles qui génèrent des visites organiques, bien convertir, contribuer aux revenus, ont un bon nombre de domaines de référence reliant à eux, etc. Ce sont les pages sur lesquelles vous devez vous concentrer pour une migration réussie du site.

Les pages les plus performantes devraient idéalement exister également sur le nouveau site. Si pour une raison quelconque, ils ne le font pas, ils doivent être redirigés vers la page la plus pertinente afin que les utilisateurs qui en font la demande ne déterrent pas sur 404 pages et l’équité de lien qu’ils avaient auparavant reste sur le site. Si l’une de ces pages cesse d’exister et n’est pas correctement redirigée, les classements et le trafic de votre site seront affectés négativement.

Benchmarking

Une fois que le lancement du nouveau site Web se rapproche, vous devez comparer les performances du site hérité. L’analyse comparative est essentielle, non seulement pour comparer les performances du nouveau site avec le précédent, mais aussi pour aider à diagnostiquer les zones sous-performantes sur le nouveau site et à les aborder rapidement.

Les mots-clés classent le suivi

Si vous ne suivez pas fréquemment le classement du site, vous devriez le faire juste avant la mise en service du nouveau site. Sinon, vous aurez plus tard du mal à déterminer si la migration s’est bien déroulée ou où exactement les choses ont mal tourné. Ne laissez pas cela à la dernière minute au cas où quelque chose tourne mal – une semaine à l’avance serait le moment idéal.

Passez un peu de temps à savoir quels mots clés sont les plus représentatifs de la visibilité organique du site et suivez-les sur le bureau et le mobile. Parce que la surveillance de milliers de combinaisons de mots clés à la tête, à mi-queue et à longue queue est généralement irréaliste, le strict minimum que vous devriez surveiller sont des mots clés qui conduisent le trafic vers le site (mots clés de classement à la page un) et ont un volume de recherche décent (tête / mi-queue focus)

Si vous obtenez du trafic à partir de mots clés de marque et non-marque, vous devez également décider quel type de mots clés à se concentrer sur plus à partir d’un suivi POV. En général, les mots clés non-marques ont tendance à être plus compétitifs et volatils. Pour la plupart des sites, il serait logique de se concentrer principalement sur ces derniers.

N’oubliez pas de suivre les classements sur ordinateur de bureau et mobile. Cela facilitera beaucoup le diagnostic des problèmes après le lancement s’il y a des problèmes de performances sur un type d’appareil. Si vous recevez un volume élevé de trafic de plus d’un pays, considérez les mots clés de suivi de rang dans d’autres marchés, aussi, parce que la visibilité et les classements peuvent varier considérablement d’un pays à l’autre.

Performances du site

Les temps de chargement des pages du nouveau site peuvent avoir un impact important sur le trafic et les ventes. Plusieurs études ont montré que plus une page prend de temps à charger, plus le taux de rebond est élevé. À moins que les temps de chargement des pages de l’ancien site et les scores de performances du site n’aient été enregistrés, il sera très difficile d’attribuer du trafic ou des pertes de revenus aux problèmes liés aux performances du site une fois que le nouveau site aura été mis en service.

Il est recommandé de passer en revue tous les principaux types de pages à l’aide des outils PageSpeed Insights et Lighthouse de Google. Vous pouvez utiliser des tableaux sommaires comme ceux ci-dessous pour comparer certaines des mesures de performance les plus importantes, qui seront utiles pour les comparaisons une fois que le nouveau site sera mis en ligne.

Mobile	Vitesse	Fcp	Dcl	Optimisation	Score d’optimisation
Accueil	Rapide	0,7 s	1,4 s	Bon	81/100
Page de catégorie	Lent	1,8 s	5.1s (en)	taille moyenne	78/100
Page de sous-catégorie	Moyenne	0,9 s	2,4 s	taille moyenne	69/100
Page produit	Lent	1,9 s	5.5s (en)	Bon	83/100

Bureau	Vitesse	Fcp	Dcl	Optimisation	Score d’optimisation
Accueil	Bon	0,7 s	1,4 s	Moyenne	81/100
Page de catégorie	Rapide	0,6 s	1,2 s	taille moyenne	78/100
Page de sous-catégorie	Rapide	0,6 s	1,3 s	taille moyenne	78/100
Page produit	Bon	0,8 s	1,3 s	Bon	83/100

Anciennes données d’analyse de site

Quelques jours avant que le nouveau site remplace l’ancien, exécuter un crawl final de l’ancien site. Cela pourrait plus tard s’avérer inestimable, s’il y avait des problèmes d’optimisation sur le nouveau site. Une dernière analyse vous permettra d’enregistrer des informations vitales sur les titres de page de l’ancien site, les descriptions méta, les titres h1-h6, l’état du serveur, les balises canoniques, les pages noindex/nofollow, les inliens/outlinks, le niveau, etc. Avoir toutes ces informations disponibles pourrait vous éviter beaucoup d’ennuis si, par exemple, le nouveau site n’est pas bien optimisé ou souffre de problèmes techniques de mauvaise configuration. Essayez également d’enregistrer une copie des cartes de site robots.txt et XML de l’ancien site au cas où vous en aurez besoin plus tard.

Données console de recherche

Envisagez également d’exporter autant que possible les données de l’ancien site sur la console de recherche. Ceux-ci ne sont disponibles que pendant 90 jours, et les chances sont que, une fois que le nouveau site va vivre les données de l’ancien site Search Console disparaîtra tôt ou tard. Les données qui valent la peine d’être exportées comprennent :

Rechercher des requêtes et des pages d’analyse
Erreurs de crawl
Ressources bloquées
Problèmes d’utilisabilité mobile
Paramètres URL
Erreurs de données structurées
Liens vers votre site
Liens internes
Statut de l’index

Redirige la préparation

La mise en œuvre des redirections est l’une des activités les plus cruciales lors d’une migration de site. Si les URL du site hérité cessent d’exister et ne sont pas correctement redirigées, le classement et la visibilité du site seront tout simplement tank.

Pourquoi les redirections sont-elles importantes dans les migrations de sites ?

Les redirections sont extrêmement importantes parce qu’elles aident les moteurs de recherche et les utilisateurs à trouver des pages qui peuvent ne plus exister, qui ont été rebaptisées ou déplacées vers un autre endroit. Du point de vue du référencement, les redirections aident les moteurs de recherche à découvrir et indexer plus rapidement les nouvelles URL d’un site, mais comprennent aussi comment les pages de l’ancien site sont associées aux pages du nouveau site. Cette association permettra de passer des anciennes pages aux anciennes pages, de sorte que les classements sont conservés sans être affectés négativement.

Que se passe-t-il lorsque les redirections ne sont pas correctement implémentées ?

Lorsque les redirections sont mal mises en œuvre, les conséquences peuvent être catastrophiques. Les utilisateurs atterriront sur les pages non trouvées (404s) ou les pages non pertinentes qui ne répondent pas à l’intention de l’utilisateur. Dans les deux cas, les taux de rebond et de conversion du site seront affectés négativement. Les conséquences pour les moteurs de recherche peuvent être tout aussi catastrophiques : ils ne pourront pas associer les pages de l’ancien site à celles du nouveau site si les URL ne sont pas identiques. Les signaux de classement ne seront pas transmis de l’ancien au nouveau site, ce qui se traduira par des baisses de classement et une perte de visibilité de recherche organique. En outre, il faudra plus de temps aux moteurs de recherche pour découvrir et indexer les pages du nouveau site.

301, 302, JavaScript redirige, ou méta rafraîchissement?

Lorsque les URL entre l’ancienne et la nouvelle version du site sont différentes, utilisez 301 redirections (permanentes). Ceux-ci indiqueront aux moteurs de recherche d’indexer les nouvelles URL ainsi que de transmettre tous les signaux de classement des anciennes URL aux nouvelles. Par conséquent, vous devez utiliser 301 redirections si votre site se déplace vers / à partir d’un autre domaine / sous-domaine, si vous passez de HTTP à HTTPS, ou si le site ou des parties de celui-ci ont été restructurés. Malgré certaines des affirmations de Google selon lesquelles 302 redirections passent PageRank, l’indexation des nouvelles URL serait plus lente et les signaux de classement pourraient prendre beaucoup plus de temps à être transmis de l’ancien à la nouvelle page.

302 redirections (temporaires) ne doivent être utilisées que dans les situations où une redirection n’a pas besoin de vivre en permanence et donc l’indexation de la nouvelle URL n’est pas une priorité. Avec 302 redirections, les moteurs de recherche seront d’abord réticents à indexer le contenu de l’URL de destination redirection et à lui transmettre tous les signaux de classement. Toutefois, si les redirections temporaires restent pendant une longue période sans être supprimées ou mises à jour, elles pourraient finir par se comporter de la même façon que les redirections permanentes (301). Utilisez 302 redirections lorsqu’une redirection est susceptible d’exiger une mise à jour ou une suppression dans un proche avenir, ainsi que pour toute redirection par pays, langue ou périphérique.

Meta actualiser et JavaScript redirections doivent être évités. Même si Google est de mieux en mieux à ramper JavaScript, il n’y a aucune garantie que ceux-ci seront découverts ou passer des signaux de classement aux nouvelles pages.

Si vous souhaitez en savoir plus sur la façon dont Google traite les différents types de redirections, s’il vous plaît se référer à la poste de John Mueller.

Rediriger le processus de cartographie

Si vous avez la chance de travailler sur une migration qui n’implique pas de modifications d’URL, vous pouvez sauter cette section. Sinon, lisez la suite pour savoir pourquoi les pages héritées qui ne seront pas disponibles sur la même URL après la migration doivent être redirigées.

Le fichier de cartographie de redirection est une feuille de calcul qui comprend les deux colonnes suivantes :

URL du site hérité – URL d’une page sur l’ancien site.
Nouvelle URL du site – URL d’une page sur le nouveau site.

Lorsque vous cartographiez (rediriger) une page de l’ancien vers le nouveau site, essayez toujours de la cartographier vers la page correspondante la plus pertinente. Dans les cas où une page pertinente n’existe pas, évitez de rediriger la page vers la page d’accueil. Tout d’abord, la redirection des utilisateurs vers des pages non pertinentes entraîne une expérience utilisateur très médiocre. Google a déclaré que la redirection des pages “en masse” vers des pages non pertinentes sera traitée comme 404s doux et à cause de cela ne sera pas passer toute valeur SEO. Si vous ne trouvez pas une page équivalente sur le nouveau site, essayez de la cartographier à sa page de catégorie parente.

Une fois la cartographie terminée, le fichier devra être envoyé à l’équipe de développement pour créer les redirections, afin qu’elles puissent être testées avant le lancement du nouveau site. La mise en œuvre de redirections est une autre partie du cycle de migration du site où les choses peuvent souvent mal tourner.

Accroître l’efficacité au cours du processus de cartographie de redirection

La cartographie redirecte exige une grande attention aux détails et doit être effectuée par des OE expérimentés. La cartographie de l’URL sur les petits sites pourrait en théorie être effectuée en cartographiant manuellement chaque URL du site hérité à une URL sur le nouveau site. Mais sur les grands sites qui se composent de milliers, voire de centaines de milliers de pages, la cartographie manuelle de chaque URL est pratiquement impossible et l’automatisation doit être introduite. S’appuyer sur certains attributs communs entre l’héritage et le nouveau site peut être un gain de temps énorme. Ces attributs peuvent inclure les titres de page, les titres H1, ou d’autres identifiants de page uniques tels que les codes de produits, SKUs etc. Assurez-vous que les attributs sur lesquels vous vous fiez pour la cartographie de redirection sont uniques et ne sont pas répétés sur plusieurs pages ; sinon, vous vous retrouverez avec une cartographie incorrecte.

Astuce Pro: Assurez-vous que la structure URL du nouveau site est de 100 finalisé sur la mise en scène avant de commencer à travailler sur la cartographie de redirection. Il n’y a rien de plus risqué que de cartographier les URL qui seront mises à jour avant la mise en service du nouveau site. Lorsque les URL sont mises à jour après la fin de la cartographie de la redirection, vous devrez peut-être faire face à des situations indésirables lors du lancement, telles que des redirections cassées, des chaînes de redirection et des boucles de redirection. Un gel de contenu doit être placé sur l’ancien site bien avant la date de migration, de sorte qu’il y a un point de coupure pour le nouveau contenu publié sur l’ancien site. Cela permettra de s’assurer qu’aucune page ne sera manquée de la cartographie de redirection et de garantir que toutes les pages sur l’ancien site sont redirigées.

N’oubliez pas les redirections héritées !

Vous devriez mettre la main sur les redirections existantes de l’ancien site pour vous assurer qu’elles sont prises en compte lors de la préparation de la cartographie de redirection du nouveau site. Sauf si vous faites cela, il est probable que le fichier de redirection actuel du site sera écrasé par le nouveau à la date de lancement. Si cela se produit, toutes les redirections héritées qui étaient auparavant en place cesseront d’exister et le site peut perdre une quantité décente d’équité de lien, dont l’ampleur dépendra en grande partie du volume du site de redirections héritées. Par exemple, un site qui a subi quelques migrations dans le passé devrait avoir un bon nombre de redirections héritées en place que vous ne voulez pas se perdre.

Idéalement, conservez autant de redirections héritées que possible, en vous assurant qu’elles ne causeront aucun problème lorsqu’elles sont combinées avec les redirections du nouveau site. Il est fortement recommandé d’éliminer toute chaîne de redirection potentielle à ce stade précoce, ce qui peut facilement être fait en vérifiant si la même URL apparaît à la fois comme une « URL Legacy » et « Nouvelle URL du site » dans la feuille de calcul de la cartographie de redirection. Si tel est le cas, vous devrez mettre à jour l’URL du nouveau site en conséquence.

Exemple:

UrL A redirige vers l’URL B (redirection de l’héritage)

L’URL B redirige vers l’URL C (nouvelle redirection)

Ce qui se traduit par la chaîne de redirection suivante :

URL A et URL B et URL C

Pour éliminer cela, modifiez la réorientation de l’héritage existant et créez-en une nouvelle afin que :

URL A redirige vers l’URL C (redirection de l’héritage modifié)

L’URL B redirige vers l’URL C (nouvelle redirection)

Astuce Pro: Vérifiez votre feuille de calcul de cartographie de redirection pour les boucles de redirection. Ceux-ci se produisent lorsque l’URL De l’héritage est identique à l’URL du « nouveau site ». Les boucles de redirection doivent être supprimées car elles entraînent un chargement infini des pages inaccessibles aux utilisateurs et aux moteurs de recherche. Les boucles de redirection doivent être éliminées parce qu’il s’agit de trafic instantané, de conversion et de classement des tueurs !

Mettre en œuvre des règles générales de redirection pour éviter le contenu en double

Il est fortement recommandé d’essayer de travailler sur les règles de redirection qui couvrent autant de demandes d’URL que possible. La mise en œuvre de règles de redirection sur un serveur Web est beaucoup plus efficace que de s’appuyer sur de nombreuses redirections en tête-à-tête. Si votre document de cartographie de redirection se compose d’un très grand nombre de redirections qui doivent être implémentées en tant que règles de redirection en tête-à-tête, les performances du site pourraient être affectées négativement. Dans tous les cas, vérifiez auprès de l’équipe de développement le nombre maximum de redirections que le serveur Web peut gérer sans problème.

Dans tous les cas, il existe des règles de redirection standard qui devraient être en place pour éviter de générer des problèmes de contenu en double:

Cas d’URL : Toutes les URL contenant des caractères de cas supérieurs doivent être redirigées 301 vers toutes les URL minuscules, par exemple https://www.website.com/Page/ devraient être automatiquement redirigées vers https://www.website.com/page/

Animateur : Par exemple, toutes les URL non-www doivent être redirigées vers leur équivalent www, par exemple https://website.com/page/ devraient être redirigés vers https://www.website.com/page/

Protocole : Sur un site Web sécurisé, les demandes d’URL HTTP doivent être redirigées vers l’URL HTTPS équivalente, par exemple http://www.website.com/page/ devrait automatiquement rediriger vers https://www.website.com/page/

Slash de fuite : Par exemple, toute URL ne contenant pas de barre oblique de fuite doit être redirigévers vers une version avec une barre oblique de fuite, par exemple http://www.website.com/page devrait être redirigé vers http://www.website.com/page/

Même si certaines de ces règles de redirection standard existent sur le site Web hérité, ne supposez pas qu’elles existeront nécessairement sur le nouveau site à moins qu’elles ne soient explicitement demandées.

Éviter les redirections internes

Essayez de mettre à jour les liens internes du site afin qu’ils ne déclenchent pas de redirections internes. Même si les moteurs de recherche peuvent suivre les redirections internes, ceux-ci ne sont pas recommandés parce qu’ils ajoutent une latence supplémentaire aux temps de chargement des pages et pourraient également avoir un impact négatif sur le temps d’exploration des moteurs de recherche.

N’oubliez pas vos fichiers d’images

Si les images du site ont été déplacées vers un nouvel emplacement, Google recommande de rediriger les anciennes URL d’image vers les nouvelles URL d’image pour aider Google à découvrir et indexer les nouvelles images plus rapidement. S’il n’est pas facile de rediriger toutes les images, visez à rediriger au moins les URL d’image qui ont accumulé des backlinks.

Phase 3 : Essais de pré-lancement

Le plus tôt vous pouvez commencer à tester, le mieux. Certaines choses doivent être entièrement mises en œuvre pour être testées, mais d’autres ne le font pas. Par exemple, les problèmes de voyage de l’utilisateur pourraient être identifiés dès la conception des prototypes ou des images filaires. Les problèmes liés au contenu entre l’ancien et le nouveau site ou les incohérences de contenu (par exemple entre le bureau et le site mobile) pourraient également être identifiés à un stade précoce. Mais les composants les plus techniques ne devraient être testés qu’une fois entièrement mis en œuvre — des choses comme des redirections, des balises canoniques ou des cartes de site XML. Plus les problèmes sont identifiés tôt, plus il est probable qu’ils seront abordés avant le lancement du nouveau site. L’identification de certains types de problèmes à un stade ultérieur n’est pas rentable, nécessiterait plus de ressources et entraînerait des retards importants. Mauvais test et ne pas permettre le temps nécessaire pour tester soigneusement tous les blocs de construction qui peuvent affecter les performances SEO et UX peut avoir des conséquences désastreuses peu de temps après le nouveau site a été mis en ligne.

S’assurer que les moteurs de recherche ne peuvent pas accéder au site de mise en scène/test

Avant de rendre le nouveau site disponible dans un environnement de mise en scène/test, prenez certaines précautions pour que les moteurs de recherche ne l’indexent pas. Il ya quelques façons différentes de le faire, chacun avec des avantages et des inconvénients différents.

Site disponible pour des IP spécifiques (les plus recommandés)

Rendre le site de test disponible uniquement pour les adresses IP spécifiques (sur liste blanche) est un moyen très efficace d’empêcher les moteurs de recherche de le ramper. Toute personne essayant d’accéder à l’URL du site de test ne sera pas en mesure de voir tout contenu à moins que leur ADRESSE IP a été mis sur la liste blanche. Le principal avantage est que les utilisateurs sur liste blanche pourraient facilement accéder et ramper le site sans aucun problème. Le seul inconvénient est que les outils Web tiers (tels que les outils de Google) ne peuvent pas être utilisés en raison des restrictions de propriété intellectuelle.

Protection par mot de passe

Mot de passe protégeant le site de mise en scène / test est une autre façon de garder les robots de recherche moteur loin, mais cette solution a deux principaux inconvénients. Selon l’implémentation, il peut ne pas être possible d’explorer et de tester un site Web protégé par mot de passe si l’application crawler ne passe pas l’écran de connexion. Autre inconvénient : les sites Web protégés par mot de passe qui utilisent des formulaires d’authentification peuvent être analysés à l’aide d’applications tierces, mais il existe un risque de causer des problèmes graves et inattendus. C’est parce que le crawler clique sur chaque lien sur une page (lorsque vous êtes connecté) et pourrait facilement finir par cliquer sur les liens qui créent ou suppriment des pages, installer / désinstaller des plugins, etc.

Blocage de Robots.txt

L’ajout des lignes de code suivantes au fichier robots.txt du site d’essai empêchera les moteurs de recherche de ramper dans les pages du site d’essai.

Agent d’utilisateur :
Refuser: /

Un inconvénient de cette méthode est que même si le contenu qui apparaît sur le serveur de test ne sera pas indexé, les URL interdites peuvent apparaître sur les résultats de recherche de Google. Un autre inconvénient est que si le fichier ci-dessus robots.txt se déplace dans le site en direct, il va causer de graves problèmes de désindexation. C’est quelque chose que j’ai rencontré de nombreuses fois et pour cette raison, je ne recommanderais pas d’utiliser cette méthode pour bloquer les moteurs de recherche.

Examen du parcours de l’utilisateur

Si le site a été repensé ou restructuré, il y a de fortes chances que les trajets des utilisateurs soient affectés dans une certaine mesure. L’examen des trajets des utilisateurs le plus tôt possible et bien avant le lancement du nouveau site est difficile en raison du manque de données utilisateur. Cependant, un professionnel expérimenté de l’UX sera en mesure de signaler toute préoccupation qui pourrait avoir un impact négatif sur le taux de conversion du site. Parce que les tests A/B à ce stade n’est presque jamais possible, il pourrait être utile d’effectuer des tests utilisateur et essayer d’obtenir des commentaires des utilisateurs réels. Malheureusement, les problèmes d’expérience utilisateur peuvent être parmi les plus difficiles à résoudre, car ils peuvent nécessiter des changements à l’échelle du site qui prennent beaucoup de temps et d’efforts.

Sur les révisions complètes du site, toutes les décisions UX ne peuvent pas toujours être étayées par des données et de nombreuses décisions devront être fondées sur les meilleures pratiques, l’expérience passée, et le «sentiment d’intestin», d’où obtenir UX / CRO experts impliqués dès que possible pourrait payer des dividendes plus tard.

Examen de l’architecture du site

Une migration de site est souvent une excellente occasion d’améliorer l’architecture du site. En d’autres termes, vous avez une grande chance de réorganiser votre contenu ciblé par mot clé et de maximiser son potentiel de trafic de recherche. La réalisation de recherches approfondies sur les mots clés aidera à identifier les meilleures pages de catégorie et de sous-catégorie possible afin que les utilisateurs et les moteurs de recherche puissent se rendre à n’importe quelle page du site en quelques clics — moins il y a de mieux, de sorte que vous ne vous retrouvez pas avec une taxonomie très profonde.

Identifier de nouveaux mots clés avec un potentiel de trafic décent et les cartographier dans de nouvelles pages de destination peut faire une grande différence pour les niveaux de trafic organique du site. D’autre part, l’amélioration de l’architecture du site doit être fait de façon réfléchie. Itt pourrait causer des problèmes si, par exemple, les pages importantes se déplacent plus profondément dans la nouvelle architecture du site ou il ya trop de pages similaires optimisées pour les mêmes mots clés. Certaines des migrations de sites les plus réussies sont les plus importantes qui allouent des ressources importantes pour améliorer l’architecture du site.

Méta données et examen de copie

Assurez-vous que les titres de page du site, les méta-descriptions, les titres et la copie ont été transférés de l’ancien au nouveau site sans problème. Si vous avez créé de nouvelles pages, assurez-vous qu’elles sont optimisées et ne ciblez pas les mots clés qui ont déjà été ciblés par d’autres pages. Si vous re-plateforme, sachez que la nouvelle plate-forme peut avoir des valeurs par défaut différentes lors de la création de nouvelles pages. Le lancement du nouveau site sans titres de page correctement optimisés ou tout autre type de copie manquante aura un impact négatif immédiat sur les classements et le trafic de votre site. N’oubliez pas d’examiner si du contenu généré par l’utilisateur (c.-à-d. commentaires, commentaires et commentaires des utilisateurs) a également été téléchargé.

Examen des liens internes

Les liens internes sont l’épine dorsale d’un site Web. Peu importe comment bien optimisé et structuré la copie du site est, il ne sera pas suffisant pour réussir à moins qu’il ne soit soutenu par un système de liaison interne sans faille. Les liens internes doivent être examinés sur l’ensemble du site, y compris les liens trouvés dans :

Navigation principale et secondaire
Liens en-tête et footer
Liens de contenu corporel
Liens pagination
Liens horizontaux (articles connexes, produits similaires, etc.)
Liens verticaux (p. ex. navigation de chapelure)
Liens inter-sites (p. ex. liens entre les sites internationaux)

Vérifications techniques

Une série de contrôles techniques doit être effectuée pour s’assurer que la configuration technique du nouveau site est saine et pour éviter de rencontrer des problèmes techniques majeurs après la mise en service du nouveau site.

Examen des fichiers Robots.txt

Préparer le fichier robots.txt du nouveau site sur l’environnement de mise en scène. De cette façon, vous pouvez le tester pour les erreurs ou les omissions et éviter d’éprouver des problèmes d’exploration du moteur de recherche lorsque le nouveau site va en ligne. Une erreur classique dans les migrations de site est lorsque le fichier robots.txt empêche l’accès au moteur de recherche en utilisant la directive suivante:

Refuser: /

Si cela est accidentellement reporté dans le site en direct (et il le fait souvent), il empêchera les moteurs de recherche de ramper sur le site. Et lorsque les moteurs de recherche ne peuvent pas explorer une page indexée, les mots clés associés à la page seront rétrogradés dans les résultats de recherche et, éventuellement, la page sera désindexée.

Mais si le fichier robots.txt sur la mise en scène est peuplé de directives robots.txt du nouveau site, cette mésaventure pourrait être évitée.

Lors de la préparation du fichier robots.txt du nouveau site, assurez-vous que :

Il ne bloque pas l’accès des moteurs de recherche aux pages qui sont destinées à être indexées.
Il ne bloque aucun JavaScript ou CSS ressources moteurs de recherche nécessaires pour rendre le contenu de la page.
Le contenu du fichier robots.txt du site existant a été examiné et reporté si nécessaire.
Il fait référence aux nouvelles cartes de sites XML plutôt qu’à toutes les cartes héritées qui n’existent plus.

Examen des balises canoniques

Examinez les balises canoniques du site. Recherchez les pages qui n’ont pas de balise canonique ou qui ont une étiquette canonique qui indique une autre URL et vous demandez si cela est prévu. N’oubliez pas d’explorer les balises canoniques pour savoir si elles renvoient une réponse de 200 serveurs. Si ce n’est pas le cas, vous devrez les mettre à jour pour éliminer les réponses des serveurs 3xx, 4xx ou 5xx. Vous devriez également rechercher des pages qui ont une balise canonique pointant vers une autre URL combinée avec une directive noindex, parce que ces deux sont des signaux contradictoires et vous; ll besoin d’éliminer l’un d’eux.

Méta robots examen

Une fois que vous avez rampé sur le site de transit, recherchez des pages avec les propriétés méta robots réglés sur “noindex” ou “nofollow”. Si tel est le cas, examinez chacun d’eux pour vous assurer que c’est intentionnel et supprimez la directive « noindex » ou « nofollow » si ce n’est pas le cas.

XML sitemaps examen

Préparez deux types différents de cartes de site : l’une qui contient toutes les pages indexables du nouveau site, et l’autre qui inclut toutes les pages indexables de l’ancien site. Le premier aidera à sensibiliser Google aux URL indexables du nouveau site. Ce dernier aidera Google à prendre conscience des redirections qui sont en place et le fait que certaines des URL indexées ont déménagé vers de nouveaux endroits, afin qu’il puisse les découvrir et mettre à jour les résultats de recherche plus rapidement.

Vous devez vérifier chaque carte de site XML pour vous assurer que :

Il valide sans problèmes
Il est encodé comme UTF-8
Il ne contient pas plus de 50 000 lignes
Sa taille ne dépasse pas 50MBs lorsqu’elle n’est pas compressée

S’il y a plus de lignes de 50K ou si la taille du fichier dépasse 50 Mo, vous devez décomposer la carte du site en plus petites. Cela empêche le serveur de devenir surchargé si Google demande la carte du site trop fréquemment.

En outre, vous devez explorer chaque carte de site XML pour vous assurer qu’elle n’inclut que des URL indexables. Toutes les URL non indexables doivent être exclues des cartes de sites XML, telles que :

3xx, 4xx et 5xx pages (p. ex. redirigées, pages non trouvées, mauvaises demandes, etc.)
404s doux. Ce sont des pages sans contenu qui renvoient une réponse de 200 serveurs, au lieu d’un 404.
Pages canonicalisées (à part les URL canoniques auto-référencées)
Pages avec une directive méta robots noindex

<! DOCTYPE html>
<Html><Tête>
<meta name "robots" contenu "noindex" />
(...)
</tête>
<corps>(...)  /corps>
</html (html)>

Pages avec un noindex X-Robots-Tag dans l’en-tête HTTP

HTTP/1.1 200 OK
Date: mar, 10 Nov 2017 17:12:43 GMT
(...)
X-Robots-Tag: noindex
(...)

Pages bloquées à partir du fichier robots.txt

Construire des cartes de site XML propres peut aider à surveiller les niveaux réels d’indexation du nouveau site une fois qu’il est mis en ligne. Si vous ne le faites pas, il sera très difficile de repérer les problèmes d’indexation.

Astuce Pro: Téléchargez et ouvrez chaque carte de site XML dans Excel pour obtenir un aperçu détaillé de tous les attributs supplémentaires, tels que hreflang ou attributs d’image.

Examen de la carte de site HTML

Selon la taille et le type de site qui est migré, avoir une carte de site HTML peut dans certains cas être bénéfique. Une carte de site HTML composée d’URL qui ne sont pas liées à partir de la navigation principale du site peut augmenter considérablement la découverte de pages et l’indexation. Toutefois, évitez de générer une carte de site HTML qui comprend trop d’URL. Si vous avez besoin d’inclure des milliers d’URL, envisagez de créer une carte de site HTML segmentée.

Le nombre de cartes de site nouétés ainsi que le nombre maximal d’URL que vous devez inclure dans chaque carte de site dépend de l’autorité du site. Plus un site Web fait autorité, plus le nombre de cartes de sites et d’URL nichés pourrait s’en tirer.

Par exemple, la carte de site HTML NYTimes.com se compose de trois niveaux, où chacun comprend plus de 1 000 URL par carte de site. Ces sites HTML imisés aident les robots de recherche à découvrir des articles publiés depuis 1851 qui autrement seraient difficiles à découvrir et à indexer, car ils n’auraient pas tous été liés en interne.

La carte de site HTML NYTimes (niveau 1)

La carte de site HTML NYTimes (niveau 2)

Examen structuré des données

Les erreurs dans le balisage des données structurées doivent être identifiées tôt, de sorte qu’il est temps de les corriger avant que le nouveau site ne soit mis en ligne. Idéalement, vous devriez tester chaque modèle de page (plutôt que chaque page) à l’aide de l’outil de test de données structuréesde Google.

Assurez-vous de vérifier le balisage sur les pages de bureau et mobiles, surtout si le site Web mobile n’est pas réactif.

L’outil ne signalera que les erreurs existantes, mais pas les omissions. Par exemple, si le modèle de votre page de produit n’inclut pas le schéma de données structurés du produit, l’outil ne signalera aucune erreur. Ainsi, en plus de vérifier les erreurs, vous devez également vous assurer que chaque modèle de page inclut le balisage de données structurés approprié pour son type de contenu.

Veuillez consulter la documentation de Google pour les détails les plus à jour sur la mise en œuvre de données structurées et les types de contenu pris en charge.

JavaScript crawling examen

Vous devez tester chaque modèle de page unique du nouveau site pour vous assurer que Google sera en mesure d’analyser le contenu qui nécessite l’analyse JavaScript. Si vous êtes en mesure d’utiliser l’outil Fetch and Render de Google sur votre site de transit, vous devriez certainement le faire. Sinon, effectuer quelques tests manuels, suivant les conseils de Justin Brigg.

Comme l’ont prouvé les tests de Bartosz Goralewicz, même si Google est capable d’explorer et d’indexer du contenu généré par JavaScript, cela ne signifie pas qu’il est capable d’explorer le contenu JavaScript dans tous les principaux frameworks JavaScript. Le tableau suivant résume les conclusions de Bartosz, montrant que certains cadres JavaScript ne sont pas SEO-friendly, avec AngularJS actuellement être le plus problématique de tous.

Bartosz a également constaté que d’autres moteurs de recherche (tels que Bing, Yandex, et Baidu) vraiment du mal avec l’indexation du contenu généré par JavaScript, qui est important de savoir si le trafic de votre site repose sur l’un de ces moteurs de recherche.

Espérons que c’est quelque chose qui va s’améliorer au fil du temps, mais avec la popularité croissante des cadres JavaScript dans le développement web, cela doit être haut sur votre liste de contrôle.

Enfin, vous devez vérifier si des ressources externes sont bloquées. Malheureusement, ce n’est pas quelque chose que vous pouvez contrôler 100 parce que de nombreuses ressources (tels que JavaScript et fichiers CSS) sont hébergés par des sites Web tiers qui peuvent être les bloquer via leurs propres fichiers robots.txt!

Encore une fois, l’outil Fetch and Render peut aider à diagnostiquer ce type de problème qui, s’il n’est pas résolu, pourrait avoir un impact négatif significatif.

Mobile site SEO examen

Examen du blocage des actifs

Tout d’abord, assurez-vous que le fichier robots.txt ne bloque pas accidentellement les fichiers JavaScript, CSS ou image qui sont essentiels pour le contenu du site mobile à rendre. Cela pourrait avoir un impact négatif sur la façon dont les moteurs de recherche rendent et indexent le contenu de la page du site mobile, ce qui pourrait affecter négativement la visibilité et les performances de recherche du site mobile.

Examen de l’index Mobile-first

Afin d’éviter tout problème associé à l’index mobile-premier de Google, examinez attentivement le site Web mobile et faites qu’il n’y a pas d’incohérences entre les sites de bureau et mobiles dans les domaines suivants :

Titres de page
Descriptions Meta
Rubriques
Copie
Étiquettes canoniques
Attributs meta robots (c.-à-d. noindex, nofollow)
Liens internes
Données structurées

Un site Web réactif doit servir le même contenu, les liens et le balisage entre les appareils, et les attributs SEO ci-dessus doivent être identiques sur les sites Web de bureau et mobiles.

En plus de ce qui précède, vous devez effectuer quelques contrôles techniques supplémentaires en fonction de la mise en place du site mobile.

Examen du site réactif

Un site Web réactif doit servir tous les appareils le même code HTML, qui est ajusté (via l’utilisation de CSS) en fonction de la taille de l’écran.

Googlebot est capable de détecter automatiquement cette configuration mobile tant qu’il est autorisé à explorer la page et ses actifs. Il est donc extrêmement important de s’assurer que Googlebot peut accéder à tous les actifs essentiels, tels que les images, JavaScript et fichiers CSS.

Pour signaler aux navigateurs qu’une page est réactive, une balise meta'”viewport” doit être en place dans la tête de chaque page HTML.

<meta nameMD "viewport" content "largeur de l’appareil-largeur, échelle initiale 1,0">

Si l’étiquette meta viewport est manquante, les tailles de police peuvent apparaître d’une manière incohérente, ce qui peut amener Google à traiter la page comme non mobile-friendly.

Examen séparé des URL mobiles

Si le site Web mobile utilise des URL séparées du bureau, assurez-vous que :

Chaque page de bureau a une balise pointant vers l’URL mobile correspondante.
Chaque page mobile est munit d’une balise rel-“canonique” pointant vers l’URL de bureau correspondante.
Lorsque les URL de bureau sont demandées sur les appareils mobiles, elles sont redirigées vers l’URL mobile respective.
Redirections travail sur tous les appareils mobiles, y compris Android, iPhone et Windows téléphones.
Il n’y a pas de liens croisés non pertinents entre les pages de bureau et mobiles. Cela signifie que les liens internes trouvés sur une page de bureau ne doivent être reliés qu’aux pages de bureau et ceux trouvés sur une page mobile ne doivent être reliés qu’à d’autres pages mobiles.
Les URL mobiles renvoient une réponse de 200 serveurs.

Examen dynamique des portions

Les sites Web de service dynamiques servent un code différent à chaque appareil, mais sur la même URL.

Sur les sites de service dynamiques, examinez si l’en-tête HTTP variable a été correctement mis en place. Ceci est nécessaire parce que les sites web de service dynamique s’altèrent le HTML pour les agents utilisateurs mobiles et l’en-tête HTTP varie aide Googlebot à découvrir le contenu mobile.

Mobile-friendliness examen

Indépendamment de la configuration du site mobile (URL réactives et séparées ou service dynamique), examinez les pages à l’aide d’un utilisateur-agent mobile et assurez-vous que :

Le viewport a été réglé correctement. L’utilisation d’un port d’œil à largeur fixe sur les appareils posera des problèmes d’utilisabilité mobile.
La taille de la police n’est pas trop petite.
Les éléments tactiles (boutons, liens) ne sont pas trop proches.
Il n’y a pas d’interstitiels intrusifs,tels que les annonces, les formulaires d’inscription à la liste de diffusion, les pop-ups De téléchargement d’applications, etc. Pour éviter tout problème, vous devez utiliser soit un petit HTML ou une bannière d’image.
Les pages mobiles ne sont pas trop lentes à charger (voir la section suivante).

L’outil de test mobile de Google peut aider à diagnostiquer la plupart des problèmes ci-dessus :

L’outil de test mobile de Google en action

Examen du site de l’AMP

S’il existe un site Web AMP et une version de bureau du site est disponible, assurez-vous que:

Chaque page non-AMP (c.-à-d. bureau, mobile) a une balise pointant vers l’URL AMP correspondante.
Chaque page AMP a une balise rel -“canonique” pointant vers la page de bureau correspondante.
Toute page AMP qui n’a pas d’URL de bureau correspondante a une balise canonique auto-référencée.

Vous devez également vous assurer que les AMP sont valides. Cela peut être testé à l’aide de l’outil de test AMP de Google.

Erreurs de contenu mixte

Avec Google poussant dur pour les sites d’être entièrement sécurisé et Chrome devient le premier navigateur à les pages HTTPde drapeau comme non sécurisées, visent à lancer le nouveau site sur HTTPS, en s’assurant que toutes les ressources telles que les images, les fichiers CSS et JavaScript sont demandées sur des connexions HTTPS sécurisées. Ceci est essentiel pour éviter questions de contenu mixte.

Le contenu mixte se produit lorsqu’une page chargée sur une connexion HTTPS sécurisée demande des actifs sur des connexions HTTP non sécurisées. La plupart des navigateurs bloquent les demandes HTTP dangereuses ou affichent simplement des avertissements qui entravent l’expérience utilisateur.

Erreurs de contenu mixte s’insinier dans la console JavaScript de Chrome

Il existe de nombreuses façons d’identifier les erreurs de contenu mixte, y compris l’utilisation d’applications de chenilles, phare de Google, etc.

Examen des actifs d’image

Google analyse les images moins fréquemment que les pages HTML. Si la migration des images d’un site d’un endroit à un autre (par exemple de votre domaine à un CDN), il existe des moyens d’aider Google à découvrir les images migrées plus rapidement. Construire une image XML sitemap aidera, mais vous devez également vous assurer que Googlebot peut atteindre les images du site lors de l’exploration du site. La partie délicate avec l’indexation d’image est que la page Web où une image apparaît sur aussi bien que le fichier d’image lui-même doivent obtenir indexé.

Examen du rendement du site

Enfin, mesurez les temps de chargement de la page de l’ancien site et voyez comment ceux-ci se comparent à ceux du nouveau site lorsque cela sera disponible sur la mise en scène. À ce stade, concentrez-vous sur les aspects de performance indépendants du réseau tels que l’utilisation de ressources externes (images, JavaScript et CSS), le code HTML et la configuration du serveur Web. Plus d’informations sur la façon de le faire est disponible plus bas.

Examen du suivi analytique

Assurez-vous que le suivi analytique est correctement mis en place. Cet examen devrait idéalement être effectué par des consultants en analyse spécialisés qui regarderont au-delà de la mise en œuvre du code de suivi. Assurez-vous que les objectifs et les événements sont correctement mis en place, le suivi du commerce électronique est mis en œuvre, le suivi amélioré du commerce électronique est activé, etc. Il n’y a rien de plus frustrant que de ne pas avoir de données d’analyse après le lancement de votre nouveau site.

Redirige les tests

Tester les redirections avant que le nouveau site ne soit mis en ligne est essentiel et peut vous éviter beaucoup d’ennuis plus tard. Il existe de nombreuses façons de vérifier les redirections sur un serveur de mise en scène / test, mais la ligne du bas est que vous ne devriez pas lancer le nouveau site Sans avoir testé les redirections.

Une fois que les redirections deviennent disponibles sur l’environnement de mise en scène/test, analysez la liste complète des redirections et vérifiez les problèmes suivants :

Rediriger les boucles (une URL qui se redirige infiniment vers elle-même)
Redirige avec une réponse de serveur 4xx ou 5xx.
Rediriger les chaînes (une URL qui redirige vers une autre URL, qui à son tour redirige vers une autre URL, etc.).
UrL canoniques qui renvoient une réponse serveur 4xx ou 5xx.
Boucles canoniques (page A a un pointage canonique à la page B, qui a un pointage canonique à la page A).
Chaînes canoniques (un canonique qui pointe vers une autre page qui a un pointon canonique vers une autre page, etc.).
Les incohérences protocole/hôte, par exemple les URL, sont redirigées vers les URL HTTP et HTTPS ou vers les URL www et non-www.
Personnages principaux/trailing whitespace. Utilisez la garniture() dans Excel pour les éliminer.
Caractères invalides dans les URL.

Astuce Pro : Assurez-vous que l’une des URL de l’ancien site redirige vers l’URL correcte sur le nouveau site. À ce stade, parce que le nouveau site n’existe pas encore, vous ne pouvez tester si l’URL de destination redirection est l’objectif, mais il vaut vraiment la peine. Le fait qu’une URL redirige ne signifie pas qu’elle redirige vers la page de droite.

Phase 4 : Activités de lancement

Lorsque le site est en panne…

Alors que le nouveau site remplace l’ancien, les chances sont que le site en direct va être temporairement vers le bas. Le temps d’arrêt doit être réduit au minimum, mais pendant ce temps, le serveur Web doit répondre à toute demande d’URL avec une réponse serveur 503 (service non disponible). Cela indiquera les robots de recherche moteur que le site est temporairement en panne pour la maintenance afin qu’ils reviennent à ramper sur le site plus tard.

Si le site est en panne pendant trop longtemps sans servir une réponse 503 serveur et les moteurs de recherche ramper le site, la visibilité de recherche organique sera négativement affectée et la récupération ne sera pas instantanée une fois que le site est de retour. En outre, tandis que le site est temporairement vers le bas, il devrait également servir une page de tenue informative informant les utilisateurs que le site est temporairement en panne pour la maintenance.

Vérifications techniques des taches

Dès que le nouveau site est mis en ligne, jetez un coup d’œil à :

Le fichier robots.txt pour s’assurer que les moteurs de recherche ne sont pas bloqués de ramper
Les pages supérieures sont redirige (p. ex., les demandes pour les pages supérieures de l’ancien site sont-elles réddiriger correctement?)
Top pages étiquettes canoniques
Réponses des serveurs des pages supérieures
Directives Noindex/nofollow, au cas où elles ne sont pas intentionnelles

Les contrôles ponctuels doivent être effectués à la fois sur les sites mobiles et de bureau, à moins que le site ne soit entièrement réactif.

Rechercher des actions Console

Les activités suivantes devraient avoir lieu dès que le nouveau site Web sera mis en ligne :

Test ezet et téléchargez la carte de site XML
Définir l’emplacement privilégié du domaine (www ou non-www)
Définir le ciblage international (le cas échéant)
Configurez les paramètres de l’URL pour résoudre rapidement les problèmes de contenu en double potentiels.
Télécharger le fichier Désavouer (le cas échéant)
Utilisez l’outil Changement d’adresse (si les domaines de commutation)

Conseil pro : Utilisez la fonction “Fetch as Google” pour chaque type de page (par exemple la page d’accueil, une catégorie, une sous-catégorie, une page de produit) pour vous assurer que Googlebot peut rendre les pages sans aucun problème. Examinez les ressources bloquées signalées et n’oubliez pas d’utiliser Fetch and Render pour le bureau et le mobile, surtout si le site Web mobile n’est pas réactif.

Les ressources bloquées empêchent Googlebot de rendre le contenu de la page

Phase 5 : Examen post-lancement

Une fois le nouveau site mis en service, une nouvelle série de contrôles approfondis devrait être effectuée. Ce sont en grande partie les mêmes que ceux mentionnés dans la section « Phase 3 : Test de pré-lancement ».

Cependant, la principale différence au cours de cette phase est que vous avez maintenant accès à beaucoup plus de données et d’outils. Ne sous-estimez pas l’effort que vous devrez faire au cours de cette phase, car tous les problèmes que vous rencontrez maintenant ont un impact direct sur les performances du site dans les SERP. D’autre part, plus tôt un problème est identifié, plus vite il sera résolu.

En plus de répéter les mêmes tâches de test qui ont été décrites dans la section de la phase 3, dans certains domaines, les choses peuvent être testées plus en profondeur, avec précision et plus en détail. Vous pouvez maintenant profiter pleinement des fonctionnalités de la console de recherche.

Vérifier les statistiques d’analyse et les journaux des serveurs

Gardez un œil sur les statistiques d’exploration disponibles dans la console de recherche, pour vous assurer que Google est ramper les pages du nouveau site. En général, lorsque Googlebot tombe sur de nouvelles pages, il a tendance à accélérer le nombre moyen de pages qu’il analyse par jour. Mais si vous ne pouvez pas repérer un pic autour du moment de la date de lancement, quelque chose peut affecter négativement la capacité de Googlebot à explorer le site.

Statistiques Crawl sur la console de recherche de Google

L’examen des fichiers journaux du serveur est de loin le moyen le plus efficace de repérer les problèmes d’analyse ou les inefficacités. Des outils comme Botify et On Crawl peuvent être extrêmement utiles parce qu’ils combinent des analyses avec des données de journal de serveur et peuvent mettre en évidence les moteurs de recherche des pages ne rampent pas, les pages qui ne sont pas liées à l’interne (pages orphelines), les pages de faible valeur qui sont fortement liées en interne, et beaucoup plus.

Examiner régulièrement les erreurs d’analyse

Gardez un œil sur les erreurs d’analyse signalées, idéalement tous les jours pendant les premières semaines. Le téléchargement quotidien de ces erreurs, l’analyse des URL signalées et la prise des mesures nécessaires (c.-à-d. implémenter 301 redirections supplémentaires, corriger les erreurs molles de 404) faciliteront une récupération plus rapide. Il est très peu probable que vous aurez besoin de rediriger chaque 404 unique qui est signalé, mais vous devez ajouter des redirections pour les plus importants.

Astuce Pro: Dans Google Analytics, vous pouvez facilement savoir quelles sont les 404 URL les plus fréquemment demandées et les corriger en premier !

Autres fonctionnalités utiles de la console de recherche

D’autres fonctionnalités de la console de recherche méritent d’être vérifiées, notamment les ressources bloquées, les erreurs de données structurées, les erreurs d’utilisabilité mobile, les améliorations HTML et le ciblage international (pour vérifier les erreurs signalées par hreflang).

Conseil pro : Surveillez de près les paramètres de l’URL au cas où ils causeraient des problèmes de contenu en double. Si tel est le cas, envisagez de prendre des mesures correctives urgentes.

Mesure de la vitesse du site

Une fois que le nouveau site est en ligne, mesurer la vitesse du site pour s’assurer que les pages du site se chargent assez rapidement sur les appareils de bureau et mobiles. Avec la vitesse du site étant un signal de classement à travers les appareils et parce que lespages lentes perdentdes utilisateurs et des clients , en comparant la vitesse du nouveau site avec l’ancien site est extrêmement important. Si les temps de chargement de la page du nouveau site semblent être plus élevés, vous devriez prendre des mesures immédiates, sinon le trafic de votre site et les conversions seront presque certainement prendre un coup.

Évaluer la vitesse à l’aide des outils de Google

Deux outils qui peuvent vous aider à cela sont phare de Google et Pagespeed Insights.

L’outil Pagespeed Insights mesure les performances des pages sur les appareils mobiles et de bureau et affiche les données de vitesse de page réelles basées sur les données utilisateur que Google recueille à partir de Chrome. Il vérifie également si une page a appliqué des pratiques exemplaires de performance communes et fournit un score d’optimisation. L’outil comprend les principales catégories suivantes :

Score de vitesse : Catégorise une page comme rapide, moyenne ou lente à l’aide de deux mesures : The First Contentful Paint (FCP) et DOM Content Loaded (DCL). Une page est considérée comme rapide si les deux mesures sont dans le tiers supérieur de leur catégorie.
Score d’optimisation : Catégorise une page comme Bonne, Moyenne ou Faible en fonction de la marge de manœuvre des performances.
Distributions de charge de page : Catégorise une page comme rapide (troisième la plus rapide), moyenne (troisième au milieu) ou Slow (troisième tiers inférieur) en comparant tous les événements FCP et DCL dans le rapport d’expérience utilisateur Chrome.
Statistiques de la page : peut indiquer si la page peut être plus rapide si le développeur modifie l’apparence et la fonctionnalité de la page.
Suggestions d’optimisation : Liste des meilleures pratiques qui pourraient être appliquées à une page.

Google PageSpeed Insights en action

Le phare de Google est très pratique pour les performances mobiles, l’accessibilité et les audits Progressifs des applications Web. Il fournit diverses mesures utiles qui peuvent être utilisées pour mesurer les performances des pages sur les appareils mobiles, telles que :

Première peinture significative qui mesure lorsque le contenu principal d’une page est visible.
Time to Interactive est le point où la page est prête pour un utilisateur d’interagir avec.
Les mesures de l’indice de vitesse montrent la vitesse à laquelle une page est visiblement peuplée

Les deux outils fournissent des recommandations pour aider à améliorer les problèmes de performance du site signalés.

Phare de Google en action

Vous pouvez également utiliser cet outil Google pour obtenir une estimation approximative du pourcentage d’utilisateurs que vous perdez peut-être des pages de votre site mobile en raison de la lenteur des temps de chargement des pages.

Le même outil fournit également une comparaison de l’industrie afin que vous ayez une idée de la distance que vous êtes des sites les plus performants dans votre industrie.

Mesurer la vitesse des utilisateurs réels

Une fois que le site a été mis en ligne, vous pouvez commencer à évaluer la vitesse du site en fonction des utilisateurs visitant votre site. Si vous avez Google Analytics, vous pouvez facilement comparer le temps de chargement moyen du nouveau site avec le précédent.

En outre, si vous avez accès à un outil de surveillance de l’utilisateur réel comme Pingdom, vous pouvez évaluer la vitesse du site en fonction des utilisateurs visitant votre site Web. La carte ci-dessous illustre comment différents visiteurs connaissent des temps de chargement très différents en fonction de leur emplacement géographique. Dans l’exemple ci-dessous, les temps de chargement des pages semblent satisfaisants pour les visiteurs du Royaume-Uni, des États-Unis et de l’Allemagne, mais pour les utilisateurs résidant dans d’autres pays, ils sont beaucoup plus élevés.

Phase 6 : Mesurer le rendement de la migration du site

Quand mesurer

La migration du site a-t-elle été couronnée de succès? C’est la question d’un million de dollars que toutes les personnes concernées aimeraient connaître dès la mise en ligne du nouveau site. En réalité, plus vous attendez, plus la réponse devient claire, car la visibilité pendant les premières semaines, voire les premiers mois peut être très volatile en fonction de la taille et de l’autorité de votre site. Pour les petits sites, une période de 4 à 6 semaines devrait être suffisante avant de comparer la visibilité du nouveau site avec la visibilité de l’ancien site. Pour les grands sites Web, vous devrez peut-être attendre au moins 2 à 3 mois avant de mesurer.

En outre, si le nouveau site est significativement différent du précédent, les utilisateurs auront besoin d’un certain temps pour s’habituer à la nouvelle look and feel et s’acclimater avec la nouvelle taxonomie, les voyages des utilisateurs, etc. Ces changements ont d’abord un impact négatif significatif sur le taux de conversion du site, ce qui devrait s’améliorer après quelques semaines, car les visiteurs de retour s’habituent de plus en plus au nouveau site. Dans tous les cas, il peut être risqué de tirer des conclusions sur les UX du nouveau site en matière de données.

Mais ce ne sont que des règles générales de base et doivent être prises en considération avec d’autres facteurs. Par exemple, si quelques jours ou semaines après le lancement du nouveau site, d’autres changements importants ont été apportés (p. ex. pour régler un problème technique), l’évaluation de la migration devrait être repoussée plus loin.

Comment mesurer

La mesure du rendement est très importante et même si les intervenants du secteur d’activité ne seraient intéressés qu’à entendre parler des revenus et de l’impact sur le trafic, il y a beaucoup d’autres mesures à laquelle vous devriez prêter attention. Par exemple, il peut y avoir plusieurs raisons pour lesquelles les revenus diminuent à la suite d’une migration du site, y compris les tendances saisonnières, la baisse de l’intérêt de la marque, les problèmes d’UX qui ont considérablement réduit le taux de conversion du site, les mauvaises performances mobiles, les temps de chargement des pages médiocres, Etc. Ainsi, en plus du trafic organique et des chiffres d’affaires, également prêter attention à ce qui suit:

Visibilité de bureau et mobile (de SearchMetrics, SEMrush, Sistrix)
Classement des ordinateurs de bureau et mobiles (à partir de n’importe quel outil fiable de suivi des classements)
Engagement des utilisateurs (taux de rebond, temps moyen sur la page)
Sessions par type de page (c.-à-d. les pages de catégorie qui conduisent autant de sessions qu’auparavant?)
Taux de conversion par type de page (c.-à-d. les pages de produits se convertissent-elles de la même manière qu’auparavant?)
Taux de conversion par appareil (c.-à-d. le taux de conversion bureau/mobile a-t-il augmenté/diminué depuis le lancement du nouveau site ?)

L’examen de ce qui est ci-dessous pourrait également être très pratique, en particulier d’un point de vue de dépannage technique:

Nombre de pages indexées (Console de recherche)
Soumis vs pages indexées dans les cartes de site XML (Console de recherche)
Pages recevant au moins une visite (analyse)
Vitesse du site (PageSpeed Insights, Lighthouse, Google Analytics)

Ce n’est qu’après avoir examiné toutes les zones ci-dessus que vous avez pu conclure en toute sécurité si votre migration a été réussie ou non.

Bonne chance et si vous avez besoin de consultation ou d’assistance pour la migration de votre site, contactez-nous!

Liste de contrôle de migration du site

Une liste de contrôle de migration de site à jour est disponible en téléchargement à partir de notre site. Veuillez noter que la liste de contrôle est régulièrement mise à jour pour inclure toutes les zones critiques pour une migration réussie du site.

Annexe: Outils utiles

Robots

Screaming Frog: Le couteau de l’armée suisse SEO, idéal pour ramper sur les petits et moyens sites Web.
Sitebulb: Application crawler très intuitive avec une interface utilisateur soignée, des rapports bien organisés, et de nombreuses visualisations de données utiles.
Deep Crawl: Crawl basé sur le nuage avec la possibilité d’explorer les sites de stadification et de faire des comparaisons d’analyse. Permet des comparaisons entre les différents crawls et fait face bien avec les grands sites Web.
Botify: Un autre robot basé sur le cloud puissant pris en charge par des capacités exceptionnelles d’analyse de fichiers de journal de serveur qui peuvent être très perspicaces en termes de compréhension de la façon dont les moteurs de recherche rampent sur le site.
On-Crawl: Analyseur de journal crawler et serveur pour les audits DE référencement d’entreprise avec de nombreuses fonctionnalités pratiques pour identifier le budget d’analyse, la qualité du contenu et les problèmes de performances.

Handy Chrome add-ons

Développeur Web: Une collection d’outils de développeur comprenant des moyens faciles d’activer/désactiver JavaScript, CSS, images, etc.
Commutateur d’agentutilisateur : Basculez entre différents agents utilisateur, y compris Googlebot, mobile, et d’autres agents.
Ayima Redirect Path: Un grand en-tête et un contrôleur de redirection.
SEO Meta en 1 clic: Un méta-attributs, des en-têtes et des liens inspecteurs sur la page.
Scraper: Un moyen facile d’gratter les données du site Web dans une feuille de calcul.

Outils de surveillance du site

Uptime Robot: Surveillance gratuite de la disponibilité du site Web.
Robotto: Outil de surveillance gratuit robots.txt.
Outils Pingdom: Surveille la disponibilité du site et la vitesse de la page des utilisateurs réels (service RUM)
RADAR SEO: Surveille tous les éléments DE SEO critiques et déclenche des alertes lorsque ces changements.

Outils de performance du site

PageSpeed Insights: Mesure les performances des pages pour les appareils mobiles et de bureau. Il vérifie si une page a appliqué des pratiques de performance communes et fournit un score, qui varie de 0 à 100 points.
Phare: Extension Handy Chrome pour les performances, l’accessibilité, les audits Progressive Web Apps. Peut également être exécuté à partir de la ligne de commande, ou comme un module Nœud.
Webpagetest.org: Tests de page très détaillés à partir de divers endroits, connexions et appareils, y compris des graphiques détaillés de cascade.

Outils structurés de test de données

L’outil de test de données structurés de Google et l’extension Chrome de l’outil de test de données structurés de Google
Validateur de balisage de Bing
Outil de test de données structurés Yandex
L’outil de test de résultats riche de Google

Outils de test mobiles

Sources de données Backlink

Outil de planification de site

Slickplan

Merci MOZ pour les idées utiles.

Click to rate this post!

[Total: 0 Average: 0]