Guía completa de errores HTTP: qué son, tipos y cómo solucionarlos

Un error HTTP es un código de tres dígitos que un servidor web devuelve al navegador para indicar el resultado de una petición. Cuando el código está entre 400 y 599, significa que algo ha fallado: los errores4xx indican un problema en la solicitud del cliente, y los errores 5xx indican un fallo en el servidor. Conocer estos códigos permite diagnosticar y solucionar problemas en sitios web, servidores y aplicaciones web de forma rápida y eficaz.

Qué son los errores HTTP

El protocolo HTTP (HyperText Transfer Protocol) es el estándar de comunicación de la web. Cada vez que tu navegador pide una página, envía una solicitud HTTP al servidor. El servidor responde con un código de estado de tres dígitos que informa del resultado de esa solicitud.

El estándar HTTP/1.1, definido en el RFC 9110, clasifica todos los códigos de respuesta en cinco familias según su primer dígito:

Los errores HTTP son únicamente los de las familias 4xx y 5xx. Las familias 1xx, 2xx y 3xx son respuestas informativas, de éxito o de redirección, no errores propiamente dichos. Un usuario que ve un 200 está recibiendo correctamente la página que pedía; un usuario que ve un 404 está recibiendo una respuesta de error porque la URL solicitada no existe.

Cómo funciona la comunicación cliente-servidor

Cuando introduces una URL en el navegador, ocurre lo siguiente en menos de un segundo:

1. Tu navegador (cliente) envía una solicitud HTTP al servidor que aloja el sitio, indicando el método HTTP (GET para leer, POST para enviar datos, PUT para actualizar, DELETE para eliminar), la URL exacta del recurso y una serie de cabeceras con información adicional sobre el cliente, el navegador y el tipo de contenido aceptado.
2. El servidor web recibe la solicitud y la procesa: busca el recurso solicitado, ejecuta el código de la aplicación (PHP, Node.js, Python...) y consulta la base de datos si es necesario para generar la respuesta.
3. El servidor devuelve una respuesta HTTP con un código de estado de tres dígitos, un conjunto de cabeceras de respuesta (tipo de contenido, longitud, caché, cookies...) y, si todo va bien, el contenido solicitado (HTML, JSON, imagen, archivo...).
4. Si el código de estado es un error de la familia 4xx o 5xx, el navegador muestra el mensaje de error correspondiente al usuario, ya sea la página de error del servidor o una página de error personalizada del sitio.

La distinción entre errores 4xx y 5xx es crítica para el diagnóstico: si el código empieza por 4, el problema está en la solicitud del cliente (URL incorrecta, falta de permisos, autenticación incorrecta); si empieza por 5, el problema está en el servidor (código de la aplicación roto, configuración incorrecta, falta de recursos).

Estructura de un error HTTP

Un mensaje de error HTTP tiene tres componentes esenciales que el servidor siempre incluye en su respuesta:

1. El código de estado: el número de tres dígitos (por ejemplo, 404).
2. La frase de razón: una descripción textual corta del código en inglés (por ejemplo, "Not Found").
3. El cuerpo de la respuesta: el contenido que muestra el navegador al usuario. Puede ser la página de error por defecto del servidor web (con un mensaje genérico) o una página de error personalizada del sitio.

Las herramientas de desarrollo del navegador (F12 > pestaña Red) permiten ver todos estos componentes, incluidas las cabeceras HTTP completas, para cualquier solicitud. Es el primer lugar donde mirar cuando aparece un error.

Errores 4xx: tabla completa de errores del cliente

Error 400 Bad Request: qué es y cómo solucionarlo

El error 400 indica que el servidor no pudo entender la solicitud porque está mal formada. A diferencia de los errores que implican permisos o existencia del recurso, el 400 es un problema de sintaxis o estructura de la propia petición HTTP, no de lo que se está pidiendo.

Las causas más frecuentes son:

