204 No Content: cosa significa

TL;DR — Una risposta 204 No Content significa «la richiesta è andata a buon fine e ti sto inviando deliberatamente una pagina vuota». È un codice di successo, non un errore. Va benissimo per cose come un’app che salva il tuo lavoro in background o un tracker di analytics, ma è sbagliato per una vera pagina web che vuoi posizionare su Google. Un body vuoto non dà a Google nulla da indicizzare, quindi tratta un 204 su una pagina come un soft 404.

Che cos’è davvero un 204

Ogni risposta inviata dal server ha un codice di stato. I codici 2xx indicano «successo». 200 OK — quello che vuoi sulle tue pagine — significa «ecco la pagina», body compreso. Anche 204 No Content significa successo, ma con una particolarità: il server sta dicendo «ho fatto ciò che hai chiesto e intenzionalmente non c’è nulla da mostrarti».

La parola chiave è intenzionalmente. Un 204 non è una pagina che non è riuscita a caricarsi né un URL che non esiste: è una risposta progettata per essere vuota. Pensalo come un cenno del server che dice «fatto» senza restituire nulla.

Perché è un problema per una pagina web

Google indicizza il contenuto di una pagina. Se un URL restituisce un 204, non c’è contenuto da leggere: il body è vuoto per progettazione. La documentazione di Google lo dice chiaramente: “Google wasn’t able to receive any content and therefore can’t process it.” (traduzione) «Google non è riuscito a ricevere alcun contenuto e quindi non può elaborarlo». Una pagina che vuoi posizionare e che restituisce un 204 non dà quindi a Google nulla su cui lavorare, il che significa che non verrà indicizzata; nella pratica, Search Console segnala spesso questi casi allo stesso modo di un soft 404: una pagina che tecnicamente ha avuto «successo», ma non ha nulla che valga la pena indicizzare.

Quindi, quando una pagina che vuoi posizionare compare come 204 in un crawl o in Search Console, è un bug da correggere, non qualcosa da lasciare così.

Quando un 204 va benissimo

La maggior parte dei 204 che vedrai non riguarda affatto pagine:

• App che salvano in background. Fai clic su «salva» e l’app memorizza il tuo lavoro senza ricaricare la pagina: il server può rispondere con un 204.
• Analytics e tracking. I tracker inviano piccole richieste «beacon» per registrare che è successo qualcosa. Non c’è una pagina da restituire, quindi un 204 è esattamente corretto.
• Interfacce di app (API). Quando un sistema dice a un altro di eliminare qualcosa, spesso non c’è nulla da restituire: un 204 dice «fatto».

Nessuno di questi contenuti deve finire su Google, quindi in questi casi un 204 è la risposta corretta, non un errore.

L’unica regola da ricordare

Non restituire mai un 204 per un URL che vuoi far trovare nelle ricerche. Se una pagina è sparita per sempre, usa 404 o 410. Se si è spostata, reindirizzala (301). Se dovrebbe contenere contenuto, correggi ciò che sta servendo una risposta vuota. Vuoi la versione più approfondita — le parole esatte di Google, i casi d’uso di API e beacon e come diagnosticare un 204 accidentale? Passa alla scheda Advanced.

TL;DR — 204 è un codice di successo 2xx conforme alla specifica (RFC 9110 §15.3.5) che restituisce un body vuoto per progettazione: il body deve essere vuoto (e non deve esserci nemmeno Content-Length, neppure 0), e i browser possono rifiutare un 204 che invia contenuto. Non è un errore e non dice nulla sull’esistenza dell’URL; l’RFC non lo limita a un elenco fisso di metodi. Gli usi legittimi sono quasi tutti risposte non-documentali: DELETE/PUT di API REST e beacon di analytics (sendBeacon(), GA4 Measurement Protocol) — anche se i professionisti non concordano sulla frequenza con cui le API dovrebbero usarlo. La conseguenza SEO è circoscritta: la tabella dei codici di stato di Google dice chiaramente che, per un 204: “Google wasn’t able to receive any content and therefore can’t process it” (traduzione) «Google non è riuscito a ricevere alcun contenuto e quindi non può elaborarlo». Una pagina che vuoi posizionare non verrà indicizzata da quella risposta e, nella pratica, questi casi vengono spesso segnalati come soft 404 in Search Console, anche se Google non garantisce né quell’etichetta specifica né un calendario di rimozione. Correggi un 204 accidentale a livello di pagina ripristinando un vero 200 oppure usando 404/410/301 secondo l’intento.

