03 octobre 2020
10minutes

Comment ne pas perdre son référencement SEO pendant la migration de son site ? Les check-lists à vérifier pour garder et augmenter son trafic

La migration d’un site en dehors des règles de l’art du SEO provoque une perte d’une quantité de trafic qualifié. Qui plus est, une migration de site mal mise en œuvre détruit rapidement la visibilité d’une marque dans les SERPs. La liste de contrôle SEO suivante aide à établir un plan de migration SEO en béton. Prêt ? Allons-y.

 

L’importance du Plan de redirection

 

Un petit rappel sur la redirection, ça ne fait pas de mal !

Une redirection est un message qu’un site web envoie à un navigateur en indiquant que la page web demandée a été déplacée de manière à ce que le navigateur le dirige automatiquement vers la nouvelle version. Trois types de redirections les plus utilisés :

  • 301 : redirection permanente, la plus importante
  • 302 : redirection temporaire
  • META Refresh : Là où les meta data vont s’actualiser via la balise META http-equiv= « Refresh »

 

Cette étape est ultime pour un référencement SEO assuré. Le plan de redirection ou redirection mapping est un processus servant à identifier l’URL de destination de chaque page du site existant après sa mise en ligne. Il s’assure que le netlinking (dofollow, nofollow, noindex), les classements et le trafic vers une URL soient captés et donnent lieu à des visites sur le nouveau site migré. Bien entendu, toute URL manquante ou inexistante affichera l’erreur 404, et mettra fin à la navigation de l’utilisateur.

 

Redirection 301 : un indice de réussite d’une migration

Parce que son utilité est de plusieurs formes :

  • Maintien de l’intérêt du visiteur et aide à stopper la perte de trafic. Une page 404 aura un effet négatif sur l’User eXperience du visiteur. Google veut leur fournir des contenus de valeur, pas des pages d’erreur. Ceux-ci conduisent à une forte baisse du PageRank et de trafic organique.
  • Amélioration de la structure des URL : possibilité de passer d’une URL malcommode comme com/produit/?category=4 à une alternative plus conviviale, plus accessible et facile pour la recherche comme domaine.com/produit/chaussure. C’est la technique d’URL Rewriting détaillée plus bas.

 

Migration de site : Redirection 301

 

Élaborer une carte de redirections d’URL en 6 étapes clefs

La meilleure pratique consiste à analyser et à prendre en compte la valeur SEO de l’ensemble du site à migrer et à rediriger chaque URL vers la page la plus pertinente de la nouvelle version. Après tout, une carte de redirection bien exécutée ne se contentera pas de maintenir une position organique après le lancement, mais l’améliorera.

 

Règle de réécriture d’URL sous le serveur web et proxy open source NGINX

 

À noter que la mise en œuvre d’une stratégie de redirection 301 est plus longue et plus complète qu’un simple article, mais il s’agit d’une tâche technique essentielle de référencement. Nous savons le faire.

Voici donc les points clefs :

#1 Rassembler les URL à conserver et à mettre à jour sur la nouvelle version du site. Ça peut être :

    • du contenu qui s’aligne avec la stratégie commerciale déjà mise en place ou les indicateurs clés de performance du site
    • des URL affichant un taux de visualisation élevé des home pages organiques dans Google Analytics
    • des URL avec des backlinks du métrique Domain Authority. Ahrefs / SEMrush peuvent vous aider.

#2 Planifier une date à laquelle aucun nouveau contenu ne doit être produit. Le contenu existant doit être modifié sur le site actuel.

#3 Après cette date, parcourir le site existant à l’aide d’un outil de crawling comme Screaming Frog. Les techniques de sitemaps XML peuvent également servir.

#4 Mettre en correspondance les URL sources et les URL cibles. Constituer un alignement dans un tableur de 5 colonnes :

    • Colonne 1 : URL actuel
    • Colonne 2 : Nouveaux URL
    • Colonne 3 : Titre : Méta titre de la page.
    • Colonne 4 : Sessions organique dans Google Analytics : nombre de sessions organiques. Cela va hiérarchiser les pages qui doivent être redirigées.
    • Colonne 5 : Notes pour inscrire les problèmes potentiels, par exemple si un contenu important n’est pas transféré vers un nouveau site ou si la chaîne de l’URL doit être modifiée.

