Attivi una CDN per rendere il sito più veloce e alleggerire il server. Poi guardi i log e trovi più richieste di prima. Il server continua a lavorare e viene il dubbio che qualcosa sia andato storto.
È proprio questa situazione che Google affronta nella guida pubblicata l’11 novembre 2026. Il problema può nascere durante il passaggio: la CDN risponde rapidamente, ma la sua cache deve ancora riempirsi. Quando arriva una richiesta per una pagina che non ha in memoria, deve recuperarla dal server di origine. Se le pagine richieste sono tante, il carico resta lì.
Per chi gestisce un ecommerce, la questione riguarda anche le pagine prodotto e il percorso d’acquisto. Per chi segue la SEO, c’è un altro rischio: reagire al picco attivando una protezione anti-bot che finisca per bloccare anche Googlebot.
Prima di cambiare le regole del firewall, partirei quindi da una domanda: chi sta facendo quelle richieste e quali arrivano davvero al server? È il controllo che permette di scegliere l’intervento, invece di procedere per tentativi.
La CDN è attiva. Perché il server lavora ancora?
Una Content Delivery Network distribuisce copie dei contenuti su server periferici, chiamati edge. Se la copia richiesta è disponibile e utilizzabile, la CDN può rispondere dalla cache: è un cache hit. Quando la copia manca, deve chiederla all’origine, cioè al server che ospita il contenuto: è un cache miss.
Durante l’avvio questa differenza conta molto. Aprire alcune pagine del sito e trovarle veloci non basta per capire quanto lavoro stia arrivando all’origine. Il controllo da chiedere al fornitore è semplice: quante richieste vengono servite dalla cache e quante devono ancora raggiungere applicazione e database?
Google suggerisce di preparare la cache sulle URL importanti, consentire l’accesso ai crawler verificati e prevedere come gestire un eventuale sovraccarico. Il passaggio a una CDN richiede quindi un collaudo. La guida non annuncia un nuovo fattore di ranking.
Un sito più veloce può essere scansionato di più, ma non è automatico
Nella documentazione sul crawl budget, Google distingue due aspetti: quanto il sito può sostenere e quanto i suoi sistemi vogliono scansionare. Risposte rapide e stabili possono consentire più connessioni. La domanda dipende anche dalle URL conosciute e dalla necessità di aggiornarle.
Per questo, una CDN più veloce non garantisce che Google esplori ogni pagina o la inserisca nell’indice. Se il tuo è un piccolo sito aziendale, partirei dalle pagine raggiungibili e dai problemi effettivamente osservati. La gestione avanzata del crawl budget interessa soprattutto siti grandi o aggiornati frequentemente.
Nei log distinguerei inoltre Googlebot da AdsBot e dagli altri crawler Google. La capacità viene condivisa, mentre la domanda cambia secondo il prodotto: leggere ogni richiesta Google come scansione organica può portare fuori strada.
Prima di partire, metti SEO, sviluppo e hosting allo stesso tavolo
Il modo più utile di preparare la migrazione è concordare chi controlla cosa. Puoi usare questa checklist come punto di partenza: è una proposta operativa, da adattare al sito e al fornitore.
| Chi coinvolgere | Cosa chiedere prima del rilascio | Cosa deve restare documentato |
|---|---|---|
| SEO | Quali pagine dobbiamo ricontrollare? | Un campione con risposta HTTP, indicizzabilità, canonical e contenuto atteso. |
| Sviluppatore | Cosa finisce in cache e cosa deve seguire regole diverse? | Il comportamento previsto per contenuti pubblici, sessioni e acquisti. |
| Hosting o sysadmin | Quanto carico può sostenere l’origine e come interveniamo? | Log, metriche e procedura di ripristino disponibili. |
| Responsabile aziendale | Quando facciamo il cambio e chi decide di fermarlo? | Una finestra concordata, un referente reperibile e criteri di sospensione. |
Nel campione inserirei home, categorie, prodotti o servizi e pagine da cui arrivano contatti. Aggiungerei anche una pagina meno visitata: le sole URL più popolari non raccontano tutto il comportamento della cache.
La preparazione automatica della cache va concordata con il team tecnico, scegliendo URL, ritmo delle richieste ed esclusioni. Eviterei inoltre, quando possibile, di cambiare nello stesso momento CDN, template, tracciamenti e checkout. Se qualcosa smette di funzionare, capire dove intervenire diventa più difficile.
Prima di fidarti del nome Googlebot, verifica la richiesta
Trovare la parola Googlebot nello user-agent non basta a dimostrare chi stia accedendo al sito. La procedura ufficiale Google prevede, per le verifiche manuali, una ricerca DNS inversa sull’IP dei log, il controllo del dominio restituito e una ricerca diretta che riconduca allo stesso IP. Per controlli automatici si possono usare gli intervalli di indirizzi pubblicati da Google.
Le liste distinguono crawler comuni, speciali e recuperi attivati dagli utenti. L’eccezione nel firewall deve quindi corrispondere al traffico che vuoi consentire.
Al collaudo chiederei di verificare sia che i crawler autentici ricevano la pagina corretta, sia che le protezioni continuino a filtrare gli accessi indesiderati. Il fatto che tu riesca ad aprire il sito dal telefono non dimostra che Googlebot lo raggiunga senza challenge o errori.
Dopo il cambio, guarda cosa succede sui due lati della CDN
Prima del rilascio, conserva un riferimento con cui confrontare i dati successivi. Le soglie di attenzione vanno stabilite con l’hosting, sulla capacità reale del server. Non c’è un numero generico da copiare e applicare a qualsiasi sito.
- Sulla CDN: quante richieste arrivano, quante trovano una risposta in cache e quante raggiungono l’origine.
- Sul server: tempi di risposta, errori, risorse occupate e segnali di saturazione.
- Nei log dei crawler verificati: volume, URL richieste e codici HTTP ricevuti.
- Sulle pagine commerciali: caricamento di categorie e servizi, invio delle richieste e completamento dell’acquisto.
Se molte richieste arrivano ancora all’origine, controllerei le regole di cache. Se gli errori riguardano soprattutto i bot, guarderei le protezioni. Sono punti da cui iniziare l’indagine: per confermare la causa servono i dati. Annotare l’orario delle modifiche aiuta a confrontarli.
Il server va in affanno: cosa controllare prima di bloccare i bot
Se il carico diventa critico, serve un intervento concordato con chi gestisce l’infrastruttura. La guida Google per ridurre urgentemente la scansione contempla risposte temporanee come 429 e 503, anche con l’header Retry-After. L’effetto può estendersi alla scansione dell’intero hostname, comprese le pagine che continuano a rispondere correttamente.
Google parla di finestre brevi, da qualche ora a uno o due giorni. Lasciare questi errori per più giorni può compromettere la presenza delle URL nei suoi prodotti. Ridurre la scansione può anche ritardare l’aggiornamento di prezzi e disponibilità; può avere conseguenze sugli annunci.
Prima di attivare una misura del genere, chiarirei chi la rimuove, quando ricontrolla il server e quale condizione permette di tornare al funzionamento normale. È facile ricordarsi di intervenire durante un’emergenza; conviene scrivere subito anche come uscirne.
Come capire se il passaggio è riuscito
Non mi fermerei al fatto che il sito sembri più rapido. Ricontrollerei il campione di pagine, l’accesso dei crawler verificati, il carico dell’origine e le funzioni commerciali. Per ogni problema ancora aperto, assegnerei un responsabile e una scadenza.
Nel tempo potrai confrontare anche il traffico organico, tenendo traccia della migrazione e degli altri interventi. Un aumento o un calo, da solo, non dimostra l’effetto della CDN. Il primo risultato da verificare è più concreto: utenti e crawler devono raggiungere il contenuto corretto, mentre il server riesce a sostenere il lavoro richiesto.