Error del servidor (5xx)

TL;DR — “Server error (5xx)” (traducción) «Error del servidor (5xx)» significa que Google intentó cargar una página y el servidor respondió con un error (un código de nivel 500) en vez de mostrarla. Google no puede indexar un error, por lo que la URL no aparece en la búsqueda. Un fallo breve no suele ser grave: Google reduce el ritmo y vuelve a intentarlo. Sin embargo, si los errores persisten, las páginas pueden acabar desapareciendo de Google. Al corregirse el servidor, el rastreo se recupera automáticamente.

Qué significa este estado

Esta etiqueta significa que la solicitud de Google recibió una respuesta del servidor dentro del intervalo 5xx. Evidence for this claim Google reports Server error 5xx when the server returned a 500-level response for the requested page. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google reduce el rastreo ante errores 5xx y puede terminar retirando las URL que fallan de forma persistente. Evidence for this claim Google slows crawling for 5xx responses and may eventually remove persistently failing URLs from the index. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Cuando Googlebot solicita una página, el servidor responde con un código de estado. Un 200 significa “here’s the page” (traducción) «aquí está la página». 5xx es toda una familia de códigos de error — 500, 502, 503, 504— que indican que algo falló del lado del servidor. Cuando Search Console muestra Server error (5xx) bajo Not indexed, informa que Google solicitó esa URL y recibió uno de esos errores en lugar de la página.

Google no puede indexar una página de error. No hay contenido real que leer, por lo que la URL permanece fuera de la búsqueda hasta que el servidor vuelve a responder con normalidad.

¿Es una emergencia?

Depende de si se trata de un caso aislado o de un patrón:

• Un fallo breve —el servidor estuvo ocupado durante un minuto o un despliegue lo reinició— es normal. Google detecta el error, reduce el ritmo y vuelve a intentarlo más tarde, sin daño duradero.
• Los errores recurrentes son el problema. Cuanto más tiempo devuelve 5xx el servidor, más reduce Google el rastreo, hasta que finalmente pueden retirarse páginas que ya estaban en Google.

Google no publica una cantidad “safe” (traducción) «segura» de URL señaladas: el impacto sobre la tasa de rastreo varía según cuántas URL fallen, no según un umbral fijo. Conviene priorizar lo que realmente importa: si la página es importante, si sigue fallando al repetir la comprobación y si se trata de unas pocas URL o de muchas. Una URL importante que falla repetidamente requiere atención inmediata; un fallo puntual en una página de poco valor suele resolverse solo. Muchas URL señaladas, o las mismas de forma reiterada, indican una avería real del sitio.

Cómo empezar a corregirlo

1. Comprobar si el sitio está disponible. Abrir una página señalada. Si también devuelve un error en esa comprobación, el servidor tiene un problema.
2. Consultar al proveedor de alojamiento o al equipo de desarrollo. Los errores 5xx casi siempre proceden del servidor, la aplicación o la base de datos, no del contenido de la página ni de la configuración de SEO.
3. Revisar las estadísticas de rastreo en Search Console (Configuración → Estadísticas de rastreo). Allí se muestra si Google ha encontrado errores recientemente en todo el sitio.
4. Después de corregirlo, solicitar una nueva comprobación. En el informe Indexación de páginas, abrir el problema “Server error (5xx)” y seleccionar Validate Fix. Google vuelve a rastrear las URL afectadas y las retira del problema a medida que responden correctamente.

El error más habitual

Si alguna vez es necesario desactivar el sitio deliberadamente —por mantenimiento, por ejemplo—, no conviene mostrar simplemente una página de error ni una página “we’ll be back soon” (traducción) «volveremos pronto» que responda con un 200 normal. Tampoco debe usarse un 404. La opción correcta es el estado 503 (literalmente, “service unavailable, temporarily” (traducción) «servicio no disponible temporalmente»). Así se comunica a Google “I’m down for a bit, come back later” (traducción) «el servicio no está disponible por un momento; volver más tarde» en vez de indicar que la página está averiada o ha desaparecido. La pestaña Avanzado explica la implementación correcta.

La pestaña Avanzado presenta la versión completa: cómo reacciona exactamente Google ante los 5xx, las diferencias entre 500, 502 y 503, el diagnóstico de la causa y la configuración correcta del modo de mantenimiento.

TL;DR — “Server error (5xx)” (traducción) «Error del servidor (5xx)» significa que el servidor devolvió un código de nivel 500 cuando Googlebot solicitó la URL, por lo que la página no puede indexarse. Hay dos perjuicios distintos: Google reduce la tasa de rastreo (en proporción a cuántas URL fallan) e ignora todo contenido devuelto con un 5xx; si los errores persisten, las URL ya indexadas se conservan al principio y luego se retiran. La recuperación es automática cuando se vuelve a 2xx, aunque la tasa de rastreo aumenta gradualmente. Google agrupa 429 (limitación de tasa o servidor sobrecargado) con 5xx. Entre las causas figuran un alojamiento sobrecargado o mal configurado, errores de la aplicación o base de datos, fallos ascendentes o de CDN, o una CDN/WAF que bloquee Googlebot. Antes de cambiar reglas de seguridad, se debe verificar mediante DNS inverso o intervalos de IP, porque el agente de usuario de Googlebot puede falsificarse. El diagnóstico sigue esta secuencia: disponibilidad del host en Estadísticas de rastreo → registros del servidor → prueba en vivo de Inspección de URL. Para cierres planificados, Google recomienda mantener el sitio en línea con funcionalidad limitada. Si es imprescindible desactivarlo por completo, la respuesta correcta es 503 + Retry-After durante uno o dos días (“a few days at most” (traducción) «unos días como máximo»); mantenerla durante semanas perjudica la indexación y no existe un plazo fijo de recuperación. Además, robots.txt debe seguir respondiendo 200, porque un 503 en robots.txt puede pausar el rastreo de todo el sitio. Después puede ejecutarse Validate Fix (opcional; solo permite seguir el estado de la corrección).

