Codes de statut HTTP : le guide complet, de la signification au coût serveur

Chaque fois qu’un navigateur, un robot d’indexation ou une application demande une ressource sur le web, le serveur répond par un nombre à trois chiffres avant même d’envoyer la moindre ligne de contenu. Ce nombre est le code de statut HTTP, la première information que reçoit le client, et il dit en un seul jeton si la demande a abouti, si elle a été déplacée ailleurs, si elle a été refusée, ou si le serveur lui-même a échoué. Un 200 annonce un succès, un 404 une ressource introuvable, un 500 une défaillance côté serveur.

Ces codes sont normalisés par la RFC 9110, publiée en juin 2022 pour remplacer la RFC 7231, et le registre officiel qui les recense est tenu par l’IANA. La quasi-totalité de ce qui s’écrit à leur sujet en français s’arrête à cette couche de définition : un tableau, un libellé, une traduction. C’est passer à côté de l’essentiel pour qui gère un site, parce qu’un code de statut n’est pas seulement une information. C’est un événement qui consomme des ressources serveur, qui retarde un affichage, et qui alimente un signal de qualité auprès des moteurs de recherche.

Une redirection 301 ajoute un aller-retour réseau complet avant que la page cible ne commence à répondre. Une erreur 404 mal configurée déclenche l’exécution intégrale de l’application au lieu d’une réponse statique, et sous le trafic d’un scanner cela suffit à faire monter la charge d’un serveur. Une rafale de 5xx amène Googlebot à ralentir son exploration, avec un effet retard qui se prolonge bien après la résolution de l’incident. Alors, combien coûte réellement chacun de ces codes, et lesquels faut-il renvoyer dans quelles situations ?

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

Un code de statut HTTP est un entier à trois chiffres, renvoyé par un serveur dans la première ligne de sa réponse, qui indique au client comment sa requête a été traitée. La RFC 9110 en définit la sémantique et les répartit en cinq classes identifiées par leur premier chiffre. Seul ce premier chiffre est normatif pour le comportement du client : un client qui rencontre un code inconnu doit le traiter comme le code x00 de sa famille.

La réponse complète ne se limite pas au nombre. Elle porte aussi un ensemble d’en-têtes qui précisent ce que le client doit faire de cette information : Location pour une redirection, Retry-After pour une indisponibilité temporaire, ETag et Last-Modified pour la validation de cache. Le code annonce la nature de la réponse, les en-têtes en donnent les modalités, et c’est la combinaison des deux qui détermine le comportement réel du navigateur.

Comment vérifier le code de statut d’une page ?

La façon la plus rapide de lire un code de statut est la commande curl avec l’option -I, qui n’envoie qu’une requête HEAD et affiche les en-têtes sans télécharger le corps de la réponse. Cette vérification prend moins d’une seconde et se révèle indispensable dès qu’on soupçonne un écart entre ce que la page affiche et ce que le serveur déclare.

$ curl -I https://exemple.fr/ancienne-page/
HTTP/2 301
location: https://exemple.fr/nouvelle-page/
cache-control: max-age=3600

$ curl -I https://exemple.fr/nouvelle-page/
HTTP/2 200
content-type: text/html; charset=UTF-8

L’onglet Réseau des outils de développement du navigateur donne la même information sur toutes les ressources d’une page, avec une colonne Statut qui se trie et se filtre. C’est le premier réflexe d’un audit : filtrer sur les codes différents de 200 pour voir immédiatement ce qui redirige, ce qui manque et ce qui échoue au chargement d’une page donnée.

Pourquoi un code de statut HTTP coûte-t-il des ressources serveur ?

Un code de statut n’est jamais gratuit, parce qu’une réponse doit être produite quelque part avant d’être envoyée. Le même code peut coûter plusieurs milliers de fois plus cher selon l’endroit où il est produit : une redirection écrite en règle sur un CDN ne touche jamais le serveur d’origine, alors que la même redirection posée par une extension WordPress démarre l’intégralité de l’application PHP et interroge la base de données pour ne renvoyer qu’un simple en-tête.

Cette distinction est le fil conducteur de tout ce qui suit. Trois niveaux de production existent, et ils n’ont rien de comparable en termes de consommation.

Niveau de production	Ce qui est mobilisé	Coût	Exemples typiques
Edge, CDN ou WAF	Rien côté origine	Quasi nul	Redirection en règle Cloudflare, blocage de sécurité, limitation de débit
Serveur web (Nginx, Apache)	Lecture de configuration	Quelques millisecondes	Redirection en configuration, 404 sur un fichier statique manquant
Application (PHP, WordPress)	Démarrage complet, requêtes SQL, rendu de gabarit	Élevé, comparable à une page complète	Redirection par extension, 404 traité par le routeur applicatif

Un même code de statut ne mobilise pas les mêmes ressources selon l’endroit où il est produit.

Le tableau se lit dans un seul sens : plus la réponse remonte vers l’application, plus elle coûte cher, et cela reste vrai que la réponse soit un succès, une redirection ou une erreur. Un 404 produit par Nginx sur un fichier absent se compte en dixièmes de milliseconde. Le même 404 renvoyé par le routeur d’un CMS mobilise un processus applicatif entier, souvent pendant plusieurs centaines de millisecondes.

La conséquence pratique est immédiate : la question à se poser devant un code de statut n’est pas seulement quel code renvoyer, mais où le produire. Chaque famille de codes se lit ensuite à travers cette grille.

Quelles sont les cinq familles de codes HTTP ?

Les codes de statut se répartissent en cinq classes, chacune identifiée par son premier chiffre, et chacune imposant au client un comportement par défaut différent. Connaître la famille suffit déjà à savoir quoi faire d’un code jamais rencontré.

