Cómo migrar un sitio a una CDN sin saturar el servidor de origen

Migrar un sitio a una red de distribución de contenidos (CDN) puede aumentar temporalmente el tráfico que llega al servidor de origen, incluso cuando el objetivo es reducirlo. Google explicó que el motivo suele estar en las cachés vacías de la CDN y advirtió que las reglas generales contra bots pueden bloquear a Googlebot y afectar la presencia de las páginas en sus resultados.

Migrar un sitio a una CDN no garantiza que el servidor de origen quede protegido desde el primer minuto. Durante la transición, las visitas de usuarios y los rastreos automatizados pueden seguir llegando al backend original mientras los servidores periféricos construyen sus cachés.

El tema fue explicado por Google en una publicación de su blog para desarrolladores, dedicada al rastreo de sitios durante una migración a una CDN. La advertencia está dirigida especialmente a administradores que observan un aumento inesperado de solicitudes poco después de modificar el DNS.

Por qué una CDN puede elevar el tráfico al origen

Una CDN distribuye archivos y respuestas desde servidores ubicados cerca de los usuarios. Cuando el DNS empieza a dirigir el tráfico hacia esa red, los sistemas de rastreo pueden percibir que el sitio responde más rápido. Según Google, esa mejora puede hacer que sus rastreadores aumenten gradualmente la frecuencia de solicitudes de acuerdo con la capacidad estimada del sitio, conocida en la publicación como hostload.

El problema aparece cuando la CDN todavía no tiene copias almacenadas. La primera solicitud de una URL en una ubicación periférica produce un fallo de caché: el servidor de la CDN debe pedir el recurso al origen, recibirlo, guardarlo si corresponde y entregarlo al cliente. Las solicitudes posteriores de esa misma URL pueden resolverse desde la periferia.

Las cachés vacías dejan expuesto al servidor de origen

Durante el calentamiento de la caché, la CDN todavía no funciona como una barrera completa. El servidor de origen sigue procesando las solicitudes que no tienen una copia disponible en los nodos periféricos. Esto puede incluir documentos HTML, hojas de estilo, archivos JavaScript e imágenes.

Los usuarios suelen concentrarse en un conjunto limitado de páginas, como la portada, los artículos más visitados o una promoción activa. Los rastreadores, en cambio, recorren una parte mucho más amplia del inventario de URLs. Por eso, el tráfico automatizado puede mantener una presión significativa sobre el origen aunque las páginas más populares ya estén almacenadas en la CDN.

Google también señala que los rastreadores no necesariamente aumentan su ritmo de manera instantánea y que algunas CDN incorporan mecanismos para regular las conexiones. Aun así, la etapa inicial requiere observar el comportamiento del origen antes de asumir que la migración ya absorbió todo el tráfico.

El riesgo de activar una protección general contra bots

Un aumento de solicitudes en los registros puede llevar a activar una regla amplia de protección contra bots o del firewall de aplicaciones web (WAF). Sin excepciones, esas reglas tratan de la misma manera a los rastreadores legítimos y al tráfico automatizado malicioso.

Si la CDN o el WAF presenta un CAPTCHA, un desafío de JavaScript o una página de bloqueo, Googlebot puede no completar el acceso al contenido. Para el buscador, el sitio puede parecer restringido o presentar errores, aunque el problema se origine en una configuración de seguridad aplicada durante la migración.

La consecuencia posible es que Google reduzca el rastreo. Si la restricción se mantiene, algunas páginas, fichas de productos u otros contenidos que dependen del rastreo pueden perder visibilidad en los resultados de Google. Esta explicación corresponde al escenario descrito por la empresa y no implica que toda caída de tráfico después de una migración tenga esa causa.

Qué deberían controlar los equipos durante la migración

El dato más importante es la diferencia entre el tráfico que llega a la CDN y el que la CDN reenvía al origen. Un aumento de solicitudes en la periferia no necesariamente equivale a un aumento igual en el backend: la proporción depende de cuántas respuestas ya fueron almacenadas y de las reglas de caché configuradas.

Durante las primeras horas o días, según el tamaño y la variedad del sitio, los equipos deberían revisar los registros del origen, los códigos de respuesta y el estado de las cachés. También resulta necesario comprobar que los contenidos que deben rastrearse sigan entregándose sin desafíos incompatibles con los robots de búsqueda.

La publicación de Google no aporta una duración universal para el calentamiento ni una configuración única para todas las CDN. La capacidad del origen, la distribución geográfica de las visitas, la cantidad de URLs y las políticas de almacenamiento determinan el comportamiento de cada migración.

Cómo evitar que Googlebot quede bloqueado

La protección contra tráfico automatizado no debería configurarse como un bloqueo indiscriminado. Las reglas deben distinguir entre solicitudes sospechosas y rastreadores que el sitio necesita atender, además de conservar una validación adecuada para evitar que cualquier actor pueda hacerse pasar por Googlebot.

También es importante probar el acceso a páginas representativas antes y después del cambio de DNS. La revisión debe contemplar la portada, páginas de contenido, recursos necesarios para renderizar el sitio y, si corresponde, fichas de productos. Un servidor que responde rápido a un usuario puede seguir fallando ante una URL que no está disponible en la caché.

Qué cambia para sitios con muchas páginas

El riesgo operativo es mayor cuando el sitio tiene un inventario amplio y poco tráfico concentrado en cada URL. En esos casos, los usuarios pueden calentar rápidamente unas pocas páginas, mientras que los rastreadores continúan solicitando recursos distribuidos por todo el dominio.

Para empresas con catálogos, medios digitales o plataformas con numerosos documentos, la migración debe contemplar la capacidad del origen durante la etapa de caché fría. La CDN puede reducir la carga una vez que las respuestas se almacenan, pero no elimina automáticamente las necesidades de procesamiento del backend durante el cambio.

La explicación completa forma parte de la serie audiovisual de Google The Non-Canonical Cabinet, mencionada en la fuente original. El contenido combina la explicación técnica con recursos humorísticos, pero la advertencia operativa es concreta: una CDN recién activada todavía puede reenviar muchas solicitudes al servidor principal y una defensa mal configurada puede impedir el rastreo.

La migración a una CDN también requiere revisar el rastreo

El cambio de DNS no termina cuando el tráfico empieza a pasar por la CDN. La etapa crítica consiste en comprobar que la red periférica absorba progresivamente las solicitudes, que el origen soporte los fallos de caché y que las medidas de seguridad no interrumpan el acceso de los rastreadores autorizados.

Para el lector responsable de un sitio, la señal más útil no es un único pico en los gráficos, sino la relación entre solicitudes al origen, aciertos de caché, errores y respuestas entregadas a Googlebot. Esa lectura permite diferenciar un calentamiento transitorio de una configuración que está bloqueando contenidos o sobrecargando el backend.