Errores en HTTP

HTTP es el protocolo de transferencia de hipertexto, es el protocolo de aplicación definido como estándar que permite que la web funcione.
Siempre que hay una petición HTTP por parte del cliente (Navegador web) el servidor devuelve un código de estado: un número de tres cifras cuya primera cifra indica la clase de respuesta.

Los códigos de estado en HTTP se clasifican en varios tipos:

1xx: Respuestas informativas
2xx: Peticiones correctas
3xx: Redirecciones
4xx: Errores del cliente
5xx: Errores del servidor

Por ejemplo, si todo funciona habitualmente, el servidor nos devolverá un código HTTP 200 OK y nos devolverá la web.

En este artículo nos centraremos en ver los 4xx y los 5xx, que son los errores, y dentro de estos los más típicos ya que existen muchos definidos en el estándar y fuera de él que no son nada habituales. La referencia actual de los códigos de estado HTTP es el RFC 9110 (junio de 2022), que sustituyó al RFC 7231 y a otros anteriores. La lista oficial de códigos la mantiene la IANA.

HTTP 4xx: Errores del cliente

Error 400 Bad Request

Este error nos lo devuelve el servidor web cuando hay un error en nuestra petición, y el servidor no puede procesar la solicitud. Las causas pueden ser diversas, tales como:
– Caracteres incorrectos en la url
– Cookies con errores (borrarlas)
– Peticiones o cabeceras demasiado grandes. Hay códigos más concretos para estos casos: 413 Content Too Large si es el cuerpo, 414 URI Too Long si es la URL y 431 Request Header Fields Too Large si son las cabeceras

Error 401 Unauthorized

Este error nos lo devuelve el servidor cuando nos informa de que la petición http no ha sido ejecutada porque faltan credenciales de autenticación válidas.

El servidor está obligado a devolver una cabecera WWW-Authenticate con la información para autenticarse (por ejemplo, el esquema Basic o Bearer).

Si el servidor web es IIS (Microsoft), podemos ver distintos subcódigos del 401. No forman parte del estándar HTTP, son propios de IIS:
401.1: Error de inicio de sesión
401.2: Error de inicio de sesión por configuración del servidor
401.3: Fallo por ACL
401.4: Autorización denegada por un filtro
401.5: Autorización denegada por una aplicación ISAPI/CGI

Error 403 Forbidden

Es similar al 401 con la diferencia de que el servidor ha entendido la petición pero se niega a atenderla. Si enviamos credenciales, el servidor las considera insuficientes: repetir la petición con las mismas no cambia nada. El servidor nos informa de que no tenemos permisos y que está prohibido acceder al recurso solicitado. Un servidor que no quiere revelar que el recurso existe puede responder con un 404 en lugar de un 403.

Error 404 Not Found

Es el error más común en http. Lo hemos visto miles de veces navegando. El error 404 significa que el servidor no ha podido encontrar el recurso solicitado.

Seguramente el contenido ha sido borrado, o el enlace es incorrecto o es defectuoso.

Según Google, los errores 404 no penalizan al resto del sitio: simplemente esa URL deja de estar indexada. Aun así, conviene revisarlos en Search Console, sobre todo si se trata de páginas que deberían existir o que reciben enlaces, y redirigirlas cuando tenga sentido.

Errores de Servidor 5xx: 500 y 502

Error 500: Internal Server Error

Generalmente ocurre porque hay un fallo en programación o en la aplicación web.
No es fácil dar con la solución sin tener conocimientos, ya que pueden afectar muchos factores. Lo que sí conviene es recordar qué hemos tocado, o restaurar un backup en caso de que lo tengamos hecho.

Error 500 en chrome

Este error también nos puede aparecer de diferentes formas:

500 Internal Server Error
HTTP 500 – Internal Server Error
Temporary Error (500)
Internal Server Error
HTTP 500 Internal Error
500 Error
HTTP Error 500
500. That’s an error

Para saber algo más de información acerca del tipo de error 500, conviene revisar el log de errores del servidor web.

Habitualmente en /var/log/apache2/error.log (Debian y Ubuntu) o /var/log/httpd/error_log (Red Hat y derivadas) si usamos Apache, y en /var/log/nginx/error.log si usamos Nginx, pero depende en gran medida de la distribución linux y de la configuración del servidor web.

