Migration de site web : stratégie et bonnes pratiques

Vous pouvez avoir besoin de migrer votre site web/entreprise pour une raison spécifique. En tant que SEOs, nous appelons cela « migration ». Une migration mal préparée peut entraîner une baisse significative de votre trafic organique. Dans ce guide, je vais partager comment vous pouvez passer à travers le processus de migration de votre site de la manière la plus transparente possible.

Pourquoi devez-vous migrer votre site web ? Il peut y avoir une ou plusieurs raisons à cela. Tout d’abord, jetons un coup d’œil aux types de migration.

1. Changement de domaine :
   Vous souhaitez peut-être déplacer votre site x.com vers y.com

2. Changement de structure d’URL :

Les URLs comportant des mots en rapport avec le contenu et la structure de votre site sont plus conviviales pour les visiteurs qui naviguent sur votre site. Si les urls du site ne sont pas adaptées au SEO, vous pouvez les modifier.

3. Migration HTTP > HTTPS :
   La sécurité est une priorité absolue pour Google. Si vous faites migrer votre site de HTTP à HTTPS, Google considère qu’il s’agit d’un déménagement de site avec modification des URLs. Cela peut affecter temporairement certains de vos chiffres de trafic.
4. Changement de plate-forme :
   La plateforme du site est ce sur quoi notre site est construit. Vous pouvez avoir créé votre site sur WordPress, Shopify, Wix ou toute autre plateforme. Vous pouvez également avoir un site personnalisé créé par une équipe de développement. Vous pouvez souhaiter passer à une meilleure plateforme. Lorsque vous changez la plateforme sur laquelle votre site est construit, il faut tester les fonctions SEO de votre nouvelle plateforme.
5. Changements de structure et de hiérarchie :
   Votre site Web peut commencer à servir dans un domaine complètement différent. Ou bien l’URL et la structure des catégories de votre site ne sont peut-être pas adaptées au SEO. Quelle que soit la raison, nous pouvons commencer à travailler sur un site entièrement nouveau.
6. Changement de serveur :
   Les migrations de serveur présentent un risque principalement en termes de vitesse de chargement des pages. La vitesse du site est un facteur de positionnement SEO, mais surtout une question d’expérience utilisateur et de taux de conversion. Vous pouvez penser à mettre en place un site d’essai sur le nouveau serveur et à y tester la vitesse des pages. N’oubliez pas non plus de vérifier les redirections pour vous assurer qu’elles se comportent comme prévu.
7. Migration séparée du site mobile :
   Google recommande le Responsive Web Design comme modèle de conception car il est le plus facile à mettre en œuvre et à maintenir. Vous pouvez donc prévoir de rediriger votre version m-dot vers la version responsive principale. Il est absolument nécessaire de procéder à une redirection à cet endroit. C’est quelque chose qui devrait être assez simple et qui devrait être assez facile à faire.

Si toute la structure reste la même, seul le domaine change (1er type de migration), il est possible de dire que notre travail est facile. Dans les autres types de migration ou lorsque plusieurs types de migration sont combinés, les choses peuvent être plus compliquées.

Il existe des dizaines d’exemples qui ont connu une perte de trafic massive pendant la migration.

Quelques erreurs qui causent des pertes de trafic lors de la migration d’un site :

• Manque de planification
• Faible connaissance du SEO et de l’UX
• Faible budget
• Problèmes de redirection
• Erreurs de mapping d’URL
• Erreurs de crawling
• Ne pas intervenir sur les erreurs instantanées

Pour ne pas rencontrer ces problèmes, vous trouverez la bonne stratégie de planification et les points à prendre en compte dans la suite de l’article.

Avant de commencer, je tiens à vous mettre en garde contre certaines choses :

