Caching per la SEO

TL;DR — Il caching significa salvare una copia di una pagina o di un file, così non deve essere ricostruito e inviato di nuovo da zero. Rende il sito più veloce per le persone e per i bot di ricerca e permette ai bot di evitare di riscaricare pagine che non sono cambiate. Il caching non ti fa ottenere un ranking migliore da solo, ma la velocità che procura e l’efficienza di crawling che abilita aiutano entrambe indirettamente.

Che cos’è il caching

Ogni volta che qualcuno apre una pagina, il server deve lavorare: costruire l’HTML, inviare le immagini e distribuire CSS e JavaScript. Il caching conserva una copia pronta di questi elementi, così la visita successiva può riutilizzarla invece di ripetere tutto il lavoro.

Per la SEO contano tre luoghi in cui può risiedere una copia:

1. Cache del browser — file salvati sul dispositivo del visitatore, così una seconda visualizzazione o una visita di ritorno viene caricata quasi istantaneamente.
2. Cache della CDN (edge) — copie conservate su server distribuiti in tutto il mondo, così un file viene servito da un luogo fisicamente vicino all’utente (o al bot) invece che dal tuo unico server origin.
3. Cache del crawler — Googlebot e Bingbot ricordano se una pagina è cambiata dall’ultima volta e, se non lo è, evitano di riscaricarla.

Perché conta per la SEO

Per due motivi, che conviene tenere separati:

• Velocità. Una distribuzione più rapida aiuta i Core Web Vitals, soprattutto la velocità di risposta del server (TTFB) e la rapidità con cui compare il contenuto principale (LCP). La velocità fa parte dei segnali di page experience di Google.
• Efficienza di crawling. Quando un bot capisce che una pagina non è cambiata, non spreca un download per essa. Su un sito grande, questo libera il bot perché dedichi il suo tempo alle pagine nuove e aggiornate.

La cosa da chiarire subito

“Cache di Google” e “caching HTTP” sono due cose diverse. Il vecchio operatore di ricerca cache: — la funzione “visualizza la copia salvata da Google di questa pagina” — è stato ritirato nel 2024. Non ha nulla a che vedere con il caching di cui parla questo articolo. Gli header Cache-Control e ETag esistono ancora e sono importanti. L’assenza di una “versione memorizzata nella cache” della pagina Google non dice nulla sulla correttezza della configurazione di caching.

Che cosa fare davvero

• Memorizza a lungo nella cache i file statici (immagini, CSS, JavaScript e font).
• Usa nomi di file versionati o con hash, così puoi aggiornarli all’istante quando serve.
• Usa una CDN per caricare i file da luoghi vicini ai tuoi utenti.
• Non permettere accidentalmente a una cache obsoleta o condivisa di servire ai bot la cosa sbagliata (il caso di errore più grave: vedi le schede Advanced e Anti-patterns).

Vuoi i dettagli a livello di header — direttive Cache-Control, ETag rispetto a Last-Modified, crawling delle CDN e errori di caching? Passa alla scheda Advanced.

TL;DR — Il caching opera su tre livelli importanti per la SEO: browser, edge della CDN e cache delle richieste condizionali del crawler. Non è un fattore di ranking, ma alimenta la velocità delle pagine (TTFB/LCP e, tramite bfcache, i Core Web Vitals delle navigazioni ripetute) e l’efficienza di crawling. Il crawler di Google preferisce ETag a Last-Modified, legge max-age solo come indicazione per il nuovo crawling e, secondo la sua documentazione, “other HTTP caching directives aren’t supported.” (traduzione) «le altre direttive di caching HTTP non sono supportate» (glossa italiana: le altre direttive di caching HTTP non sono supportate). Le CDN ottengono una velocità di crawling consentita più alta, ma solo quando la loro cache è calda; i rischi reali sono i lanci con cache fredda e le configurazioni errate di CDN/WAF che bloccano del tutto i bot.

I tre livelli del caching

Il caching per la SEO non è una sola cosa: sono tre meccanismi, ciascuno controllato in modo un po’ diverso:

1. Cache del browser — il dispositivo del visitatore conserva i file, così le visualizzazioni ripetute saltano la rete. È ciò a cui PageSpeed Insights si riferisce con “Servi gli asset statici con una policy di caching efficiente.” (traduzione) «servi gli asset statici con una policy di caching efficiente»
2. Cache CDN / edge — una rete di distribuzione dei contenuti conserva copie sui nodi edge in tutto il mondo (per la trattazione completa vedi l’approfondimento su CDN e SEO). La descrizione di Google dice che le CDN sono un intermediario tra origin e utente e che storicamente il loro obiettivo principale è il caching: conservano i contenuti di un URL, così il tuo server non deve servire di nuovo quel file per un certo periodo.
3. Cache del crawler — Googlebot e Bingbot tengono un proprio registro dei cambiamenti dei contenuti usando richieste condizionali. È la leva del crawl budget; i dettagli appartengono all’approfondimento sulle richieste condizionali, quindi qui resterò a livello di sintesi.

