Le guide de la migration de site web que vous devez lire

Il y a beau­coup de types de migra­tions dif­férentes, mais les étapes de base de la plan­i­fi­ca­tion et de repér­er les prob­lèmes sont les mêmes. Une migra­tion peut être très com­plexe, impli­quer beau­coup de per­son­nes et d’étapes dif­férentes. Ne paniquez pas si cela ne se passe pas comme prévu, vous pou­vez cor­riger presque tout ce qui va aller de travers.

Nous allons voir dans ce guide :

• Pré­par­er une migra­tion de site
• Men­er une migra­tion de site
• Tester et sur­veiller la suite

Vous avez besoin de savoir ce qui va chang­er et qui va être impliqué dans ces change­ments. En d’autres ter­mes, il faut plan­i­fi­er et suiv­re toutes les étapes. Il va fal­loir savoir qui sont toutes les per­son­nes impliquées, leurs rôles, les dead­lines et un ensem­ble de process pour suiv­re le tout. Un chargé de pro­jet et un sys­tème de suivi de pro­jet vont vous aider. Ten­ter de tout faire par mail et Slack risque de devenir hors de contrôle.

Il vous faut aus­si un plan pour revenir en arrière, au cas où quelque chose de dra­ma­tique arrive. Vous pour­rez tou­jours restau­r­er le site dans son état ini­tial, même si c’est le plan de la dernière chance.

Il va vous fal­loir con­naître les impacts de vos actions, être sûr d’avoir accès à la GSC et Google Ana­lyt­ics de l’an­ci­enne et du nou­veau site (faites une vue com­binées des deux si besoin). Cer­tains change­ments vont met­tre des semaines voire des mois à avoir un impact sur vos flux, mais d’autres pour­raient n’en avoir aucun. Par exem­ple, si vous migrez un site de taille moyenne sur un nou­veau domaine, vous allez avoir quelques semaines de vari­a­tion. Mais si vous le com­binez dans un site exis­tant, vous pour­riez ne voir aucune dif­férence de trafic.

Il va fal­loir faire un peu de tra­vail de pré­pa­ra­tion. Je sug­gère quelques étapes :

• Faites un crawl de votre site. Vous allez vous en servir comme base pour suiv­re les change­ments par la suite. Vous pou­vez utilis­er l’Audit de site pour cela.
• Créez une série de pages test comme celles du rap­port Top Pages de l’Explo­rateur de site. Vous allez vous en servir plus tard pour véri­fi­er les erreurs. Vous pou­vez même lancer un crawl sur ces pages dans un autre pro­jet d’audit pour facile­ment les com­par­er par la suite.
• Restreignez l’accès à votre site de développe­ment ou stag­ing site (si vous en avez un) pour qu’il ne soit pas indexé.
• Faites une sauve­g­arde de votre site, juste au cas où vous auriez besoin de faire un rollback.

Pre­cise­ly what’s involved in a web­site migra­tion depends on whether the URLs will remain the same or not. Below we’ll dis­cuss both scenarios.

Ce que va pré­cisé­ment impli­quer une migra­tion de site dépend de si les URLs vont rester les mêmes ou non. Nous allons voir les deux scénarios.

Quand les URLs sont les mêmes…

C’est la déci­sion la plus sim­ple (en tout cas d’un point de vue SEO) car moins de choses vont chang­er. Cela reste une opéra­tion com­plexe, mais la plu­part des tâch­es à entre­pren­dre sont plus typ­ique­ment un tra­vail d’infrastructure/DevOps ou de développeur et pas de SEO.

Ces migra­tions peu­vent impliquer :

• Héberge­ment : CDN, serveur
• Plate­forme : CMS, langue, JS framework
• Design : tem­plate, Liens internes, tags

Si vous utilisez un site de développe­ment ou de stag­ing, il vaut mieux y avoir accès pour véri­fi­er les éventuels prob­lèmes avant de pouss­er la ver­sion live.

Ce qu’il faut chercher

Vous allez devoir chercher tous les change­ments pos­si­ble, dont des choses comme :

