SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Les opinions de l’auteur sont entièrement les siennes (à l’exception de l’événement improbable de l’hypnose) et peuvent ne pas toujours refléter les opinions de Moz.

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

Une migration de site est un terme largement utilisé par les professionnels du référencement pour décrire tout événement au cours duquel un site Web subit des changements substantiels dans des domaines pouvant affecter de manière significative la visibilité des moteurs de recherche – généralement des modifications de l’emplacement, de la plate-forme, de la structure, du contenu, de la conception ou de l’UX du site.

La documentation de Google sur les migrations sur site ne les couvre pas en profondeur et minimise le fait qu’elles entraînent si souvent une perte importante de trafic et de revenus, qui peut durer de quelques semaines à plusieurs mois, selon l’étendue des signaux de classement des moteurs de recherche. ont été affectées, ainsi que le temps nécessaire à l’entreprise affectée pour déployer un plan de redressement efficace.

Liens d’accès rapide

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


Exemples de migration de sites

La section suivante explique à quoi ressemblent les migrations de sites réussies et infructueuses et explique pourquoi il est 100% possible de sortir d’une migration de site sans subir de pertes importantes.

Démystifier le mythe de la « baisse de trafic attendue »

Quiconque a été impliqué dans une migration de site a probablement entendu la théorie répandue selon laquelle cela entraînera de facto une perte de trafic et de revenus. Même si cette affirmation contient une part de vérité pour certains cas très spécifiques (c’est-à-dire le passage d’un domaine établi à un tout nouveau), elle ne devrait pas être traitée comme un évangile. Il est tout à fait possible de migrer sans perdre de trafic ni de revenus ; vous pouvez même profiter d’une croissance significative juste après le lancement d’un site Web remanié. Cependant, 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 du site d’un grand détaillant britannique, où le site Web 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 organique. Il s’agit d’un exemple typique d’une mauvaise migration de site, probablement causée par une mauvaise planification ou mise en œuvre.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Exemple d’une mauvaise migration de site — la 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 passage de HTTP à HTTPS a entraîné une perte de visibilité permanente de 20 %.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Un autre exemple de mauvaise migration de site — aucun signe de reprise après 6 mois !

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

Exemples de migrations de sites réussies

À quoi ressemble une migration de site réussie ? 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 de site réussie présente au moins l’une des caractéristiques suivantes :

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

Le rapport de visibilité suivant est issu d’une migration de site HTTP vers HTTPS, qui s’est également accompagnée d’améliorations significatives des temps de chargement des pages du site.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Le rapport de visibilité suivant est issu d’une refonte complète du site, à 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, toutes aussi importantes.

Comme c’est souvent le cas pour les projets de migration sur site, la date de lancement a dû être repoussée plusieurs fois en raison des risques de lancement prématuré du nouveau site et avant que les obstacles techniques majeurs ne soient entièrement surmontés. Mais comme vous pouvez le voir sur le graphique de visibilité ci-dessous, l’attente en valait la peine. La visibilité organique non seulement n’a pas baissé (comme la plupart s’y attendraient normalement), mais en fait, elle a commencé à augmenter 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é les 80 %.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Exemple de 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 car le nouveau site Web a été repensé et construit à partir de zéro sur une nouvelle plate-forme avec une taxonomie de site améliorée qui comprenait de nouvelles pages de destination, une structure d’URL mise à jour, de nombreuses redirections pour préserver l’équité des liens, ainsi qu’un passage de HTTP vers HTTPS.

En général, introduire trop de changements en même temps peut être délicat car si quelque chose ne va pas, vous aurez du mal à comprendre ce qui est exactement en cause. Mais en même temps, laisser les changements majeurs à plus tard n’est pas idéal non plus car cela nécessitera plus de ressources. Si vous savez ce que vous faites, apporter plusieurs changements positifs à la fois peut être très rentable.

Avant d’entrer dans les détails de la façon dont vous pouvez transformer un projet de migration de site complexe en succès, il est important de passer en revue les principaux types de migration de site et d’expliquer les principales raisons pour lesquelles tant de migrations de sites échouent.


Types de migration de sites

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

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

La documentation de Google couvre principalement les migrations avec des changements d’emplacement de site, qui sont classées comme suit :

  • Déménagement du site avec Modifications d’URL
  • Déménagement du site sans pour autant Modifications d’URL

Migrations de déplacement de site

URL-structure2.png

Ceux-ci se produisent généralement lorsqu’un site passe à une URL différente en raison de l’un des éléments ci-dessous :

Changement de protocole

Un exemple classique est la migration de HTTP vers HTTPS.

Changement de sous-domaine ou de sous-dossier

Très courant dans le référencement international où une entreprise décide de déplacer un ou plusieurs ccTLD 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 uniformes.

Changement de nom de domaine

Cela se produit généralement lorsqu’une entreprise change de marque et doit passer d’un domaine à un autre.

Changement de domaine de premier niveau

Ceci est courant lorsqu’une entreprise décide de lancer des sites Web internationaux et doit passer d’un ccTLD (domaine de premier niveau de code de pays) à un gTLD (domaine de premier niveau générique) ou vice versa, par ex. passer de .co.uk à .com, ou 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 généralement les liens internes et la structure de l’URL du site.

Autres types de migrations

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

Replateforme

C’est le cas lorsqu’un site Web est déplacé d’une plate-forme/CMS à une autre, par ex. migrer de WordPress vers Magento ou simplement passer à la dernière version de la plate-forme. Le changement de plate-forme peut, dans certains cas, également entraîner des modifications de conception et d’URL en raison de limitations techniques qui surviennent souvent lors du changement de plate-forme. C’est pourquoi les migrations de re-plateforme aboutissent rarement à 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é de la recherche organique d’un site, selon l’échelle. Ces changements peuvent souvent affecter la taxonomie, la navigation et les liens internes du site.

Modifications de la configuration mobile

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

Changements structurels

Celles-ci sont souvent causées par des changements majeurs dans la taxonomie du site qui ont un impact sur la navigation sur le site, les liens internes et les parcours des utilisateurs.

Refontes du site

Celles-ci peuvent aller de changements de conception majeurs dans l’apparence et la convivialité à 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 hybrides qui peuvent être combinés de pratiquement toutes les manières possibles. Plus il y a de changements introduits en même temps, plus la complexité et les risques sont élevés. Même si faire trop de changements en même temps augmente les risques de problèmes, cela peut être plus rentable du point de vue des ressources si la migration est très bien planifiée et exécutée.


Pièges courants de migration de site

Même si chaque migration de site est différente, il existe quelques thèmes communs derrière les catastrophes de migration de site les plus courantes, le plus important étant le suivant :

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Mauvaise stratégie

Certaines migrations de sites sont vouées à l’échec bien avant le lancement du nouveau site. Une stratégie qui repose sur des objectifs peu clairs et irréalistes a beaucoup moins de chances de réussir.

L’établissement d’objectifs mesurables est essentiel pour mesurer l’impact de la migration post-lancement. Pour la plupart des migrations de sites, l’objectif principal doit être la conservation des niveaux actuels de trafic et de revenus du site. Dans certains cas, la barre pourrait être placée plus haut, mais en général, anticiper ou prévoir la croissance devrait être un objectif secondaire. Cela aidera à éviter de créer des attentes irréalistes.

