304 Not Modified: guida alla cache condizionale

TL;DR — Una risposta 304 Not Modified è il modo con cui il server dice “lo hai già: la tua copia è ancora valida, non scaricarla di nuovo”. Non è un errore e, pur appartenendo alla famiglia 3xx dei “redirect”, non invia nessuno verso un nuovo URL. Si verifica solo quando il client, browser o crawler, invia prima una richiesta condizionale chiedendo “è cambiato dall’ultima volta?”. Per la SEO non sposta le posizioni, ma sui siti grandi può aiutare i motori di ricerca a usare le risorse in modo più efficiente.

Che cos’è davvero un 304

Ogni risposta inviata dal server inizia con un codice di stato a tre cifre. 200 OK significa “ecco la pagina, con body e tutto il resto”. Un 304 Not Modified è più specifico: il client ha inviato una richiesta condizionale, cioè “dammi questa pagina, ma solo se è cambiata”, e il server ha stabilito che non è cambiata. Invece del 200 che avrebbe inviato altrimenti, risponde 304 senza alcun body. Questa è la regola effettiva: un 304 è sempre e soltanto la risposta a un GET/HEAD condizionale la cui condizione è risultata falsa.

Una seconda visita è il modo tipico in cui succede ed è un buon modello mentale: la prima volta che un browser o un crawler recupera una pagina, riceve un normale 200 con tutto il contenuto, più un paio di piccoli header “impronta”. Alla visita successiva, il client mostra quell’impronta al server e chiede: “è ancora uguale?”. Se non è cambiato nulla, il server risponde 304 senza inviare alcun body e il client riutilizza la copia che aveva già. Ma “seconda visita” è l’esempio, non la regola del protocollo: ciò che attiva davvero un 304 è la richiesta condizionale, in qualunque modo arrivi. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

Perché appartiene alla famiglia dei “redirect” ma non è un redirect

Il 304 inizia con 3, la classe che HTTP usa per i redirect. Questo confonde continuamente. Ma un 304 non ha alcun header Location e non invia a un indirizzo diverso: non si sposta nessuno. Riporta semplicemente il client alla propria copia salvata. Quindi “famiglia dei redirect” è una stranezza della numerazione, non ciò che il codice fa.

Un 304 è un problema?

No. Vedere 304 nella scheda di rete del browser o in un report di crawl indica che la cache funziona, esattamente ciò che vuoi. Molti consigli del tipo “errore 304, come risolverlo” trattano il codice come qualcosa di rotto sul tuo sito. Non lo è: è il risultato corretto e previsto di una cache che si comporta bene.

Aiuta la SEO?

Non direttamente le tue posizioni. Google ha già il contenuto dall’ultima scansione della pagina: un 304 conferma soltanto che non è cambiato e Google continua a usare ciò che aveva memorizzato (Search può comunque ricalcolare i segnali di un URL, ma il 304 in sé non è un bonus di ranking o indicizzazione). Dove aiuta davvero è nell’efficienza delle risorse: se un motore di ricerca non deve riscaricare pagine che non sono cambiate, risparmia banda e calcolo da entrambe le parti. Google dice che questo può migliorare indirettamente l’efficienza del crawling, ma non garantisce che lo sforzo risparmiato venga automaticamente riallocato alle pagine nuove o aggiornate. Conta soprattutto sui siti grandi con molte pagine che cambiano raramente.

Vuoi conoscere i meccanismi reali, gli ETag, If-None-Match, i validator forti e deboli, l’implementazione e ciò che Google ha davvero detto? Passa alla scheda Advanced.

TL;DR — 304 è la risposta a un GET/HEAD condizionale la cui condizione risulta falsa e che altrimenti avrebbe ricevuto un 200 (RFC 9110 §15.4.5). Appartiene alla classe 3xx ma non è un redirect: niente Location, nessun nuovo URL e, normativamente, nessun body (“it cannot contain content or trailers”). La condizione è trasportata da If-None-Match (rispetto a un ETag) e/o If-Modified-Since (rispetto a Last-Modified); se il validator corrisponde ancora, il server restituisce 304 e il client riutilizza la cache. Impatto SEO: nessun effetto diretto sul ranking — Google ha già il contenuto, anche se Search può ancora ricalcolare i segnali di un URL — e un vantaggio di risparmio di risorse sui siti grandi (Google dice che può migliorare indirettamente l’efficienza del crawling; non promette la riallocazione automatica del crawl budget verso altri URL). L’infrastruttura di crawling di Google supporta entrambi i validator e raccomanda ETag come principale, perché non ha i problemi di formattazione delle date. Non confonderlo con 301/302/307/308, che spostano l’URL, né con 204, anch’esso senza body ma perché non c’è davvero nulla da inviare.

Che cosa significa 304 nella specifica

RFC 9110 (HTTP Semantics) §15.4.5 lo definisce con precisione: «Il codice di stato 304 (Not Modified) indica che è stata ricevuta una richiesta GET o HEAD condizionale che avrebbe prodotto una risposta 200 (OK), se la condizione non fosse risultata falsa». Questo è il trigger normativo effettivo: un GET/HEAD condizionale la cui condizione è falsa e che altrimenti avrebbe ricevuto 200. In termini semplici: il client chiede “dammi questa pagina, ma solo se è cambiata”, il server stabilisce che non è cambiata e salta l’invio del body. Una “seconda visita” è l’esempio quotidiano di come una richiesta diventa condizionale (il client allega un validator salvato da una risposta precedente), ma è un esempio didattico, non la regola: la specifica non richiede una visita precedente, soltanto una richiesta condizionale. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