Cosa significa 204 nella specifica

RFC 9110 (HTTP Semantics) è inequivocabile: un 204 indica che «il server ha completato con successo la richiesta e che non c’è altro contenuto da inviare nel body del payload della risposta». È un codice di successo — della stessa famiglia 2xx di 200 OK — con la differenza deliberata che non c’è un body.

Contano tre dettagli operativi. Primo, il body deve essere davvero vuoto: MDN osserva che un 204 “must not include any content or the Content-Length header (browsers may reject responses that include content).” (traduzione) «non deve includere contenuto né l’header Content-Length (i browser possono rifiutare le risposte che includono contenuto)». È un divieto reale, non una convenzione elastica: RFC 9110 §8.6 vieta del tutto Content-Length su un 204, quindi «invia semplicemente Content-Length: 0» (una correzione che ho visto consigliare) non è neppure conforme; la risposta termina nella sezione degli header, punto. Secondo, gli header eventualmente presenti in un 204 — un ETag, un Last-Modified — descrivono la rappresentazione selezionata dopo il completamento dell’azione, non un body che è stato inviato. Terzo, un ETag compare in alcuni 204 (l’esempio di MDN è un PUT che aggiorna una risorsa sul posto), ma l’RFC non richiede che ogni 204 lo includa: non considerarlo scontato. Un 204 è memorizzabile nella cache per euristica in modo predefinito, a meno che il metodo o header espliciti di controllo della cache dicano diversamente.

È fondamentale: 204 non ha nulla a che fare con l’esistenza di un URL. Un endpoint API funzionante può restituire correttamente 204 per sempre. Questa è la differenza rispetto a un 404 (non trovato) o a un 410 (gone): quelli riguardano l’assenza; 204 riguarda una richiesta riuscita che non trasporta deliberatamente alcun payload.

Come tratta Google un 204

Questa è tutta la storia SEO, ed è più circoscritta di quanto facciano pensare i testi standard dei blog dei vendor. Google indicizza i contenuti. Un 204 non ha contenuto. La documentazione ufficiale di Google sui codici di stato dedica al 204 una frase specifica e delimitata: mentre la regola generale dei 2xx è che «Google considera il contenuto per l’elaborazione», la riga dedicata al 204 dice invece che “Google wasn’t able to receive any content and therefore can’t process it.” (traduzione) «Google non è riuscito a ricevere alcun contenuto e quindi non può elaborarlo».

Questo è il confine reale e vale la pena essere precisi su ciò che promette e ciò che non promette. Le indicazioni generali sui 2xx nella stessa pagina dicono che un contenuto vuoto o simile a un errore può essere segnalato come soft 404, ma la riga del 204 non garantisce che ogni 204 finisca sotto quell’etichetta specifica di Search Console, e Google non pubblica un calendario di rimozione. Ciò che è solido è questo: un 204 su un URL di contenuto non fornisce nulla alla pipeline di indicizzazione di Google, quindi dire che l’URL non verrà indicizzato da quella risposta è un’inferenza ragionevole; non la estenderei a una «perdita di ranking garantita a livello di sito» o a un «recupero automatico del crawl budget», perché la documentazione di Google non promette nessuna delle due cose. Nella pratica, Search Console presenta spesso questi casi come soft 404: è il pattern che ho visto e di cui ho scritto, ma considera etichetta e tempistiche del report come comportamento osservato, non come garanzia documentata.