• Balis­es Canon­i­cal. Elles devraient être similaires.
• Balis­es Title. Assurez-vous qu’elles soient les mêmes ou très sim­i­laires à ce que vous aviez. De nou­veaux sys­tèmes peu­vent avoir des généra­tions automa­tiques de balis­es ou cer­tains réglages par défaut qui seront dif­férents de ce que vous aviez.
• Meta descrip­tions
• Balis­es Heading
• Hre­flang
• Schema
• Meta robots. Il faut vous assur­er que vos pages ne sont pas en noindex.
• Con­tenu.C’est par­ti­c­ulière­ment impor­tant pour les sys­tèmes JavaScript. De nou­veaux sys­tèmes pour­raient ne pas avoir tout le con­tenu chargé dans le DOM par défaut, les moteurs de recherche pour­raient ne pas voir cer­tains con­tenus à cause de cela.
• Liens Internes. Des choses comme le fil d’Ariane, les arti­cles en rap­port, les liens du foot­er ou du menu prin­ci­pal peu­vent avoir changé.
• Dif­férences de vitesse

Utilisez la fonc­tion com­para­i­son de l’Audit de site pour voir les change­ments depuis votre dernier crawl.

Il y a quelques autres points qui pour­raient créer des prob­lèmes plus importants.

• Si vous lais­sez acci­den­telle­ment un blocage, les moteurs de recherche ne pour­ront pas explor­er vos pages.
• Par­fois de vieilles redi­rec­tions ne sont pas copiées de votre fichi­er .htac­cess ou de con­fig­u­ra­tion de serveur, ce qui va vous faire per­dre cer­tains back­links. Ce prob­lème est dif­fi­cile à repér­er et survient sou­vent au moment du change­ment d’hébergement. Gardez un œil sur le rap­port Best by link de l’Explo­rateur de site et fil­trez par 404 pour voir les liens qui sont main­tenant cassés.

Lorsque les URLs sont différentes…

Ces migra­tions sont générale­ment plus com­pliquées. La seule excep­tion est de pass­er de HTTP à HTTPS, ce qui est rel­a­tive­ment facile aujourd’hui.

Ces migra­tions peu­vent impliquer :

• Domaine : chang­er de domaine, fusion­ner avec un autre site, sépar­er un site.
• Pro­to­cole : HTTP > HTTPS
• Path (chemin) : sous-domaine/­sous-dossier, ce qui change l’archi­tec­ture du site

Spécifique au HTTP > HTTPS

• Utilisez une Poli­tique de Sécu­rité de Con­tenu d’upgrade-inse­cure-requests pour régler les prob­lèmes de con­tenu mixte (mixed con­tent). C’est rapi­de à implé­menter et fonc­tionne pour toutes les ressources à part les liens internes, que vous allez devoir met­tre à jour vous-même.
• Installez un cer­ti­fi­cat de sécurité
• Redi­rec­tions 301 HTTP > HTTPS
• Ajoutez un head­er HSTS

Je ne m’inquiéterai pas pour des élé­ments comme une chaîne de redi­rec­tion sur le root path ou met­tre à jour les liens au site. Cor­riger une chaîne ou met­tre à jour des liens ne vous apportera pas grand-chose comme le sig­nal sera con­solidé par les redirections.

Spécifique aux changements de domaine

• Bais­sez tem­po­raire­ment le TTL (quelques heures). Cela va rafraîchir les caches DNS plus rapi­de­ment et quand vous activerez la migra­tion, vos change­ments seront vus par plus d’utilisateurs plus rapidement.
• Utilisez un out­il de change­ment d’adresse dans GSC
• Véri­fi­er l’ancien domaine pour toute action manuelle qu’il pour­rait y avoir à faire dans le GSC.

Voici une petite astuce pour les util­isa­teurs de Ahrefs : si vous changez la cible de votre crawl dans les réglages de votre pro­jet pour un domaine dif­férent, votre nou­veau crawl se fera sur le nou­veau domaine et vous pour­rez le com­par­er à celui de l’ancien.

Pour tout

• Met­tez à jour les liens internes et liens de dif­férentes balis­es comme la canon­ique, hre­flang, etc. Vous pour­riez avoir recours à un plu­g­in de rechercher et rem­plac­er pour aller plus vite sur vos liens internes.
• Con­fig­urez GSC. Cela peut impli­quer des choses comme trans­fér­er vos fichiers de désaveu, paramétr­er le geo-tar­get­ing, les réglages de paramètres d’URL et charg­er les sitemaps. Il va fal­loir garder un sitemap avec les anci­ennes URL pen­dant une petite péri­ode, cela va vous aider à suiv­re l’indexation des URLs dans GSC.
• Retirez tous les blocages d’exploration des pages sur l’ancien et le nou­veau site. Tout doit être exploré pour que les sig­naux se con­soli­dent correctement.
• Assurez-vous que les pages que vous voulez index­er ne sont pas en noin­dex. Vous pou­vez utilis­er l’Audit de site pour cela.
• Redirigez les pages. Il faut vous assur­er que les anci­ennes pages soient redirigées avec une redi­rec­tion 301 vers les nou­velles ver­sions de votre page. C’est une bonne idée de rediriger des élé­ments comme les images et les PDF aus­si, mais ne vous inquiétez pas des choses comme les fichiers JS, CSS ou de police. Con­cen­trez-vous sur la redi­rec­tion des élé­ments qui sont indexés par les moteurs de recherche et ne vous inquiétez pas des autres fichiers.