Qué informa realmente el estado

La etiqueta informa la respuesta observada por Google, no el fallo concreto del origen, proxy, base de datos o CDN que la causó. Evidence for this claim Google reports Server error 5xx when the server returned a 500-level response for the requested page. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report La guía de HTTP de Google define por separado los efectos sobre el rastreo y la indexación. Evidence for this claim Google slows crawling for 5xx responses and may eventually remove persistently failing URLs from the index. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

La definición de Google se resume en una línea: el servidor devolvió un error de nivel 500 cuando se solicitó la página. Googlebot hizo una solicitud y, en vez de un 200 con contenido, recibió un 500, 502, 503, 504 o similar. La URL aparece bajo Not indexed porque no había contenido utilizable que indexar.

Debe mantenerse clara una distinción: se trata del código de respuesta, no del contenido, marcado ni configuración de SEO de la página. Un 5xx es un problema del servidor y la infraestructura. Editar el HTML de la página no corrige un 502 procedente de un backend sobrecargado.

Cómo trata Google los 5xx: la economía del rastreo

Esta parte suele omitirse y explica por qué un 5xx importa más que, por ejemplo, un 404. La documentación de Google sobre errores HTTP detalla el comportamiento:

• El rastreo se ralentiza. Los errores 5xx (y 429) hacen que los rastreadores de Google reduzcan temporalmente el ritmo. La disminución es proporcional al número de URL individuales que devuelven un error del servidor: unas pocas URL producen un ajuste leve; un 5xx generalizado frena con fuerza.
• El contenido se ignora. Todo lo recibido desde una URL que devuelve 5xx se descarta. Un cuerpo de error no obtiene crédito parcial: Google no indexa un mensaje de sitio caído servido con 500.
• Las URL indexadas se conservan y después se retiran. Al principio permanecen en el índice, pero la canalización de indexación de Google retira las URL que devuelven persistentemente un error del servidor. Una interrupción breve no cuesta presencia en el índice; una prolongada sí.
• La recuperación es automática, pero gradual. Cuando el servidor vuelve a responder con 2xx, Google aumenta poco a poco la tasa de rastreo. No se requiere abrir una incidencia: se corrige el servidor y el rastreo se recupera con cautela por sí solo.

Esa secuencia —ralentizar → ignorar el contenido → conservar → retirar → recuperarse con 2xx— constituye el eje de precisión de todo el tema.

429 cuenta como error del servidor. Es importante señalarlo porque gran parte del contenido competidor lo omite: Google interpreta 429 Too Many Requests como señal de sobrecarga del servidor y lo agrupa con 5xx. Si la limitación de tasa o la protección contra bots responde 429 a Googlebot, se produce la misma ralentización del rastreo que con un 500.

Los códigos 5xx habituales según su posible causa raíz

Saber qué 5xx aparece es un punto de partida para saber dónde investigar, no una prueba de qué se averió. RFC 9110 (la especificación HTTP) define cada código según lo que hacía el componente que respondió, y cualquiera puede proceder de un servidor de origen, un servidor de aplicaciones, un balanceador de carga, una CDN o un proxy delante del origen real. El código es la primera pista; después deben correlacionarse los registros del perímetro, origen, aplicación y base de datos o dependencias correspondientes a la misma solicitud antes de concluir qué capa falló:

• 500 Internal Server Error — según la especificación, “the server encountered an unexpected condition that prevented it from fulfilling the request.” (traducción) «el servidor encontró una condición inesperada que le impidió satisfacer la solicitud». Es deliberadamente genérico: suele deberse al código de la aplicación o a un error de ejecución o configuración, pero el estado por sí solo no lo demuestra; deben revisarse los registros de la aplicación.
• 502 Bad Gateway — “the server, while acting as a gateway or proxy, received an invalid response from an inbound server.” (traducción) «el servidor, mientras actuaba como puerta de enlace o proxy, recibió una respuesta no válida de un servidor entrante». Señala una interacción ascendente, no un proveedor concreto: debe revisarse la cadena formada por balanceador, proxy inverso, CDN y origen.
• 503 Service Unavailable — “the server is currently unable to handle the request due to a temporary overload or scheduled maintenance.” (traducción) «el servidor no puede atender actualmente la solicitud por una sobrecarga temporal o mantenimiento programado». Conviene revisar capacidad, picos de tráfico y estados de mantenimiento. Es también el código que debe enviarse deliberadamente durante una interrupción planificada. La especificación advierte que un servidor sobrecargado ni siquiera tiene obligación de devolver 503: “some servers might simply refuse the connection,” (traducción) «algunos servidores podrían simplemente rechazar la conexión», lo que puede aparecer como tiempo de espera o error de conexión.
• 504 Gateway Timeout — “the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server.” (traducción) «el servidor, mientras actuaba como puerta de enlace o proxy, no recibió a tiempo la respuesta de un servidor ascendente». Marca un límite de tiempo de espera, no qué componente fue lento: deben revisarse consultas largas a la base de datos, llamadas lentas a terceros y un origen sometido a demasiada carga.

Existe un hilo práctico común: los 5xx suelen remontarse a un backend sobrecargado o lento, por lo que mejorar el rendimiento del servidor —consultas más rápidas, renderizado del lado del servidor más ligero, más capacidad— suele formar parte de la solución. Sin embargo, como el mismo código puede surgir en cualquier capa de la cadena, el código acota la búsqueda y los registros identifican dónde falló.

Causas habituales