#5 Obtenir un aperçu du plan de la version du site web

#6 S’assurer que chaque URL existant se dirige vers une page de redirection sur le nouveau site. Aucune erreur 404. Pour un nom de domaine ou une structure d’URL intactes, une redirection peut être futile.

 

Déroulement d’une migration SEO chez la plateforme BrightEdge

 

La redirection d’un site sous le CMS WordPress, par exemple, peut être gérée de deux manières distinctes : via le fichier .htaccess ou des plug-ins de redirection comme Redirection, WP 404 Auto Redirect to Similar Post.

Un site volumineux peut entraîner des contraintes temps. Il y a également les problèmes d’excès de redirections, d’où le déploiement via un fichier .htaccess utilisant des règles du regex est la seule façon d’atténuer l’impact sur la vitesse des pages.

 

Vérification des redirections avant la publication

Vérifier que toutes les redirections pointent vers la bonne URL. Une opération réussie renvoie une montée en liste de messages moved permanently correspondant au code de réponse HTTP 301. L’étape suivante consiste alors à les extraire et à les comparer à la cartographie originale. Tous les 404 identifiés dans le crawl doivent être exportés et redirigés soit vers l’URL correcte contenue dans la carte originale, soit vers la page d’accueil.

Il y a l’extension Chrome Redirect Path pour déterminer si la redirection a été correctement mise en place.

 

URL REWRITING : une gestion complexe des URL

 

Mettre en place la réécriture d’URL ou URL rewriting dépend du serveur web.  Chez Apache, le principal outil pour gérer la redirection d’URL est mod_rewrite. C’est un outil puissant à tel point qu’il est utilisé abusivement : excès de réglage et de tests par rapport à de multiples expressions regex. Dans une logique de performance et de référencement SEO, le moins de règles possible est la clé, en gardant le cycle de réécriture court et en permettant au serveur d’envoyer en un éclair une réponse, qu’il s’agisse d’une redirection ou du contenu réel.

 

Réécrire l’URL uniquement dans le cycle de réécriture

Réécrire, mais ne pas rediriger immédiatement. Procéder d’abord à un rewriting interne en changeant l’ancien chemin d’accès pour le chemin d’accès mis à jour.

Ensuite, faire un test de plusieurs règles qui font des redirections 301 basées sur le mot-clef dans l’URL.

Traiter les mises à jour de l’architecture de l’information. Une fois de plus, mettre à jour l’URL interne vers le nouveau chemin pour simplifier la correspondance de ces cas dans les règles de rewriting. À ce stade, vous pouvez maintenant procéder à la redirection des pages vers leur cheminement actualisé avec une seule règle.

Pour finir, la réorientation. Les règles de rewriting sont lues de haut en bas. Pour les redirections, il est crucial de court-circuiter le cycle dès qu’une correspondance est trouvée. Si une règle correspond, l’URL est réécrite et une redirection est émise, ce qui mène à la sortie du cycle.

La prochaine fois où il va falloir gérer des règles de rewriting complexes, il est important de voir si le rewriting interne de l’URL pendant le cycle de réécriture va éviter les chaînes de redirections.

 

Quelles versions d’URL doit-on déclarer à Google Search Console ?

 

Au terme d’une migration de site CMS ou HTML, il est impossible de passer à côté de données techniques gratuites sur les performances du nouveau site dans les SERP. Il faut configurer correctement toutes les versions du domaine du site migré comme étant property dans la page Google Search Console, l’outil gratuit d’indexation d’un site web de Google.

Supposons que le nom de domaine du site nouvellement migré soit eficiens.com. Un nom de domaine mieux référencé que le précédent.

#1 Ajouter donc com et www.eficiens.com (même s’il n’y aucune redirection vers www) en tant que nouvelles propriétés distinctes.

#2 Ajouter aussi le protocole https:// pour chacune des deux variations.
Pour un site web sur son propre domaine et servi uniquement le protocole HTTP, il faut au minimum deux versions de domaine dans la console. Et quatre versions pour un site servi uniquement par le protocole HTTPS.

 

Si le site web comporte des sous-domaines / sous-répertoires, il faut les renseigner séparément dans la console afin d’obtenir davantage de données, de fixer des objectifs géographiques ou de définir des plans de site.

 

