¿Qué son los códigos de estado HTTP?
Los códigos de estado HTTP son los números de tres dígitos que un servidor devuelve con cada respuesta para indicar al cliente qué ha pasado: la solicitud funcionó, el recurso se movió, el cliente cometió un error o el servidor falló. Están definidos en el estándar HTTP (RFC 9110) y son la forma más rápida de entender por qué una página, una llamada a la API o una comprobación de monitorización se comportó como lo hizo. Esta guía cubre los códigos que realmente encontrarás en producción, qué significan para el SEO y el uptime y cuáles merecen una alerta.
Las cinco clases de códigos de estado HTTP
El primer dígito de un código de estado define su clase. Conocer la clase te dice al instante si se trata de un éxito, una redirección, un problema del cliente o un fallo del servidor.
Clases de códigos de estado
Respuestas informativas 1xx
Los códigos 1xx son respuestas provisionales que se envían antes de la definitiva. Los navegadores y las bibliotecas HTTP los gestionan automáticamente, por lo que rara vez aparecen en los registros o en los resultados de monitorización.
Continue
El servidor ha recibido las cabeceras de la solicitud y el cliente puede enviar el cuerpo. Se usa con la cabecera Expect: 100-continue en subidas grandes.
Switching Protocols
El servidor acepta cambiar de protocolo a petición del cliente, normalmente al actualizar una conexión a WebSocket.
Early Hints
Early Hints: el servidor envía cabeceras Link antes de la respuesta final para que el navegador empiece a precargar CSS crítico, fuentes o scripts.
Respuestas de éxito 2xx
Los códigos 2xx indican que la solicitud se recibió, se entendió y se aceptó. Para la mayoría de páginas y endpoints de health check, 200 es la respuesta esperada; cualquier otra merece una segunda mirada.
OK
La solicitud se completó y el cuerpo de la respuesta contiene el recurso solicitado. Es la respuesta normal para páginas y solicitudes GET.
Created
La solicitud se completó y creó un recurso nuevo, normalmente tras un POST a una API. La cabecera Location suele apuntar al nuevo recurso.
No Content
La solicitud se completó, pero no hay cuerpo que devolver. Habitual en solicitudes DELETE y en APIs que solo confirman una acción.
Partial Content
El servidor devuelve solo una parte del recurso porque el cliente envió una cabecera Range. Se usa para streaming de vídeo y descargas reanudables.
Qué vigilar en las respuestas 2xx
- Un 200 no demuestra que la página funcione: una página de error servida con 200 aparece como «soft 404» en Google Search Console
- Comprueba que las páginas clave devuelven el contenido esperado, no solo un código de éxito
- Espera 201 o 204 de los endpoints de escritura; un 200 ahí puede indicar un cambio en la API
- Un 206 solo debería aparecer donde realmente sirves solicitudes por rangos
Redirecciones 3xx
Los códigos 3xx indican al cliente que el recurso está en otro lugar o que no ha cambiado. Elegir la redirección correcta es importante para el SEO: Google trata de forma distinta las redirecciones permanentes y las temporales al decidir qué URL indexar.
Moved Permanently
Moved Permanently. El recurso tiene una nueva URL permanente. Úsalo para cambios de dominio, migraciones a HTTPS y nuevas estructuras de URL. Los clientes pueden convertir un POST en GET al seguirlo.
Found
Found. El recurso está temporalmente en otra URL y la original debe seguir indexada. Úsalo para cambios breves, como páginas de mantenimiento.
Not Modified
Not Modified. La copia en caché sigue siendo válida, así que el servidor no envía cuerpo. Señal de que las solicitudes condicionales y las cabeceras de caché funcionan.
Temporary Redirect
Temporary Redirect. Como 302, pero el cliente debe repetir la solicitud con el mismo método y cuerpo; importante para formularios y llamadas a la API.
Permanent Redirect
Permanent Redirect. Como 301, pero el método y el cuerpo no deben cambiar. La opción segura para mover endpoints de API de forma permanente.
Cómo afectan las redirecciones al SEO
- Google considera 301 y 308 una señal fuerte para indexar la URL de destino, y 302 y 307 una señal débil (Google Search Central)
- Los rastreadores de Google siguen hasta 10 saltos de redirección por defecto, pero cada salto añade latencia: enlaza directamente a la URL final
- Los bucles de redirección hacen que una URL sea inaccesible para usuarios y rastreadores
- Usa redirecciones permanentes para cambios permanentes; un 302 de larga duración envía señales contradictorias
- Tras una migración, comprueba que las URL antiguas redirigen en lugar de devolver 404
Errores del cliente 4xx
Los códigos 4xx indican que el servidor cree que el cliente ha cometido un error: una URL incorrecta, credenciales ausentes o demasiadas solicitudes. Son los errores que más ven los usuarios, y un aumento repentino suele apuntar a un enlace roto, un fallo en un despliegue o un cambio en la API.
Bad Request
Bad Request. El servidor no puede procesar la solicitud por sintaxis incorrecta, JSON no válido o parámetros ausentes. Revisa la validación del cliente y los payloads de la API.
Unauthorized
Unauthorized. Falta la autenticación o no es válida. Es normal en endpoints protegidos; un aumento puede indicar tokens caducados o ataques de relleno de credenciales.
Forbidden
Forbidden. El servidor entendió la solicitud, pero la rechaza incluso con credenciales válidas. Revisa roles, permisos de archivos y reglas del firewall y la CDN.
Not Found
Not Found. El servidor no encuentra el recurso solicitado. Suele deberse a páginas eliminadas, errores tipográficos o redirecciones que faltan.
Gone
Gone. El recurso se eliminó a propósito y no volverá. Google trata 404 y 410 igual: la URL se elimina del índice.
Too Many Requests
Too Many Requests. El cliente superó un límite de solicitudes. La cabecera Retry-After indica cuándo volver a intentarlo. Google trata el 429 como un error del servidor y rastrea más despacio.
Qué vigilar en las respuestas 4xx
- Errores 404 en páginas que antes funcionaban: normalmente falta una redirección tras un lanzamiento o una migración
- Tasas crecientes de 401/403, que pueden indicar credenciales caducadas o reglas de acceso mal configuradas
- Errores 400 tras un despliegue, a menudo señal de un cambio en la API
- Errores 429 que afectan a usuarios legítimos o a Googlebot: tus límites son demasiado estrictos
- Las URL indexadas que devuelven 4xx se eliminan del índice de Google
Errores del servidor 5xx
Los códigos 5xx indican que la solicitud era válida, pero el servidor (o algo detrás de él) falló. Son los errores que tumban un sitio, así que siempre deberían generar una alerta.
Internal Server Error
Internal Server Error. Una condición inesperada impidió al servidor atender la solicitud: normalmente una excepción no controlada, una consulta a la base de datos fallida o una configuración incorrecta.
Bad Gateway
Bad Gateway. Un proxy, balanceador de carga o CDN recibió una respuesta no válida del servidor de origen. Comprueba que la aplicación que hay detrás funciona y es accesible.
Service Unavailable
Service Unavailable. El servidor no puede atender la solicitud temporalmente por sobrecarga o mantenimiento. Envía una cabecera Retry-After durante las paradas planificadas.
Gateway Timeout
Gateway Timeout. Un proxy o gateway no recibió a tiempo la respuesta del servidor de origen. Busca consultas lentas, procesos bloqueados o problemas de red.
Qué vigilar en las respuestas 5xx
- Cualquier 5xx en la página de inicio, el login, el checkout o el endpoint de health check requiere atención inmediata
- 502 y 504 suelen apuntar a la infraestructura entre el usuario y tu aplicación: proxies, balanceadores de carga, CDN
- Un 503 en picos de tráfico es un aviso de falta de capacidad
- Los errores 5xx persistentes hacen que Google rastree más despacio y, con el tiempo, elimine URL indexadas (Google Search Central)
- Los errores 5xx intermitentes pasan fácilmente desapercibidos sin monitorización continua
Cómo monitorizar los códigos de estado HTTP
Nadie puede vigilar los registros del servidor las 24 horas, así que automatízalo: un monitor de uptime solicita tus URL a intervalos fijos y te avisa en cuanto falla una comprobación. Empieza por las páginas que generan ingresos o que más importan a tus usuarios y añade después los endpoints de API y de health check. Nuestra guía de monitorización de sitios web explica cómo elegir qué monitorizar.
Monitoriza los códigos de estado con nanokoi.io
La monitorización de uptime de nanokoi.io comprueba tus URL cada 5 minutos en el plan Free, cada minuto en Starter y cada 30 segundos en Professional, y te avisa por email, Slack o webhook cuando falla una comprobación. También monitoriza certificados SSL y registros DNS, para que detectes las causas de los errores antes que tus usuarios. Consulta los planes e intervalos de comprobación.
Buenas prácticas
- Monitoriza las páginas y endpoints críticos, no solo la página de inicio
- Genera alertas ante cualquier 5xx y ante respuestas 4xx de URL que siempre deberían funcionar
- Envía las alertas a donde trabaja tu equipo, por ejemplo a un canal de Slack dedicado (consulta nuestra guía para configurar un webhook de Slack)
- Vuelve a comprobar las redirecciones después de cada migración o cambio de URL
- Sirve páginas de error útiles con el código de estado correcto, nunca una página de error con 200
Escenarios habituales de códigos de estado
Los códigos de estado rara vez aparecen solos. Estos son patrones que reconocerás en producción, con los códigos que debes buscar y por dónde empezar a solucionarlos.
El checkout falla bajo carga
Los clientes reciben un error al intentar completar una compra.
500, 502, 503
Pedidos perdidos y carritos abandonados
Revisa los registros de la aplicación, las conexiones a la base de datos, el estado de la pasarela de pago y la capacidad del servidor
La app móvil no carga contenido
Los usuarios de la app ven de repente pantallas vacías o mensajes de error.
429, 401
Usuarios frustrados y sesiones fallidas
Revisa los límites de la API, la caducidad de los tokens y la lógica de reintentos del cliente
El tráfico cae tras un rediseño
Las URL antiguas devuelven errores en lugar de redirigir a su nueva ubicación.
404, 301
Pérdida de posiciones en buscadores y backlinks rotos
Redirige cada URL antigua con un 301 o 308, actualiza el sitemap y corrige los enlaces internos
Faltan imágenes y CSS para algunos usuarios
Las páginas se cargan sin estilos ni imágenes en ciertas regiones.
403, 404, 502
Un sitio que parece roto y una mala experiencia de usuario
Revisa la configuración de la CDN, la conexión con el servidor de origen, las reglas de acceso y la caché
Cómo solucionar un error HTTP
Cuando salta una alerta, sigue siempre el mismo orden. Ahorra tiempo y evita que corrijas síntomas en lugar de causas.
- 1
Evalúa el alcance y el impacto
¿Qué URL están afectadas, desde cuándo y para quién? Un solo endpoint y un dominio entero son incidentes muy distintos.
- 2
Reproduce la solicitud
Repite la solicitud con curl o con las herramientas de desarrollo del navegador. Revisa la URL, el método, las cabeceras y el cuerpo en busca de errores o parámetros ausentes.
- 3
Prueba desde otra red
Solicita la misma URL desde otra ubicación o red para descartar problemas locales y compara la respuesta de la CDN con la del servidor de origen.
- 4
Revisa las dependencias
Ante errores 5xx, comprueba bases de datos, servicios de backend, APIs de terceros y recursos del servidor como CPU, memoria y disco.
- 5
Revisa los cambios recientes
La mayoría de incidentes llegan tras un despliegue, un cambio de configuración o un certificado o dominio caducado. Mira primero tu registro de cambios.
- 6
Evita que se repita
Una vez resuelto, añade un monitor para la URL afectada y documenta lo ocurrido para resolver más rápido el siguiente incidente.
Preguntas frecuentes sobre los códigos de estado HTTP
¿Qué diferencia hay entre los códigos de estado 4xx y 5xx?
Los códigos 4xx indican que el servidor cree que el cliente cometió un error, como pedir una página que no existe o enviar credenciales no válidas. Los 5xx indican que la solicitud era válida, pero el servidor no pudo procesarla.
¿Debo usar una redirección 301 o 302?
Usa 301 (o 308) cuando una página se haya movido definitivamente: Google lo considera una señal fuerte para indexar la nueva URL. Usa 302 (o 307) solo para cambios temporales en los que la URL original deba seguir indexada.
¿Qué diferencia hay entre 404 y 410?
404 indica que no se encontró el recurso; 410, que se eliminó a propósito y no volverá. Google trata ambos igual y elimina la URL de su índice.
¿Qué códigos de estado HTTP deberían generar una alerta?
Cualquier respuesta 5xx y las respuestas 4xx de URL que siempre deberían funcionar, como la página de inicio, el login, el checkout y los endpoints de health check. Las redirecciones inesperadas en esas URL también merecen una alerta.
Detecta los errores HTTP antes que tus usuarios
Monitoriza tus URL clave con nanokoi.io y recibe alertas por email, Slack o webhook cuando falle una comprobación. El plan Free incluye hasta 5 URL con comprobaciones cada 5 minutos.
Empieza a monitorizar gratisNo se requiere tarjeta de crédito