La specifica usa perfino la parola «redirecting» in questa sezione: il server reindirizza il client a usare quella rappresentazione salvata come se fosse il contenuto di una risposta 200 (OK). Ma leggila con attenzione: sta reindirizzando il client alla propria cache, non a un altro URL. Non c’è header Location e non c’è un nuovo indirizzo. Questa singola frase è all’origine della maggior parte della confusione sul fatto che 304 «sia un redirect». In senso HTTP non lo è.

Sono importanti anche altri due punti normativi:

• Nessun body, mai. RFC 9110: “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (traduzione) «Una risposta 304 termina alla fine della sezione degli header; non può contenere contenuto o trailer». Un 304 che invia un body viola la specifica e alcuni client lo gestiranno male. È una regola rigida, non una preferenza stilistica. La stessa specifica afferma: “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (traduzione) «Il codice di stato 304 (Not Modified) indica che è stata ricevuta una richiesta GET o HEAD condizionale che avrebbe prodotto una risposta 200 (OK), se la condizione non fosse risultata falsa.» Google aggiunge: “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (traduzione) «Raccomandiamo vivamente di usare ETag perché è meno soggetto a errori e sbagli: il valore non è strutturato, a differenza di Last-Modified»; e: “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) «La nostra raccomandazione è richiedere un refresh della cache per cambiamenti significativi del contenuto; se hai aggiornato solo la data di copyright in fondo alla pagina, probabilmente non è significativo».
• Trasporta gli stessi metadati che avrebbe un 200. Il server deve generare gli header che avrebbe inviato in una risposta 200 (OK) alla stessa richiesta — Content-Location, Date, ETag e Vary — oltre a Cache-Control ed Expires dove applicabile. Un 304 è quindi gli header del 200 senza il payload.

Come funziona davvero un 304: richieste condizionali

Un server non invia mai un 304 dal nulla. È sempre una risposta a una richiesta condizionale, resa tale dal client tramite un validator salvato da una risposta precedente. Esistono due validator.

ETag e If-None-Match

Un ETag (entity tag) è un token opaco che il server allega a una risposta 200: consideralo l’impronta della versione di quella precisa rappresentazione dell’URL. Alla richiesta successiva per quell’URL, il client rimanda il valore salvato nell’header If-None-Match. Il server confronta i valori: se l’ETag corrente corrisponde ancora, non è cambiato nulla e restituisce 304; se è diverso, restituisce un 200 fresco con il nuovo contenuto e un nuovo ETag.

Last-Modified e If-Modified-Since

L’alternativa basata sulla data: il server invia un timestamp Last-Modified nel 200. La volta successiva, il client lo rimanda nell’header If-Modified-Since e il server confronta le date: se la risorsa non è cambiata da quel timestamp, restituisce 304. È più semplice ma più grossolana (precisa solo quanto il timestamp) e sensibile alla formattazione esatta della data HTTP, una fonte comune di bug. Quando entrambi i validator sono presenti, If-None-Match (l’ETag) ha la precedenza su If-Modified-Since.

ETag forti e deboli

Un ETag può essere forte o debole e la differenza conta. Secondo le indicazioni MDN sulle richieste condizionali, la validazione forte garantisce che la risorsa sia identica byte per byte a quella con cui viene confrontata. Un ETag debole ha il prefisso W/ (per esempio ETag: W/"abc123") e afferma soltanto l’equivalenza semantica: l’esempio di MDN è che una pagina diversa da un’altra solo per una data diversa nel footer o per pubblicità diversa sarebbe considerata identica con la validazione debole. Gli ETag forti (senza prefisso) sono necessari per cose come le richieste di intervallo che richiedono una corrispondenza byte per byte; quelli deboli sono utili quando compressione, spazi bianchi o differenze banali non sostanziali non devono forzare un nuovo download completo. La trappola pratica: se l’ETag cambia ogni volta che il contenuto viene ricompresso con gzip/Brotli o varia tra server bilanciati, provocherai ricrawl inutili. Scegli deliberatamente forte o debole e mantieni stabile il valore per contenuti davvero invariati.

L’handshake completo, passo dopo passo

1. Prima richiesta → il server restituisce 200 OK con il contenuto, più ETag e/o Last-Modified.
2. Il client salva il contenuto e quei validator.
3. Richiesta successiva → il client invia If-None-Match e/o If-Modified-Since con i valori salvati.
4. Il server decide: invariato → 304 Not Modified, nessun body e il client riutilizza la cache; cambiato → 200 OK con il nuovo body e validator aggiornati. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation

Se vuoi approfondire cache e validator come leva per l’efficienza del crawling, cioè l’intera storia delle richieste condizionali e il collegamento con il crawl budget, questo è un argomento complementare; questo articolo si concentra sul codice di stato.

304 e SEO: nessun effetto sul ranking, un effetto reale sull’efficienza del crawl

Ecco l’intera storia SEO, più circoscritta di quanto facciano pensare molti testi boilerplate dei blog. 304 non ha alcun effetto diretto sul ranking e le indicazioni di Google su come i codici di stato influenzano crawling e indicizzazione delimitano anche l’effetto sull’indicizzazione: Search può ricalcolare i segnali di un URL, ma per il resto un 304 non cambia il modo in cui la pagina viene indicizzata. Google ha già il contenuto dal crawl precedente; un 304 conferma soltanto che non è cambiato e Google continua a usare ciò che possiede. Restituire 304 non dà alcun bonus di ranking.

