Codes statut HTTP liste complète 2026 | de 1xx à 5xx

Chaque appel vers une page web se termine par un nombre à trois chiffres renvoyé par le serveur : ce code de statut HTTP, que l’on retrouve dans toute liste de diagnostics réseau, dit si la ressource existe, si elle a bougé, si l’accès est refusé ou si l’application est tombée.

Ce guide rassemble les codes de statut HTTP en liste complète, de 1xx à 5xx, avec leur signification, des cas d’usage réels, les erreurs de configuration les plus fréquentes et la méthode pour les déboguer côté serveur comme côté client. Chez Example Domain test 123, nous utilisons ce référentiel comme base de tout diagnostic technique de site web.

Codes statut HTTP liste complète 2026 | de 1xx à 5xx

Temps de lecture : ~10 min

1. Qu’est-ce qu’un code de statut HTTP
2. Codes de statut HTTP, la liste complète par famille
3. Les codes 1xx, réponses informatives
4. Les codes 2xx, les succès
5. Les codes 3xx, redirections et cache
6. Les codes 4xx, erreurs côté client
7. Les codes 5xx, erreurs côté serveur
8. Impact SEO des codes HTTP
9. Comment vérifier le code réponse HTTP d’une page web
10. Aller plus loin avec les codes de statut HTTP
11. Questions fréquentes sur les codes de statut HTTP

Qu’est-ce qu’un code de statut HTTP

Un code de statut HTTP est la réponse numérique qu’un serveur envoie après avoir reçu une requête HTTP. Il accompagne toujours la réponse serveur, aux côtés des en-têtes HTTP comme Location, Cache-Control ou Content-Type, et il précède le contenu éventuel. Le protocole HTTP prévoit des codes valides de 100 à 599, comme le rappelle la spécification RFC 9110 consacrée à la sémantique de HTTP. Le premier chiffre définit la famille, les deux suivants n’ont pas de rôle de catégorisation.

La signification d’un code HTTP dépend aussi de la méthode utilisée. Une requête GET, POST, PUT ou DELETE ne produit pas les mêmes réponses attendues. Une création de ressource via une API renvoie typiquement 201, alors qu’une simple consultation de page renvoie 200. Le registre officiel des codes est maintenu par l’IANA, et MDN Web Docs de Mozilla en propose une lecture accessible pour les développeurs.

Codes de statut HTTP, la liste complète par famille

Avant de détailler chaque code, voici la grille de lecture des cinq familles de codes réponse HTTP.

Comprendre les familles de codes HTTP

Les codes 1xx, réponses informatives

Les codes informatifs signalent que la requête a bien été reçue et que le traitement continue. Le code 100 Continue invite le client à envoyer la suite de sa requête. Le code 101 Switching Protocols acte un changement de protocole, par exemple lors de l’ouverture d’une connexion WebSocket. Le code 102 Processing, issu de WebDAV, indique un traitement long dont la réponse complète n’est pas encore prête. Le code 103 Early Hints transmet des indications préliminaires, souvent pour amorcer le préchargement de ressources et gagner du temps d’affichage.

Ces réponses ne sont presque jamais visibles dans un navigateur et n’apparaissent pas dans les rapports d’exploration classiques. Les codes 100 et 101 sont définis dans le RFC 9110, les autres proviennent d’extensions enregistrées par l’IANA.

Les codes 2xx, les succès

Le code HTTP 200 OK est la réponse la plus courante du web. Il signifie que la ressource a été trouvée et servie correctement, et il est mis en cache par défaut dans les conditions prévues par le protocole. Le code 201 Created confirme la création d’une ressource après une requête POST ou PUT. Le code 202 Accepted indique une prise en compte sans traitement terminé, typique des traitements asynchrones. Le code 203 Non-Authoritative Information signale des informations transmises par un intermédiaire et non par la source d’origine.

Le code 204 No Content valide la requête sans renvoyer de corps de réponse, ce qui est utile pour une suppression ou une sauvegarde silencieuse. Le code 205 Reset Content demande au client de réinitialiser son formulaire. Le code 206 Partial Content sert aux téléchargements repris ou au streaming par plages. Les codes 207 Multi-Status et 208 Already Reported appartiennent à WebDAV et décrivent l’état de plusieurs ressources dans une même réponse. Enfin, 226 IM Used correspond à une manipulation d’instance appliquée à la ressource.

Les codes 3xx, redirections et cache

Les codes 3xx demandent une action supplémentaire pour obtenir la ressource. Le code 300 Multiple Choices annonce plusieurs représentations possibles. Le code 301 Moved Permanently signale un déplacement définitif, tandis que 302 Found indique une adresse temporaire. Le code 303 See Other oriente le client vers une autre URL, généralement en GET, ce qui évite de rejouer un POST. Le code 304 Not Modified indique que la ressource n’a pas changé depuis la version présente dans le cache navigateur, qui peut donc être réutilisée. Le code 305 Use Proxy est déprécié. Les codes 307 Temporary Redirect et 308 Permanent Redirect conservent strictement la méthode HTTP et le corps de la requête.

