J'ai supprimé tous les liens internes du site. Exprès.
En juin, j'ai fait retirer près de 1500 liens internes des contenus pour reconstruire le maillage. Voici les sauvegardes préparées, le suivi des liens différés et les défauts retrouvés après la purge.
L’essentiel en bref
En juin, j'ai demandé qu'on retire les liens internes des contenus pour reconstruire le maillage. L'opération concernait près de 1500 liens sur 800 pages, en 7 langues. Les liens de navigation, d'auteur et de catégorie étaient conservés.
Je suis Jim. Cette série reprend la refonte Eurofiscalis après la mise en ligne. Le premier sujet est le maillage hérité de l'ancien site : pourquoi je l'ai retiré, comment on l'a reconstruit et ce qu'il a fallu corriger ensuite.
Pourquoi repartir du maillage des contenus
Le maillage interne, c'est l'ensemble des liens qu'une page fait vers les autres pages du même site. Il aide le lecteur à poursuivre sa lecture et les moteurs à découvrir les pages et leurs relations. J'en ai parlé en détail dans l'article sur le cocon sémantique à l'échelle, je ne vais pas refaire la théorie ici.
Le problème, c'est ce qu'on avait récupéré. Des années de liens posés à la main, par plusieurs personnes, sur l'ancien site, puis déménagés tels quels dans le nouveau CMS. Des ancres qui ne suivaient aucune règle commune, des liens vers des pages qui avaient changé d'adresse ou de rôle, et surtout aucune vue d'ensemble fiable sur qui pointait vers qui.
On pouvait passer des semaines à trier, lien par lien. Ou on pouvait tout retirer et reconstruire proprement, avec une doctrine unique, appliquée par le pipeline à chaque publication. J'ai choisi la page blanche.
Retirer les liens en gardant une restauration possible
Supprimer en masse, c'est le genre d'opération où une erreur se propage partout en quelques secondes. Nous avons préparé les contrôles avant de lancer le script.
Première chose : pas d'IA sur les données. L’IA pouvait aider à préparer le travail. Pour modifier le contenu brut de centaines de documents, je veux un script déterministe, qui fait exactement la même chose à chaque fois, et dont je peux lire chaque ligne.
Deuxième chose : pouvoir revenir en arrière. Avant de toucher quoi que ce soit, trois filets de sécurité : une sauvegarde précise de chaque lien retiré, un script capable de les remettre à leur place, et une photo complète de la base de données.
Troisième chose : retirer le lien, garder les mots. Le texte de l'ancre reste dans la phrase. Seul le lien disparaît. Le texte devait rester lisible. C’était le comportement attendu, à contrôler après l’opération.
Et enfin, on savait précisément ce qu'on ne touchait pas : les liens vers d'autres sites, les liens de prise de rendez-vous, les pages auteur et catégorie, et bien sûr les données dynamiques (les taux et les seuils branchés sur leur source, dont je reparlerai dans le dernier article de la série).
Reconstruire sans jamais poser un lien mort
Repartir de zéro, c'est bien. Mais le nouveau site continue de grandir pendant qu'on remaille. Et là, un problème très concret se pose.
Un article sur le numéro de TVA en Croatie peut avoir besoin de renvoyer vers la page du représentant fiscal du même pays. Sauf que cette page n'est pas encore publiée. Deux mauvaises options. Poser le lien quand même, et tu as un lien cassé tant que la cible n'existe pas. Ou ne rien noter, et tu oublies de faire le lien le jour où elle sort.
Nous avons retenu le lien différé. On ne pose pas le lien, on enregistre l'intention, directement dans l'article. Trois informations suffisent : la page visée, le texte exact qui deviendra le lien, et l'endroit où il se trouve dans l'article.
Le jour où la page cible est publiée, une « vague de relink » passe sur tous les articles qui l'attendaient, et pose tous les liens d'un coup, au bon endroit, sur le bon texte.
Les phrases coupées retrouvées après la purge
Puis, en août, Max nous remonte un retour utilisateur : trois pages, en polonais, en tchèque et en italien, avec une phrase coupée net. Du genre « consultez également . », avec un point qui flotte tout seul.
Le défaut venait des fragments de texte autour du lien. Ces pages étaient des traductions reconstruites après la version française. Au moment de la purge, leur lien avait été retiré, mais les petits morceaux de texte autour étaient restés, mal recollés. Personne ne les avait jamais relues depuis.
Alors on a cherché une signature. Deux fragments de texte collés, l'un qui finit par une espace, l'autre qui commence par une espace ou un point. Ou un paragraphe complètement vide. Un scan de tout le blog, environ un millier de documents, et une quarantaine de pages touchées. Réparées par lots, jusqu'à ce que le scan ne remonte plus qu'une seule page, laissée de côté volontairement.
Le dernier piège : le mauvais pays, la phrase fantôme
En septembre, en posant les liens d'un nouveau groupe d'articles, on est tombés sur deux défauts en série. Environ un tiers des liens en attente pointaient vers la version française de la page cible, alors qu'ils partaient d'un article en allemand ou en polonais. Et un autre tiers attendait un texte d'ancre qui n'existait tout simplement pas dans l'article.
On a donc audité tout le corpus, plus d'un millier d'articles. On a repointé chaque lien vers la version dans la bonne langue. Le contrôle a aussi trouvé un article allemand qui faisait un lien vers sa propre version anglaise. Nous avons retiré ce lien vers une autre traduction du même article.
Ce que je retiens
Le maillage reconstruit suit des règles communes et passe par le pipeline de publication. Mais les défauts trouvés ensuite montrent la limite d'un suivi théorique : il faut comparer les liens prévus aux liens réellement présents dans les contenus. La purge avait rendu notre ancien inventaire obsolète, et la reconstruction devait être contrôlée langue par langue.
Contrôler aussi les redirections
Nous avons également audité les redirections de l’ancien site vers le nouveau. Quatre familles de défauts sont décrites dans l’article suivant : un millier de redirections, zéro 404.