Liens internes cassés : comment les détecter ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Définir un lien interne réellement cassé

Un lien interne est cassé lorsque la page source de votre propre site envoie vers une destination qui n’est plus utilisable comme prévu. Le cas le plus évident est une réponse 404 ou 410, mais une erreur serveur persistante, une URL mal formée ou une ancienne route supprimée peuvent produire le même résultat pour le visiteur. Le diagnostic concerne le graphe interne : menus, breadcrumbs, cartes, sommaires et liens contextuels. Une redirection qui conduit correctement vers une ressource valide n’entre pas dans cette catégorie ; elle doit être examinée séparément comme chemin indirect.

Retrouver l’origine de chaque référence obsolète

Les liens cassés apparaissent souvent après une migration, un changement de slug, une suppression de contenu ou une refonte de navigation. Le point important est de ne pas se limiter à la cible en erreur. Il faut conserver la page source, l’ancre, le href exact et le composant qui génère le lien. Une même 404 présente dans cinquante pages peut provenir d’un template commun, alors que cinquante cibles différentes traduisent plutôt un nettoyage éditorial incomplet. Cette distinction change complètement la manière de corriger et l’ordre de priorité.

Construire un crawl source vers destination

Exportez les liens internes avec leur statut final et regroupez-les par cible. Vérifiez le HTML réellement rendu, y compris les liens ajoutés par JavaScript si le site en dépend. Testez les chemins relatifs, variantes de slash, ancres de fragment et normalisations d’URL. Pour les erreurs temporaires, répétez le contrôle avant de conclure à une suppression durable. Une réponse 403, 429 ou un timeout n’a pas le même sens qu’une 404 stable. L’objectif est de qualifier chaque occurrence avec suffisamment de contexte pour éviter une correction automatique mal adaptée.

Décider si la destination doit encore exister

Avant de remplacer le lien, demandez-vous si la page cible avait encore une fonction utile. Si une nouvelle page couvre réellement le même besoin, la source peut pointer directement vers elle. Si le contenu a été retiré sans équivalent, supprimer le lien est parfois plus honnête qu’envoyer vers une catégorie générique. Restaurer une page peut être pertinent lorsqu’une suppression était accidentelle. Une redirection permanente n’est justifiée que si la relation entre ancienne et nouvelle ressource est claire. Le but est de préserver la navigation, pas de transformer toute erreur en redirection artificielle.

Prioriser les liens qui structurent le site

Un lien cassé dans un hub, un menu ou un contenu très consulté mérite une intervention plus rapide qu’une référence isolée dans une archive secondaire. Comptez le nombre de pages sources, regardez la profondeur des destinations et identifiez les pages de conversion ou de connaissance importantes. Les défauts générés par un composant global ont aussi une portée particulière car une seule correction peut résoudre de nombreuses occurrences. Cette priorisation évite de consacrer le même temps à tous les liens et permet de traiter d’abord ceux qui dégradent réellement la découverte ou le parcours utilisateur.

Vérifier que la correction ne déplace pas le problème

Après modification, relancez le crawl avec les mêmes règles. La page source doit maintenant pointer vers une destination valide, directement accessible et cohérente avec le texte de l’ancre. Contrôlez la canonical de la cible et assurez-vous que le nouveau href ne crée pas une chaîne de redirections. Si plusieurs pages dépendaient d’un template, vérifiez un échantillon représentatif au lieu d’une seule URL. Conservez les couples avant/après afin de pouvoir mesurer la disparition du défaut et détecter une régression lors d’une prochaine migration ou d’un changement de taxonomie.

Clôturer avec une preuve reproductible

Une alerte peut être fermée lorsque la source, l’ancienne destination, la décision et le résultat final sont documentés. Pour une correction massive, gardez le nombre d’occurrences initiales et le nombre restant après recrawl. Pour une page volontairement supprimée, notez pourquoi aucun remplacement n’a été retenu. Cette trace est particulièrement utile lorsque plusieurs équipes interviennent sur le CMS ou le contenu. Elle permet de distinguer une résolution durable d’un simple changement de symptôme et évite que l’ancien href soit réintroduit plus tard par un template ou un import.

Checklist opérationnelle de validation

Pour clôturer ce contrôle sur liens internes cassés, conservez au minimum une URL représentative, l’état avant modification, la règle ou le composant responsable et le résultat du test après correction. Vérifiez également la cohérence avec le parent /seo/maillage-interne et les pages liées /seo/maillage-interne, /seo/pages-orphelines, /seo/liens-internes-vers-redirections. La décision doit respecter cette limite : Définir un lien interne cassé par sa destination réellement inaccessible ou en erreur. Ne pas classer une redirection fonctionnelle comme lien cassé ni promettre un effet direct sur le classement. Si plusieurs occurrences partagent la même cause, testez un échantillon puis confirmez le résultat par un crawl global. Si un cas reste ambigu, laissez-le en revue plutôt que d’appliquer une correction mécanique. Cette trace permettra de reproduire le diagnostic lors d’une prochaine refonte, migration ou évolution du CMS.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

Comment détecter et corriger les liens internes cassés ?