Migration SEO: toutes les étapes à suivre

La migration d’un ancien site vers un nouveau, suite à une refonte, est une étape délicate qui peut s’avérer désastreuse si elle n’est pas gérée correctement. La prise en compte du SEO, avant et après la migration, est essentielle pour ne pas vous retrouver avec une perte de trafic difficile à récupérer.
On va détailler l’ensemble des étapes à suivre, avant, pendant et après la migration afin de ne pas perdre votre référencement.

1/ Auditer le site existant

L’audit du site existant permet d’extraire les données qu’il faudra comparer avec les données du nouveau site. En effet, refondre un site c’est l’occasion de l’améliorer en tout points et pour cela il faut savoir d’où on part.  Les données intéressantes qu’on peut extraire sont notamment:

• Les niveau de profondeurs: le nouveau site devra faire mieux
• Volume d’urls: le nouveau site devra comporter au moins autant d’urls
• Répartition du pagerank interne: Cela permet de voir comment est distribué le jus du site par type de pages. Le nouveau site devra faire mieux

Pour avoir une vision détaillée de l’ensemble des données du site existant, il faut le catégoriser par type de pages comme les fiches produits, les catégories, les paginations, le blog, etc.. Par exemple, connaitre les niveaux de profondeur du site au global c’est bien, mais les connaitre par type de pages c’est encore mieux:

L’objectif d’auditer le site existant est surtout d’avoir des éléments de comparaison avec ceux du nouveau site. Il s’agit aussi d’identifier les forces et faiblesses du site existant afin de conforter les forces sur le nouveau site et effacer les faiblesses.

Il ne s’agit pas non plus de réaliser un audit complet et détaillé car on ne va pas optimiser l’ancien site alors qu’un nouveau est en passe de sortir. En revanche, pour le site en refonte justement, il est nécessaire de réaliser un audit complet et approfondi, comme on va le voir tout de suite.

2/ Auditer le nouveau site en refonte

Réaliser un audit du nouveau site, avant même qu’il sorte en production, est l’étape la plus importante à suivre avant de migrer le site actuel. Refondre un site est souvent l’occasion d’améliorer l’expérience utilisateur, le web-design ou le tunnel de conversion par exemple. Côté référencement, c’est l’occasion d’optimiser le site comme revoir l’arborescence du site, améliorer la structure des pages, optimiser le maillage interne . Tous ces changements nécessitent d’auditer le site web en profondeur

Le référencement doit être pris en compte bien avant la migration, il ne s’agit pas, comme je l’ai vu récemment chez un client, de modifier le menu du site pour des questions d’ergonomie sans considérer l’impact que ça aura forcément sur le positionnement du site. Expérience utilisateur et SEO doivent fonctionner main dans la main.

Il faut notamment se poser la question de l’audit du nouveau site en vue d’une migration dans les cas suivants:

• Changement du menu
• Changements des urls
• Changement de l’arborescence ou de la hiérarchie des pages
• Changement de nom de domaine
• Migration du site en https
• Changement dans le maillage interne
• Migration d’un site mobile dédié vers un site responsive

Tester le nouveau site sur un serveur de test

Tester le nouveau site sur un serveur de test est bien-sur un pré-requis pour toutes les étapes avant la migration. Je suis toujours étonné de voir le nombre de gens, même sur de gros sites, qui font des modifications en live sur le site de production et qui s’étonnent après d’avoir des erreurs inattendus. C’est une étape à ne pas prendre à la légère, quitte à décaler la mise en ligne prévue du nouveau site.

Il faut veiller à protéger le serveur de test par une authentification obligatoire avec login / mot de passe. C’est la meilleure méthode pour éviter que Google ne crawle et n’indexe le site de développement.

On pourrait passer par le fichier robots.txt avec un disallow afin de bloquer le crawl de Google ou par des meta noindex sur les pages, mais on prend le risque de déployer par erreur le fichier robots.txt ou les meta noindex du site de développement vers le site de production, ce qui serait catastrophique.

Catégoriser le nouveau site

Comme pour tout audit, la première étape est de catégoriser le site par type de pages comme par exemple les fiches produits, les catégories, les paginations, le blog, etc… l’objectif est de pouvoir comparer les données des types de pages du nouveau site avec celles du site existant.

Mettre à jour les liens internes