Questa è la posizione che ho sostenuto nei miei articoli. Nella guida Codici di stato HTTP e loro impatto SEO del blog di Ahrefs, nella sezione su come Google gestisce le risposte 2xx, l’ho scritto direttamente: «La maggior parte dei 2xx consente di indicizzare le pagine. Tuttavia, i 204 vengono trattati come soft 404 e non vengono indicizzati». La considero ancora la lettura pratica; la formulazione più precisa e aggiornata del documento di Google è quella sul «non riuscire a ricevere o elaborare il contenuto», ed è quella a cui ti indirizzerei per il confine ufficiale esatto.

I soft 404 sono documentati come casi che continuano a essere sottoposti a crawl e sprecano crawl budget, ma questa è la guida generale di Google sui soft 404, non una promessa specifica sui 204. Usare 204 non libera né reindirizza automaticamente le risorse di crawl; la precisazione di Google è che l’allocazione delle risorse dipende dai limiti di servizio, dalla qualità del sito e dall’inventario, non dal codice di stato che ha attivato l’esclusione. La conclusione sicura è: correggi un 204 accidentale perché impedisce a una pagina di essere indicizzata, non perché ti spetti uno specifico dividendo di crawl budget.

204 a confronto con i codici con cui viene confuso

Il tranello è che 204, 200 vuoto, 404 e 410 possono tutti finire come «soft 404» in GSC quando non c’è contenuto utilizzabile, ma segnalano intenti molto diversi a un client conforme alla specifica. 410 è il segnale deliberato «questo esisteva e ora è sparito per sempre»; 204 non è mai stato progettato per quel significato e non dovrebbe stare sugli URL di pagina.

Quando 204 è esattamente corretto (non un bug)

Quasi ogni 204 legittimo è una risposta non-documentale:

• DELETE / PUT di un’API REST. Quando un client elimina una risorsa o la aggiorna sul posto e non c’è nulla di significativo da restituire, 204 è la risposta idiomatica: è il pattern raccomandato dalla stessa RFC 9110.
• Beacon di analytics e tracking. La specifica Beacon del W3C, costruita attorno a navigator.sendBeacon(), prevede che gli endpoint beacon rispondano con 204. L’endpoint Measurement Protocol di Google Analytics 4 restituisce 204 per gli hit che accetta. È importante segnalarlo: GA4 restituisce 204 anche per payload malformati o non validi, quindi lì un 204 conferma solo che l’endpoint era raggiungibile e ha risposto strutturalmente, non che il tuo hit sia stato elaborato. Non leggere il 204 di un beacon come prova del successo.
• UX «salva senza cambiare pagina». Un PUT che salva lo stato sul posto e lascia l’utente sulla pagina corrente: la formulazione di MDN è “the client doesn’t need to navigate away from its current page.” (traduzione) «il client non deve spostarsi dalla pagina corrente».

Il filo conduttore è questo: non sono URL che qualcuno dovrebbe indicizzare, quindi un 204 è corretto e previsto. Il problema è solo un 204 su un URL-documento che dovrebbe posizionarsi.

Vale la pena segnalare una sfumatura correlata: RFC 9110 non limita il 204 specificamente a DELETE/PUT/beacon, che sono solo i pattern più comuni. La definizione della specifica è indipendente dal metodo; ciò che conta davvero è il contratto del metodo e se sarebbe utile restituire una rappresentazione. La questione ha due lati. Una richiesta GET che restituisce 204 è legale per il protocollo — professionisti su Stack Overflow ne discutono da anni — ma la vera domanda per una pagina indicizzabile non è «è consentito un 204 su GET?», bensì «questo URL deve consegnare a Google una rappresentazione per poter essere trovato?». Per una pagina che vuoi posizionare, la risposta è sempre sì. Quindi la regola SEO non riguarda il metodo HTTP usato: in prima battuta riguarda il fatto che l’URL debba essere o meno un documento.