Il faut faire ces change­ments aus­si rapi­de­ment que pos­si­ble donc, si vous avez un site de développe­ment ou de stag­ing, vous devriez lancer une explo­ration dessus pour vous assur­er que tout va bien avant de le pass­er en live. Sou­venez-vous que si un ancien site util­i­sait le HTTPS et que le cer­ti­fi­cat expire, les bots vont pass­er mais les util­isa­teurs auront un mes­sage d’erreur et ne seront pas redirigés. Il existe des cer­ti­fi­cats mul­tido­maines qui s’appliquent à plusieurs domaines à la fois qui peu­vent vous aider à éviter ce problème.

Si vous voyez une baisse, c’est cer­taine­ment lié aux redi­rec­tions, quelque chose qui ne peut pas être exploré, des élé­ments en noin­dex, des change­ment ou sup­pres­sion de con­tenu, change­ment dans les liens internes ou autres élé­ments qui auraient changé en lien avec le SEO technique.

Il y a plusieurs moyens de suiv­re la pro­gres­sion d’une migra­tion et de s’assurer que tout va comme il faut.

Avec Ahrefs

There are sev­er­al var­i­ous ways to look for changes. As I men­tioned ear­li­er, you can change the scope of your crawl in Site Audit and get a com­par­i­son that shows you what changed. You’ll want to look out for changes to things like:

Il y a plusieurs moyens de véri­fi­er les change­ments. Comme je l’ai men­tion­né plus tôt, vous pou­vez chang­er la cible de votre crawl dans l’Audit de site pour avoir une com­para­i­son avec la ver­sion précé­dente pour voir les change­ments. Vous allez devoir chercher des change­ments comme :

• Balis­es canoniques
• Hre­flang. Elles seront brisées pen­dant une péri­ode si vous changez de domaine, il va fal­loir un cer­tain temps pour que les pages soient de nou­veau explorées et que les con­nex­ions soient faites.
• Schema
• Robots Meta

Vous vous sou­venez lorsque nous avons créé une liste des top pages plus haut ? Ce sont vos pages pri­or­i­taires. Il va être intéres­sant de crawler cette liste dans l’Audit de site pour vous assur­er que des élé­ments comme les redi­rec­tions soient bien en place et qu’il n’y a pas eu de change­ments trop rad­i­caux. Si vous faites un pro­jet séparé pour cette liste en amont, vous pou­vez même faire un crawl de com­para­isons pour voir rapi­de­ment les change­ments sur ces pages.

Vous pou­vez voir le traf­ic par page, le traf­ic des mots-clés et l’historique des change­ments avec les rap­ports Top Pages et Organ­ic Key­words de l’Explorateur de Site 2.0. Il est facile de faire des com­para­isons pour le même domaine, mais si vous en avez changé, vous devriez peut-être exporter ces don­nées vers Excel ou Google Sheets pour pro­duire une vue com­binée pour dif­férentes péri­odes pour voir où vous pour­riez avoir eu des pertes et ce qui a pu se passer.

Traf­ic de page et his­torique des change­ments selon le rap­port Top Pages 2.0 dans l’Explorateur de Site.

Vous pou­vez aus­si utilis­er notre crawler pour vous assur­er que les redi­rec­tions fonc­tion­nent cor­recte­ment et que les liens sont bien redirigés comme il faut.

Voici la méth­ode la plus sim­ple pour y arriver :

1. Entrez votre domaine dans l’Explo­rateur de Site
2. Ren­dez-vous dans le rap­port Best by Links (meilleure par lien)
3. Ajouter un fil­tre “404 not found”
4. Triez par domaines référents.

Cela va vous mon­tr­er les pages qui dis­posent de back­links que nous voyons en 404 avec notre crawler. Pensez à les rediriger.

Avec GSC

La Google Search Con­sole dis­pose de beau­coup de don­nées qui vont vous aider dans votre migra­tion. Par exem­ple, vous pou­vez véri­fi­er les prob­lèmes de canon­i­sa­tion en util­isant l’outil d’inspection d’URL. Entrez sim­ple­ment l’URL et Google va vous dire quel canon­i­cal il a choisi.

