Migration SEO de A à Z

La migration d’un site Web peut être un véritable champ de mines si vous n’êtes pas méticuleux dans votre approche. Assurez-vous de ne rien manquer d’important avec l’aide de notre guide complet.

Aller à la section

  • Qu’est-ce qu’une migration de site Web ?
  • Types de migration de sites Web
  • Processus de migration de sites Web
  • Outils de migration de sites Web
  • Vous planifiez la migration d’un site Web ?

La migration d’un site Web n’est pas la tâche la plus facile au monde, mais une bonne planification permet d’atténuer la plupart des risques.

Nous avons établi la liste de contrôle de la migration de sites Web suivante pour vous aider à vous frayer un chemin à travers le processus, à éviter la plupart des pièges typiques et à arriver de l’autre côté avec un site propre et bien rangé, et prêt pour le succès du référencement.

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

Lorsque nous parlons de “migration de site Web”, cela signifie généralement qu’un site a subi un changement majeur dans un ou plusieurs des aspects suivants : la technologie sur laquelle le site est construit ; l’endroit où le site est hébergé ; la façon dont le contenu du site est structuré.

Les migrations de sites Web peuvent modifier considérablement la façon dont votre site est perçu par les moteurs de recherche et, par conséquent, avoir un impact potentiel important sur votre visibilité organique. Plus le changement est important, plus il y a de chances que votre site soit réévalué à partir de zéro, ce qui pourrait vous faire perdre tout avantage en termes de classement.

Il est donc essentiel de disposer d’un plan solide, adapté à vos besoins spécifiques et conçu pour rendre le processus aussi fluide que possible, en couvrant les activités qui doivent être menées avant, pendant et après le lancement.

Types de migration de sites Web

Il existe de nombreux types de migration de sites Web, certains étant plus courants que d’autres. Examinons quelques exemples et soulignons les problèmes spécifiques au contexte.

Migration de protocole (HTTP vers HTTPS)

Exemple : http://www.example.com vers https://www.example.com

L’une des raisons les plus courantes de la migration d’un site web au cours des deux dernières années est le changement de protocole de HTTP à HTTPS.

Le protocole HTTPS est devenu une exigence des navigateurs web modernes car le fait de servir votre site via la couche de sockets sécurisés offre un bien meilleur niveau de sécurité et de confidentialité à vos utilisateurs. En conséquence, si un site est hébergé en HTTPS plutôt qu’en HTTP, les visiteurs n’ont pas besoin d’être avertis par le message “non sécurisé” lorsqu’ils arrivent sur votre site. La confiance et l’engagement des utilisateurs s’en trouvent renforcés, ce qui se traduit par une réduction du taux de rebond et une augmentation du temps de visite, facteur de classement positif pour les moteurs de recherche. Ainsi, HTTPS peut conduire à un meilleur classement que HTTP.

Cependant, il faut faire attention à certaines choses.

Le processus de migration de HTTP à HTTPS s’effectue en grande partie par la configuration de votre environnement d’hébergement. Cette tâche est souvent confiée à un fournisseur spécialisé en informatique ou à un membre de votre équipe. Les tâches consistent généralement à obtenir et à installer un certificat SSL et à reconfigurer l’hôte préféré dans un panneau de contrôle tel que Plesk ou cPanel.

Mais il y a aussi des tâches qui sont plus susceptibles d’être accomplies par un webmaster ou un concepteur de sites Web. Par exemple, la mise à jour de tous les liens internes de votre site pour s’assurer qu’ils pointent vers des URL HTTPS et que les actifs tels que les images, les fichiers CSS et JS sont référencés via des requêtes https. Si votre site utilise un CMS standard tel que WordPress, il y aura probablement des variables de configuration du CMS qui devront être mises à jour avec le nouveau protocole, et divers endroits dans la base de données où le HTTP est référencé.

Ces éléments peuvent avoir un impact sérieux sur votre référencement s’ils ne sont pas effectués en tant que partie intégrante de la migration.

