Détecter et corriger les liens morts (404) d’un site avec n8n et l’IA

Un lien mort ne casse rien de visible : la page continue de s’afficher pour tout le monde, sauf pour la personne qui clique sur ce lien précis et atterrit sur une 404. C’est justement ce qui le rend dangereux — personne ne le voit avant qu’un visiteur, ou pire, le robot d’exploration de Google, ne tombe dessus. Ce guide construit dans n8n un pipeline qui parcourt le sitemap XML d’un site, vérifie chaque URL sans interrompre le workflow au premier code d’erreur, puis laisse un LLM proposer la meilleure redirection — avant un rapport hebdomadaire validé par un humain, jamais une correction automatique en production.

Un phénomène mesuré, pas une inquiétude de rédacteur

L’idée que les liens « pourrissent » avec le temps n’est pas propre au web grand public — elle a été étudiée en profondeur dans un contexte où la précision de la citation compte particulièrement : le droit et la recherche scientifique. Zittrain, Albert et Lessig, dans leur étude Perma: Scoping and Addressing the Problem of Link and Reference Rot in Legal Citations (2014), montrent que plus de 70 % des liens cités dans les grandes revues de droit américaines et près de la moitié de ceux cités dans les décisions de la Cour suprême ne pointent plus vers le contenu original. Klein et al., dans Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot (PLOS ONE, 2014), retrouvent le même mécanisme sur plus d’un million de liens extraits d’articles scientifiques : un article sur cinq perd l’accès au contexte web qu’il cite, une proportion qui grimpe à sept sur dix parmi les articles qui citent effectivement des ressources web. Un blog qui maille abondamment ses articles entre eux — comme celui-ci — n’échappe pas à cette mécanique : chaque renommage de slug, chaque suppression de page produit ou d’article obsolète laisse potentiellement une trace de liens cassés ailleurs sur le site.

Ce que le workflow doit accomplir

Quatre étapes : lister toutes les URLs du site depuis le sitemap, vérifier leur code de réponse HTTP sans faire planter le workflow au premier 404 rencontré, faire proposer par un LLM une page de remplacement parmi les URLs encore valides, puis livrer un rapport hebdomadaire — sans jamais toucher à la configuration du site automatiquement.

Étape 1 — Extraire toutes les URLs depuis le sitemap XML

Un Schedule Trigger déclenche, une fois par semaine, un node HTTP Request en GET sur https://votredomaine.fr/sitemap.xml. La réponse XML passe par le node XML pour être convertie en JSON exploitable, puis un node Split Out isole chaque <url><loc> en item individuel — la même mécanique que celle détaillée dans notre guide Split Out et Aggregate. À ce stade, vous avez un item n8n par URL publiée sur le site : c’est la liste de référence des pages « vivantes » qui servira aussi bien à vérifier les liens qu’à proposer des redirections plus tard.

Étape 2 — Vérifier chaque URL sans interrompre le workflow

C’est le piège classique : par défaut, le node HTTP Request de n8n traite toute réponse hors plage 2xx comme une erreur et arrête l’exécution — exactement l’inverse de ce qu’on veut ici, où un 404 est une donnée à collecter, pas un incident. Deux réglages dans les Options du node changent ce comportement :

• Never Error : la requête est considérée comme réussie quel que soit le code HTTP retourné.
• Include Response Headers and Status : le code de statut devient disponible dans la sortie (statusCode), au lieu d’être simplement avalé.

Ce second node HTTP Request tourne en HEAD (plus léger qu’un GET complet, puisque seul le code de statut compte ici) à l’intérieur d’un Loop Over Items, avec un lot de quelques URLs à la fois et un court délai entre chaque lot — pour ne pas cogner le serveur vérifié avec des centaines de requêtes simultanées. Notre guide HTTP Request : retry, timeout et appels API fiables détaille les réglages de tolérance aux lenteurs réseau, utiles ici puisqu’un simple timeout ne doit pas être confondu avec un vrai lien mort. Un node IF en sortie route ensuite les URLs par tranche de code : statusCode >= 400 part vers la branche de diagnostic, le reste est simplement journalisé pour l’historique.

Étape 3 — Laisser l’IA proposer la meilleure redirection

Une fois une URL cassée identifiée, la question n’est pas seulement « est-elle morte ? » mais « vers quoi la rediriger ? ». Un node AI Agent reçoit l’URL cassée, le texte d’ancrage ou le contexte de la page qui pointait vers elle, et la liste des URLs encore valides récupérée à l’étape 1. Sa tâche : identifier la page de destination la plus proche sémantiquement — un article renommé, une page produit remplacée par une nouvelle référence — plutôt qu’une redirection générique vers la page d’accueil, qui dilue à la fois l’expérience utilisateur et la valeur SEO du lien entrant.

Forcez une sortie structurée avec le Structured Output Parser : { "brokenUrl": "...", "suggestedTarget": "...", "confidence": 0.8, "reason": "..." }. En dessous d’un seuil de confiance (0,6 par exemple), le champ suggestedTarget reste vide plutôt que de forcer une proposition peu fiable — mieux vaut un rapport qui dit « aucune correspondance claire » qu’une redirection suggérée au hasard.

Étape 4 — Rapporter, jamais corriger automatiquement

Le workflow s’arrête volontairement avant la mise en production de la redirection. Le rapport hebdomadaire — envoyé par email ou dans un canal Slack dédié — liste chaque URL cassée, le texte source qui la citait, la redirection suggérée par l’IA et son score de confiance. C’est exactement le même principe de garde-fou que celui détaillé dans notre guide sur l’approbation humaine avec le node Wait et Slack : l’IA propose, un humain valide avant que quoi que ce soit ne change dans la configuration réelle du site.

Ce rythme hebdomadaire n’est pas arbitraire : les études citées plus haut montrent que le pourrissement des liens est un processus continu, pas un événement ponctuel qu’un audit annuel suffirait à couvrir. Un contrôle récurrent, même léger, détecte le problème pendant qu’il est encore une poignée de pages plutôt qu’un chantier de rattrapage de plusieurs centaines de liens. Le sujet est proche, mais distinct, de celui traité dans notre guide sur le content decay et le déclin de trafic SEO : là, une page perd son trafic sans disparaître ; ici, elle a purement et simplement cessé d’exister quelque part dans votre propre maillage — et notre guide sur le rapport SEO hebdomadaire Search Console complète naturellement ce contrôle en surveillant, lui, l’impact sur les positions et les clics.

Pour aller plus loin

Ce workflow reprend la même mécanique de journalisation — chaque décision tracée, chaque action soumise à validation humaine — que celle détaillée dans le Pack Conformité & Audit (149 €), directement transposable ici pour garder un historique des liens corrigés au fil des mois. Si votre priorité immédiate est plutôt une boîte mail qui déborde, le Pack Inbox IA (79 €) applique la même logique de tri et d’alerte à vos emails ; et le Bundle FlowKit Complet (269 € au lieu de 347 €) réunit les trois packs sur une base commune si vous comptez enchaîner plusieurs automatisations de ce type.