La solicitud se completó correctamente.
Cuándo usarlo
Lo habitual para un GET correcto o un POST que devuelve un resultado.
A tener en cuenta
El mayor error con 200 es el “soft 404”: una página de error o un resultado vacío servidos con estado 200. Google detecta muchos de ellos y los señala en Search Console, pero desperdician presupuesto de rastreo y pueden mantener indexadas URL basura. Las aplicaciones de una sola página son culpables frecuentes, porque el servidor devuelve index.html con 200 para cualquier ruta; devuelve un 404 real para las rutas desconocidas o añade noindex.
Las API que envuelven los errores en un 200 con un campo de error rompen la monitorización, los reintentos y la caché, porque todo parece correcto. Un 200 a un GET puede guardarse en los navegadores y las CDN, incluso de forma heurística cuando solo hay Last-Modified, así que define Cache-Control explícitamente. Añade un ETag o Last-Modified para que los clientes puedan revalidar y obtener un 304 barato, y usa 204 cuando de verdad no haya nada que devolver.
Éxito (2xx)
Los códigos 2xx indican éxito: el servidor recibió, entendió y aceptó la solicitud.
Cómo se ve
HTTP/1.1 200 OKCómo enviarlo
| Node.js / Express | res.status(200).end() |
|---|---|
| Python / Flask | return '', 200 |
| nginx | return 200; |
Cómo comprobarlo
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/