Migration de site : la check-list des liens

Une migration casse les liens à quatre endroits distincts, et la plupart des équipes n'en vérifient qu'un, les redirections en général, puis considèrent que c'est fait. Les trois autres remontent des semaines plus tard, une plainte à la fois.

Cette check-list couvre les liens internes et entrants de votre site. La question distincte des backlinks que d'autres vous ont donnés mérite son propre passage : garder ses backlinks lors d'une refonte. Les deux se mènent le même jour, avec les mêmes gens, et se confondent d'autant plus facilement.

La check-list, dans l'ordre

Un mois après, le sujet est clos. Ce qui casse ensuite relève de l'entretien ordinaire, pas de la migration, et le confondre envoie chercher au mauvais endroit.

Avant : trois listes qui valent la peine

Les URL qui reçoivent du trafic. Depuis vos statistiques, sur douze mois, pas sur un. Les pages saisonnières sont celles dont personne ne se souvient en juillet, et ce sont celles qui font remonter des plaintes en novembre.

Les URL qui reçoivent des liens, internes et externes. Ce sont les adresses qui doivent continuer de répondre, quoi qu'il change par ailleurs. Elles se trouvent dans la Search Console, dans votre suivi de liens, et dans les journaux de votre serveur, où figurent les visites arrivées de l'extérieur.

Les URL absolues écrites à l'intérieur de vos contenus. C'est la liste que personne ne fait, et c'est là que les migrations cassent réellement. Chaque https://anciendomaine.com/... tapé dans un corps d'article survit parfaitement à l'export et continue de pointer vers l'ancien endroit. Cherchez votre propre nom de domaine dans l'export de vos contenus et comptez les occurrences : le chiffre surprend en général, et il surprend d'autant plus que le site est ancien.

Le jour J : les quatre endroits où les liens cassent

1. Le plan de redirection. Un saut, page vers page équivalente. La décision pour chaque URL retirée suit le même arbre que n'importe quelle suppression, et cet arbre ne produit jamais « redirection vers l'accueil ».

2. Les liens internes dans le contenu. Les liens relatifs survivent en général. Les absolus, non, sauf à les réécrire. Faites-le en rechercher-remplacer sur l'export, avant l'import, pas après coup page par page.

3. La navigation, le pied de page et les gabarits. Les menus sont souvent construits sur des chemins écrits en dur dans un thème. Ils sont sur toutes les pages : une erreur ici est la plus visible que vous puissiez commettre, et la plus rapide à corriger si vous la testez le jour même.

4. Le mobilier technique. Sitemap régénéré, robots.txt relu, balises canoniques pointant vers les nouvelles URL, hreflang mis à jour si vous avez plusieurs langues. Chacun de ces éléments contredit silencieusement les autres quand on n'en met à jour qu'une partie, et la contradiction ne produit aucune erreur visible.

Après : quoi vérifier, dans l'ordre

• Ouvrez les anciennes URL. Pas le nouveau sitemap : les anciennes adresses exactes. Chacune doit répondre 200 après exactement une redirection. Deux sauts fonctionnent aussi, et se feront couper un jour par quelqu'un qui fait le ménage.
• Crawlez tout le nouveau site. C'est le passage qui trouve les liens absolus que vous avez ratés, et c'est la raison de le faire maintenant plutôt que dans six mois. Les méthodes gratuites suffisent pour un site de quelques centaines de pages.
• Vérifiez aussi les liens sortants. Une migration est le seul moment où quelqu'un relit vraiment chaque page : profitez-en, ils ne remontent nulle part ailleurs.
• Surveillez la Search Console pendant un mois. Les erreurs d'exploration arrivent progressivement, pas le jour de la mise en ligne, et une remontée en troisième semaine est normale.

Le cas du changement de nom de domaine

C'est la migration la plus lourde, et elle mérite trois règles supplémentaires.

La redirection se garde indéfiniment. Pas deux ans : indéfiniment. Un domaine abandonné emporte tout l'historique de liens, et il finit souvent racheté par quelqu'un d'autre, ce qui transforme vos anciennes références en liens vers un site que vous ne contrôlez plus.

L'ancien domaine se renouvelle en même temps que le nouveau. La date d'expiration est la vraie date de fin de votre migration, et c'est celle que personne ne note nulle part.

Les emails comptent aussi. Les adresses en @anciendomaine continuent de recevoir du courrier pendant des années, y compris les avis de renouvellement et les alertes de vos prestataires. Une migration réussie qui perd la boîte aux lettres est une migration ratée deux ans plus tard.

Qui fait quoi, et pourquoi cela compte

Une check-list sans propriétaire se transforme en liste de vœux. Trois rôles suffisent, même dans une équipe de deux personnes.

Quelqu'un tient les listes : trafic, liens, URL absolues. C'est un travail de tableur, pas de technique, et il peut commencer un mois avant sans dépendre de personne.

Quelqu'un tient les redirections : écriture, mise en place, test. C'est le seul rôle qui doit être présent le jour de la bascule.

Quelqu'un tient la vérification d'après : les contrôles à J plus 1, J plus 3 et J plus 30. C'est le rôle qu'on oublie d'attribuer, et c'est celui qui décide si la migration s'est bien passée ou si l'on s'en apercevra en février.

Ce qui va casser malgré tout

Une migration parfaite n'existe pas, et prévoir les fuites vaut mieux que promettre l'étanchéité.

Les URL avec paramètres, les anciennes pages de recherche, les pièces jointes et les images passent presque toujours à travers. Les liens envoyés dans des emails il y a trois ans continueront d'arriver, et personne ne peut en dresser la liste. Enfin, les redirections en chaîne héritées d'une migration précédente se révèlent souvent à cette occasion, parce qu'elles ajoutent un saut de plus et franchissent la limite au-delà de laquelle plus rien ne suit.

La bonne réponse n'est pas d'essayer de tout prévoir : c'est de regarder les journaux du serveur pendant les deux premières semaines. Ils listent ce que les gens ont réellement demandé, y compris ce que vous n'aviez pas imaginé, et ils sont le seul rapport qui ne dépend d'aucune liste établie à l'avance. Le tri de ces 404 suit ses propres règles : tous ne méritent pas une correction.

Les deux erreurs qui coûtent le plus cher

Tout rediriger vers l'accueil parce que le plan a été laissé au dernier après-midi. Cela transforme une liste de décisions gérable en perte définitive, et cela se répare mal, parce que plus personne ne sait ensuite quelle ancienne URL correspondait à quoi.

Un cas se présente plus souvent que les autres et se traite exactement pareil : le passage de HTTP à HTTPS. Toutes vos adresses changent, donc c'est une migration, avec la même check-list. Ce que HTTPS change vraiment, et ce qu'il ne change pas se lit avant de la dérouler.

Supprimer les règles de redirection un an plus tard lors d'un ménage, par quelqu'un qui n'était pas là. Ces règles sont la seule chose qui rattache encore des années de liens à votre site. Gardez-les, et laissez dans le fichier un commentaire disant pourquoi elles existent et à quelle migration elles correspondent.