En plus de cela, vous pou­vez exporter les don­nées du GSC et faire une vue com­binée de votre traf­ic dans Excel ou Google Data Stu­dio pour avoir une meilleure vue sur votre migra­tion. Vous pou­vez aus­si utilis­er une vue com­binée des don­nées de page ou de mots-clés pour mit­iger toute perte.

Le rap­port de cou­ver­ture d’index va vous aider à voir com­ment vos pages sont indexées. Si vous avez chargé à la fois les anciens et nou­veaux fichiers de sitemap, vous pou­vez voir les change­ments dans l’indexation, repér­er d’éventuels prob­lèmes à cet endroit. Avec les fichiers sitemap, vous pour­rez avoir un rap­port de cou­ver­ture spé­ci­fique pour les pages qui sont dessus.

Si vous voulez voir un aperçu de l’activité de crawl de Google et tous les prob­lèmes iden­ti­fiés, le meilleur endroit où chercher est le rap­port de sta­tis­tique d’exploration dans la Google Seach Con­sole. Il existe plusieurs rap­ports qui vont vous aider à iden­ti­fi­er les change­ments dans le com­porte­ment de l’exploration, des prob­lèmes de crawl et vous don­ner plus d’information sur la manière dont Google crawle votre site.

Il faut absol­u­ment analyser tout ce qui est noti­fié comme une erreur d’exploration dans le rap­port de crawl, comme ici :

Il y a aus­si la date et l’heure pré­cise de la dernière explo­ration d’une page.

Divers

Si vous n’aviez pas de crawl de base de votre ancien site et que vous avez besoin de voir les dif­férences entre l’ancien et le nou­veau, véri­fiez archive.org pour voir s’ils ont des copies de cer­taines de ces pages. Ils ont générale­ment des copies des fichiers robots.txt de cer­tains sites, ce qui peut être pra­tique pour voir si quelque chose n’a pas fonc­tion­né et a été acci­den­telle­ment blo­qué pen­dant la transition.

Si vous n’avez pas accès à la Google Search Con­sole pour un site, vous pou­vez tout de même véri­fi­er la canon­i­sa­tion en col­lant l’URL dans Google. En règle générale, la pre­mière page qui sera mon­trée sera la canonique.

Une fois encore, si vous n’avez pas accès à la GSC, beau­coup de prob­lèmes liés au crawl peu­vent être véri­fiés dans vos fichiers log.

Un aver­tisse­ment néan­moins : l’opérateur de recherche site : n’est pas tou­jours bien com­pris. Si vous utilisez site :, vous deman­dez ce que Google con­nait d’un site spé­ci­fique. Ce n’est pas parce que vous voyez des pages que cela veut dire que c’est comme cela qu’elles sont indexées ou qu’il y a un prob­lème avec la migra­tion. J’ai déjà vu des per­son­nes que cela a poussées à blo­quer l’ancien site pour que les pages ne soient pas dans l’index, ce qui cause des problèmes.

Poursuivre la surveillance

Cer­tains prob­lèmes peu­vent sur­venir bien longtemps après la fin de la migration.

• Sur­veillez l’ancien domaine pour vous assur­er qu’il soit renou­velé, et faites de même pour tous ceux qui rediri­gent vers votre nou­veau site. Si le domaine expire, tous les sig­naux qui étaient passés via les redi­rec­tions depuis les anciens sites pour­raient être perdus.
• Si vous ne vous êtes pas débar­rassé de votre ancien héberge­ment et que vous con­servez les redi­rec­tions ci- dessus, soyez con­scient qu’elles seront cassées si l’hébergement prend fin, et vous allez per­dre quelques liens. Vous pou­vez résoudre ce prob­lème en faisant des redi­rec­tions depuis les DNS et stock­er ces redi­rec­tions sur votre nou­veau site.
• Assurez-vous de garder les cer­ti­fi­cats de sécu­rité à jour ou passez sur un cer­ti­fi­cat mul­ti-domaine, comme nous en avons par­lé plus haut.

Conclusion

La migra­tion de sites n’est pas une mince affaire, alors prenez le temps de célébr­er si tout se passe bien. Cela dit, ce n’est sans doute pas la dernière fois que vous faites une migra­tion de site, je vous sug­gère de vous réu­nir avec toutes les per­son­nes qui ont été impliquées dans celle-ci pour dis­cuter de ce qui s’est bien passé, ce qui s’est mal passé, et ce qu’il faudrait chang­er si vous aviez à le refaire.

Vous avez des ques­tions ? Je suis sur Twit­ter.