Ciò che il 304 ti offre sono risparmi di risorse che possono migliorare indirettamente l’efficienza del crawl. Nel post di Google Search Central del dicembre 2024 sulla cache HTTP, Gary Illyes lo ha detto chiaramente: “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (traduzione) «Soprattutto se hai un sito grande con contenuti che cambiano raramente nei singoli URL, consentire la cache locale può aiutare il sito a essere sottoposto a crawl in modo più efficiente.»

Sul meccanismo esatto del 304, lo stesso post spiega chiaramente perché il body vuoto è il punto: “If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (traduzione) «Se il valore ETag inviato dal crawler corrisponde al valore corrente generato dal server, il server dovrebbe restituire una risposta HTTP 304 (Not Modified) senza body». Quel body assente conta perché il server non deve spendere risorse di calcolo per generare contenuto né trasferire il body HTTP. Risparmi calcolo e banda da entrambe le parti. La formulazione di Google per il beneficio a valle è condizionale: questi risparmi di risorse possono migliorare indirettamente l’efficienza del crawl. Non è una promessa che lo sforzo risparmiato venga automaticamente riallocato ai tuoi URL nuovi o aggiornati: trattalo come un meccanismo di risparmio delle risorse con un vantaggio a cascata plausibile, non garantito.

Perché conta di più sui siti grandi

Se hai qualche centinaio di pagine, il tema è in gran parte teorico: Google esplorerà comodamente l’intero sito. Il vantaggio cresce con le dimensioni: un sito con centinaia di migliaia o milioni di URL, molti dei quali cambiano raramente, trae un beneficio concreto quando i crawler possono evitare di riscaricare quelli invariati. È il pubblico a cui si rivolge il post di Google e questa è la cornice onesta da mantenere: non vendere il 304 come tattica per siti piccoli.

ETag o Last-Modified: che cosa conta come “cambiato”

Google raccomanda ETag come validator principale perché è meno soggetto a errori e sbagli: il valore non è strutturato, a differenza di Last-Modified. Impostare entrambi va bene ed è incoraggiato. Se usi Last-Modified, la data deve essere formattata secondo lo standard HTTP: Google raccomanda il formato “Weekday, DD Mon YYYY HH:MM:SS Timezone,” (traduzione) «Giorno della settimana, GG Mmm AAAA HH:MM:SS Fuso orario», per esempio “Fri, 4 Sep 1998 19:15:56 GMT” (traduzione) «Ven, 4 set 1998 19:15:56 GMT», altrimenti potrebbe essere ignorata in silenzio. Google suggerisce anche di impostare il campo max-age di Cache-Control per aiutare i crawler a decidere quando ripetere il crawl.

Decidere quale cambiamento sia abbastanza importante da invalidare la cache spetta a te, ma il consiglio di Google è riservarlo ai cambiamenti sostanziali: richiedi un refresh della cache quando il contenuto cambia in modo significativo; se hai aggiornato soltanto la data di copyright in fondo alla pagina (traduzione) «la data di copyright in fondo alla pagina», probabilmente non è significativo.

Che cosa fanno davvero Googlebot e Bingbot

Non ogni richiesta del crawler è condizionale. La documentazione sui crawler di Google osserva che i singoli crawler e fetcher Google variano nel supporto alla cache in base al prodotto che servono: Googlebot supporta la cache durante il ricrawl degli URL per Search, mentre altri fetcher Google la supportano solo in determinate condizioni. Anche con header configurati correttamente, quindi, non aspettarti che il 100% delle richieste contenga If-None-Match/If-Modified-Since. Per Bing: le richieste condizionali non sono una funzione esclusiva di Google. Il crawler di Bing supporta richieste GET condizionali (inviando If-Modified-Since e, quando disponibile, If-None-Match, e accettando un 304 se il contenuto è invariato) almeno dal post del blog Live Search del 2008, anche se Bing non ha pubblicato un equivalente moderno dell’articolo di Google del 2024. Considera questi meccanismi comportamento HTTP generico applicabile a entrambi i motori.

Come implementare il supporto al 304

1. Invia i validator nel 200. Configura server, CDN o app per allegare un ETag (raccomandato) e/o un header Last-Modified formattato correttamente alle risposte normali 200. Molti server e framework generano automaticamente gli ETag per i file statici; le risposte dinamiche di solito richiedono un’attivazione esplicita.
2. Rispetta gli header condizionali al ritorno. Quando arriva una richiesta con If-None-Match/If-Modified-Since, confronta il validator corrente e restituisci 304 (senza body) se corrisponde ancora, oppure un 200 fresco se non corrisponde. Anche in questo caso i server di file statici spesso lo fanno per te; route applicative e edge worker spesso no, a meno che tu non li configuri.
3. Decidi che cosa significa “cambiato” e mantieni stabile l’ETag per contenuti davvero invariati: non lasciare che ricompressione o differenze tra server lo facciano cambiare inutilmente.
4. Controlla le configurazioni errate classiche:
   • Sempre-200: non emetti mai validator, quindi nessuna richiesta è condizionale e non ottieni il vantaggio di efficienza.
   • ETag instabili: un valore che cambia anche quando il contenuto non cambia (bilanciatori, ricompressione), costringendo a riscaricamenti continui.
   • 304 obsoleti: il caso pericoloso, un server che continua a restituire 304 (o un ETag invariato) dopo che il contenuto è davvero cambiato, così crawler e cache non ricevono mai l’aggiornamento. È un bug da individuare nell’analisi dei log, non un difetto intrinseco del 304.

