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.
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 :
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.
Parce que son utilité est de plusieurs formes :
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.
À 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 :
#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 :
#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.
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é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.
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, 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.
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.
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 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 :
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.
Une migration, ce n’est pas qu’une série d’actions techniques sur les DNS et fichiers de re-directions. C’est aussi une surveillance qui doit s’établir dans le cadre de la maintenance de votre site web pendant une durée minimale de 6 mois. Vous constaterez alors progressivement comment Google migre votre site URL par URL. Et vous pourrez ainsi corriger les problèmes si besoin.