È anche utile sapere che «204 è sempre corretto per le risposte API» non è un punto condiviso universalmente nemmeno tra i progettisti di API. Il testo di Postman indica 204 come scelta preferita per le azioni che non devono restituire nulla; Brandur Leach ha sostenuto la tesi opposta: una risposta di successo vuota può essere leggermente dannosa per i client API che si aspettano una rappresentazione (stato aggiornato, ID generato, campo calcolato) anche dopo una scrittura riuscita. È un compromesso legittimo di progettazione API sull’ergonomia degli sviluppatori, non una questione di correttezza HTTP: in ogni caso 204 resta conforme alla specifica ed è separato dalla domanda SEO di questo articolo. Un punto su cui i testi sulle API a volte sono imprecisi: inviare Content-Length: 0 su un 204 «per sicurezza». Non farlo: RFC 9110 §8.6 vieta completamente Content-Length in una risposta 204, non solo quando è diverso da zero.

Diagnosticare e correggere un 204 accidentale a livello di pagina

Se un crawler (Screaming Frog, Ahrefs Site Audit) o i tuoi log mostrano un 204 su una pagina che dovrebbe avere contenuto:

1. Conferma ciò che riceve davvero Googlebot. Usa l’Ispezione URL in Search Console per vedere lo stato e il contenuto renderizzato ricevuti da Google, non solo ciò che mostra il browser. Una CDN, un edge worker, un WAF o una route dell’app può restituire 204 ai bot o in condizioni specifiche mentre per te sembra tutto a posto (lo stesso pattern «nel browser sembra tutto a posto» di un 403 rimasto per errore).
2. Poi correggi in base all’intento:
   • La pagina dovrebbe esistere con contenuto → trova la logica del server/CDN/app che emette 204 e ripristina un 200 corretto con il body reale.
   • La pagina è sparita senza sostituzione → restituisci 404 o 410.
   • La pagina è stata spostata → 301 verso il nuovo URL.
3. Monitora. Controlla il report Page Indexing di GSC per le voci soft 404, osserva i codici di stato del crawl nei log e configura il crawler affinché segnali i 204: così un 204 accidentale su un template non deindicizza in silenzio un’intera sezione.

Il modello mentale da conservare è questo: 204 non è «cattivo». È uno strumento preciso, corretto per endpoint API e beacon e sbagliato per i documenti. Il problema esiste solo quando lo usi nel posto sbagliato. I codici affini come 403, 404, 410 e soft 404 hanno ciascuno il proprio ruolo nella decisione: il posto del 204 è fuori dalla pagina.

Riepilogo AI

Una sintesi della versione Advanced:

• 204 No Content è un codice di successo 2xx (RFC 9110 §15.3.5) che restituisce un body vuoto per progettazione. Non è un errore e non dice nulla sull’esistenza di un URL. L’RFC non lo limita a un elenco fisso di metodi: DELETE/PUT/beacon sono pattern comuni, non un requisito, e 204 su una GET è legale per il protocollo.
• Il body deve essere vuoto, senza eccezioni. Secondo MDN, un 204 non deve includere contenuto né un header Content-Length; RFC 9110 §8.6 vieta Content-Length del tutto, quindi anche Content-Length: 0 non è conforme. Gli header eventualmente presenti descrivono la rappresentazione selezionata dopo l’azione, non un body trasferito. Un 204 è memorizzabile nella cache per euristica in modo predefinito, ma un ETag non è garantito su ogni 204: l’esempio di MDN lo include per uno specifico caso PUT, non come regola universale.
• Conseguenza SEO (circoscritta e precisa): la documentazione di Google sui codici di stato dice chiaramente che per un 204 “Google wasn’t able to receive any content and therefore can’t process it.” (traduzione) «Google non è riuscito a ricevere alcun contenuto e quindi non può elaborarlo». Questo sostiene un’inferenza ragionevole: una pagina che vuoi posizionare non verrà indicizzata da quella risposta. Google però non garantisce che ogni 204 riceva una specifica etichetta soft 404 o un calendario di rimozione, e usare 204 non recupera automaticamente il crawl budget né dimostra un effetto sul ranking. Come scrivo nei miei articoli: «204s will be treated as soft 404s and won’t be indexed» — «i 204 verranno trattati come soft 404 e non saranno indicizzati» —: è il pattern pratico che ho osservato, anche se la formulazione ufficiale precisa è più circoscritta.
• Gli usi legittimi sono soprattutto non-documentali: DELETE/PUT di API REST e beacon di analytics (sendBeacon(), Measurement Protocol di GA4). GA4 restituisce 204 anche per hit malformati, quindi un 204 del beacon non dimostra che l’hit sia stato elaborato. Anche qui i professionisti non sono completamente d’accordo: Postman considera 204 il default per azioni senza nulla da restituire, mentre Brandur Leach sostiene che un successo vuoto può danneggiare leggermente i client che si aspettano una rappresentazione; è un dibattito sull’ergonomia delle API, non sulla correttezza HTTP.
• 204 non è mai corretto per una pagina da posizionare. Sparita senza sostituzione → 404/ 410; spostata → 301; dovrebbe avere contenuto → correggi il server/CDN che emette 204 e ripristina un vero 200. Conferma ciò che riceve Googlebot con l’Ispezione URL.

Documentazione ufficiale

Riferimenti primari per capire che cos’è un 204 e come lo gestisce Google.

Specifica HTTP e riferimento browser

• RFC 9110 §15.3.5 — 204 No Content — la definizione autorevole: successo, nessun body del payload, nessun trailer, memorizzabile per euristica e header che descrivono la rappresentazione selezionata dopo l’azione.
• RFC 9110 §8.6 — Content-Length — la regola che vieta del tutto Content-Length in una risposta 204 (non solo quando è diverso da zero).
• MDN — 204 No Content — spiegazione in linguaggio chiaro, vincolo su body vuoto e Content-Length, memorizzabilità nella cache, esempio specifico di ETag e caso d’uso «salva senza cambiare pagina».

Google Search Central

• Come i codici di stato HTTP e gli errori di rete e DNS influenzano la Ricerca Google — la tabella dei codici di stato che cita esplicitamente il 204 e la definizione di soft 404 di Google.

Beacon e analytics (i casi legittimi del 204)

• W3C — Beacon — la specifica navigator.sendBeacon() che prevede una risposta 204 dagli endpoint beacon.
• Google Analytics 4 — Measurement Protocol reference — l’endpoint di raccolta GA4, le cui risposte (incluso un 204 per gli hit accettati) sono documentate qui.

Citazioni dalla fonte

Dichiarazioni registrate. Ogni link è un deep link che porta al passaggio citato nella pagina sorgente.

La specifica HTTP

• “The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.” (traduzione) «Il codice di stato 204 (No Content) indica che il server ha completato con successo la richiesta e che non c’è altro contenuto da inviare nel body del payload della risposta» — RFC 9110, HTTP Semantics, §15.3.5. Leggi la sezione

MDN Web Docs

• “The HTTP 204 No Content successful response status code indicates that a request has succeeded, but the client doesn’t need to navigate away from its current page. A 204 response is cacheable by default, and an ETag header is included in such cases.” (traduzione) «Il codice di stato di risposta HTTP di successo 204 No Content indica che una richiesta è andata a buon fine, ma il client non deve spostarsi dalla pagina corrente. Una risposta 204 è memorizzabile nella cache per impostazione predefinita e in questi casi include un header ETag» — Vai alla citazione

