ClasesSEO
ES EN
Optimización de motores de búsqueda SEO

Errores 5xx y SEO: qué hacer cuando tu servidor falla (500, 502, 503 y 504)

8 min de lectura Read in English
Errores 5xx y SEO: qué hacer cuando tu servidor falla (500, 502, 503 y 504)
Tabla de contenidos

Search Console marca "Error del servidor (5xx)" y tú entras a la página y carga perfecta. Los errores 5xx no son solo una página caída: Google vio la caída, bajó el rastreo de todo el dominio y, si se repite, termina sacándola del índice.

Qué significan los errores 5xx para Google (y qué no)

Un 5xx es la respuesta con la que el servidor admite que el fallo es suyo: no puede completar la petición. No es un 404, donde simplemente dice que eso no existe.

La consecuencia está en la documentación de Google sobre códigos de estado y rastreadores: ante errores 5xx o un 429, Googlebot reduce el ritmo de rastreo temporalmente. Las URLs indexadas se mantienen, pero con el tiempo se descartan; el contenido que llega con un 5xx se ignora; y al volver el 2xx, la tasa de rastreo sube otra vez de forma gradual.

El matiz que casi nadie tiene en cuenta: ante un 404 Google concluye rápido que la página no existe y la retira; ante un 5xx no concluye nada, pero tampoco espera para siempre. Es una prórroga, no un indulto.

Por qué ya no ves el error (y aun así te está costando)

Search Console muestra lo que pasó cuando Google rastreó, no lo que ocurre al abrir la URL en el navegador. La ayuda del informe de indexación lo confirma: el error pudo ser temporal y la prueba en vivo puede salir bien. Ese desfase es lo que deja que el problema se cronifique, porque nadie lo mira.

Los errores 5xx, uno por uno: qué significa cada código

Cada código apunta a un culpable distinto:

  • 500 Internal Server Error - la aplicación reventó: excepción no capturada, error fatal del lenguaje, fallo de conexión con la base de datos. Es el único que señala a tu código o a tu entorno.
  • 502 Bad Gateway - el proxy, el balanceador o la CDN recibió una respuesta inválida del servidor de atrás, normalmente porque el proceso murió o el pool de trabajadores se agotó.
  • 503 Service Unavailable - sobrecarga temporal o mantenimiento programado. Es el 5xx más honesto: si vas a estar caído a propósito, este es el código.
  • 504 Gateway Timeout - el proxy esperó y el origen no contestó a tiempo. Habla de lentitud, no de caída: una consulta pesada o una página que tarda demasiado. Si te suena, empieza por el tiempo hasta el primer byte.
  • 429 Too Many Requests - no es 5xx por definición, pero Google lo trata como error de servidor y lo agrupa bajo la etiqueta HTTP 429/5XX. Si tu WAF limita peticiones por IP, Googlebot es el primero que se come el límite.

503 con Retry-After: decirle a Google cuándo volver

La norma HTTP admite segundos (Retry-After: 120) o una fecha absoluta en UTC. Google documenta el mismo encabezado para 503 y 429. No arregla nada, pero evita que Googlebot insista mientras arreglas el origen.

Los códigos propietarios del CDN también cuentan

Algunos proxys devuelven códigos no estándar dentro del rango 5xx, del estilo 52x, cuando no logran hablar con el origen. Para Google son errores de servidor igual: no te fíes del argumento de que no es un 500 de verdad.

Cómo saber en qué capa está el fallo

Recorre las capas de fuera hacia dentro: DNS y TLS, CDN o WAF, servidor web, aplicación y base de datos. El código delata la capa: 502 y 504 apuntan al tramo entre proxy y origen, 500 a la aplicación y 429 a un límite de peticiones.

Compara la URL pública con el origen directo:

curl -sI https://ejemplo.com/producto | head -1

Si la URL con CDN da 502 y el origen responde 200, el problema está en el tramo intermedio. Si el origen también falla, sigue bajando hasta el primer componente roto. Y si la respuesta cambia según el user-agent, ya sabes por dónde va.

El WAF que bloquea a Googlebot

La documentación advierte que los sistemas anti-DoS y los cortafuegos mal configurados pueden bloquear al rastreador, porque Googlebot hace muchas más peticiones que un humano. A veces responde 403, pero bajo ráfagas muchos devuelven 429 o 5xx. Si los 5xx aparecen en Google y nunca en las métricas de tu aplicación, mira el WAF antes que el código.

Dónde verlo en Search Console (sin adivinar)