• ! Google ne recommande pas d’apporter des modifications à la fois au design et à la structure de l’URL en même temps. Si possible, il est utile d’effectuer ces deux ou plusieurs types de migration à des moments différents, étape par étape.
• ! Si le site est déplacé vers un domaine différent, il convient d’examiner l’historique de la nouvelle adresse de domaine. Les outils de recherche et d’audit Archive.org, « yoursite.com » fonctionnent. S’il existe un enregistrement de domaine ou un site établi auparavant, il faut le reconsidérer. Installer un domaine avec une entité de marque dans Google, qui a été exposé à des problèmes tels que des liens de spam ou de piratage, ou en servant sur un sujet complètement différent, fera perdre une grande partie du trafic.
• ! Dans certains cas, même si la planification et la mise en œuvre de la migration se déroulent sans problème, il est possible que le trafic organique diminue de 15 % ou plus. Étant donné qu’il y a un changement important dans la structure du site, Google réapprend et évalue chaque page une par une. Cette période est généralement de quelques semaines mais peut être plus longue pour les grands sites. Si tout se passe bien, votre trafic organique reprendra un élan positif dans un délai très court après cette évaluation.
• ! Le site ne doit pas être fermé aux utilisateurs pendant ou avant la migration. Si un changement de conception ou de structure doit être effectué, vous pouvez annoncer cette information à votre public à l’avance avec des méthodes simples. (Carrousel, e-mail, SMS, notification push, etc.) Les pages avec des codes d’état différents ou des messages d’avertissement peuvent être interprétées négativement par Googlebot.
• ! Le moment de la migration (lancement de la nouvelle structure) doit se situer dans le fuseau horaire où le site web reçoit le moins de trafic. De cette façon, en cas de problèmes indésirables, le nombre de personnes qui seront touchées sera maintenu à un niveau minimum. En outre, pendant ces heures où la charge du serveur est faible, Googlebot parcourra et indexera le nouveau site plus rapidement.

[Étude de cas] Optimiser le SEO après une refonte de site web

Un an après la refonte de leur site web, EasyCash ont réalisé que la performance qu’ils avaient visée n’était pas au rendez-vous. Ils ont ainsi identifié et résolu différents points SEO bloquants.

Lire l'étude de cas

Planification et collecte de données

Un plan de projet qui ne saute aucune étape garantit que le travail progresse sans erreur. Lorsque le plan de travail est déterminé, la répartition des tâches devient claire. Ce plan doit être établi au moins 30 jours avant la migration.

Il est important de conserver des données actualisées sur les visiteurs. En fonction de la taille de votre projet web, il est nécessaire de regrouper les pages et les requêtes ayant le plus fort trafic.

Conseil : conserver les fichiers journaux couvrant 45 jours avant la date de migration vous permet d’analyser le comportement de Googlebot et de prendre des mesures immédiates en cas de différence.

Créer un site de test et interdire l’accès

Le processus de migration commence par des wireframes pour les SEOs. Si les wireframes sont vérifiés et que les commentaires des SEO sont faits pendant la création des wireframes, les changements à faire dans le site de test sont réduits. Cela permet au projet d’avancer plus rapidement. Cela facilite également le travail des concepteurs UX/UI.

Il est également important de désactiver l’accès des robots au site de test. Sinon, vous pouvez faire l’expérience que vos nouvelles pages sont incluses dans l’index de Google en un temps très court.

Comment interdire l’accès aux robots des moteurs de recherche par le fichier robots.txt ?

Créez un fichier robots.txt : Vous pouvez créer un fichier nommé test.exemple.com/robots.txt et exécuter les commandes suivantes :

——

Agent utilisateur : *
Disallow : /
# Cette commande empêche tous les robots d’accéder à mon site Web.

——

Agent utilisateur : Oncrawl
Autoriser : /
# Cette commande permet uniquement au « bot Oncrawl » d’accéder à mon site web.

—–

Il est possible de décider des bots à tester et de définir la trace de l’agent utilisateur par le biais du fichier robots.txt. Oncrawl dispose de fonctionnalités qui vous faciliteront grandement la tâche.