• Alojamiento sobrecargado. Los picos de tráfico, incluido un rastreo agresivo, superan la capacidad del servidor y este empieza a rechazar solicitudes con 5xx.
• Errores de aplicación o base de datos. Excepciones no controladas, base de datos caída, despliegue defectuoso o grupos de conexiones agotados.
• Configuración incorrecta. Una configuración rota tras un cambio, una dependencia vencida o un disco lleno.
• Fallos ascendentes o de CDN. El origen funciona, pero un proxy, balanceador o CDN devuelve 502/504, o la propia CDN sufrió una interrupción.
• Una CDN/WAF o un limitador de tasa bloquea Googlebot. La protección contra bots, las reglas de seguridad o la limitación de tasa confunden Googlebot con un atacante y devuelven 5xx o 429 solo a Googlebot, mientras las personas acceden sin problemas. Es una causa real frecuente y poco cubierta; por ello debe reproducirse como Googlebot y no limitarse a una comprobación en el navegador.

Cómo diagnosticarlo

Conviene avanzar desde la vista de todo el sitio hasta la URL individual:

1. Estadísticas de rastreo → Disponibilidad del host. En Search Console: Configuración → Estadísticas de rastreo. El estado del host y el desglose por código de respuesta muestran si los 5xx son persistentes y amplios o un fallo aislado, además de indicar aproximadamente cuándo comenzaron.
2. Registros del servidor y de acceso. Son la fuente de verdad. Deben filtrarse por Googlebot verificado (véase la pestaña Scripts) y revisarse los códigos recibidos y sus marcas de tiempo. Los registros revelan bloqueos de CDN/WAF contra Googlebot que una prueba de navegador no mostraría.
3. Inspección de URL → Prueba en vivo. Ejecutar una URL señalada en Inspección de URL y usar Test Live URL. Esto confirma si Google-InspectionTool puede acceder en este momento, pero no prueba lo ocurrido cuando Google registró antes el 5xx. Que una página funcione minutos u horas más tarde no descarta un error real: hora, IP, ubicación geográfica, caché y detección de bots pueden variar.
4. Reproducir como Googlebot. Solicitar la URL con el agente de usuario de Googlebot y, si es posible, desde fuera de la red, para detectar reglas WAF o de limitación dirigidas al bot. Es una prueba diferencial, no una prueba verificada de lo que vio Googlebot: la cadena Googlebot es trivial de falsificar. Antes de relajar una regla WAF, CDN o de tasa porque “it’s only blocking Googlebot” (traducción) «solo bloquea Googlebot», debe confirmarse en los registros que el tráfico es Googlebot real mediante DNS inverso o los intervalos de IP publicados por Google (véase Scripts). Nunca se debe cambiar un control de seguridad basándose únicamente en el encabezado de agente de usuario.

Cómo corregirlo

Una vez identificada la causa, las correcciones siguen la guía de Google “fixing server errors” (traducción) «corrección de errores del servidor»:

• Confirmar la escala en Estadísticas de rastreo antes de cambiar nada: ¿es persistente y amplio o aislado?
• Reducir la carga excesiva de páginas en solicitudes dinámicas. Almacenar en caché las páginas costosas, optimizar consultas lentas y evitar generar respuestas pesadas en cada solicitud.
• Comprobar que el host no esté caído, sobrecargado ni mal configurado. Añadir capacidad, corregir la configuración, reiniciar el servicio averiado y revisar la base de datos.
• Comprobar que Google no esté bloqueado accidentalmente. Auditar reglas de CDN, WAF, bots y límites de tasa que puedan devolver 5xx o 429 a Googlebot.
• Controlar el rastreo con criterio. Si el rastreo agresivo sobrecarga el sistema, debe usarse un 503 o 429 temporal para reducir el ritmo del bot, no un bloqueo permanente.

La forma correcta de desactivar un sitio deliberadamente: 503 + Retry-After

A veces se necesita que el sitio no esté disponible: una migración, mantenimiento programado o la pausa de un negocio en línea. Hacerlo mal convierte un evento planificado en uno de desindexación. El documento de Google Pause your online business in Google Search explica el enfoque correcto.

La recomendación predeterminada de Google es mantener el sitio disponible, aunque limitado. Si el cierre es temporal y se prevé reabrir, Google prefiere “keep your site online and limit the functionality” (traducción) «mantener el sitio en línea y limitar su funcionalidad» en vez de desactivarlo por completo. La desactivación total con 503 es la opción urgente, no la predeterminada.

Cuando sea necesario desactivar todo el sitio, debe usarse 503 (Service Unavailable) con un encabezado Retry-After. Google indica: “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code.” (traducción) «Si es necesario desactivar urgentemente el sitio durante uno o dos días, se debe devolver una página informativa de error con un código de estado HTTP 503». También debe acompañarse con el encabezado: “Use the retry-after HTTP header with a best effort date or duration.” (traducción) «Usar el encabezado HTTP retry-after con una fecha o duración aproximada». El 503 indica una caída temporal y Retry-After orienta al bot sobre cuándo volver, pero el encabezado es orientativo, no una garantía de rastreo en ese momento exacto.

Es solo una medida a corto plazo. Google la denomina “an extreme measure that should only be taken for a very short period of time (a few days at most).” (traducción) «una medida extrema que solo debe adoptarse durante un periodo muy breve (unos días como máximo)». También advierte: “Completely closing a site even for just a few weeks can have negative consequences on Google’s indexing of your site.” (traducción) «Cerrar por completo un sitio, incluso durante unas semanas, puede tener consecuencias negativas para su indexación en Google». No existe un atajo para recuperarse: “there’s no fixed time for a recovery from a complete removal, and there’s no mechanism to speed that up.” (traducción) «no hay un plazo fijo para recuperarse de una retirada completa ni un mecanismo para acelerarlo». Por tanto, un 503 correcto protege durante uno o dos días, pero ningún código de estado ni validación en Search Console evita el daño de permanecer fuera de línea durante semanas o garantiza una fecha de retorno. Una interrupción larga requiere otro plan, posiblemente con redirecciones.