La “cache del browser” sopra è una scorciatoia per più di un meccanismo. Secondo la guida al caching HTTP di MDN, vale la pena distinguere: la cache HTTP privata (per browser, indicizzata per richiesta e, nei browser moderni, partizionata per sito di primo livello per limitare il tracciamento cross-site), la cache in memoria usata dalla sessione corrente, la bfcache descritta sotto e, separatamente, la Cache Storage di un service worker, controllata dal JavaScript del sito e non governata direttamente dagli header Cache-Control. “Controlla la cache del browser” può quindi indicare quattro passaggi di debugging diversi, a seconda del meccanismo che si comporta male.

Perché il caching alimenta i Core Web Vitals

Recuperare risorse dalla rete è lento e costoso. Il caching elimina la latenza di rete e il costo di trasferimento per tutto ciò che non è cambiato. Questo si riflette direttamente in due misure vicine ai vitals: TTFB (una risposta dalla cache salta la rigenerazione sull’origin) e LCP (immagini, CSS e font in cache vengono renderizzati prima).

Cache-Control, nelle direttive che contano

Cache-Control è l’header principale. Queste sono le direttive da conoscere:

• max-age=<seconds> — per quanto tempo una copia fresca resta valida. Per asset immutabili e versionati, la documentazione Lighthouse di Chrome raccomanda un anno o più un anno o più, per esempio Cache-Control: max-age=31536000.
• no-cache — non significa “non memorizzare nella cache”. Significa “memorizzala, ma riconvalidala con il server prima di riutilizzarla”. Abilita comunque il flusso leggero 304.
• no-store — è la direttiva che significa davvero non conservare alcuna copia in una cache HTTP. È una direttiva di caching, non un interruttore generale della privacy: secondo RFC 9111 non è un modo affidabile per cancellare la cronologia del browser e non dice nulla sulla Cache Storage del service worker.
• public / private — indicano se le cache condivise (come una CDN) possono conservare la risposta oppure se può farlo solo il browser dell’utente finale.
• immutable — salta la riconvalida finché la risposta è ancora fresca. Non significa “mai obsoleta”: quando scade max-age, si applicano di nuovo le normali regole di freschezza.
• must-revalidate — vale all’estremo opposto della sequenza: conta solo dopo che una risposta è diventata obsoleta e dice alla cache di riconvalidarla con l’origin invece di servirla comunque.
• s-maxage, stale-while-revalidate, stale-if-error — controlli più fini, soprattutto per CDN e cache condivise: durata separata per le cache condivise, riuso obsoleto limitato durante un fetch in background e riuso obsoleto limitato in caso di errore dell’origin. Il supporto varia tra browser e CDN, quindi controlla il supporto attuale prima di basarti su queste direttive; inoltre nessuna di queste direttive extra viene rispettata dal crawler di Google, come vedremo.

Cache-busting con nomi di file versionati

Il trucco che ti permette di memorizzare aggressivamente nella cache e aggiornare all’istante: inserisci un hash del contenuto nel nome del file, per esempio style.x234dff.css. Poiché l’URL è la chiave della cache, cambiando il file cambia l’URL; così le cache recuperano subito la nuova versione mentre le vecchie restano memorizzate per tutto il tempo desiderato. Sia la guida HTTP cache di web.dev sia l’articolo di ingegneria front-end di Bing descrivono lo stesso modello: Bing incorpora gli hash dei contenuti nell’URL, così “the URL acts as the cache key,” (traduzione) «l’URL funziona da chiave della cache», mantenendo coerenti le cache e consentendo scadenze lunghe.

La trappola della bfcache: dove no-store danneggia silenziosamente i CWV

Ecco un aspetto poco trattato. La cache indietro/avanti (bfcache) permette di ripristinare istantaneamente una pagina quando si preme “indietro”. Il ripristino dalla bfcache salta del tutto la misurazione di LCP/CLS/INP, quindi è un vantaggio puro per i dati sul campo di CrUX. Tuttavia, secondo la guida bfcache di Google, impostare Cache-Control: no-store sul documento della pagina ha storicamente fatto sì che i browser rifiutassero di memorizzare quella pagina nella bfcache. Se ti serve freschezza per un documento HTML ma non vuoi rinunciare all’idoneità alla cache indietro/avanti, usa no-cache o max-age=0 invece di no-store.

Come una cache decide che qualcosa è “abbastanza fresco”

Prima che intervenga un validator, una cache controlla la freschezza: l’età della risposta memorizzata ha superato la durata di freschezza assegnata da Cache-Control (o, in assenza di una durata esplicita, una durata euristica che la cache può stimare)? L’header di risposta Age indica da quanto tempo una cache condivisa conserva già la risposta: così puoi capire, in DevTools o dal log della CDN, quanta durata di freschezza rimane. Se è fresca, la cache può riutilizzarla immediatamente, senza alcuna richiesta. Se è obsoleta, dovrebbe convalidarla prima di riutilizzarla: è qui che ETag/If-None-Match e Last-Modified/If-Modified-Since diventano utili, come descritto dopo per la versione più ristretta di questo meccanismo HTTP usata da Googlebot.

