Migration de site Web : stratégie de référencement et meilleures pratiques

Vous devrez peut-être migrer votre site Web/entreprise pour une raison spécifique. En tant que référenceurs, nous appelons cela « migration » ou « déplacement de site ». 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.

Pourquoi avez-vous besoin de migrer votre site Web ? Il peut y avoir une ou plusieurs raisons à cela.

Examinons d'abord les types de migration

1. Changement de domaine :
   Vous voudrez peut-être déplacer votre site x.com vers y.com
2. Modification de la structure de l'URL :
   Les URL contenant des mots pertinents pour le contenu et la structure de votre site sont plus conviviales pour les visiteurs qui naviguent sur votre site. Si les URL du site ne sont pas optimisées pour le référencement, vous pouvez les modifier.
3. Migration HTTP > HTTPS :
   La sécurité est une priorité absolue pour Google. Si vous migrez votre site de HTTP vers HTTPS, Google traite cela comme un déplacement de site avec des modifications d'URL. Cela peut temporairement affecter certains de vos numéros de trafic.
4. Changement de plate-forme :
   La plate-forme du site est ce sur quoi notre site est construit. Vous auriez pu créer votre site Web sur WordPress, Shopify, Wix ou toute autre plateforme. En outre, vous pouvez avoir un site personnalisé créé par une équipe de développement. Vous voudrez peut-être passer à une meilleure plateforme. Lors du changement de plate-forme sur laquelle votre site est construit, nous devons tester les fonctions de référencement de votre nouvelle plate-forme.
5. Modifications de la structure et de la hiérarchie :
   Votre site Web peut commencer à servir dans un domaine complètement différent. Ou l'URL et la structure des catégories de votre site peuvent ne pas être optimisées pour le référencement. Quelle que soit la raison, nous pouvons commencer à travailler sur un tout nouveau site.
6. Changement de serveur :
   Les migrations de serveur présentent des risques principalement en termes de vitesse de chargement des pages. La vitesse du site est un facteur de classement SEO, mais plus important encore, c'est un problème d'expérience utilisateur et de taux de conversion. Vous pouvez envisager de configurer un site intermédiaire sur le nouveau serveur et de tester la vitesse des pages dessus. N'oubliez pas non plus de vérifier les redirections pour vous assurer qu'elles se comportent comme prévu.
7. Migration distincte du site mobile :
   Google recommande le Responsive Web Design comme modèle de conception, car il est le plus facile à mettre en œuvre et à entretenir. Vous pouvez donc prévoir de rediriger votre version m-dot vers la version responsive principale. Faire une redirection là-bas est absolument la bonne chose. C'est quelque chose qui devrait être assez simple et devrait être assez facile à faire.

Si toute la structure reste la même, seul le domaine change (1er type de migration), on peut dire que notre travail est facile. Dans d'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 subi une perte de trafic massive pendant la migration.

Certaines erreurs qui entraînent une perte de trafic lors du déplacement d'un site :

1. Manque de planification
2. Faible connaissance SEO et UX
3. Petit budget
4. Problèmes de redirection
5. Erreurs de mappage d'URL
6. Erreurs d'exploration
7. Ne pas interférer avec les erreurs instantanées

Afin de ne pas rencontrer ces problèmes, vous trouverez la bonne stratégie de planification et les points à considérer dans la suite de l'article.

Avant de commencer, je tiens à vous avertir de quelques points :

• ! Google déconseille de modifier simultanément la conception et la structure de l'URL. 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, l'historique de la nouvelle adresse de domaine doit être étudié. Archive.org, les outils de recherche et d'audit "votresite.com" fonctionneront. S'il y a un enregistrement de domaine ou un site établi auparavant, il doit être reconsidéré. L'installation d'un domaine avec une entité de marque dans Google, qui a été exposée à des problèmes tels que des liens de spam ou de piratage, ou en servant sur un sujet complètement différent, entraînera la perte d'une grande partie du trafic.
• ! Dans certains cas, même si la planification et la mise en œuvre de la migration se font sans aucun problème, il est possible que le trafic organique diminue de 15 % ou plus. Comme il y a un changement de structure important sur le 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 prendra un élan positif en très peu de temps après cette évaluation.
• ! Le site ne doit pas être fermé aux utilisateurs pendant ou avant la migration. Si une modification de conception ou de structure doit être apportée, 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 de statut ou des messages d'avertissement différents 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 reçoit le moins de trafic. De cette façon, en cas de rencontre de problèmes indésirables, le nombre d'audiences qui seront affectées sera maintenu à un niveau minimum. De plus, pendant ces heures où la charge du serveur est faible, Googlebot explorera et indexera le nouveau site plus rapidement.

