¿El downtime perjudica el SEO? Qué le pasa realmente al ranking

¿El downtime perjudica el SEO? Una caída corta casi nunca, pero un downtime que dura días puede reducir la frecuencia con la que Google rastrea el sitio y, con el tiempo, sacar páginas del índice. Lo que decide el resultado es cuánto tiempo está el sitio sin servicio y qué código de estado HTTP devuelve mientras tanto.

En una agencia, arreglar la caída suele ser trabajo de otro: el hosting, el desarrollador del cliente o su equipo de IT. Darse cuenta sí es cosa tuya. Un sitio al que Googlebot no llega no puede mantener sus posiciones, y el cliente va a preguntar por qué nadie lo vio.

Qué dice la documentación de Google

La página de Google sobre cómo afectan los códigos de estado HTTP al rastreo es bastante clara. Los errores de servidor 5xx y el 429 Too Many Requests hacen que Googlebot rastree el sitio más despacio. Las URLs que ya están indexadas se conservan durante un tiempo, pero si los errores continúan acaban eliminándose. Los timeouts y las conexiones rechazadas se tratan de forma muy parecida a los errores de servidor.

Para una indisponibilidad planificada o temporal, la respuesta recomendada es 503 Service Unavailable. Le dice a los rastreadores que el problema debería pasar. Una cabecera Retry-After añade cuándo volver, por ejemplo Retry-After: 3600 para una hora.

Hay un detalle que se pasa por alto con facilidad. Si el propio robots.txt devuelve un error de servidor, la documentación de Google sobre robots.txt indica que deja de rastrear el sitio, y si el error se prolonga mucho recurre a la última copia del archivo que tiene en caché. Una caída que tumba todo el host se lleva el robots.txt por delante.

Cuánto downtime perjudica el SEO

Google no publica ningún umbral, así que toma estas franjas como una orientación y no como reglas.

Duración de la caída	Qué suele pasar
Unos minutos	Puede que Googlebot ni siquiera pida nada. Si lo hace, reintenta más tarde. Sin efecto medible en el ranking.
Unas horas	El rastreo se ralentiza. Las páginas siguen indexadas y, con un 503 limpio, el sitio se recupera cuando vuelve a estar estable.
Uno o más días de 5xx	Baja la frecuencia de rastreo y algunas URLs pueden salir del índice. La mayoría vuelve tras la recuperación, no siempre en la misma posición.
Caídas cortas frecuentes	Cada una es menor, pero un hosting que falla una y otra vez puede mantener a Googlebot rastreando con cautela.

Por qué el código de estado importa tanto como la duración

Dos sitios caídos durante las mismas cuatro horas pueden salir de ello de forma distinta.

El primero devuelve 503 con Retry-After desde su modo mantenimiento. Google lo interpreta como algo temporal y espera. El segundo muestra una página amable de "Volvemos enseguida" con un 200 OK. Para Googlebot es una página real cuyo contenido se ha sustituido por una frase, y si la rastrea en ese estado, el texto de mantenimiento puede acabar en el snippet de búsqueda hasta que vuelva el contenido real.

Un 500 Internal Server Error o un timeout quedan a medio camino. No se indexan como contenido, pero tampoco transmiten la señal de "esto es temporal".

WordPress lo hace bien por defecto. Durante las actualizaciones del núcleo y de los plugins crea un archivo .maintenance y sirve el mensaje "Briefly unavailable for scheduled maintenance" con un estado 503. Los plugins de terceros de "próximamente" y mantenimiento no se comportan todos igual, así que comprueba cuál usa el sitio del cliente antes de una caída planificada.

Dónde se ve el daño en Search Console

Si sospechas que una caída ya ha afectado a un cliente, hay dos informes que ayudan. El informe Estadísticas de rastreo, dentro de Ajustes, tiene una sección Estado del host que cubre la obtención de robots.txt, la resolución DNS y la conectividad del servidor en los últimos 90 días, además de un desglose de las solicitudes de rastreo por código de respuesta. El informe Indexación de páginas agrupa bajo "Error de servidor (5xx)" las URLs que Google no pudo obtener.

Los dos miran hacia atrás. Explican lo que pasó la semana pasada, lo cual sirve para el informe al cliente pero no para evitarlo. Hay otro fallo de infraestructura que para los visitantes se parece mucho a una caída, y lo tratamos en la monitorización de caducidad del certificado SSL.

Enterarte mientras todavía está pasando

Imagina la versión cara. El sitio de un cliente se cae un viernes por la noche, nadie está mirando, Googlebot y los clientes se encuentran errores todo el fin de semana y te enteras el lunes. Si es un ecommerce, las ventas perdidas del fin de semana pueden pesar más que cualquier bajada de posiciones, y eres tú quien tiene que explicar las dos cosas. Revisar a mano 5 o 50 sitios de clientes no es realista, así que la solución viable es un monitor que avise cuando algo falla. Nuestra comparativa alternativa a UptimeRobot repasa las opciones.

La monitorización de uptime de Deltio te avisa por Slack y email, sitio a sitio, cuando el sitio de un cliente se cae. También detecta cuándo una página se ha sustituido por una página de mantenimiento, que es justo el caso del "volvemos enseguida" con 200 OK que un check básico de arriba/abajo da por bueno. Y como la misma cuenta compara a diario noindex, robots.txt y las URLs del sitemap, también ves si un sitio vuelve de un incidente con la configuración SEO cambiada.

No analiza el crawl budget ni lee los logs del servidor. Para eso sigues necesitando Search Console y los logs de acceso del hosting. Cómo encajan uptime e indexabilidad lo explicamos en uptime y monitorización SEO.