Migration de site : ce qui fait perdre le trafic organique, et comment l’éviter

Sommaire

Le scénario est connu. Le nouveau site est plus beau, plus rapide, mieux structuré ; il part en ligne un mardi ; trois semaines plus tard, le trafic organique a fondu et personne ne sait dire pourquoi. Le référencement n’a pas « mal réagi à la refonte ». Des centaines d’adresses qui recevaient des visites et des liens renvoient désormais une erreur, ou pointent vers une page qui n’a rien à voir.

Google documente la procédure de bout en bout dans sa page Déplacer un site avec des changements d’URL. Elle est courte, et presque tout ce qui casse en production y figure. Ce qui suit en est la version opérationnelle : dans quel ordre, avec quels fichiers, et où regarder quand ça déraille.

Ce qu’on appelle une migration

Le mot recouvre des opérations de risque très différent. La première chose à établir est laquelle on fait, ou lesquelles, ce qui est pire.

La documentation de Google donne une consigne que les plannings de refonte ignorent presque toujours : ne changer qu’une chose à la fois. Un changement de CMS, de structure d’URL et de domaine le même jour produit, quand le trafic baisse, trois causes possibles et aucun moyen de les séparer. Quand le calendrier le permet, on bascule le domaine d’abord, la refonte ensuite (ou l’inverse), mais pas les deux ensemble.

L’inventaire : la liste qui décide de tout

Le plan de redirections ne vaut que ce que vaut la liste des anciennes URL. Une adresse qui n’y figure pas ne sera pas redirigée, et personne ne s’en apercevra avant qu’elle manque. Google recommande de commencer par les pages importantes et cite lui-même les sources : sitemaps, journaux serveur, Search Console.

En pratique, on croise au moins quatre sources, parce qu’aucune n’est complète seule :

• un crawl complet du site actuel, qui donne ce qui est lié, mais pas les pages orphelines ;
• le rapport Performances de la Search Console, onglet Pages, exporté sur la période la plus longue disponible : ce sont les URL qui reçoivent effectivement des impressions et des clics ;
• l’outil d’analyse d’audience, en pages de destination, pour les adresses qui reçoivent du trafic d’autres sources ;
• les pages qui reçoivent des liens externes, depuis le rapport Liens de la Search Console : une ancienne page sans trafic mais citée par d’autres sites mérite sa redirection.

N’oubliez pas les fichiers. Google rappelle que l’inventaire inclut les images, les vidéos, les fichiers JavaScript et CSS. Un PDF de tarifs lié depuis des dizaines de sites partenaires est une URL comme une autre.

Le résultat est un tableur avec, au minimum, ces colonnes : ancienne URL, clics sur douze mois, domaines référents, nouvelle URL, code attendu (301, 404 ou 410), code constaté. Cette dernière colonne se remplit lors de la recette, pas avant.

Le plan de redirections

Une redirection permanente, côté serveur

Google le dit en toutes lettres dans sa page Redirections et recherche Google : une redirection permanente (301 ou 308) signale que la cible devient l’URL canonique, et c’est elle qui apparaît dans les résultats. Une redirection temporaire (302, 307) laisse la source en place dans l’index. Les redirections JavaScript ne sont vues qu’après le rendu, qui peut échouer ; elles ne se justifient que si le serveur ne permet rien d’autre.

Le cas typique de la 302 accidentelle : une extension de redirection qui l’applique par défaut, ou un développeur qui la choisit « en attendant d’être sûr ». La migration ressemble alors à une réussite dans le navigateur, et l’index garde les anciennes adresses.

Un seul saut

Chaque ancienne URL pointe directement vers sa destination finale. Google tolère des chaînes courtes (idéalement pas plus de trois redirections, et moins de cinq), mais elles se forment toutes seules au fil des refontes : l’URL de 2019 redirige vers celle de 2022, qui redirige vers celle d’aujourd’hui. Au moment de la migration, on reprend aussi les anciennes redirections encore actives et on les fait pointer vers la cible finale.

