Guía completa de los códigos de error HTTP: causas, soluciones e impacto en el SEO

Los códigos de error HTTP son importantes para webmasters, desarrolladores, especialistas SEO, equipos de hosting y usuarios habituales que quieren entender por qué no carga un sitio web o una página. 

En esta guía aprenderás qué significan errores como 502, 503, 504, 403 y los relacionados con SSL, por qué se producen, cómo solucionarlos y cómo pueden afectar al SEO.

¿Qué son los códigos de error HTTP y cómo funcionan?

Los códigos de error HTTP son respuestas del servidor que explican qué ha ocurrido después de que un navegador, un bot de un motor de búsqueda o una aplicación haya solicitado una página. Una solicitud correcta suele devolver 200 OK. Si algo falla, el servidor devuelve otro código que señala el problema.

Estos códigos indican si una página está disponible, se ha movido, está bloqueada, no existe o se ve afectada por un problema del servidor. Para los propietarios de sitios web y los especialistas SEO, ayudan a detectar problemas que pueden perjudicar el rastreo, la indexación, el posicionamiento y la experiencia de usuario.

Cómo funciona la comunicación cliente-servidor

Cuando un usuario abre un sitio web, el navegador envía una solicitud al servidor. El servidor comprueba la URL, los permisos, los archivos y la lógica de la aplicación, y después devuelve un código de respuesta.

Si la solicitud se completa correctamente, la página carga. Si falla, el navegador puede mostrar 403 Forbidden, 502 Bad Gateway o 504 Gateway Timeout.

En los sitios web HTTPS, el navegador también verifica el certificado SSL o TLS. Un certificado caducado, no válido o que no coincide puede provocar una advertencia de seguridad.

Clases de códigos de estado HTTP

Los códigos de estado HTTP se dividen en cinco grupos principales:

Los códigos 1xx son respuestas informativas. Significan que la solicitud se ha recibido y que el proceso sigue en curso.

Los códigos 2xx indican éxito. El ejemplo más habitual es 200 OK, que significa que la página o el recurso se ha cargado correctamente.

Los códigos 3xx son redirecciones. Indican a los navegadores y a los motores de búsqueda que la URL solicitada se ha movido o que se necesita otra acción.

Los códigos 4xx son errores del lado del cliente. Normalmente significan que la página no existe, que la solicitud es incorrecta o que el acceso está bloqueado. Entre los ejemplos habituales están 403 Forbidden y 404 Not Found.

Los códigos 5xx son errores del lado del servidor. Significan que la solicitud puede ser válida, pero el servidor no puede completarla. Entre los ejemplos habituales están 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable y 504 Gateway Timeout.

En SEO, los errores 4xx y 5xx repetidos pueden bloquear el rastreo, reducir la confianza de los usuarios y debilitar la visibilidad orgánica.

Tabla de referencia rápida: códigos de error clave

Los códigos de estado HTTP son respuestas breves del servidor que explican qué ha ocurrido después de que un navegador, un bot o una aplicación haya enviado una solicitud. El flujo básico es: el cliente envía una solicitud, el servidor la procesa y el servidor devuelve un código de respuesta. Este código indica si la página se ha cargado, si se ha bloqueado el acceso, si el servidor ha fallado o si no se ha podido establecer una conexión segura.

Piensa en ello como un pedido en un restaurante. 403 significa que se niegan a atenderte; 502, 503 o 504 significan que la cocina o el proveedor tienen un problema, y los errores SSL significan que el restaurante no puede demostrar que es seguro entrar.

Estos cinco errores son especialmente importantes porque afectan directamente al acceso, a la disponibilidad del servidor, a las conexiones seguras, a la experiencia de usuario y al rastreo de los motores de búsqueda.

Error 403 Forbidden: qué significa y cómo solucionarlo