La différence entre une redirection 301 et 302 tient à la durée annoncée. La redirection permanente dit aux navigateurs et aux moteurs que l’ancienne adresse ne doit plus être considérée comme principale, la redirection temporaire laisse l’URL d’origine en place. Le tableau suivant résume les quatre codes de redirection les plus utilisés.

Quand faut-il préférer une redirection 308 à une redirection 301 ? Dès que la requête n’est pas un simple GET. Sur un formulaire ou une passerelle API, un 301 peut conduire certains clients à transformer un POST en GET et à perdre le corps de la requête, alors que 308 impose la conservation de la méthode. Pour les pages éditoriales classiques, le 301 reste la référence.

Bon à savoir

Une redirection permanente est fortement mise en cache par les navigateurs. Revenir en arrière après une erreur de configuration prend donc du temps chez les visiteurs déjà passés sur l’ancienne URL.

Les codes 4xx, erreurs côté client

Cette famille signale que le serveur refuse ou ne peut pas traiter la requête telle qu’elle est formulée. Le code 400 Bad Request correspond à une requête mal formée. Le 401 Unauthorized réclame une authentification valide, alors que le code HTTP 403 interdit l’accès à une ressource pourtant comprise par le serveur. Le 402 Payment Required reste réservé. La fameuse erreur 404 Not Found signifie que la ressource demandée est introuvable, sans préjuger de son existence passée. Le 405 Method Not Allowed rejette la méthode employée, le 406 Not Acceptable échoue sur la négociation de contenu et le 407 Proxy Authentication Required exige une authentification auprès du proxy.

Suivent le 408 Request Timeout, le 409 Conflict lié à l’état courant de la ressource, puis le code HTTP 410 Gone qui déclare une suppression définitive. Les codes 411 Length Required, 412 Precondition Failed, 413 Content Too Large, 414 URI Too Long, 415 Unsupported Media Type, 416 Range Not Satisfiable et 417 Expectation Failed encadrent des problèmes de format, de taille ou de conditions d’en-tête HTTP. Le 418 I’m a teapot vient d’une spécification humoristique et n’a aucun usage réel. Le 421 Misdirected Request, le 422 Unprocessable Content, le 423 Locked, le 424 Failed Dependency, le 425 Too Early, le 426 Upgrade Required, le 428 Precondition Required, le 429 Too Many Requests, le 431 Request Header Fields Too Large et le 451 Unavailable For Legal Reasons complètent la liste des codes HTTP de cette famille.

En pratique, quatre codes concentrent l’essentiel des questions sur un site web. Le 401 signale une authentification manquante ou invalide, typiquement dans un espace client ou un back office, ce qui impose de vérifier la session et les identifiants. Le 403 refuse l’accès malgré une requête comprise, souvent à cause d’un dossier protégé ou d’une règle de pare feu applicatif, ce qui appelle à contrôler les droits, les règles serveur et le CDN. Le 404 signale une ressource introuvable, due à une URL erronée ou à un contenu jamais publié, et invite à corriger le lien ou à servir une page utile. Le 410 indique une ressource supprimée définitivement, comme une offre retirée sans équivalent, ce qui doit conduire à assumer la suppression et à retirer les liens internes concernés.

Les codes 5xx, erreurs côté serveur

Une erreur 500 serveur est une défaillance générique de l’application, souvent une exception non gérée, une limite de mémoire atteinte ou une requête de base de données en échec. Le 501 Not Implemented signale une fonctionnalité non prise en charge. L’erreur 502 bad gateway survient lorsqu’un reverse proxy, un CDN ou une passerelle API reçoit une réponse invalide du serveur en amont. L’erreur 503 service indisponible correspond à une indisponibilité temporaire, pour maintenance ou surcharge, et gagne à être accompagnée d’un en-tête Retry-After. Le 504 Gateway Timeout traduit un délai dépassé entre deux serveurs.

Les codes 505 HTTP Version Not Supported, 506 Variant Also Negotiates, 507 Insufficient Storage, 508 Loop Detected, 510 Not Extended et 511 Network Authentication Required complètent la famille. Les codes 507 et 508 relèvent de WebDAV, le 511 concerne une authentification au niveau du réseau, par exemple sur un portail captif. Le RFC 9110 standardise notamment les codes 500 à 505.

Concrètement, quatre codes reviennent le plus souvent en diagnostic. Le 500 correspond à une erreur interne de l’application, à chercher dans les journaux serveur et applicatifs. Le 502 traduit une réponse invalide d’un service amont, à examiner du côté de la configuration du reverse proxy ou du CDN. Le 503 signale un service saturé ou en maintenance, lié à la charge serveur, à la file d’attente ou à un mode maintenance. Le 504 indique un délai d’attente dépassé entre serveurs, à investiguer via le temps d’exécution, la base de données et les timeouts.

