Códigos de estado HTTP: guía completa de todos los códigos de respuesta

Toda respuesta HTTP empieza por un número de tres cifras, y ese número es el servidor contándote, de la forma más breve posible, qué ha pasado con tu petición. Casi siempre no lo ves: la página carga y el navegador sigue adelante. El número solo se vuelve visible cuando algo va mal, que es justo cuando necesitas saber qué significa.

Pero los códigos de estado no son solo diagnóstico: son instrucciones. Un 301 le dice a un buscador que mueva su entrada de índice de forma permanente; un 429 le dice a un cliente exactamente cómo frenar; un 503 le dice a un rastreador que vuelva más tarde en lugar de retirar tu página. Devolver el código equivocado es una de las formas más silenciosas de perder tráfico, porque nada se rompe a la vista. Esta guía recorre cada clase, los códigos que te vas a encontrar de verdad y cómo comprobar qué devuelve realmente una URL.

Por qué importan los códigos de estado

Cuatro públicos leen tus códigos de estado, y cada uno actúa de forma distinta:

• Los navegadores. Deciden si siguen una redirección, si reutilizan una copia en caché y si reenvían el cuerpo de un formulario.
• Los buscadores. El código decide si una URL se indexa, se fusiona con otra, se reintenta más tarde o se descarta. Servir una página «no encontrado» amable con un 200 es el error clásico: al rastreador se le dice que la página existe y la mantiene en el índice.
• Los clientes de API. Un cliente bien escrito se bifurca según el código. Un 429 o un 503 merecen reintento; un 400 nunca, porque reintentar una petición mal formada produce el mismo error.
• Tu propia monitorización. Las alertas y las tasas de error se construyen casi siempre sobre códigos de estado, así que un servicio que devuelve 200 con un error en el cuerpo es invisible para sus propios paneles.

Las cinco clases

La primera cifra te dice de quién es la responsabilidad y qué hacer a continuación. Si no recuerdas nada más, recuerda esta tabla.

La división entre 4xx y 5xx es la que más importa en la práctica, porque responde a la única pregunta que cuenta durante un incidente: ¿esto lo arreglo yo o lo arreglan ellos?

Los códigos que te vas a encontrar

Hay decenas de códigos registrados, pero una jornada de trabajo implica quizá quince. Los de éxito son los más simples. 200 OK es la respuesta corriente. 201 Created es la respuesta correcta a un POST que ha creado algo, y debería llevar una cabecera Location apuntando al nuevo recurso. 204 No Content dice que la petición tuvo éxito y que deliberadamente no hay nada que devolver, que es la respuesta adecuada a un DELETE. 206 Partial Content es lo que hace posible saltar en un vídeo y reanudar descargas.

Redirecciones: 301, 302, 307 y 308

Las redirecciones causan más daño de SEO que cualquier otra clase, casi siempre porque se intercambian la forma permanente y la temporal.

• 301 Moved Permanently: la URL ha cambiado para siempre. Los buscadores transfieren las señales de posicionamiento a la nueva dirección y acaban sustituyendo la antigua en su índice. Úsalo en migraciones de dominio, el paso de HTTP a HTTPS y al añadir o quitar www.
• 302 Found: temporal. La URL antigua sigue indexada porque has dicho que va a volver. Úsalo en pruebas A/B, ventanas cortas de mantenimiento y enrutado geográfico que piensas revertir.
• 307 Temporary Redirect: como 302, pero se garantiza que se conservan el método y el cuerpo. Un POST redirigido con 307 llega como POST; históricamente algunos clientes convertían un POST redirigido en un GET.
• 308 Permanent Redirect: el equivalente permanente de 307: la misma semántica de caché que 301, conservando el método.
• 304 Not Modified: no es realmente una redirección. Responde a una petición condicional y significa «tu copia en caché sigue valiendo», que es por lo que un sitio bien configurado transfiere muchos menos datos de lo que sugiere su peso.

Dos reglas: nunca encadenes redirecciones cuando basta un salto, porque cada salto cuesta latencia y presupuesto de rastreo, y nunca redirijas todas las páginas inexistentes a la portada. Lo segundo parece ordenado y cuenta algo falso tanto a los usuarios como a los rastreadores.

Errores de cliente: 400, 401, 403, 404 y 429

La familia 4xx dice que el problema era la petición. Conviene acertar con las distinciones, porque los clientes se comportan de forma distinta con cada una.

• 400 Bad Request: sintaxis mal formada: JSON roto, un campo obligatorio ausente, un parámetro que no se puede interpretar. Nunca reintentable tal cual.
• 401 Unauthorized: mal nombrado; significa no autenticado. Sin credenciales, o con credenciales que el servidor no pudo verificar. Debería incluir una cabecera WWW-Authenticate.
• 403 Forbidden: el servidor sabe quién eres y aun así no puedes hacer esto. Volver a autenticarse no ayudará.
• 404 Not Found: no existe nada en esta URL. El servidor no dice si existió alguna vez.
• 405 Method Not Allowed: la URL existe pero no para este verbo. Incluye una cabecera Allow con los que sí funcionan.
• 409 Conflict: la petición choca con el estado actual, por ejemplo una clave duplicada o una versión obsoleta.
• 410 Gone: el recurso existió y se retiró deliberadamente. Los buscadores descartan un 410 más rápido que un 404, así que es la mejor opción cuando has retirado contenido a propósito.
• 422 Unprocessable Content: la sintaxis se interpretó pero los valores no pasan la validación. Útil para separar «no puedo leer esto» de «lo he leído y está mal».
• 429 Too Many Requests: has excedido un límite de peticiones. Acompáñalo siempre de una cabecera Retry-After; sin ella, los clientes reintentan de inmediato y agravan la sobrecarga.