Un error 403 Forbidden significa que el servidor ha entendido la solicitud, pero deniega el acceso a la página, al archivo o al directorio. La URL puede ser correcta, el servidor puede estar en línea y el recurso puede existir, pero el visitante, el bot o la aplicación no tiene permiso para abrirlo.

Para los propietarios de sitios web, este error suele aparecer tras migraciones, actualizaciones del CMS, cambios de permisos, nuevas reglas de seguridad o ajustes del cortafuegos (firewall). Con un VPS Rocky Linux bien configurado, los equipos normalmente pueden rastrear el problema a través de la propiedad de los archivos, las reglas de Apache o Nginx, la configuración de SELinux y los registros.

Un VPS AlmaLinux bien mantenido también facilita la recuperación tras cambios en la raíz de documentos, actualizaciones del gestor de PHP o el refuerzo de la seguridad. En la mayoría de los casos, la página no está rota; lo que falla son las reglas de acceso que la rodean.

Causas habituales de los errores 403

Una causa habitual son los permisos incorrectos de archivos o directorios. Los servidores web deben poder leer los archivos del sitio y entrar en sus directorios. En muchas configuraciones de Linux, los directorios usan permisos 755 y los archivos, permisos 644. Si los permisos son demasiado restrictivos, el servidor puede bloquear el acceso.

Otro motivo frecuente es un archivo .htaccess mal configurado. Una regla puede bloquear a todos los visitantes, un rango concreto de IP, una carpeta protegida o el listado de directorios.

Ejemplo de una regla restrictiva en .htaccess:

Deny from all

En configuraciones antiguas de Apache, esta regla deniega el acceso a todo el mundo. En versiones más recientes de Apache, una restricción similar puede usar:

Require all denied

Un error 403 también puede deberse a reglas del WAF o del cortafuegos. Las herramientas de seguridad pueden bloquear solicitudes sospechosas, determinados países, direcciones IP concretas, bots, user agents o intentos de inicio de sesión repetidos. Esto protege el sitio, pero los falsos positivos pueden bloquear a usuarios reales o a los rastreadores de los motores de búsqueda.

Otra posible causa es la falta de un archivo de índice. Si un directorio no tiene index.html, index.php ni ningún archivo de índice configurado, y el listado de directorios está desactivado, el servidor puede devolver 403 Forbidden.

Los registros de Apache suelen revelar el motivo:

client denied by server configuration

Esto suele apuntar a las reglas del servidor, la configuración de directorios, .htaccess o los ajustes de control de acceso.

Cómo solucionar el error 403 Forbidden paso a paso

 1. Comprueba primero la URL

Asegúrate de que la URL solicitada es correcta. Una URL equivocada a veces puede apuntar a un directorio protegido en lugar de a una página pública.

 2. Comprueba los permisos de archivos y directorios

En muchos servidores web Linux, los directorios normalmente deben ser legibles y ejecutables por el servidor web, mientras que los archivos deben ser legibles.

Ejemplo de comando para un directorio web:

chmod 755 /var/www/

Para los archivos y directorios dentro del sitio web, se suelen usar permisos como 644 para los archivos y 755 para los directorios:

find /var/www/ -type f -exec chmod 644 {} \;

find /var/www/ -type d -exec chmod 755 {} \;

ATENCIÓN: no uses chmod 777 como solución rápida. Concede permisos de lectura, escritura y ejecución a todo el mundo, lo que puede suponer un riesgo de seguridad grave. Un directorio web público con permisos de escritura puede permitir que atacantes, malware o scripts vulnerables modifiquen archivos.

 3. Comprueba la propiedad de los archivos

Aunque los permisos parezcan correctos, la propiedad puede ser incorrecta tras una migración o una subida manual. El usuario del servidor web debe poder leer los archivos. Según tu stack, este usuario puede ser www-data, apache, nginx u otro usuario del sistema.

 4. Revisa las reglas de .htaccess