Mauvaise planification

Présenter un plan de projet détaillé le plus tôt possible aidera à éviter les retards en cours de route. Prévoyez du temps et des ressources supplémentaires pour faire face à toute circonstance imprévue qui pourrait 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. Cartographiez toutes les dépendances et sensibilisez toutes les parties prenantes à celles-ci.

Évitez de planifier de lancer le site près de vos pics saisonniers, car si quelque chose ne va pas, vous n’aurez pas assez de temps pour rectifier les problèmes. Par exemple, les détaillants devraient éviter de lancer un site vers septembre/octobre pour éviter de mettre en danger la période chargée d’avant Noël. Dans ce cas, il serait beaucoup plus judicieux de lancer pendant les mois d’été les plus calmes.

Manque de ressources

Avant de vous engager dans un projet de migration de site, estimez le temps et les efforts nécessaires pour en faire un succès. Si votre budget est limité, demandez si cela vaut la peine de procéder à une migration susceptible de ne pas atteindre les objectifs fixés et d’entraîner une perte de revenus.

En règle générale, essayez d’inclure un tampon d’au moins 20 % de ressources supplémentaires par rapport à ce que vous pensez initialement que le projet nécessitera. Ce tampon supplémentaire vous permettra par la suite de résoudre rapidement les problèmes dès qu’ils surviennent, sans compromettre le succès. Si vos ressources sont trop limitées ou si vous commencez à prendre des raccourcis à ce stade précoce, la migration du site sera menacée.

Manque de consultation /UX

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

Pour éviter les risques, nommez des consultants et UX expérimentés afin qu’ils puissent discuter des conséquences potentielles de chaque changement avec les principales parties prenantes de l’entreprise qui comprennent les subtilités de l’entreprise mieux que quiconque. Le pour et le contre 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écessitent une grande planification et suffisamment de temps pour les tests. Chercher un soutien professionnel tardivement est très risqué car 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 bien 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 en production. Il va sans dire que vous ne devriez pas lancer un site Web s’il n’a pas été testé par des équipes expertes en et UX.

Le souci du détail est également très important. 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 (et donc les revenus) d’un site peut faire une grande différence.

Réponse lente à la correction de bogues

Il y aura toujours des bugs à corriger une fois le nouveau site en ligne. Cependant, certains bogues sont plus importants que d’autres et peuvent nécessiter une attention immédiate. Par exemple, lancer un nouveau site uniquement pour constater que les robots des moteurs de recherche ont du mal à explorer et à indexer le contenu du site nécessiterait une solution immédiate. Une réponse lente à des obstacles techniques majeurs peut parfois être catastrophique et prendre beaucoup de temps pour s’en remettre.

Sous-estimation de l’échelle

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

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


Processus de migration de site

Le processus de migration du site peut être divisé en six phases essentielles principales. Elles sont toutes d’égale importance et ignorer l’une des tâches ci-dessous pourrait entraver le succès de la migration à des degrés divers.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

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 clair sur les objectifs dès le début, car ils vous aideront à définir et à gérer les attentes. Déplacer un site de HTTP vers HTTPS est très différent de passer par une refonte complète du site, les deux devraient donc avoir des objectifs différents. Dans le premier cas, l’objectif doit être de conserver les niveaux de trafic du site, alors que dans le second, vous pouvez potentiellement viser la croissance.

Une migration de site est une excellente occasion de résoudre les problèmes hérités. Inclure autant d’entre eux que possible dans la portée du projet devrait être très rentable, car la résolution de ces problèmes après le lancement nécessitera beaucoup plus de ressources.

Cependant, dans tous les cas, identifiez les aspects les plus critiques pour la réussite du projet. Identifiez tous les risques qui pourraient avoir un impact négatif sur la visibilité du site et réfléchissez aux précautions à prendre. Idéalement, préparez quelques scénarios prévisionnels en fonction des différents risques et opportunités de croissance. Il va sans dire que les scénarios de prévision doivent être préparés par des consultants expérimentés en migration de site.

Inclure autant de parties prenantes que possible à ce stade précoce vous aidera à acquérir une compréhension plus approfondie des plus grands défis et opportunités entre les divisions. Demandez les commentaires de vos équipes de contenu, de référencement, d’expérience utilisateur et d’analyse et dressez une liste des plus gros problèmes et opportunités. Vous devez ensuite déterminer quel serait le retour sur investissement potentiel de chacun d’entre eux. Enfin, choisissez l’une des options disponibles en fonction de vos objectifs et des ressources disponibles, qui constituera 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 elles sont mises en œuvre. Ceux-ci doivent ensuite être communiqués et discutés avec toutes les parties prenantes, afin que vous fixiez des objectifs réalistes, convenez du projet, de la portée et définissiez les bonnes attentes dès le départ.

Préparer le plan de projet

La planification est tout aussi importante car les migrations de sites peuvent souvent être des projets très complexes pouvant facilement s’étendre sur plusieurs mois. Pendant la phase de planification, chaque tâche a besoin d’un propriétaire (c’est-à-dire consultant , consultant UX, éditeur de contenu, développeur Web) et d’une date de livraison prévue. Toutes les dépendances doivent être identifiées et incluses dans le plan du projet afin que tout le monde soit au courant de toutes les activités qui ne peuvent pas être réalisées en raison de la dépendance des autres. Par exemple, les redirections ne peuvent pas être testées à moins que le mappage de redirection n’ait été effectué et que les redirections n’aient été implémentées lors du transfert.

Le plan du projet doit être partagé avec toutes les personnes impliquées le plus tôt possible afin qu’il y ait suffisamment de temps pour les discussions et les clarifications. Chaque activité doit être décrite de manière très détaillée, 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 afin d’organiser et de réaliser les activités requises selon le calendrier.

Une partie cruciale du plan de projet consiste à déterminer correctement la date de lancement prévue. Idéalement, le nouveau site devrait être lancé pendant une période 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 comme les migrations de sites ne se déroulent jamais entièrement comme prévu, un certain degré de flexibilité sera nécessaire.


Phase 2 : Préparation pré-lancement

Celles-ci incluent 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 de référencement du nouveau site devraient déjà avoir été saisies. Vous devez assurer la liaison avec les concepteurs et les architectes de l’information, fournir des commentaires sur les prototypes et les wireframes bien avant que le nouveau site ne soit disponible sur un environnement de transfert.

Examen des wireframes

Passez en revue les prototypes ou les wireframes du nouveau site avant le début du développement. L’examen des principaux modèles du nouveau site peut aider à identifier les problèmes de référencement et d’expérience utilisateur à un stade précoce. Par exemple, vous constaterez peut-être que de grandes portions de contenu ont été supprimées des pages de catégorie, qui devraient être signalées instantanément. Ou vous découvrirez peut-être que certaines pages à fort trafic n’apparaissent plus dans la navigation principale. Tout changement radical dans la conception ou la copie des pages doit être soigneusement examiné pour détecter d’éventuels problèmes de référencement.

Préparation des spécifications techniques

Une fois les prototypes et wireframes passés en revue, préparez une spécification technique détaillée. L’objectif de ce document essentiel est de capturer toutes les exigences essentielles en matière de référencement dont les développeurs doivent être conscients avant de déterminer la portée du projet en termes de travail et de coûts. C’est à cette étape que les budgets sont signés ; si les exigences de référencement ne sont pas incluses, il peut être impossible de les inclure plus tard.

La spécification technique de référencement doit être très détaillée, mais rédigée de manière à ce que les développeurs puissent 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 d’URL
  • Métadonnées (y compris les valeurs par défaut générées dynamiquement)
  • Données structurées
  • Directives canoniques et méta-robots
  • Copie et en-têtes
  • Navigation principale et secondaire
  • Lien interne (sous n’importe quelle forme)
  • Pagination
  • Plan(s) de site XML
  • Plan du site HTML
  • Hreflang (s’il existe des sites internationaux)
  • Configuration mobile (y compris l’application, le site AMP ou PWA)
  • Redirections
  • Page 404 personnalisée
  • JavaScript, CSS et fichiers image
  • Temps de chargement des pages (pour ordinateur et mobile)

La spécification doit également inclure des domaines de la fonctionnalité CMS qui permettent aux utilisateurs de :

  • Spécifiez des URL personnalisées et remplacez celles par défaut
  • Mettre à jour les titres des pages
  • Mettre à jour les méta descriptions
  • Mettre à jour les en-têtes h1 à h6
  • Ajouter ou modifier la balise canonique par défaut
  • Définissez les attributs méta robots sur index/noindex/follow/nofollow
  • Ajouter ou modifier le texte alternatif de chaque image
  • Inclure les champs Open Graph pour la description, l’URL, l’image, le type, le nom du site
  • Inclure les champs Twitter Open Graph pour la carte, l’URL, le titre, la description, l’image
  • Importation groupée ou modification des redirections
  • Mettre à jour le fichier robots.txt

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

Identification des pages prioritaires

L’un des plus grands défis des 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 vous assurer que vous vous concentrez sur les pages qui comptent vraiment. Ce sont les pages qui ont généré du trafic vers l’ancien site, les pages qui ont accumulé des liens, les pages qui se convertissent bien, etc.

Pour ce faire, vous devez :

  1. Explorer l’ancien site
  2. Identifier toutes les pages indexables
  3. Identifier les pages les plus performantes

Comment explorer l’ancien site

Explorez l’ancien site Web afin d’avoir une copie de toutes les URL, titres de page, métadonnées, en-têtes, redirections, liens rompus, etc. Quelle que soit l’application de robot d’exploration choisie (voir l’annexe), assurez-vous que l’exploration n’est pas trop restrictive . Portez une attention particulière aux paramètres du robot d’exploration avant d’explorer l’ancien site et demandez-vous si vous devez :

  • Ignorez robots.txt (au cas où des pièces vitales seraient accidentellement bloquées)
  • Suivez les liens internes « nofollow » (afin que le robot d’exploration atteigne plus de pages)
  • Explorer tous les sous-domaines (selon la portée)
  • Explorer en dehors du dossier de démarrage (selon la portée)
  • Changer l’agent utilisateur en Googlebot (bureau)
  • Changer l’agent utilisateur en Googlebot (smartphone)

Conseil de pro : conservez une copie des données d’exploration de l’ancien site (dans un fichier ou sur le cloud) pendant plusieurs mois après la fin de la migration, juste au cas où vous auriez besoin des données de l’ancien site une fois le nouveau site mis en ligne .