Google Search Central — gestione di 2xx / 204

• «Google non è riuscito a ricevere alcun contenuto e quindi non può elaborarlo» — documento di Google sui codici di stato HTTP, riga del 204 nella tabella dei 2xx (in contrasto con la regola generale dei 2xx, secondo cui «Google considera il contenuto per l’elaborazione»). Documento di Google sui codici di stato

Patrick Stox — Ahrefs

• “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (traduzione) «La maggior parte dei 2xx consente di indicizzare le pagine. Tuttavia, i 204 vengono trattati come soft 404 e non vengono indicizzati» — dalla mia guida Codici di stato HTTP e loro impatto SEO. Vai alla citazione

Matt G. Southern — Search Engine Journal

• “The exception is a 204 status code, which means the page was successfully accessed but no content was found. Google may show a soft 404 in Search Console for pages serving a 204 code.” (traduzione) «L’eccezione è un codice di stato 204, che significa che la pagina è stata raggiunta con successo ma non è stato trovato alcun contenuto. Google può mostrare un soft 404 in Search Console per le pagine che servono un codice 204» — Vai alla citazione

204 legittimi e accidentali

Casi concreti per capire dove appartiene un 204 e dove invece è un bug.

Corretto: DELETE di un’API REST

Un client elimina una risorsa: non c’è nulla da restituire.

DELETE /api/items/42 HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content

Nessun body, nessun Content-Length. È la risposta idiomatica e non dovrebbe mai essere un URL che ti aspetti di vedere nelle ricerche.

Corretto: beacon di analytics (sendBeacon)

// Fires a fire-and-forget beacon on page unload
navigator.sendBeacon('/collect', payload);
// Endpoint responds:  HTTP/1.1 204 No Content

L’endpoint non deve servire alcuna pagina, quindi 204 è esattamente corretto. Lo stesso vale per l’endpoint Measurement Protocol di GA4: ricorda solo che GA4 restituisce 204 anche per hit malformati, quindi un 204 conferma che l’endpoint ha risposto, non che il tuo hit sia stato elaborato.

Sbagliato: una pagina di contenuto che restituisce 204

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

HTTP/1.1 204 No Content        ← bug: a real page must return 200 + body

Google riceve un body vuoto, tratta l’URL come un soft 404 e non lo indicizza. La correzione dipende dall’intento:

• Dovrebbe esistere con contenuto → ripristina 200 OK con il body reale (correggi la route server/CDN/app che emette 204).
• Sparita senza sostituzione → 404 o 410.
• Spostata → 301 verso il nuovo URL.

Regola pratica: se una persona deve arrivare all’URL e leggere qualcosa, questo deve restituire 200 con un body. Riserva 204 agli endpoint macchina-macchina — API e beacon — dove non c’è davvero nulla da mostrare.

Diagnosticare un 204 imprevisto

Una pagina è vuota e il pannello Network mostra 204

Sintomo: un URL-documento che dovrebbe renderizzare contenuto restituisce 204 No Content.

Causa probabile: il routing dell’app, una regola CDN, un edge worker o un gestore degli errori sta emettendo la risposta di successo tipica delle API su una route di pagina.

Correzione: segui la richiesta attraverso il livello che possiede la risposta. Se la pagina deve esistere, ripristina un 200 con un body reale. Conferma la correzione con una nuova richiesta degli header e ricaricando il browser con la cache disabilitata.

Search Console segnala un soft 404 per un URL 204

Sintomo: l’URL è escluso come soft 404 anche se 204 è un codice di successo.

Causa probabile: la classificazione riguarda il contenuto mancante, non il fatto che il codice inizi con 2. Un 204 non ha un body per definizione.

Correzione: scegli la risposta in base all’intento: 200 con contenuto per una vera pagina, 301 per uno spostamento oppure 404/410 per una pagina sparita. Esegui di nuovo l’Ispezione URL dopo aver distribuito la correzione.