304 rispetto agli altri codici di stato

304 rispetto a 301 / 302 / 307 / 308

Quelli sono i redirect veri. Un 301/308 (permanente) o 302/307 (temporaneo) porta un header Location e sposta il client verso un URL diverso; 301/308 trasferiscono anche un segnale di canonizzazione. Un 304 non ha Location, non sposta nessuno e non trasferisce segnali di ranking. Stessa famiglia 3xx per numerazione, lavoro completamente diverso. I dettagli dei singoli redirect sono negli articoli dedicati (vedi l’articolo sul redirect 301 e il sub-hub dei redirect).

304 rispetto a 204 No Content

Entrambi non hanno body, ma per ragioni completamente diverse. Un 204 No Content è un successo 2xx con body intenzionalmente vuoto perché il server non ha davvero nulla da inviare, per esempio una DELETE/PUT API completata o un beacon analitico. Un 304 non invia body non perché non ci sia nulla da inviare, ma perché “lo hai già e la copia è ancora valida”. Non confonderli: un 204 su un URL di pagina può essere trattato come un soft 404 perché non c’è contenuto indicizzabile, mentre un 304 conferma la validità di contenuto che Google possiede già. L’articolo 204 No Content tratta quel codice in dettaglio.

Miti comuni sul 304

1. “304 è un redirect”. Nessun header Location, nessuno si sposta. Il client riutilizza la propria copia in cache. Il riferimento della RFC 9110 al reindirizzare il client verso la rappresentazione salvata significa riportarlo alla cache, non a un altro URL.
2. “304 è un errore da correggere”. È il risultato corretto e previsto di una configurazione funzionante per le richieste condizionali. Vedere 304 in un crawl o nei DevTools indica che la cache funziona: è il fraintendimento più comune nella SERP.
3. “304 aiuta il ranking”. Non esiste alcun effetto diretto sul ranking e Google delimita anche l’effetto sull’indicizzazione: Search può ricalcolare i segnali di un URL, ma per il resto un 304 non cambia l’indicizzazione. Il vantaggio è il risparmio di risorse che Google dice possa migliorare indirettamente l’efficienza del crawl sui siti molto grandi; non è un segnale di ranking né una garanzia che lo sforzo risparmiato passi ad altri URL.
4. “If my server returns 304, Google will use stale content forever.” (traduzione) «Se il mio server restituisce 304, Google userà per sempre contenuto obsoleto». Il 304 scatta solo finché il validator corrisponde ancora. Nel momento in cui il contenuto cambia davvero, un server correttamente implementato restituisce un 200 fresco con nuovi validator. Il rischio reale è un server configurato male che continua a restituire 304 dopo il cambiamento: è un bug, non una proprietà del 304. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation
5. “ETag e Last-Modified sono intercambiabili”. Entrambi sono validator, ma Last-Modified è sensibile al formato della data e preciso solo quanto il suo timestamp, mentre ETag è opaco e preciso (e può variare in modo problematico tra server o dopo una ricompressione se implementato senza attenzione). Google raccomanda ETag come principale; se puoi, imposta entrambi.

Domande frequenti

HTTP 304 è un errore? No: è un segnale di successo che indica che la cache funziona. Significa che la copia memorizzata dal client è ancora valida.

304 Not Modified è un redirect? No. Appartiene alla classe 3xx per numerazione, ma non ha un header Location e non sposta il client verso un nuovo URL.

Il 304 aiuta la SEO o il ranking? Nessun effetto diretto sul ranking e nessun effetto sull’indicizzazione oltre al possibile ricalcolo dei segnali di un URL da parte di Google. Risparmia banda e calcolo permettendo ai crawler di saltare le pagine invariate; Google dice che questo può migliorare indirettamente l’efficienza del crawl sui siti grandi.

Qual è la differenza tra ETag e Last-Modified? ETag è un’impronta opaca della versione, confrontata tramite If-None-Match; Last-Modified è un timestamp, confrontato tramite If-Modified-Since. Google raccomanda ETag perché è meno soggetto a errori.

Che cos’è un ETag forte rispetto a uno debole? Un ETag forte afferma che il contenuto è identico byte per byte; un ETag debole (con prefisso W/) afferma l’equivalenza semantica e tollera differenze banali, come la compressione o una data del footer cambiata.

Perché vedo 304 nei log o nei report di crawl? Perché i client inviano richieste condizionali e il server conferma correttamente che il contenuto non è cambiato. È previsto ed è positivo.

Come faccio a far restituire correttamente 304 al server? Invia ETag/Last-Modified nel 200, poi rispetta If-None-Match/If-Modified-Since nella richiesta successiva restituendo 304 senza body quando il validator corrisponde ancora.

Qual è la differenza tra 304 e 204? Entrambi non hanno body: il 204 perché non c’è nulla da inviare, il 304 perché possiedi già una copia ancora valida.

Googlebot invia header condizionali in ogni richiesta? No: il supporto alla cache varia in base al crawler, quindi non ogni richiesta sarà condizionale anche quando gli header sono configurati.

Una risposta 304 può avere un body? No. Secondo RFC 9110, “it cannot contain content or trailers” (traduzione) «non può contenere contenuto o trailer». Un 304 con body viola la specifica.

Riepilogo AI

Una sintesi della versione Advanced:

• 304 Not Modified è la risposta a un GET/HEAD condizionale la cui condizione risulta falsa e che altrimenti avrebbe ricevuto 200 (RFC 9110 §15.4.5). Appartiene alla classe 3xx ma NON è un redirect: nessun header Location, nessun nuovo URL e, normativamente, nessun body: “it cannot contain content or trailers” (traduzione) «non può contenere contenuto o trailer». Una seconda visita è l’esempio tipico di come una richiesta diventa condizionale, non la regola del protocollo.
• È la risposta a una richiesta condizionale. Un GET/HEAD che porta If-None-Match (confrontato con un ETag) e/o If-Modified-Since (confrontato con Last-Modified). Se il validator corrisponde ancora, il server restituisce 304 e il client riutilizza la copia in cache.
• La parola “redirecting” della specifica è metaforica: rimanda il client alla propria cache, non a un altro URL. Quella frase causa gran parte della confusione sul fatto che un 304 sia un redirect.
• ETag rispetto a Last-Modified: ETag è un token opaco di versione (confrontato tramite If-None-Match); Last-Modified è una data (confrontata tramite If-Modified-Since, con formattazione HTTP-date esatta obbligatoria). If-None-Match prevale quando sono presenti entrambi. ETag forte = identico byte per byte; ETag debole (prefisso W/) = equivalenza semantica.
• Nessun effetto diretto sul ranking e nessun effetto sull’indicizzazione oltre al possibile ricalcolo dei segnali di un URL da parte di Google. Google possiede già il contenuto; il 304 conferma soltanto che non è cambiato. Come ha spiegato Gary Illyes, la cache può aiutare il sito a essere sottoposto a crawl in modo più efficiente: il vantaggio è un risparmio di risorse che può migliorare indirettamente l’efficienza del crawl sui siti grandi, non una riallocazione garantita del crawl budget e non un segnale di ranking.
• Google raccomanda ETag come principale perché è meno soggetto a errori e sbagli: “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (traduzione) «Raccomandiamo vivamente di usare ETag perché è meno soggetto a errori e sbagli»; va bene impostare entrambi e Last-Modified deve usare il formato “Weekday, DD Mon YYYY HH:MM:SS Timezone” (traduzione) «Giorno della settimana, GG Mmm AAAA HH:MM:SS Fuso orario»; invalida la cache solo per cambiamenti significativi, non per una data di copyright nel footer (traduzione) «la data di copyright in fondo alla pagina».
• Il supporto alla cache varia in base al crawler: non ogni richiesta di Googlebot è condizionale. Bing supporta il GET condizionale almeno dal post Live Search del 2008; è comportamento HTTP generico.
• Da non confondere con 301/302/307/308, redirect reali che spostano l’URL, o 204 No Content, anch’esso senza body ma perché non c’è davvero nulla da inviare.
• Il rischio vero non è il 304 in sé, ma un server configurato male che restituisce 304 dopo che il contenuto è cambiato: intercettalo nell’analisi dei log. Un 304 valido può anche sembrare un errore in alcune librerie client o negli strati di cache della piattaforma, pur non essendoci nulla di sbagliato.

Documentazione ufficiale

Riferimenti da fonti primarie per capire che cos’è 304 e come lo usano i motori di ricerca.

Specifica HTTP e riferimento browser

• RFC 9110 §15.4.5 — stato HTTP 304 — la definizione autorevole: richiesta condizionale, nessun body, header obbligatori.
• MDN — stato HTTP 304 — spiegazione in linguaggio semplice, trigger If-None-Match/If-Modified-Since ed elenco degli header che un 304 deve portare.
• MDN — HTTP conditional requests — spiegazione della validazione forte e debole.
• MDN — ETag — l’header ETag, inclusa la sintassi debole (W/) rispetto a quella forte.

Google Search Central

• Crawling December: HTTP caching — il post di Gary Illyes del 9 dicembre 2024: come ETag/If-None-Match e Last-Modified/If-Modified-Since producono i 304 e perché aiutano l’efficienza del crawl.
• Google Crawler (User Agent) Overview — quali crawler Google supportano la cache e la raccomandazione di preferire ETag a Last-Modified.
• How HTTP status codes affect Google’s crawlers — la riga attuale di Google sul 304, compresa la precisazione che Search può ricalcolare i segnali di un URL anche se il 304 non ha altrimenti effetti sull’indicizzazione.
• Troubleshoot Google Search crawling errors — la fonte della formulazione condizionale di Google secondo cui il risparmio di risorse delle richieste condizionali “may indirectly” migliorare l’efficienza del crawl e del fatto che Google non invii header condizionali a ogni tentativo di crawl.

Bing

• Annuncio di miglioramenti al crawler per Live Search — il vecchio post Bing/Live Search che conferma il supporto al GET condizionale (If-Modified-Since/If-None-Match → 304) dal 2008.

Citazioni dalla fonte

Dichiarazioni pubbliche. Ogni link è un deep link che porta al passaggio citato nella pagina sorgente in cui la fonte lo supporta.

La specifica HTTP

• “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (traduzione) «Il codice di stato 304 (Not Modified) indica che è stata ricevuta una richiesta GET o HEAD condizionale che avrebbe prodotto una risposta 200 (OK), se la condizione non fosse risultata falsa.» — RFC 9110, HTTP Semantics, §15.4.5. Leggi la sezione
• “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (traduzione) «Una risposta 304 termina alla fine della sezione degli header; non può contenere contenuto o trailer». — RFC 9110, §15.4.5 (la regola normativa “no body, ever” (traduzione) «nessun body, mai»). Leggi la sezione