Une fois ces vérifications effectuées, une étape essentielle consiste à s’assurer que toutes les URL HTTP renvoient une redirection 301 vers leur équivalent HTTPS. Un robot d’exploration de site tel que Screaming Frog peut vous aider à explorer l’ensemble du site rapidement et avec un minimum de travail manuel, après quoi vous pouvez utiliser les rapports “codes de réponse” ou “chaînes de redirection” pour vérifier.

Migration de domaine

Exemple : https://www.example.com vers https://www.newexample.com

Une migration de domaine consiste à changer le nom de domaine par lequel un site est adressé. C’est généralement le cas lorsqu’une entreprise change de marque ou acquiert un nom de domaine qui correspond mieux à sa marque existante.

La migration vers un domaine ayant appartenu à une autre personne ou entreprise comporte certains des risques les plus élevés en termes d’impact organique imprévu.

Avant même d’acheter un domaine “d’occasion”, vous devez vérifier son historique.

Si le domaine a été utilisé par un autre site pendant une période prolongée, il est probable qu’il ait accumulé une variété de signaux externes que les moteurs de recherche utilisent pour décider à qui le site sera utile.

Si l’objectif du site précédent n’était pas le même que le vôtre, un travail sérieux peut être nécessaire pour modifier la façon dont le domaine est perçu par les moteurs de recherche.

Ce travail peut impliquer le nettoyage et le désaveu de liens qui étaient autrefois précieux pour l’ancien propriétaire, mais qui ne le seront pas pour vous parce qu’ils ne sont pas pertinents pour les activités de votre entreprise. Les liens forts et les mentions de domaine qui semblent pouvoir aider votre site à se classer n’auront de la valeur que s’ils sont pertinents par rapport à votre verticalité.

Un autre risque est celui d’un domaine qui n’a pas été utilisé pendant une période prolongée et qui n’affiche peut-être qu’une page d’attente ou un message “à vendre”. Google et d’autres moteurs de recherche suppriment souvent ces domaines de l’index public parce qu’ils offrent peu de valeur aux utilisateurs finaux, et il peut s’écouler beaucoup de temps avant qu’ils ne soient à nouveau “autorisés” dans l’index public.

Dans un cas que nous avons vu l’année dernière, ce processus a pris près de 12 mois à partir de la migration.

Il est donc essentiel de vérifier à quoi servait un domaine auparavant, car cela peut être la clé du succès de votre site Web à court et moyen terme. Internet Archive est un excellent outil qui permet de visualiser les itérations du site au fil des ans. Les outils de référencement tels que Sistrix, Ahrefs, SEMrush, Majestic sont excellents pour vérifier les liens retour, la visibilité et les mots clés pour lesquels le domaine est apparu dans les SERPs. Tout cela peut aider à dresser un tableau de la façon dont un domaine est perçu.

Par exemple, supposons que votre site Web vende des voitures, mais après avoir effectué certaines des vérifications ci-dessus, vous découvrez que le nom de domaine que vous venez d’acquérir était auparavant utilisé par un site qui vend des montres. Si tous les backlinks externes concernent des montres, il est très probable que les moteurs de recherche continueront à associer ce nom de domaine aux montres jusqu’à ce que la pondération du profil de backlink évolue vers quelque chose de plus pertinent. Dans l’intervalle, vous devrez vous appuyer sur d’autres canaux pour compenser le déficit de vos performances organiques.

Cela signifie également que les backlinks historiques qui ont une grande valeur perçue par votre vendeur et qui ont donc été pris en compte dans le prix demandé pour le domaine, pourraient en fait être un handicap majeur plutôt qu’un atout.

Cela vaut-il la peine de revoir votre choix de domaine ?

Migration des extensions de domaine

Exemple : https://www.example.co.uk vers https://www.example.com

On parle de migration d’extension de domaine lorsqu’un site web passe d’un ccTLD (country code top-level domain) à un gTLD (generic top-level domain) ou inversement. C’est souvent le cas lorsqu’une entreprise cherche à passer à un modèle d’entreprise plus axé sur l’international.