Come Googlebot usa il caching (il lato dell’efficienza di crawling)

Google ha fatto una richiesta insolitamente diretta nel post di dicembre 2024 Crawling December: HTTP caching: abilita il caching così i suoi crawler possono evitare di riscaricare pagine invariate. Il dato più sorprendente di quel post è che i fetch memorizzabili nella cache sono in diminuzione: circa lo 0,026% del totale dei fetch era memorizzabile 10 anni fa, mentre oggi il numero è 0,017%. Sono numeri piccoli, ma Google vuole chiaramente che vadano nella direzione opposta.

ETag rispetto a Last-Modified: quale preferisce Google

L’infrastruttura di crawling di Google supporta i due validator standard: ETag (con If-None-Match) e Last-Modified (con If-Modified-Since). Google raccomanda con forza ETag perché il suo valore non è strutturato e quindi è meno esposto agli errori di parsing che può provocare una stringa di data; se sono presenti entrambi, i crawler usano il valore ETag come richiede lo standard HTTP. Google suggerisce comunque di impostarli entrambi, perché li usano altre applicazioni come i CMS. Se usi Last-Modified, la data deve seguire il formato HTTP, per esempio Fri, 4 Sep 1998 19:15:56 GMT, altrimenti non verrà analizzata.

Quando il validator memorizzato dal crawler corrisponde ancora, il server restituisce un 304 Not Modified senza corpo: è proprio questo il punto. Come dice Google, l’assenza del corpo fa sì che il server non consumi risorse per generare il contenuto e non consumi banda per trasferirlo. Il meccanismo 304 è il metodo di crawl budget trattato in dettaglio nell’articolo sulle richieste condizionali; qui basta sapere che esiste e fa risparmiare denaro a entrambe le parti.

La sfumatura che quasi tutti perdono

Il crawler di Google non agisce sull’intero insieme di direttive Cache-Control come farebbe un browser o una CDN. Secondo la panoramica ufficiale dei crawler, oltre a ETag/Last-Modified, “other HTTP caching directives aren’t supported.” (traduzione) «le altre direttive di caching HTTP non sono supportate» (glossa italiana: le altre direttive di caching HTTP non sono supportate). L’unica eccezione parziale: Google dice che puoi impostare facoltativamente max-age per aiutare i crawler a determinare quando ripetere il crawling di un URL, come indicazione per un nuovo crawling e non come blocco rigido. Quindi no-cache, s-maxage, stale-while-revalidate e simili modellano ancora il comportamento di browser e CDN, ma non cambiano il modo in cui Googlebot memorizza nella cache. Anche il consiglio di Google su quando invalidare è sensato: richiedi un refresh della cache in caso di cambiamenti significativi, mentre aggiornare solo la data del copyright nel footer non è significativo.

CDN e crawling

Una CDN offre più della velocità. L’infrastruttura di crawling di Google è progettata per consentire velocità di crawling più alte sui siti supportati da una CDN, dedotte dall’indirizzo IP che serve gli URL: presume che un origin supportato da CDN possa gestire più richieste simultanee.

Ma c’è una complicazione da pianificare: la cache fredda. Al primo accesso a un URL, la cache della CDN è “fredda”: nessuno lo ha ancora richiesto, quindi l’origin deve servirlo almeno una volta per riscaldare la cache. Google avverte che lanciare molti URL contemporaneamente grava quindi davvero sul crawl budget, con una velocità di crawling alta per alcuni giorni. Se fai un grande lancio o una migrazione del sito, pianifica che l’origin sopporti il carico completo per ogni URL prima che la CDN inizi ad aiutare.

Una configurazione errata della CDN è un rischio per il crawling

I problemi più gravi legati al caching non sono durate lente: sono configurazioni di CDN e WAF che bloccano i bot. Il post di Google sulle CDN è esplicito: per i blocchi temporanei, inviare 503/429 è il metodo preferito per segnalarli, mentre i timeout di rete vengono trattati come errori terminali e “hard”, che possono far rimuovere gli URL dall’indice. Il caso più subdolo è un blocco morbido: un interstitial di verifica del bot. Il crawler vede solo la pagina della sfida, non il sito; perciò Google raccomanda con forza di restituire 503 ai client automatici. Il modo più semplice per controllare che una CDN non stia bloccando silenziosamente Google è lo strumento Ispezione URL in Search Console: guarda l’immagine renderizzata; se mostra una sfida per il bot o una pagina vuota, parla con il provider CDN.

