Erreurs 404 et 5xx des crawler : le voir dans les log SEO

Certaines erreurs ne se voient nulle part. Vous ouvrez la page dans votre navigateur : elle s'affiche parfaitement, code 200. Mais quand Googlebot la demande, le serveur lui renvoie une 404 ou une 500. Ce type d'écart silencieux échappe à la plupart des outils, car ils testent le site comme un visiteur, pas comme un robot. Seuls les logs enregistrent ce que les robots reçoivent vraiment. Cet article explique comment débusquer ces erreurs et pourquoi elles pèsent lourd en SEO.

Comprendre les codes d'erreurs HTTP

Les codes de statut HTTP sont le langage par lequel votre serveur répond aux robots.

• 404 (Not Found) : la ressource n'existe pas. Ponctuel, c'est normal ; récurrent sur des URL importantes, c'est un problème de liens internes ou de sitemap.
• 410 (Gone) : la ressource a été volontairement supprimée. Signal plus fort et plus propre qu'une 404 pour dire à Google d'oublier une URL.
• 500 (Internal Server Error) : le serveur a planté sur cette requête. Aux yeux du moteur, c'est un signe de fragilité.
• 503 (Service Unavailable) : indisponibilité temporaire. Acceptable ponctuellement (maintenance), inquiétante si elle persiste.

Le principe SEO est simple : Googlebot interprète des erreurs répétées comme un signal de qualité dégradée. Un site qui sert régulièrement des 5xx voit sa fréquence de crawl se réduire, car le moteur ralentit pour ne pas aggraver une charge serveur qu'il suppose problématique.

Le cas silencieux : 200 pour l'humain, erreur pour le robot / crawler

C'est l'erreur la plus difficile à détecter, et souvent la plus coûteuse. Plusieurs causes produisent cet écart entre ce que voit un visiteur et ce que reçoit un robot.

• Cache et CDN : une version en cache sert un 200 aux humains pendant que l'origine renvoie une erreur aux robots, ou l'inverse.
• Blocage par user-agent : une règle de sécurité mal réglée refuse Googlebot en croyant bloquer un scraper, et lui répond 403 ou 404.
• Géolocalisation : le serveur route différemment selon l'IP ; les IP de Google, souvent américaines, tombent sur une version différente.
• Rendu JavaScript : la page se construit côté client ; sans exécution du script, le robot reçoit une coquille vide ou une erreur.

Aucun de ces cas n'apparaît quand vous testez le site vous-même. Seule la ligne de log, qui enregistre le code réellement servi à l'IP de Googlebot, les révèle. C'est l'illustration la plus nette de l'intérêt des logs : ils voient le site à travers les yeux du robot, pas les vôtres.

La méthode pour les repérer

1. Isoler les robots vérifiés

On commence par ne garder que les vrais robots, authentifiés par leur IP, sans quoi on chasserait des erreurs servies à de faux Googlebot sans intérêt. Cette étape préalable est décrite dans l'article Identifier Googlebot et démasquer les faux Googlebot.

2. Filtrer sur les codes non-200

On extrait ensuite toutes les requêtes robots dont le code n'est pas un 200 (ni une 304, réponse normale de non-modification). On obtient la liste brute des points de friction rencontrés par les moteurs.

3. Regrouper, dater, prioriser

On agrège par URL pour faire remonter les erreurs récurrentes, on les date pour distinguer un incident ponctuel d'un problème chronique, et on priorise selon l'importance des pages touchées. Une 5xx sur une page pilier crawlée quotidiennement passe avant une 404 sur une vieille URL oubliée.

Corriger selon la cause

Le traitement dépend du diagnostic. Une 404 sur une URL qui devrait exister appelle une redirection 301 vers l'équivalent pertinent, ou la réparation du lien interne fautif. Une URL définitivement supprimée gagne à répondre en 410 plutôt qu'en 404, pour accélérer sa sortie de l'index. Une 5xx récurrente relève de l'infrastructure : logs applicatifs, capacité serveur, requêtes lentes. Quant aux écarts 200/erreur, ils se règlent en alignant la configuration (cache, sécurité, géolocalisation) sur un comportement identique pour humains et robots.

Attention aux redirections : corriger une 404 par une 301 est bon, mais enchaîner les redirections crée une chaîne qui consomme du budget de crawl. Chaque saut est une requête de plus. Ce lien entre erreurs, redirections et budget est approfondi dans le cluster consacré au budget de crawl.

