Error del servidor (5xx) en Search Console: un freno en todo el rastreo
En la Google Search Console, «Error del servidor (5xx)» es el único estado de error cuyo efecto se desborda más allá de la URL afectada. Un 404 queda confinado a su propia página; un 5xx empuja a Google a aflojar el rastreo de todo el sitio, con tanta más fuerza cuanto mayor es el número de URLs con error.
Esa mecánica de ralentización cambia la lectura del informe. ¿Qué señala de verdad un servidor que no pudo responder, cuando el código no dice nada del contenido de la página? ¿Por qué un puñado de 5xx no pesa lo mismo que una oleada que vuelve en cada subida de carga? ¿Y cuánto espera Google antes de retirar una URL indexada desde hace tiempo?
Tres preguntas que marcan la diferencia entre un hipo puntual y un freno instalado en todo el rastreo.
Error del servidor (5xx): qué te dice Search Console
El estado significa que, al paso de Googlebot, tu servidor devolvió un código 5xx (de 500 a 599) en vez de servir la página. El código no revela nada del contenido: solo indica que el servidor no pudo responder en ese instante. El informe «Indexación de páginas» de la Search Console agrupa estos casos bajo la etiqueta «Error del servidor (5xx)».
Ese es el matiz que separa un 5xx de un 4xx. Un 4xx es una respuesta sobre la página: el 404 dice «esta URL no existe», el 403 dice «el acceso está prohibido». Un 5xx no dice nada de la página, porque el servidor nunca llegó a procesarla. Se quedó mudo. Para Googlebot, ese silencio es una señal distinta de un rechazo explícito, y es justamente lo que dispara el comportamiento particular de los 5xx sobre el rastreo.
Ese silencio también distingue el 5xx del Soft 404, donde el servidor sí responde un código 200 «OK» pero sirve una página vacía o un mensaje de error. Del lado del 5xx, el servidor no miente sobre el estado de la página: admite que no puede responder. El Soft 404, en cambio, pretende que todo va bien cuando la página no tiene nada que ofrecer. Dos problemas opuestos, dos correcciones distintas.
Los códigos detrás del «5xx»: 500, 502, 503, 504
| Código | Nombre | Qué significa del lado de la infraestructura |
|---|---|---|
| 500 | Internal Server Error | Fallo de aplicación genérico: una excepción no gestionada, un script que se cae, una dependencia caída. |
| 502 | Bad Gateway | Una pasarela (proxy inverso, CDN, balanceador) recibió una respuesta no válida del servidor de origen (upstream). |
| 503 | Service Unavailable | Servicio temporalmente no disponible: saturación, reinicio o mantenimiento planificado. |
| 504 | Gateway Timeout | Una pasarela esperó demasiado una respuesta del origen: se agotó el tiempo de espera. |
La Search Console agrega todos estos casos bajo una sola etiqueta «5xx». Para conocer el código exacto que se produjo, hay que recuperarlo en otra parte: en los registros del servidor, o mediante una inspección que devuelva la respuesta que Googlebot recibió de verdad.
5xx, 4xx y robots.txt: tres bloqueos muy distintos
| 5xx | 4xx | robots.txt (disallow) | |
|---|---|---|---|
| ¿El código dice algo sobre la página? | No: el servidor no pudo responder. | Sí: la página no existe (404) o el acceso está prohibido (403). | No: exclusión voluntaria, la página no se lee. |
| ¿Efecto sobre la tasa de rastreo? | Ralentiza el rastreo de todo el sitio, proporcionalmente al número de URLs con error. | Ningún efecto sobre el ritmo (salvo el 429). | Ningún efecto. |
| Desindexación | Margen, luego retirada si el error persiste. | Retirada progresiva (Google reintenta antes de abandonar). | La URL puede seguir indexada sin que se lea su contenido. |
Esta tabla pone de relieve el rasgo propio de los 5xx: es el único de los tres casos cuyo efecto no se detiene en la URL culpable. Un 4xx y un bloqueo por robots.txt afectan únicamente a la página apuntada; un 5xx, en cambio, repercute en el ritmo de rastreo de todo el sitio.
Por qué un 5xx frena el rastreo de todo el sitio
Los errores 5xx (y el código 429) empujan a Googlebot a ralentizar temporalmente el rastreo de todo el sitio, proporcionalmente al número de URLs con error. Los 4xx, al contrario, no tienen ningún efecto sobre el ritmo de rastreo. La lógica de Google es sencilla: un servidor que responde con 5xx probablemente está en apuros, y seguir solicitándolo al mismo ritmo correría el riesgo de rematarlo.
Googlebot adopta, pues, un reflejo de protección. Cuanto más crece el volumen de 5xx, más reduce su cadencia para no agravar la situación. Este comportamiento está documentado por Google en su página sobre los errores HTTP y de red, que sitúa explícitamente los 5xx y el 429 entre las respuestas que hacen aflojar al rastreador.
La consecuencia para el SEO es indirecta pero real. Durante esa ralentización, tus páginas perfectamente sanas se rastrean con menos frecuencia. Una actualización de contenido, una página nueva, una corrección en una ficha de producto: todo eso lo ve Google más tarde. El freno no penaliza solo a las URLs con error, penaliza el ritmo al que Google descubre el conjunto de tus cambios. Eso es lo que vuelve el 5xx fundamentalmente distinto de un error No se ha encontrado (404), que queda confinado a su propia página sin tocar el resto.
Puntual o recurrente: calibrar la urgencia
No todos los 5xx valen lo mismo. Un pico aislado, ligado a un despliegue o a un reinicio, es un hipo: el servidor flaqueó una fracción de segundo y luego se recuperó. Una oleada recurrente, disparada en cada subida de carga, es un freno estructural instalado. Esa distinción marca directamente el nivel de prioridad que hay que dar a la corrección.
Los 5xx puntuales (despliegue, reinicio, tirón de red)
Un 5xx puntual surge en el momento preciso en que Googlebot llama a la puerta mientras el servidor está no disponible una fracción de segundo. Un despliegue que reinicia la aplicación, un contenedor reciclado, un pico de red pasajero: la ventana de indisponibilidad es estrecha, y la mayoría de tus visitantes ni siquiera la nota.
Estos errores aparecen en el informe, pero a menudo se resuelven solos al paso siguiente de Googlebot. El buen reflejo no es entrar en pánico con la primera línea 5xx, sino mirar si el fenómeno se repite de un análisis a otro. Un 5xx que aparece una vez y luego desaparece no tiene el mismo peso que un 5xx que vuelve en cada toma.
Los 5xx recurrentes o inducidos por la carga
Es el caso que de verdad merece atención. Aquí el servidor se satura, ya sea bajo la carga del tráfico real o bajo la del propio rastreo, cuando Googlebot explora muchas URLs en poco tiempo. Los errores son entonces intermitentes: surgen en los picos y luego se borran cuando la carga baja.
La trampa está en su invisibilidad. Abres la URL en tu navegador en un momento de calma, responde perfectamente un 200, y concluyes que es un falso positivo de la Search Console. En realidad, la página sí estaba en 5xx en el momento en que Googlebot la solicitó, en pleno pico. Es también un error HTTP que reaparece, con otra lógica, en el estado Se ha bloqueado debido a que el acceso no está permitido (403): lo que ves en un instante dado no siempre refleja lo que Googlebot recibió en su último paso.
Identificar las páginas con 5xx a escala
La herramienta de Inspección de URL de la Search Console da el veredicto 5xx página por página, lo que la vuelve impracticable en cuanto quieres medir la magnitud del fenómeno. Y los 5xx suelen ser intermitentes: una URL que responde correctamente cuando la pruebas pudo muy bien devolver un 5xx en el último paso de Googlebot. De ahí el interés de un veredicto fechado del paso de Google, en vez de una prueba que lanzas tú mismo en un momento de calma.
Ahí está toda la dificultad del diagnóstico de los 5xx. Un rastreo casero te dice el estado del servidor ahora, bajo tu propia carga. El veredicto de Google, en cambio, te dice el estado del servidor en el momento en que Googlebot llamó, bajo la carga de ese momento, que suele ser la que satura el servidor. Esas dos fotografías no siempre coinciden, y es la segunda la que determina lo que Google retiene.
💡 ¿Necesitas ver cuántas de tus URLs devuelven un 5xx, y cuáles? IndexProbe inspecciona tu lista de URLs a través de la API de la Search Console y devuelve, por página, el código que Googlebot recibió realmente, fechado en su último paso. Probar IndexProbe en acceso anticipado →
Del «código por URL» a la tasa de errores: lo que la GSC no muestra
La Search Console te da el estado de una URL, pero no te da, sobre la lista de páginas que te interesa, la parte exacta que devuelve un 5xx ni la lista precisa de las URLs afectadas. Sabes que hay un problema, sin medir su contorno. Y como la herramienta de inspección funciona una URL cada vez, reconstruir esa tasa a mano sobre miles de páginas resulta imposible.
Es exactamente el paso que IndexProbe automatiza. La herramienta es la versión en masa de la Inspección de URL de la Search Console: allí donde la GSC te hace inspeccionar tus páginas una por una, IndexProbe revisa la lista de URLs que le proporcionas, o que construyes desde tu GSC, y devuelve para cada una el código recibido por Googlebot. Obtienes de una sola vez la proporción de 5xx entre las páginas analizadas y la lista exacta de las URLs que hay que tratar, allí donde la herramienta de inspección de una en una te dejaría cruzar los resultados a mano.
Corregir un error del servidor 5xx
Corregir un 5xx es devolverle al servidor la capacidad de responder de nuevo un código 200. Según la causa, eso pasa por aliviar la carga (caché, CDN, ampliación de capacidad), corregir el fallo de aplicación responsable, u optimizar las consultas demasiado lentas que agotan los tiempos de espera. Para Google, la única señal de fin es la vuelta a un código 2xx en el paso siguiente de Googlebot.
Reflejos por código (500, 502, 503, 504)
Cada código orienta hacia una familia de causas, y por tanto hacia un punto de partida para el diagnóstico.
- 500 (Internal Server Error) — Rumbo a los registros de la aplicación. Una excepción no gestionada, una dependencia externa caída, una variable de entorno que falta tras un despliegue: el 500 es un fallo del lado del código, y la respuesta está en el rastro de error.
- 502 (Bad Gateway) — El problema está entre la pasarela y el servidor de origen. Comprueba que el servicio de aplicación esté funcionando, que el proxy inverso o el CDN apunten al destino correcto, y que el origen no devuelva una respuesta malformada.
- 503 (Service Unavailable) — A menudo es una señal de saturación o de reinicio. Si es la carga, hay que añadir capacidad o caché. Si es un mantenimiento, el 503 es justamente la respuesta correcta, a condición de acompañarla bien (ver más abajo).
- 504 (Gateway Timeout) — Una petición tarda demasiado en completarse. Busca los tratamientos lentos: consultas de base de datos sin optimizar, llamadas a servicios de terceros sin tiempo de espera, cálculos pesados en la ruta crítica.
Mantenimiento planificado: la respuesta correcta es 503 + Retry-After
⚙️ Cortar limpiamente para un mantenimiento
Para un corte de uno o dos días, la respuesta correcta es un código 503 acompañado de la cabecera
Retry-After, que le indica a Googlebot cuándo volver. Google espera entonces sin penalizar el sitio, entendiendo que la indisponibilidad es voluntaria y temporal.A evitar a toda costa: devolver un código 200 con un mensaje «Sitio en mantenimiento». Para Google, eso es una página válida de contenido vacío, es decir, un Soft 404 en potencia.
Atención, por último, a la duración: más allá de unos pocos días, un 503 prolongado acaba sacando las páginas del índice. El método está documentado por Google en su guía Pausar un negocio online.
Comprobar que la corrección ha funcionado
Tres movimientos medibles confirman que la corrección ha surtido efecto: el número de páginas en 5xx baja, la tasa de errores 5xx sobre el perímetro vigilado retrocede, y las páginas rastreadas en 30 días vuelven a subir, señal de que Google suelta el freno. El método consiste en comparar dos análisis del mismo perímetro, antes y después de la intervención.
Un punto que conviene tener presente: la recuperación del rastreo es progresiva, no instantánea. Una vez resueltos los 5xx, Googlebot no acelera de golpe. Vuelve a probar con prudencia, comprueba que el servidor aguanta, y luego eleva poco a poco su cadencia. Las páginas rastreadas en 30 días remontan, por tanto, a lo largo de varias tomas, no de la noche a la mañana.
💡 Sigue la recuperación del rastreo, análisis tras análisis. IndexProbe te da el veredicto oficial 5xx de Google, fechado en su último paso, sobre la lista de URLs que le proporcionas o que construyes desde la GSC. Al relanzar el mismo análisis, comparas dos tomas del mismo perímetro y mides la bajada real de los errores y la recuperación del rastreo, sin volver a cruzar la Inspección de URL página a página. Probar IndexProbe en acceso anticipado →
Preguntas frecuentes
¿Un error 5xx desindexa mi página? No de inmediato. Mientras el error sea puntual, Google le da un margen a la página y la sigue considerando indexada. Solo si el 5xx persiste en el tiempo la URL acaba saliendo del índice. La vuelta a un código 2xx en el paso siguiente de Googlebot devuelve la página a la carrera.
¿Qué diferencia hay entre un 5xx y un 404 para el SEO? Un 404 queda confinado a su propia página y no tiene ningún efecto sobre el ritmo de rastreo del resto del sitio. Un 5xx, en cambio, no dice nada del contenido de la página pero ralentiza el rastreo de todo el sitio, proporcionalmente al número de URLs con error. El 404 es un problema local, el 5xx un problema que se desborda.
¿Cuánto espera Google antes de retirar una URL en 5xx?
Google no publica una duración precisa. Su documentación habla de errores «persistentes» sin fijar un umbral cifrado. El único caso acotado es el mantenimiento con un 503 y una cabecera Retry-After: Google espera entonces unos pocos días, pero más allá, el 503 prolongado también acaba sacando las páginas.
¿Hay que devolver un 503 o un 500 durante un mantenimiento?
Un 503 acompañado de la cabecera Retry-After. El 503 indica una indisponibilidad voluntaria y temporal, que Google entiende y tolera. Al contrario, un 500 sufrido es un fallo, y un 200 con un mensaje «Sitio en mantenimiento» es una señal falsa que se interpretará como una página vacía, es decir, un Soft 404 en potencia.
¿El 429 se trata como un 5xx? Desde el punto de vista del rastreo, sí. El 429 («Too Many Requests») es el único error de la familia 4xx que, como los 5xx, hace ralentizar el rastreo de todo el sitio. Google lo clasifica junto a los errores de servidor precisamente porque señala una saturación, y adopta por tanto el mismo reflejo de protección.