Dans le cas de changement de domaine, d’urls ou de protocole https, il faut bien mettre à jour les anciennes urls par les nouvelles. Même si les anciennes urls sont redirigées vers les nouvelles, il faut éviter de faire crawler inutilement des redirections par Googlebot. Si Google crawle vite, il verra plus de pages potentiellement indexables. Forcer Google à passer par des redirections avant d’atteindre l’url finale est une perte de temps. Et même si ce temps de redirection est minime à l’échelle d’une seule url, à l’échelle d’un gros site avec déja plusieurs milliers de pages, ce n’est pas négligeable.

Sur des gros sites, pour vérifier que l’ensemble des liens pointent bien vers les urls du nouveau site et pas l’ancien, il faut passer un crawl du site web. De plus, ça permettra de vérifier d’autres informations fondamentales pour le SEO comme des liens brisés, des pages d’erreurs 404 et autres.

Vérifier les rel canonical

Il faut vérifier que les balises « rel=canonical » indiquent bien les urls du nouveau site et non l’ancien. Des erreurs sur les urls canoniques peuvent être catastrophiques car ça empêcherait les urls du nouveau site d’être indexées. Ajouter des rel canonical sur l’ensemble des urls du site c’est aussi un signal supplémentaire pour indiquer à Google que les nouvelles urls remplacent bien par les anciennes. Attention, ca ne dispense pas d’effectuer des redirections comme on le verra plus tard.

Les rel canonical c’est aussi une bonne manière d’éviter des problèmes de duplications suite à des urls paramétrées qu’on ne voudrait pas indexer. Attention là aussi, dans certains cas, les rel canonical pointent vers elles-mêmes et dans d’autres cas, les rel canonical pointent vers l’url à indexer.

Corriger les problèmes de duplication

Des erreurs de migration peuvent souvent conduire à des problèmes de duplication. L’audit du site de refonte permet justement de révéler ces problèmes et de les corriger comme par exemple:

• Plusieurs versions de la même url avec donc un contenu identique
• Avoir des versions d’urls avec https et http accessibles en même temps
• Avoir des versions d’urls avec www et d’autres sans www
• Eviter que les urls du moteur de recherche interne soient indéxées

Tant qu’à faire, refondre un site est l’occasion de nettoyer le site des pages inutiles et des pages dupliquées. Un nouveau site c’est l’occasion de partir sur un index propre, sans pages dupliquées indéxées, un crawl optimisé vers des pages génératrices de trafic. Ceci dit, on peut faire ces optimisations en toute occasion.

Vérifier le taguage analytics

Il faut bien veiller à ce que le tag web analytics reste identique entre l’ancien site et le nouveau site afin de garder l’historique du trafic et détecter toute perte éventuelle de trafic. C’est souvent le dernier élément qui est vérifié par les développeurs et ça peut arriver qu’ils oublient de l’insérer, ce qui résulte malheureusement en un trou de données dans votre outil de web analytics.

Analyser les urls disparues

Dans le processus de refonte d’un site, il est pas rare d’oublier des urls pourtant présentes dans l’ancien site. C’est d’autant plus pénalisant si ces urls sont positionnées sur Google et génèrent du trafic.

Il faut notamment vérifier des urls manquantes dans le cas suivants:

• Si il y a une refonte de l’arborescence du menu, il est pas impossible que des sous catégories entières soient oubliées du nouveau menu. Ce qui résulterait en une perte de trafic inévitable.
• Si il y a des changements d’urls sur le nouveau site, il faut bien veiller à ce que les anciennes urls redirigent vers des urls équivalentes

Là aussi un comparatif entre le crawl de l’ancien site et du nouveau site permettra de détecter des différences sur les volumes de pages.

3/ Lister les urls du site existant

Le site existant fait du trafic sur des urls positionnées, une migration ne doit pas résulter en une perte de trafic. Il est d’ailleurs faut de dire, comme on peut parfois le lire, qu’une migration s’accompagne forcément d’une perte de trafic. Personnellement toutes les migrations que j’ai eu à gérer depuis le début se sont traduites au contraire par des hausses de trafic.

Le site actuel possède aussi des urls positionnées au delà de la page 1 de Google qui ne font pas de trafic mais qui pourraient en faire. Ces pages aussi sont importantes car elles ont un potentiel de positionnement et de trafic futur.

Pour lister les urls de l’ancien site, il faut prendre en compte l’ensemble des sources suivantes:

1. Lister les urls avec un outil de crawl comme oncrawl, screaming frog, botify ou le non moins connu RM Tech d’Olivier Duffez, permettra d’extraire les urls accessibles à travers la structure de liens du site.
2. Lister les urls qui font des visites avec l’outil de web analytics comme Google analytics
3. Lister les urls qui reçoivent des liens entrants, des backlinks, avec un outil comme majestic SEO
4. Lister les urls vues par Googlebot avec une analyse de logs

3-1/Crawler l’ancien site

Crawler l’ancien site est indispensable pour préparer les urls qu’il faudra rediriger vers le nouveau site. Ça permettra de récupérer les urls accessibles dans la structure du site. Mais ce n’est pas suffisant, il faut croiser ces données avec les 3 autres sources suivantes

3-2/Lister les urls qui font des visites

Les urls qui font des visites ne sont pas forcément dans la structure du site et donc pas accessible via un outil de crawl. Ça peut être des urls hors structure, des « nomatch« , il est donc essentiel d’extraire les urls visitées. Les urls peuvent potentiellement faire une visite tous les 6 mois, c’est le cas sur du trafic ultra longue traîne. Il est donc préférable d’extraire les visites sur une longue période afin d’avoir une liste exhaustive d’urls.

Côté méthodologie, sur Google analytics, on peut facilement extraire les urls visitées depuis Google avec cette petite requête que j’ai spécialement préparé pour vous sur l’outil query explorer

3-3/Lister les pages qui reçoivent des liens entrants

Les pages qui reçoivent des liens entrants, ou backlinks, sont importants par la popularité qu’elles apportent au reste du site. Il est donc important de les lister afin de vérifier qu’elles existent toujours sur le nouveau site ou qu’elles soient bien rediriger vers des pages équivalentes.

Pour extraire les urls recevant des backlinks, l’utilisation d’outils comme majestic seo ou ahrefs sont bien utiles.

3-4/lister les urls vues par googlebot

On a les urls présentes dans la structure du site existant, les urls visitées, les urls qui reçoivent des backlinks, il manque les urls vues par Googlebot. En effet, Googlebot peut voir des urls qui ne se trouvent pas dans le site, qui ne font de visites et ne reçoivent pas de backlinks.

Vous me direz, quel intérêt de lister de telles urls ? Et bien, comme je disais en introduction de cette partie, le site possède certainement des pages avec un potentiel de positionnement et de trafic futur, et il est possible qu’aucune des 3 sources précédentes n’arrivent à les extraire. Si Google passe du temps à explorer ces pages, il faut se poser la question de leur intérêt ou pas.

Pour lister les urls vues par Googlebot, ça passe par une analyse des fichiers de logs du serveur hébergeant le site actuel. L’intérêt c’est aussi de consolider les données qui n’auraient pas été récupérées par ailleurs.

4/ Lister les urls du nouveau site

Maintenant qu’on a les urls de l’ancien site, il faut à présent lister les urls du site en refonte. Pour faire ça, il y a qu’une seule méthode qu’on a déjà vu dans la phase d’audit du nouveau site, c’est à dire récupérer les urls crawlées sur ce dernier.

5/ Créer un plan de redirections

Il y a deux types de règles de redirections à prendre en compte:

• Les règles de redirections déjà existantes sur le site actuel
• Les nouvelles règles qu’il faudra créer entre les anciennes urls et les nouvelles

Le truc c’est d’éviter d’avoir des conflits entre les nouvelles règles et les anciennes règles de redirections. Il faut notamment éviter de se retrouver avec des chaines de redirections: url A > url B > url C > url D, qui feraient perdre du temps à Googlebot et conduiraient donc à des pertes de crawl.

5-1/ Créer les nouvelles règles de redirections

En fonction des changements d’urls entre site existant et nouveau site, plusieurs solutions sont possibles:

• Pour le HTTPS, je vous renvoie vers cet article sur la migration vers un site https,
• Si les modifications sont peu nombreuses, quelques regex sur le fichier .htaccess suffiront. Je vous conseille cet outil d’Aleyda Solis pour créer des règles simples.
• Si en revanche, de nombreuses modifications d’urls impliqueraient des règles trop nombreuses, et notamment trop de regles url vers url, il vaut mieux passer par une table de correspondance.

Une table de correspondance consiste à faire correspondre chaque ancienne url vers chaque nouvelle url dans un fichier texte ou dans une base de données. Voici le code qu’il faut rajouter dans le fichier de configuration du serveur avec l’utilisation d’un fichier texte:

RewriteEngine On
RewriteMap redirects txt=/etc/httpd/conf/redirects.txt
RewriteCond ${redirects:$1} !=""
RewriteRule ^(.*)$ ${redirects:$1} [redirect=permanent,last]

Ce fichier redirects.txt doit ressembler à ceci:

/ancienne-url https://www.nouveau-site.fr/nouvelle-url

5-2/ Uniformiser les anciennes et nouvelles règles

Une fois ces règles établies, il faut faire en sorte qu’elles soient bien compatibles avec les règles existantes et qu’elles ne créent pas de chaines de redirections (url A> url B > url C > url D > url F ) ou encore des boucles de redirections (url A> url B > url A > url B > url A > ….). Une mise à jour complète des anciennes règles de redirections est souvent nécessaire.

6/ Vérifier les redirections

La vérification des redirections doit se faire avant la mise en ligne du nouveau site, afin d’éviter les erreurs en production ou de devoir corriger dans l’urgence. Cette recette doit se faire sur le site de test afin de vérifier chaque ancienne url est bien redirigée vers les nouvelles. Les redirections doivent être de type 301, définitive, et être directes, sans passer par des chaines ou boucles de redirections.

Si vous changez de domaine, il est important de bien garder le contrôle de l’ancien domaine pendant plusieurs années après la migration notamment pour les backlinks vers l’ancien domaine.

7/ Préparer les sitemaps.xml

Il faut préparer le sitemap.xml du nouveau site avec l’ensemble des pages stratégiques. Et si le site existant n’a pas encore de sitemap.xml, il est préférable aussi de le créer avec notamment les pages qui font des visites. Une fois la migration effectuée, l’objectif sera de forcer Google à crawler les anciennes urls et ainsi de prendre en compte rapidement les redirections vers les nouvelles urls.

8/ Migrer le site

On y est, c’est le jour J, il est temps de basculer la refonte du site en production. Toutes les étapes de préparation avant migration permettent normalement d’aborder cette phase avec sérénité puisque on sait que le nouveau site est optimisé, qu’on a pas oublié d’urls, que les redirections fonctionnent bien, etc…

Toutefois, ça reste un moment critique et il faut veiller aux points suivants:

1. Choisir le bon moment pour migrer, c’est à dire à une heure où le trafic sur le site est faible, le soir ou tôt le matin par exemple.
2. Il est possible que le site reste inaccessible quelques temps, le temps de basculer le site et la nouvelle base de données. Pendant ce temps, le site devrait envoyer des pages d’erreur 503 personnalisées. Ça indiquera à Google que le site est en maintenance et qu’il doit repasser un peu plus tard pour vérifier à nouveau.
3. Pour un changement de domaine, créer la nouvelle propriété de console de recherche Google
4. Envoyer le nouveau sitemap.xml dans la console de recherche existante ou dans la nouvelle propriété si il s’agit d’un changement de domaine ou de protocole HTTPS.
5. Même si on a déjà testé les redirections sur le serveur de test, il faut vérifier à nouveau la liste d’urls préalablement préparée et s’assurer que les redirections fonctionnent bien en production. Pour cela, il faut crawler la liste d’urls, vérifier les codes réponses renvoyés (301) et vérifier que les urls cibles sont les bonnes.
6. Naviguez sur le site et vérifier que tout fonctionne: formulaires, panier, …
7. On peut lancer à nouveau un crawl rapide pour vérifier qu’il n’y a pas d’erreurs critiques de type 404, 500 ou de grosses bourdes techniques de type noindex, canonical, etc.. Logiquement, vu qu’on a déja recetter le site de développement, ça ne devrait pas arriver mais c’est toujours rassurant.

9/ Surveiller l’après migration

Trafic organique sur Google analytics avant et après migration suite à un audit SEO du site en refonte

Une fois que vous avez passé le site en production et appliqué les étapes précédentes, il faut analyser par précaution l’évolution du site:

• Suivre le positionnement du site avec un outil comme semrush
• Suivre le trafic du site, notamment le trafic organique, sur google analytics par exemple
• Suivre l’indexation du site sur la console de recherche de Google

Si toutes les étapes d’avant, pendant et post migration sont bien respectées, le trafic du site devrait peu varier, voire même s’améliorer si le nouveau site a été l’occasion de revoir profondément son optimisation pour les moteurs de recherche.

A propos de Serge Esteves

Consultant SEO / Webmarketing : Techniques avancées en référencement combinées aux leviers du marketing entrant (UX, CRO, analytics, content marketing, ereputation, ..).