---
title: "Codes de statut HTTP : le guide complet, de la signification au coût serveur"
description: "Un 404, une redirection 301 ou une rafale de 500 ne sont pas que des messages d'état : chacun consomme des ressources serveur, retarde un affichage et pèse sur l'exploration de Google. Reste à savoir combien, et surtout à quel endroit ces réponses sont réellement produites."
url: "https://agencewebperformance.fr/http-codes/"
lang: "fr-FR"
published: "2026-08-16T19:00:00+02:00"
modified: "2026-08-16T19:00:00+02:00"
---

cache | Codes HTTP | Serveur web

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

Auteur

Eroan Boyer

Publié le

16 août 2026

Durée de lecture

34 minutes

![Décapotable bleue face à un embranchement : à gauche une route barrée signalée 404, à droite un élévateur signalé 301.](https://agencewebperformance.fr/wp-content/uploads/2026/08/codes-statut-http-20260817.jpg)

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](https://www.rfc-editor.org/rfc/rfc9110), publiée en juin 2022 pour remplacer la RFC 7231, et le registre officiel qui les recense est tenu par l’[IANA](https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml). 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](https://www.rfc-editor.org/rfc/rfc9110#section-15) 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 |

![Schéma comparant les trois niveaux où un code de statut HTTP peut être produit : edge et CDN, serveur web, application, avec les ressources mobilisées par chacun.](https://agencewebperformance.fr/wp-content/uploads/2026/08/codes-statut-http-niveaux-production-20260816.svg)

*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](https://developers.google.com/crawling/docs/troubleshooting/http-status-codes?hl=fr) 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](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/200) 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`](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/204) 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`](https://www.rfc-editor.org/rfc/rfc9110#name-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.

![Schéma comparant le chemin réseau d'une requête directe et celui d'une requête passant par une redirection 301, qui ajoute un cycle DNS, TCP et TLS complet.](https://agencewebperformance.fr/wp-content/uploads/2026/08/codes-statut-http-cout-redirection-20260816.svg)

*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](https://developer.chrome.com/docs/lighthouse/performance/redirects), 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](https://agencewebperformance.fr/optimiser-lcp/).

```
// 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`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/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`](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/304) 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`](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Headers/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.

![Schéma comparant trois façons de servir une ressource déjà connue du navigateur : réponse 200 complète, validation par code 304 sans corps, et cache encore frais sans aucune requête.](https://agencewebperformance.fr/wp-content/uploads/2026/08/codes-statut-http-mecanisme-304-20260816.svg)

*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](https://web.dev/articles/http-cache?hl=fr), et que nous développons dans notre guide sur [les différentes couches de mise en cache](https://agencewebperformance.fr/cache-web/).

```
# 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`](https://www.rfc-editor.org/rfc/rfc8297), 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](https://developer.chrome.com/docs/web-platform/early-hints?hl=fr), et la couverture navigateur se consulte sur [Can I Use](https://caniuse.com/mdn-http_status_103). Cette piste vient naturellement compléter [le travail de réduction du délai de première réponse](https://agencewebperformance.fr/optimiser-ttfb/), 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](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/404) 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](https://agencewebperformance.fr/prestations/audit-performance/) : **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.

![Schéma en cinq étapes montrant comment une rafale d'erreurs 404 traitées par l'application sature le pool de processus et dégrade le temps de réponse de tout le site.](https://agencewebperformance.fr/wp-content/uploads/2026/08/codes-statut-http-saturation-404-20260816.svg)

*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](https://agencewebperformance.fr/prestations/hebergement-wordpress-performant/) **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](https://support.google.com/webmasters/answer/181708?hl=fr) 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](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/403) 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`](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/400) 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`](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/401) 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`](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/422) : 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`](https://www.rfc-editor.org/rfc/rfc9110#name-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`](https://developer.mozilla.org/fr/docs/Web/HTTP/Guides/Redirections) 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`](https://www.rfc-editor.org/rfc/rfc6585#section-4), 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`](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Headers/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

[Votre site est-il aussi rapide que vos visiteurs l’espèrent ?](https://agencewebperformance.fr/contact/)

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

L’[erreur http `500` Internal Server Error](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/500) 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](https://wordpress.org/documentation/article/common-wordpress-errors/) 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`](https://developer.mozilla.org/fr/docs/Web/HTTP/Reference/Status/502) 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](https://agencewebperformance.fr/optimiser-ttfb/).

## Erreur `503` : que signifie service temporarily unavailable ?

Le [`503 Service Unavailable`](https://www.rfc-editor.org/rfc/rfc9110#name-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`](https://github.com/nginx/nginx/blob/master/src/http/ngx_http_request.h). 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](https://developers.google.com/crawling/docs/troubleshooting/http-status-codes?hl=fr), 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](https://support.google.com/webmasters/answer/7440203?hl=fr) 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é](https://agencewebperformance.fr/limpact-seo-webperf/).

## 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](https://agencewebperformance.fr/definitions-webperf/), 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**.

## Poursuivez votre lecture

![Robots d’IA et crawlers : ce qu’ils coûtent vraiment à votre serveur](https://agencewebperformance.fr/wp-content/uploads/2026/10/robots-ia-20261015.jpg)

Robots d’IA et crawlers : ce qu’ils coûtent vraiment à votre serveur

cache | Infrastructure | Robots | SEO | TTFB | WordPress

[Robots d’IA et crawlers : ce qu’ils coûtent vraiment à votre serveur](https://agencewebperformance.fr/robots-ia/)

![Google Tag Manager et web performance : le coût caché de votre conteneur](https://agencewebperformance.fr/wp-content/uploads/2026/09/google-tag-manager-20260917.jpg)

Google Tag Manager et web performance : le coût caché de votre conteneur

Analytics | Core Web Vitals | JavaScript | Scripts tiers

[Google Tag Manager et web performance : le coût caché de votre conteneur](https://agencewebperformance.fr/google-tag-manager/)

![Chat, avis et enquêtes : ce que vos widgets de relation client coûtent vraiment](https://agencewebperformance.fr/wp-content/uploads/2026/09/widget-chat-avis-20260917.jpg)

Chat, avis et enquêtes : ce que vos widgets de relation client coûtent vraiment

CLS | Core Web Vitals | JavaScript | Scripts tiers | Widgets

[Chat, avis et enquêtes : ce que vos widgets de relation client coûtent vraiment](https://agencewebperformance.fr/widget-chat/)

[Tous nos articles](https://agencewebperformance.fr/blog/)