Cambia temporalmente el nombre de .htaccess para comprobar si es el causante del problema. Si la página empieza a funcionar, revisa las reglas de acceso, las reglas de reescritura, las restricciones por IP y directivas antiguas como Deny from all.

 5. Comprueba el cortafuegos, el WAF y los plugins de seguridad

Si el error solo aparece para algunos usuarios, países, direcciones IP o bots, revisa los registros del cortafuegos y la configuración del WAF. Los plugins de seguridad de WordPress y de CMS similares también pueden provocar respuestas 403.

 6. Comprueba el archivo de índice

Asegúrate de que el directorio contiene un archivo de índice válido, como index.php o index.html. Si falta el archivo de índice y el listado de directorios está desactivado, el servidor puede devolver 403.

 7. Lee los registros del servidor

Los registros son la forma más rápida de encontrar la causa real. Revisa los registros de Apache, Nginx, PHP, el WAF y el panel de control del hosting en busca de mensajes relacionados con accesos denegados, problemas de permisos o direcciones IP bloqueadas.

403 vs 401: ¿cuál es la diferencia?

Un error 401 Unauthorized significa que el servidor no puede confirmar quién es el usuario. La autenticación falta, no es válida o ha caducado. Esto puede ocurrir cuando alguien no ha iniciado sesión, usa una contraseña incorrecta o envía un token de API no válido.

Un error 403 Forbidden significa que el servidor entiende la solicitud, pero no se permite el acceso. Es posible que el usuario ya esté autenticado, pero aun así no tenga el rol, el nivel de acceso, el permiso por IP o el permiso del servidor necesarios.

La diferencia clave es sencilla: 401 tiene que ver con la autenticación y 403, con la autorización. La autenticación pregunta: “¿Quién eres?”. La autorización pregunta: “¿Tienes permiso para acceder a esto?”.

Error 502 Bad Gateway: causas y soluciones

Un error 502 Bad Gateway significa que una pasarela o un servidor proxy ha recibido una respuesta no válida de un servidor upstream. En la práctica, esto suele ocurrir cuando un navegador llega a Nginx, Apache, un balanceador de carga, una CDN o un proxy inverso, pero el siguiente servicio de la cadena no responde correctamente.

La ruta de la solicitud suele tener este aspecto:

client → Nginx → PHP-FPM / upstream application server

Si Nginx puede aceptar la solicitud, pero PHP-FPM, Node.js, Python, una API de backend u otro servicio upstream no devuelve una respuesta válida, el usuario puede ver 502 Bad Gateway. Por eso los errores 502 son habituales en sitios web dinámicos, proyectos de ecommerce con mucho tráfico, plataformas basadas en API y sitios que funcionan en entornos de hosting VPS mal configurados.

¿Qué causa un error 502?

Un error 502 Bad Gateway suele significar que la pasarela ha llegado al servicio upstream, pero ha recibido una respuesta defectuosa o no válida. Entre las causas habituales están un pool de PHP-FPM caído, un proceso de Node.js o Python detenido, una aplicación de backend sobrecargada, registros DNS incorrectos o un cortafuegos que bloquea la comunicación entre Nginx y el servidor upstream.

La configuración de la CDN también puede provocar errores 502 cuando la CDN apunta a una IP de origen incorrecta o no puede conectarse al servidor. En los sitios web basados en PHP, PHP-FPM suele ser el punto débil, sobre todo cuando los límites de memoria, los límites de workers o las rutas de socket están mal configurados.

Un mensaje típico en el registro de Nginx es:

upstream prematurely closed connection while reading response header

En proyectos con mucho tráfico, la monitorización periódica de los servicios upstream, el DNS y la configuración del proxy mantiene estable toda la cadena de solicitudes.

Cómo solucionar el error 502 Bad Gateway paso a paso

Si ves un error 502 Bad Gateway, revisa toda la cadena de la solicitud en lugar de reiniciarlo todo a ciegas. El problema suele estar entre la pasarela, como Nginx, y el servicio upstream, como PHP-FPM, Node.js u otro backend.