Por qué no debe usarse 200 ni 404

• No servir una página 200 “under maintenance” (traducción) «en mantenimiento». Google trata su contenido como el de la página real y podría indexar el mensaje “we’ll be back soon” (traducción) «volveremos pronto». En cambio, el contenido de un 503 correcto se ignora, que es el resultado deseado.
• No devolver 404 (ni 403/410). La guía de Google indica expresamente que no debe bloquearse el sitio con 403, 404 o 410 durante una interrupción. 404 significa que el recurso desapareció, no que está temporalmente caído; si se desea conservar la página, corresponde un 503.

La trampa de robots.txt: debe seguir siendo rastreable

Este detalle suele pasarse por alto y puede pausar el rastreo de todo el sitio. Durante una ventana de mantenimiento con 503, el archivo robots.txt debe seguir respondiendo 200 y permanecer rastreable. Google es tajante: “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.” (traducción) «No devolver un código de estado HTTP 503 para el archivo robots.txt, porque bloquea todo el rastreo». El controlador de mantenimiento debe excluir robots.txt para que siempre responda 200; no conviene dejarlo al azar.

Como contexto, la especificación de robots.txt de Google describe un comportamiento por etapas si el propio archivo empieza a fallar, no un bloqueo instantáneo y permanente: durante las primeras 12 horas Google detiene el rastreo mientras sigue reintentando robots.txt; durante los 30 días siguientes usa la última versión válida conocida mientras intenta obtener una nueva; después de 30 días, si el sitio es accesible, descarta la versión en caché y actúa como si no existiera robots.txt, es decir, sin sus restricciones. Si no existe una versión en caché, Google también supone que no hay restricciones. Nada de esto justifica correr ese riesgo deliberadamente: una pausa de varios días al inicio sigue siendo perjudicial. Solo significa que un 503 accidental en robots.txt no es un estado permanente e irrecuperable si se corrige.

Validación de la corrección en GSC

Después de restablecer el servidor:

1. Abrir el problema Server error (5xx) en el informe Indexación de páginas.
2. Seleccionar Validate Fix. Google vuelve a rastrear las URL afectadas por lotes.
3. Observar el estado de validación. Las URL que vuelven a 200 desaparecen del problema; si algunas aún fallan, la validación las señala para diagnosticarlas individualmente.

No es necesario esperar a la validación para que se produzca el rastreo natural, pero Validate Fix prioriza el conjunto afectado y proporciona un estado que puede seguirse. La tasa de rastreo aumenta gradualmente cuando vuelven las respuestas 2xx, por lo que no debe esperarse una recuperación instantánea del volumen anterior.

Relación con otros temas

Un 5xx es un problema de rastreo y entrega, por lo que afecta temas vecinos: los 5xx persistentes reducen drásticamente la tasa de rastreo, la palanca que Googlebot ajusta cuando el servidor tiene dificultades, y la vista a nivel de host aparece en el informe Estadísticas de rastreo y su estado del host. Es distinto de un 404 (no encontrado), que indica que el recurso desapareció en vez de estar averiado y se trata con mucha más suavidad. Para comprender el descubrimiento y la obtención, puede consultarse el centro sobre rastreo; para los demás estados de Indexación de páginas, el centro de Indexación de páginas de GSC.

Resumen de IA

Versión condensada de la perspectiva Avanzado:

• Qué es: “Server error (5xx)” (traducción) «Error del servidor (5xx)» en Indexación de páginas de GSC significa que Googlebot solicitó una URL y el servidor devolvió un código de nivel 500 (500/502/503/504) en lugar de 200. La página queda bajo Not indexed porque no hay contenido utilizable. Es un problema de servidor o infraestructura, no de contenido.
• Cómo reacciona Google: el rastreo se ralentiza en proporción a cuántas URL fallan; el contenido de un 5xx se ignora; las URL indexadas se conservan y luego se retiran si persisten los errores; la tasa de rastreo se recupera gradualmente cuando vuelven los 2xx.
• 429 cuenta: Google agrupa 429 Too Many Requests (servidor sobrecargado) con 5xx; limitar la tasa de Googlebot provoca la misma ralentización.
• Los códigos son un punto de partida, no una prueba: 500 = condición inesperada del servidor; 502 = respuesta ascendente incorrecta para una puerta de enlace o proxy; 503 = sobrecarga o mantenimiento; 504 = tiempo de espera agotado mientras se esperaba al servidor ascendente. Cualquiera puede originarse en el servidor de origen, aplicación, base de datos, balanceador o CDN; deben correlacionarse los registros de todas las capas antes de atribuir la causa.
• Causas habituales: alojamiento sobrecargado o mal configurado, errores de aplicación o base de datos, fallos ascendentes o de CDN, y una CDN/WAF o un limitador que bloquee Googlebot (devuelve 5xx/429 al bot mientras las personas acceden correctamente). Antes de cambiar reglas de seguridad, debe confirmarse que sea Googlebot real mediante DNS inverso o intervalos de IP; el agente de usuario puede falsificarse.
• Diagnóstico: disponibilidad del host en Estadísticas de rastreo → registros filtrados por Googlebot → prueba en vivo de Inspección de URL → reproducción como Googlebot. Que una página funcione ahora solo describe el estado actual, no lo que Googlebot encontró cuando registró el error.
• Interrupción planificada correcta: Google prefiere mantener el sitio disponible con funcionalidad limitada. Si debe desactivarse por completo, usar 503 + Retry-After (Retry-After es orientativo) durante uno o dos días (“a few days at most” (traducción) «unos días como máximo»); semanas de interrupción dañan la indexación y no hay un plazo fijo de recuperación. No usar una página de mantenimiento con 200 ni un 404.
• La trampa de robots.txt: mantener robots.txt en 200 durante la ventana 503. Un 503 en robots.txt puede pausar el rastreo general (según la especificación: 12 horas sin rastreo y después hasta 30 días usando el robots.txt almacenado antes de asumir que no hay restricciones).
• Validación: corregir el servidor y después usar Validate Fix en Indexación de páginas. Es opcional; Google actualiza el recuento con cualquier nuevo rastreo. La tasa de rastreo vuelve gradualmente.