Un suivi des erreurs à intégrer dans la durée

Les erreurs vues par les robots ne sont pas un audit ponctuel mais un indicateur à surveiller. Une refonte, une migration, une mise à jour de CMS ou une nouvelle règle de sécurité peuvent en introduire du jour au lendemain. Comparer la répartition des codes de réponse d'une période à l'autre, comme nous le recommandons dans l'article sur les KPI, permet de détecter ces régressions avant qu'elles n'entament vos positions.

Est-ce que j'ai trop d'erreurs HTTP dans mes log SEO ?

Aucun site n'affiche zéro erreur, et ce n'est pas l'objectif. Des 404 existent toujours : liens externes obsolètes, anciennes URL supprimées, sondages de robots. La question n'est donc pas « y a-t-il des erreurs ? » mais « quelle est leur part, et sur quelles pages ? ». Un repère simple : la grande majorité des réponses servies aux robots devrait être des 200 (ou des 304). Dès que les codes d'erreur et les redirections captent une fraction notable du crawl, du budget se dissipe et un signal de qualité se dégrade.

Plus que le volume brut, c'est la nature et la localisation des erreurs qui comptent. Dix 404 sur de vieilles URL sans importance sont anecdotiques ; une seule 5xx récurrente sur une page pilier crawlée quotidiennement est prioritaire. La règle : pondérer chaque erreur par l'importance de la page touchée et par sa fréquence de crawl. C'est ce croisement qui transforme une longue liste d'erreurs en une file de corrections classée par impact.

Un diagnostic pas à pas

Prenons un cas typique. Après une migration, le trafic organique baisse sans explication évidente dans Search Console. L'analyse des logs suit alors un fil clair. Première étape : la répartition des codes révèle une hausse nette des 301. Deuxième étape : en regroupant par URL, on découvre des chaînes de redirections : l'ancienne URL redirige vers une deuxième, qui redirige vers la page finale. Chaque page coûte désormais deux requêtes de crawl au lieu d'une. Troisième étape : quelques anciennes URL, oubliées dans la table de redirection, répondent carrément en 404, coupant le lien entre le contenu migré et l'autorité qu'il avait accumulée.

Le remède découle du diagnostic : aplatir les chaînes pour que chaque ancienne URL pointe en une seule redirection vers sa destination finale, et rétablir les 404 fautives en 301 correctes. Invisible dans un audit classique, ce problème saute aux yeux dans les logs, et sa correction restaure souvent le trafic en quelques semaines.

410 ou 404 : bien choisir son signal

Quand une page disparaît pour de bon, deux réponses sont possibles, et le choix a des conséquences. Une 404 dit au moteur « je ne trouve pas cette page » ; il reviendra la tester plusieurs fois avant d'abandonner, par prudence. Une 410 dit « cette page a été volontairement supprimée » ; le signal est plus fort et plus définitif, et Google la retire généralement plus vite de son index. Pour une suppression assumée, produit retiré du catalogue, article obsolète dépublié : la 410 est le choix propre ; on réserve la 404 aux absences involontaires ou incertaines. Ce niveau de finesse, détaillé dans l'article sur les codes de statut HTTP, évite de laisser traîner dans l'index des URL mortes qui diluent la qualité perçue du site.

Prévenir plutôt que guérir : les moments à risque

Les erreurs vues par les robots n'arrivent pas au hasard. Elles surgissent surtout lors d'événements précis : migration de site, changement de CMS, mise à jour d'une règle de sécurité ou de pare-feu, refonte de l'arborescence, déploiement d'un CDN. À chacun de ces moments, il est prudent de programmer une analyse de logs dans les jours qui suivent, plutôt que d'attendre que la baisse de trafic sonne l'alarme. Détecter une régression de codes de réponse tôt, c'est la corriger avant qu'elle n'entame les positions : le contraire du réflexe habituel, qui consiste à diagnostiquer une fois le mal fait.

→ L'analyseur de logs CrawlLab classe automatiquement les codes de réponse par robot et par date : repérez en un coup d'œil les 404 et 5xx que Googlebot rencontre, y compris celles invisibles depuis votre navigateur.

À lire aussi

• Analyse de logs serveur pour le SEO : le guide complet
• Analyse de logs SEO : quels KPI suivre et comment les interpréter