Sono favorevole a spostare i redirect sulla CDN. Nel podcast Marketing Speak l’ho descritto così: “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (traduzione) «uno dei miei preferiti, che secondo me non viene usato abbastanza, è semplicemente spostare i redirect al livello CDN». (Vai alla citazione)

Errori di caching che danneggiano crawling e indicizzazione

Questo è l’aspetto che la maggior parte degli articoli sul “caching per la SEO” ignora. Una cache non rende soltanto le cose veloci: una cache sbagliata può servire a un bot i byte sbagliati e rompere crawling o indicizzazione.

Un caso reale: una cache condivisa che serve un robots.txt bloccante. Ho analizzato un caso di blocco intermittente di Googlebot ricondotto a una cache CDN condivisa tra un ambiente di test e il sito live. Come ho scritto in Indicizzato, anche se bloccato da robots.txt: “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (traduzione) «una possibile causa è una cache condivisa tra un ambiente di test e uno live; quando è attiva la cache dell’ambiente di test, il file robots.txt può contenere una direttiva bloccante». La soluzione era separare la cache oppure escludere i file .txt dalla cache nell’ambiente di test. Una configurazione errata del caching ha causato direttamente un errore di crawling: è questa la categoria di rischio che fa davvero male.

Altri errori della stessa famiglia:

• Cache CDN obsoleta che serve contenuti vecchi ai bot. Se la cache edge conserva una versione vecchia molto dopo la pubblicazione di una modifica, i bot continuano a vedere quella vecchia. Esegui il purge alla pubblicazione oppure lega la durata della cache alla frequenza con cui cambia davvero la pagina.
• Frammentazione della cache per Vary / User-Agent. La chiave di una cache condivisa normalmente è solo l’URL; Vary aggiunge header di richiesta (come User-Agent o Accept-Language) a quella chiave, così le varianti vengono memorizzate separatamente. Se ometti un header che cambia davvero la risposta, un richiedente può ricevere la variante di un altro: confusione tra mobile/desktop o bot/umano. Se aggiungi troppi header a Vary, frammenti la cache in così tante chiavi quasi duplicate che il tasso di hit migliora appena. Separatamente, per motivi di privacy i browser moderni partizionano anche le proprie cache per sito di primo livello, quindi una risorsa memorizzata mentre è incorporata in un sito generalmente non viene riutilizzata quando è incorporata in un altro: è un meccanismo diverso da Vary, da non confondere quando fai debugging di un report “perché non è in cache?”.

La mia regola generale sulla durata nasce dal lavoro su LCP: come ho scritto nella mia guida Ahrefs al Largest Contentful Paint, “Your cache time should be as long as you are comfortable with” (traduzione) «la durata della cache dovrebbe essere lunga quanto ti senti a tuo agio» (glossa italiana: la durata della cache dovrebbe essere lunga quanto ti senti a tuo agio). E [“An ideal setup is to cache for a really long period of time but purge the cache when you make a change to a page.” (traduzione) «la configurazione ideale prevede una cache molto lunga e il purge quando modifichi una pagina»] (glossa italiana: la configurazione ideale è una cache molto lunga, con purge quando modifichi una pagina). Cache lunga, purge immediato. È questa combinazione a tenerti veloce e aggiornato.

Il caching è un fattore di ranking?

No, non direttamente. Non esiste un segnale di ranking legato alla presenza di ETag o a una buona policy Cache-Control. Il caching alimenta due elementi che contano per la visibilità: velocità delle pagine / Core Web Vitals (un input esplicito della page experience) ed efficienza di crawling (che determina la velocità con cui i contenuti nuovi e aggiornati vengono scoperti e aggiornati, influendo indirettamente sui risultati sensibili alla freschezza). Configuralo perché rende il sito veloce e facile da sottoporre a crawling, non aspettandoti un aumento diretto del ranking.

Riepilogo IA

Una sintesi della versione Advanced:

• Caching = tre livelli per la SEO: cache del browser, cache CDN/edge e cache delle richieste condizionali del crawler. Ciascuno è controllato in modo un po’ diverso.
• Non è un fattore di ranking, ma alimenta due elementi importanti: velocità delle pagine (TTFB/LCP e vitals delle navigazioni ripetute tramite bfcache) ed efficienza di crawling.
• Basi di Cache-Control: max-age imposta la freschezza (un anno o più per asset immutabili e versionati); no-cache = “memorizza ma riconvalida” (non “non memorizzare”); no-store = non memorizzare nulla; public/private regolano le cache condivise/CDN.
• Cache-busting: inserisci un hash del contenuto nel nome del file per memorizzare aggressivamente e aggiornare comunque all’istante (Google e Bing usano entrambi questo modello).
• Trappola bfcache: Cache-Control: no-store sul documento HTML può rendere la pagina non idonea alla cache indietro/avanti, danneggiando silenziosamente i vitals CrUX. Usa invece no-cache o max-age=0.
• Googlebot rispetta solo ETag e Last-Modified (preferisce ETag e legge max-age come indicazione per un nuovo crawling). Secondo Google, “other HTTP caching directives aren’t supported” (glossa italiana: le altre direttive di caching HTTP non sono supportate). Un validator corrispondente restituisce 304 Not Modified senza corpo, risparmiando calcolo e banda.
• Le CDN ottengono una velocità di crawling consentita maggiore, ma solo quando la cache è calda. I lanci con cache fredda colpiscono comunque l’origin una volta per URL: pianificali per i grandi lanci e le migrazioni.
• Il rischio maggiore non è il caching lento, ma una configurazione errata CDN/WAF che blocca i bot (restituisci 503/429 per i blocchi temporanei e controlla gli interstitial di blocco morbido) e cache obsolete/condivise che servono contenuti sbagliati, per esempio un robots.txt bloccante.

