Muffet : détecter tous les liens morts de votre site web en quelques secondes
Vos liens morts vous coûtent plus cher que vous ne le croyez
Il existe une statistique que peu de webmasters ont envie de regarder en face : sur un site de quelques centaines de pages qui vit depuis cinq ou six ans, une part significative des liens sortants ne mène tout simplement plus nulle part. Le blog que vous citiez a fermé, la documentation a été réorganisée, le dépôt GitHub a été renommé. Et pendant ce temps, votre page continue tranquillement de pointer vers le vide.
Le souci, c'est que personne n'a envie de cliquer manuellement sur quatre mille liens pour vérifier. C'est le genre de corvée pour laquelle on invente des outils, et Muffet fait précisément cela, avec une rapidité qui surprend la première fois.
Muffet, vérificateur de liens morts pour sites web
Logo officiel de Muffet - Crédit photo : © Raviqqe.com
Muffet, le vérificateur de liens qui ne traîne pas
Muffet est un link checker écrit en Go, publié sous licence MIT par le développeur Raviqqe. Le principe tient en une phrase : vous lui donnez une URL de départ, il explore récursivement toutes les pages du site, extrait chaque lien qu'il rencontre, puis vérifie un par un que la ressource pointée répond bien.
Là où beaucoup d'outils similaires se contentent des balises "<a>", Muffet ratisse nettement plus large. Il inspecte les liens hypertextes, mais aussi les images, les feuilles de style, les scripts : bref, tout ce qu'un navigateur irait réellement chercher pour afficher correctement votre page. Le résultat est parlant. Vous ne découvrez pas seulement les vieux articles qui pointent vers des sites disparus, mais aussi la police d'écriture hébergée ailleurs ou le script tiers dont l'URL a changé il y a huit mois sans que personne ne s'en aperçoive.
Le projet est activement maintenu, largement adopté — plus de 2 600 étoiles sur GitHub — et le choix du langage Go a deux conséquences très pratiques : un binaire unique sans dépendance, et une gestion de la concurrence qui explique la vitesse annoncée. Par défaut, Muffet ouvre jusqu'à 512 connexions HTTP simultanées. Vous voyez l'ordre de grandeur.
Une installation en une ligne
https://github.com/raviqqe/muffet/releases
Trois chemins s'offrent à vous, selon vos habitudes. Si vous avez déjà Go sur votre machine :
go install github.com/raviqqe/muffet/v2@latest
Sous macOS ou Linux, Homebrew fait le travail :
brew install muffet
Et si vous préférez ne rien installer du tout, l'image Docker officielle est disponible :
docker run raviqqe/muffet https://www.exemple.com
L'usage se résume ensuite à passer l'adresse de votre site en argument : Muffet part de cette page, suit les liens internes, teste tout ce qu'il croise et vous rend un rapport. Sur un site statique de taille moyenne, l'opération se compte en dizaines de secondes.
Le paramétrage, c'est là que ça devient intéressant
La commande nue suffit pour un premier essai, mais les options font toute la différence dès que vous passez sur un site réel.
Cadrer le périmètre de l'analyse
Les drapeaux --exclude et --include acceptent des expressions régulières et vous permettent d'écarter les zones qui n'ont rien à faire dans l'audit : espace d'administration, URL de partage réseaux sociaux, moteur de recherche interne. L'option --one-page-only limite le contrôle aux liens présents sur l'URL fournie, ce qui est parfait pour tester une page précise avant publication. À l'inverse, --follow-sitemap-xml vous fait partir de votre plan de site, et --follow-robots-txt impose à Muffet de respecter les règles que vous avez déjà écrites pour les moteurs de recherche. Enfin, --ignore-fragments évite de traiter séparément les ancres d'une même page.
Ne pas mettre votre serveur à genoux
512 connexions simultanées, c'est confortable pour l'auditeur, beaucoup moins pour un hébergement mutualisé. Les options --max-connections et --max-connections-per-host vous permettent de réduire la voilure, tandis que --rate-limit plafonne le nombre de requêtes par seconde. Ajoutez --timeout pour ajuster le délai d'attente, fixé à dix secondes par défaut, et --max-retries pour donner une seconde chance aux serveurs capricieux plutôt que de les déclarer morts un peu vite.
Décider de ce qui compte comme une erreur
Par défaut, Muffet considère comme valides les codes de réponse de la plage 200. Le drapeau --accepted-status-codes vous laisse redéfinir ce périmètre, ce qui devient vite indispensable face aux services qui répondent 403 aux robots. Vous pouvez également injecter vos propres en-têtes HTTP avec --header — pratique pour un user-agent personnalisé ou un jeton d'authentification —, passer par un proxy ou pointer un résolveur DNS particulier.
Des liens morts, un vrai sujet de sécurité
On range volontiers les liens cassés dans la catégorie « confort de lecture » ou « référencement ». C'est très en dessous de la réalité.
Un lien qui pointe vers un domaine expiré n'est pas un lien mort : c'est un lien disponible à l'achat pour n'importe qui.
Le mécanisme est connu et régulièrement exploité. Un domaine cité par des centaines de sites arrive à expiration, un tiers le rachète pour quelques euros, et récupère instantanément tout le trafic résiduel ainsi que la crédibilité que vos pages lui prêtent encore. Ce trafic peut alors être redirigé vers du contenu publicitaire, une page d'hameçonnage, ou pire. Vos visiteurs, eux, ont simplement cliqué sur un lien depuis un site en qui ils ont confiance : le vôtre.
Le risque grimpe encore d'un cran lorsqu'il s'agit de ressources actives. Une balise de script pointant vers une bibliothèque JavaScript hébergée sur un domaine abandonné, c'est une exécution de code arbitraire offerte sur un plateau à celui qui reprendra l'adresse. Même logique pour les sous-domaines pointant vers des services cloud désactivés, cible classique du subdomain takeover. Muffet ne fait pas la différence entre ces cas de figure et une simple faute de frappe, mais il vous donne la liste complète — et cette liste est le point de départ obligatoire de tout nettoyage sérieux.
Automatiser, plutôt que de recommencer chaque année
Le véritable intérêt de l'outil se révèle quand vous cessez de le lancer à la main. Muffet sait produire ses résultats en trois formats via l'option --format : du texte lisible par un humain, du JSON à faire avaler à vos propres scripts, et du JUnit XML directement interprétable par la plupart des plateformes d'intégration continue.
Concrètement, vous ajoutez une étape à votre chaîne de publication : à chaque mise en ligne, Muffet passe sur la préproduction et fait échouer la construction si un lien casse. Le problème est traité au moment où il apparaît, pendant que son auteur s'en souvient encore, au lieu d'être découvert trois ans plus tard par un visiteur agacé.
Ce qu'il faut garder en tête
Muffet vise explicitement les sites statiques. Il lit le HTML servi par le serveur, sans exécuter le JavaScript : une application monopage qui construit sa navigation côté client ne sera donc que partiellement explorée. Attendez-vous par ailleurs à un certain nombre de faux positifs. Les grandes plateformes et les services derrière un pare-feu applicatif répondent volontiers par un refus ou une limitation de débit aux requêtes automatisées, sans que le lien soit pour autant invalide. C'est précisément à cela que servent --accepted-status-codes, --header et --rate-limit : quelques minutes de réglage vous éviteront de courir après des alertes fantômes.
Une dernière recommandation de bon sens : un outil qui envoie des centaines de requêtes par seconde ne se pointe que sur des sites dont vous avez la responsabilité. Ailleurs, le comportement s'apparente à un balayage non sollicité.
Pour le reste, Muffet appartient à cette catégorie d'outils discrets qui règlent un problème précis, sans configuration interminable ni interface superflue. Un binaire, une URL, et une liste de choses à corriger. Difficile de faire plus direct.