Documentación oficial

Documentación de fuentes primarias de los motores de búsqueda.

Google

• Page Indexing report — el informe, incluida la definición del estado “Server error (5xx)” y la guía “fixing server errors”.
• How HTTP status codes affect Google’s crawlers — tratamiento exacto de 5xx y 429: ralentización del rastreo, contenido ignorado, conservación seguida de retirada y recuperación con 2xx.
• Pause your online business in Google Search — documento canónico para desactivar correctamente un sitio: 503 + Retry-After, “a few days at most” y la regla de mantener robots.txt rastreable.
• How to deal with planned site downtime (Search Central blog, 2011) — explicación anterior, todavía citada, del mismo consejo sobre 503.
• How Google interprets the robots.txt specification — comportamiento por etapas cuando robots.txt devuelve 5xx: pausa de 12 horas, hasta 30 días con la versión almacenada y, después, suposición de que no hay restricciones.
• Optimize your crawl budget — cómo influyen las respuestas del servidor, incluidos los 5xx, en la capacidad de rastreo.

Bing / Microsoft

• Bing Webmaster Guidelines — Bing muestra errores del servidor en sus informes de rastreo y, como Google, recomienda un 503 con un encabezado Retry-After durante interrupciones temporales para que Bingbot vuelva en vez de retirar páginas.

Citas de la fuente

Declaraciones públicas de Google. Cada enlace lleva directamente al pasaje citado en la página de origen.

Google — definición del estado en Indexación de páginas

• “Your server returned a 500-level error when the page was requested.” (traducción) «El servidor devolvió un error de nivel 500 cuando se solicitó la página». — Google, documento de ayuda del informe Indexación de páginas. Ir a la cita

Google — tratamiento de los 5xx (documento sobre códigos de estado HTTP)

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped.” (traducción) «Los errores de servidor 5xx y 429 hacen que los rastreadores de Google ralenticen temporalmente el rastreo. En Google Search, las URL ya indexadas se conservan en el índice, pero finalmente se retiran». Ir a la cita
• “Any content Google receives from URLs that return a 5xx status code is ignored.” (traducción) «Se ignora todo contenido que Google recibe de URL que devuelven un código de estado 5xx». Ir a la cita
• “Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error.” (traducción) «Google reduce la tasa de rastreo del sitio. La reducción es proporcional al número de URL individuales que devuelven un error del servidor». Ir a la cita
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (traducción) «Cuando el servidor empieza a responder con un código de estado 2xx, Google aumenta gradualmente la tasa de rastreo del sitio». Ir a la cita
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (traducción) «Los rastreadores de Google interpretan el código de estado 429 como señal de que el servidor está sobrecargado y lo consideran un error del servidor». Ir a la cita

Google — desactivar correctamente un sitio (Pause your online business)

• “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code.” (traducción) «Si es necesario desactivar urgentemente el sitio durante uno o dos días, se debe devolver una página informativa de error con un código de estado HTTP 503». Ir a la cita
• “This is an extreme measure that should only be taken for a very short period of time (a few days at most).” (traducción) «Esta es una medida extrema que solo debe adoptarse durante un periodo muy breve (unos días como máximo)». Ir a la cita
• “Completely closing a site even for just a few weeks can have negative consequences on Google’s indexing of your site.” (traducción) «Cerrar por completo un sitio, incluso durante unas semanas, puede tener consecuencias negativas para su indexación en Google». Ir a la cita
• “Use the retry-after HTTP header with a best effort date or duration.” (traducción) «Usar el encabezado HTTP retry-after con una fecha o duración aproximada». Ir a la cita
• “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.” (traducción) «No devolver un código de estado HTTP 503 para el archivo robots.txt, porque bloquea todo el rastreo». Ir a la cita

Lista de comprobación para corregir “Server error (5xx)”

Se recomienda seguir el orden indicado; los primeros pasos determinan si se trata de una emergencia.

• Confirmar la escala. GSC → Configuración → Estadísticas de rastreo → disponibilidad del host y gráfico por código de respuesta. ¿Es persistente o amplio, o un fallo aislado?
• Reproducir el error. Cargar una URL señalada y después usar Inspección de URL → Probar URL publicada para observar la respuesta desde Google en ese momento.
• Comprobar que no sea específico de bots. Solicitar la URL con el agente de usuario de Googlebot y desde fuera de la red para detectar reglas de CDN, WAF o tasa que solo afecten al bot (5xx o 429).
• Leer los registros. Filtrar los registros del servidor o acceso por Googlebot verificado; confirmar qué códigos recibió y cuándo comenzaron los 5xx.
• Identificar el código. 500 (aplicación o BD) · 502 (ascendente incorrecto) · 503 (sobrecarga o mantenimiento) · 504 (tiempo de espera ascendente). Orienta hacia la capa que debe corregirse.
• Reducir la carga dinámica. Almacenar en caché páginas costosas, optimizar consultas lentas y corregir el trabajo pesado del servidor detrás de 503/504.
• Corregir la salud del host. Capacidad, configuración, reinicios, base de datos y dependencias.
• Auditar bloqueos contra Google. Reglas de CDN/WAF/bots/tasa que devuelvan 5xx/429 a Googlebot.
• Verificar que robots.txt responde 200, sobre todo si hay un controlador de mantenimiento. Un 503 en robots.txt puede pausar el rastreo general.
• Ejecutar Validate Fix cuando el servidor esté sano y observar el estado de validación.