Lorsque le domaine cible est nouvellement acquis, il est utile de procéder aux mêmes vérifications que celles mentionnées dans la section ” migration de domaine ” ci-dessus, car une autre entreprise pourrait avoir utilisé la version .com de votre domaine dans un but complètement différent du vôtre.

Le ciblage international est un sujet à part entière, mais en ce qui concerne la migration, il y a quelques points clés à considérer :

  1. Configuration des balises hreflang. Avez-vous l’intention d’utiliser votre nouveau domaine pour cibler des publics de langues différentes ? Si c’est le cas, vous devrez mettre en place une structure d’URL qui permette aux robots d’exploration de comprendre comment accéder aux différentes variantes linguistiques du même contenu, ce qui implique l’utilisation de balises hreflang.
  2. Paramètres de ciblage international dans Search Console. Lorsqu’un domaine possède une extension non spécifique à un pays, Search Console permet aux webmasters de définir un pays cible préféré. Vous devrez vérifier que ce paramètre correspond à vos besoins. (Il s’agit désormais d’un outil hérité dans Search Console).

Migration de sous-domaines

Exemple : https://blog.example.com vers https://www.example.com/blog

Les migrations de sous-domaines peuvent être effectuées pour diverses raisons, comme la migration d’un blog vers votre site Web principal ou la fusion de sites mobiles et de bureau distincts en un seul site réactif.

Fusion de sites

Exemple : https://www.example1.com et https://www.example2.com vers https://www.example3.com

Les fusions de sites impliquant des sites préexistants sur plusieurs domaines peuvent être très compliquées. Il peut s’agir de fusionner plusieurs entreprises sous un nouveau domaine ou de consolider plusieurs sites internationaux dans un TLD avec des structures de sous-dossiers.

Changement de structure d’URL

Exemple : https://www.example.com/some-path/product-url en https://www.example.com/product-url

Les modifications structurelles des URL ou du contenu peuvent constituer un facteur supplémentaire dans bon nombre des types de migration ci-dessus. Vous pouvez changer de plateforme, de Shopify à WordPress, ou déplacer le contenu de votre blog de la racine vers un sous-dossier. En vous assurant que les redirections sont correctement configurées, vous pourrez transférer le capital sur les nouvelles URL.

Processus de migration du site Web

Quel que soit le type de migration de site Web, le processus peut généralement être divisé en trois étapes : pré-lancement, vérifications le jour du lancement et post-lancement.

Pré-lancement

Vérification du nom de domaine

Comme nous l’avons mentionné précédemment, si vous achetez un domaine pour y migrer votre site web, faites quelques vérifications pour établir l’historique du domaine. Soyez attentif à tout ce qui pourrait poser problème, comme des liens retour sans rapport avec le domaine, des classements historiques de mots-clés dans une niche ou des pénalités manuelles.

Contrôle des performances

Décider du contenu à conserver doit être un élément clé de toute migration de site.

Prévoyez-vous de conserver l’ensemble de votre contenu ? Si ce n’est pas le cas, demandez-vous s’il serait plus facile de migrer le site Web dans son intégralité et d’effectuer un tri du contenu à une date ultérieure, ou de prendre le taureau par les cornes et de le réduire au préalable.

En effectuant une vérification détaillée des pages qui ont de la valeur, puis en les réduisant avant la migration, on peut obtenir une migration plus rapide et plus propre, car les moteurs de recherche n’auront pas autant d’URL à explorer pendant la migration elle-même.

En utilisant Google Search Console pour évaluer le classement des mots clés et les URL préférées, et Google Analytics pour évaluer les performances du site sur tous les canaux, vous pouvez identifier les pages qui n’ont pas une valeur commerciale suffisante et qui peuvent être élaguées en toute sécurité.

