Un sitio que devuelve errores de servidor de forma intermitente no solo pierde visitas de usuarios reales durante el tiempo que dura el fallo: modifica, de forma medible y con efectos que persisten después de resolver el problema, la manera en que Google rastrea ese dominio. Esta guía va sobre ese impacto técnico concreto, distinto de la disponibilidad percibida por un usuario: qué pasa exactamente cuando Googlebot encuentra una caída, cómo se recupera la confianza y qué diferencia hay, a nivel de algoritmo de rastreo, entre una caída puntual y una inestabilidad sostenida.
Qué hace Googlebot cuando encuentra errores 5xx
Cuando Googlebot recibe un código de respuesta 5xx (error de servidor) al intentar rastrear una URL, no lo interpreta como un fallo aislado de esa página concreta sino como una señal sobre la salud general del servidor que la sirve. Si el volumen de errores 5xx sube por encima de lo habitual para ese dominio, el sistema de gestión de crawl rate reduce automáticamente la velocidad de rastreo, en la práctica dando al servidor "más margen" asumiendo que está sobrecargado o inestable. Es una respuesta defensiva pensada para no empeorar un problema de infraestructura ya existente, pero tiene un coste: menos rastreo significa que el contenido nuevo o modificado tarda más en descubrirse y actualizarse en el índice mientras dure esa reducción.
El caso especial de robots.txt caído
Existe un comportamiento específico y bien documentado por Google para el propio fichero robots.txt: si al intentar consultarlo Googlebot recibe un error de servidor de forma sostenida, durante más de 12 horas, el sistema pasa a asumir que el sitio entero está bloqueado para rastreo, por precaución, hasta que robots.txt vuelva a responder con normalidad. Es un matiz que sorprende a muchos equipos técnicos: no hace falta que el sitio entero esté caído para perder rastreo por completo, basta con que el fichero robots.txt en concreto no responda de forma fiable durante ese margen de horas, aunque el resto del sitio siga funcionando con normalidad.
Caída corta frente a inestabilidad sostenida: no es el mismo impacto
Google distingue, en la práctica de cómo reacciona su sistema, entre una interrupción puntual de pocas horas y un patrón de inestabilidad que se repite durante días o semanas. Una caída corta y aislada, sobre todo si el sitio tiene un historial de estabilidad previo, normalmente se absorbe sin consecuencias duraderas: Google puede reintentar más tarde y el crawl rate se recupera con rapidez una vez el servidor vuelve a responder con normalidad. El problema real aparece con la inestabilidad sostenida: fallos intermitentes que se repiten a lo largo de varios días, incluso si cada fallo individual dura poco, porque el sistema empieza a tratar la inestabilidad como una característica del sitio, no como un incidente puntual, y ajusta el crawl rate a la baja de forma más persistente. La recuperación de la confianza en ese escenario no es inmediata en cuanto el problema se soluciona: Google necesita observar un periodo sostenido de respuestas normales antes de volver a subir el ritmo de rastreo al nivel previo, así que un problema resuelto hoy puede seguir teniendo eco en el rastreo durante días o semanas.
Por qué Search Console no es una herramienta de monitorización en tiempo real
El informe de estadísticas de rastreo (Crawl Stats) de Search Console muestra datos agregados con retraso, normalmente de uno a varios días, y está pensado para revisar tendencias, no para detectar una caída mientras está ocurriendo. Confiar solo en ese informe para enterarse de una caída del servidor significa, en la práctica, enterarse cuando ya ha pasado el tiempo suficiente para que el problema haya tenido impacto real en usuarios y en el rastreo, sin ninguna posibilidad de reaccionar mientras el incidente estaba activo.
La monitorización de uptime real es una categoría de herramienta distinta y complementaria: un servicio que hace peticiones sintéticas periódicas (cada uno a cinco minutos, típicamente) desde varias ubicaciones geográficas, y avisa de inmediato (correo, SMS, notificación push) en cuanto detecta una respuesta de error o un tiempo de espera agotado. La diferencia práctica es la de horas de reacción: con monitorización real se puede intervenir mientras el incidente está ocurriendo; revisando solo Search Console después, el margen de reacción ya se ha perdido.
Comprobación mínima recomendada para un sitio de negocio pequeño:
- Frecuencia: cada 5 minutos
- Desde al menos 2-3 ubicaciones geográficas distintas
(para descartar que un fallo puntual sea solo cuestión de una ruta de red)
- Alerta inmediata (no diaria ni semanal) ante código de error o timeout
- Comprobación del código de estado HTTP real, no solo de si "carga algo"
(una página de error genérica devuelta como 200 pasa desapercibida
para una comprobación que solo mira si hay respuesta)Factores de hosting que determinan la fiabilidad real
La estabilidad de un sitio depende en gran medida de dónde vive, y no todos los tipos de hosting ofrecen las mismas garantías. En hosting compartido (varios sitios de distintos clientes en el mismo servidor físico, con recursos de CPU y memoria compartidos entre todos), un pico de tráfico o un proceso pesado de otro cliente en el mismo servidor puede degradar el rendimiento o provocar errores en un sitio que, por sí mismo, no ha cambiado nada: es el fenómeno conocido como "ruido de vecino" (noisy neighbor), y es una de las causas de inestabilidad intermitente más difíciles de diagnosticar desde fuera, porque los síntomas aparecen y desaparecen sin relación aparente con nada que el propio sitio haya hecho.
Para sitios con tráfico relevante o con una dependencia de negocio real en la disponibilidad, disponer de una página de estado (status page) pública, donde se comunican incidencias activas y su resolución, no evita la caída en sí pero reduce el coste reputacional: comunicar de forma proactiva que existe un problema conocido y en qué punto está su solución genera más confianza que el silencio, tanto de cara a usuarios reales como de cara a la propia gestión interna del incidente.
Preguntas frecuentes
¿Cuánto tiempo de caída empieza a afectar de verdad al rastreo?
No hay un umbral público exacto, pero el caso documentado con más claridad es el de robots.txt: más de 12 horas sin respuesta válida hace que Google asuma bloqueo total del sitio. Para el resto de errores 5xx, el efecto es progresivo: cuanto mayor es el volumen y la duración de los errores, mayor es la reducción del crawl rate y más tiempo tarda en recuperarse después.
¿Basta con revisar Search Console cada semana para detectar problemas de disponibilidad?
No para detectar el incidente mientras ocurre: Search Console muestra datos agregados con varios días de retraso, útil para confirmar el impacto a posteriori pero inútil para reaccionar durante la caída. Para eso hace falta monitorización de uptime dedicada con alertas inmediatas.
¿Migrar a un hosting más caro garantiza mejor disponibilidad?
No de forma automática: lo que determina la fiabilidad no es solo el precio sino el nivel de aislamiento de recursos (si el plan reserva CPU y memoria dedicada o las comparte con otros clientes), la existencia de redundancia real, y el soporte técnico disponible ante un incidente. Conviene revisar esas características concretas, no solo la etiqueta comercial del plan.
¿Un solo error 500 aislado, visto una vez, es motivo de preocupación?
En la inmensa mayoría de casos, no: un error puntual y aislado, sin repetición, se absorbe sin consecuencias duraderas en el rastreo. Es la repetición y la persistencia en el tiempo, no un incidente único, lo que hace que el sistema de rastreo empiece a tratarlo como una característica del sitio en vez de como una anomalía pasajera.