Indexación de páginas agrupa las URLs bajo el estado Error del servidor (5xx): ahí ves cuántas son y ejemplos, que dicen si afecta a una plantilla entera o a casos aislados.

Configuración > Estadísticas de rastreo agrupa las peticiones de Googlebot por código, tipo de archivo y finalidad, y avisa cuando los errores apuntan a un problema de disponibilidad. Es donde se ve el pico en el tiempo y si tocó a todo el hostname. Para el detalle URL por URL, la API de inspección de URL automatiza la comprobación.

Validar la corrección sin precipitarse

Pide la validación cuando el servidor lleve estable un rato, no al reiniciar: Google vuelve a probar una muestra y tarda días. Mientras esperas, la fuente fiable son tus logs y el porcentaje de 5xx de las Estadísticas de rastreo.

Las tres causas que explican casi todo

Un despliegue

Variables de entorno que faltan, caché de configuración vieja, permisos cambiados o una migración que bloquea la tabla. Es el 500 del viernes por la tarde, y se detecta comparando la hora del pico con el historial de despliegues.

Recursos agotados

Sin workers libres el proxy responde 502; con la base de datos al límite aparece el 504; con disco lleno o memoria insuficiente se alternan 500 y 503. Ahí está la diferencia entre estar caído y estar ahogado, y los límites del plan de hosting explican buena parte de los casos.

Tráfico y bots

Un pico real, un scraper o un WAF estricto. El 429 es la pista: alguien limita peticiones y puede estar limitando a Googlebot. Si el pico no sale en analítica pero sí en logs, es un bot.

Caída corta, mantenimiento y caída larga: qué devolver

Caída corta (horas)

Arregla y deja que el 5xx sea 5xx. Google baja el ritmo y lo recupera solo al volver el 2xx. No fuerces reindexaciones.

Mantenimiento programado

503 más Retry-After. La guía de reducción de la tasa de rastreo es explícita: servir 500, 503 o 429 reduce el rastreo de urgencia en todo el hostname, incluidas las URLs que responden bien. Sirve para horas o un día, nunca como estado permanente.

Cuando se alarga más de uno o dos días

Si Googlebot ve esos códigos en la misma URL varios días, la URL puede salir del índice. Un 503 de una semana no es modo vacaciones: es una desindexación lenta.

Lo que no se hace

Devolver 200 con la página de error: Google lo lee como soft 404, peor que un 5xx honesto. Usar 401 o 403 para frenar el rastreo: la documentación confirma que los 4xx, salvo el 429, no afectan a la tasa de rastreo. Y borrar las URLs del sitemap durante la caída.

Monitorización: enterarte antes que Search Console

Search Console avisa con días de retraso; el servidor sabe en segundos. Mínimo viable: comprobación sintética por plantilla -portada, categoría, ficha, formulario- y alerta por porcentaje de 5xx, no solo por sitio caído. En logs, separa los 5xx por user-agent: si solo los sufre Googlebot, es WAF, no código. El análisis de logs del servidor lo resuelve en minutos.

Disponibilidad no es indexabilidad

Una web que responde 200 pero devuelve páginas vacías por un error de plantilla no aparece en el informe de 5xx y sí puede salir como soft 404. Hay que mirar contenido, no solo el código de estado.

Checklist para cerrar el caso

  1. Identifica la plantilla afectada en Indexación de páginas y cuántas URLs incluye.
  2. Reproduce el error con el mismo user-agent y desde fuera de tu red.
  3. Revisa logs del servidor y del WAF en la ventana exacta del pico.
  4. Corrige la causa, no el síntoma: si el 502 venía de workers agotados, el arreglo es capacidad.
  5. Confirma un 200 estable durante un ciclo completo de tráfico.
  6. Solo entonces valida y vigila Estadísticas de rastreo hasta que el porcentaje de 5xx vuelva a la normalidad.

Cuándo un 5xx es de verdad grave

Importan la persistencia, el alcance y el momento. Un 500 intermitente en una plantilla con miles de URLs pesa mucho más que una hora de 503 en un blog pequeño, y un 5xx que coincide con un lanzamiento cuesta más que el mismo error en una semana tranquila. Al recuperar, no solicites indexación en masa: la tasa se recupera sola. Si el tráfico ya cayó, ordena el diagnóstico con la guía de caída de tráfico en Google y revisa tu crawl budget, porque un 5xx sostenido gasta rastreo en balde. Y no confundas señales: un 301 es permanente y deliberado; un 5xx avisa de que algo se rompió.

Usamos cookies para mejorar tu experiencia y analizar el tráfico del sitio. Al continuar navegando aceptas su uso.

Privacidad