Liens morts

Il est inévitable, surtout quand on crée beaucoup de liens, de se retrouver confronter à des liens morts. C’est ce que l’on appelle le link-rot.

Par soucis de transparence, pour faciliter le suivi des liens morts et pour inciter mes éventuels lecteurs vers lesquels j’ai créé un lien devenu mort à m’indiquer comment le corriger, je présente ici une page générée automatiquement, contenant le rapport des liens morts détectés sur mon site.

Je m’efforce d’automatiser le processus de détection de ces liens morts, autant pour les liens internes à mon site que pour les liens externes. S’il est parfaitement légitime de me tenir pour responsable de la vivacité de mes propres liens internes, personne ne peut me rendre responsable des liens externes. Ce n’est pas mon travail. Je n’ai aucune obligation de maintenir un outil de vérification et la transparence des résultats. Je le fais par plaisir du travail bien fait et par respect pour mes visiteurs, mais je n’ai aucune emprise sur les nombreux facteurs externes déterminant si un lien est accessible ou non par mon outil.

Méthodologie

Le script utilise désormais un fetch HTTP maison (basé sur undici) qui :

• génère un user-agent réaliste à chaque exécution (bibliothèque user-agents)
• envoie d’abord une requête HEAD puis, en cas d’échec ou de code ≥ 400, une requête GET après un délai de 5s
• suit les redirections manuellement (jusqu’à 5 sauts) et abandonne au-delà
• applique un timeout de 5 s par requête
• envoie des en-têtes classiques d’un navigateur (Accept, Accept-Language)
• n’enregistre pas de cookies

Trois cas de figure se présentent à ce stade.

Code HTTP entre 200 et 400

Mon outil considère systématiquement qu’un code HTTP supérieur à 200 et strictement inférieur à 400 est une page accessible.

Cela peut générer des faux positifs (des pages considérées comme accessibles, mais qui ne le sont pas), notamment dans les cas suivants :

• Si le site affiche une page d’erreur sans relayer le code HTTP correspondant à l’erreur
• L’URL est conservée pour un contenu totalement différent de la page originale

Lorsque je constate qu’un URL retourne un code strictement inférieur à 400, il n’est pas re-testé avant 1 mois.

Code HTTP entre 400 et 499

Toute réponse avec un code HTTP compris entre 400 et 499 est considérée comme une erreur, dans le respect de la RFC 7231.

Cela génère de nombreux faux négatifs (des pages considérées comme inaccessibles alors qu’elles le sont), symptomatiques d’une volonté de blocage des techniques de navigation automatisée, ou d’un problème de paramétrage de mon outil.

Par construction, par honnêteté intellectuelle et par bienveillance, mon outil est développé de manière à ne pas être intrusif. Son “paramétrage” permettrait en théorie d’exploiter des techniques plus agressives afin de limiter ces faux négatifs. J’ai fait le choix délibéré de ne pas rendre mon outil plus agressif, et de marquer tout lien retournant un code supérieur ou égal à 400 comme étant inaccessible, peu importe la raison réelle.

Je considère que ne pas respecter la RFC 7231 est une pratique destructive. Donc les serveurs qui répondent avec un code inapproprié doivent être marqués comme étant inaccessibles.

Le problème ici est que, si l’on retourne une erreur 403 pour un contenu qui existe réellement, sous prétexte que la navigation ne s’est pas faite avec un navigateur “traditionnel”, il n’est pas possible pour moi de savoir si la page a été déplacée, si j’ai commis une erreur dans le copier-coller de l’URL, ou si j’ai accédé à un URL protégé par un mot de passe (un exemple de motif légitime d’utilisation de l’erreur 403).

Il existe trop de ces cas de figure pour que j’accepte de prendre le temps de les identifier manuellement.

Les requêtes ayant abouti à un code HTTP compris entre 400 et 499 ne sont pas réitérées avant 1 semaine.

Code HTTP supérieur ou égal à 500

Les requêtes ayant abouti à un code HTTP supérieur ou égal à 500 ne sont pas réitérées avant 1 jour : ces erreurs sont censées être légitimes, transitoires et promptement corrigées.

J’ai néanmoins identifié que certains serveurs répondent à un navigateur automatisé avec une erreur 500. Je refuse de constituer et de maintenir une liste de ces serveurs.

Timeout

De nombreux sites ont fait le choix de punir la navigation automatisée en ne répondant tout simplement pas à la requête, en laissant le client “tourner dans le vide”. Il n’est donc pas possible, pour un script bienveillant, de savoir si le serveur distant bloque la requête ou s’il s’agit d’un problème transitoire.

On pourrait ergoter longtemps sur le bienfondé (ou pas) de cette technique. Pour ma part, je considère qu’elle est destructive. Donc les serveurs qui ne répondent jamais doivent être marqués comme étant inaccessibles, parce que certains d’entre eux peuvent réellement être temporairement inaccessibles.

Les requêtes ayant abouti à un timeout ne sont pas renouvelées avant 1 semaine.

Autres cas

Il arrive que le fetch me renvoie un statut nul/0 (qui n’existe pas réellement). Dans la majorité des cas, le problème est lié aux certificats du serveur (obsolescence, nom de domaine qui ne correspond pas, etc.) ou à un refus de connexion.

Les requêtes aboutissant à un code HTTP 0 ou à une erreur réseau ne sont pas renouvelées avant 1 semaine.

Rapport