Restriction d’IP : Si vous êtes impliqué dans le plan de migration du site web d’une entreprise, vous pouvez ouvrir l’accès uniquement à l’IP de l’entreprise et désactiver l’accès à toutes les autres IP afin d’éviter que le nouveau projet ne soit exposé. Dans ce cas, vous devrez donner un accès à l’IP privé à l’agence ou aux consultants avec lesquels vous travaillez, le cas échéant. Même si vous faites la restriction d’IP, vous devez interdire les bots par le fichier robots.txt.

Protection par mot de passe : Une combinaison d’identifiant et de mot de passe peut être créée pour entrer sur le site de test. Les applications de crawling telles qu’Oncrawl ont des fonctions d’accès par mot de passe.

Balise noindex : Une balise méta noindex peut être ajoutée à la section head de toutes les pages afin d’empêcher les pages du site de test d’être indexées par Google.

Conseil : L’une des erreurs les plus courantes est d’oublier de supprimer la balise noindex après la migration vers le nouveau site Web. N’oubliez pas de confirmer que les balises sont mises à jour en index, follow au moment de la migration.

Suivi des performances avec Google Analytics

L’un des points les plus importants pour le suivi des performances est de continuer à partir du même compte Google Analytics sans perte de données. Par conséquent, le code GA et GTM existant doit être actif sur le nouveau site lors de la migration.

La génération d’un nouveau code GA rend plus difficile la mesure de vos performances web.

En ajoutant un rappel à votre tableau de bord Google Analytics le jour du déménagement, il vous sera plus facile de comparer les performances par la suite.

Création d’une liste d’URL existante

J’ai mentionné au début de mon article que si nous ne faisons que changer notre nom de domaine, notre travail est facile. Nous pouvons appliquer cela en masse à partir du fichier .htaccess avec le code suivant ou un code similaire.

* Le fichier .htaccess est un fichier de configuration situé sur les serveurs Apache.

RewriteEngine On RewriteCond %{HTTP_HOST} ^oldsitee\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.newsite\.com$
RewriteRule (.*)$ https://newsite.com/$1 [R=301,L]

Ce jeu de règles garantit que l’adresse du domaine est automatiquement redirigée vers https://newsite.com lorsqu’une url est atteinte sur oldsite.com ou www.oldsite.com.

Cependant, si votre travail consiste à corriger une structure d’URL incorrecte, les choses se compliquent ici. J’ai expliqué cette situation plus loin dans l’article.

Nous sommes maintenant à l’un des points les plus importants du processus de migration. Il est essentiel d’obtenir la liste complète des URLs importantes du site actuel. Si vous oubliez une URL ayant beaucoup de visiteurs et un PageRank élevé, et que vous la laissez en dehors de la migration, préparez-vous à une baisse de votre trafic organique.

Conseil : en exportant les URLs à partir de plusieurs sources, vous pouvez vous assurer qu’aucune URL n’est oubliée.

Commencer par le plan Sitemap XML est toujours la bonne démarche. Pour transférer simplement les URLs de votre fichier XML sur la feuille de calcul, vous pouvez copier le lien ici et écrire votre propre url sitemap à la place de https://www.sinanyesiltas.com/post-sitemap.xml dans la première ligne.

• Toutes les URLs avec impression dans Search Console,
• Toutes les URLs avec des pages vues dans Google Analytics,
• Toutes les URLs obtenues à la suite d’un crawling avec Oncrawl,
• L’utilisation de plusieurs outils de crawling tiers permet de s’assurer que le travail est clair. Il est essentiel de s’assurer qu’aucune URL n’est oubliée en tirant parti des différentes fonctionnalités de chaque application d’exploration.
• Il est important d’inclure ici les pages qui ont déjà obtenu des liens. Pour cela, il est nécessaire de découvrir les pages liées à travers les outils Search Console, Ahrefs, Semrush et Majestic et de les ajouter au même document.