Une fois cette étape franchie, avant de procéder à la migration, laissez le temps aux moteurs de recherche de recrawler votre site, de remarquer les changements et de réduire le nombre de requêtes vers ces URL.

Analyse des fichiers journaux

L’analyse des fichiers journaux est une activité relativement technique, dont la courbe d’apprentissage est trop raide pour certains, mais elle peut vous donner une compréhension approfondie de ce que font les moteurs de recherche lorsqu’ils visitent votre site Web. C’est très utile pour les migrations de sites, car vous pouvez mesurer le comportement des robots d’exploration avant, pendant et après, ce qui vous donne une idée précise du succès de la migration.

Les fichiers journaux du serveur regorgent d’informations sur les pages et les actifs de votre site que les moteurs de recherche et les robots aiment explorer. Ces informations peuvent vous aider à résoudre les problèmes de liens internes et les erreurs d’exploration, à identifier les anciennes URL qui sont toujours explorées mais ne sont pas signalées, et à faciliter le mappage et le test des redirections tout au long du processus.

Vous pouvez utiliser l’analyseur de fichiers journaux de Screaming Frogs pour simplifier le processus.

Correction des liens internes non-200

La correction des liens internes qui ne renvoient pas une réponse 200 dans la phase de pré-lancement peut aider à conserver le budget d’exploration, et aussi vous faire gagner du temps en améliorant le rapport signal/bruit dans vos journaux de post-lancement.

Un profil d’exploration ordonné permet aux robots d’exploration de comprendre plus facilement votre site, ce qui peut accélérer la réussite de votre migration, car il y a moins d’URL à explorer de nouveau et à réévaluer.

Si vous effectuez cette opération manuellement, n’oubliez pas de vérifier les menus de navigation pour ordinateurs de bureau et mobiles, le contenu hérité tel que les anciens articles de blog, les références aux actifs tels que les images, et les éléments techniques qui sont cachés, tels que les balises canoniques et les sitemaps XML.

L’analyse des fichiers journaux peut vous aider à repérer les requêtes cassées ; les logiciels d’exploration tels que Screaming Frog peuvent vous aider à identifier les liens cassés dans le contenu de votre site et à repérer la mauvaise configuration d’éléments techniques en masse.

Collecte d’URL

La collecte d’une liste complète de toutes les URL connues est une activité essentielle de pré-lancement. Cette liste peut être utilisée comme fichier maître pour tester les redirections après le lancement.

Mais comment rassembler toutes ces URL ? Vous devez utiliser plusieurs sources pour être sûr d’obtenir une image complète. Voici quelques suggestions :

  1. Google Search Console (rassemblez les pages les plus performantes, les pages les plus liées).
  2. Google Analytics (rassemblez toutes les URL des pages de destination de tous les canaux au cours des 12 derniers mois).
  3. URL des pages d’atterrissage dans les comptes de recherche payants tels que Google Ads et Bing Ads.
  4. Les sources externes telles qu’Ahrefs, SEMrush, Moz, Majestic et Sistrix sont une bonne source d’URL référencées en externe, et notamment de précieux backlinks.
  5. Un crawl complet du site web en utilisant Screaming Frog.
  6. Les fichiers journaux du serveur mettront en lumière les URL que les moteurs de recherche explorent, mais qui ne figurent pas ailleurs.
  7. Instructions de redirection, par exemple dans le fichier .htaccess de votre site, le fichier des routes ou la configuration de IIS.

Une fois que vous avez rassemblé les URL de tous ces endroits, vous devez les dédupliquer, puis les classer en deux catégories : celles que vous souhaitez conserver et migrer, et celles que vous souhaitez supprimer.

Robots.txt

Le fichier robots.txt affecte la manière dont les robots des moteurs de recherche explorent votre site. Votre site Web actuel devrait en avoir un, mais vous devriez également tenir compte de celui de votre site Web de mise en scène/développement.

Pour le site actuel, il est bon de vérifier si les directives qu’il contient sont toujours nécessaires.

