Votre site vient d'être refait, ou simplement réorganisé, et la Search Console affiche une liste d'erreurs 404 qui s'allonge. Ou bien un client vous signale qu'un lien de votre page d'offre mène à une page vide. Les liens internes cassés arrivent presque toujours de la même façon : une adresse change, et les liens qui pointaient vers elle restent en place.
En réorganisant ce site, j'ai moi-même laissé derrière moi des adresses qui n'existaient plus, et je les ai redirigées une par une. Sur ce blog, ma chaîne de publication bloque aussi les liens morts avant la mise en ligne. Voici comment je les trouve, comment je décide quoi en faire, et ce que j'ai installé pour qu'ils ne reviennent pas.
01Ce qu'un lien interne cassé coûte vraiment
Il faut d'abord dégonfler une peur. Google l'écrit clairement sur son blog : les 404 sont normales sur le Web, et le fait que certaines adresses n'existent plus n'a aucune incidence sur les autres pages du site dans les résultats de recherche. Une longue liste de 404 dans la Search Console n'est pas une pénalité.
Le coût est ailleurs. Un lien interne sert à deux choses : guider le visiteur vers la suite logique de sa lecture, et permettre à Google de découvrir vos pages. Dans sa vidéo sur les liens internes, Martin Splitt, de l'équipe Google Search Central, le dit simplement : Googlebot s'en sert pour trouver les pages du site et comprendre comment elles se relient. Un lien cassé interrompt les deux.
Concrètement, cela donne un visiteur qui cherchait votre offre et tombe sur une impasse, et une page importante qui ne reçoit plus le lien qui la rendait visible. La documentation de Google recommande que chaque page importante reçoive un lien d'au moins une autre page du site. Quand ce lien unique casse, la page devient orpheline sans que personne ne s'en aperçoive.
02Trouver les liens cassés sans y passer la semaine
Je fais l'audit du maillage interne en trois passes, de la plus rapide à la plus complète.
Partir de ce que Google a vu
Le rapport sur l'indexation des pages de la Search Console a un motif « Introuvable (404) ». Google y liste les adresses qui ont renvoyé une 404, souvent repérées via un lien depuis une autre page. C'est un bon point de départ, avec une limite : le rapport montre ce que Google a croisé, pas forcément d'où vient le lien. Une partie de ces adresses viennent d'autres sites ou d'anciens liens que vous ne contrôlez pas.
Explorer le site comme un robot
Un logiciel d'exploration parcourt toutes les pages à partir de l'accueil, suit chaque lien et note son code de réponse. Ce que je regarde en premier, c'est la colonne « page source » : elle dit où se trouve le lien cassé, donc où le corriger. Je filtre ensuite sur les codes 404 et 410, puis sur les redirections en chaîne. Google suit jusqu'à 10 sauts de redirection, mais chaque saut ralentit le visiteur et rien ne justifie d'en empiler.
Vérifier les pages qui comptent, à la main
Enfin, je prends les dix pages qui portent l'activité (accueil, offres, contact, les articles qui amènent du monde) et je clique sur chacun de leurs liens, en navigation privée. C'est lent, mais c'est la seule passe qui attrape un lien vers une page qui répond en 200 et affiche pourtant un message d'erreur, ce qu'on appelle une « soft 404 ».
Pour un audit plus large avant une refonte, j'ai décrit ma méthode dans l'audit technique avant refonte.
03Corriger, rediriger ou laisser une 404
Pour chaque lien cassé, je me pose une seule question : la page que le lien visait existe-t-elle encore quelque part ?
- Elle existe, à une autre adresse : je corrige le lien dans la page source pour qu'il pointe directement vers la bonne adresse. C'est la correction que je préfère, parce qu'elle supprime le problème au lieu de le contourner.
- Elle existe ailleurs, et d'autres liens que je ne contrôle pas pointent vers l'ancienne adresse : j'ajoute une redirection permanente. Google recommande une redirection côté serveur en 301 ou 308, qu'il traite comme un signal fort ; la redirection en JavaScript ne vient qu'en dernier recours.
- Elle n'existe plus, et rien ne la remplace : je retire le lien, et je laisse l'ancienne adresse renvoyer une vraie 404 ou une 410.
Le troisième cas est celui qu'on rate le plus souvent. La tentation est de rediriger toutes les adresses mortes vers la page d'accueil. Google le déconseille : rediriger des adresses inconnues vers l'accueil peut nuire à la compréhension et à l'indexation du site, parce que le visiteur atterrit sur une page qui ne répond pas à ce qu'il cherchait. Une 404 propre, avec un message utile et un lien vers la recherche ou le menu, vaut mieux.
04Ce que j'ai fait en réorganisant ce site
J'ai construit ce site en Next.js, puis je l'ai réorganisé. Chaque changement de structure a laissé des adresses derrière lui, et je les ai déclarées dans le fichier de configuration du site.
La documentation de Next.js permet d'écrire ces redirections avec une source, une destination et un réglage permanent ou non ; une redirection permanente y renvoie un code 308. Les motifs de chemin permettent de rediriger toute une section d'un coup.
Voici ce que contient ma liste :
- la rubrique « Projets » est devenue « Missions », et toutes ses anciennes adresses mènent au portfolio ;
- les pages détail de chaque mission ont été supprimées, et leurs adresses redirigent vers le portfolio des missions ;
- l'ancienne page « à propos » mène à la page Services ;
- les adresses de l'ancien site, construit sous Webflow et encore connues de Google, sont reprises une par une ;
- une adresse sans langue mène à la version française.
J'ai aussi fait un compromis que je ne referais pas tel quel. Les articles de l'ancien blog n'ont pas été repris, et leurs adresses redirigent toutes vers la liste du blog. C'est mieux qu'une impasse pour le visiteur, mais c'est exactement le cas que Google décrit : une redirection vers une page qui ne remplace pas l'originale. Pour un ancien article qui recevait du trafic, la bonne réponse aurait été de le réécrire à la même place, ou de laisser une vraie 404.
Si vous préparez une migration de ce type, j'ai détaillé la méthode dans migrer un site vers Next.js et Sanity.
05Empêcher les nouveaux liens morts d'arriver en ligne
Corriger une fois ne suffit pas. Les liens cassés reviennent à chaque nouvel article, à chaque page renommée. Sur ce blog, j'ai donc mis le contrôle avant la publication, et non après.
Ma machine de contenu fonctionne avec un brief, puis un « gate » qui relit l'article avant de le publier. Trois contrôles concernent les liens :
- chaque lien interne est comparé à la liste des pages qui existent vraiment (pages fixes et articles publiés, lus dans le CMS) ; un lien vers une page inexistante bloque la publication ;
- en mode réseau, l'outil ouvre chaque lien externe ; une réponse 404 ou 410 bloque aussi, et l'article ne part pas tant que la source n'est pas remplacée ;
- après publication, je vérifie la page publique, en français et en anglais, avec ses liens internes en 200.
La raison est simple : un modèle de langage invente volontiers des adresses plausibles, et un humain pressé aussi. Le contrôle ne coûte rien une fois écrit. J'en parle plus largement dans ma checklist de recette avant mise en production, où la vérification des liens fait partie des points à cocher.
La limite de cette méthode
Mon contrôle vérifie les liens au moment où j'écris. Il ne voit pas un article publié il y a six mois qui pointe vers une page que j'ai supprimée hier. Pour ce cas-là, il faut toujours une exploration régulière du site, ou au minimum un regard mensuel sur le rapport d'indexation. Le plus sûr est de l'inscrire dans un rapport SEO qui part seul chaque mois, plutôt que de compter sur la mémoire de quelqu'un.
Et sur un site de plusieurs milliers de pages générées par un CMS, une liste de redirections écrite à la main devient vite ingérable. Il faut alors des règles par motif, et des tests qui les rejouent.
06Par où commencer cette semaine
Si vous ne deviez faire qu'une chose, ouvrez le rapport d'indexation de la Search Console et exportez les adresses en 404. Pour chacune, cherchez la page de votre site qui y mène, et appliquez la règle : corriger le lien, rediriger en 301 si la page a déménagé, ou laisser la 404 si elle n'existe plus. Comptez environ deux semaines pour que Google valide la correction.
Ensuite, notez dans un fichier chaque adresse que vous changez, au moment où vous la changez. C'est ce fichier qui vous évitera la prochaine liste.
Si votre site sort d'une refonte et que vous voulez un regard extérieur sur ses liens et ses redirections, mes services décrivent comment je travaille. On peut en parler.