Après avoir obtenu toutes les URLs, vous aurez des données groupées similaires à celles ci-dessous dans un seul document Excel.

Nous avons obtenu plusieurs feuilles Excel différentes avec les URLs disponibles. Il est temps de les combiner dans un seul fichier et de le rendre unique. Nous continuons notre chemin avec un document où il n’y a pas d’URLs correspondantes, vos URLs actuelles sont listées et aucune URL importante n’est oubliée. L’onglet ALL dans l’image représente la zone dont je parle.

Mapping des URLs (Mapping des anciennes et nouvelles URLs)

Dans le projet où la structure de l’URL a changé, les URLs existants doivent être mis en correspondance avec les nouvelles URLs. Un SEO qui fera cela de la meilleure façon peut s’assurer que le processus de migration se déroule en douceur et sans perte.

Il est nécessaire de faire correspondre la nouvelle URL avec chacune des URLS existantes dans le document que nous avons créé à l’étape précédente. Vous pouvez partager directement ce document que vous allez compléter avec l’équipe informatique, et demander l’identification des redirections via le fichier .htaccess. Ou vous pouvez le faire vous-même.

Il y a des éléments critiques à prendre en compte dans cette étape :

• La redirection 301 côté serveur doit être utilisée dans les redirections à appliquer. Ce type de redirection redirige en permanence la page X vers la page Y et garantit que toutes les valeurs de la page X sont transférées vers la page Y. L’utilisation de 302, 307, JS, Meta ou d’autres types de redirection est une erreur très critique dans le processus de migration.
• N’incluez pas dans votre fichier de mappage d’URL les URL qui n’ont pas de visiteurs, dont le contenu est médiocre et qui, selon vous, nuisent à votre budget de crawl. N’oubliez pas que Google a réservé un espace pour votre site dans son centre de données et que vous devez utiliser cet espace avec vos pages les plus efficaces. Si vous avez identifié un groupe de pages inutiles, faites en sorte que ces pages répondent avec le code d’état 410.
  Pourquoi 410 ? Le code d’état 410, contrairement au code 404, indique que cette page est maintenant supprimée et qu’elle ne sera plus active. Si vous utilisez le code d’état 404, Googlebot visite votre serveur pour vérifier si la même page est à nouveau active. En éliminant ces visites, 410 est une solution importante pour utiliser efficacement votre budget de crawl.
• Ne redirigez pas plusieurs pages vers une seule page en bloc. Cela crée une confusion tant pour les utilisateurs que pour les robots. Au lieu d’appliquer une redirection 301 en masse pour les pages que vous n’utilisez pas et que vous trouvez improductives, examinez la solution 410.
• Si vous êtes dans le processus de migration d’un site de e-commerce avec des milliers de pages, il n’est pas possible de préparer un mapping un à un pour chaque URL. Dans ce cas, vous pouvez guider votre équipe informatique en préparant des modèles.

Redirections d’images

Les images sont également incluses dans les mappages de migration et de redirection de sites. L’une des erreurs les plus courantes que nous voyons est que les orientations des images ne sont pas incluses dans la migration. Afin de ne pas perdre les classements et les valeurs obtenus dans Google Images, il est important de préparer un mappage d’URL distinct pour les images. Le travail de migration doit être envisagé en fonction des URL et non des pages.

Comment procéder ?

• Explorez vos fichiers d’images avec Oncrawl.
• Vous pouvez analyser vos sources d’images qui obtiennent des backlinks avec Ahrefs, Semrush et Majestic.
• Vous pouvez analyser les pages contenant vos images via Search Console > Search Type > Image.
• Rassemblez toutes les URLs que vous obtenez dans le même format excel que nous avons fait pour les pages, éliminez les doublons et terminez votre configuration de mapping.

(Si le domaine change) Google Address Change Tool

Après avoir effectué tout le travail préliminaire et activé les redirections, il existe un outil qui nous permet de spécifier le déménagement du site à Google et qui facilite les choses : Address Change Tool. Les signaux seront traités en moins de temps après avoir sélectionné l’ancien site et les nouveaux sites dans cet outil.