•  Recarga la página y prueba desde otra red

Recarga la página, prueba con otro navegador y haz la prueba desde una red diferente. Si el error solo aparece en una ubicación, revisa la caché de la CDN, el DNS o el enrutamiento local.

•  Comprueba el servicio upstream

Asegúrate de que PHP-FPM, Nginx o tu proceso de backend están en ejecución.

systemctl status php-fpm

systemctl status nginx

En algunos servidores, el servicio PHP-FPM puede incluir la versión, como php8.2-fpm.

•  Reinicia los servicios afectados

Si el servicio se ha caído, reinícialo y vigila si el error vuelve a aparecer.

systemctl restart php-fpm

systemctl restart nginx

•  Revisa los registros

Revisa los registros de Nginx, PHP-FPM y la aplicación en busca de errores upstream, mensajes de conexión rechazada, problemas de memoria o tiempos de espera agotados.

/var/log/nginx/error.log

/var/log/php-fpm/error.log

• Verifica la configuración upstream

Comprueba si Nginx apunta al socket, puerto o dirección upstream correctos. Una ruta de socket de PHP-FPM o un puerto de backend incorrectos pueden provocar inmediatamente un error 502.

• Comprueba las reglas del cortafuegos

Asegúrate de que la pasarela puede conectarse al servicio upstream. Revisa las reglas del cortafuegos local, la configuración del cortafuegos del hosting, los grupos de seguridad y las reglas de la red interna.

• Revisa la configuración de DNS y CDN

Si usas una CDN, confirma que apunta a la IP de origen correcta. Comprueba también los registros DNS de dominios, subdominios, API y nombres de host upstream.

• Comprueba los recursos del servidor

Un uso elevado de la CPU, poca RAM, el disco lleno o demasiados workers de PHP-FPM pueden volver inestable el upstream.

502 vs 504: diferencias clave

Un error 502 Bad Gateway significa que la pasarela ha recibido una respuesta no válida o defectuosa del servidor upstream. Es posible que el servicio upstream se haya caído, haya cerrado la conexión demasiado pronto, haya devuelto cabeceras mal formadas o haya fallado antes de enviar una respuesta utilizable.

Un error 504 Gateway Timeout significa que la pasarela no ha recibido una respuesta a tiempo. Es posible que el servidor upstream siga funcionando, pero sea demasiado lento, esté sobrecargado, se haya atascado en una consulta a la base de datos o esté esperando a una API externa.

La diferencia es sencilla: 502 significa que la pasarela ha recibido una respuesta defectuosa, mientras que 504 significa que ha esperado demasiado y no ha recibido respuesta a tiempo. Ambos implican comunicación entre servidores, pero apuntan a problemas distintos.

Error 503 Service Unavailable: por qué se produce y qué hacer

Un error 503 Service Unavailable significa que el servidor no puede atender la solicitud temporalmente. El sitio web no tiene por qué estar roto de forma permanente. Puede que el servidor esté sobrecargado, en mantenimiento, con pocos recursos o cerrado intencionadamente por trabajos programados.

En SEO, 503 suele ser el código de estado correcto durante una caída temporal. Indica a los navegadores y a los motores de búsqueda que la página volverá más tarde, en lugar de tratarla como eliminada o no disponible de forma permanente.

Causas habituales de los errores 503

Un error 503 suele aparecer cuando el servidor no puede procesar solicitudes temporalmente debido a picos de tráfico, un uso elevado de la CPU, poca RAM, sobrecarga de la base de datos, límites del hosting o demasiados workers de PHP activos.

El mantenimiento programado también puede provocar un 503. Si un sitio web se está actualizando, migrando o reparando, este estado es mejor que mostrar páginas rotas. Una respuesta de mantenimiento correcta puede incluir una cabecera Retry-After, que indica a los rastreadores y a los clientes cuándo volver a intentarlo.