Notez que cela concerne aussi les sous-domaines « non-indexables » comme les serveurs de staging ou qui n’ont pas de données disponibles de la même façon que les sous-domaines des sessions admin. De cette manière, Google Search Console peut fournir des données supplémentaires spécifiques et détaillées liées à la recherche, telles que les données de l’analyse de recherche.

#3 Rendre les données plus utiles. Car devant les variations de liens ajoutées précédemment en tant que property dans la console, il peut être confus de déterminer quelle propriété doit être vérifiée pour servir de données de positionnement à Google Analytics. C’est l’utilité de la fonctionnalité property set ou « ensemble de propriétés ». Son rôle est d’encapsuler dans cet ensemble toutes les propriétés inscrites qui méritent d’être vérifiées.

#4 Garder une empreinte des URL de mise en scène dans le but d’éviter leur indexation.

#5 Poursuivre la création de nouveaux property set dans Google Search Console, si cela fait sens pour le nouveau site. Ces ensembles de propriétés n’affichent pas les données de manière rétroactive. En effet, la collecte de données débute uniquement après que celles-ci ont été créées, et plusieurs jours peuvent s’écouler avant que les premières données ne soient disponibles pour le visiteur.

 

Il est également possible de télécharger les données via un API et de faire passer le référencement au niveau supérieur, mais une chose est vitale si vous avez changé de nom de domaine… la migration de DNS.

 

Stratégie pour minimiser les problèmes de migration de DNS

 

Le DNS (Domain Name Service) est « la colle » qui maintient la présence en ligne d’un site migré. Dans le monde du business, la résolution DNS massivement redondante, évolutive et géographiquement diversifiée est à la fois une fonction essentielle et plus économiquement externalisée.

Pour maintenir une expérience utilisateur cohérente lors de la migration de DNS, il est judicieux d’utiliser deux fournisseurs simultanément, et de ne désactiver l’ancien service que lorsque le DNS est proprement opérationnel chez le nouveau provider.

 

Les questions relatives à la mise en cache du DNS

Les migrations DNS sont extrêmement délicates. Chaque fois qu’une réponse DNS est envoyée en tant que réponse à la demande d’un visiteur, cette information est mise en cache sur un serveur de noms récursif situé à proximité du réseau, chez le FAI de l’utilisateur par exemple.

Et la durée de mise en cache d’un enregistrement par un serveur récursif est déterminé par le Time to Live (TTL) fixé par le propriétaire du site web.

Quant aux enregistrements de serveur de noms, cela peut prendre des heures, voire des jours.

Assurer que l’enregistrement A / NS / CNAME approprié est établi pour le domaine source et le domaine cible dans le DNS public en vérifiant auprès de votre bureau d’enregistrement de domaine :

  • Si un domaine doit pointer directement vers votre serveur, ajouter un enregistrement A avec l’adresse IP du serveur.
  • Pour créer une association indirecte, de sorte que le domaine pointe vers certains serveurs de noms, qui renvoient à leur tour vers l’adresse IP du serveur, ajouter des enregistrements NS avec les adresses des name server.
  • Si votre domaine est un alias d’un autre domaine, ajouter un enregistrement CNAME valide avec le nom du domaine primaire.

 

Primo, s’assurer que l’ancien et le nouveau provider fournissent des enregistrements DNS identiques pour le nouveau nom de domaine.

Secundo, lors de la migration, le nouveau et l’ancien provider DNS doivent maintenir le nom de domaine opérationnel pendant au moins le TTL maximum après que les enregistrements NXRRSet aient été soumis comme faisant autorité pour le domaine. Ce n’est qu’après s’être assuré que les TTL ont expiré – et que les anciennes données des serveurs de noms en cache ont été supprimés – que vous devez supprimer vos anciens serveurs de noms. 7 à 10 jours est une bonne règle empirique.

Tertio, faire attention lors de la migration d’une zone migrée DNSSEC. Cette norme sert de validation des domaines signés sur la base d’une hiérarchie de clés cryptographiques stockées dans les zones allant de la vôtre à la racine du DNS elle-même. Les clés doivent être renouvelées régulièrement, afin de minimiser les risques compromis par les attaquants.

Dans les cas où la zone à migrer est signée DNSSEC, le timing est primordial. Les enregistrements de signatures ont une date d’expiration incorporée, distincte du Time to Live de l’enregistrement.

 

 

Vous avez aimé ? Notez-nous !