Réussir sa migration SEO

Crawl du site à date

En temps normal, il est toujours bon d’avoir une base de crawl de son site récente. Si ce n’est pas le cas, la migration est le bon moment pour se constituer une base de crawl récente. Elle servira :

A se constituer une base de mots clés
A comparer les KPI du site avant /après migration.
A détecter toute anomalie actuelle sur le site et à ne pas reproduire sur la nouvelle version.

J’ai effectué une migration récemment, et il s’est trouvé que le crawl pré migration a détecté plusieurs spider traps pouvant être rapidement corrigés via le robots.txt. J’en ai également profité pour corriger quelques coquilles et erreurs.

J’ai également profiter du crawl pour :

Bien catégoriser les pages du site
Compter le volume des pages par catégories
La répartition par profondeur
Sauver le temps de chargement des pages
Récupérer l’ensemble des URL du site afin de réaliser un plan de migration et de n’en n’oublier aucune.

Ces données me permettront de m’assurer que la totalité des pages ont été conservées.

Etablissement d’une liste de mots clés

Le crawl du m’a permis de récupérer l’ensemble des pages de mon site. J’ai deux templates principaux : catégories / produits. En scrapant la balise h1 de ces pages, j’ai pu constituer la base de mots clés qui correspond le mieux à la thématique de mon site.

Une fois cette base en poche, je récupère pour tous les mots clés l’ensemble des résultats Google. Il est préférable d’anticiper cette action et de réaliser 2 ou 3 relevés de positions avant la migration, espacés d’une semaine.

Pour aller plus loin, on peut également identifier quelles sont les URL de destination qui sont positionnées sur cette base de mots clés et s’assurer après la migration qu’elles le sont toujours (et surtout qu’elles existent toujours).

Traitement des logs et/ou Analytics

Nous avons certes crawlé le site et récupéré toutes les URL, mais cela ne suffit pas à récupérer les pages orphelines : il s’agit des pages crawlées par Google mais non accessibles via l’arborescence.

Les logs vont nous permettre de détecter des pages orphelines très crawlées par Google ou très visitées. Il faudra rajouter ces pages au plan de migration.

Si vous n’avez pas de logs, vous pourrez au moins récupérer les pages qui génèrent des visties via votre outil de statistiques et les inclure dans votre plan de migration.

Netlinking

Un rapport de netlinking doit se réaliser avant la migration. Il s’agit de récupérer l’ensemble des liens pointant vers votre site, et surtout ceux qui vous rapportent le plus de « trust ». Le but est de conserver au mieux leur effet sur notre site. Ces backlinks, vous pouvez :

Les mettre à jour directement depuis le site partenaire : assez difficile
Inclure les pages de destination et vous assurer qu’elles figurent bien dans votre plan de migration. Une 301 transmettra de la popularité, pas la 404.

Plan de redirection

Voici venu le temps du plan de migration.

Cas d’un changement de domaine : il s’agit de réaliser une simple redirection de domaine à domaine, qui se configure directement sur le fichier de configuration de votre ancien serveur (ou sur son .htaccess). Toutes les pages seront alors redirigées. Voici le code à utiliser :


Options +FollowSymlinks

RewriteEngine on

RewriteCond %{HTTP_HOST} ^www.ancien_domaine.com$

RewriteRule ^(.*) <a href="http://www.nouveau_domaine.com/$1">http://www.nouveau_domaine.com/$1</a> [QSA,L,R=301]

Cas d’un changement d’URL : c’est le cas le plus délicat où il ne faut surtout rien oublier. Pensez donc à rediriger en 301 :

Toutes les URL que vous avez crawlées sur votre site
Les URL qui génèrent du crawl (si vous avez les logs)
Les URL qui génèrent du trafic
Les URL qui se positionnent sur votre base de mots clés
Les URL de destination des backlinks

Recette

Est-venu le temps de la recette, dans un bel environnement preprod. Voici les principales actions à mener :

Vvotre environnement de recette doit être bloqué aux robots (Google).
Crawlez le site en recette et comparez tous les KPI avec ceux relevés lors du crawl pré migration.
Assurez-vous que les nouvelles recommandations SEO que vous avez émises pour le nouveau site sont bien en place.
Réalisez un audit SEO comme si vous le faisiez pour la première fois : une migration peut impliquer de nombreuses régressions, malheureusement.
Vérifier que toutes les pages ont bien leur <title> de rempli, meta description.
N’oubliez pas dans l’établissement des problèmes que vous rencontrerez d’indiquer une note de criticité, qui permettra d’ordonner toutes les actions.
Recettez les redirections : c’est possible s’il s’agit d’une migration où toutes les URLs sont modifiées. On peut tout à fait mettre en place les redirections de l’ancien serveur, et de volontairement tester les anciens patterns et de s’assurer qu’ils pointent bien vers les nouveaux. Pour cela, partez de la base de crawl que vous avez faite avant la migration, et testez toutes ces URL sur l’environnement de recette. Elles doivent toutes répondre en 301 et rediriger vers les nouvelles URL correspondant à votre plan de migration.
Assurez-vous de retrouver la totalité de vos pages, que vous n’avez pas perdu en terme de niveau de profondeur, de temps de chargement.
Il peut y avoir également des éléments nouveaux : on peut profiter d’une migration pour créer un nouvelle version mobile d’un site. Je me souviens par exemple qu’on avait profité d’une migration pour mettre en place du « dynamic serving ». il s’agissait d’offrir deux codes HTML différent en fonction du user-agent. Par exemple, un user-agent mobile devait récupérer du contenu optimisé pour le mobile, et un user-agent desktop devait récupérer un contenu adapté pour les ordinateurs. On devait du coup mettre en place le Vary: User-Agent dans toutes les en-têtes des pages, mais uniquement celles qui possédaient une version mobile (car toutes les pages n’étaient pas adaptées mobile !). C’est le uniquement qui était drôle, car j’ai crawlé l’ensemble des pages du site, avec deux user-agent (Mobile et Desktop), et j’ai du m’assurer qu’en fonction du user-agent employé, les en-têtes des pages qui avaient une version mobile devaient renvoyer le Vary: User-Agent et les autres non.

Crawl post-migration

Une fois la recette terminée, on met le site en ligne 🙂 Félicitations ! A ce stade, il fait tout simplement réitérer les actions menées lors de la recette

Suivi post migration

Le suivi peut se réaliser à plusieurs niveaux, et tous sont complémentaires :

Google Webmater Tools : il va surtout vous renseigner sur le taux de crawl, temps de chargement des pages, erreurs rencontrées. Si vous avez changé de domaine, n’oubliez pas de l’indiquer sur l’ancien domaine.
Suivi du trafic : classique.
Suivi des positions : récupérez vos positions de manière hebdomadaire durant la phase de migration, sur une période de 3 mois par exemple. Vous pouvez ensuite non pas arrêter mais espacer la récupération des positions.
Logs : les logs sont mine d’information, profitez-en si vous y avez accès 🙂 Suivez les erreurs (visites, crawl), l’évolution du crawl sur les anciennes pages, l’évolution du crawl sur les nouvelles pages. Vous pouvez par exemple suivre le crawl des nouvelles pages, et vous faire une idée du temps que Google aura mis à explorer la totalité de votre site. Si votre plan de migration a été bien fait, il devrait être rapide.
Abandon de l’ancien domaine : je vous recommande de le conserver le plus longtemps possible, car il conservera les redirections des pages de destination de vos backlinks.