MDN Web Docs

• “The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.” (traduzione) «Il codice di stato della risposta HTTP di redirection 304 Not Modified indica che non è necessario ritrasmettere le risorse richieste.» Vai alla citazione
• “Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (traduzione) «La validazione forte consiste nel garantire che la risorsa sia identica byte per byte a quella con cui viene confrontata.» — MDN, “HTTP conditional requests.” Leggi la guida

Gary Illyes, Google: “Crawling December: HTTP caching” (9 dicembre 2024)

• «Soprattutto se hai un sito grande con contenuti che cambiano raramente nei singoli URL, consentire la cache locale può aiutare il sito a essere sottoposto a crawl in modo più efficiente. L’infrastruttura di crawling di Google supporta la cache HTTP euristica definita dallo standard HTTP, in particolare tramite gli header di risposta ETag e Last-Modified e gli header di richiesta If-None-Match e If-Modified-Since». (Traduzione italiana dell’originale citato nella sezione avanzata.) Leggi il post
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (traduzione) «Raccomandiamo vivamente di usare ETag perché è meno soggetto a errori e sbagli: il valore non è strutturato, a differenza di Last-Modified». Leggi il post
• “If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (traduzione) «Se il valore ETag inviato dal crawler corrisponde al valore corrente generato dal server, il server dovrebbe restituire una risposta HTTP 304 (Not Modified) senza body». Leggi il post
• “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) «La nostra raccomandazione è richiedere un refresh della cache per cambiamenti significativi del contenuto; se hai aggiornato solo la data di copyright in fondo alla pagina, probabilmente non è significativo». Leggi il post

Fonte Ahrefs — Patrick Stox

• “304 Not Modified – Says the page hasn’t been modified. Typically used for caching.” (traduzione) «304 Not Modified: indica che la pagina non è stata modificata. In genere viene usato per la cache». — dalla mia guida Codici di stato HTTP e loro impatto SEO (questo articolo è l’approfondimento che quella voce non aveva). Vai alla citazione

304 nel contesto: i codici senza body e 3xx con cui viene confuso

304 rispetto ai codici simili — il formato HTTP-date raccomandato è “Weekday, DD Mon YYYY HH:MM:SS Timezone” (traduzione) «Giorno della settimana, GG Mmm AAAA HH:MM:SS Fuso orario».

La trappola: 304 e 204 non hanno entrambi body, e 304/301/302/307/308 sono tutti 3xx; ma 304 è l’eccezione su entrambi gli assi. È l’unico 3xx che non sposta nessuno e l’unico codice senza body che significa “lo hai già” invece di “non c’è nulla da inviare”.

I due validator

Quando sono presenti entrambi, If-None-Match ha la precedenza su If-Modified-Since.

Fatti rapidi

• 304 non ha mai un body: RFC 9110 lo rende normativo.
• 304 è un codice 3xx ma non è un redirect (niente Location, nessun nuovo URL).
• Nessun effetto diretto sul ranking e nessun effetto sull’indicizzazione oltre al possibile ricalcolo dei segnali di un URL da parte di Google: il vantaggio è un risparmio di risorse che può aiutare indirettamente l’efficienza del crawl sui siti grandi.
• Google raccomanda ETag come principale; impostare sia ETag sia Last-Modified va bene.
• Last-Modified deve usare il formato «giorno della settimana, giorno mese anno ora:minuto:secondo fuso orario», altrimenti potrebbe essere ignorato.
• Invalida la cache per cambiamenti significativi del contenuto, non per una data di copyright nel footer.
• Non ogni richiesta del crawler è condizionale: il supporto alla cache varia in base al crawler.
• Bing supporta il GET condizionale → 304 dal 2008; è comportamento HTTP generico.
• Il rischio reale è un 304 obsoleto (il server restituisce 304 dopo un cambiamento del contenuto): intercettalo nell’analisi dei log.

Handshake della richiesta condizionale, in HTTP grezzo

Catene concrete di richieste e risposte che mostrano come nasce un 304. (I valori degli header sono illustrativi.)

ETag / If-None-Match: primo fetch (200)

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

<full page body here>

Il client salva il body e il valore di ETag.

ETag / If-None-Match: fetch successivo, contenuto invariato (304)

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 304 Not Modified
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

Nessun body. L’ETag corrispondeva, quindi il server ha risparmiato il calcolo necessario a generare la pagina e la banda necessaria a inviarla. Il client riutilizza la copia in cache.

Last-Modified / If-Modified-Since: l’equivalente basato sulla data

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT

Nota il formato esatto della data HTTP, «giorno della settimana, giorno mese anno ora:minuto:secondo fuso orario», che Google raccomanda per evitare problemi di parsing.

Quando il contenuto È cambiato: un 200 fresco, non un 304

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "e5f6g7h8"          ← new value: content changed

<updated page body here>

L’ETag salvato non corrisponde più, quindi il server invia il nuovo contenuto e un nuovo validator. La cache si aggiorna. È esattamente per questo che un 304 implementato correttamente non può “intrappolare” un crawler su contenuto obsoleto: nel momento in cui il contenuto cambia, cambia il validator e la richiesta successiva riceve un vero 200.

ETag debole e forte

ETag: "a1b2c3d4"      ← strong: asserts byte-for-byte identity
ETag: W/"a1b2c3d4"    ← weak: asserts semantic equivalence (the W/ prefix)