Lista de comprobación para una interrupción planificada (“503 done right” (traducción) «503 bien implementado»)

Antes de activar el modo de mantenimiento:

• Servir 503 (Service Unavailable), no 200, 403, 404 ni 410.
• Añadir un encabezado Retry-After con una fecha o duración aproximada.
• Mantenerlo breve: uno o dos días, unos días como máximo. Semanas de interrupción perjudican la indexación con independencia del código de estado.
• Excluir robots.txt de la regla de mantenimiento para que siga respondiendo 200 y sea rastreable.
• Servir en el cuerpo 503 una página de mantenimiento útil para las personas. Google ignora el contenido, pero quienes visiten el sitio sí lo verán.
• Al restablecer el sitio, confirmar que las páginas responden 200 y que la tasa de rastreo se recupera de forma gradual.

Hojas de referencia rápida sobre 5xx

Los códigos 5xx habituales: qué significan y dónde investigar

Cómo reacciona Google ante un 5xx

Qué código de estado corresponde a cada situación

Modelos mentales

1. Un 5xx significa “broken” (traducción) «averiado»; un 404, “gone” (traducción) «desaparecido». Google los trata de forma muy distinta. Un 404 no es problemático: una vez descubierto, Googlebot vuelve a probarlo y lo retira gradualmente. Un 5xx indica que algo falla en el servidor, por lo que Google reduce el ritmo, ignora el contenido y, si persiste, retira las páginas. Al elegir deliberadamente un código de estado, debe seleccionarse el que refleje la realidad.

2. Ralentizar → ignorar → conservar → retirar → recuperar. Ese es el ciclo de vida de un 5xx. Las interrupciones breves se toleran porque permanecen en la fase de conservación; las prolongadas cuestan presencia en el índice porque alcanzan la retirada; y la solución consiste simplemente en volver a 2xx, que inicia una recuperación gradual.

3. La regla de proporcionalidad. La ralentización es proporcional a cuántas URL fallan. Una URL inestable produce un ajuste leve; un 5xx generalizado frena con fuerza. Esto orienta la priorización: un conjunto pequeño es menos urgente; un error a nivel de host es una emergencia.

4. 503 es una función, no solo un error. Para una interrupción planificada, 503 + Retry-After es la respuesta correcta y segura para SEO, porque expresa temporalidad. Sin embargo, es una herramienta de corto plazo: unos días como máximo. Ningún código protege contra el daño de indexación de permanecer fuera de línea durante semanas.

5. robots.txt soporta todo el sistema. robots.txt debe tratarse como la URL que nunca puede devolver 5xx. Un 503 en robots.txt no solo lo oculta: pausa el rastreo de todo el sitio. Toda regla de mantenimiento debe excluirlo.

6. Reproducir como el bot, no como una persona. Las causas 5xx más difíciles —reglas WAF y limitación de tasa— se activan solo para Googlebot. Si la página funciona en el navegador pero GSC informa 5xx, el problema aún no se ha reproducido: debe probarse con el agente de usuario de Googlebot y revisarse los registros.

Comprobar qué código de estado devuelve realmente una URL

El primer paso consiste en confirmar el código de respuesta desde la línea de comandos y, de ser posible, como Googlebot, ya que algunos 5xx/429s solo se activan para el bot.

macOS / Linux

# Status code as a normal client
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

# Status code as Googlebot (catches WAF / rate-limit rules that target the bot)
curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://www.example.com/page/

# Full response headers — confirm a 503 carries a Retry-After during maintenance
curl -sI https://www.example.com/page/

Windows (PowerShell)

# Status code (note: 5xx throws, so capture the response in the catch block)
try {
  (Invoke-WebRequest -Uri "https://www.example.com/page/" -UseBasicParsing).StatusCode
} catch {
  $_.Exception.Response.StatusCode.value__
}

