Por qué Googlebot puede rastrear más al pasar una web a un CDN

Pasar una web a un CDN suele aliviar al servidor, pero los primeros días puede pasar lo contrario: el rastreo de Google se dispara y las peticiones siguen llegando al servidor de origen. Gary Illyes y Cherry Prommawin, de Google, lo explican en el blog de Search Central el 11 de noviembre de 2026. Detrás hay dos causas que se suman: Google interpreta las respuestas rápidas del CDN como una mejora del servidor, y la caché del CDN empieza vacía.

Las respuestas rápidas pueden aumentar el ritmo de rastreo

Google ajusta el ritmo de rastreo de cada sitio con lo que llama límite de capacidad de rastreo (hostload). Si el servidor tarda cada vez más en responder, sus rastreadores frenan para no tumbarlo. Si responde rápido y de forma estable, Google lo toma como señal de que aguanta más y, siempre que haya demanda de rastreo, sube el límite poco a poco.

Cuando el DNS pasa a apuntar al CDN, los tiempos de conexión y de respuesta caen de golpe. Para los sistemas de Google es como si el servidor hubiera estrenado hardware, y los rastreadores aceleran.

Con la caché vacía, cada URL nueva llega al origen

Un CDN recién puesto tiene la caché fría. La primera vez que alguien pide una URL en un nodo, el CDN no tiene copia (sea el HTML, el CSS, el JavaScript o una imagen): es un fallo de caché, y el nodo tiene que ir a buscarla al servidor de origen, servirla y guardarla si la respuesta admite caché. Las peticiones siguientes pueden salir del CDN mientras esa copia siga vigente.

Los usuarios se concentran en pocas páginas (la portada, los artículos más leídos, las promociones), que entran en caché enseguida. Los rastreadores hacen lo contrario: recorren todo el inventario de URL. Así que, mientras Google sube el ritmo por las respuestas rápidas, cada URL que todavía no está en caché atraviesa el CDN y acaba en el servidor de origen. Google precisa que sus rastreadores no aceleran de un momento a otro y que muchos CDN ya dosifican las conexiones, pero hasta que la caché se llena el CDN no hace de escudo.

Bloquear todos los bots puede sacarte de Google

Ver en los logs una avalancha de peticiones automáticas justo después del cambio asusta, y la reacción típica es activar en el panel del CDN la protección contra bots para todo el tráfico automatizado. Si esa regla no tiene excepciones, el CDN o el WAF (el cortafuegos de aplicaciones web) también intercepta a los rastreadores de Google con un CAPTCHA, que no pueden resolver.

Lo que recibe Google entonces es un 403 o una página de comprobación. Illyes añade que, aunque esa página se sirva con un código 200, los rastreadores no tienen forma de saber que es un control de seguridad: para Google, el sitio parece roto o restringido a propósito. Si la regla se queda puesta, los rastreadores reducen la actividad y las páginas empiezan a caer del índice, igual que los productos de Google Shopping. Google advierte de que también dejan de funcionar los productos de anuncios que dependen del rastreo.

Cómo pasar a un CDN sin saturar el origen

Las recomendaciones de Google para el cambio son estas:

• Deja pasar a los bots verificados. La mayoría de CDN y WAF tienen una opción o una regla gestionada para permitir los bots conocidos y verificados, que se saltan el CAPTCHA mientras el resto del tráfico sigue filtrado. Los rastreadores de Google se identifican con sus rangos de IP publicados. Mejor aún: bloquea solo los bots que no quieras, con el robots.txt o con reglas concretas, en vez de bloquear todo lo automatizado.
• Precalienta la caché. Antes de mandar todo el tráfico al CDN, pide a través de él, a un ritmo controlado, las páginas con más tráfico, las de los próximos picos (lanzamientos o campañas de temporada) y las URL que más rastrea Google.
• Usa un 429 o un 503 como freno temporal. Si aun así el origen no aguanta mientras se llena la caché, configura el servidor o el CDN para devolver esos códigos durante unas horas, uno o dos días como mucho.

Ese freno está documentado en la guía para reducir con urgencia la frecuencia de rastreo, que admite también el 500. Con muchas URL respondiendo así, Google baja el ritmo en todo el nombre de host, también en las URL que sí devuelven contenido, y lo recupera solo cuando los errores desaparecen. Con un 503 o un 429 se puede añadir la cabecera Retry-After para indicar cuándo volver. La guía avisa del precio: Google descubre menos páginas nuevas, actualiza más tarde las existentes (precios y disponibilidad incluidos) y, si la misma URL devuelve esos códigos durante varios días, puede sacarla del índice. Si no es posible servir errores, queda el formulario para pedir que se reduzca la frecuencia de rastreo, que tarda días.

Antes de cambiar el DNS, mira tus logs

Nuestra lectura: nada de esto cambia cómo rastrea Google. Lo útil es que explica un síntoma que confunde, el de un pico de rastreo justo al poner el CDN, y que lo hace con la regla del límite de capacidad, que ya estaba documentada. Por eso no conviene leer ese pico como un ataque.

Qué hacer en una migración a CDN:

• Saca de los logs del servidor las URL que más pide Googlebot y úsalas para precalentar la caché. Las de mayor tráfico salen de la analítica.
• Antes de activar cualquier regla anti-bots, comprueba que tiene la excepción para bots verificados. Tras el cambio, pasa la prueba en directo de la inspección de URLs de Search Console: un CAPTCHA o un 403 indica un bloqueo para la herramienta de inspección. Contrasta ese resultado con los logs de peticiones de Googlebot verificado, porque la prueba en directo utiliza Google-InspectionTool.
• Vigila los días siguientes el informe de estadísticas de rastreo de Search Console. Lo esperable es que baje el tiempo medio de respuesta y suban las peticiones. Si el origen no aguanta, el freno es un 429 o un 503 durante horas, no un bloqueo.