Pour votre nouveau site d’essai, il est essentiel de veiller à ce que les moteurs de recherche ne puissent pas l’explorer avant la mise en service.

Plans de site XML

Vos sitemaps XML doivent fournir une liste complète du contenu que vous souhaitez indexer. Ils peuvent aider les robots d’exploration à découvrir vos nouvelles URL et à suivre la couverture d’indexation – de vos nouvelles et anciennes URL.

Pour ce faire, vous pouvez diviser le plan du site en catégories d’URL basées sur un thème commun. Par exemple, un type particulier de contenu, comme les articles de blog, peut être répertorié dans un plan de site XML, tandis que les URL de produits sont répertoriées dans un autre.

En hébergeant un sitemap XML de vos anciennes URL sur votre nouveau site Web, vous pouvez accélérer l’exploration des anciennes URL et contrôler combien d’entre elles restent dans l’index au fil du temps. Cela peut vous aider à repérer le contenu hérité qui continue de figurer dans l’index longtemps après la migration et peut vous donner des indices sur la façon de résoudre le problème.

Configuration hreflang

Si vous migrez plusieurs domaines vers un nouveau TLD avec plusieurs langues cibles, il est essentiel de s’assurer que la configuration hreflang est effectuée sur le site de transit et testée avant le lancement. Il peut s’agir de vérifier que le hreflang est implémenté dans le code de chaque page ou dans les sitemaps XML, que la balise html lang a été définie, ou même que le contenu a été traduit correctement.

Vous devez vérifier la couverture des balises hreflang, la configuration canonique de chaque variante de page, l’inclusion de balises réciproques entre les variantes de page, et si toutes les paires de langues/locaux requises sont présentes et correctes.

Vérifications de la Search Console et nouvelle configuration

Avant le lancement, vous devez vous assurer que vous avez accès à toutes les propriétés de Google Search Console dont vous avez besoin pour effectuer la migration.