• URL con caracteres inválidos o mal codificados (por ejemplo, espacios que deberían ser %20, o caracteres como # sin codificar en la parte de la ruta)
• Cabeceras HTTP corruptas o demasiado largas (algunos proxies tienen límites estrictos de tamaño de cabecera)
• Cookies corruptas que se envían automáticamente con cada solicitud al servidor
• Datos de formulario con formato incorrecto o con caracteres no permitidos en el encoding declarado

La solución empieza por limpiar las cookies del navegador para ese dominio y verificar que la URL no contiene caracteres especiales sin codificar correctamente. Si el error viene de una API, verificar que el cuerpo de la solicitud tiene el formato correcto (JSON bien formado, XML válido) y que el Content-Type de la cabecera coincide con el formato del cuerpo.

Error 401 vs 403: la distinción que todos confunden

Esta es una de las confusiones más comunes en el mundo del desarrollo web y tiene implicaciones prácticas importantes porque determina completamente cómo resolver el problema. El estándar HTTP tiene aquí una inconsistencia histórica que viene del RFC 2616 de 1999:

La regla mnemotécnica: 401 = "¿Quién eres?" (falta autenticación). 403 = "Sé quién eres, pero no puedes pasar" (falta autorización). En inglés: authentication (401) vs authorization (403).

En el diseño de APIs REST, esta distinción es especialmente importante: devolver un 403 cuando corresponde un 401 (o viceversa) confunde al cliente sobre cómo resolver el problema. El cliente que recibe un 401 sabe que debe autenticarse; el que recibe un 403 sabe que aunque se autentique, no tendrá acceso a ese recurso.

Error 404 Not Found: impacto en SEO y gestión correcta

El 404 es el error más conocido de la web. Aparece cuando el servidor no encuentra el recurso en la URL indicada, pero el servidor en sí funciona correctamente. La causa puede estar en el cliente (URL mal escrita, enlace roto) o en el servidor (página eliminada, URL cambiada sin redirección).

La gestión incorrecta de los 404 puede tener un impacto significativo en el SEO:

• URLs con backlinks o tráfico orgánico que dan 404: se pierde la autoridad de enlace que esos backlinks transferían y el posicionamiento acumulado durante meses o años. La solución correcta es crear una redirección 301 hacia la página más relevante disponible.
• URLs nuevas sin historial que dan 404: sin impacto en el SEO. Google simplemente no las indexa. No es necesario preocuparse por ellas.
• Redirigir todos los 404 a la página de inicio: es el error más común. Genera "Soft 404s" que Google penaliza porque el contenido servido (la portada) no corresponde a la URL solicitada. Cada redirección 301 debe apuntar a la página más relevante y temáticamente relacionada con la URL que genera el 404.
• La diferencia entre 404 y 410: el código 410 (Gone) indica que el recurso existió pero fue eliminado permanentemente y no volverá. Google procesa el 410 más rápido para la desindexación que el 404 genérico. Si eliminas contenido deliberadamente, usa 410 en lugar de 404 para que Google lo desindexe antes.

Para identificar todos los 404 que afectan a tu sitio, usa Google Search Console (sección Cobertura > Errores) para ver los que detecta Googlebot, y Screaming Frog para rastrear todo tu sitio y encontrar los internos.

Errores 5xx: tabla completa de errores del servidor

Error 500 Internal Server Error: diagnóstico paso a paso

El 500 es el error más genérico de la familia 5xx y por eso el más frustrante: el servidor sabe que algo ha fallado, pero no puede o no quiere especificar qué. El RFC 9110 lo describe como "el servidor encontró una condición inesperada que le impidió cumplir la solicitud".

El diagnóstico siempre empieza por los logs de error del servidor, que contienen el mensaje exacto, el archivo y la línea donde ocurrió el fallo. Sin los logs, estás trabajando a ciegas. Las causas más frecuentes, por orden de probabilidad:

1. Errores en el archivo .htaccess: un error de sintaxis en el .htaccess provoca un 500 inmediato en Apache. Si el error apareció justo después de editar el .htaccess, ese es casi con certeza el culpable. Renómbralo temporalmente a .htaccess_bak y recarga para confirmarlo. Si el error desaparece, revisa el .htaccess línea por línea.
2. Permisos de archivos incorrectos: en servidores Linux, los archivos PHP deben tener permisos 644 (rw-r--r--) y los directorios 755 (rwxr-xr-x). Permisos demasiado permisivos (777) o demasiado restrictivos pueden provocar un 500. Corrígelos con: find /ruta -type f -exec chmod 644 {} \; && find /ruta -type d -exec chmod 755 {} \;
3. Errores de sintaxis en PHP: una coma que falta, un paréntesis sin cerrar, una función llamada incorrectamente o una variable no definida en modo estricto. Muy frecuente después de actualizar plugins, temas o el propio núcleo de WordPress. El debug.log de WordPress muestra el archivo y la línea exactos.
4. Límite de memoria PHP insuficiente: el error "Allowed memory size of XXXXXXX bytes exhausted" en los logs indica que PHP necesita más memoria de la configurada. Aumenta memory_limit en php.ini o añade define('WP_MEMORY_LIMIT', '256M'); en wp-config.php.
5. Timeout de ejecución PHP: si un script supera max_execution_time (por defecto 30 segundos en la mayoría de servidores), PHP lo interrumpe con un 500. Aumenta max_execution_time en php.ini para scripts legítimamente lentos.
6. Problemas con la base de datos: si la aplicación web no puede conectarse a MySQL o hay un error en una consulta SQL, puede devolver un 500 en lugar de un error de base de datos más específico. Verifica que el servicio MySQL está activo y que las credenciales en la configuración son correctas.

Diferencia entre los errores 502, 503 y 504

Estos tres errores son los más confundidos entre sí porque todos indican problemas en la capa de infraestructura del servidor, especialmente en configuraciones con proxy inverso (Nginx delante de Apache, PHP-FPM o Node.js), pero tienen causas y soluciones completamente distintas:

La distinción práctica más importante: el 502 indica que el servidor de destino respondió pero con algo inválido (el servicio existe pero está roto); el 503 indica que el servidor de destino está demasiado ocupado o en mantenimiento; el 504 indica que el servidor de destino no respondió en absoluto dentro del tiempo límite.

Errores de navegador relacionados con HTTP

Además de los errores HTTP estándar, Chrome, Firefox y otros navegadores tienen sus propios códigos internos que aparecen cuando el problema ocurre antes de que el servidor pueda devolver un código HTTP estándar, generalmente en la capa de red o de transporte:

Cómo diagnosticar un error HTTP: proceso sistemático

Cuando aparece un error HTTP que no puedes explicar, sigue este proceso en orden. El 90% de los errores se resuelven en los primeros tres pasos:

Paso 1: Identifica el código exacto

Abre las herramientas de desarrollo del navegador (F12, pestaña Red / Network) y localiza la solicitud fallida. El código de tres dígitos en la columna Estado lo dice todo. Los mensajes de error genéricos que muestran algunos servidores ("Algo salió mal", "Error del sistema", "Oops!") no son suficientes para el diagnóstico: necesitas el código exacto, las cabeceras de respuesta completas y el cuerpo de la respuesta de error que devuelve el servidor.

Paso 2: Determina si el problema es del cliente o del servidor

4xx: el problema está en la solicitud del cliente. Revisar la URL, los permisos, la autenticación y el .htaccess. 5xx: el problema está en el servidor. Empezar siempre y obligatoriamente por los logs del servidor antes de hacer cualquier otra cosa.

Paso 3: Consulta los logs del servidor

Para cualquier error 5xx, los logs son el primer paso absolutamente obligatorio. Contienen el mensaje exacto, el archivo y la línea donde ocurrió el fallo, reduciendo el tiempo de diagnóstico de horas a minutos.

• Apache: /var/log/apache2/error.log
• Nginx: /var/log/nginx/error.log
• PHP-FPM: /var/log/php8.x-fpm.log
• Plesk: Websites y Domains > [tu dominio] > Logs
• WordPress: activar define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); en wp-config.php, luego revisar wp-content/debug.log