[Étude de cas] Empêchez votre refonte de pénaliser votre référencement

Un an après la refonte de leur site internet, EasyCash s'est vite rendu compte que les performances qu'ils espéraient n'étaient pas au rendez-vous. Ils ont identifié et résolu plusieurs obstacles au référencement.

Lire l'étude de cas

Planification et collecte de données

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

Il est important de conserver les données actuelles des visiteurs. Selon la taille de votre projet web, il est nécessaire de regrouper les pages et requêtes les plus fréquentées.

Conseil : conserver les fichiers journaux pendant 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

Le processus de migration commence par des wireframes pour les référenceurs. Si les wireframes sont vérifiés et que des commentaires SEO sont faits lors de la création des wireframes, les modifications à apporter dans le site de test sont réduites. 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 constater que vos nouvelles pages sont incluses dans l'index Google en très peu de temps.

Comment interdire les robots des moteurs de recherche par le fichier robots.txt ?

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

——

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

——

Agent utilisateur : OnCrawl
Permettre: /
# Cette commande permet uniquement au "bot OnCrawl d'accéder à mon site Web.

—–

Il est possible de décider avec quels robots tester et de définir la trace vers l'agent utilisateur via le fichier robots.txt. Oncrawl a des fonctionnalités qui rendront les choses beaucoup plus faciles.

Restriction IP : Si vous êtes impliqué dans le plan de migration du site Web d'une entreprise, vous pouvez uniquement ouvrir l'accès à l'IP de l'entreprise et désactiver l'accès à toutes les autres IP afin d'empêcher que le nouveau projet ne soit exposé. Dans ce cas, vous devrez donner un accès IP privé à l'agence ou aux consultants avec lesquels vous travaillez, le cas échéant. Même si vous effectuez la restriction 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 accéder au site de test. Les applications d'exploration telles que Oncrawl ont des fonctionnalités d'accès par mot de passe.

Balise Noindex : Une balise meta noindex peut être ajoutée dans la section head de toutes les pages afin d'empêcher que les pages du site de test soient indexées par Google.

Astuce : L'une des erreurs les plus courantes consiste à 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 pour indexer, suivre 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 avec la migration.

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

L'ajout d'un rappel à votre tableau de bord Google Analytics le jour du déménagement vous permettra de comparer plus facilement les performances ultérieurement.

Création d'une liste d'URL existantes

J'ai mentionné au début de mon article que si nous ne changeons que notre nom de domaine, notre travail est facile. Nous pouvons l'appliquer 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$ [OU]
RewriteCond %{HTTP_HOST} ^www\.nouveausite\.com$
Règle de réécriture (.*)$ https://nouveausite.com/$1 [R=301,L]

Cet ensemble de règles garantira que l'adresse de domaine sera automatiquement redirigée 301 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. Obtenir la liste complète des URL importantes pour le site actuel est essentiel. Si vous oubliez une URL avec beaucoup de visiteurs et un PageRank élevé, et que vous la laissez hors de la migration, préparez-vous à une baisse de votre trafic organique.

Conseil : En exportant des URL à partir de plusieurs sources, vous pouvez vous assurer qu'aucune URL n'est omise.

Commencer avec XML Sitemap est toujours la bonne étape. Pour transférer simplement les URL de votre fichier XML sur la feuille de calcul, vous pouvez copier le lien ici et écrire votre propre URL de sitemap au lieu de https://www.sinanyesiltas.com/post-sitemap.xml sur la première ligne.

• Toutes les URL avec impression dans la Search Console,
• Toutes les URL avec pages vues via Google Analytics,
• Toutes les URL obtenues suite au crawl avec Oncrawl,
• Aller de l'avant en utilisant plusieurs outils d'exploration tiers garantit que le travail est clair. Il est essentiel de s'assurer qu'aucune URL n'est omise en profitant des différentes fonctionnalités de chaque application de crawling.
• 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 via les outils Search Console, Ahrefs, Semrush et Majestic et de les ajouter au même document.

Après avoir obtenu toutes les URL, vous aurez une donnée groupée similaire à celle ci-dessous dans un seul document Excel.

Nous avons de nombreuses feuilles Excel différentes avec les URL disponibles. Il est temps de les combiner tous en un seul fichier et de le rendre unique. Nous continuons notre chemin avec un document où il n'y a pas d'URL correspondantes, vos URL actuelles sont répertoriées et aucune URL importante n'est laissée de côté. L'onglet ALL dans l'image représente la zone dont je parle.

Mappage d'URL (ancien - nouveau mappage d'URL)

Dans le projet où la structure de l'URL a changé, les URL existantes doivent être mises en correspondance avec les nouvelles URL. Un référencement qui le fera de la meilleure façon peut garantir que le processus de migration se déroule sans heurts et sans perte.

