Un client m'appelle un mardi matin, paniqué. Son site e-commerce fait 480 000 URL indexées, et son rapport de crawl vient de lui sortir 12 847 liens en 404. Il veut que je « répare tout ». Je lui ai répondu qu'on n'allait en réparer que 40, et que ça suffirait. Il a cru que je me fichais de lui.
Trois semaines plus tard, son trafic organique était remonté de 11 %. On n'avait touché qu'à 62 URL au total. Le reste des 12 785 liens brisés ? Des paramètres de tri, des pages de pagination profonde, des vieilles URL de filtres que personne n'atteignait. Voilà le vrai problème quand on cherche comment détecter les liens brisés sur un grand site : ce n'est pas de les trouver. C'est de ne pas se noyer dedans.
Points clés à retenir
- Sur un gros site, un crawl complet sort des milliers de 404 dont la majorité n'a aucun impact : la priorisation compte plus que la détection.
- Les logs serveur révèlent les vrais 404 vus par les utilisateurs, là où un crawler invente parfois des erreurs que personne ne rencontre.
- Découpez le crawl par sitemaps ou par répertoires : 500 000 URL en un seul passage, ça échoue ou ça coûte une fortune en crédits.
- Un lien cassé souvent cliqué mérite une redirection 301. Un lien cassé jamais cliqué mérite un 410.
- Le monitoring continu (cron, CI/CD, alertes) bat le grand nettoyage annuel.
Détecter les liens brisés sur un grand site : la réalité des volumes
Sur un site de 50 pages, vous lancez un outil gratuit, vous avez 3 erreurs, vous les corrigez en buvant un café. Sur 500 000 URL, la même logique produit un fichier CSV de 40 Mo que personne n'ouvrira jamais.
La différence n'est pas une question d'échelle. C'est une différence de nature. Un petit site se traite exhaustivement. Un grand site se traite par échantillonnage et par priorité.
Pourquoi un crawl complet vous ment à moitié
Un crawler ne voit pas ce que voient vos visiteurs. Il suit des liens dans le HTML, parfois dans des scripts, et il déclenche des URL que seuls des robots explorent. J'ai vu un site d'actualités où le crawl remontait 8 000 « liens brisés » qui étaient en fait des URL de partage social générées dynamiquement — jamais cliquées par un humain, jamais indexées, sans aucune valeur.
À l'inverse, le crawler rate ce qui se passe côté serveur. Les erreurs 404 provoquées par un formulaire mal configuré, une API qui renvoie une page vide, un redirect en boucle sur un sous-domaine mobile : tout ça vit dans les logs, pas dans le HTML.
Le crawl vous donne une carte. Les logs vous donnent la circulation réelle. Il vous faut les deux.
Découper le crawl pour ne pas exploser le budget
Concrètement, voici comment je procède sur un site au-delà de 100 000 URL :
- Je récupère la liste des sitemaps déclarés et je les segmente par type de contenu (produits, catégories, articles, pages statiques).
- Je crawle un segment à la fois, avec une limite de profondeur et une limite de pages par répertoire.
- Je désactive le suivi des paramètres d'URL inutiles (tri, filtre, session) via les règles du crawler, sinon je double le nombre de pages visitées pour rien.
- Je fixe un délai entre requêtes réaliste — sinon je me fais bloquer par le WAF et je perds deux heures à comprendre pourquoi le crawl renvoie des 403 partout.
Sur un site à 400 000 URL, cette segmentation m'a fait passer d'un crawl de 9 heures (qui plantait à mi-parcours) à quatre crawls de 40 minutes. Et surtout : des rapports lisibles.
Les logs serveur : la source que la plupart des gens ignorent
Voilà l'angle que je ne vois presque jamais dans les guides sur les liens brisés, et c'est pourtant celui qui change tout à grande échelle.
Vos logs d'accès contiennent chaque requête reçue par votre serveur, avec le code de statut. Filtrez les lignes en 404 et 410, croisez avec l'URL de provenance (le referer), et vous obtenez exactement ce que je veux : les liens brisés que de vrais utilisateurs ont rencontrés, avec leur contexte d'arrivée.
La requête qui fait 80 % du travail
Sur un serveur Apache ou Nginx, une commande du type grep " 404 " access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -100 vous sort le top 100 des URL en 404, classées par fréquence. Sur un mois de logs, c'est déjà une feuille de route.
Ce que ça m'a révélé sur un site de presse : une seule URL de redirection cassée, héritée d'une migration de rubrique, générait à elle seule 19 % des 404 du site. Le crawler la voyait une fois. Les logs la voyaient 40 000 fois par mois.
Et là, vous voyez l'évidence : réparer cette URL unique valait plus que réparer les 3 000 autres combinées. C'est ça, la priorisation à l'échelle.
Comment prioriser des milliers de liens cassés (la partie qui compte)
Bon, vous avez vos données. Un CSV de crawl croisé avec les logs. Maintenant il faut trancher. Voici les critères que j'applique, dans cet ordre :
- Fréquence réelle dans les logs — un lien cassé cliqué 500 fois par mois passe avant tout le reste.
- Autorité interne de la page source — un lien cassé depuis votre page d'accueil ou une page hub très liée vaut dix liens cassés depuis une page orpheline.
- Position dans le maillage — un lien en 404 dans le menu de navigation est une plaie visible ; le même en pied de page d'un vieil article, personne ne le verra.
- Type d'erreur — 404 sur une URL qui recevait du trafic avant ? Redirection 301 vers l'équivalent le plus proche. 404 sur une URL qui n'a jamais eu de trafic ? 410, ou on la laisse mourir.
- Le reste : on note, on ne touche pas.
Avouons-le, cette dernière ligne est la plus difficile à faire accepter. Les équipes techniques aiment l'idée d'un nettoyage complet. Mais passer trois semaines à corriger 3 000 liens que personne ne clique, c'est trois semaines pendant lesquelles les 40 vrais problèmes restent en place.
Un tableau de priorisation concret
| Signal | Action recommandée | Effort |
|---|---|---|
| 404 cliqué + page source à forte autorité interne | Redirection 301 immédiate | 5 minutes |
| 404 dans les logs, source peu liée | Inspecter et rediriger si trafic réel | 30 minutes |
| 404 jamais vu dans les logs, page orpheline | 410 ou laisser en l'état | 0 |
| 404 sur URL de paramètres (tri, filtre, session) | Bloquer dans robots.txt ou désindexer | 1 heure |
| Chaîne de redirections (> 2 sauts) | Corriger la cible finale | 15 minutes |
Sur le site du client dont je parlais au départ, ce tri a transformé 12 847 lignes en une liste de 58 actions. 58. En un après-midi.
Automatiser : le monitoring bat la chasse annuelle
Le vrai piège des grands sites, ce n'est pas de trouver les liens brisés une fois. C'est de les voir apparaître en continu, au fil des publications, des migrations, des refontes.
Un lien qu'on brise aujourd'hui est un lien qu'on ne cassera plus demain si on l'attrape maintenant. Ma règle : un contrôle hebdomadaire automatisé sur les URL critiques, pas un crawl complet chaque fois.
Où brancher l'automatisation
Trois endroits qui me servent concrètement :
- Un cron hebdomadaire qui crawle uniquement les pages à fort trafic (top 5 000 par analytics) et alerte s'il détecte du 404.
- Un hook dans la CI/CD : avant chaque déploiement, on vérifie que les liens du template (menu, footer, bannières) répondent bien — ça bloque une mise en prod une fois sur vingt, et c'est exactement le but.
- Une surveillance des logs en temps réel avec alerte si le taux de 404 dépasse un seuil (par exemple 2 % des requêtes sur une heure glissante). Sur un site sain, un pic soudain signale toujours une régression.
Le déploiement qui bloque la prod, c'est le scénario que personne ne prépare. J'ai vu un site où une refonte de template a rendu 3 200 URL internes cassées en une nuit. Le contrôle en CI aurait attrapé ça en deux minutes. Le crawl complet l'a attrapé trois jours plus tard, après une perte de trafic qu'on a mis deux semaines à récupérer.
Faut-il vraiment corriger absolument tous les liens brisés ?
Non. C'est même une erreur de vouloir le faire. Un lien en 404 qui ne reçoit ni clic ni lien entrant ni indexation n'a strictement aucun effet mesurable. Google ne pénalise pas un site pour avoir des 404 en soi — un 404 est une réponse HTTP parfaitement normale. Ce qui compte, c'est l'expérience de l'utilisateur qui atterrit sur une page morte, et l'autorité interne qui se perd dans le vide.
Traduit en pratique : corrigez les 404 qui ont un impact humain ou un impact de maillage. Laissez tranquilles les autres. Vouloir un site à zéro erreur est un objectif esthétique, pas un objectif de performance.
Les outils tiennent-ils la distance sur un gros site ?
Franchement, les vérificateurs de liens gratuits qu'on trouve partout sont inutilisables dès qu'on dépasse quelques milliers de pages. Ils rampent, ils se font bloquer, ou ils rendent un rapport impossible à exploiter. Pour un grand site, il faut des outils capables de crawler par lots et d'exporter proprement.
Mon approche perso : un crawler pro pour la cartographie, plus une analyse maison des logs pour la réalité terrain. Les deux ensemble coûtent moins cher que la licence d'un outil « tout-en-un » qui prétend tout faire et fait tout à moitié.
Ce qui compte au final n'est pas l'outil. C'est la question qu'on lui pose. Si vous demandez « tous les liens brisés », vous obtenez du bruit. Si vous demandez « les liens brisés qui touchent du trafic réel et du maillage fort », vous obtenez une feuille de route.
Et cette question, aucun outil ne la posera à votre place. C'est vous qui décidez quoi réparer — et surtout quoi ignorer. La prochaine fois que votre crawl vous sortira 12 000 erreurs, gardez en tête le chiffre 62. C'est le nombre d'URL qu'il a vraiment fallu toucher pour récupérer 11 % de trafic. Le reste attendra. Peut-être indéfiniment.