Paso 4: Verifica la configuración del servidor

Para errores 5xx: .htaccess (renombra a .htaccess_bak para probar), permisos de archivos con chmod, configuración de PHP en php.ini (memory_limit, max_execution_time) y variables de entorno de la aplicación. Para errores 4xx: reglas de autenticación, listas de acceso IP en el servidor o el WAF, y configuración de CORS si el error viene de una solicitud de origen cruzado.

Paso 5: Reproduce el error de forma aislada

¿El error aparece en todas las páginas o solo en algunas específicas? ¿En todos los navegadores o solo en Chrome? ¿Con todas las IPs o solo con la tuya? ¿Después de limpiar la caché el error persiste? ¿En incógnito el comportamiento es diferente? Aislar las condiciones que reproducen el error reduce drásticamente el espacio de búsqueda de la causa raíz y acelera enormemente el diagnóstico.

Paso 6: Contacta con el soporte de hosting

Si no puedes acceder a los logs del servidor o el error persiste sin una causa aparente después de los pasos anteriores, el soporte técnico de tu proveedor de hosting puede acceder a los logs del servidor a nivel de sistema y revisar la configuración del servidor que no está expuesta en el panel de control. En sys4net, el soporte técnico tiene acceso a todos los logs del servidor y puede diagnosticar el problema de forma directa.