Regola pratica: se gestisci un sito grande con molti URL che cambiano raramente, inviare un ETag stabile (e rispettare If-None-Match) sui tuoi 200 permette ai crawler di confermare “è ancora uguale” con un 304 economico e senza body, risparmiando banda e calcolo che, secondo Google, possono migliorare indirettamente l’efficienza con cui viene esplorato il resto del sito. Se il tuo ETag cambia a ogni ricompressione o tra server bilanciati, perdi questo vantaggio.

Errori 304 che rompono la cache condizionale

Cambiare l’ETag quando la rappresentazione non è cambiata

Un ETag legato a un’istanza del server, a un passaggio di compressione o al timestamp della richiesta vanifica il validator: il contenuto invariato continua a restituire un 200 completo. Genera un validator stabile dalla rappresentazione oppure usa deliberatamente un ETag debole quando le differenze a livello di byte non sono significative.

Restituire 304 dopo che il contenuto è cambiato

Un validator obsoleto può nascondere un aggiornamento reale a client e crawler. Invalida l’ETag o fai avanzare Last-Modified ogni volta che cambia la rappresentazione, poi conferma che la vecchia richiesta condizionale riceva un 200 fresco con body.

Inviare 304 senza una richiesta condizionale corrispondente

Un server non dovrebbe indovinare che il client abbia una copia in cache. Restituisci 304 solo dopo aver valutato If-None-Match o If-Modified-Since; una prima richiesta normale ha bisogno di una risposta completa.

Trattare 304 come un redirect o una pagina vuota

Un 304 non ha header Location né body di risposta. Non instradarlo nella logica dei redirect e non sostituire una risorsa realmente vuota con 304: usa lo stato che descrive la risposta effettiva.

Problemi comuni con 304

Il server restituisce sempre 200

Sintomo: richieste ripetute scaricano il body completo anche quando non è cambiato nulla. Causa probabile: la risposta iniziale non ha un validator oppure l’applicazione ignora gli header della richiesta condizionale. Correzione: invia ETag e/o un Last-Modified valido, poi implementa il controllo corrispondente If-None-Match o If-Modified-Since. Conferma che una richiesta invariata restituisca un 304 senza body.

Server d’origine diversi producono ETag diversi

Sintomo: lo stesso URL invariato alterna 200 e 304 dietro un bilanciatore. Causa probabile: ogni nodo genera il proprio validator. Correzione: deriva l’ETag dallo stato condiviso del contenuto, non dal nodo che serve la risposta, e ripeti la stessa richiesta condizionale su più risposte.

Il contenuto aggiornato continua a restituire 304

Sintomo: dopo un deploy, un browser o un crawler continua a vedere una rappresentazione vecchia. Causa probabile: il validator non è stato invalidato insieme al contenuto. Correzione: correggi la chiave di cache o la logica di distribuzione, svuota la cache interessata dove necessario e dimostra che il vecchio ETag ora riceve un 200 con un nuovo validator.

Last-Modified sembra ignorato

Sintomo: If-Modified-Since non produce mai un 304. Causa probabile: una data HTTP non valida, precisione insufficiente del timestamp o un ETag che ha la precedenza. Correzione: ispeziona gli header grezzi, correggi il formato della data e testa ogni validator separatamente.

Un 304 sembra un errore nel codice dell’applicazione

Sintomo: uno script o un’app genera un’eccezione o registra un “errore” per una richiesta che in realtà ha ricevuto 304. Causa probabile: alcune librerie client HTTP trattano qualsiasi stato diverso da 200, incluso un 304 valido, come una condizione simile a un’eccezione, a meno che tu non configuri esplicitamente la gestione dei redirect o l’accettazione delle risposte not-modified; è una particolarità della libreria client, non un problema del protocollo o del server. Correzione: controlla come la libreria gestisce nello specifico il 304 (non solo la gestione degli errori 4xx/5xx) e conferma che la risposta HTTP grezza sia un 304 corretto e senza body prima di attribuire la colpa al server.

Uno strato di cache della piattaforma (per esempio output caching di IIS) confonde il quadro

Sintomo: l’app d’origine sembra corretta, ma il comportamento 304 continua a sembrare sbagliato. Causa probabile: uno strato di cache specifico della piattaforma di hosting, per esempio l’output caching di IIS, si trova tra app e client e può generare o intercettare autonomamente le risposte 304. Correzione: consideralo uno dei possibili strati, insieme ad app d’origine, CDN, bilanciatore e cache della piattaforma, non il sospetto predefinito; isolalo con un test controllato che cambi il validator in ogni strato uno alla volta prima di concludere quale sia responsabile.

Prompt: controlla una traccia di richiesta condizionale

Incolla gli header di richiesta e risposta di un fetch iniziale e di un fetch ripetuto.

Act as an HTTP caching reviewer. I will paste two request/response header traces for
the same URL: an initial fetch and a conditional repeat. Identify the validator used,
check whether If-None-Match or If-Modified-Since was evaluated correctly, verify that
a 304 has no body or Location header, and flag unstable or stale-validator risks.
Return: observed flow, pass/fail checks, likely cause of each failure, and the exact
next request I should run. Do not infer headers that are not present.

[PASTE BOTH TRACES]

Prompt: esamina un’implementazione ETag

Incolla la configurazione pertinente dell’applicazione, della CDN o del server.

Review this ETag/Last-Modified implementation for conditional GET correctness. Trace
the 200 -> conditional request -> 304 path, explain what causes the validator to
change, and test mentally for multiple origin nodes, compression variants, and real
content updates. Separate protocol violations from efficiency issues. Give a minimal
fix and a curl-based validation plan. Do not invent platform behavior.