Este error también puede producirse cuando un plan de hosting se queda pequeño para el proyecto. Si aparecen errores 503 durante campañas, picos en el proceso de pago o actividad de bots, trasladar un ecommerce en crecimiento a una solución VPS USA bien configurada, con suficiente CPU, RAM y capacidad de base de datos, puede mejorar la estabilidad.

Cómo solucionar el error 503 Service Unavailable paso a paso

 1. Comprueba si la caída es intencionada

Empieza por la pregunta más sencilla: ¿está el sitio en modo mantenimiento? Revisa la configuración del panel de control del hosting, las herramientas de despliegue, los plugins de mantenimiento del CMS y la configuración del servidor.

 2. Comprueba los recursos del servidor

Fíjate en la CPU, la RAM, el espacio en disco, los procesos activos y la carga de la base de datos. Si el servidor está sobrecargado constantemente, reiniciar los servicios puede ocultar el problema solo durante unos minutos.

 3. Revisa los registros del servidor web y de la aplicación

Revisa los registros de Nginx, Apache, PHP, la base de datos y el CMS. Busca errores de memoria, límites de workers, conexiones fallidas a la base de datos, errores de plugins o solicitudes repetidas de bots.

 4. Reinicia los servicios que hayan fallado

Si un servicio se ha detenido, reinícialo y vigila el resultado.

systemctl restart nginx

systemctl restart apache2

systemctl restart php-fpm

systemctl restart mysql

Los nombres de los servicios pueden variar según el sistema operativo y el stack.

 5. Desactiva los plugins de WordPress como paso de diagnóstico

En WordPress, un plugin defectuoso puede provocar errores 503 tras una actualización o un conflicto. Cambia temporalmente el nombre de la carpeta de plugins y comprueba si el sitio carga.

Ejemplo:

mv wp-content/plugins wp-content/plugins-disabled

Si el sitio vuelve a funcionar, restaura el nombre de la carpeta y desactiva los plugins uno a uno para encontrar la causa.

 6. Usa una respuesta de mantenimiento adecuada

Si la caída está programada, muestra una página de mantenimiento con el estado 503 y una cabecera Retry-After. Esto es mejor para el SEO que devolver 200 OK con un mensaje de mantenimiento.

Ejemplo de configuración de Nginx:

location / {

add_header Retry-After 3600 always;

return 503;

}

error_page 503 /maintenance.html;

location = /maintenance.html {

root /var/www/html;

}

Esto indica a los clientes que vuelvan a intentarlo pasados 3600 segundos.

 7. Amplía los recursos u optimiza el stack

Si los errores 503 se producen con un tráfico normal, aumenta los recursos del servidor, optimiza las consultas a la base de datos, añade caché, reduce los plugins pesados, limita los bots abusivos o traslada los servicios de alta carga a una infraestructura separada.

503 vs 500: entender la diferencia

Un error 503 Service Unavailable significa que el servidor no puede atender la solicitud temporalmente. Puede que el servidor esté sobrecargado, en modo mantenimiento o limitado por los recursos disponibles.

Un error 500 Internal Server Error significa que el servidor ha sufrido un fallo interno inesperado al procesar la solicitud. Normalmente se debe a fallos de la aplicación, configuración defectuosa, errores en el código, permisos o scripts fallidos.

La diferencia práctica es importante: 503 dice “inténtalo más tarde”, mientras que 500 dice “algo ha fallado dentro del servidor o de la aplicación”. Para el mantenimiento programado y la sobrecarga temporal, 503 es la respuesta más limpia y más favorable para el SEO.

Error 504 Gateway Timeout: diagnóstico y solución

Un error 504 Gateway Timeout significa que una pasarela o un servidor proxy no ha recibido una respuesta del servidor upstream dentro del tiempo permitido. La solicitud ha llegado a la cadena de servidores, pero una parte de esa cadena ha tardado demasiado en responder.

Un flujo típico tiene este aspecto:

client → Nginx or proxy → PHP, database, API, or application server

Este error suele aparecer en sitios web dinámicos cuyas páginas dependen de consultas a la base de datos, API externas, pasarelas de pago, filtros de búsqueda, informes o lógica de backend pesada. Un VPS de alta carga bien configurado ayuda a estos proyectos a gestionar flujos de solicitudes más pesados con mayor fiabilidad, sobre todo cuando se combina con una configuración adecuada de los tiempos de espera, caché y optimización del backend.

¿Qué provoca un error 504?

El desencadenante más habitual es un servicio upstream lento. Puede que PHP esté procesando un script pesado, que la base de datos se haya atascado en una consulta SQL compleja o que la aplicación esté esperando a una API externa que responde demasiado despacio.

La configuración del tiempo de espera del proxy también puede causar el problema. Si Nginx espera solo 60 segundos, pero el backend necesita 90 segundos para completar la tarea, Nginx puede devolver 504 Gateway Timeout aunque el backend siga trabajando.

Las bases de datos son otra fuente frecuente de errores 504. Las consultas sin índices, los joins grandes, los servidores MySQL o PostgreSQL sobrecargados, las tablas bloqueadas y las operaciones de búsqueda lentas pueden retrasar la respuesta hasta que la pasarela se rinde.

Un mensaje habitual en el registro de Nginx tiene este aspecto:

upstream timed out (110: Connection timed out) while reading response header from upstream

Significa que Nginx ha esperado al servicio upstream, pero no ha recibido una cabecera de respuesta antes de que expirara el límite de tiempo.

Cómo solucionar el error 504 Gateway Timeout paso a paso

¿No sabes qué hacer cuando una página devuelve una y otra vez un error 504 Gateway Timeout? Empieza por la ruta de la solicitud y después revisa paso a paso el servidor, los registros, la configuración de los tiempos de espera y el rendimiento del backend.

 1. Comprueba si el error es temporal

Recarga la página, prueba desde otra red y comprueba si el problema afecta a una URL o a todo el sitio web. Si falla una sola página, suele deberse a un script, una consulta o una llamada a una API lentos.

 2. Comprueba los recursos del servidor

Revisa la CPU, la RAM, el uso del disco, la carga media y la actividad de la base de datos. Si el servidor está sobrecargado, aumentar los tiempos de espera no resolverá la causa de fondo.

 3. Examina los registros

Revisa los registros de Nginx, Apache, PHP, la base de datos y la aplicación en busca de mensajes de tiempo de espera agotado, consultas lentas, errores de memoria o solicitudes externas fallidas.

 4. Aumenta con cuidado los tiempos de espera de Nginx

proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_send_timeout 300;

 5. Comprueba los límites de PHP

max_execution_time = 300

Revisa también los ajustes de PHP-FPM, como request_terminate_timeout.

 6. Optimiza el backend

Corrige las consultas SQL lentas, añade índices, almacena en caché las operaciones pesadas y traslada a tareas en segundo plano las importaciones, los informes, las tareas de sincronización y las llamadas lentas a API.

Errores de certificado SSL/TLS: guía completa de solución de problemas

Los errores de certificado SSL y TLS aparecen cuando un navegador no puede establecer una conexión segura y de confianza con un sitio web. Esto puede ocurrir antes de que cargue la página, durante el handshake TLS o cuando una página HTTPS intenta cargar recursos HTTP no seguros.

Códigos de error SSL más habituales y qué significan

La siguiente tabla explica los errores SSL y TLS que los usuarios ven con más frecuencia en los navegadores.

Estos errores suelen deberse a certificados caducados, una instalación incorrecta, certificados intermedios ausentes, nombres de dominio erróneos, versiones de TLS no compatibles o una configuración SSL incorrecta de la CDN.

Cómo solucionar los errores de certificado SSL paso a paso

 1. Comprueba el estado del certificado