Comment identifier les pages indexables

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

  • Renvoie une réponse du serveur 200
  • Soit ne pas avoir de balise canonique, soit avoir une URL canonique auto-référente
  • Ne pas avoir de 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 méritent d’être optimisées (si elles existent sur le nouveau site) ou redirigées (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 que leur optimisation ou leur redirection est impossible en raison de contraintes de temps, de ressources ou techniques.

Si tel est le cas, vous devez identifier les pages les plus performantes de l’ancien site. Cela aidera à hiérarchiser les pages sur lesquelles se concentrer au cours des étapes ultérieures.

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

  • URL héritée (n’incluez que celles indexables à partir des données de craw)
  • Visites organiques au cours des 12 derniers mois (Analytics)
  • Revenus, conversions et taux de conversion au cours des 12 derniers mois (Analytics)
  • Pages vues au cours des 12 derniers mois (Analytics)
  • Nombre de clics au cours des 90 derniers jours (Search Console)
  • Top pages liées (Majestic /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, convertissent bien, contribuent aux revenus, ont un bon nombre de domaines référents qui y sont liés, etc. Ce sont les pages sur lesquels vous devez vous concentrer pour une migration de site réussie.

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 les demandent n’arrivent pas sur les pages 404 et que l’équité des liens qu’ils avaient auparavant reste sur le site. Si l’une de ces pages cesse d’exister et n’est pas correctement redirigée, le classement et le trafic de votre site seront affectés négativement.

Analyse comparative

Une fois le lancement du nouveau site Web proche, vous devez évaluer les performances de l’ancien site. 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 domaines sous-performants sur le nouveau site et pour y remédier rapidement.

Suivi du classement des mots clés

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

Passez du temps à déterminer quels mots-clés sont les plus représentatifs de la visibilité de la recherche organique du site et suivez-les sur ordinateur et mobile. Étant donné que la surveillance de milliers de combinaisons de mots clés de tête, de milieu et de longue traîne est généralement irréaliste, le strict minimum que vous devez surveiller sont les mots clés qui génèrent du trafic vers le site (mots clés classés sur la première page) et ont un volume de recherche décent (tête / milieu -mise au point de la queue)

Si vous obtenez du trafic à partir de mots-clés de marque et sans marque, vous devez également décider sur quel type de mots-clés vous concentrer davantage à partir d’un PDV de suivi. En général, les mots-clés non liés à la marque 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 et mobile. Cela facilitera grandement le diagnostic des problèmes après le lancement en cas de problèmes de performances sur un type d’appareil. Si vous recevez un volume élevé de trafic en provenance de plusieurs pays, envisagez également les mots-clés de suivi des classements sur d’autres marchés, car 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 met de temps à se charger, plus le taux de rebond est élevé. À moins que les temps de chargement des pages de l’ancien site et les scores de performance du site n’aient été enregistrés, il sera très difficile d’attribuer une perte de trafic ou de revenus aux problèmes liés aux performances du site une fois que le nouveau site sera en ligne.

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 récapitulatifs comme ceux ci-dessous pour comparer certaines des mesures de performance les plus importantes, qui seront utiles pour les comparaisons une fois le nouveau site en ligne.

MOBILE

La vitesse

PCF

DCL

Optimisation

Note d’optimisation

Page d’accueil

Rapide

0.7s

1.4s

Bon

81/100

Page de catégorie

Lent

1.8s

5.1s

Moyen

78/100

Page de sous-catégorie

Moyenne

0.9s

2.4s

Moyen

69/100

Fiche produit

Lent

1.9s

5.5s

Bon

83/100

BUREAU

La vitesse

PCF

DCL

Optimisation

Note d’optimisation

Page d’accueil

Bon

0.7s

1.4s

Moyenne

81/100

Page de catégorie

Rapide

0.6s

1.2s

Moyen

78/100

Page de sous-catégorie

Rapide

0.6s

1.3s

Moyen

78/100

Fiche produit

Bon

0.8s

1.3s

Bon

83/100

Anciennes données d’exploration de site

Quelques jours avant que le nouveau site ne remplace l’ancien, exécutez une analyse finale de l’ancien site. Cela pourrait s’avérer inestimable par la suite, en cas de problème d’optimisation sur le nouveau site. Une analyse finale vous permettra d’enregistrer des informations vitales sur les titres de page de l’ancien site, les méta descriptions, les en-têtes h1 à h6, l’état du serveur, les balises canoniques, les pages noindex/nofollow, les liens entrants/sortants, le niveau, etc. vous évitera bien des problèmes si, par exemple, le nouveau site n’est pas bien optimisé ou souffre de problèmes de configuration technique. Essayez également d’enregistrer une copie des plans de site robots.txt et XML de l’ancien site au cas où vous en auriez besoin plus tard.

Données de la Search Console

Envisagez également d’exporter autant que possible les données de la Search Console de l’ancien site. Ceux-ci ne sont disponibles que pendant 90 jours, et il est probable qu’une fois le nouveau site mis en ligne, les données de la Search Console de l’ancien site disparaîtront 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 d’exploration
  • Ressources bloquées
  • Problèmes d’utilisation mobile
  • Paramètres d’URL
  • Erreurs de données structurées
  • Liens vers votre site
  • Liens internes
  • État de l’index

Préparation des redirections

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 Web seront tout simplement perdus.

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

Les redirections sont extrêmement importantes car elles aident les moteurs de recherche et les utilisateurs à trouver des pages qui n’existent peut-être plus, ont été renommées ou déplacées vers un autre emplacement. D’un point de vue , les redirections aident les moteurs de recherche à découvrir et indexer plus rapidement les nouvelles URL d’un site, mais aussi à comprendre comment les pages de l’ancien site sont associées aux pages du nouveau site. Cette association permettra aux signaux de classement de passer des anciennes pages aux nouvelles, 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 mises en œuvre ?

Lorsque les redirections sont mal mises en œuvre, les conséquences peuvent être catastrophiques. Les utilisateurs atterriront soit sur des pages introuvables (404), soit sur des 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 seront incapables d’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 entraînera des baisses de classement et une perte de visibilité de la recherche organique. De plus, il faudra plus de temps aux moteurs de recherche pour découvrir et indexer les pages du nouveau site.

301, 302, redirections JavaScript ou méta-actualisation ?

Lorsque les URL entre l’ancienne et la nouvelle version du site sont différentes, utilisez les redirections 301 (permanentes). Ceux-ci indiqueront aux moteurs de recherche d’indexer les nouvelles URL et de transmettre les signaux de classement des anciennes URL aux nouvelles. Par conséquent, vous devez utiliser les redirections 301 si votre site se déplace vers/depuis 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 affirmations de Google selon lesquelles les redirections 302 passent le PageRank, l’indexation des nouvelles URL serait plus lente et les signaux de classement pourraient prendre beaucoup plus de temps à être transmis de l’ancienne à la nouvelle page.

Les redirections 302 (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 les redirections 302, les moteurs de recherche seront initialement réticents à indexer le contenu de l’URL de destination de la redirection et à lui transmettre des signaux de classement. However, if the temporary redirects remain for a long period of time without being removed or updated, they could end up behaving similarly to permanent (301) redirects. Use 302 redirects when a redirect is likely to require updating or removal in the near future, as well as for any country-, language-, or device-specific redirects.

Meta refresh and JavaScript redirects should be avoided. Even though Google is getting better and better at crawling JavaScript, there are no guarantees these will get discovered or pass ranking signals to the new pages.

If you’d like to find out more about how Google deals with the different types of redirects, please refer to John Mueller’s post.

Redirect mapping process

If you are lucky enough to work on a migration that doesn’t involve URL changes, you could skip this section. Otherwise, read on to find out why any legacy pages that won’t be available on the same URL after the migration should be redirected.

The redirect mapping file is a spreadsheet that includes the following two columns:

  • Legacy site URL –> a page’s URL on the old site.
  • New site URL –> a page’s URL on the new site.

When mapping (redirecting) a page from the old to the new site, always try mapping it to the most relevant corresponding page. In cases where a relevant page doesn’t exist, avoid redirecting the page to the homepage. First and foremost, redirecting users to irrelevant pages results in a very poor user experience. Google has stated that redirecting pages “en masse” to irrelevant pages will be treated as soft 404s and because of this won’t be passing any value. If you can’t find an equivalent page on the new site, try mapping it to its parent category page.

Once the mapping is complete, the file will need to be sent to the development team to create the redirects, so that these can be tested before launching the new site. The implementation of redirects is another part in the site migration cycle where things can often go wrong.

Increasing efficiencies during the redirect mapping process

Redirect mapping requires great attention to detail and needs to be carried out by experienced s. The URL mapping on small sites could in theory be done by manually mapping each URL of the legacy site to a URL on the new site. But on large sites that consist of thousands or even hundreds of thousands of pages, manually mapping every single URL is practically impossible and automation needs to be introduced. Relying on certain common attributes between the legacy and new site can be a massive time-saver. Such attributes may include the page titles, H1 headings, or other unique page identifiers such as product codes, SKUs etc. Make sure the attributes you rely on for the redirect mapping are unique and not repeated across several pages; otherwise, you will end up with incorrect mapping.

Pro tip: Make sure the URL structure of the new site is 100% finalized on staging before you start working on the redirect mapping. There’s nothing riskier than mapping URLs that will be updated before the new site goes live. When URLs are updated after the redirect mapping is completed, you may have to deal with undesired situations upon launch, such as broken redirects, redirect chains, and redirect loops. A content-freeze should be placed on the old site well in advance of the migration date, so there is a cut-off point for new content being published on the old site. This will make sure that no pages will be missed from the redirect mapping and guarantee that all pages on the old site get redirected.

Don’t forget the legacy redirects!

You should get hold of the old site’s existing redirects to ensure they’re considered when preparing the redirect mapping for the new site. Unless you do this, it’s likely that the site’s current redirect file will get overwritten by the new one on the launch date. If this happens, all legacy redirects that were previously in place will cease to exist and the site may lose a decent amount of link equity, the extent of which will largely depend on the site’s volume of legacy redirects. For instance, a site that has undergone a few migrations in the past should have a good number of legacy redirects in place that you don’t want getting lost.

Ideally, preserve as many of the legacy redirects as possible, making sure these won’t cause any issues when combined with the new site’s redirects. It’s strongly recommended to eliminate any potential redirect chains at this early stage, which can easily be done by checking whether the same URL appears both as a “Legacy URL” and “New site URL” in the redirect mapping spreadsheet. If this is the case, you will need to update the “New site URL” accordingly.

Example:

URL A redirects to URL B (legacy redirect)

URL B redirects to URL C (new redirect)

Which results in the following redirect chain:

URL A –> URL B –> URL C

To eliminate this, amend the existing legacy redirect and create a new one so that:

URL A redirects to URL C (amended legacy redirect)

URL B redirects to URL C (new redirect)

Pro tip: Check your redirect mapping spreadsheet for redirect loops. These occur when the “Legacy URL” is identical to the “new site URL.” Redirect loops need to be removed because they result in infinitely loading pages that are inaccessible to users and search engines. Redirect loops must be eliminated because they are instant traffic, conversion, and ranking killers!

Implement blanket redirect rules to avoid duplicate content

It’s strongly recommended to try working out redirect rules that cover as many URL requests as possible. Implementing redirect rules on a web server is much more efficient than relying on numerous one-to-one redirects. If your redirect mapping document consists of a very large number of redirects that need to be implemented as one-to-one redirect rules, site performance could be negatively affected. In any case, double check with the development team the maximum number of redirects the web server can handle without issues.

In any case, there are some standard redirect rules that should be in place to avoid generating duplicate content issues:

Even if some of these standard redirect rules exist on the legacy website, do not assume they’ll necessarily exist on the new site unless they’re explicitly requested.

Avoid internal redirects

Try updating the site’s internal links so they don’t trigger internal redirects. Even though search engines can follow internal redirects, these are not recommended because they add additional latency to page loading times and could also have a negative impact on search engine crawl time.

Don’t forget your image files

If the site’s images have moved to a new location, Google recommends redirecting the old image URLs to the new image URLs to help Google discover and index the new images quicker. If it’s not easy to redirect all images, aim to redirect at least those image URLs that have accrued backlinks.


Phase 3: Pre-launch testing

The earlier you can start testing, the better. Certain things need to be fully implemented to be tested, but others don’t. For example, user journey issues could be identified from as early as the prototypes or wireframes design. Content-related issues between the old and new site or content inconsistencies (e.g. between the desktop and mobile site) could also be identified at an early stage. But the more technical components should only be tested once fully implemented — things like redirects, canonical tags, or XML sitemaps. The earlier issues get identified, the more likely it is that they’ll be addressed before launching the new site. Identifying certain types of issues at a later stage isn’t cost effective, would require more resources, and cause significant delays. Poor testing and not allowing the time required to thoroughly test all building blocks that can affect and UX performance can have disastrous consequences soon after the new site has gone live.

Making sure search engines cannot access the staging/test site

Before making the new site available on a staging/testing environment, take some precautions that search engines do not index it. There are a few different ways to do this, each with different pros and cons.

Site available to specific IPs (most recommended)

Making the test site available only to specific (whitelisted) IP addresses is a very effective way to prevent search engines from crawling it. Anyone trying to access the test site’s URL won’t be able to see any content unless their IP has been whitelisted. The main advantage is that whitelisted users could easily access and crawl the site without any issues. The only downside is that third-party web-based tools (such as Google’s tools) cannot be used because of the IP restrictions.

Password protection

Password protecting the staging/test site is another way to keep search engine crawlers away, but this solution has two main downsides. Depending on the implementation, it may not be possible to crawl and test a password-protected website if the crawler application doesn’t make it past the login screen. The other downside: password-protected websites that use forms for authentication can be crawled using third-party applications, but there is a risk of causing severe and unexpected issues. This is because the crawler clicks on every link on a page (when you’re logged in) and could easily end up clicking on links that create or remove pages, install/uninstall plugins, etc.

Robots.txt blocking

Adding the following lines of code to the test site’s robots.txt file will prevent search engines from crawling the test site’s pages.

User-agent: *
Disallow: /

One downside of this method is that even though the content that appears on the test server won’t get indexed, the disallowed URLs may appear on Google’s search results. Another downside is that if the above robots.txt file moves into the live site, it will cause severe de-indexing issues. This is something I’ve encountered numerous times and for this reason I wouldn’t recommend using this method to block search engines.

User journey review

If the site has been redesigned or restructured, chances are that the user journeys will be affected to some extent. Reviewing the user journeys as early as possible and well before the new site launches is difficult due to the lack of user data. However, an experienced UX professional will be able to flag any concerns that could have a negative impact on the site’s conversion rate. Because A/B testing at this stage is hardly ever possible, it might be worth carrying out some user testing and try to get some feedback from real users. Unfortunately, user experience issues can be some of the harder ones to address because they may require sitewide changes that take a lot of time and effort.

On full site overhauls, not all UX decisions can always be backed up by data and many decisions will have to be based on best practice, past experience, and “gut feeling,” hence getting UX/CRO experts involved as early as possible could pay dividends later.

Site architecture review

A site migration is often a great opportunity to improve the site architecture. In other words, you have a great chance to reorganize your keyword targeted content and maximize its search traffic potential. Carrying out extensive keyword research will help identify the best possible category and subcategory pages so that users and search engines can get to any page on the site within a few clicks — the fewer the better, so you don’t end up with a very deep taxonomy.

Identifying new keywords with decent traffic potential and mapping them into new landing pages can make a big difference to the site’s organic traffic levels. On the other hand, enhancing the site architecture needs to be done thoughtfully. Itt could cause problems if, say, important pages move deeper into the new site architecture or there are too many similar pages optimized for the same keywords. Some of the most successful site migrations are the ones that allocate significant resources to enhance the site architecture.

Make sure that the site’s page titles, meta descriptions, headings, and copy have been transferred from the old to the new site without issues. If you’ve created any new pages, make sure these are optimized and don’t target keywords that have already been targeted by other pages. If you’re re-platforming, be aware that the new platform may have different default values when new pages are being created. Launching the new site without properly optimized page titles or any kind of missing copy will have an immediate negative impact on your site’s rankings and traffic. Do not forget to review whether any user-generated content (i.e. user reviews, comments) has also been uploaded.

Internal linking review

Internal links are the backbone of a website. No matter how well optimized and structured the site’s copy is, it won’t be sufficient to succeed unless it’s supported by a flawless internal linking scheme. Internal links must be reviewed throughout the entire site, including links found in:

  • Body content links
  • Pagination links
  • Horizontal links (related articles, similar products, etc)
  • Vertical links (e.g. breadcrumb navigation)
  • Cross-site links (e.g. links across international sites)

Technical checks

A series of technical checks must be carried out to make sure the new site’s technical setup is sound and to avoid coming across major technical glitches after the new site has gone live.

Robots.txt file review

Prepare the new site’s robots.txt file on the staging environment. This way you can test it for errors or omissions and avoid experiencing search engine crawl issues when the new site goes live. A classic mistake in site migrations is when the robots.txt file prevents search engine access using the following directive:

Disallow: /

If this gets accidentally carried over into the live site (and it often does), it will prevent search engines from crawling the site. And when search engines cannot crawl an indexed page, the keywords associated with the page will get demoted in the search results and eventually the page will get de-indexed.

But if the robots.txt file on staging is populated with the new site’s robots.txt directives, this mishap could be avoided.

When preparing the new site’s robots.txt file, make sure that:

  • It doesn’t block search engine access to pages that are intended to get indexed.
  • It doesn’t block any JavaScript or CSS resources search engines require to render page content.
  • The legacy site’s robots.txt file content has been reviewed and carried over if necessary.
  • It references the new XML sitemaps(s) rather than any legacy ones that no longer exist.

Canonical tags review

Review the site’s canonical tags. Look for pages that either do not have a canonical tag or have a canonical tag that is pointing to another URL and question whether this is intended. Don’t forget to crawl the canonical tags to find out whether they return a 200 server response. If they don’t you will need to update them to eliminate any 3xx, 4xx, or 5xx server responses. You should also look for pages that have a canonical tag pointing to another URL combined with a noindex directive, because these two are conflicting signals and you;’ll need to eliminate one of them.

Meta robots review

Once you’ve crawled the staging site, look for pages with the meta robots properties set to “noindex” or “nofollow.” If this is the case, review each one of them to make sure this is intentional and remove the “noindex” or “nofollow” directive if it isn’t.

XML sitemaps review

Prepare two different types of sitemaps: one that contains all the new site’s indexable pages, and another that includes all the old site’s indexable pages. The former will help make Google aware of the new site’s indexable URLs. The latter will help Google become aware of the redirects that are in place and the fact that some of the indexed URLs have moved to new locations, so that it can discover them and update search results quicker.

You should check each XML sitemap to make sure that:

  • It validates without issues
  • It is encoded as UTF-8
  • It does not contain more than 50,000 rows
  • Its size does not exceed 50MBs when uncompressed

If there are more than 50K rows or the file size exceeds 50MB, you must break the sitemap down into smaller ones. This prevents the server from becoming overloaded if Google requests the sitemap too frequently.

In addition, you must crawl each XML sitemap to make sure it only includes indexable URLs. Any non-indexable URLs should be excluded from the XML sitemaps, such as:

  • 3xx, 4xx, and 5xx pages (e.g. redirected, not found pages, bad requests, etc)
  • Soft 404s. These are pages with no content that return a 200 server response, instead of a 404.
  • Canonicalized pages (apart from self-referring canonical URLs)
  • Pages with a meta robots noindex directive


(…)

(…)

  • Pages with a noindex X-Robots-Tag in the HTTP header
HTTP/1.1 200 OK
Date: Tue, 10 Nov 2017 17:12:43 GMT
(…)
X-Robots-Tag: noindex
(…)
  • Pages blocked from the robots.txt file

Building clean XML sitemaps can help monitor the true indexing levels of the new site once it goes live. If you don’t, it will be very difficult to spot any indexing issues.

Pro tip: Download and open each XML sitemap in Excel to get a detailed overview of any additional attributes, such as hreflang or image attributes.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

HTML sitemap review

Depending on the size and type of site that is being migrated, having an HTML sitemap can in certain cases be beneficial. An HTML sitemap that consists of URLs that aren’t linked from the site’s main navigation can significantly boost page discovery and indexing. However, avoid generating an HTML sitemap that includes too many URLs. If you do need to include thousands of URLs, consider building a segmented HTML sitemap.

The number of nested sitemaps as well as the maximum number of URLs you should include in each sitemap depends on the site’s authority. The more authoritative a website, the higher the number of nested sitemaps and URLs it could get away with.

For example, the NYTimes.com HTML sitemap consists of three levels, where each one includes over 1,000 URLs per sitemap. These nested HTML sitemaps aid search engine crawlers in discovering articles published since 1851 that otherwise would be difficult to discover and index, as not all of them would have been internally linked.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

The NYTimes HTML sitemap (level 1)

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

The NYTimes HTML sitemap (level 2)

Structured data review

Errors in the structured data markup need to be identified early so there’s time to fix them before the new site goes live. Ideally, you should test every single page template (rather than every single page) using Google’s Structured Data Testing tool.

Be sure to check the markup on both the desktop and mobile pages, especially if the mobile website isn’t responsive.

Structured Data Testing Tool.png

The tool will only report any existing errors but not omissions. For example, if your product page template does not include the Product structured data schema, the tool won’t report any errors. So, in addition to checking for errors you should also make sure that each page template includes the appropriate structured data markup for its content type.

Please refer to Google’s documentation for the most up to date details on the structured data implementation and supported content types.

JavaScript crawling review

You must test every single page template of the new site to make sure Google will be able to crawl content that requires JavaScript parsing. If you’re able to use Google’s Fetch and Render tool on your staging site, you should definitely do so. Otherwise, carry out some manual tests, following Justin Brigg’s advice.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

As Bartosz Góralewicz’s tests proved, even if Google is able to crawl and index JavaScript-generated content, it does not mean that it is able to crawl JavaScript content across all major JavaScript frameworks. The following table summarizes Bartosz’s findings, showing that some JavaScript frameworks are not -friendly, with AngularJS currently being the most problematic of all.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Bartosz also found that other search engines (such as Bing, Yandex, and Baidu) really struggle with indexing JavaScript-generated content, which is important to know if your site’s traffic relies on any of these search engines.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Hopefully, this is something that will improve over time, but with the increasing popularity of JavaScript frameworks in web development, this must be high up on your checklist.

Finally, you should check whether any external resources are being blocked. Unfortunately, this isn’t something you can control 100% because many resources (such as JavaScript and CSS files) are hosted by third-party websites which may be blocking them via their own robots.txt files!

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Again, the Fetch and Render tool can help diagnose this type of issue that, if left unresolved, could have a significant negative impact.

Mobile site review

Assets blocking review

First, make sure that the robots.txt file isn’t accidentally blocking any JavaScript, CSS, or image files that are essential for the mobile site’s content to render. This could have a negative impact on how search engines render and index the mobile site’s page content, which in turn could negatively affect the mobile site’s search visibility and performance.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Mobile-first index review

In order to avoid any issues associated with Google’s mobile-first index, thoroughly review the mobile website and make there aren’t any inconsistencies between the desktop and mobile sites in the following areas:

  • Page titles
  • Meta descriptions
  • Headings
  • Copy
  • Canonical tags
  • Meta robots attributes (i.e. noindex, nofollow)
  • Internal links
  • Structured data

A responsive website should serve the same content, links, and markup across devices, and the above attributes should be identical across the desktop and mobile websites.

In addition to the above, you must carry out a few further technical checks depending on the mobile site’s set up.

Responsive site review

A responsive website must serve all devices the same HTML code, which is adjusted (via the use of CSS) depending on the screen size.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Googlebot is able to automatically detect this mobile setup as long as it’s allowed to crawl the page and its assets. It’s therefore extremely important to make sure that Googlebot can access all essential assets, such as images, JavaScript, and CSS files.

To signal browsers that a page is responsive, a meta= »viewport » tag should be in place within the

of each HTML page.

If the meta viewport tag is missing, font sizes may appear in an inconsistent manner, which may cause Google to treat the page as not mobile-friendly.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Separate mobile URLs review

If the mobile website uses separate URLs from desktop, make sure that:

  1. Each desktop page has a tag pointing to the corresponding mobile URL.
  2. Each mobile page has a rel= »canonical » tag pointing to the corresponding desktop URL.
  3. When desktop URLs are requested on mobile devices, they’re redirected to the respective mobile URL.
  4. Redirects work across all mobile devices, including Android, iPhone, and Windows phones.
  5. There aren’t any irrelevant cross-links between the desktop and mobile pages. This means that internal links on found on a desktop page should only link to desktop pages and those found on a mobile page should only link to other mobile pages.
  6. The mobile URLs return a 200 server response.
SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Dynamic serving review

Dynamic serving websites serve different code to each device, but on the same URL.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

On dynamic serving websites, review whether the vary HTTP header has been correctly set up. This is necessary because dynamic serving websites alter the HTML for mobile user agents and the vary HTTP header helps Googlebot discover the mobile content.

Mobile-friendliness review

Regardless of the mobile site set-up (responsive, separate URLs or dynamic serving), review the pages using a mobile user-agent and make sure that:

  1. The viewport has been set correctly. Using a fixed width viewport across devices will cause mobile usability issues.
  2. The font size isn’t too small.
  3. Touch elements (i.e. buttons, links) aren’t too close.
  4. There aren’t any intrusive interstitials, such as Ads, mailing list sign-up forms, App Download pop-ups etc. To avoid any issues, you should use either use a small HTML or image banner.
  5. Mobile pages aren’t too slow to load (see next section).

Google’s mobile-friendly test tool can help diagnose most of the above issues:

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Google’s mobile-friendly test tool in action

AMP site review

If there is an AMP website and a desktop version of the site is available, make sure that:

  • Each non-AMP page (i.e. desktop, mobile) has a tag pointing to the corresponding AMP URL.
  • Each AMP page has a rel= »canonical » tag pointing to the corresponding desktop page.
  • Any AMP page that does not have a corresponding desktop URL has a self-referring canonical tag.

You should also make sure that the AMPs are valid. This can be tested using Google’s AMP Test Tool.

Mixed content errors

With Google pushing hard for sites to be fully secure and Chrome becoming the first browser to flag HTTP pages as not secure, aim to launch the new site on HTTPS, making sure all resources such as images, CSS and JavaScript files are requested over secure HTTPS connections.This is essential in order to avoid mixed content issues.

Mixed content occurs when a page that’s loaded over a secure HTTPS connection requests assets over insecure HTTP connections. Most browsers either block dangerous HTTP requests or just display warnings that hinder the user experience.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Mixed content errors in Chrome’s JavaScript Console

There are many ways to identify mixed content errors, including the use of crawler applications, Google’s Lighthouse, etc.

Image assets review

Google crawls images less frequently than HTML pages. If migrating a site’s images from one location to another (e.g. from your domain to a CDN), there are ways to aid Google in discovering the migrated images quicker. Building an image XML sitemap will help, but you also need to make sure that Googlebot can reach the site’s images when crawling the site. The tricky part with image indexing is that both the web page where an image appears on as well as the image file itself have to get indexed.

Site performance review

Last but not least, measure the old site’s page loading times and see how these compare with the new site’s when this becomes available on staging. At this stage, focus on the network-independent aspects of performance such as the use of external resources (images, JavaScript, and CSS), the HTML code, and the web server’s configuration. More information about how to do this is available further down.

Analytics tracking review

Make sure that analytics tracking is properly set up. This review should ideally be carried out by specialist analytics consultants who will look beyond the implementation of the tracking code. Make sure that Goals and Events are properly set up, e-commerce tracking is implemented, enhanced e-commerce tracking is enabled, etc. There’s nothing more frustrating than having no analytics data after your new site is launched.

Redirects testing

Testing the redirects before the new site goes live is critical and can save you a lot of trouble later. There are many ways to check the redirects on a staging/test server, but the bottom line is that you should not launch the new website without having tested the redirects.

Once the redirects become available on the staging/testing environment, crawl the entire list of redirects and check for the following issues:

  • Redirect loops (a URL that infinitely redirects to itself)
  • Redirects with a 4xx or 5xx server response.
  • Redirect chains (a URL that redirects to another URL, which in turn redirects to another URL, etc).
  • Canonical URLs that return a 4xx or 5xx server response.
  • Canonical loops (page A has a canonical pointing to page B, which has a canonical pointing to page A).
  • Canonical chains (a canonical that points to another page that has a canonical pointing to another page, etc).
  • Protocol/host inconsistencies e.g. URLs are redirected to both HTTP and HTTPS URLs or www and non-www URLs.
  • Leading/trailing whitespace characters. Use trim() in Excel to eliminate them.
  • Invalid characters in URLs.

Pro tip: Make sure one of the old site’s URLs redirects to the correct URL on the new site. At this stage, because the new site doesn’t exist yet, you can only test whether the redirect destination URL is the intended one, but it’s definitely worth it. The fact that a URL redirects does not mean it redirects to the right page.


Phase 4: Launch day activities

When the site is down…

While the new site is replacing the old one, chances are that the live site is going to be temporarily down. The downtime should be kept to a minimum, but while this happens the web server should respond to any URL request with a 503 (service unavailable) server response. This will tell search engine crawlers that the site is temporarily down for maintenance so they come back to crawl the site later.

If the site is down for too long without serving a 503 server response and search engines crawl the website, organic search visibility will be negatively affected and recovery won’t be instant once the site is back up. In addition, while the website is temporarily down it should also serve an informative holding page notifying users that the website is temporarily down for maintenance.

Technical spot checks

As soon as the new site has gone live, take a quick look at:

  1. The robots.txt file to make sure search engines are not blocked from crawling
  2. Top pages redirects (e.g. do requests for the old site’s top pages redirect correctly?)
  3. Top pages canonical tags
  4. Top pages server responses
  5. Noindex/nofollow directives, in case they are unintentional

The spot checks need to be carried out across both the mobile and desktop sites, unless the site is fully responsive.

Search Console actions

The following activities should take place as soon as the new website has gone live:

  1. Set the Preferred location of the domain (www or non-www)
  2. Set the International targeting (if applicable)
  3. Configure the URL parameters to tackle early any potential duplicate content issues.
  4. Upload the Disavow file (if applicable)
  5. Use the Change of Address tool (if switching domains)

Pro tip: Use the “Fetch as Google” feature for each different type of page (e.g. the homepage, a category, a subcategory, a product page) to make sure Googlebot can render the pages without any issues. Review any reported blocked resources and do not forget to use Fetch and Render for desktop and mobile, especially if the mobile website isn’t responsive.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Blocked resources prevent Googlebot from rendering the content of the page


Phase 5: Post-launch review

Once the new site has gone live, a new round of in-depth checks should be carried out. These are largely the same ones as those mentioned in the “Phase 3: Pre-launch Testing” section.

However, the main difference during this phase is that you now have access to a lot more data and tools. Don’t underestimate the amount of effort you’ll need to put in during this phase, because any issues you encounter now directly impacts the site’s performance in the SERPs. On the other hand, the sooner an issue gets identified, the quicker it will get resolved.

In addition to repeating the same testing tasks that were outlined in the Phase 3 section, in certain areas things can be tested more thoroughly, accurately, and in greater detail. You can now take full advantage of the Search Console features.

Check crawl stats and server logs

Keep an eye on the crawl stats available in the Search Console, to make sure Google is crawling the new site’s pages. In general, when Googlebot comes across new pages it tends to accelerate the average number of pages it crawls per day. But if you can’t spot a spike around the time of the launch date, something may be negatively affecting Googlebot’s ability to crawl the site.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Crawl stats on Google’s Search Console

Reviewing the server log files is by far the most effective way to spot any crawl issues or inefficiencies. Tools like Botify and On Crawl can be extremely useful because they combine crawls with server log data and can highlight pages search engines do not crawl, pages that are not linked to internally (orphan pages), low-value pages that are heavily internally linked, and a lot more.

Review crawl errors regularly

Keep an eye on the reported crawl errors, ideally daily during the first few weeks. Downloading these errors daily, crawling the reported URLs, and taking the necessary actions (i.e. implement additional 301 redirects, fix soft 404 errors) will aid a quicker recovery. It’s highly unlikely you will need to redirect every single 404 that is reported, but you should add redirects for the most important ones.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Pro tip: In Google Analytics you can easily find out which are the most commonly requested 404 URLs and fix these first!

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Other useful Search Console features

Other Search Console features worth checking include the Blocked Resources, Structured Data errors, Mobile Usability errors, HTML Improvements, and International Targeting (to check for hreflang reported errors).

Pro tip: Keep a close eye on the URL parameters in case they’re causing duplicate content issues. If this is the case, consider taking some urgent remedial action.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Measuring site speed

Once the new site is live, measure site speed to make sure the site’s pages are loading fast enough on both desktop and mobile devices. With site speed being a ranking signal across devices and becauseslow pages lose users and customers, comparing the new site’s speed with the old site’s is extremely important. If the new site’s page loading times appear to be higher you should take some immediate action, otherwise your site’s traffic and conversions will almost certainly take a hit.

Evaluating speed using Google’s tools

Two tools that can help with this are Google’s Lighthouse and Pagespeed Insights.

The Pagespeed Insights Tool measures page performance on both mobile and desktop devices and shows real-world page speed data based on user data Google collects from Chrome. It also checks to see if a page has applied common performance best practices and provides an optimization score. The tool includes the following main categories:

  • Speed score: Categorizes a page as Fast, Average, or Slow using two metrics: The First Contentful Paint (FCP) and DOM Content Loaded (DCL). A page is considered fast if both metrics are in the top one-third of their category.
  • Optimization score: Categorizes a page as Good, Medium, or Low based on performance headroom.
  • Page load distributions: Categorizes a page as Fast (fastest third), Average (middle third), or Slow (bottom third) by comparing against all FCP and DCL events in the Chrome User Experience Report.
  • Page stats: Can indicate if the page might be faster if the developer modifies the appearance and functionality of the page.
  • Optimization suggestions: A list of best practices that could be applied to a page.
SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Google’s PageSpeed Insights in action

Google’s Lighthouse is very handy for mobile performance, accessibility, and Progressive Web Apps audits. It provides various useful metrics that can be used to measure page performance on mobile devices, such as:

  • First Meaningful Paint that measures when the primary content of a page is visible.
  • Time to Interactive is the point at which the page is ready for a user to interact with.
  • Speed Index measures shows how quickly a page are visibly populated

Both tools provide recommendations to help improve any reported site performance issues.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Google’s Lighthouse in action

You can also use this Google tool to get a rough estimate on the percentage of users you may be losing from your mobile site’s pages due to slow page loading times.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

The same tool also provides an industry comparison so you get an idea of how far you are from the top performing sites in your industry.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Measuring speed from real users

Once the site has gone live, you can start evaluating site speed based on the users visiting your site. If you have Google Analytics, you can easily compare the new site’s average load time with the previous one.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

In addition, if you have access to a Real User Monitoring tool such as Pingdom, you can evaluate site speed based on the users visiting your website. The below map illustrates how different visitors experience very different loading times depending on their geographic location. In the below example, the page loading times appear to be satisfactory to visitors from the UK, US, and Germany, but to users residing in other countries they are much higher.

SEO: Le guide de migration de site Web : stratégie, processus et liste de contrôle de référencement

Phase 6: Measuring site migration performance

When to measure

Has the site migration been successful? This is the million-dollar question everyone involved would like to know the answer to as soon as the new site goes live. In reality, the longer you wait the clearer the answer becomes, as visibility during the first few weeks or even months can be very volatile depending on the size and authority of your site. For smaller sites, a 4–6 week period should be sufficient before comparing the new site’s visibility with the old site’s. For large websites you may have to wait for at least 2–3 months before measuring.

In addition, if the new site is significantly different from the previous one, users will need some time to get used to the new look and feel and acclimatize themselves with the new taxonomy, user journeys, etc. Such changes initially have a significant negative impact on the site’s conversion rate, which should improve after a few weeks as returning visitors are getting more and more used to the new site. In any case, making data-driven conclusions about the new site’s UX can be risky.

But these are just general rules of thumb and need to be taken into consideration along with other factors. For instance, if a few days or weeks after the new site launch significant additional changes were made (e.g. to address a technical issue), the migration’s evaluation should be pushed further back.

How to measure

Performance measurement is very important and even though business stakeholders would only be interested to hear about the revenue and traffic impact, there are a whole lot of other metrics you should pay attention to. For example, there can be several reasons for revenue going down following a site migration, including seasonal trends, lower brand interest, UX issues that have significantly lowered the site’s conversion rate, poor mobile performance, poor page loading times, etc. So, in addition to the organic traffic and revenue figures, also pay attention to the following:

  • Desktop and mobile rankings (from any reliable rank tracking tool)
  • User engagement (bounce rate, average time on page)
  • Sessions per page type (i.e. are the category pages driving as many sessions as before?)
  • Conversion rate per page type (i.e. are the product pages converting the same way as before?)
  • Conversion rate by device (i.e. has the desktop/mobile conversion rate increased/decreased since launching the new site?)

Reviewing the below could also be very handy, especially from a technical troubleshooting perspective:

  • Number of indexed pages (Search Console)
  • Submitted vs indexed pages in XML sitemaps (Search Console)
  • Pages receiving at least one visit (analytics)
  • Site speed (PageSpeed Insights, Lighthouse, Google Analytics)

It’s only after you’ve looked into all the above areas that you could safely conclude whether your migration has been successful or not.

Good luck and if you need any consultation or assistance with your site migration, please get in touch!


Site migration checklist

An up-to-date site migration checklist is available to download from our site. Please note that the checklist is regularly updated to include all critical areas for a successful site migration.


Appendix: Useful tools

Crawlers

  • Screaming Frog: The Swiss army knife, ideal for crawling small- and medium-sized websites.
  • Sitebulb: Very intuitive crawler application with a neat user interface, nicely organized reports, and many useful data visualizations.
  • Deep Crawl: Cloud-based crawler with the ability to crawl staging sites and make crawl comparisons. Allows for comparisons between different crawls and copes well with large websites.
  • Botify: Another powerful cloud-based crawler supported by exceptional server log file analysis capabilities that can be very insightful in terms of understanding how search engines crawl the site.
  • On-Crawl: Crawler and server log analyzer for enterprise audits with many handy features to identify crawl budget, content quality, and performance issues.

Handy Chrome add-ons

  • Web developer: A collection of developer tools including easy ways to enable/disable JavaScript, CSS, images, etc.
  • User agent switcher: Switch between different user agents including Googlebot, mobile, and other agents.
  • Ayima Redirect Path: A great header and redirect checker.
  • Meta in 1 click: An on-page meta attributes, headers, and links inspector.
  • Scraper: An easy way to scrape website data into a spreadsheet.

Site monitoring tools

  • Uptime Robot: Free website uptime monitoring.
  • Robotto: Free robots.txt monitoring tool.
  • Pingdom tools: Monitors site uptime and page speed from real users (RUM service)
  • Radar: Monitors all critical elements and fires alerts when these change.

Site performance tools

  • PageSpeed Insights: Measures page performance for mobile and desktop devices. It checks to see if a page has applied common performance best practices and provides a score, which ranges from 0 to 100 points.
  • Lighthouse: Handy Chrome extension for performance, accessibility, Progressive Web Apps audits. Can also be run from the command line, or as a Node module.
  • Webpagetest.org: Very detailed page tests from various locations, connections, and devices, including detailed waterfall charts.

Structured data testing tools

Mobile testing tools

Backlink data sources

#guide #migration #site #Web #stratégie #processus #liste #contrôle #référencement