[PASTE CONFIGURATION OR CODE]

Shell: riproduci un ETag come richiesta condizionale

Esegui questo comando in un terminale macOS/Linux. Copia l’ETag esattamente, comprese le virgolette.

URL='https://example.com/page'
curl -sS -D - -o /dev/null "$URL"
curl -sS -D - -o /dev/null -H 'If-None-Match: "PASTE_ETAG_HERE"' "$URL"

La prima risposta dovrebbe esporre il validator. La seconda dovrebbe restituire 304 quando la rappresentazione è invariata e 200 quando l’ETag incollato è obsoleto.

PowerShell: testa Last-Modified

Esegui in PowerShell dopo aver sostituito URL e timestamp.

$url = 'https://example.com/page'
$headers = @{ 'If-Modified-Since' = 'Tue, 14 Jul 2026 12:00:00 GMT' }
Invoke-WebRequest -Uri $url -Headers $headers -SkipHttpErrorCheck

Console DevTools: elenca i validator delle risorse della pagina

Esegui nella Console del browser. Riporta le voci di resource timing; usa il pannello Network per ispezionare gli header effettivi ETag, Last-Modified e di stato.

console.table(performance.getEntriesByType('resource').map(r => ({name: r.name, transferSize: r.transferSize, encodedBodySize: r.encodedBodySize})));

Strumenti per ispezionare il comportamento 304

• HTTP Header Checker: ispeziona ETag, Last-Modified, Cache-Control, Vary e le impronte della CDN/edge sulla risposta normale prima di riprodurre un validator.
• Pannello Network dei DevTools del browser: disattiva “Disable cache”, ricarica e confronta gli header di richiesta e risposta. DevTools rende visibili anche HSTS e il comportamento della cache locale, quindi distingui il comportamento del browser da ciò che ha inviato l’origine.
• curl: invia un header esatto If-None-Match o If-Modified-Since senza lasciare che lo stato della cache del browser interferisca.
• Log di accesso: quantifica quali richieste dei crawler erano condizionali e se sono terminate in 304 o in un 200 completo.

Dimostra che le risposte condizionali funzionano dopo un cambiamento

Test della rappresentazione invariata

Test da eseguire: recupera l’URL, copia il suo ETag, poi ripeti con curl -I -H 'If-None-Match: "VALUE"' URL. Risultato atteso: 304, il validator corrispondente e nessun body o Location. Interpretazione del fallimento: il server ha ignorato la condizione o ha generato un validator instabile. Finestra di monitoraggio: immediata. Trigger di rollback: la modifica alla cache fa perdere alle richieste normali la risposta 200 completa.

Test della rappresentazione cambiata

Test da eseguire: esegui un vero cambiamento del contenuto, poi riproduci il vecchio ETag. Risultato atteso: 200 con il body aggiornato e un nuovo validator. Interpretazione del fallimento: l’invalidazione della cache è obsoleta. Finestra di monitoraggio: immediatamente dopo che il deploy raggiunge ogni origine. Trigger di rollback: qualsiasi origine restituisce ancora 304 per il vecchio validator dopo il completamento del rilascio.

Test di stabilità tra più origini

Test da eseguire: ripeti abbastanza volte le stesse richieste normali e condizionali da raggiungere il pool di server, registrando ETag e stato. Risultato atteso: rappresentazioni invariate usano validator compatibili e producono 304 in modo coerente. Interpretazione del fallimento: i validator variano in base al nodo o alla codifica senza una strategia Vary corrispondente. Finestra di monitoraggio: immediata, su tutto il pool distribuito. Trigger di rollback: la nuova logica dei validator serve contenuto obsoleto o mescola rappresentazioni tra client.

Misura la salute della cache condizionale

Tasso di successo della rivalidazione condizionale

Metrica: richieste condizionali che terminano in 304 rispetto a un 200 completo. Che cosa indica: se le risorse invariate evitano trasferimenti inutili. Come raccoglierla: raggruppa le richieste dei log di accesso che portano If-None-Match o If-Modified-Since per stato della risposta e classe di URL. Benchmark/intervallo realistico: stabilisci una baseline per tipo di contenuto; le pagine che cambiano spesso non devono essere forzate verso il tasso degli asset statici. Cadenza: settimanale durante il rollout, poi mensile.

Byte evitati nei fetch invariati

Metrica: byte stimati del body di risposta non trasferiti per risposte 304 valide. Che cosa indica: il lato banda del vantaggio di efficienza del crawl. Come raccoglierla: unisci il conteggio dei 304 nei log alla dimensione dell’ultima risposta completa per la stessa classe di URL. Benchmark/intervallo realistico: confronta con la baseline del sito prima della modifica; nessun obiettivo universale si adatta a ogni mix di contenuti. Cadenza: mensile.

Errori dei validator obsoleti

Metrica: URL cambiati che accettano ancora un validator vecchio. Che cosa indica: se l’efficienza viene ottenuta a spese della freschezza. Come raccoglierla: esegui un piccolo campione dopo il deploy riproducendo gli ETag precedenti al deploy. Benchmark/intervallo realistico: qualsiasi risposta obsoleta confermata richiede un’indagine. Cadenza: ogni deploy che modifica la cache o la generazione dei validator.

Mettiti alla prova: 304 Not Modified

Cinque domande rapide su che cosa significa 304 e come funziona. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche