La requête a réussi.
Quand l’utiliser
Valeur par défaut pour un GET réussi, ou un POST qui renvoie un résultat.
Bon à savoir
Le plus gros piège du 200 est la « soft 404 » : une page d’erreur ou un résultat vide servi avec le statut 200. Google en détecte beaucoup et les signale dans la Search Console, mais elles gaspillent le budget de crawl et peuvent garder des URL inutiles dans l’index. Les applications monopages sont souvent en cause, car le serveur renvoie index.html avec un 200 pour chaque chemin ; renvoyez une vraie 404 pour les routes inconnues ou ajoutez noindex.
Les API qui enveloppent les erreurs dans un 200 avec un champ error cassent la supervision, les nouvelles tentatives et le cache, puisque tout paraît réussi. Un 200 en réponse à un GET peut être stocké par les navigateurs et les CDN, même de façon heuristique quand seul Last-Modified est présent : définissez donc Cache-Control explicitement. Ajoutez un ETag ou un Last-Modified pour que les clients puissent revalider et obtenir un 304 peu coûteux, et utilisez 204 quand il n’y a vraiment rien à renvoyer.
Succès (2xx)
Les codes 2xx indiquent un succès : le serveur a reçu, compris et accepté la requête.
À quoi ça ressemble
HTTP/1.1 200 OKComment l’envoyer
| Node.js / Express | res.status(200).end() |
|---|---|
| Python / Flask | return '', 200 |
| nginx | return 200; |
Comment le vérifier
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/