Impacto de los errores HTTP en el SEO

Los errores HTTP no son solo un problema para los usuarios: afectan directamente al posicionamiento en buscadores. La gravedad depende del tipo de error, su duración y el historial de las URLs afectadas:

Usa Google Search Console, sección Cobertura, para monitorizar los errores que detecta Googlebot al rastrear tu sitio. Revísalo al menos semanalmente para detectar problemas antes de que impacten el posicionamiento de forma significativa.

Errores HTTP en WordPress: los más frecuentes y sus soluciones

WordPress tiene particularidades que hacen que ciertos errores HTTP sean más frecuentes que en aplicaciones web estándar, especialmente después de actualizaciones:

• Error 500 en WordPress: casi siempre causado por un plugin incompatible con la versión actual de WordPress o PHP, el .htaccess corrupto después de una actualización, o el límite de memoria PHP insuficiente para la carga de plugins. Activa WP_DEBUG y WP_DEBUG_LOG en wp-config.php para ver la causa exacta en wp-content/debug.log. Desactiva todos los plugins renombrando la carpeta wp-content/plugins a wp-content/plugins_bak para aislar el culpable, y luego actívalos de uno en uno.
• Error 403 en WordPress: frecuentemente causado por un plugin de seguridad (Wordfence, Sucuri, iThemes Security) que detecta actividad sospechosa y bloquea tu IP, o por el .htaccess corrupto. Regenera el .htaccess desde Ajustes, sección de Enlaces permanentes, haciendo clic en Guardar cambios sin modificar nada.
• Error 404 en WordPress: si todas las páginas dan 404 excepto la portada, el problema suele ser el .htaccess o los permalinks. Ve a Ajustes, sección de Enlaces permanentes, y guarda sin cambios para regenerar el .htaccess automáticamente.
• ERR_TOO_MANY_REDIRECTS en WordPress: generado por configuración incorrecta de HTTPS, especialmente cuando WordPress está detrás de Cloudflare en modo SSL Flexible (que envía HTTP al servidor) o de un proxy inverso que no pasa correctamente la cabecera X-Forwarded-Proto a PHP. La solución es añadir la detección de X-Forwarded-Proto en wp-config.php o cambiar Cloudflare de Flexible a Full (Strict).

Errores HTTP en APIs REST

Las APIs REST usan los códigos HTTP de forma más precisa y sistemática que las aplicaciones web tradicionales. Un uso correcto de los códigos de estado es fundamental para que los clientes de la API puedan manejar los errores de forma automática:

Preguntas frecuentes sobre errores HTTP

¿Cuál es la diferencia entre un error 4xx y un error 5xx?

Los errores 4xx son causados por la solicitud del cliente: está mal formada, la URL no existe, o no tienes permiso para acceder al recurso. El servidor funcionaba correctamente, pero la solicitud tenía un problema. Los errores 5xx indican que el servidor recibió una solicitud válida pero no pudo completarla por un fallo interno: código de la aplicación, plugin, configuración del servidor o base de datos. Si ves un 4xx, revisa cómo estás haciendo la solicitud; si ves un 5xx, empieza por los logs de error y el código de la aplicación.

¿Por qué aparece un error HTTP en mi web cuando antes funcionaba?

Los cambios recientes son la causa más frecuente: una actualización de plugin o tema en WordPress, un cambio en el código o en el .htaccess, permisos de archivo modificados, un cambio en la configuración de PHP, o un certificado SSL caducado. Revisa exactamente qué modificaste justo antes de que apareciera el error. Si no hiciste ningún cambio consciente, revisa los logs del servidor en busca de patrones nuevos: actualizaciones automáticas de sistema, cambios en el servidor o certificados SSL que caducaron sin que lo supieras.

¿Un error HTTP afecta al SEO de mi web?

Depende del tipo de error y de su duración. Los errores 5xx persistentes son los más perjudiciales porque impiden que Google indexe el contenido: si Googlebot no puede acceder a tus páginas, no puede indexarlas. Los errores 404 en URLs con backlinks o tráfico orgánico hacen perder la autoridad de enlace acumulada. Un error 503 de corta duración con la cabecera Retry-After no tiene impacto significativo en el posicionamiento. Los errores en URLs nuevas sin historial no tienen impacto en el SEO.

¿Cuál es el error HTTP más difícil de resolver?

El error 500 es el más genérico y por eso el más difícil de diagnosticar sin acceso a los logs del servidor: puede tener docenas de causas distintas en el código, la configuración o los recursos, y el servidor no da ninguna pista específica. El error 502 también es complejo porque implica revisar la comunicación entre múltiples componentes del stack: el proxy inverso, el servidor de aplicación y a veces la base de datos. En ambos casos, los logs del servidor son absolutamente imprescindibles para el diagnóstico eficiente.

¿Cuál es la diferencia entre un error 500 y un error 502?

El error 500 lo genera el propio servidor de aplicación (Apache, Nginx con PHP directamente) cuando falla al procesar la solicitud por un error interno. El error 502 lo genera el servidor proxy o balanceador de carga (normalmente Nginx o Cloudflare) cuando el servidor de aplicación al que reenvía las solicitudes (PHP-FPM, Node.js, Apache en un stack LEMP) le devuelve una respuesta inválida o no responde. El 502 implica una arquitectura con al menos dos servidores en la cadena.

¿Puedo personalizar las páginas de error HTTP de mi web?

Sí. En Apache, añade directivas ErrorDocument en tu .htaccess:

ErrorDocument 404 /pagina-404.html
ErrorDocument 500 /pagina-500.html
ErrorDocument 403 /pagina-403.html

En Nginx se usa la directiva error_page en el bloque server. WordPress usa el archivo 404.php del tema activo para la página de error 404 personalizada. Una buena página 404 retiene al visitante incluyendo un buscador interno, el menú de navegación principal y sugerencias de páginas populares o relacionadas.

¿Cómo monitorizar los errores HTTP de mi web?

Las herramientas más útiles son Google Search Console (sección Cobertura, subsección Errores) para los errores que detecta Googlebot durante el rastreo; los logs del servidor para errores en tiempo real; herramientas de monitorización externa como UptimeRobot o Pingdom para alertas inmediatas cuando el sitio devuelve errores 5xx o no responde; y Screaming Frog para rastreos completos del sitio que identifiquen todos los 404, redirecciones rotas y errores del servidor en tu propio sitio web.