Il browser e il crawler non concordano sullo stato

Sintomo: la pagina sembra normale nel browser, ma un crawler o una voce di log mostra 204.

Causa probabile: la risposta varia in base a bot, metodo, area geografica, cache, WAF o logica edge.

Correzione: confronta GET e HEAD, le richieste con user agent normale e Googlebot e la richiesta esatta nei log del server/CDN. Correggi la regola condizionale, poi verifica che entrambi i percorsi restituiscano la stessa risposta prevista.

Classificare un insieme di URL 204 in base all’intento

Incolla un export di crawl o log che includa URL, metodo della richiesta, tipo di contenuto, referrer o tipo di route e codice di risposta.

Classify each HTTP 204 row I provide as:
- likely legitimate API response,
- likely legitimate beacon/background request,
- accidental document/page response, or
- insufficient evidence.

For every row, cite the supplied evidence, explain why 204 does or does not fit, and give
the next verification step. For accidental page responses, recommend exactly one intended
outcome: 200 with content, 301 to a relevant replacement, or 404/410 if gone.

Do not infer that a 204 analytics response means the event was processed. Do not invent
route behavior, redirect targets, or page content. Return a table followed by a prioritized
manual-check queue.

PASTE ROWS HERE

Trovare le risposte 204 accidentali

Ispezionare un URL e il metodo della richiesta

curl -sS -D - -o /dev/null https://example.com/page
curl -sS -X HEAD -D - -o /dev/null https://example.com/page

La richiesta del documento non dovrebbe essere 204 se l’URL deve renderizzare contenuto. Prova GET e HEAD, perché gestori difettosi specifici per metodo possono restituire risposte diverse.

Confrontare la risposta predefinita e quella con user agent Googlebot

url="https://example.com/page"
curl -sS -o /dev/null -w "default: %{http_code} %{size_download} bytes\n" "$url"
curl -sS -A "Googlebot" -o /dev/null -w "Googlebot UA: %{http_code} %{size_download} bytes\n" "$url"

Un 204 con zero byte scaricati su un solo percorso indica una logica condizionale del server, della CDN o del WAF. Usa log reali e Ispezione URL per confermare ciò che Google ha ricevuto davvero.

Segnalare i 204 da un elenco di URL

while IFS= read -r url; do
  code=$(curl -sS -o /dev/null -w "%{http_code}" "$url")
  if [ "$code" = "204" ]; then printf '%s\t%s\n' "$code" "$url"; fi
done < urls.txt

Esegui questo su macOS, Linux o WSL con un URL per riga in urls.txt. Esamina ogni risultato in base all’intento della route: i 204 di API e beacon non sono errori.

Strumenti per separare i 204 legittimi da quelli accidentali

Lo strumento gratuito di Patrick

• Bulk HTTP Status Code Checker — controlla fino a 500 URL, filtra i risultati per 204 ed esporta l’insieme interessato. Usa il contesto della route e del contenuto per separare gli endpoint API/beacon validi dagli URL di pagina che dovrebbero restituire contenuto.

Confermare la causa

• Ispezione URL di Google Search Console — testa dal vivo un URL di pagina per vedere cosa Google riesce a recuperare dopo che hai modificato la risposta.
• Log del server/CDN — individua se il 204 varia in base a metodo, user agent, route o posizione edge.
• Pannello Network dei DevTools del browser — distingue la richiesta del documento dalle chiamate API e beacon in background; un 204 su un beacon può essere corretto, mentre un 204 sul documento non lo è.
• Un crawler completo del sito — inventaria gli URL-documento che restituiscono 204 e mantiene il controllo negli audit ricorrenti, così una regressione del template non interessa un’intera sezione.

Mettiti alla prova: 204 No Content

Cinque domande rapide su che cosa significa un 204 e quando è corretto. Scegli una risposta per ciascuna, poi verifica.

Cronologia modifiche