Si nuestro hosting utiliza cPanel, hay una sección específica para los errores en http que podremos revisar.

Error de Permisos: Muchas veces la causa del error 500 son unos permisos de ejecución mal configurados.

Demasiado tiempo de espera: Si el script php depende de recursos y el tiempo de ejecución lo limita, puede producirse un error.

Fallo en el .htaccess: Si has tocado algo en este archivo recientemente, revísalo ya que puede ser la causa.

Fallo por el límite de memoria: Puede ser que en el archivo php.ini o en wp-config.php en el caso de WordPress estemos limitando la memoria, deberemos aumentarla y probar.

Error 502: Bad Gateway

Aparece cuando un servidor que actúa como pasarela o proxy (CDN, balanceador, nginx) recibe una respuesta no válida del servidor de origen.

Pueden ser diversas las causas:
– Firewall bloqueando la solicitud: O se ha activado alguna regla por error.
– Fallo en el servidor Proxy: como no puede conectarse al servidor web, nos devuelve error.
– Fallo en un cluster, o CDN. (sobrecarga).
– Estamos recibiendo un ataque DDoS, aunque en ese caso lo más habitual es ver un 503 o un 504.

Tabla de códigos de estado HTTP más habituales

Los nombres de 413 y 422 cambiaron con el RFC 9110. El 418 “I’m a teapot” nació como broma del 1 de abril (RFC 2324) y la IANA lo tiene reservado como “(Unused)”, no es un código real. El código más reciente del registro es el 104 Upload Resumption Supported, para reanudar subidas de archivos; está registrado de forma temporal mientras el IETF termina el borrador de subidas reanudables y todavía no forma parte de ningún RFC.

Otros códigos que conviene conocer

• 410 Gone: el recurso se ha eliminado de forma permanente. Es más explícito que un 404 cuando sabemos que el contenido no va a volver.
• 429 Too Many Requests: el cliente ha hecho demasiadas peticiones en poco tiempo y el servidor aplica un límite. Puede incluir la cabecera Retry-After. Está definido en el RFC 6585.
• 503 Service Unavailable: el servidor no puede atender la petición de forma temporal, por mantenimiento o sobrecarga.
• 504 Gateway Timeout: el proxy o pasarela no ha recibido respuesta a tiempo del servidor de origen.
• 499 Client Closed Request: no es estándar. Lo registra Nginx en sus logs cuando el cliente cierra la conexión antes de recibir la respuesta.
• 520 a 526: tampoco son estándar. Los devuelve Cloudflare cuando falla la conexión con el servidor de origen (por ejemplo, 521 si el origen rechaza la conexión, 522 si se agota el tiempo de conexión y 525 o 526 si falla el certificado SSL del origen).
• Soft 404: no es un código de estado, sino el caso en que una página que no existe o está vacía devuelve un 200 OK. Search Console lo señala como error porque el servidor debería devolver un 404 o un 410.

Preguntas frecuentes

¿Qué diferencia hay entre un error 401 y un 403?

El 401 indica que falta autenticación o que no es válida: con las credenciales correctas, la petición funcionaría. El 403 indica que el servidor sabe quién eres (o no le importa) y aun así no te deja acceder.

¿Es mejor devolver un 404 o un 410 para una página eliminada?

El 410 indica de forma explícita que el contenido no va a volver. Para Google, según su documentación, los dos se tratan igual: la URL sale del índice y se rastrea cada vez menos.

¿Afectan los errores 5xx al SEO?

Sí, si se mantienen en el tiempo. Según Google, los 5xx y el 429 hacen que Googlebot reduzca temporalmente el ritmo de rastreo, y las URL que siguen devolviendo error de servidor acaban saliendo del índice. Para una parada por mantenimiento lo correcto es devolver un 503, si es posible con la cabecera Retry-After.

¿Cómo veo el código de estado de una página?

En el navegador, con las herramientas de desarrollo (F12), pestaña Red: cada petición muestra su código en la columna Estado. Desde la terminal, con curl -I https://ejemplo.com.

Datos del RFC 9110, el registro de códigos de estado HTTP de la IANA (última actualización 15 de septiembre de 2025), el RFC 6585 y la documentación de Google Search Central, revisados el 1 de noviembre de 2026.