• La propriété de la Search Console est requise pour l’ancien site et le nouveau site.
• Le changement d’adresse est uniquement utilisé pour les changements de domaine. Il n’est pas disponible pour les changements d’url de sous-dossier ou les migrations HTTP > HTTPS.
• Dans cet outil de changement, il est nécessaire de traiter chaque sous-domaine séparément, le cas échéant.
• Lorsque ces conditions sont remplies, le processus peut être lancé en sélectionnant l’ancien et le nouveau site avec l’outil de changement d’adresse de Google.

Mise à jour des liens

Le site Web aura désormais une nouvelle structure d’URL. Dans ce cas, tous les liens du site devraient fonctionner dans la nouvelle version. Si les anciennes URL continuent à être utilisées dans les liens du site, de nombreuses redirections inutiles fonctionneront. Par conséquent, les liens suivants doivent être vérifiés :

• Tous les liens internes de la page
• Balises canoniques
• -S’il y en a – Balises Hreflang
• -S’il y en a – Balises alternatives
• -S’il y en a – Liens HTML Sitemap
• Liens vers les profils de médias sociaux
• Liens de page d’atterrissage utilisés dans les campagnes publicitaires

Conseil : si vous avez modifié l’ensemble de votre structure d’URL, je vous recommande de conserver votre fichier sitemap XML avec les anciennes URLs pendant un certain temps. Créez un sitemap XML distinct avec votre nouvelle structure d’URL. Continuez à envoyer les anciennes URLs à Googlebot pendant un certain temps. De cette façon, Googlebot accélérera le processus de visualisation et d’indexation de la redirection sur les anciennes URLs. En fonction de la taille du site, je recommande de garder votre fichier sitemap XML actif depuis au moins 1 mois.

Contrôler

Après l’application des redirections, il est nécessaire de confirmer que le code de statut de chaque URL est 301 en crawlant les anciennes URL obtenues auparavant. Ici, il est très important de prendre des mesures rapides lorsque des URL avec un code de statut autre que 301 sont détectées.

Autres points de contrôle à surveiller :

• Le fichier Robots.txt
• Code de suivi de Google Analytics
• Contrôle de vérification de Search Console (si le domaine a changé, il faut continuer avec 2 domaines différents, l’ancien et le nouveau)
• Balise Meta (noindex, follow)
• Balise canonique

Notez également ceci :

• Si possible, les fournisseurs de backlinks doivent être contactés et les anciens liens doivent être remplacés par de nouveaux. S’il existe un vaste réseau de backlinks, on peut établir un planning par ordre d’importance et ne contacter que les plus importants.
• Les pages d’atterrissage utilisées dans les campagnes publicitaires doivent être revues ou les équipes concernées doivent être informées.
• En crawlant le nouveau site, il convient de vérifier si tous les liens fonctionnent correctement, et si une boucle de redirection se produit dans le site, il faut intervenir immédiatement.
• Les liens dans les profils de médias sociaux doivent être mis à jour.
• L’indexation des nouvelles pages doit être suivie.
• Les performances des mots-clés doivent être contrôlées.
• Les redirections 301 ne doivent pas être désactivées de sitôt, elles doivent toujours rester actives.
• Si le domaine a été changé, l’ancien domaine doit être conservé pendant au moins deux années supplémentaires.
• Les anciennes données (URLs, logs, performances des mots-clés, etc.) doivent être conservées pendant un certain temps.
• Si un fichier de désaveu est installé sur l’ancien site, il doit également être téléchargé sur le nouveau domaine.

Google s’occupe de la configuration du routage entre l’ancien et le nouveau site pendant 180 jours. Après cette période de 180 jours, il ne reconnaît plus aucune association entre l’ancien et le nouveau site et traite l’ancien site comme un site non pertinent s’il est toujours présent et explorable.