Une destination équivalente, ou un vrai 404

La règle de correspondance est simple à énoncer : une ancienne page pointe vers la nouvelle page qui répond à la même question. Quand il n’en existe pas, on ne redirige pas : on renvoie un 404 ou un 410, comme Google le recommande pour les contenus qui ne sont pas repris.

Combien de temps les garder

La documentation de migration parle d’au moins un an, et conseille de les garder aussi longtemps que possible. En pratique, il n’y a aucune raison de les retirer : un fichier de redirections ne coûte presque rien, et les liens externes vers les anciennes adresses ne disparaîtront jamais tous.

Tout ce qui doit suivre les redirections

Les redirections ne sont qu’un signal parmi d’autres. Quand le reste du site continue de désigner les anciennes adresses, on envoie à Google des signaux contradictoires.

• Les canoniques. Chaque nouvelle page porte une balise canonique qui se désigne elle-même. Le défaut classique : un gabarit importé de la préproduction, avec des canoniques pointant vers le domaine de test.
• Le hreflang. Sur un site multilingue, les annotations doivent référencer les nouvelles URL, dans toutes les langues, au même moment. Un hreflang qui pointe vers une adresse redirigée est une annotation cassée.
• Les liens internes. Ils pointent vers les nouvelles adresses, pas vers les anciennes en comptant sur la redirection. C’est le moment de vérifier le maillage du nouveau gabarit, qui a souvent perdu des liens en route.
• Le sitemap. Un nouveau sitemap ne contient que les nouvelles URL, celles qui répondent en 200. Il est envoyé dans la Search Console au lancement ; l’ancien peut ensuite être retiré.
• Le robots.txt. Celui de la nouvelle version doit reprendre les exclusions utiles, et rien d’autre. Bloquer l’exploration de l’ancien site, c’est empêcher Google de voir les redirections.

La préproduction : indexée d’un côté, bloquée de l’autre

L’environnement de test cause deux accidents opposés.

Le premier : la préproduction est indexée. Un sous-domaine de recette ouvert, lié une fois depuis un ticket public ou un e-mail, et Google en trouve une copie complète du futur site. Le robots.txt ne suffit pas à l’en empêcher : une URL bloquée peut quand même apparaître dans les résultats, sans description. Pour tenir un environnement de test hors de l’index, la documentation désigne le noindex ou la protection par mot de passe. La seconde est la seule qui protège aussi des regards.

Le second : les blocages partent en production. Le noindex global posé pendant le développement, ou le Disallow: / du robots.txt de recette, est copié tel quel le jour de la bascule. C’est l’accident le plus coûteux de la liste, parce qu’il est total. Google conseille de tenir la liste des URL portant un noindex à retirer au lancement ; on y ajoute une ligne « robots.txt de production vérifié » dans la recette.

La recette avant bascule

La recette se fait sur l’environnement final, avec le plan de redirections réellement actif, pas sur une maquette. L’ordre qui fonctionne :

1. Tester chaque ligne du tableur. Un script ou un outil de crawl en mode liste interroge toutes les anciennes URL et remplit la colonne code constaté : une 301, en un saut, vers la nouvelle URL attendue, qui elle-même répond en 200. Toute ligne qui diffère est un ticket.
2. Crawler la nouvelle version. On y cherche les liens internes vers des URL redirigées, les canoniques erronées, les pages en noindex qui ne devraient pas l’être, et les titres ou contenus perdus par rapport à l’ancien gabarit.
3. Comparer les pages qui comptent. Pour les vingt URL qui apportent le plus de clics, on ouvre l’ancienne et la nouvelle côte à côte : titre, texte, données structurées, liens. Une refonte de gabarit qui supprime la moitié d’un texte est une migration de contenu, même à URL constante.
4. Vérifier la mesure. Le plan de marquage doit fonctionner le jour même. Sans données propres sur la première semaine, on ne pourra jamais dire si la baisse vient du référencement ou d’une balise disparue.

