Mis à jours 25 août 2018 L’une des tâches les plus redoutables qu’un propriétaire de domaine peut effectuer, c’est de migrer le site Web pour la première fois. Si quelque chose ne va pas, le temps d’arrêt pourrait coûter cher à votre entreprise. Mais pas de panique. Avec notre guide-checklist sur la migration de sites Web, votre client moyen ne sera même pas au courant des modifications apportées dans les coulisses.
Liste de contenu
5 principaux types de migration :
- Hébergement
Le site Web se déplace vers un nouvel hébergeur, ce qui changera l’adresse IP.
- Nom de domaine ou HTTPS ..
La structure du site reste généralement la même, mais l’emplacement change.
- Migration de plate-forme
Le site web passe à une toute nouvelle plateforme.
- Structure de l’URL
Le changement clé est la structure de l’URL ou l’architecture du site.
- Design
La structure et l’emplacement du site Web restent généralement les mêmes, mais un nouveau design est lancé.
Tous les types de migration requièrent différents niveaux de considération et de planification pour garantir le maintien du statu quo, même si le troisième type de migration est le plus intensif du point de vue de la SEO.
Différents types de migrations peuvent également être combinés au sein d’un même projet, ce qui peut apporter des considérations supplémentaires. Par exemple, si le domaine change, cela peut être une bonne occasion d’ajouter HTTPS ou d’améliorer la hiérarchie ou la structure de l’URL en même temps.
Les recommandations ci-dessous fournissent une liste de contrôle pour couvrir toutes les exigences clés.
Les trois phases du processus de migration, qui seront examinées ci-dessous, sont les suivantes :
- Planification de la migration
- Migration et étapes immédiates suivantes
- Action post-migration et maintenance
L’une des principales exigences est le temps alloué à la première phase. Plus tôt ces considérations peuvent être intégrées dans le processus de migration, mieux nous pouvons atténuer les risques.
Analyse comparative
Avant d’entreprendre un projet de migration de site Web, nous recommandons que des objectifs clairs soient établis et que les performances actuelles soient mesurées. Après la migration, cela permettra une évaluation précise du succès.
Les points de données suivants doivent être enregistrés :
- Le classement du site dans tous les pays (y compris les nouveaux ciblés)
- Le trafic organique et les principales pages de destination
- Les performances du temps de chargement du site Web (https://www.webpagetest.org/)
Phase 1 : Vérifications préalables à la migration
Avant que la migration du site puisse commencer, de nombreuses vérifications doivent être effectuées pour garantir le bon déroulement des phases suivantes.
Bloquer le nouveau site Web dans l’environnement de transfert
- L’environnement de transfert ne doit pas être analysé par les moteurs de recherche utilisant l’authentification HTTP (voir la documentation pour Apache, NginX ou IIS). Pour ce faire, l’utilisateur doit entrer un nom d’utilisateur et un mot de passe avant de pouvoir y accéder et empêcher les moteurs de recherche d’accéder à l’environnement de transfert.
- Des exceptions IP peuvent être implémentées pour des fournisseurs externes
- Le site peut être bloqué par le fichier robots.txt et la balise META sur la page [noindex, nofollow], mais il s’agit d’un risque plus élevé et non d’une recommandation préférée.
Construire le nouveau sitemap
- Si les URLs changent, un sitemap pour la nouvelle structure de site devra être créé. Cela devrait répertorier toutes les pages à inclure dans la nouvelle structure du site et les URLs correspondantes sur le site existant.
- Une fois que la liste finale a été acceptée et signée par les parties prenantes concernées, la phase de mappage d’URL peut alors commencer.
- Avancer sans cette signature créera un travail supplémentaire pour revoir et ajuster le mappage de redirection à une date ultérieure et augmenter les chances de générer des erreurs lors du lancement.
Document de mappage d’URL
- Les URLs devront être mappées depuis les anciennes URLs vers les nouvelles URLs via les redirections 301 (en utilisant la destination agréée dans le sitemap)
- Tous ceux qui ne sont pas transférés vers le nouveau domaine devront être :
- 301 redirigé vers la page correspondante
- 301 redirigé vers la prochaine page concernée/page concernée suivante (si elles reçoivent actuellement du trafic ou ont des liens externes pointant vers eux)
- Ou si le contenu est en cours de suppression et n’a pas sa place sur le nouveau site, dans ce cas, il devrait être laissé au 404
- La liste des principales pages de destination peut être identifiée à partir des sources suivantes :
- Pages de renvoi organiques dans Google Analytics et Google Search Console (GSC)
- Analyse du site Web en utilisant un logiciel externe
- Vidage de la base de données du CMS actuel
- Sitemaps XML actuels
- Vérification des journaux du serveur (les 30 derniers jours seraient suffisants pour les sites non affectés par la saisonnalité)
- Pages qui reçoivent des backlinks externes (provenant de fournisseurs de GSC ou de tiers tels que Ahrefs.com ou Majesticseo.com)
Éliminer les chaînes de redirection
- Pour éviter les sauts de redirection inutiles, toutes les redirections actuelles doivent être examinées et mappées pour pointer directement vers les nouvelles URLs.
- Là, l’objectif est de s’assurer que les nouvelles redirections sont mappées sur une base de 1 à 1
Effectuer une analyse de l’environnement de transfert
Une analyse exhaustive de l’endroit ou le site sera transférer est nécessaire afin de s’assurer que l’environnement est prêt recevoir et faire fonctionner votre site sans erreurs
Vérifiez que les éléments suivants ont été correctement configurés :
- La structure de l’URL correspond au plan du site convenu
- Les anciennes URLs 301 redirigent correctement vers les nouvelles URLs
- Les anciennes URLs ne sont pas liées en interne
- Balisage de document ; H1 à H5, titres de page, balises meta, balises canoniques, etc.
- Aucun 4xx, 3xx, 5xx en interne ou externe ou autres codes de statut d’erreur d’analyse
- Plusieurs analyses peuvent être effectuées pour s’assurer que tous les problèmes sont résolus avant la signature.
- Remplir les sitemaps HTML et XML avec les destinations d’URL migrées
- Assurez-vous que tous les sitemaps de l’environnement de transfert reflètent les configurations correctes d’URL et de domaine
- Créez un ancien sitemap XML pour les URLs à rediriger ou à supprimer
- Créez un sitemap XML contenant les URLs migrées ou retirées. Ceci sera utilisé après le lancement pour faciliter l’analyse des redirections et l’identification des 404 prévus.
- Ceci peut être généré à partir des données collectées lors de la phase de mappage des redirections
- Assurez-vous que l’ancien et le nouveau domaine sont configurés dans le même compte GSC (anciennement Google Webmaster Tools)
- La fonctionnalité de changement d’adresse sera utilisée après le lancement pour aider Google à comprendre la nouvelle configuration et à analyser l’ancien sitemap XML sur le nouveau domaine.
- Si nécessaire, configurez un compte avant la migration – https://www.google.com/webmasters/tools/home
- Suivi
- Ajoutez des codes de suivi au plan de migration
- Tout URL ou objectif de conversion à mettre à jour doit être noté dans le document de mappage d’URL et créé à l’avance dans les programmes de suivi correspondants, en utilisant des règles d’exclusion pour empêcher le suivi de la pollution sur le serveur de développement.
- Des comptes fictifs doivent être créés pour effectuer des tests sur le serveur de développement. Idéalement, implémentez une solution de gestion des balises pour une installation plus robuste des balises, la gestion des modifications, les tests et les implémentations de suivi avancées.
Phase 2 : pendant la migration
La deuxième phase comprend le lancement du nouveau site et les actions immédiates nécessaires une fois que tout est prêt.
Migrer pendant un temps d’arrêt
Analysez les analyses quotidiennes pour choisir le meilleur moment pour migrer le site Web. Cela assurera le moins de perturbations au trafic régulier si le basculement n’est pas immédiat, ce qui devrait être le cas.
Servir le code de statut 503
S’il y a un temps d’arrêt imprévu pendant la migration, un code de statut 503 doit être servi, ce qui empêche temporairement les moteurs de recherche d’explorer le site Web sans aucune pénalisation. Il les informe que le serveur est actuellement indisponible et de revenir plus tard.
Supprimer l’authentification HTTP et les restrictions IP
Migrer le site Web depuis le transfert à la production et supprimer toutes les restrictions d’accès au site Web pour faciliter l’exploration et l’indexation.
Migrez le fichier robots.txt correct
- Si le fichier robots.txt lors du transfert est utilisé pour empêcher les robots d’analyse d’accéder au site, assurez-vous qu’il n’est pas migré lors de la phase de lancement.
- Un nouveau fichier robots.txt doit être préparé à l’avance, qui peut être remplacé lorsque le site est mis en ligne. Si l’authentification sécurisée est utilisée à la place et que le fichier robots.txt est correct lors du transfert, il peut être migré directement dans le nouvel environnement.
Vérifiez le site Web pour toute directive NOINDEX, NOFOLLOW pouvant être migré
- Si la balise Meta noindex a été utilisée sur le serveur de transfert pour empêcher l’indexation par les moteurs de recherche, assurez-vous que cette balise est supprimée pendant le processus de migration.
- Des vérifications manuelles peuvent être effectuées immédiatement après le lancement, suivies d’une analyse plus approfondie du site Web.
Phase 3 : Après la migration
Après la mise en ligne du site, il reste encore du travail à faire. Mais la troisième phase ne débutera que lorsque la migration du site aura été achevée avec succès.
Mettre en œuvre des recommandations de mappage d’URL
Une fois le site en ligne, le plan de redirection 301 doit être déployé sur le site en direct.
Effectuer des tests d’acceptation de redirection
- Assurez-vous que toutes les anciennes URL 301 redirigent vers l’URL de page de destination appropriée, conformément au document de mappage
- Les erreurs doivent être minimisées lors des tests sur l’environnement du transfert
Soumettez le nouveau sitemap XML
Soumettez dans le sitemap dans GSC pour le nouveau domaine pour faciliter l’analyse.
Soumettez l’ancien sitemap XML
- Soumettez l’ancien sitemap pour aider Google à analyser les anciennes URLs et à les remplacer par les nouvelles URLs dans les résultats de la recherche.
- Il peut être supprimé une fois que toutes les nouvelles URLs ont été indexées avec succès.
Récupérer et répertorier les URLs dans GSC
- Cet outil permet de récupérer et répertorier des pages à mesure que Google les voit et peut vous aider à résoudre les problèmes éventuels.
- L’élément clé à considérer ici est le blocage de JavaScript et CSS
- Ces vérifications doivent être effectuées sur plusieurs modèles de page pour garantir la découverte de toutes les erreurs potentielles.
Migrer les paramètres depuis l’ancien compte GSC
- Paramètres du pays, fichier de désaveu et réglages de paramètres
- Ceci est applicable si vous déplacez des domaines ou de HTTP vers HTTPS
Exécutez une analyse complète du site pour déterminer les problèmes :
- Les erreurs 404, 302, 301, 500 ainsi que les vérifications de la structure de l’URL
- Les titres de pages et meta descriptions, balises canoniques et balises meta de robots
- Les codes d’analyse et de suivi
Changement d’adresse dans Google Search Console
- Assurez-vous que le nouveau domaine est vérifié
- Utilisez la fonctionnalité de changement d’adresse pour indiquer à Google que le site a été déplacé vers un nouveau domaine (le cas échéant)
- Les redirections 301 doivent être implémentées avant que cette fonction puisse être utilisée
Effectuez des tests d’acceptation du serveur (ou SATs)
Réponse attendue : code de statut 404 Réponse attendue : code de statut 404 Réponse attendue : code de statut 404 Réponse attendue : code de statut 301 Redirection vers : https://www.exemple.com/dossier/ Réponse attendue : code de statut 301 Redirection vers : https://www.example.com/dossier/ Remarque : Vous pouvez avoir des règles spécifiques qui déterminent la réponse de votre serveur. Ceux fournis ci-dessus sont à titre d’exemple. Vous devez vous efforcer de créer vos propres SATs en fonction des configurations existantes. Il faut faire un suivis rigoureux afin de s’assurer que tout s’est déroulé à merveille, rapidement et de manière proactive, en abordant toutes les actions identifiées Auteure des blogs, Aina Strauss préfère penser à « carrière » comme un verbe plutôt qu’un nom. Elle est journaliste indépendant depuis les débuts du Web et écrit sur tout, de l’informatique, de nouvelles technologies au voyage. Son but n’est autre que d’apporter plus d’informations à tous ceux qui souhaitent adopter les nouvelles technologies du Web et de les aider à sélectionner le meilleur hébergement de manière pratique et rentable. Mettre à jour les liens externes
Assurez-vous que les vérifications manuelles sont effectuées sur les fonctionnalités clés
Entreprendre un suivi sur le site pour les deux ou quatre prochaines semaines