Errores de servidor: 500, 502, 503 y 504

Un 5xx significa que tu petición era razonable y el servidor falló igualmente. Los cuatro habituales apuntan a capas distintas, lo que los hace genuinamente útiles durante un incidente.

• 500 Internal Server Error: una excepción no gestionada en la aplicación. El comodín genérico, y lo primero que hay que buscar en los registros.
• 502 Bad Gateway: un proxy o balanceador recibió una respuesta vacía o inválida del origen. Normalmente la aplicación detrás del proxy se cayó o no estaba escuchando.
• 503 Service Unavailable: el servidor está sobrecargado o en mantenimiento. Es el único código de la familia que deberías devolver a propósito, con una cabecera Retry-After, durante una parada planificada: los rastreadores conservan la página y vuelven.
• 504 Gateway Timeout: el proxy esperó al origen y se rindió. Apunta a una dependencia lenta más que a una caída.

Durante una incidencia, la diferencia entre 502 y 504 te dice si tu aplicación se ha muerto o solo se ha vuelto lenta, que suele ser la pista más rápida disponible.

Códigos de estado y SEO

Los buscadores tratan el código de estado como la afirmación autorizada sobre una URL, y se fían de él más que de cualquier cosa del cuerpo de la página. De ahí se derivan cuatro consecuencias:

1. Los «soft 404» desperdician presupuesto de rastreo. Un mensaje de «página no encontrada» servido con 200 mantiene indexada una URL muerta que compite con tus páginas reales. Devuelve un 404 o un 410 de verdad.
2. Usa 301 para mudanzas permanentes. Un 302 en una mudanza real deja indexada la URL antigua y reparte las señales entre dos direcciones.
3. Mantén cortas las cadenas de redirección. Cada salto añade latencia y los rastreadores solo siguen un número limitado antes de rendirse. Apunta la URL antigua directamente al destino final.
4. Devuelve 503 durante el mantenimiento. Un 503 con Retry-After le dice al rastreador que vuelva. Un tiempo de espera agotado o un 500 parecen un sitio roto.

Las redirecciones también interactúan con HTTPS. Si tu redirección de http:// a https:// está puesta pero el certificado es inválido o ha caducado, los visitantes ven un aviso del navegador antes de que la redirección importe, así que conviene confirmar el certificado con el verificador de certificados SSL al mismo tiempo.

Cómo comprobar un código de estado

Tu navegador oculta el código cuando la carga va bien, así que hay que pedirlo explícitamente. Tres formas fiables:

1. El panel de red del navegador. Abre las herramientas de desarrollo, recarga y lee la columna de estado. Esto muestra la cadena completa de redirecciones, que un solo número no puede.
2. curl -I https://example.com. Una petición HEAD imprime la línea de estado y las cabeceras sin descargar el cuerpo. Añade -L para seguir las redirecciones y ver cada salto.
3. Una referencia que puedas buscar. Cuando tienes el número y necesitas el significado, las obligaciones y las causas típicas, nuestra referencia de códigos de estado HTTP enumera todos los códigos con qué hacer al respecto.

Dos cosas que comprobar más allá del número. Primero, prueba la URL exacta que tocaría un usuario, con o sin barra final, porque a menudo se resuelven de forma distinta. Segundo, si la respuesta es un 429, lee el valor de Retry-After y averigua si la espera de tu cliente lo respeta de verdad; la calculadora de límites de peticiones convierte un límite en intervalos concretos.

Errores habituales que evitar

• Devolver 200 con un error en el cuerpo. La monitorización, las cachés, los rastreadores y los clientes leen el código, no tu JSON. Es el error más consecuente de la lista.
• Usar 302 para una mudanza permanente. Las señales de posicionamiento se quedan en la URL antigua, a veces durante meses.
• Redirigir todos los 404 a la portada. Te oculta los enlaces rotos y produce «soft 404» para los rastreadores.
• 403 donde corresponde 401. Un cliente que recibe 403 no intentará autenticarse, porque 403 dice que la autenticación no es el problema.
• 429 sin Retry-After. Los clientes adivinan, normalmente reintentando al instante, que es exactamente la conducta que el límite existe para evitar.
• Dejar que el mantenimiento devuelva un tiempo de espera agotado. Devuelve 503 con Retry-After para conservar tus entradas de índice.
• Cadenas largas de redirección tras una migración. Cada migración añade un salto; redúcelas a uno la próxima vez que toques las reglas.

Comprueba tus propios códigos

Los códigos de estado son el diagnóstico más barato de la web: un número, sin autenticación y una respuesta sin ambigüedad sobre si una URL funciona, se ha movido o ha fallado. Empieza comprobando qué devuelven tus páginas importantes, confirma que tus redirecciones son permanentes donde deben serlo y temporales donde deben serlo, y asegúrate de que cada ruta de error devuelve un código acorde con lo que pasó de verdad.

Herramientas y guías relacionadas:

• Códigos de estado HTTP: referencia buscable de todos los códigos de respuesta.
• Calculadora de límites de peticiones: convierte un límite en intervalos seguros y un Retry-After.
• Búsqueda de DNS: confirma que un dominio resuelve antes de depurar sus respuestas.
• Verificador de certificados SSL: comprueba el certificado detrás de tu redirección HTTPS.
• Redirecciones 301 y 302: cuál usar y qué ve el SEO - qué redirección usar y qué efecto tiene cada una en tu posicionamiento.
• 404 o 410: qué le dice cada uno a Google sobre una página muerta - qué le dice cada código a Google sobre una página que eliminaste.

Preguntas frecuentes