Una CDN appena attivata può accelerare le risposte e, allo stesso tempo, esporre il server di origine a un picco di richieste. Google spiega il motivo: la cache è inizialmente vuota e la prima richiesta per ogni URL non memorizzato deve raggiungere nuovamente l'origine. Se Googlebot osserva risposte rapide sul nuovo edge, può anche aumentare gradualmente la frequenza di scansione quando c'è domanda.
L'obiettivo di questa guida è effettuare una migrazione graduale: preparare gli URL prioritari, preriscaldare la cache a un ritmo controllato e tenere pronto un freno temporaneo. Gli esempi usano Python e Nginx; la configurazione specifica della CDN dipenderà dal provider.
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 un elenco circoscritto di URL
Non iniziare cercando di scansionare l'intero sito. Google consiglia di richiedere in modo programmatico le pagine con più traffico, quelle che potrebbero ricevere a breve un picco e gli URL scansionati frequentemente. Il primo passaggio consiste nel salvare questi indirizzi in un file, uno per riga. Usa qui il dominio pubblico già servito dalla CDN: in questo modo le richieste passeranno dall'edge e potranno riempirne la cache.
https://www.example.com/
https://www.example.com/noticias/
https://www.example.com/productos/ejemplo/
https://www.example.com/ayuda/Si tratta di una selezione intenzionale, non di un elenco generato a partire da tutte le possibili combinazioni di parametri. Google avverte che alcune strutture di URL, come la navigazione a faccette o i calendari con molti indirizzi, possono contribuire a un brusco aumento della scansione.
2. Preriscalda a un ritmo controllato
Questo script Python standard legge l'elenco e visita ogni indirizzo in ordine, con una pausa tra le richieste. Non crea concorrenza e non riprova in un ciclo: se una richiesta fallisce, lo registra e prosegue. Imposta la pausa con cautela ed esegui prima lo script su un elenco ridotto, monitorando il server di origine.
#!/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, da sola, non garantisce un carico sicuro: il costo dipende da ciò che fa il server di origine per produrre ogni risposta. Se noti un aumento della latenza o la comparsa di errori, interrompi il processo e riduci il ritmo. Ripetere un URL sarà utile solo se la CDN può memorizzarlo e se le richieste raggiungono una posizione edge che non possiede ancora quella copia.
3. Imposta un limite di emergenza in Nginx
Sul server di origine, Nginx può limitare la frequenza delle richieste per indirizzo IP. Questo esempio è una configurazione minima completa: memorizza la zona di limitazione nel contesto http e applica la regola al server. La direttiva limit_req può restituire una risposta di rifiuto quando viene superato il limite; qui è indicato il codice 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";
}
}
}Questi valori sono un punto di partenza a scopo illustrativo, non una cifra consigliata per qualsiasi sito web. Prima di metterla in produzione, convalida la configurazione con nginx -t e adattala al modello di traffico effettivo e alla capacità del server di origine. Se la CDN condivide un indirizzo di uscita tra molte visite, limitare per IP sul server di origine può raggruppare utenti diversi; verifica come viene trasmesso l'indirizzo del client prima di basarvi la regola.
Non bloccare tutti i bot come risposta automatica a un picco. Google avverte che le CAPTCHA o le regole indiscriminate possono impedire ai crawler verificati di accedere al sito. Configura un'eccezione nella CDN o nel firewall, se il prodotto lo consente, e filtra selettivamente il traffico indesiderato.
4. Verifica il comportamento prima di aprire il traffico
Verifica che il dominio pubblico risponda e che il server di origine non inizi a degradarsi durante il preriscaldamento. Questo comando mostra il codice HTTP e il tempo totale della richiesta con curl. Ripetilo per gli URL prioritari e confronta i risultati con le metriche del server; una risposta corretta dall'edge non dimostra, da sola, che il carico sul server di origine sia diminuito.
#!/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.txtEsegui prima la verifica su pochi indirizzi. Quando le risposte sono corrette e il carico sul server di origine rimane entro i limiti che il servizio può sostenere, amplia l'elenco o indirizza più traffico verso la CDN. Google osserva che i suoi crawler non aumentano la frequenza all'improvviso e che alcune CDN applicano controlli sulle connessioni, ma una cache fredda continua a lasciare le richieste iniziali sul server di origine.
5. Se il server di origine è sotto pressione, rallenta per poco tempo
Se il volume continua a mettere a rischio il servizio, Google consiglia di restituire temporaneamente HTTP 429 (Too Many Requests) o 503 (Service Unavailable) per ridurre la frequenza di scansione. La guida di Google indica che queste risposte devono essere una misura di breve durata: alcune ore o, al massimo, uno o due giorni. Quando si usa 429 o 503, è possibile aggiungere Retry-After per comunicare quando riprovare la richiesta.
Non trasformare questo freno in un blocco permanente e non sostituire una risposta di sovraccarico con una pagina di verifica rivolta a tutti i sistemi automatizzati. Monitora i log e lo stato del server per tutta la durata della misura. Google indica che riduce la scansione in presenza di un numero significativo di risposte 429, 503 o 500 e che la aumenta automaticamente quando questi errori diminuiscono.
Errori da evitare
Una cache fredda non protegge dalla prima richiesta per ogni URL univoco: quella richiesta può comunque raggiungere il server di origine. Preriscalda le pagine selezionate prima di inviare tutto il traffico e non interpretare il primo picco come prova automatica di un attacco.
Evita anche di attivare una protezione generale contro i bot senza eccezioni per i crawler verificati e non usare il limite di Nginx come se conoscessi in anticipo il traffico effettivo o l'indirizzo IP che il server vedrà dopo la CDN. Se Googlebot aumenta la scansione, controlla i log per identificare il traffico; la guida di Google consiglia anche di esaminare gli URL e la struttura del sito quando l'aumento è brusco.
La sequenza pratica è semplice: elenco ridotto, preriscaldamento graduale, verifica del server di origine e apertura progressiva. Se il carico aumenta bruscamente, applica un limite temporaneo e mantieni l'accesso per i crawler verificati.
Fonti: Search Engine Roundtable, Google for Developers, Google for Developers, Google for Developers
