Códigos de estado HTTP explicados: los que de verdad se confunden

El primer dígito es la única parte que algunos clientes leen

La RFC 9110 exige que un cliente entienda la clase de un código de estado aunque no reconozca el código en sí, y que trate cualquier código desconocido como el x00 de su clase. Un cliente que nunca ha oído hablar del 451 lo maneja como un 400; un 599 desconocido se maneja como un 500. Esa regla es lo que hace extensible el espacio, y también significa que la clase carga con casi todo el comportamiento: las cachés deciden a partir de ella si almacenan, los proxies si reintentan y los rastreadores si indexan, casi siempre antes de analizar nada de tu cuerpo de respuesta.

La consecuencia práctica es que devolver un 200 con el error descrito en el cuerpo coloca el fallo donde nada más puede verlo. Tu sonda de disponibilidad marca verde, tu CDN cachea la página de error y un buscador la indexa como un documento real. Es el problema del soft 404 en su forma general, y merece una auditoría, porque el arreglo es un cambio de una línea en el código de estado y no algo arquitectónico.

Redirecciones: cuáles conservan tu POST

La rejilla de cuatro códigos de redirección cruza en realidad dos preguntas: permanente o temporal, y si el método sobrevive. 301 y 308 son permanentes, 302 y 307 temporales; 307 y 308 son los dos que prohíben al cliente cambiar la petición. MDN es directo sobre por qué existe el par nuevo: el 301 ya exigía que el método y el cuerpo quedaran intactos, pero esa exigencia la manejaban mal los clientes antiguos, que pasaban a GET. Nadie podía arreglar el parque instalado, así que se acuñaron dos códigos nuevos con la garantía escrita en su definición.

Así que la elección se sigue del tráfico. Para una página que solo recibe GET, el 301 está bien y es a lo que más acostumbrados están los buscadores. Para una ruta de API, el destino de un formulario o cualquier cosa que pueda recibir POST, PUT o DELETE, usa 308 y la petición llega intacta. Una advertencia sobre la permanencia: los navegadores cachean un 301 con agresividad y algunos lo guardan mucho más de lo que esperas, así que un 301 emitido durante un experimento puede sobrevivirlo en máquinas a las que no tienes acceso. Sirve 302 o 307 mientras aún decides.

Los errores que más a menudo se devuelven mal

401 y 403 son el par que más tiempo de soporte cuesta. El 401 significa que la petición carecía de credenciales de autenticación válidas, y MDN señala que se envía con una cabecera WWW-Authenticate que describe el esquema que el servidor espera: es una invitación a reintentar con credenciales. El 403 es la situación contraria: las credenciales son perfectamente válidas y el cliente sigue sin permiso para esta acción. Devolver un 401 a un usuario autenticado le dice a su cliente que vuelva a autenticarse, lo que producirá exactamente el mismo rechazo, y le hace creer que su sesión está rota cuando no lo está.

404 y 410 solo se diferencian en el grado de certeza, y ahí está la clave. La guía de MDN es explícita: si quien opera el servidor no sabe si la situación es temporal o permanente, debe usar 404. El 410 se usa cuando retiraste la cosa a propósito y no volverá: es cacheable por defecto y dice a los rastreadores que dejen de preguntar. Retry-After, por su parte, es una cabecera que lleva un retardo en segundos o una fecha HTTP; en un 503 estima cuánto estará el servicio no disponible y en un 429 indica cuánto esperar antes de una nueva petición. Es una guía, no un contrato, y MDN señala que el soporte entre clientes es desigual, pero Googlebot la respeta, lo que ya justifica ponerla durante un mantenimiento planificado.

Preguntas frecuentes

¿Una migración de sitio debe usar 301 o 308?

Para páginas que solo se piden con GET, el 301 es el valor seguro y el que todo rastreador y proxy lleva décadas manejando. Recurre al 308 en todo lo que pueda recibir POST, PUT o DELETE — endpoints de formulario, rutas de API, receptores de webhooks — porque ahí es donde un cliente que degrada el método en silencio convierte una redirección en un cuerpo de petición perdido. Nada impide usar ambos en la misma migración, ruta por ruta.

¿Qué debe devolver una API cuando falla la validación?

Usa 400 Bad Request cuando la petición en sí está malformada y el servidor no puede analizarla: JSON roto, una cabecera obligatoria ausente. Usa 422 Unprocessable Content cuando la sintaxis es correcta pero el contenido incumple tus reglas, como un cuerpo bien formado con una fecha de fin anterior a la de inicio. Lo que no debes devolver es un 500, que culpa al servidor de un error del cliente y contamina tu presupuesto de errores, ni un 200 con el problema descrito en el cuerpo, que oculta el fallo a todas las capas entre tú y quien llama.

¿Los 404 perjudican el posicionamiento?

Un 404 es una respuesta válida y honesta, y una parte normal de cualquier sitio con algo de historia; una página que ya no existe debe decirlo. El daño viene de los sustitutos. Un soft 404 — una página amable servida con estado 200 — mantiene URL muertas en el índice y gasta presupuesto de rastreo en nada. Redirigir en bloque toda página ausente a la portada es el mismo error disfrazado de 301. Si la retirada fue deliberada y permanente, el 410 lo dice sin rodeos.