Documentazione ufficiale

Documentazione primaria dei motori di ricerca e dei rispettivi team che gestiscono gli strumenti.

Google

• Crawling December: caching HTTP — il post di Gary Illyes del dicembre 2024: ETag rispetto a Last-Modified, meccanica 304, statistica sui fetch memorizzabili in calo e indicazione max-age per il nuovo crawling.
• Panoramica di Google Crawler (User Agent) — sezione HTTP Caching — riferimento aggiornato: regola di spareggio ETag e frase “other HTTP caching directives aren’t supported” (traduzione) «le altre direttive di caching HTTP non sono supportate».
• Crawling December: CDN e crawling — Splitt e Illyes sul caching CDN, la maggiore velocità consentita di crawling, i lanci con cache fredda e i blocchi rigidi rispetto a quelli morbidi.
• Servi gli asset statici con una policy di caching efficiente — audit Lighthouse/PageSpeed e indicazione di un anno o più per gli asset immutabili.
• Previeni le richieste di rete non necessarie con la cache HTTP — riferimento alle direttive e modello di cache-busting con nomi di file hashati.
• Cache indietro/avanti (bfcache) — perché no-store sul documento HTML può compromettere l’idoneità alla bfcache.
• Indice della serie Crawling December — la serie completa del 2024: Googlebot, caching HTTP, navigazione sfaccettata e CDN.

Bing / Microsoft

• Prestazioni front-end rapide per Microsoft Bing — il team di ingegneria di Bing sull’inserimento dell’hash dei contenuti negli URL per la coerenza della cache e le scadenze lunghe, e sul ruolo della CDN nell’accelerare la distribuzione degli asset statici.
• Serie Bingbot: massimizzare l’efficienza del crawling — la logica della freschezza del crawling, che il caching supporta evitando il crawling quando il contenuto non è cambiato.
• Linee guida per webmaster di Bing — l’hub in cui si trovano le indicazioni di Bing su CDN e prestazioni.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google e dei miei articoli. Ogni link è un deep link che porta al passaggio citato nella pagina sorgente.

Google — Crawling December: caching HTTP

• “While Google’s crawling infrastructure supports heuristic caching mechanisms, in fact always had, the number of requests that can be returned from local caches has decreased: 10 years ago about 0.026% of the total fetches were cacheable, which is already not that impressive; today that number is 0.017%.” (traduzione) «Sebbene l’infrastruttura di crawling di Google supporti meccanismi di caching euristici, il numero di richieste restituibili dalle cache locali è diminuito: dieci anni fa era memorizzabile circa lo 0,026% dei fetch totali, già un dato poco impressionante; oggi è lo 0,017%» Vai alla citazione
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value). And, if you have the option, set them both: the internet will thank you. Maybe.” (traduzione) «Raccomandiamo con forza di usare ETag perché è meno soggetto a errori; il suo valore non è strutturato come quello di Last-Modified. Se puoi, impostali entrambi: Internet ti ringrazierà. Forse.» Vai alla citazione
• “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (traduzione) «Raccomandiamo di richiedere il refresh della cache quando il contenuto cambia in modo significativo; se hai aggiornato solo la data del copyright in fondo alla pagina, probabilmente non è significativo.» Vai alla citazione

Google — panoramica dei crawler (sezione HTTP Caching)

• “If both ETag and Last-Modified response header fields are present in the HTTP response, Google’s crawlers use the ETag value as required by the HTTP standard.” (traduzione) «Se nella risposta HTTP sono presenti sia ETag sia Last-Modified, i crawler di Google usano il valore ETag come richiede lo standard HTTP.» Vai alla citazione
• “Other HTTP caching directives aren’t supported.” (traduzione) «Le altre direttive di caching HTTP non sono supportate.» Vai alla citazione

Google — Crawling December: CDN e crawling

• “Historically, CDNs’ biggest focus is caching, meaning that once a user requested a URL from your site, CDNs will store the contents of that URL in their caches for a time so your server doesn’t have to serve that file again for a while.” (traduzione) «Storicamente, il principale obiettivo delle CDN è il caching: dopo che un utente ha richiesto un URL del tuo sito, le CDN ne conservano il contenuto nelle proprie cache per un certo periodo, così il server non deve servire di nuovo quel file per un po’.» Vai alla citazione