# As Googlebot
try {
  (Invoke-WebRequest -Uri "https://www.example.com/page/" -UseBasicParsing `
    -UserAgent "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)").StatusCode
} catch { $_.Exception.Response.StatusCode.value__ }

Confirmar que el tráfico era realmente Googlebot antes de confiar en los registros

Un 5xx atribuido a “Googlebot” en los registros puede proceder de un agente de usuario falsificado. Debe verificarse mediante una comprobación DNS inversa y directa; Google no publica ningún atajo.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Modo de mantenimiento correcto: 503 + Retry-After y robots.txt en 200

El punto crítico consiste en servir 503 para el sitio, pero nunca para robots.txt.

Apache (.htaccess)

# Let robots.txt through untouched so crawling isn't halted
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^ /maintenance.html [R=503,L]

# Attach the headers to the 503 response
<If "%{REQUEST_URI} != '/robots.txt'">
  Header always set Retry-After "86400"
</If>
ErrorDocument 503 /maintenance.html

Nginx

location / {
    # robots.txt is matched by a more specific block below, so it's exempt
    return 503;
}

location = /robots.txt {
    # Always serve the real robots.txt with a 200
    try_files $uri =404;
}

error_page 503 /maintenance.html;
location = /maintenance.html { internal; }

# Add Retry-After to 503 responses (a day, in seconds)
add_header Retry-After 86400 always;

La comprobación puede realizarse con curl -sI como en la sección anterior: las URL del sitio deben devolver 503 con un encabezado Retry-After, mientras https://www.example.com/robots.txt debe seguir devolviendo 200.

Herramientas para encontrar y confirmar un 5xx

Conviene empezar con herramientas que comprueben directamente el estado de las URL señaladas y pasar a los registros cuando una sola solicitud no revele la causa.

• Bulk HTTP Status Code Checker — permite pegar todas las URL que Search Console señaló bajo “Server error (5xx)” (hasta 500 a la vez) y ver en ese momento el código, la cadena de redirecciones y la latencia de cada una. Es la forma más rápida de confirmar una corrección antes de seleccionar Validate Fix en GSC o de detectar URL que aún fallan.
• Website Down Checker — comprueba desde un punto de observación en vivo si una URL individual está caída, con tiempo de respuesta y redirecciones. Resulta útil como primer paso del diagnóstico antes de investigar los registros.
• HTTP Header Checker — inspecciona todos los encabezados de respuesta en cada salto de redirección. Permite confirmar que un 503 incluye Retry-After durante el mantenimiento y que robots.txt sigue respondiendo 200 sin quedar atrapado por la regla de mantenimiento.
• Log File Analyzer — analiza un registro de acceso para mostrar desperdicio por código de estado y actividad por bot, además de separar Googlebot verificado de agentes falsificados. Es la herramienta para el caso más difícil: una CDN/WAF o un limitador que devuelve 5xx o 429 solo a Googlebot mientras las personas reciben una respuesta normal, algo que una prueba de navegador no detecta.

De Google y rastreadores de terceros:

• Search Console — Crawl Stats report (Settings → Crawl stats) ofrece la vista general de disponibilidad del host y el desglose por código de respuesta descritos en la pestaña Avanzado.
• Screaming Frog SEO Spider / Ahrefs Site Audit pueden rastrear el sitio de forma similar a Googlebot y mostrar a escala qué URL fallan, más allá de la muestra de Search Console.

Errores que convierten un 5xx corregible en un problema de indexación

• Servir durante el mantenimiento una página 200 “we’ll be back soon” (traducción) «volveremos pronto» en vez de 503. Google considera real cualquier contenido recibido con 200 y puede indexar el mensaje de mantenimiento en lugar del contenido. Debe servirse 503; su contenido se ignora, que es lo deseado.
• Devolver 404, 410 o 403 durante una interrupción planificada. Indican “gone” (traducción) «desaparecido» o “forbidden” (traducción) «prohibido», no indisponibilidad temporal. La guía de Google indica que no debe bloquearse así un sitio en pausa. Un 503 conserva inicialmente la posición de la página en el índice; un 404/410 no.
• Permitir que el modo de mantenimiento también devuelva 503 para robots.txt. Una regla general que responde 503 a todo, incluido robots.txt, pausa el rastreo de todo el sitio, no solo de las páginas desactivadas. El controlador debe excluir robots.txt para que siempre responda 200.
• Suponer que una página que funciona ahora descarta un 5xx anterior exclusivo de Googlebot. Una CDN/WAF o un limitador puede devolver 5xx o 429 solo a Googlebot mientras todas las personas reciben 200, y que funcione en este minuto no demuestra qué devolvió cuando llegó Google. Debe probarse con el agente de usuario de Googlebot, leerse los registros y confirmarse el bot real mediante DNS inverso o intervalos de IP antes de confiar únicamente en el encabezado.
• Mantener durante semanas una ventana de mantenimiento “temporary” (traducción) «temporal». Un 503 solo es correcto para una interrupción breve; Google dice “a few days at most” (traducción) «unos días como máximo». Incluso un 503 técnicamente correcto perjudica la indexación si dura semanas, y Google aclara que no hay un plazo fijo de recuperación ni forma de acelerarla.

Confirmar que la corrección de 5xx se aplicó realmente

Cada prueba siguiente comprueba una afirmación concreta después de que el error del servidor parezca resuelto. Conviene ejecutarlas en orden; las dos primeras detectan la mayoría de los falsos positivos de corrección.

Prueba 1 — Las URL señaladas devuelven 200 en este momento

• Prueba: ejecutar Bulk HTTP Status Code Checker con todas las URL señaladas por Search Console, o usar curl -sI con cada una.
• Resultado esperado: 200 en todas las URL de forma constante en solicitudes repetidas, no intermitente.
• Interpretación del fallo: cualquier URL con 5xx indica que el problema de servidor o host persiste; una mezcla de 200 y 5xx entre repeticiones apunta a un sistema ascendente sobrecargado o inestable.
• Ventana de supervisión: inmediata; una pasada limpia basta para avanzar a Validate Fix.
• Criterio de reversión: cualquier reaparición de 5xx antes de seleccionar Validate Fix exige detenerse y continuar el diagnóstico en vez de validar una corrección inestable.

Prueba 2 — El nuevo rastreo de Google elimina el problema

• Prueba: abrir Server error (5xx) en el informe Indexación de páginas y seleccionar Validate Fix.
• Resultado esperado: el estado pasa a “Validation passed” (traducción) «Validación superada» a medida que Google vuelve a rastrear las URL y confirma 2xx.
• Interpretación del fallo: “Validation failed” (traducción) «Validación fallida» en URL concretas, incluso si las comprobaciones propias fueron correctas, suele indicar fallos específicos de Googlebot y devuelve la investigación a reglas WAF o de tasa dirigidas al bot.
• Ventana de supervisión: Google rastrea el conjunto por lotes según su propia programación y no publica una cadencia fija. Debe revisarse periódicamente en vez de esperar una fecha concreta. La validación ni siquiera es obligatoria: Google actualiza el recuento cuando vuelve a rastrear una página con problemas conocidos, pero Validate Fix prioriza el conjunto y proporciona un estado.
• Criterio de reversión: cualquier URL que vuelva a aparecer bajo Server error (5xx) tras superar la validación.

Prueba 3 — Se recupera la disponibilidad del host en Estadísticas de rastreo

• Prueba: Search Console → Configuración → Estadísticas de rastreo → estado del host.
• Resultado esperado: el gráfico de disponibilidad vuelve a la normalidad sin nuevas alertas rojas en el desglose.
• Interpretación del fallo: si el gráfico sigue en rojo después de la supuesta corrección, los rastreadores de Google aún encuentran errores; la solución no llegó a lo que Googlebot solicita realmente.
• Ventana de supervisión: dejar unos días después de la corrección para que el informe lo refleje; es móvil, no en tiempo real.
• Criterio de reversión: el estado del host vuelve a rojo tras un periodo en verde.

Prueba 4 — robots.txt sigue devolviendo 200

• Prueba: ejecutar curl -sI con la URL de robots.txt o usar HTTP Header Checker.
• Resultado esperado: 200, igual que antes del incidente o la ventana de mantenimiento.
• Interpretación del fallo: un 503 o cualquier respuesta distinta de 200 en robots.txt bloquea el rastreo de todo el sitio, no solo de las URL que se pretendía afectar.
• Ventana de supervisión: inmediata.
• Criterio de reversión: cualquier respuesta distinta de 200 en robots.txt debe tratarse como la máxima prioridad.

Prueba 5 — Googlebot recibe la misma respuesta que un navegador

• Prueba: solicitar la URL con el agente de usuario de Googlebot (véase Scripts) y contrastar el resultado con el informe de Googlebot verificado frente a falsificadores de Log File Analyzer.
• Resultado esperado: Googlebot recibe el mismo 200 que una solicitud normal del navegador.
• Interpretación del fallo: una diferencia entre la solicitud con agente de Googlebot y la normal indica una regla WAF, de limitación o de detección que apunta específicamente al bot.
• Ventana de supervisión: inmediata.
• Criterio de reversión: cualquier diferencia entre lo que recibe Googlebot y el tráfico real.

KPI permanentes de salud del servidor

No son comprobaciones únicas de una corrección —para eso está la pestaña Pruebas de validación—, sino métricas que conviene vigilar trimestre a trimestre para evitar que un patrón 5xx crezca sin detectarse.

Tasa de 5xx en los registros del servidor o acceso

• Qué indica: proporción real de solicitudes que fallan en el servidor, con independencia de lo que Search Console haya llegado a muestrear y comunicar.
• Cómo obtenerla: Log File Analyzer permite cargar el registro de acceso, ver el desperdicio por código de estado y filtrar por Googlebot.
• Referencia o intervalo realista: no existe un porcentaje saludable universal. Debe establecerse una línea base propia durante un periodo sano y vigilar aumentos, no perseguir una meta inventada.
• Cadencia: después de todo despliegue o pico de tráfico; para la mayoría de los sitios basta una revisión semanal.

Estadísticas de rastreo de GSC: estado del host por código de respuesta

• Qué indica: lectura reciente de Google sobre la frecuencia con que sus rastreadores encuentran errores en el host, independientemente de los registros propios.
• Cómo obtenerla: Search Console → Configuración → Estadísticas de rastreo.
• Referencia o intervalo realista: rige la misma honestidad: seguir la tendencia propia en vez de un porcentaje fijo y considerar digna de investigación toda nueva alerta roja, sea cual sea la cifra.
• Cadencia: revisión semanal o inmediata tras una interrupción o ventana de mantenimiento conocida.

Tiempo de actividad o disponibilidad del origen

• Qué indica: si el servidor de origen es accesible, antes de cualquier código que termine viendo Googlebot.
• Cómo obtenerla: un monitor de disponibilidad para cobertura continua o una comprobación puntual con Website Down Checker.
• Referencia o intervalo realista: depende por completo del nivel de alojamiento y de cualquier SLA. No existe una cifra universal que deba copiarse; corresponde usar el SLA propio o el historial como referencia.
• Cadencia: continua cuando sea posible o, como mínimo, después de cualquier incidente conocido.

Recuento de Server error (5xx) en el informe Indexación de páginas

• Qué indica: cuántas URL tiene Google señaladas actualmente como erróneas; es el registro oficial rezagado, frente a la vista en tiempo real del servidor o los registros.
• Cómo obtenerlo: Search Console → Indexación de páginas → Not indexed → Server error (5xx).
• Referencia o intervalo realista: cero es el objetivo honesto para toda URL que deba indexarse. Cualquier cifra superior merece seguir los pasos de diagnóstico de este artículo.
• Cadencia: cada vez que se revise Search Console y siempre después de un incidente o despliegue conocido.

Prompts de IA para diagnosticar 5xx y revisar el modo de mantenimiento

Dos prompts basados en las tareas concretas descritas en el artículo; los datos propios se insertan en cada uno.

Prompt: detectar patrones en líneas de registro sin procesar durante un incidente 5xx

Here are raw server/access log lines from around the time my site started
returning 5xx errors:

<paste log lines>

From only what's in these lines, tell me:
1. Which HTTP status codes appear, and in what proportion.
2. Whether requests from Googlebot's IP ranges or user-agent get a different
   status code than other traffic (this could indicate a WAF or rate limiter
   targeting the bot specifically).
3. Any timing pattern — recurring at a fixed interval, clustered around a
   traffic spike, or starting right after a specific timestamp.

Don't guess at a root cause you can't see in the data — only report what the
log lines actually show.

Prompt: revisar una configuración de modo de mantenimiento para detectar la trampa de robots.txt

Here is my maintenance-mode configuration (nginx/Apache/other):

<paste config>

Check specifically whether this configuration:
1. Returns a 503 status code for regular site pages during maintenance.
2. Excludes /robots.txt from the 503 rule, so robots.txt keeps returning 200.
3. Sets a Retry-After header on the 503 responses.

Flag anything that would cause robots.txt to return a non-200 status, and
anything missing a Retry-After header.

Autoevaluación: Error del servidor (5xx)

Cinco preguntas sobre el significado de “Server error (5xx)”, la reacción de Google y la forma correcta de desactivar deliberadamente un sitio. Debe elegirse una respuesta para cada una y después comprobarla.

Registro de cambios