Impact SEO des codes HTTP

Priorités SEO liées aux codes HTTP

Un code HTTP 200 OK est la condition minimale pour qu’une page soit explorée puis éventuellement indexée, sous réserve du contenu, du robots.txt, des directives noindex et de la balise canonique. Une erreur 404 n’est pas une faute en soi lorsqu’elle concerne une URL qui n’a jamais existé. Elle devient problématique quand elle touche des pages recevant des liens internes ou externes, car elle dégrade l’expérience et gaspille le budget d’exploration. La différence entre 404 et 410 est une question de signal : le 410 affirme une suppression définitive et assumée, le 404 laisse planer un doute.

Les redirections permanentes servent lors des changements de nom de domaine, des migrations HTTP vers HTTPS, des refontes de structure d’URL et des fusions de pages. Voici les points de vigilance à contrôler après toute migration.

• La longueur de la chaîne de redirections, à limiter autant que possible, et l’absence de boucle de redirections.
• La cohérence entre l’en-tête Location, la balise canonique, le sitemap et le maillage interne.
• L’usage d’un code temporaire uniquement pour des situations réellement provisoires.

Côté priorités, les erreurs 5xx sur des pages stratégiques passent avant tout, car elles bloquent l’exploration. Viennent ensuite les 404 recevant des liens, les chaînes de redirections issues d’anciennes migrations, puis les 403 renvoyés par erreur à un robot d’indexation par un pare feu applicatif ou un CDN mal réglé.

Comment vérifier le code réponse HTTP d’une page web

Étapes pour contrôler un code de réponse HTTP

La vérification se fait en quatre temps. Il faut d’abord identifier précisément l’URL, la méthode GET POST PUT DELETE employée, les paramètres et le contexte, navigateur, robot d’exploration ou application. Ensuite, reproduisez la requête avec l’onglet réseau des outils de développement ou en ligne de commande avec curl -I suivi de l’adresse, puis curl -I -L pour suivre toute la chaîne de redirections et voir le code final. Analysez ensuite chaque saut, notamment les passages HTTP vers HTTPS et les variantes avec et sans www.

Enfin, remontez aux journaux serveur, aux journaux applicatifs, aux erreurs de base de données, aux limites de mémoire et aux règles du pare feu. Un même code peut être produit par le serveur d’origine, un reverse proxy, un CDN, une couche de cache ou une passerelle API. Si l’incident est intermittent, comparez les réponses depuis plusieurs réseaux et plusieurs zones géographiques avant de conclure.

À retenir

Un code HTTP ne décrit pas seulement un état, il pilote le comportement du cache, des navigateurs et des robots. Le choisir correctement vaut mieux que le corriger après coup.

Aller plus loin avec les codes de statut HTTP

Ressources de référence sur les codes HTTP

Maîtriser les codes de statut HTTP, c’est disposer d’un langage commun entre développement, infrastructure et référencement. Une bonne pratique consiste à auditer régulièrement les réponses des pages clés, à documenter les règles de redirection en place et à surveiller les erreurs serveur dans les journaux. Le registre de l’IANA, le RFC 9110 et MDN Web Docs restent les trois références à consulter en cas de doute sur un code précis.

En résumé sur les codes de statut HTTP

Points clés à retenir

En comprenant la logique des familles de codes, en configurant correctement vos réponses serveur et en surveillant régulièrement les erreurs, vous facilitez le travail des navigateurs comme des robots d’exploration. Le bon code HTTP est un signal fort sur l’état réel de la ressource : il doit rester cohérent avec votre contenu, votre stratégie de redirection et vos objectifs SEO.

FAQ sur les codes de statut HTTP

Un code 418 peut-il apparaître sur un vrai site ?

Il existe dans certaines implémentations par clin d’oeil, mais il ne correspond à aucun usage sérieux. S’il apparaît en production, il s’agit presque toujours d’une règle de test oubliée ou d’un filtrage volontaire de trafic automatisé.

Faut-il rediriger toutes les pages supprimées vers la page d’accueil ?

Non. Une redirection n’a de sens que vers un contenu réellement équivalent. Sans équivalent, un 404 ou un 410 est plus honnête et évite de créer des redirections jugées non pertinentes.

Quelle différence entre HTTP/1.1 et les versions suivantes pour les codes de statut ?

Les codes eux-mêmes restent identiques, car ils relèvent de la sémantique du protocole décrite par le RFC 9110. Seul le transport change, ce qui peut influencer les performances mais pas la signification des réponses.

Comment gérer proprement une maintenance planifiée ?

Renvoyez un 503 accompagné d’un en-tête Retry-After indiquant la durée estimée. Les robots d’exploration comprennent alors qu’il s’agit d’une interruption temporaire et reviendront plus tard.

Un code 304 est-il un problème ?

Non, c’est un signe de bon fonctionnement du cache. Il indique que la ressource n’a pas changé et qu’une copie locale valide peut être réutilisée, ce qui réduit la bande passante et le temps de chargement.