Patrick Stox — caching e CDN

• “Your cache time should be as long as you are comfortable with.” (traduzione) «La durata della cache dovrebbe essere lunga quanto ti senti a tuo agio.» — io, nella guida Ahrefs al Largest Contentful Paint. Vai alla citazione
• “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (traduzione) «Una possibile causa è una cache condivisa tra un ambiente di test e uno live; quando è attiva la cache dell’ambiente di test, il file robots.txt può contenere una direttiva bloccante.» — io, su un vero errore di crawling ricondotto a una cache condivisa. Vai alla citazione
• “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (traduzione) «Uno dei miei preferiti, che secondo me non viene usato abbastanza, è semplicemente spostare i redirect al livello CDN.» — io, nel podcast Marketing Speak. Vai alla citazione

Caching per la SEO — scheda rapida

Direttive Cache-Control, decodificate

Che cosa rispetta davvero Googlebot

• ✅ ETag + If-None-Match (validator preferito da Google)
• ✅ Last-Modified + If-Modified-Since (formatta la data secondo HTTP: Fri, 4 Sep 1998 19:15:56 GMT)
• ✅ max-age — ma solo come indicazione sui tempi del nuovo crawling, non come regola
• ❌ Tutto il resto — “other HTTP caching directives aren’t supported” (glossa italiana: le altre direttive di caching HTTP non sono supportate)

Fatti rapidi

• Google preferisce ETag; se sono impostati entrambi, vince ETag. Impostali comunque entrambi (li usano i CMS).
• Un validator corrispondente → 304 Not Modified, nessun corpo → risparmia calcolo e banda.
• Chrome/Lighthouse: memorizza gli asset immutabili nella cache per un anno o più.
• Le CDN ottengono una velocità di crawling consentita più alta, ma solo quando la cache è calda.
• Blocco temporaneo? Restituisci 503/429, mai un 200 silenzioso con errore o un interstitial per bot.
• no-store sul documento HTML può rendere la pagina non idonea alla bfcache → usa no-cache/max-age=0.
• La “cache di Google” (operatore cache:) è stata ritirata nel 2024: non c’entra con il caching HTTP.

Miti ed errori sul caching

Per ciascuno: perché è sbagliato e che cosa fare invece.

Mito: “Memorizzare la mia pagina nella cache migliorerà il ranking.” Perché è sbagliato: non esiste un segnale di ranking per la configurazione della cache. Il team Search Relations di Google ha chiarito che il caching non è un fattore di ranking. Fai invece: configura il caching per i vantaggi reali — velocità delle pagine / Core Web Vitals ed efficienza di crawling — che influiscono entrambi indirettamente sulla visibilità. Non aspettarti un aumento diretto.

Mito: “La cache di Google e il caching HTTP sono la stessa cosa.” Perché è sbagliato: l’operatore di ricerca cache: e il visualizzatore delle pagine memorizzate erano una funzione di snapshot rivolta agli utenti, ritirata del tutto nel 2024. Il caching HTTP (Cache-Control/ETag) è un’infrastruttura senza relazione. Fai invece: ignora la “versione memorizzata nella cache” mancante: non dice nulla sulla configurazione. Valuta il caching dagli header e dal comportamento di crawling/prestazioni.

Mito: “no-cache significa non memorizzare nella cache.” Perché è sbagliato: no-cache significa “memorizzala, ma riconvalidala con il server prima di usarla”. Abilita comunque il flusso di riconvalida 304. no-store è la direttiva che impedisce davvero la memorizzazione. Fai invece: usa no-cache quando vuoi freschezza con riconvalida; riserva no-store alle risposte realmente sensibili che non devono mai essere memorizzate.

Mito: “Una durata lunga della cache farà vedere a Google contenuti obsoleti per sempre.” Perché è sbagliato: il crawler di Google convalida tramite ETag/Last-Modified a ogni nuovo crawling, indipendentemente da max-age; max-age è un’indicazione per il nuovo crawling, non un blocco che impedisce a Google di recuperare di nuovo la pagina. Fai invece: usa una cache lunga, ma attiva un vero cache-buster (nuovo ETag/Last-Modified o URL) quando cambiano contenuti importanti: è esattamente la raccomandazione di Google.

Mito: “Una CDN risolve automaticamente i problemi di crawl budget.” Perché è sbagliato: una CDN aiuta solo quando la cache è calda; l’origin serve comunque ogni URL almeno una volta (il problema della cache fredda) e una CDN configurata male può bloccare i crawler e peggiorare le cose. Fai invece: pianifica il carico sull’origin per grandi lanci e migrazioni e verifica che la CDN non stia bloccando i bot (Ispezione URL e 503/429 per i blocchi temporanei).