1xx, réponses informationnelles : le serveur signale qu’il a reçu la requête et poursuit son traitement. La réponse finale suivra. Cette famille inclut le 100 Continue, le 101 Switching Protocols lors du passage à WebSocket, et le 103 Early Hints, le seul de la famille qui intéresse directement la performance ;
2xx, succès : la requête a été reçue, comprise et traitée. Le contenu attendu est là, ou bien l’opération demandée a bien eu lieu ;
3xx, redirections : la ressource se trouve ailleurs, ou la copie en cache du client est encore valable. Le client doit émettre une seconde requête, ou réutiliser ce qu’il possède déjà ;
4xx, erreurs du client : la requête est fautive du point de vue du serveur. URL inexistante, méthode non autorisée, authentification manquante, format non accepté ;
5xx, erreurs du serveur : la requête était valable, mais le serveur n’a pas su y répondre. C’est la seule famille dont la responsabilité incombe entièrement à l’hébergement et à l’application.

Cette répartition n’est pas qu’une convention d’écriture. La documentation de Google sur l’exploration décrit un traitement différent pour chaque famille : le contenu d’une réponse 2xx est envoyé au pipeline d’indexation, les 3xx sont suivies jusqu’à dix sauts, le contenu des 4xx est ignoré et l’URL finit par sortir de l’index, et les 5xx déclenchent un ralentissement de l’exploration.

Reste que le comportement à l’intérieur d’une famille varie beaucoup, et c’est là que les arbitrages se jouent réellement.

Que signifie le code HTTP 200 et les autres codes 2xx ?

Le 200 OK signifie que la requête a abouti et que le corps de la réponse contient la ressource demandée. C’est le code que renvoie une page qui s’affiche normalement, et MDN précise que sa signification dépend de la méthode employée : sur un GET, la ressource est dans le corps ; sur un POST, c’est le résultat de l’action. Un 200 ne garantit toutefois pas l’indexation, Google le dit explicitement dans sa documentation d’exploration.

Sur le plan de la performance, le 200 est le code le plus coûteux de la famille, puisqu’il transporte l’intégralité de la ressource. Tout l’enjeu de l’optimisation consiste précisément à en émettre le moins possible sur des contenus que le client possède déjà, ce que permettent le cache et la validation.

Que signifient les codes 201, 202, 204 et 206 ?

Le 201 Created confirme qu’une ressource a été créée à la suite de la requête, typiquement après un POST sur une API, et l’en-tête Location indique où elle se trouve désormais. Le 202 Accepted signale que la demande est prise en compte mais traitée de façon asynchrone, ce qui est le cas des files d’attente et des traitements différés. Google précise que ses robots attendent alors le contenu pendant une durée limitée, variable selon le robot concerné, avant de passer à l’étape suivante avec ce qu’ils ont reçu.

Le 204 No Content indique un succès sans corps de réponse : l’opération a réussi, il n’y a rien à afficher. C’est la réponse idéale d’un appel de suivi ou d’une suppression, et son intérêt en performance est réel puisqu’elle évite d’émettre des octets inutiles. Attention toutefois du côté du référencement : Google ne peut rien traiter d’un 204 et le considère comme dépourvu de contenu.

Le 206 Partial Content répond à une requête portant un en-tête Range, et ne renvoie qu’un fragment de la ressource. C’est le mécanisme qui permet la lecture en continu d’une vidéo, la reprise d’un téléchargement interrompu, ou le chargement progressif d’un fichier volumineux. Sur un site qui héberge lui-même ses vidéos, la présence de 206 dans les journaux est normale et attendue.

Quelle différence entre une redirection 301 et une redirection 302 ?

Le 301 Moved Permanently annonce un déplacement définitif : la ressource a changé d’adresse pour de bon, et les clients doivent mettre à jour leurs références. Le 302 Found annonce un détour temporaire : l’URL d’origine reste la bonne, mais la réponse se trouve ailleurs pour l’instant. Google traite le 301 comme un signal fort de canonicalisation et le 302 comme un signal faible, ce que sa documentation d’exploration formule dans ces termes exacts.

La différence pratique la plus lourde de conséquences ne se joue pourtant pas du côté des moteurs, mais du côté des navigateurs. Un 301 est mis en cache de façon agressive par les clients, parfois durablement, et une redirection permanente posée par erreur devient très difficile à annuler pour les visiteurs qui l’ont déjà enregistrée. Tant qu’un déplacement n’est pas certain et définitif, le 302 reste le choix prudent.

Il faut ajouter à cela le 303 See Other, qui force le passage en GET après un envoi de formulaire pour éviter la double soumission, et le 304 Not Modified, qui appartient techniquement à la famille des 3xx sans être une redirection du tout.

À quoi servent les redirections 307 et 308 ?

Les codes 307 Temporary Redirect et 308 Permanent Redirect reprennent la sémantique du 302 et du 301, avec une garantie supplémentaire décisive : ils préservent la méthode HTTP et le corps de la requête. Un POST redirigé en 307 reste un POST, avec ses données intactes.

Cette garantie n’existe pas avec le 301 et le 302. Pour des raisons historiques, de nombreux clients transforment un POST redirigé en GET, ce qui fait disparaître silencieusement les données envoyées. Sur un formulaire de commande ou un appel d’API, la conséquence est une requête qui semble aboutir alors qu’elle n’a rien transmis.

Google traite le 307 comme un 302 et le 308 comme un 301, mais rappelle dans sa documentation que ces codes restent sémantiquement distincts et qu’il vaut mieux utiliser celui qui correspond réellement à l’intention. La question du coût, elle, ne dépend d’aucun de ces quatre codes : elle dépend du nombre de sauts et de l’endroit où ils sont produits.

Combien de temps coûte une redirection ?

Une redirection coûte un cycle réseau complet avant que la page cible ne commence à répondre : résolution DNS si le domaine change, établissement de la connexion TCP, négociation TLS, envoi de la requête, réception de la réponse. Sur une connexion mobile, chaque saut se compte en centaines de millisecondes, et ce délai s’ajoute intégralement avant le premier octet de la page réellement demandée.

Une redirection ajoute un cycle réseau complet avant le premier octet de la page cible.

Le point à retenir est que ce coût est payé pour recevoir un en-tête Location et rien d’autre. Aucun contenu utile ne transite pendant ce cycle. C’est la raison pour laquelle Lighthouse dispose d’un audit dédié aux redirections, qui les signale dès qu’elles précèdent le chargement du document principal.

Ce délai est mesurable côté visiteur grâce à l’API Navigation Timing, qui expose les propriétés redirectStart et redirectEnd sur l’entrée de navigation. Comme il se situe avant le TTFB, il se répercute sur toutes les métriques qui en découlent, à commencer par le rendu du plus grand élément visible.

// Délai de redirection réellement subi par le visiteur
const nav = performance.getEntriesByType('navigation')[0];
const redirectMs = nav.redirectEnd - nav.redirectStart;

console.log(`Redirections : ${nav.redirectCount} saut(s), ${redirectMs.toFixed(0)} ms`);
console.log(`TTFB : ${(nav.responseStart - nav.requestStart).toFixed(0)} ms`);

Ce que révèle presque toujours cette mesure sur un site qui a vécu, c’est que le délai n’est pas dû à une redirection isolée, mais à leur accumulation.

Pourquoi une chaîne de redirections dégrade-t-elle la performance ?

Une chaîne de redirections multiplie le coût unitaire par le nombre de sauts, sans qu’aucun de ces sauts n’apporte de contenu. Trois redirections successives, c’est trois cycles réseau complets avant le premier octet utile, et le motif est fréquent sur les sites qui ont enchaîné une migration HTTPS, un changement de structure d’URL et un passage sans le www.

Le cas typique se lit ainsi : http://exemple.fr/produit redirige vers https://exemple.fr/produit, qui redirige vers https://www.exemple.fr/produit, qui redirige enfin vers https://www.exemple.fr/boutique/produit. Chaque règle a été ajoutée séparément, à une époque différente, par une personne différente. Aucune n’est fausse prise isolément.

Les robots d’exploration ont leurs propres limites en la matière. Google suit par défaut jusqu’à dix sauts de redirection, et Search Console remonte une erreur dédiée lorsqu’une chaîne devient trop longue, boucle sur elle-même ou aboutit à une URL vide. La correction est toujours la même : aplatir la chaîne pour que la première requête pointe directement vers la destination, en une seule règle plutôt qu’en trois qui se succèdent.

Où faut-il poser ses redirections ?

Une redirection produite par l’application contourne le cache de page : le serveur exécute tout le code du CMS, initialise la connexion à la base de données, charge les extensions, pour finalement renvoyer un en-tête de quelques dizaines d’octets. Le coût est celui d’une page complète pour un contenu nul, et il se paie à chaque requête concernée.

La règle est donc de traiter les redirections au niveau du serveur web, ou mieux encore à l’edge, et jamais dans le code applicatif quand c’est évitable. Une règle écrite dans la configuration Nginx se résout avant que PHP ne soit sollicité.

# Nginx : la redirection est résolue avant tout appel à PHP-FPM
location = /ancienne-page/ {
    return 301 https://exemple.fr/nouvelle-page/;
}

# Apache, même principe dans le .htaccess
Redirect 301 /ancienne-page/ https://exemple.fr/nouvelle-page/

Un cas particulier mérite d’être connu, parce qu’il fait disparaître complètement le coût d’une redirection très répandue. L’en-tête Strict-Transport-Security, ou HSTS, indique au navigateur que le domaine ne doit être contacté qu’en HTTPS. Le passage de http vers https devient alors une réécriture interne au navigateur, sans le moindre trajet réseau, là où une redirection classique en aurait coûté un complet.

Comment un code 304 accélère-t-il un site ?

Le 304 Not Modified indique au client que la copie qu’il détient est toujours valable, et il ne transporte aucun corps de réponse. Le navigateur réutilise alors sa version locale au lieu de retélécharger un fichier identique. Sur un script de 180 Ko, l’économie de bande passante est totale.

Le mécanisme repose sur deux couples d’en-têtes. Le serveur envoie un Last-Modified ou un ETag avec la ressource ; lors de la requête suivante, le navigateur les renvoie sous forme de If-Modified-Since ou d’If-None-Match. Si rien n’a changé, le serveur répond 304 et l’affaire est réglée en quelques octets.

$ curl -I -H 'If-None-Match: "a3f9c1e"' https://exemple.fr/assets/app.js
HTTP/2 304
etag: "a3f9c1e"
cache-control: max-age=604800

Reste une nuance que la plupart des articles omettent, et qui change complètement la stratégie : l’aller-retour réseau a bien lieu. Un 304 est moins cher qu’un 200, il n’est pas gratuit. Sur une connexion mobile avec une latence de 150 ms, vingt ressources validées par 304 représentent un délai bien réel avant que la page ne soit complète.

Le 304 supprime le transfert du contenu, pas l’aller-retour réseau qui le précède.

L’optimum n’est donc pas de multiplier les 304 mais de les rendre tout simplement inutiles. Une ressource dont le nom de fichier porte une empreinte du contenu peut être servie avec une durée de vie très longue et la directive immutable : le navigateur cesse alors de demander confirmation, et l’aller-retour disparaît. C’est le principe que détaille la documentation de web.dev sur le cache HTTP, et que nous développons dans notre guide sur les différentes couches de mise en cache.