Des propriétés distinctes sont généralement nécessaires pour surveiller les performances des variantes d’un domaine (http://, https://, http://www. et https://www.).

Une “propriété de domaine” couvrira toutes les variantes de votre domaine, y compris les sous-domaines, mais ce n’est qu’en revendiquant les propriétés individuelles que vous aurez accès à tous les paramètres et outils de rapport pour chacune d’elles.

Si votre migration implique un changement de domaine, vous devrez le faire pour le domaine actuel et le nouveau domaine.

Une fois que vous avez accès à toutes les propriétés Search Console requises, vous devez vérifier les différentes sections pour détecter les problèmes majeurs tels que les problèmes de sécurité et les actions manuelles. Vérifiez également l’onglet “Couverture” pour voir si Google a des difficultés à explorer le site Web actuel.

Il est également utile de demander le profil Bing Webmaster Tools de votre site et de procéder aux vérifications qui s’y trouvent. Il s’agit de l’équivalent de Google Webmaster Tools chez Microsoft, qui offre une perspective différente sur les mêmes informations.

Si vous prenez le temps de régler ces problèmes maintenant, vous obtiendrez de meilleurs résultats lors de la migration.

Configuration de Google Analytics

Par défaut, Google Analytics est indifférent aux domaines et aux protocoles. Si vous installez le même extrait d’analyse sur différents sites, les données des deux sites seront enregistrées.

Toutefois, il est important de vérifier la configuration de votre GA pour toute configuration spécifique à un domaine – par exemple, si le suivi est limité uniquement à un domaine spécifique ou à une propriété de domaine. Cela est parfois fait pour empêcher l’enregistrement de données erronées à partir de sites de transit, par exemple.

En fonction de votre situation, il peut être utile de configurer un profil distinct pour le nouveau domaine ou site afin de pouvoir comparer les performances avant et après la migration. Cela peut constituer un diagnostic utile si les choses ne se déroulent pas comme prévu.

Autres canaux de marketing

Nous n’entrerons pas dans les détails sur ce point, mais la prise en compte de l’impact potentiel de la migration sur d’autres canaux de marketing est une partie importante de la migration d’un site Web. Dans le cadre de vos vérifications de pré-lancement, créez une liste de tous les éléments de vos activités de marketing plus larges qui pourraient nécessiter une mise à jour. Il peut s’agir des éléments suivants

  1. Les pages d’atterrissage utilisées dans vos comptes de PPC et de publicité par affichage.
  2. Les liens dans les profils de médias sociaux et les messages populaires/principaux.
  3. Inscriptions dans les annuaires professionnels tels que Google My Business, Bing Places for Business et autres annuaires.
  4. URL de destination du marketing par courriel
  5. URL des produits inclus dans les flux pour le marketing d’affiliation et les canaux similaires.
  6. Publicité traditionnelle telle que la presse écrite, la radio et la télévision.

Pour les sites plus importants et les entreprises dotées d’équipes complexes, il est important d’avoir une conversation dès le début avec les fournisseurs de services de marketing et les parties prenantes similaires pour les sensibiliser à la migration et leur demander quelles sont leurs préoccupations concernant l’impact potentiel.

Cartographie des redirections

Le mappage des redirections est sans doute la partie la plus importante de la phase de pré-lancement. Nous laissons généralement cette étape le plus tard possible dans les préparatifs de la migration, car d’autres activités (comme l’élagage et la restructuration) peuvent avoir un impact sur la liste des anciennes et des nouvelles URL.

Cela permet d’éviter de perdre du temps à maintenir et à mettre à jour les instructions de redirection pour tenir compte d’autres changements qui surviennent après la mise en correspondance.

Lors de la planification des redirections, il faut tenir compte du fait qu’à moins que votre migration ne soit un simple “copier-coller” d’un site d’un domaine à un autre sans aucun changement structurel, il n’est généralement pas possible d’adopter une approche “taille unique” pour les instructions de redirection.

Voici quelques types de redirections à prendre en compte :

  • Redirections de page à page (https://www.example.com/category/page/ à https://www.example1.com/category/page/). Si vous voulez conserver autant d’équité de classement que possible, la majorité de vos redirections doivent être de page à page. Pour de meilleurs résultats, le contenu de votre nouvelle page devra être au moins aussi bon que celui de votre page existante.
  • Redirections de page à parent (https://www.example.com/category/page/ à https://www.example1.com/category/). Ce type de redirection peut s’avérer nécessaire si, pendant la phase de pré-lancement, vous décidez d’élaguer un contenu de niveau inférieur pour lequel il n’existe pas d’équivalent approprié, mais une page parente ou une catégorie conteneur étroitement liée.
  • Redirections de la page vers la racine (https://www.example.com/category/page/ vers https://www.example1.com/). C’est peut-être la meilleure option si certaines pages du site actuel n’ont pas de page directe ou parente vers laquelle rediriger. La redirection de l’URL vers la racine (page d’accueil) ne vaut la peine que si elle ne crée pas une trop grande déconnexion pour un utilisateur peu méfiant et n’entraîne pas de rebond.
  • Pas de redirection. Autoriser une URL à 404 peut être la meilleure solution s’il n’y a vraiment aucun équivalent et que votre nouveau site n’a aucune valeur pour les utilisateurs qui recherchent votre ancien contenu. Par exemple, si vous avez décidé de ne plus vendre une catégorie entière de produits.

N’oubliez pas non plus vos redirections préexistantes, en veillant à ce qu’elles ne soient pas oubliées ou qu’elles n’entrent pas en conflit avec le nouveau mappage des redirections. Même si certaines redirections sont en place depuis longtemps (plus de 12 mois), il est probable qu’elles soient encore explorées de temps en temps – l’analyse des fichiers journaux peut vous aider à vérifier si c’est le cas ou non.

Un autre point important à considérer est que les redirections doivent toujours emprunter le chemin le plus court et le plus direct possible. Plutôt que d’envoyer les utilisateurs de A à B à C, nécessitant 2 instructions de redirection, vous voudriez idéalement qu’ils aillent de A à C, nécessitant une seule instruction. Le rapport sur les “chaînes de redirection” de Screaming Frog peut être utilisé pour vérifier que vos règles de redirection ne contiennent pas d’entrées entraînant des étapes multiples.

Vérifications pour le jour du lancement

Le jour du lancement est enfin arrivé ! Votre site d’essai est terminé, vos redirections sont prêtes à être utilisées et vous avez mis en place tous vos systèmes de suivi pour vous préparer. Sans plus attendre, vous lancez votre site.

Voici une liste de choses que vous devez vérifier immédiatement :

  1. Assurez-vous que vos redirections fonctionnent. Nous aimons effectuer quelques vérifications manuelles ponctuelles immédiatement, suivies d’un crawl complet de toutes les anciennes URL dans la liste de mappage des redirections pour s’assurer qu’elles mènent à un point d’arrivée raisonnable. Un crawler tel que Screaming Frog peut être utilisé en “mode liste” pour automatiser cette opération.
  2. Vérifiez le fichier robots.txt. Si vous aviez une directive disallow en place sur votre environnement de test, vous devez vous assurer qu’elle a été supprimée maintenant que le site est en ligne. Vous devez également vérifier les directives qui s’y trouvent pour vous assurer qu’elles vous conviennent. Google propose un testeur de robots.txt pour vous aider à vérifier si les directives qu’il contient fonctionnent comme prévu.
  3. Vérifiez vos sitemaps XML. Assurez-vous que toutes les URL que vous souhaitez indexer y figurent. Cela aidera les moteurs de recherche à découvrir et à indexer vos nouvelles URL plus rapidement. Soumettre les sitemaps XML à des endroits comme Google Search Console aidera également à identifier tout problème. Et enfin, n’oubliez pas d’inclure une directive sitemap dans votre fichier robots.txt !
  4. Assurez-vous que vos sitemaps XML sont configurés dans Bing Webmaster Tools.
  5. Exécutez un crawl complet. Cela vaut la peine d’exécuter un crawl complet pour s’assurer que tous les liens internes renvoient un statut 200 ; que toutes les URL canoniques ont des balises canoniques qui correspondent à l’URL de la requête ; que les directives d’indexation ne bloquent pas les pages clés ou si vous avez manqué une certaine section qui ne devrait pas être indexée ; que les balises hreflang et lang sont configurées.
  6. Vérifiez que vos outils de suivi, tels que Google Analytics, fonctionnent sur le nouveau domaine. La fonction de rapport en temps réel peut vous aider à voir ce qui se passe avec des utilisateurs réels.
  7. Si vos vérifications initiales semblent bonnes, n’oubliez pas d’informer Google que vous avez changé de domaine. L’une des choses les plus importantes à faire le jour du lancement est d’utiliser l’outil de changement d’adresse de Google pour l’informer que votre ancien domaine a été transféré vers le nouveau. Cela aidera Google à vérifier le changement et, espérons-le, à accélérer le processus d’exploration et d’indexation du nouveau domaine.
  8. Mettez à jour les URL cibles sur vos canaux de publicité payants. Pour beaucoup d’entreprises, les canaux de publicité payante et les canaux sociaux payants sont des moteurs de revenus essentiels, alors n’oubliez pas de mettre à jour toutes vos créations publicitaires avec les nouvelles adresses des pages de destination. Les flux d’achats devront également être vérifiés pour s’assurer que les URL de vos produits sont toujours valides. Accordez une attention particulière aux produits à variantes multiples, qui peuvent inclure des paramètres URL supplémentaires pour aider les robots d’exploration à accéder aux variantes de couleur/taille individuelles. Cela devient encore plus complexe lorsque des paramètres hreflang sont également utilisés.
  9. Si votre migration implique un changement de domaine (et de nom de société/marque), n’oubliez pas de vérifier les mentions de l’ancienne marque, du nom de société ou du nom de domaine. Les endroits souvent négligés sont les méta titres des pages, les méta descriptions, les données structurées, les noms de fichiers d’images et le texte alt, ainsi que les courriels générés par le site (par exemple, les courriels de confirmation de commande). Pensez également à vérifier les liens externes vers vos autres propriétés web. Par exemple, les profils sociaux, la fiche Google My Business et les sites d’évaluation externes.

Contrôles après le lancement

Les contrôles post-lancement doivent être effectués régulièrement dans les jours et les semaines qui suivent le lancement. Vous devez garder un œil sur les domaines couverts pendant la phase de pré-lancement pour vous assurer qu’il n’y a pas de problèmes émergents. Voici trois activités clés qui pourraient vous aider à détecter tout problème et à garantir un bon résultat de migration :

1. Vérifier toutes les zones de Search Console. Il faudra quelques jours à Search Console pour commencer à rapporter des données significatives, mais une fois que c’est le cas, vous devez chercher à résoudre tous les problèmes qui sont mis en évidence aussi rapidement que possible. Les principaux domaines d’intérêt sont les suivants : les problèmes de couverture, afin de corriger les erreurs d’exploration ou les zones que Google ne peut pas indexer ; la section “Mobile Friendly”, au cas où des problèmes liés au nouveau site ou au nouveau domaine empêcheraient Google de rendre les pages correctement ; les “Core Web Vitals”, pour les problèmes liés à la vitesse et à l’expérience utilisateur ; la section “Structured Data”, pour les problèmes tels qu’un schéma de produit incomplet ; la section “Crawl Stats”, pour vérifier si le nouveau site est exploré et, le cas échéant, si le taux d’exploration est comparable à celui du site précédent.
2. Vérifier les fichiers journaux du serveur. Il s’agit en fait de l'”autre côté” de la section des statistiques d’exploration de Search Console – voir ce que les robots d’exploration des moteurs de recherche font lorsqu’ils visitent votre site, mais avec un plus grand niveau de transparence et de détail, ce qui vous aidera à résoudre tout problème.
3. Commencez à récupérer les backlinks. Prenez contact avec les sites hébergeant vos backlinks les plus importants pour demander qu’ils soient mis à jour pour pointer vers vos nouvelles URL. Cette tâche peut prendre un certain temps, mais il peut être plus facile de récupérer un lien retour existant de haut niveau que d’essayer d’en placer un nouveau. Des outils comme Ahrefs peuvent vous aider à identifier les backlinks les plus intéressants.

Outils de migration de sites Web

Voici une liste d’outils qui pourraient vous aider dans la migration de votre site Web :

  1. Google Search Console & Analytics – pour le suivi interne.
  2. Sistrix, Ahrefs, SEMrush, Moz, Majestic – pour les vérifications externes des anciens et nouveaux domaines.
  3. Internet Archive – pour vérifier l’historique des nouveaux domaines
  4. Screaming Frog – pour tous vos besoins en matière de crawling et de vérification.
  5. Screaming Frog Log File Analyser – pour simplifier le processus de vérification de vos fichiers journaux avant et après la migration.

Vous planifiez la migration d’un site Web ?

Chaque migration de site Web est unique. Les projets de migration sur lesquels nous travaillons impliquent généralement plusieurs types de migration simultanés. Dans ce cas, nous recommandons parfois à notre client d’effectuer certains éléments de la migration (comme la restructuration du site) de manière isolée avant de procéder à la migration complète. Cela peut entraîner un surcroît de travail à court terme, mais cela permet de réduire les risques liés à la migration elle-même.

Quel que soit le type de migration dont vous vous occupez, le fait de suivre un processus ordonné comme celui que nous avons exposé ci-dessus vous aidera à obtenir un résultat positif.

Si vous avez besoin d’informations supplémentaires ou si vous envisagez un projet de migration de site Web et souhaitez obtenir de l’aide, n’hésitez pas à nous contacter.


Laisser un commentaire