Codes HTTP
Ce que chaque famille de codes signifie pour Google, et pourquoi le code servi à un robot n’est pas toujours celui que vous voyez.
Un code HTTP, ou code de statut, est le nombre à trois chiffres par lequel un serveur annonce le résultat d’une requête, avant même d’en envoyer le contenu. Son premier chiffre indique la famille de la réponse, et c’est cette famille que les moteurs de recherche lisent pour décider s’ils gardent l’URL, la retirent de l’index ou reviendront plus tard. Le code n’est pas une propriété de l’URL mais de l’échange : la même adresse peut répondre différemment selon qui la demande.
Que veulent dire les cinq familles de codes ?
La RFC 9110, qui définit la sémantique de HTTP, range les codes en cinq classes selon leur premier chiffre, et précise que ce chiffre suffit à comprendre la réponse. Les 1xx sont informationnels et annoncent que la requête est reçue et le traitement en cours. Les 2xx disent que la requête a été reçue, comprise et acceptée. Les 3xx annoncent qu’une action supplémentaire est nécessaire pour aboutir, ce qui recouvre les redirections. Les 4xx signalent une erreur du côté du client, requête mal formée ou ressource absente. Les 5xx signalent que le serveur a échoué alors que la requête paraissait valide. La spécification ajoute un point que l’on oublie souvent en audit : un client doit savoir traiter n’importe quel code de statut, et s’il en rencontre un qu’il ne connaît pas, il doit le traiter comme le code x00 de sa classe. Autrement dit, un 418 se lit comme un 400, et un 599 comme un 500.
Comment Google traite chaque famille ?
Google documente son propre traitement, et il ne recouvre pas exactement la spécification. Les 2xx conduisent à un examen du contenu, sans garantie d’indexation. Les 3xx font suivre la redirection, dans une limite de dix sauts par tentative d’exploration, au-delà de laquelle l’URL est considérée en erreur. Les 4xx ne sont pas indexés, et Google retire de l’index les URL qui y répondent, avec une exception notable : le 429, traité comme une erreur serveur et non comme une erreur client. Les 5xx font ralentir l’exploration, et Google conserve d’abord les URL déjà indexées avant de les supprimer si l’erreur s’installe. Cette asymétrie entre 4xx et 5xx est la seule chose à retenir si l’on ne retient qu’une chose : pour retirer une page durablement, on sert un 404 ou un 410. Pour la mettre à l’abri le temps d’une intervention, on sert un 503.
| Code | Ce qu’il annonce | Ce que Google en fait |
|---|---|---|
| 200 | Requête acceptée, contenu servi | Contenu examiné, indexation possible sans garantie |
| 301 | Déplacement permanent | Redirection suivie, signal fort vers la nouvelle URL |
| 302 | Déplacement temporaire | Redirection suivie, l’URL d’origine reste privilégiée |
| 404 | Ressource absente | Non indexée, retirée de l’index si elle y figurait |
| 410 | Ressource supprimée volontairement | Même traitement que 404, retrait un peu plus rapide |
| 429 | Trop de requêtes | Traité comme une erreur serveur, exploration ralentie |
| 503 | Service indisponible | Exploration ralentie, URL conservées au début |
Faut-il servir un 404 ou un 410 ?
La différence est réelle mais mince, et elle ne justifie pas un chantier. Le 404 dit que la ressource est introuvable, sans se prononcer sur la suite : elle peut réapparaître. Le 410 dit qu’elle a été supprimée volontairement et ne reviendra pas. Google traite les deux de la même façon sur le fond, avec un retrait de l’index légèrement plus rapide pour le 410. En pratique, le 410 se justifie quand on supprime délibérément un lot de pages et qu’on veut accélérer leur sortie, par exemple après le nettoyage de pages générées par erreur. Pour tout le reste, le 404 servi par défaut convient. Ce qui compte davantage, c’est qu’une page supprimée renvoie effectivement l’un des deux, et non un 200 sur une page qui affiche « contenu introuvable », cas que Google identifie comme une soft 404 et traite à part.
Ouvrir l’URL dans son navigateur et conclure qu’elle répond 200. Le navigateur est un client parmi d’autres : il envoie ses propres en-têtes, il est parfois déjà authentifié, et il passe par un cache. Le seul contrôle qui vaut est celui de la réponse brute, et il se refait avec un client en ligne de commande, en variant le User-Agent. Un site peut servir un 200 à un visiteur et un 403 à un robot sans que rien ne le signale à l’écran.
Pourquoi les chaînes de redirection posent problème ?
Parce que Google en suit un nombre limité par tentative, et parce qu’elles se construisent sans qu’on les décide. Google indique suivre jusqu’à dix redirections par tentative d’exploration, et considérer l’URL en erreur au-delà. Or une chaîne se forme naturellement au fil des refontes : un premier passage en HTTPS, puis un ajout de barre oblique finale, puis un changement de slug, et l’ancienne adresse traverse trois sauts avant d’atteindre la bonne. Chaque saut ajoute un aller-retour réseau, ce qui ralentit le rendu pour le visiteur autant que l’exploration pour le robot. La correction consiste à aplatir la chaîne : faire pointer chaque ancienne adresse directement vers la destination finale, plutôt que vers l’étape suivante. C’est un travail de plan de redirections, pas de règle serveur supplémentaire.
Comment savoir ce que le serveur répond vraiment ?
En lisant les journaux du serveur, et pas seulement en interrogeant les URL une par une. Un contrôle unitaire donne le code servi à vous, à cet instant, avec vos en-têtes. Les journaux donnent le code servi à chaque demandeur réel, sur toute la période, y compris aux robots que vous ne pouvez pas imiter. C’est la seule source qui permette de repérer qu’une même adresse a répondu différemment selon le client, cas qui ne se déduit d’aucun crawl et d’aucune interface d’administration. Search Console rapporte de son côté ce que Googlebot a reçu, ce qui recoupe utilement les journaux, mais avec un décalage et sur le seul périmètre de Google. Les trois sources ne disent pas la même chose et c’est précisément pour cela qu’on les croise.
Comment corriger les erreurs les plus fréquentes ?
En traitant la cause plutôt que le symptôme, et en commençant par les URL qui reçoivent réellement des visites ou des liens. Une erreur 404 sur une adresse que personne ne demande n’a pas d’impact sur le référencement naturel et ne mérite pas de redirection : la corriger consomme du temps sans rien produire. La même erreur sur une page qui recevait des clics ou qui est citée par un site externe se corrige, elle, par une redirection permanente vers l’équivalent le plus proche, et non vers la page d’accueil, qui est une réponse commode et rarement utile pour l’internaute. Une erreur serveur se traite à l’inverse : elle ne se redirige pas, elle se répare, et tant que la réparation dure, un état temporairement indisponible protège l’index mieux qu’une page d’erreur servie en 200. Enfin, une redirection posée pour un déplacement définitif se déclare permanente, et une redirection posée le temps d’une opération se déclare temporaire, sans quoi le moteur mémorise durablement une adresse qui n’était censée servir que quelques jours.
Cas mesuré sur un site en production
Mesure du 3 septembre 2026. Sur un site vitrine d’une centaine de pages en hébergement mutualisé, les journaux serveur de sept jours totalisent 127 872 requêtes de robots et onze codes HTTP distincts : 98,0 % de 200, 0,9 % de 301, 0,7 % de 404, puis 400, 401, 403, 410, 302, 500, 207 et 503 en traces. Le fait notable n’est pas cette répartition mais une seule URL. Le fichier robots.txt a reçu trois codes différents sur la même semaine, selon le demandeur : 200 pour la plupart des robots, dont douze fois pour Googlebot Desktop, 301 quarante fois réparties sur huit robots dont Googlebot Desktop sept fois, et 401 sept fois, toutes pour le robot d’un moteur génératif, assorties de trois 400 pour le même. Le fichier qui règle l’accès des robots n’était donc pas servi de la même façon à tous, et l’un d’eux s’est vu réclamer une authentification sur un fichier public. Ouverte dans un navigateur, la même adresse répond 200 : rien à l’écran ne laissait deviner l’anomalie.
Faire expliquer ce terme par une IA
Ouvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
Sources
- 1IETF, RFC 9110 HTTP Semantics : les cinq classes de codes et la règle du x00
- 2Google Search Central, HTTP status codes : traitement des 2xx, 3xx, 4xx, 429 et 5xx
- 3Google Search Central, Reduce the Googlebot crawl rate : 500, 503, 429 et durée maximale
- 4Google Search Central, Managing crawl budget : effet des erreurs sur l’exploration
Questions fréquentes
Un 404 pénalise-t-il un site ?−
Non. Une page absente répond 404, c’est la réponse correcte et Google la traite comme telle. Ce qui pose problème est ailleurs : des liens internes qui pointent encore vers ces adresses, ou un volume de 404 si élevé qu’il occupe l’exploration au détriment des pages utiles.
Quelle différence entre une 404 et une soft 404 ?+
La 404 est un code renvoyé par le serveur. La soft 404 est une page qui renvoie 200 tout en affichant un message d’absence de contenu. Google identifie ce cas et traite la page comme introuvable, mais il aura dépensé une requête pour le découvrir.
Combien de redirections Google suit-il ?+
Jusqu’à dix par tentative d’exploration, au-delà desquelles l’URL est considérée en erreur. Ce plafond est rarement atteint, mais les chaînes de trois ou quatre sauts sont fréquentes après plusieurs refontes et ralentissent visiteurs comme robots.
Quel code servir pendant une maintenance ?+
Un 503, et pour une durée courte. Google ralentit alors son exploration et conserve d’abord les URL indexées. Maintenu plusieurs jours sur les mêmes adresses, ce code peut en revanche provoquer leur suppression de l’index.
Où voir les codes HTTP reçus par Google ?+
Dans Search Console, rapport d’indexation et inspection d’URL, pour ce que Googlebot a reçu. Dans les journaux du serveur pour ce qui a réellement été servi, à Google comme à tous les autres. Les deux se croisent, ils ne se remplacent pas.
Damien Hernandez
Consultant SEO senior, 17 ans d’expérience (Accor, Louvre Hotels, Infopro Digital). Spécialiste SEO technique, analyse de logs et optimisation pour les moteurs génératifs (GEO).