Mito: “Qualsiasi direttiva Cache-Control impostata cambia il modo in cui Googlebot esegue il crawling.” Perché è sbagliato: secondo la documentazione Google, oltre a ETag/Last-Modified (e all’indicazione facoltativa max-age), “other HTTP caching directives aren’t supported” dal crawler (glossa italiana: le altre direttive di caching HTTP non sono supportate). Fai invece: usa stale-while-revalidate, s-maxage, no-cache e simili per regolare browser e CDN, ma affidati a ETag/Last-Modified per influire sul caching di Googlebot.

Configurazioni di caching, prima e dopo

1. Asset statico senza policy di caching → avviso PageSpeed eliminato

• Prima: style.css viene servito senza Cache-Control; Lighthouse segnala “Serve static assets with an efficient cache policy” e le visite ripetute lo riscaricano.
• Dopo: rinomina in style.a1b2c3.css e servi Cache-Control: public, max-age=31536000, immutable. Le visite ripetute saltano il download; un cambiamento del contenuto implica un nuovo nome di file, che invalida all’istante.

2. Documento HTML che volevi “fresco” → bfcache persa

• Prima: Cache-Control: no-store sull’HTML per forzare la freschezza. Effetto collaterale: la pagina non è idonea alla bfcache, quindi le navigazioni indietro rimisurano LCP/CLS/INP e peggiorano i dati sul campo CrUX.
• Dopo: passa a no-cache (o max-age=0: riconvalidi comunque per la freschezza, ma la pagina resta idonea alla bfcache e le navigazioni ripetute vengono ripristinate all’istante.

3. Cache condivisa tra staging e produzione → blocco intermittente di Googlebot

• Prima: gli ambienti di test e live condividono una cache CDN. Quando è attiva la versione di test, il robots.txt memorizzato nella cache contiene una direttiva bloccante e Googlebot vede a intermittenza un disallow che non dovrebbe esserci.
• Dopo: separa la cache tra gli ambienti oppure escludi i file .txt dalla cache dell’ambiente di test, così il robots.txt live non viene mai servito dalla cache di staging. (È un caso reale che ho descritto in Indicizzato, anche se bloccato da robots.txt.)

4. Grande lancio dietro una CDN → picco di crawling inatteso

• Prima: pubblichi 50 000 nuovi URL in una volta pensando che la CDN assorba il carico. Ogni URL è una cache miss fredda, quindi l’origin serve ciascuno almeno una volta e la velocità di crawling resta alta per giorni.
• Dopo: riscalda la cache prima del lancio (oppure distribuisci il rollout) e prevedi, oltre a dimensionare il sistema, che l’origin sopporti il carico completo per URL prima che la CDN inizi a proteggerlo.

Checklist di configurazione del caching HTTP

• Gli asset statici (immagini, CSS, JS e font) hanno un max-age lungo (un anno o più per file immutabili/versionati).
• Usi nomi di file versionati/hashati per poter memorizzare aggressivamente nella cache e invalidare comunque all’istante.
• ETag è impostato (è il validator preferito da Google); imposta anche Last-Modified con una data HTTP formattata correttamente.
• Il server restituisce 304 Not Modified (senza corpo) quando un validator corrisponde ancora.
• I documenti HTML che richiedono freschezza usano no-cache/max-age=0, non no-store (proteggi l’idoneità alla bfcache).
• Un cambiamento importante dei contenuti attiva un vero cache-buster (nuovo ETag/Last-Modified/URL), non solo una modifica alla data nel footer.
• Una CDN è davanti all’origin, con public/s-maxage impostati affinché le cache condivise possano conservare ciò che va condiviso.
• La cache viene sottoposta a purge alla pubblicazione, così i bot non ricevono mai contenuti obsoleti.
• Staging e produzione non condividono una cache per robots.txt o altri file di controllo.
• I blocchi temporanei restituiscono 503/429, non pagine 200 silenziose con errore né interstitial per bot.
• Ispezione URL in Search Console mostra la pagina reale (non una sfida o una pagina vuota), confermando che CDN/WAF non sta bloccando Googlebot.

I file aggiornati restano obsoleti dopo il deployment

Sintomo: i visitatori continuano a ricevere un vecchio file CSS, JavaScript o immagine. Causa probabile: una cache di lunga durata usa lo stesso URL per byte modificati. Soluzione: pubblica gli asset immutabili con nomi hashati dal contenuto e aggiorna il riferimento nell’HTML; esegui il purge del vecchio oggetto edge solo quando hai riutilizzato l’URL. Conferma che il nuovo URL venga caricato.

Googlebot riscarica pagine invariate

Sintomo: i log mostrano risposte 200 complete ripetute per lo stesso HTML invariato. Causa probabile: validator ETag/Last-Modified mancanti o instabili. Soluzione: emetti un validator stabile e corretto per il contenuto e verifica una richiesta condizionale. Una riconvalida funzionante restituisce 304 quando la rappresentazione non è cambiata.

Utenti diversi ricevono la variante memorizzata sbagliata

Sintomo: contenuti relativi a lingua, dispositivo, accesso o personalizzazione trapelano tra utenti. Causa probabile: la chiave della cache condivisa non include la dimensione che modifica la risposta oppure il contenuto privato è stato marcato come pubblico. Soluzione: correggi chiave della cache e comportamento di Vary, contrassegna correttamente le risposte private, esegui il purge degli oggetti contaminati e riprova più varianti.

La cache CDN non segnala mai un hit

Sintomo: richieste ripetute e idonee continuano a raggiungere l’origin. Causa probabile: no-store/private, cookie, una chiave della cache eccessivamente frammentata o una regola di bypass edge. Soluzione: esamina gli header di stato della risposta e della cache CDN, modifica solo le regole sicure per quella classe di contenuto e richiedi due volte la stessa chiave per confermare un hit.

Memorizza in base al rischio della rappresentazione, non solo all’estensione del file

Classifica ogni risposta prima di assegnarle una policy:

1. Asset pubblico immutabile: CSS, JS, font o immagini con hash del contenuto possono usare una durata lunga, perché i byte modificati ottengono un nuovo URL.
2. Documento pubblico ma variabile: l’HTML può essere memorizzato brevemente oppure riconvalidato con ETag/Last-Modified; freschezza e correzione rapida contano più del TTL massimo.
3. Risposta specifica per utente: il caching condiviso non è sicuro, a meno che la personalizzazione non venga rimossa dalla rappresentazione o separata correttamente nella chiave della cache.
4. Risposta sensibile: usa la policy rigorosa richiesta dai dati, accettando il compromesso sulle prestazioni invece di esporre il contenuto.

La domanda utile non è “Per quanto tempo posso memorizzare questo tipo di contenuto?”. È “Che cosa ci sarebbe di sbagliato se questa rappresentazione esatta venisse riutilizzata per questo richiedente dopo questa modifica?”

Freschezza, correttezza, efficienza

Una policy di caching deve superare tre test: freschezza (le modifiche compaiono quando promesso), correttezza (il richiedente giusto riceve la variante giusta) ed efficienza (byte invariati non vengono rigenerati o trasferiti inutilmente). Un tasso di hit elevato non è un successo se serve la risposta sbagliata.

Strumenti per ispezionare il caching HTTP

• Pannello Network di DevTools del browser — esamina Cache-Control, ETag, Last-Modified, Age, Vary e se la risposta proviene da memoria, disco o rete.
• curl — invia richieste HEAD e condizionali senza l’ambiguità della cache del browser; confronta il validator iniziale con If-None-Match o If-Modified-Since.
• PageSpeed Insights / Lighthouse — individua gli asset statici con policy di caching inefficienti; l’articolo rimanda alle indicazioni ufficiali sulla policy di cache Lighthouse.
• Analytics e log della CDN — esamina stato hit/miss/bypass, chiavi della cache, richieste all’origin e purge al livello che serve davvero la risposta pubblica.
• Log del server — verifica che Googlebot riceva riconvalide 304 invece di corpi completi per pagine invariate.

Dimostrare che una modifica al caching funziona

Test della richiesta condizionale

Test da eseguire: recupera la risposta, copia il suo ETag e poi richiedila con If-None-Match. Risultato atteso: una rappresentazione invariata restituisce 304 senza corpo della risposta. Interpretazione del fallimento: il validator manca, è instabile o viene ignorato. Finestra di monitoraggio: immediata. Trigger di rollback: contenuto modificato risposto erroneamente con 304 oppure validator in collisione tra varianti.

Test dell’asset versionato

Test da eseguire: distribuisci i byte modificati su un nuovo URL con hash del contenuto e ricarica una pagina che lo referenzia. Risultato atteso: il nuovo URL restituisce il nuovo asset, mentre il vecchio può restare memorizzato nella cache. Interpretazione del fallimento: l’HTML usa ancora il vecchio asset oppure la build non ha cambiato l’hash. Finestra di monitoraggio: immediatamente dopo la propagazione HTML/CDN. Trigger di rollback: stile rotto o errori di script sul nuovo asset.

Test delle varianti della cache condivisa

Test da eseguire: richiedi ogni variante significativa tramite la CDN, ripeti ciascuna richiesta e confronta corpo, chiave/stato della cache e Vary. Risultato atteso: ogni richiedente riceve la rappresentazione corretta e vengono riutilizzate solo varianti sicure. Interpretazione del fallimento: manca una dimensione nella chiave della cache oppure il contenuto privato è condiviso. Finestra di monitoraggio: immediata, più revisione dei log di produzione. Trigger di rollback: un utente riceve il contenuto personalizzato o la lingua di un altro utente.

Mettiti alla prova: caching per la SEO

Cinque domande rapide su caching HTTP, CDN e crawling. Scegli una risposta per ciascuna e poi controlla il risultato.

Cronologia modifiche