Il est nécessaire de faire correspondre la nouvelle URL à chacune des URL existantes dans le document que nous avons créé à l'étape précédente. Vous pouvez directement partager ce document que vous compléterez 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 choses critiques à considérer dans cette étape:

• La redirection 301 côté serveur doit être utilisée dans les redirections à appliquer. Ce type de redirection redirige de manière permanente la page X vers la page Y et garantit que toute la valeur de la page X est transférée 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 les URL qui n'ont pas de visiteurs, un contenu médiocre et qui, selon vous, nuisent à votre budget d'exploration dans votre fichier de mappage d'URL. N'oubliez pas que Google a réservé un espace pour votre site dans son centre de données et 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 de statut 410, contrairement au 404, indique que cette page est maintenant supprimée et 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 de la confusion pour les utilisateurs et les bots. Au lieu d'appliquer un bloc 301 pour les pages que vous n'utilisez pas et que vous trouvez improductives, passez en revue la solution 410.
• Si vous êtes dans le processus de migration d'un site e-commerce avec des milliers de pages, il n'est pas possible de préparer un mappage 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 site. L'une des erreurs les plus courantes que nous constatons est que les orientations d'image 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 séparé pour les images. Le travail de migration doit être examiné en fonction de l'URL et non de la page.

Comment faire?

1. Explorez vos fichiers image avec Oncrawl.
2. Vous pouvez analyser vos sources d'images qui obtiennent des backlinks avec Ahrefs, Semrush et Majestic.
3. Vous pouvez analyser les pages avec vos images via Search Console > Type de recherche > Image.
4. Collectez toutes les URL que vous obtenez dans le même format Excel que nous avons fait pour les pages, éliminez les doublons et complétez votre configuration de mappage.

(Si le domaine change) Outil de changement d'adresse Google

Après avoir terminé tous les travaux préliminaires et activé les redirections, il existe un outil qui nous permet de spécifier le déplacement du site vers Google et facilite les choses : l'outil de changement d'adresse. Les signaux seront traités plus rapidement 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 et le nouveau site.
• Le changement d'adresse n'est utilisé que pour les changements de domaine. Non disponible pour les changements d'URL de sous-dossiers ou les migrations HTTP > HTTPS.
• Dans cet outil de changement, il est nécessaire de gérer 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 Google Changer d'adresse.

Mises à 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 d'ê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
• -Le cas échéant- Balises hreflang
• -Le cas échéant- Balises alternatives
• -Le cas échéant- Liens HTML vers le sitemap
• Liens de profil de médias sociaux
• Liens de page de destination utilisés dans les campagnes publicitaires

Conseil : Si vous avez modifié l'intégralité de votre structure d'URL, je vous recommande de conserver votre fichier de plan de site XML avec les anciennes URL pendant un certain temps. Créez un sitemap XML séparé avec votre nouvelle structure d'URL. Continuez à envoyer d'anciennes URL à Googlebot pendant un certain temps. De cette manière, Googlebot accélérera le processus de visualisation et d'indexation de la redirection sur les anciennes URL. En fonction de la taille du site, je recommande de garder votre fichier de plan de site XML actif au moins 1 mois.

Les contrôles

Une fois les redirections appliquées, il est nécessaire de confirmer que le code d'état de chaque URL est 301 en explorant les anciennes URL obtenues auparavant. Ici, il est très important d'agir rapidement lorsque des URL avec un code d'état autre que 301 sont détectées.

Autres points de contrôle à surveiller :

• Fichier robots.txt
• Code de suivi Google Analytics
• Contrôle de vérification de la Search Console (si le domaine a changé, il doit être poursuivi avec 2 domaines différents, ancien et nouveau)
• Balise META (noindex, follow)
• Balise canonique

Notez également ceux-ci :

• Si possible, les fournisseurs de backlinks doivent être contactés et les anciens liens doivent être remplacés par de nouveaux. S'il y a un gros réseau de backlinks, un planning peut être fait par ordre d'importance et seuls les plus importants pourront être contactés./li>
• Les pages de destination utilisées dans les campagnes publicitaires doivent être revues ou les équipes concernées doivent être informées.
• En explorant 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, une intervention immédiate doit être entreprise.
• 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 surveillées.
• Les redirections 301 ne doivent pas être désactivées de si tôt, elles doivent toujours rester actives.
• Si le domaine a été modifié ; L'ancien domaine doit être conservé au minimum 2 ans supplémentaires.
• Les anciennes données (URL, 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 gère la configuration du routage entre l'ancien et le nouveau site pendant 180 jours. Après la période de 180 jours, il ne reconnaît 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.