Deux préparatifs encore : valider l’ancien et le nouveau site dans la Search Console avant la bascule, en conservant les fichiers ou balises de validation dans la nouvelle version, et prévenir l’hébergeur. Google rappelle que l’exploration augmente après une migration, puisqu’il doit parcourir les anciennes URL pour découvrir leurs redirections.

Le changement de domaine : l’outil de changement d’adresse

La Search Console propose un outil de changement d’adresse. Il ne sert que dans un cas : le passage d’un domaine ou d’un sous-domaine à un autre. Il est inutile pour un passage en HTTPS, un changement entre version avec et sans www, ou un déplacement de pages à l’intérieur du même site : les redirections et le sitemap y suffisent.

Dans le cas où il s’applique, l’ordre est le suivant : migrer, mettre en place les redirections 301 (y compris celle de l’ancienne page d’accueil, que l’outil exige), puis envoyer la demande depuis la propriété de l’ancien domaine. Les deux propriétés doivent être détenues par le même compte, et chaque variante de sous-domaine de l’ancien site validée et déclarée séparément.

L’aide de la Search Console indique que Google privilégie le nouveau site pendant environ 180 jours, et demande de conserver les redirections au moins aussi longtemps. Elle ajoute un conseil rarement suivi : garder l’ancien domaine enregistré au moins un an, pour qu’il ne soit pas racheté.

Après la bascule : ce qu’on surveille

Google prévient que les positions fluctuent pendant la transition, et que pour un site de taille moyenne, il peut s’écouler quelques semaines ou plus avant que les nouvelles URL remplacent les anciennes. Une baisse la première semaine n’est donc pas un diagnostic. Une baisse qui se concentre sur certaines pages, en revanche, en est un.

Le suivi tient en un rituel quotidien les deux premières semaines, puis hebdomadaire :

• Search Console, rapport Indexation des pages sur la nouvelle propriété : les URL indexées doivent monter, et les motifs d’exclusion être lus un par un. Un pic de « soft 404 » ou de « Introuvable (404) » désigne des lignes du tableur.
• Search Console, rapport Sitemaps : le nombre d’URL découvertes et indexées depuis le nouveau sitemap.
• Search Console, rapport Performances, comparé page à page avec la période précédente. Le trafic de l’ancienne propriété doit baisser pendant que celui de la nouvelle monte ; c’est l’évolution décrite par Google, et c’est celle qu’on vérifie.
• Les journaux serveur : erreurs 404 sur les anciennes URL encore demandées par Googlebot ou par des visiteurs. C’est la source la plus rapide pour découvrir les oublis de l’inventaire.
• L’inspection d’URL, pour une sélection de pages stratégiques : l’URL canonique choisie par Google est-elle bien la nouvelle ?

Chaque 404 découverte après coup s’ajoute au tableur et reçoit sa redirection. Le tableur reste vivant plusieurs mois : c’est le seul document qui permet de répondre, six mois plus tard, à la question « où est passée telle page ? ».

Enfin, les liens que vous maîtrisez : signatures d’e-mail, profils d’entreprise, campagnes publicitaires, liens des partenaires les plus importants. Google conseille de les mettre à jour pour que les visiteurs ne passent plus par la redirection. Les campagnes payantes, en particulier, qui pointent encore vers les anciennes URL après la bascule, gaspillent un temps de chargement à chaque clic.

Ce que l’accompagnement change

Rien de ce qui précède n’est secret. Ce qui fait échouer les migrations n’est pas l’ignorance de la procédure, c’est le calendrier : le tableur est commencé la veille, la recette est raccourcie parce que le site doit sortir, et la personne qui connaissait les anciennes URL a quitté le projet. Le travail utile d’un accompagnement en référencement naturel se situe là : tenir l’inventaire dès le cadrage de la refonte, faire valider le plan de redirections comme un livrable à part entière, et refuser une mise en ligne dont la recette n’est pas faite.

Si vous préparez en même temps une refonte de l’arborescence, l’article sur l’architecture SEO traite de la structure cible ; celui-ci, du chemin pour y arriver sans perdre ce qui existe.