# Ressource versionnée : plus jamais de requête de validation
location ~* \.(js|css|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

Dernier point, dans la logique des trois niveaux de production : un 304 produit par l’application coûte exactement le prix d’une page complète, puisque tout le code a tourné pour décider de ne rien envoyer. La validation doit être gérée par le serveur web, qui la résout sur les métadonnées du fichier.

À quoi sert le code HTTP 103 Early Hints ?

Le 103 Early Hints, défini par la RFC 8297 en décembre 2017, est une réponse informationnelle envoyée avant la réponse finale du serveur. Elle permet de transmettre des en-têtes Link au navigateur pendant que le serveur prépare encore le document, de sorte que le téléchargement des ressources critiques commence en avance.

Son intérêt est directement proportionnel au temps que met le serveur à produire sa réponse. Sur un site dont le TTFB est structurellement élevé, parce que la page demande des calculs ou des appels externes, ce temps mort est autant de latence pendant laquelle le navigateur ne fait rien. Le 103 le transforme en fenêtre de préchargement.

HTTP/2 103
link: </assets/critique.css>; rel=preload; as=style
link: </fonts/manrope.woff2>; rel=preload; as=font; crossorigin

HTTP/2 200
content-type: text/html; charset=UTF-8

Le mécanisme est décrit en détail dans la documentation de Chrome sur les Early Hints, et la couverture navigateur se consulte sur Can I Use. Cette piste vient naturellement compléter le travail de réduction du délai de première réponse, dont elle ne dispense jamais : le 103 masque un TTFB élevé, il ne le corrige pas.

Erreur 404 : que signifie ce code http et d’où vient-il ?

Le code http 404 Not Found signifie que le serveur n’a trouvé aucune ressource correspondant à l’URL demandée. La RFC 9110 précise qu’il n’indique pas si cette absence est temporaire ou définitive, ce qui le distingue du 410. Le nombre 404 n’a aucune signification cachée : c’est simplement le quatrième code de la famille des erreurs client, contrairement à la légende tenace d’un bureau numéroté 404 au CERN.

Pour un visiteur qui tombe dessus sur un site tiers, les causes sont presque toujours les mêmes : une adresse mal saisie, un lien périmé sur un autre site, un signet vers une page supprimée, ou un contenu déplacé sans redirection. Rafraîchir la page ne sert à rien, puisque le serveur répond correctement : il n’a réellement rien à cette adresse. Vérifier l’orthographe de l’URL, remonter à la racine du site ou utiliser sa recherche interne sont les seules démarches utiles.

Pour qui exploite le site, en revanche, l’erreur code 404 est bien plus qu’un désagrément d’affichage.

Une erreur 404 consomme-t-elle des ressources serveur ?

Sur un CMS, une URL introuvable est fréquemment la requête la plus coûteuse de tout le site. Elle échappe au cache de page, puisqu’aucune version de cette URL n’a jamais été mise en cache, déclenche le démarrage complet de l’application, exécute la requête principale en base de données, constate son échec, puis charge le gabarit d’erreur pour l’afficher. Tout ce travail est fourni pour ne rien servir.

Une mauvaise configuration aggrave considérablement le phénomène. Lorsqu’un fichier statique manquant est renvoyé vers le contrôleur applicatif au lieu d’être traité par le serveur web, une simple image absente déclenche un démarrage applicatif complet. Sur un site qui a perdu quelques dizaines de fichiers lors d’une migration, chaque affichage de page paie ce prix plusieurs fois.

C’est exactement le motif que nous cherchons en priorité dans les journaux lors d’un audit de performance sur un site lent : la volumétrie de 404 et, surtout, le niveau auquel elles sont produites.

Pourquoi les erreurs 404 peuvent-elles faire monter la charge d’un serveur ?

L’effet d’échelle transforme un coût unitaire acceptable en incident de production. Sous le balayage d’un scanner de vulnérabilités, d’un robot d’aspiration ou d’une vague de liens cassés, ces 404 applicatives mobilisent durablement les processus PHP. Le pool de processus sature, les requêtes légitimes attendent leur tour, le temps de réponse se dégrade pour tout le monde, et la charge moyenne du serveur monte alors qu’aucune page réelle n’est servie.

La suite est mécanique. Quand le pool reste saturé, le serveur web finit par renvoyer des 502 ou des 504 sur des pages parfaitement valides, et un incident qui n’était qu’un excès de 404 devient une indisponibilité visible. C’est l’un des scénarios de panne les plus courants sur les hébergements mutualisés et les VPS mal dimensionnés.

La réaction en chaîne, du balayage de robots à la dégradation du temps de réponse.

Quatre mesures coupent cette chaîne à des endroits différents, et il vaut mieux les appliquer ensemble.

Traiter les 404 sur ressources statiques directement au niveau du serveur web, sans jamais atteindre l’application ;
Mettre en cache la réponse 404 elle-même pendant une courte durée, pour qu’une même URL fantôme ne soit calculée qu’une fois ;
Limiter le débit sur les motifs de balayage connus, et filtrer à l’edge les chemins qui n’existent pas sur la pile utilisée ;
Surveiller le volume de 404 dans les journaux serveur, en distinguant celles qui viennent de vrais visiteurs de celles qui viennent de robots.

La première mesure se met en place en quelques lignes de configuration, et c’est celle qui a le plus d’effet immédiat. La directive try_files de Nginx permet de renvoyer un 404 sec sur les extensions de fichiers statiques sans jamais solliciter PHP-FPM.

# Les fichiers statiques absents ne réveillent jamais l'application
location ~* \.(jpg|jpeg|png|webp|avif|svg|css|js|woff2)$ {
    try_files $uri =404;
    access_log off;
}

# Le routeur du CMS ne voit que les URL de pages
location / {
    try_files $uri $uri/ /index.php?$args;
}

Ce type de réglage relève de la configuration serveur autant que du code, et c’est l’une des raisons pour lesquelles nous traitons le dimensionnement de l’hébergement comme un levier de performance à part entière plutôt que comme un simple support.

Qu’est-ce qu’un soft 404 et pourquoi est-ce un problème ?

Un soft 404 est une page qui affiche un message de type page introuvable tout en renvoyant un code 200. Google la définit exactement en ces termes et recommande de renvoyer un vrai 404 pour les pages qui n’existent pas. Le problème est qu’un soft 404 est invisible sans audit : à l’œil, la page semble correcte.

Le défaut est double, et c’est ce qui le rend particulièrement coûteux. Côté serveur, la page a été intégralement calculée et sera mise en cache comme un contenu valide alors qu’elle ne contient rien. Côté moteurs, Google continue d’explorer une URL qu’il croit valable, ce qui gaspille du budget d’exploration et peut retarder la découverte des pages qui comptent réellement.

Les redirections de masse vers la page d’accueil produisent le même effet. John Mueller les a explicitement classées dans cette catégorie : une URL supprimée qu’on redirige vers l’accueil n’est pas indexée pour autant, et finit traitée comme un soft 404 sur le long terme.

Erreur 403 forbidden : quelles sont les causes du code http 403 ?

Le code erreur 403 Forbidden signifie que le serveur a compris la requête mais refuse de la satisfaire. La ressource existe, l’accès est simplement interdit. Contrairement au 401, aucune authentification ne débloquera la situation : le refus est catégorique, et la RFC 9110 précise que le serveur peut même choisir de renvoyer un 404 à la place s’il ne souhaite pas révéler l’existence de la ressource.

Pour un internaute bloqué par une erreur http 403 sur un site, les causes les plus fréquentes tiennent en trois catégories : une page réservée aux membres connectés, un pare-feu applicatif qui a jugé la requête suspecte (VPN, extension de navigateur, adresse IP signalée), ou une restriction géographique. Vider les cookies du site, désactiver un VPN ou tenter depuis une autre connexion résout une bonne partie des cas.

Côté exploitation, les causes techniques d’une erreur 403 http sont plus prosaïques. Des permissions de fichiers incorrectes après une migration, un fichier index manquant dans un répertoire dont le listing est désactivé, une règle de sécurité trop large, ou une extension de sécurité qui bloque un motif d’URL légitime.

Un cas mérite une attention particulière pour le référencement. Google est très clair sur ce point : Googlebot ne fournit jamais d’identifiants, donc un serveur qui lui renvoie un 403 le fait à tort, et la page ne sera pas indexée. Search Console remonte alors ces URL sous le libellé explicite Bloquée en raison d’une interdiction d’accès (403).

Que signifient les codes http 400, 401 et les autres erreurs client ?

Le 400 Bad Request signale une requête que le serveur ne peut pas traiter parce qu’elle est malformée : syntaxe invalide, en-tête corrompu, corps de requête illisible, URL contenant des caractères non encodés. C’est un refus de traitement, pas un refus d’accès, et il survient souvent sur des appels d’API mal construits ou des cookies devenus trop volumineux.

Le 401 Unauthorized porte un nom trompeur : il signifie en réalité non authentifié. Le serveur exige une identification, et doit accompagner sa réponse d’un en-tête WWW-Authenticate décrivant la méthode attendue. La différence avec le 403 tient en une phrase : sur un 401, s’identifier peut débloquer la situation, sur un 403, non.

Les autres erreurs client se rencontrent surtout sur les API, et leur bonne utilisation est ce qui distingue une interface exploitable d’une interface frustrante.

405 Method Not Allowed : la ressource existe mais n’accepte pas cette méthode. Un POST sur une page qui n’attend qu’un GET en est l’exemple canonique ;
406 Not Acceptable : aucun format proposé par le serveur ne correspond à ce que l’en-tête Accept du client réclame ;
408 Request Timeout : le client a mis trop de temps à envoyer sa requête, et le serveur a fermé la connexion inactive ;
409 Conflict : la requête entre en conflit avec l’état actuel de la ressource, typiquement lors de deux modifications concurrentes ;
415 Unsupported Media Type : le format du corps envoyé n’est pas géré, par exemple du XML là où l’API attend du JSON ;
422 Unprocessable Content : la syntaxe est correcte et le format compris, mais le contenu est sémantiquement invalide. C’est le code d’une validation de formulaire qui échoue sur le fond.

La confusion la plus répandue oppose le 400 et le 422. Le premier dit que la requête est illisible, le second qu’elle est parfaitement lisible mais que ce qu’elle demande n’a pas de sens. Une adresse électronique mal formée relève du 422, pas du 400 : le serveur a très bien compris ce qu’on lui envoyait.

Quand faut-il utiliser un code 410 plutôt qu’un 404 ?

Le 410 Gone s’utilise quand la suppression est définitive et connue comme telle. La RFC 9110 le décrit comme la réponse appropriée lorsque le serveur sait que la ressource a été volontairement retirée et qu’aucune adresse de remplacement n’existe. Le 404, lui, reste muet sur la permanence.

Sur le plan du référencement, la différence pratique est faible mais réelle. Google indique traiter le 410 comme un 404 dans sa documentation d’exploration, tout en confirmant que ces deux codes retirent l’URL de l’index. John Mueller a d’ailleurs tranché la question de leur impact sur la qualité perçue d’un site, dans une réponse publiée sur Reddit et reprise début 2026 :

Les 404 et les 410 ne sont pas un signal de qualité négatif. C’est ainsi que le web est censé fonctionner.
John Mueller, Search Advocate chez Google, sur Reddit, propos rapportés par Search Engine Roundtable le 2 janvier 2026

Le vrai critère de choix est donc ailleurs que dans une prétendue prime au 410. Utilisez un 410 pour les contenus retirés délibérément et sans successeur, comme une offre d’emploi pourvue, un produit définitivement arrêté ou une page purgée ; conservez le 404 pour tout le reste, et posez une redirection 301 dès qu’un équivalent existe réellement.

L’erreur à éviter absolument reste la redirection de masse vers la page d’accueil, qui n’a aucun des mérites des trois options précédentes et fabrique en prime des soft 404 en série.

À quoi sert le code 429 et comment protège-t-il un serveur ?

Le 429 Too Many Requests, défini par la RFC 6585 en avril 2012, signale qu’un client a envoyé trop de requêtes sur une période donnée. C’est le seul code de la famille 4xx qui protège activement l’infrastructure au lieu de constater un échec : il empêche la saturation décrite plus haut, en refusant le trafic excessif avant qu’il ne consomme des ressources.

Son efficacité dépend entièrement de l’endroit où il est produit. Un 429 servi par l’application ne protège de rien, puisque le coût du démarrage applicatif a déjà été payé au moment où la décision est prise. Il doit donc être émis le plus en amont possible, à l’edge ou au niveau du serveur web, là où le refus ne coûte presque rien.

# Nginx : 10 requêtes par seconde et par IP, avec une file de 20
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_status 429;

location / {
    limit_req zone=general burst=20 nodelay;
    try_files $uri $uri/ /index.php?$args;
}

Le 429 doit toujours s’accompagner d’un en-tête Retry-After indiquant le délai avant nouvelle tentative, exprimé en secondes ou sous forme de date. Sans lui, un client bien élevé n’a aucun moyen de savoir quand revenir, et un robot légitime risque d’abandonner définitivement.

Un point de vigilance mérite d’être souligné parce qu’il est souvent pris à l’envers. Google traite le 429 comme un signal de surcharge serveur, au même titre qu’une erreur 5xx, et ralentit son exploration en conséquence. Sa documentation ajoute une consigne explicite : ne jamais utiliser un 401 ou un 403 pour limiter le débit d’exploration, car ces codes n’ont aucun effet sur le rythme de Googlebot et provoquent en revanche une désindexation.

Votre site est-il aussi rapide que vos visiteurs l’espèrent ?

Découvrez comment nous pouvons vous accompagner

Erreur 500 : que signifie ce code d’erreur et comment le corriger ?

L’erreur http 500 Internal Server Error est la réponse générique d’un serveur qui a rencontré une condition inattendue et ne sait pas la qualifier plus précisément. La requête était valable, l’application a démarré, elle a commencé à s’exécuter, puis elle a échoué en cours de route. C’est le code le plus recherché de tous, et aussi le moins informatif par construction.

Pour un visiteur qui rencontre une error 500 sur un site tiers, il n’y a strictement rien à faire : le problème est entièrement côté serveur. Rafraîchir la page quelques minutes plus tard reste la seule option raisonnable, et l’erreur disparaît d’elle-même si l’incident était passager.

Sur le plan du coût, le 500 est particulièrement ingrat. Toute la chaîne a été mobilisée, le démarrage applicatif, la connexion à la base, l’exécution du code, et le résultat est nul. Le serveur paie en prime l’écriture dans les journaux d’erreur, ce qui, sous un incident massif, ajoute une charge d’écriture disque à un système déjà en difficulté.

Comment corriger une erreur 500 ?

Le code lui-même ne dit rien de la cause, et c’est précisément pour cela que le journal d’erreurs est le seul point de départ valable. Sur une pile PHP, la trace se trouve dans le journal du serveur web, dans celui de PHP-FPM, et souvent dans un fichier de débogage propre à l’application. Le message qui s’y trouve, lui, est explicite.

# Les dernières erreurs applicatives, en temps réel
tail -f /var/log/nginx/error.log
tail -f /var/log/php8.3-fpm.log

# Sur WordPress, activer la journalisation dans wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Les causes les plus fréquentes sur un site WordPress sont un conflit d’extensions après une mise à jour, une limite de mémoire PHP atteinte, une erreur de syntaxe dans un fichier de thème, un fichier .htaccess corrompu, ou une base de données injoignable. La documentation officielle de WordPress détaille la procédure de désactivation en masse des extensions, qui isole le coupable en quelques minutes.

Quelle différence entre une erreur 502 et une erreur 504 ?

Le 502 Bad Gateway signifie qu’un serveur agissant comme passerelle a reçu une réponse invalide de la part du serveur en amont. Le 504 Gateway Timeout signifie que ce même serveur amont n’a pas répondu du tout dans le délai imparti. Le 502 traduit une réponse cassée, le 504 une absence de réponse, et cette nuance oriente directement le diagnostic.

Dans une pile classique Nginx plus PHP-FPM, la traduction opérationnelle est très concrète. Un pool de processus PHP épuisé, ou un processus qui plante en cours d’exécution, se manifeste typiquement par des 502. Un traitement qui dépasse la durée maximale, comme un import volumineux ou une requête SQL non optimisée, produit des 504. Ce sont les deux codes qui traduisent le plus directement une charge excessive.

Les paramètres à examiner sont peu nombreux et se lisent en quelques minutes. Le nombre maximal de processus enfants du pool PHP, la durée d’exécution autorisée, et les délais d’attente du serveur web vers son backend forment le trio décisif.

# PHP-FPM : le pool trop petit produit des 502 sous charge
pm.max_children = 24
request_terminate_timeout = 60s

# Nginx : au-delà de ce délai, le client reçoit un 504
fastcgi_read_timeout 60s;

Augmenter ces valeurs sans rien changer d’autre revient souvent à déplacer le problème, en échangeant des 502 rapides contre des 504 lents. Le travail utile consiste d’abord à réduire ce que chaque requête coûte, ce qui ramène au délai de première réponse et à ce qui le compose.

Erreur 503 : que signifie service temporarily unavailable ?

Le 503 Service Unavailable indique que le serveur est momentanément incapable de traiter la requête, pour cause de surcharge ou de maintenance planifiée. La RFC 9110 insiste sur un point que presque personne n’applique : cette condition est présumée temporaire, et le serveur devrait indiquer par un en-tête Retry-After quand revenir.

C’est le seul code correct pour une maintenance. Servi avec son Retry-After, il dit aux moteurs de recherche de repasser plus tard et préserve l’indexation existante. Une maintenance servie en 200 avec une jolie page d’attente est autrement plus dangereuse : Google indexe alors cette page d’attente à la place du contenu réel, sur potentiellement des milliers d’URL.

<?php
// Maintenance correcte : code 503 et délai de retour explicite
http_response_code(503);
header('Retry-After: 3600');
header('Content-Type: text/html; charset=UTF-8');
echo '<h1>Maintenance en cours</h1><p>Retour prévu dans une heure.</p>';
exit;

La durée reste le facteur déterminant. Google conseille depuis longtemps ce dispositif pour les interruptions planifiées, mais un 503 qui se prolonge sur plusieurs jours finit par entraîner le retrait des URL de l’index. Quelques heures ne coûtent rien, plusieurs jours coûtent le référencement.

Que signifie un code 499 dans les logs Nginx ?

Le 499 n’appartient à aucune norme : il n’est pas au registre IANA, et il est propre à Nginx, qui le définit dans son code source sous le nom NGX_HTTP_CLIENT_CLOSED_REQUEST. Il signifie que le client a fermé la connexion avant que le serveur ne réponde. Aucune erreur n’a eu lieu côté serveur, personne n’attendait plus la réponse.

Ce code n’apparaît donc jamais dans un navigateur, uniquement dans les journaux d’accès. Et c’est là qu’il devient précieux, parce qu’il mesure indirectement quelque chose qu’aucun autre code ne dit : la patience réelle des clients face à la lenteur du backend.

Une part de 499 qui grimpe signale presque toujours un backend trop lent, avec des visiteurs qui ferment l’onglet ou des robots qui abandonnent avant la fin. C’est un indicateur de performance déguisé en code d’erreur, et son évolution dans le temps se surveille comme une métrique à part entière. Le compter dans les journaux ne demande qu’une ligne.

# Répartition des codes de statut sur les 100 000 dernières requêtes
tail -n 100000 /var/log/nginx/access.log \
  | awk '{print $9}' | sort | uniq -c | sort -rn

Quel est l’impact des codes de statut sur le référencement ?

Chaque famille de codes produit un effet distinct sur l’indexation, et la documentation d’exploration de Google, mise à jour le 4 février 2026, en donne le détail code par code. Le point le plus lourd de conséquences concerne les 5xx : face à une hausse des erreurs serveur, les robots de Google ralentissent temporairement leur exploration, et la baisse est proportionnelle au nombre d’URL concernées.

Ce ralentissement ne se corrige pas instantanément. Google précise que le rythme d’exploration remonte progressivement une fois que le serveur recommence à répondre en 2xx, ce qui signifie qu’un incident de quelques heures a un coût de visibilité qui se prolonge bien après sa résolution. Les URL déjà indexées sont conservées un temps, puis finissent par être retirées si les erreurs persistent.

Les autres familles se lisent plus simplement. Les 4xx, à l’exception notable du 429, n’ont aucun effet sur le rythme d’exploration : les URL concernées sortent de l’index et sont explorées de moins en moins souvent, sans que le reste du site en pâtisse. Les redirections transmettent le signal de canonicalisation, fort pour le 301, faible pour le 302.

Où voir les codes d’erreur rencontrés par Google ?

Google remonte tout ce qu’il rencontre à l’exploration dans la Search Console, sous l’onglet Pages, dans la section Pourquoi des pages ne sont pas indexées. Ce tableau liste les motifs de non-indexation, avec le nombre d’URL concernées par chacun et l’historique du site sur ce problème, et un clic sur une ligne donne les exemples d’URL affectées.

Les libellés y sont directement traduits des codes de statut, ce qui en fait le premier tableau de bord. On y trouve Erreur serveur (5xx), Erreur liée à des redirections, Erreur soft 404, Introuvable (404), Bloquée en raison d’une interdiction d’accès (403), Bloquée en raison d’une demande non autorisée (401), et une entrée générique pour les autres erreurs 4xx.

Une ligne mérite une lecture particulière parce qu’elle relie directement le référencement à la santé du serveur : Détectée, actuellement non indexée. La documentation de Search Console explique que Google voulait explorer ces URL mais a différé l’exploration parce que le site risquait d’être surchargé. Voir cette ligne enfler est le signal qu’un problème de performance est en train de coûter de l’indexation.

Le rapport Statistiques d’exploration, accessible depuis les paramètres de la propriété, complète utilement la lecture avec la répartition des codes de réponse dans le temps et l’état de l’hôte. C’est là que se lit la corrélation entre un pic de 5xx et la chute des requêtes d’exploration qui suit, un rapprochement que nous documentons systématiquement quand nous analysons le lien entre performance technique et visibilité.

Le tableau de référence des codes de statut HTTP

Voici les codes que l’on rencontre réellement sur le web, avec pour chacun ce qu’il coûte et l’action qu’il appelle. Les colonnes de coût sont ce qui distingue ce tableau des listes de définitions habituelles.

Code	Libellé	Ce que ça veut dire	Ce que ça coûte	Que faire
100	Continue	Le serveur accepte de recevoir la suite de la requête	Négligeable	Rien, mécanisme interne
101	Switching Protocols	Passage à un autre protocole, typiquement WebSocket	Négligeable	Rien
103	Early Hints	Ressources critiques annoncées avant la réponse finale	Gain net sur les TTFB élevés	Activer si le serveur le permet
200	OK	Succès, le contenu est dans la réponse	Le plus cher de la famille : tout le corps transite	Rien, c’est la cible
201	Created	Une ressource a été créée	Coût applicatif normal	Renvoyer l’en-tête Location
202	Accepted	Demande acceptée, traitement différé	Faible à l’émission	Prévoir un suivi d’état
204	No Content	Succès sans corps de réponse	Très faible : aucun octet utile	Réserver aux appels sans retour
206	Partial Content	Fragment de ressource, réponse à un Range	Proportionnel au fragment	Rien, attendu sur les médias
301	Moved Permanently	Déplacement définitif	Un cycle réseau complet, mis en cache durablement	Poser au niveau serveur, jamais en chaîne
302	Found	Détour temporaire	Un cycle réseau complet	Préférer au 301 tant que rien n’est certain
303	See Other	Rediriger en GET après un envoi	Un cycle réseau complet	Utiliser après un POST de formulaire
304	Not Modified	La copie du client est encore valable	Un aller-retour, presque zéro octet	Le rendre inutile par un cache long et immutable
307	Temporary Redirect	Comme 302, méthode préservée	Un cycle réseau complet	Obligatoire si un POST est redirigé
308	Permanent Redirect	Comme 301, méthode préservée	Un cycle réseau complet	Obligatoire si un POST est redirigé
400	Bad Request	Requête malformée	Faible si rejetée tôt	Valider en amont, pas dans le contrôleur
401	Unauthorized	Authentification requise	Faible	Ne jamais l’utiliser contre les robots
403	Forbidden	Accès refusé, définitivement	Quasi nul à l’edge, élevé en applicatif	Filtrer au plus tôt, jamais contre Googlebot
404	Not Found	Ressource introuvable	Souvent la requête la plus chère du site	Traiter les statiques au serveur web, mettre en cache
405	Method Not Allowed	Méthode HTTP non acceptée	Faible	Renvoyer l’en-tête Allow
406	Not Acceptable	Aucun format ne convient au client	Faible	Assouplir la négociation de contenu
408	Request Timeout	Le client a mis trop de temps à envoyer	Une connexion mobilisée pour rien	Ajuster les délais d’inactivité
409	Conflict	Conflit avec l’état actuel de la ressource	Coût applicatif normal	Expliquer le conflit dans le corps
410	Gone	Suppression volontaire et définitive	Identique au 404	Réserver aux retraits assumés sans successeur
415	Unsupported Media Type	Format du corps non géré	Faible	Documenter les formats acceptés
422	Unprocessable Content	Syntaxe correcte, contenu invalide	Coût de la validation	Détailler les champs en erreur
429	Too Many Requests	Trop de requêtes sur la période	Économie nette : il évite la saturation	Servir à l’edge, toujours avec Retry-After
499	Client Closed Request	Le client est parti avant la réponse (Nginx)	Le travail serveur est perdu	Surveiller la part : c’est un signal de lenteur
500	Internal Server Error	Défaillance applicative non qualifiée	Toute la pile payée pour un échec	Lire le journal d’erreurs, rien d’autre
502	Bad Gateway	Réponse invalide du serveur en amont	Symptôme de pool saturé	Dimensionner le pool, alléger les requêtes
503	Service Unavailable	Indisponibilité temporaire ou maintenance	Faible, mais coûteux en visibilité si prolongé	Toujours accompagner d’un Retry-After
504	Gateway Timeout	Le serveur amont n’a pas répondu à temps	Symptôme de traitement trop long	Optimiser la requête avant d’allonger le délai

Une lecture transversale de ce tableau fait ressortir un motif net. Les codes les plus coûteux ne sont pas les erreurs les plus spectaculaires, mais les réponses banales produites au mauvais niveau : un 404 applicatif, une redirection posée par une extension, un 304 calculé par le CMS. Aucun de ces trois cas n’apparaît dans un rapport d’erreurs.

La deuxième lecture concerne les colonnes d’action : la moitié des recommandations tiennent en une même consigne, servir la réponse le plus en amont possible. C’est ce qui rend l’inventaire des codes de statut d’un site aussi instructif qu’un profil de charge.

Comment analyser les codes de statut dans les logs serveur ?

Les journaux d’accès du serveur web sont la seule source qui voit l’intégralité du trafic, robots compris, là où les outils de mesure côté navigateur ne voient que les visiteurs qui ont exécuté du JavaScript. C’est donc là, et nulle part ailleurs, que se lit la volumétrie réelle des 404, la part de 499, et les pics de 5xx corrélés à la charge.

Quatre requêtes suffisent à dresser un état des lieux exploitable en quelques minutes. La première donne la répartition globale, la deuxième identifie les URL fantômes les plus demandées, la troisième isole les erreurs serveur, la quatrième révèle qui déclenche ces requêtes.

# Les 30 URL en 404 les plus demandées
awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -rn | head -30

# Les erreurs serveur des dernières heures, avec leur URL
awk '$9 ~ /^5/ {print $9, $7}' access.log | sort | uniq -c | sort -rn | head -20

# Qui génère les 404 : visiteurs ou robots ?
awk '$9 == 404' access.log | grep -o 'bot\|crawler\|spider' | sort | uniq -c

Le rapport Statistiques d’exploration de la Search Console apporte le point de vue complémentaire, celui de Google, avec la répartition des codes de réponse et l’état de l’hôte sur quatre-vingt-dix jours. Un crawler complète le dispositif en révélant ce qu’aucun journal ne montre : les chaînes de redirection internes et les soft 404, qui par définition répondent en 200 et passent donc inaperçues dans les logs.

Ces trois sources ne se recoupent que partiellement, et c’est précisément leur croisement qui est instructif. Le vocabulaire employé par chacune d’entre elles figure d’ailleurs dans notre glossaire des termes de la web performance, pour qui découvre ces rapports.

Un code de statut est une décision d’architecture

La plupart des sites choisissent leurs codes de statut sans le savoir. Personne n’a décidé que les 404 seraient traitées par le routeur du CMS, que les redirections seraient posées par une extension, ou que la maintenance s’afficherait en 200. Ces choix se sont faits par défaut, au fil des installations et des migrations, et ils continuent de se payer à chaque requête sans jamais apparaître dans un rapport de performance.

Ce qui rend le sujet intéressant, c’est qu’il fait tomber la frontière habituelle entre le référencement et l’infrastructure. Un même réglage, l’endroit où l’on produit un 404, détermine simultanément la charge d’un serveur, le budget d’exploration consommé, et ce que Search Console affichera dans trois semaines. Peu de leviers techniques ont cette portée transversale pour un effort aussi modeste.

Reste la question que ces trois chiffres posent en creux à toute équipe technique : qui, dans l’organisation, est propriétaire de cette décision ? Le développeur qui écrit le routeur, l’administrateur système qui configure Nginx, et le responsable du référencement qui lit la Search Console regardent le même code de statut depuis trois points de vue différents, et aucun des trois ne le voit en entier. Les sites qui traitent bien leurs codes de statut sont souvent, tout simplement, ceux où ces trois personnes se parlent.