Verifica el dominio, la fecha de caducidad, el emisor y la cadena de certificados. Puedes probar el certificado activo con:

openssl s_client -connect domain.com:443

 2.  Renueva o reinstala el certificado

Si el certificado ha caducado o está mal instalado, renuévalo. En muchos servidores Linux, Let’s Encrypt es la opción más sencilla:

certbot --nginx -d domain.com -d www.domain.com

 3. Comprueba la cobertura del dominio

Asegúrate de que el certificado cubre exactamente el nombre de host que se abre, incluidos www, los subdominios y los dominios de API.

 4. Corrige el contenido mixto

Sustituye todos los recursos internos http:// por https://. Esto incluye imágenes, scripts, archivos CSS, fuentes, contenidos incrustados y URL canónicas.

 5.  Revisa la configuración del servidor

Comprueba la configuración SSL de Nginx o Apache, los certificados intermedios, las versiones de TLS compatibles y las redirecciones de HTTP a HTTPS.

Errores SSL con CDN: Cloudflare, AWS CloudFront

Los errores SSL de la CDN suelen producirse cuando la CDN usa HTTPS para los visitantes, pero no puede conectarse de forma segura al servidor de origen. En Cloudflare, usa el modo Full Strict con un certificado de origen válido. En AWS CloudFront, configura el certificado en AWS Certificate Manager y haz que coincida con los alias de dominio correctos.

Cómo afectan los errores HTTP al SEO: presupuesto de rastreo, indexación y posicionamiento

Los motores de búsqueda solo pueden posicionar las páginas a las que pueden llegar, que pueden rastrear y que pueden entender. Cuando URL importantes devuelven errores HTTP, el rastreo pierde eficiencia, la indexación se vuelve inestable y los usuarios pueden acabar en páginas rotas o no disponibles. Una configuración de servidor fiable, unos códigos de respuesta correctos y un hosting VPS NVMe rápido ayudan a mantener accesibles los sitios web grandes durante los picos de tráfico, las actualizaciones del catálogo y los rastreos de los motores de búsqueda.

Errores 4xx y SEO

Los errores 4xx suelen significar que una página no existe, está bloqueada o no está disponible por cuestiones de permisos. Un 404 no es perjudicial cuando una página se ha eliminado intencionadamente, pero se convierte en un problema cuando páginas de producto, páginas de servicios o artículos valiosos devuelven este código por error.

Un error 403 Forbidden es más arriesgado porque puede impedir que los motores de búsqueda accedan a contenido público. Si los rastreadores no pueden acceder repetidamente a una URL, la página puede perder visibilidad o salir del índice.

Errores 5xx y SEO

Los errores 5xx significan que el servidor no ha podido procesar una solicitud válida. Una caída breve suele ser asumible, pero los errores 500, 502, 503 o 504 frecuentes pueden reducir el rastreo y retrasar la indexación.

Un 503 programado con Retry-After es aceptable. Los errores 503 repetidos con un tráfico normal indican inestabilidad del servidor.

Cadenas de redirecciones y su impacto

Las cadenas de redirecciones obligan a los rastreadores y a los usuarios a pasar por varias URL antes de que cargue la página final. Esto ralentiza el rastreo, empeora la experiencia de usuario y puede reducir la eficacia de los enlaces internos.

Haz un seguimiento de estos problemas en Google Search Console mediante los informes de indexación, la Inspección de URLs, los ejemplos de errores del servidor, las páginas bloqueadas y las advertencias de redirección. Empieza por las URL que aportan tráfico, ingresos, backlinks o leads.

Herramientas para diagnosticar errores HTTP

Los errores HTTP son más fáciles de solucionar cuando puedes ver dónde falla la solicitud: en el navegador, en el servidor, en la CDN o dentro de la aplicación. Usa varias herramientas a la vez en lugar de basarte solo en la página de error visible.

DevTools del navegador: pestaña Network

