Una CDN recién activada puede acelerar las respuestas y, aun así, dejar al servidor de origen frente a un pico de peticiones. Google explica el motivo: la caché empieza vacía y la primera solicitud de cada URL que no está almacenada debe volver al origen. Si Googlebot observa respuestas rápidas en el nuevo borde, también puede aumentar gradualmente el ritmo de rastreo cuando haya demanda.
El objetivo de esta guía es hacer una migración gradual: preparar las URL prioritarias, precalentar la caché a un ritmo medido y tener un freno temporal listo. Los ejemplos usan Python y Nginx; la configuración concreta de la CDN dependerá del proveedor.
flowchart TD A["Elegir URL prioritarias"] --> B["Precalentar CDN con pausas"] B --> C["Verificar respuestas y carga"] C --> D["Dirigir tráfico a la CDN"] D --> E["Vigilar origen y rastreo"] E --> F["Aplicar freno temporal si hace falta"]
1. Prepara una lista acotada de URL
No empieces intentando recorrer todo el sitio. Google recomienda solicitar de forma programática las páginas con más tráfico, las que podrían recibir un pico próximo y las URL que se rastrean con frecuencia. El primer paso es guardar esas direcciones en un archivo, una por línea. Usa aquí el dominio público que ya sirve la CDN; así las solicitudes pasarán por el borde y podrán llenar su caché.
https://www.example.com/
https://www.example.com/noticias/
https://www.example.com/productos/ejemplo/
https://www.example.com/ayuda/Es una selección deliberada, no un listado generado a partir de todas las combinaciones posibles de parámetros. Google advierte que ciertas estructuras de URL, como la navegación por facetas o calendarios con muchas direcciones, pueden contribuir a un aumento brusco del rastreo.
2. Precalienta a un ritmo controlado
Este script de Python estándar lee la lista y visita cada dirección en orden, con una pausa entre solicitudes. No crea concurrencia ni reintenta en bucle: si una petición falla, lo deja registrado y continúa. Ajusta la pausa con cautela y ejecútalo primero sobre una lista pequeña mientras observas el origen.
#!/usr/bin/env python3
"""Solicita URL públicas para precalentar la caché de una CDN."""
import sys
import time
from urllib.error import HTTPError, URLError
from urllib.request import Request, urlopen
URL_FILE = "urls.txt"
PAUSE_SECONDS = 1.0
TIMEOUT_SECONDS = 15
with open(URL_FILE, encoding="utf-8") as file:
urls = [line.strip() for line in file if line.strip()]
for url in urls:
request = Request(url, headers={"User-Agent": "CacheWarmer/1.0"})
try:
with urlopen(request, timeout=TIMEOUT_SECONDS) as response:
print(f"{response.status} {url}")
except HTTPError as error:
print(f"HTTP {error.code} {url}", file=sys.stderr)
except (URLError, TimeoutError) as error:
print(f"ERROR {url}: {error}", file=sys.stderr)
time.sleep(PAUSE_SECONDS)La pausa no garantiza una carga segura por sí sola: el coste depende de lo que haga el origen al producir cada respuesta. Si ves que sube la latencia o aparecen errores, detén el proceso y reduce el ritmo. Una URL repetida solo ayudará si la CDN la puede almacenar y si las solicitudes llegan a una ubicación de borde que aún no tiene esa copia.
3. Pon un límite de emergencia en Nginx
En el origen, Nginx puede limitar la tasa de solicitudes por dirección IP. Este ejemplo es una configuración mínima completa: guarda la zona de límite en el contexto http y aplica la regla al servidor. La directiva limit_req puede devolver una respuesta de rechazo cuando se excede el límite; aquí se indica el código 429.
events {
worker_connections 1024;
}
http {
limit_req_zone $binary_remote_addr zone=per_ip:10m rate=5r/s;
server {
listen 8080;
server_name _;
location / {
limit_req zone=per_ip burst=10 nodelay;
limit_req_status 429;
return 200 "Origen disponible\n";
}
}
}Los valores son un punto de partida ilustrativo, no una cifra recomendada para cualquier web. Antes de ponerlo en producción, valida la configuración con nginx -t y ajústala al patrón real de tráfico y a la capacidad del origen. Si la CDN comparte una dirección de salida para muchas visitas, limitar por IP en el origen puede agrupar usuarios distintos; revisa cómo llega la dirección del cliente antes de basar la regla en ella.
No bloquees todos los bots como respuesta automática a un pico. Google advierte que los desafíos CAPTCHA o las reglas indiscriminadas pueden impedir que los rastreadores verificados accedan al sitio. Configura la excepción en la CDN o el firewall cuando el producto lo permita, y filtra selectivamente el tráfico no deseado.
4. Comprueba el comportamiento antes de abrir el tráfico
Verifica que el dominio público responde y que el origen no empieza a degradarse mientras precalientas. Este comando muestra el código HTTP y el tiempo total de la solicitud con curl. Repítelo para las URL prioritarias y compáralo con las métricas del servidor; una respuesta correcta desde el borde no demuestra por sí sola que el origen esté descargado.
#!/usr/bin/env bash
set -eu
while IFS= read -r url; do
[ -n "$url" ] || continue
curl --silent --show-error --output /dev/null \
--write-out '%{http_code} %{time_total}s ' "$url"
printf '%s\n' "$url"
done < urls.txtHaz la comprobación primero con pocas direcciones. Cuando las respuestas sean correctas y la carga del origen se mantenga dentro de lo que tu servicio puede soportar, amplía la lista o dirige más tráfico a la CDN. Google señala que sus rastreadores no aumentan el ritmo de golpe y que algunas CDN aplican controles de conexión, pero la caché fría sigue dejando peticiones iniciales en el origen.
5. Si el origen sufre, frena por poco tiempo
Si el volumen sigue poniendo en riesgo el servicio, Google recomienda devolver temporalmente HTTP 429 (Too Many Requests) o 503 (Service Unavailable) para reducir la frecuencia de rastreo. La guía de Google indica que estas respuestas deben ser una medida breve: unas horas o, como máximo, uno o dos días. Al usar 429 o 503, se puede añadir Retry-After para comunicar cuándo volver a intentar la solicitud.
No conviertas ese freno en un bloqueo permanente ni sustituyas una respuesta de sobrecarga por una página de desafío para todos los automatismos. Supervisa los registros y la salud del servidor mientras dura la medida. Google indica que reduce el rastreo ante un número significativo de respuestas 429, 503 o 500 y que lo aumenta automáticamente cuando esos errores disminuyen.
Errores que conviene evitar
Una caché fría no protege frente a la primera solicitud de cada URL única: esa petición aún puede llegar hasta el origen. Precalienta las páginas elegidas antes de enviar todo el tráfico y no interpretes el primer pico como prueba automática de un ataque.
También evita activar protección general contra bots sin excepciones para los rastreadores verificados, y no uses el límite de Nginx como si conocieras de antemano el tráfico real o la dirección IP que verá el servidor tras la CDN. Si Googlebot incrementa el rastreo, comprueba los registros para identificar el tráfico; la guía de Google también recomienda revisar las URL y la estructura del sitio cuando el aumento sea brusco.
La secuencia práctica es sencilla: lista pequeña, precalentamiento pausado, comprobación del origen y apertura gradual. Si la carga se dispara, aplica un límite temporal y conserva el acceso de los rastreadores verificados.
Fuentes: Search Engine Roundtable, Google for Developers, Google for Developers, Google for Developers