Chrome DevTools te ayuda a inspeccionar las solicitudes en tiempo real. Abre la pestaña Network, recarga la página y comprueba el código de estado, la URL de la solicitud, las cabeceras de respuesta, las redirecciones y los recursos que fallan. Es útil para detectar problemas de 403, 404, 502, contenido mixto y cadenas de redirecciones.

Uso de curl y de la línea de comandos

curl is a fast way to check server responses without a browser:

curl -I https://example.com

Muestra el código de estado HTTP, las redirecciones, las cabeceras de caché y, a veces, detalles de la CDN o del servidor. Para comprobaciones SEO más amplias, usa Google Search Console, Screaming Frog o Ahrefs Site Audit. Con un VPS con cPanel, el diagnóstico es más sencillo porque las comprobaciones por línea de comandos pueden combinarse con los registros del panel, las herramientas SSL, las redirecciones y la configuración de dominios.

Análisis de registros del servidor: Nginx, Apache

Los registros del servidor muestran lo que ha ocurrido realmente detrás del error. Revisa los registros de errores de Nginx o Apache en busca de fallos upstream, accesos denegados y tiempos de espera agotados.

upstream timed out while reading response header from upstream

Filtros útiles:

grep "502" /var/log/nginx/error.log

grep "504" /var/log/nginx/error.log

grep "client denied" /var/log/apache2/error.log

Usa las herramientas del navegador para confirmar lo que ve el usuario, las comprobaciones por línea de comandos para verificar la respuesta bruta del servidor y los registros del servidor para encontrar el motivo técnico exacto del error.

Solución de problemas: árbol de decisión rápido

Usa este árbol de decisión rápido cuando necesites una primera acción sin perder tiempo. Si el error es 4xx, revisa el acceso, los permisos y las URL bloqueadas. Si es 5xx, revisa la carga del servidor, los servicios upstream, el DNS, el cortafuegos y la configuración de la CDN.

Te recomendamos empezar por las comprobaciones más seguras y pasar después a los registros del servidor, las reglas del cortafuegos, la configuración de la CDN y la optimización del backend si el error sigue apareciendo.

Preguntas frecuentes

¿Cuál es la diferencia entre un 502 Bad Gateway y un 504 Gateway Timeout?

Un 502 significa que la pasarela ha recibido una respuesta no válida del servidor upstream. Un 504 significa que el servidor upstream no ha respondido a tiempo.

¿Puede un error 403 Forbidden deberse a un problema con el certificado SSL?

Normalmente no. Un 403 es un problema de acceso o de permisos. Los problemas de SSL suelen aparecer como advertencias de certificado o errores de conexión TLS antes de que cargue la página.

¿Cómo afectan los errores HTTP al posicionamiento de mi sitio web en Google?

Los errores 4xx y 5xx frecuentes pueden bloquear el rastreo, retrasar la indexación, eliminar páginas de los resultados de búsqueda y perjudicar la experiencia de usuario.

¿Qué debo hacer si veo un error 503 en mi sitio de WordPress?

Comprueba el modo mantenimiento, desactiva los plugins actualizados recientemente, revisa la carga del servidor y examina los registros de PHP o del servidor web.

¿Por qué sigo recibiendo errores de certificado SSL aunque mi certificado es válido?

Entre las causas habituales están los certificados intermedios ausentes, una cobertura de dominio incorrecta, problemas con el modo SSL de la CDN, el contenido mixto o datos del navegador y del DNS en caché.

¿Un 500 Internal Server Error es lo mismo que un 502 Bad Gateway?

No. Un 500 significa que el servidor ha fallado internamente. Un 502 significa que una pasarela ha recibido una respuesta defectuosa de otro servidor.

¿Cómo puedo monitorizar mi sitio web automáticamente para detectar errores HTTP?

Usa la monitorización de disponibilidad, Google Search Console, alertas basadas en los registros del servidor, Screaming Frog, Ahrefs Site Audit o comprobaciones personalizadas con curl y cron.