200 OK: guida

TL;DR — Una risposta 200 OK significa che il server dice «ecco la pagina che hai chiesto, va tutto bene». È il codice di successo che vuoi per ogni pagina destinata alla ricerca Google. Ma un 200 da solo non garantisce l’indicizzazione: Google valuta comunque se il contenuto merita di essere indicizzato. E un 200 su una pagina rotta o vuota è un bug, non un via libera.

Che cosa significa 200 OK

Ogni volta che il browser o Googlebot chiede una pagina a un server, il server risponde con un codice di stato a tre cifre prima di inviare altro. 200 OK è quello che significa «tutto bene»: il server ha trovato ciò che hai chiesto e lo restituisce, normalmente insieme al contenuto della pagina. (Tecnicamente la specifica consente in alcuni casi un 200 con body vuoto, ma per una pagina che vuoi far leggere alle persone serve sempre un body reale.) È il codice che quasi non noti, perché indica che nulla è andato storto. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Patrick Stox lo riassume in tre parole nella guida Ahrefs ai codici di stato HTTP: “200 OK – All good. Everything is successful.” (traduzione) «200 OK: tutto bene. Tutto è riuscito.»

Per le pagine del tuo sito che vuoi far trovare nella ricerca, 200 è esattamente il codice che vuoi restituire.

Perché un 200 non racconta tutta la storia

Ecco la parte che la maggioranza delle pagine sul significato di 200 omette: un 200 fa considerare la pagina per l’indicizzazione, non la fa entrare sicuramente nell’indice. Sono due cose molto diverse.

Pensa al 200 come al biglietto che ti fa entrare. Una volta dentro, Google decide ancora se vale la pena conservare il contenuto: è di qualità? È quasi duplicato di un’altra pagina? È scarno o vuoto? Contiene un tag noindex che dice a Google di restare fuori? Ognuna di queste condizioni può impedire l’indicizzazione anche a una pagina 200 perfettamente sana. Evidence for this claim Google passes a 2xx response to its indexing pipeline, which may index the content but does not guarantee that it will do so; error-like content can be classified as a soft 404. Scope: Google Search handling of 2xx page responses and soft 404s. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Quindi, se una pagina restituisce 200 ma non compare su Google, il problema non è il codice di stato: sono il contenuto o la configurazione.

La trappola: un 200 che in realtà significa «non trovato»

L’errore più insidioso è una pagina che restituisce 200 ma il cui contenuto dice «non esiste». Un prodotto esaurito con una pagina vuota, un articolo eliminato che carica ancora un template vuoto o una pagina di risultati di ricerca senza risultati: il server invia un allegro 200, ma non c’è nulla di reale.

Google guarda oltre il codice il contenuto effettivo, decide che la pagina è vuota o contiene un errore e la etichetta come soft 404 in Search Console, trattandola come una vera pagina «non trovata». Il dettaglio è spiegato nell’articolo sugli errori soft 404; in breve: se una pagina è davvero sparita, deve restituire 404 o 410, non 200.

L’unica regola da ricordare

Una pagina che vuoi in Google deve restituire 200 con contenuto reale. Se è sparita, usa 404 o 410. Se è stata spostata, usa un redirect 301. Se è duplicata, usa un canonical tag. Vuoi il testo esatto di Google, la differenza tra 200 e 204 e come controllare che cosa ha ricevuto davvero Googlebot? Passa alla scheda Advanced.

TL;DR — 200 OK è il codice di successo 2xx standard (RFC 9110 §15.3.1): il server ha completato la richiesta e, per GET/HEAD, il body è una rappresentazione della risorsa. Per impostazione predefinita è memorizzabile in cache per euristica. Per la SEO è necessario ma non sufficiente: la documentazione Google dice: “may index the content, but that’s not guaranteed,” (traduzione) «può indicizzare il contenuto, ma non è garantito». Quindi qualità, duplicazione, contenuto scarno e noindex vengono valutati sopra il 200. Il fallimento classico è il soft 404: un 200 che avvolge contenuto vuoto o d’errore, rilevato da Google a livello di contenuto e segnalato come soft 404 indipendentemente dal codice. Distingui 200 (body previsto) da 204 (body vuoto, trattato come soft 404 sulle pagine) e 304 (segnale di caching, non decisione d’indicizzazione). E controlla che cosa ha ricevuto Googlebot: cloaking, blocchi ai bot, regole geografiche e configurazione CDN/WAF possono servire al browser un codice diverso.

Che cosa significa 200 nella specifica

RFC 9110 (HTTP Semantics) è l’autorità attuale e §15.3.1 è diretto: «Il codice di stato 200 (OK) indica che la richiesta è riuscita». Il contenuto del body dipende dal metodo. Per i metodi importanti per le pagine, GET e HEAD, il contenuto rappresenta la risorsa richiesta. La RFC precisa anche che, salvo le risposte a CONNECT, un 200 dovrebbe contenere contenuto a meno che il framing non segnali esplicitamente lunghezza zero: «un 200 ha sempre un body» è una scorciatoia, non un assoluto. In pratica, per una pagina che vuoi indicizzare, l’obiettivo è un body reale e non vuoto. Un 200 è anche «memorizzabile in cache per euristica» per impostazione predefinita, salvo direttive Cache-Control; per questo header di validazione come ETag e Last-Modified contano sulle pagine sottoposte spesso a nuovo crawl. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Tecnicamente 200 non riguarda solo le pagine. La RFC descrive il significato di «successo» per ogni metodo:

Per i metodi diversi da GET spesso non vedrai un 200: MDN nota che le richieste PUT o DELETE riuscite “often do not result in a 200 OK response,” (traduzione) «spesso non producono una risposta 200 OK», mentre 201 Created o 204 No Content sono più comuni. Nulla di questo è rilevante per la SEO degli URL di pagina; la frase da ricordare è che, per un documento che vuoi indicizzare, l’obiettivo è 200 con un body reale.

Necessario, non sufficiente, per l’indicizzazione

È la cosa più importante da capire ed è il punto in cui la maggior parte delle pagine concorrenti di glossario sbaglia nettamente. Dicono «200 significa che la pagina viene indicizzata». La documentazione Google lo spiega: per un 200 Google “passes on whatever it received to the next processing step… For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (traduzione) «passa ciò che ha ricevuto alla fase successiva… Per Google Search, la fase successiva è la pipeline di indicizzazione. I sistemi di indicizzazione possono indicizzare il contenuto, ma non è garantito». Evidence for this claim Google passes a 2xx response to its indexing pipeline, which may index the content but does not guarantee that it will do so; error-like content can be classified as a soft 404. Scope: Google Search handling of 2xx page responses and soft 404s. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Quindi il 200 è un contratto sulla risposta HTTP, non una promessa sul destino della pagina nella Ricerca. Dopo il 200, Google valuta autonomamente:

• Qualità: pagine scarne, di basso valore o generate automaticamente possono non essere indicizzate.
• Duplicazione: un quasi-duplicato di un URL più forte può essere accorpato a quell’URL invece di essere indicizzato autonomamente (è ciò che il canonical tag serve a controllare).
• Direttive: un noindex nel meta tag o nell’header X-Robots-Tag esclude la pagina anche con un 200 perfetto.

La guida Ahrefs di Patrick traccia la stessa distinzione a livello di famiglia: “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (traduzione) «La guida osserva che la maggior parte dei codici di successo consente di indicizzare le pagine, mentre le risposte senza contenuto vengono trattate come errori soft e non vengono indicizzate». Il 200 rende una pagina idonea, non indicizzata.

La trappola del soft 404

L’esempio più netto del fatto che «200 non è tutta la storia» è il soft 404. La documentazione Google sui codici di stato spiega il meccanismo: “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (traduzione) «Se il contenuto suggerisce un errore per Google Search, una pagina vuota o un messaggio d’errore, Search Console mostrerà un errore di pagina non trovata.» La classificazione dipende dal contenuto renderizzato, non dal codice HTTP. La pipeline guarda oltre il 200 e, se la pagina sembra «non trovata», la inserisce e segnala come una vera 404.

I casi tipici: un prodotto dismesso la cui pagina ora carica un template vuoto, un articolo eliminato che restituisce ancora una shell 200, una categoria filtrata o una ricerca con zero elementi e un messaggio «qui non c’è nulla». Ognuno restituisce un 200 tecnicamente corretto mentre comunica a utenti e Google che non c’è niente da vedere.

Questo sito ha un articolo dedicato agli errori soft 404 per i meccanismi di rilevazione e le correzioni: non li ripeterò qui. Per il discorso sul 200, il punto è semplice: restituire 200 su una pagina davvero sparita prepara il soft 404. La correzione è far coincidere il codice con la realtà.

Una trappola collegata: il successo del trasporto non è il successo dell’applicazione

Vale una breve parentesi per API e monitoraggio: il livello HTTP e quello applicativo possono non concordare. Un endpoint API può inviare 200 con un oggetto JSON di errore nel body; una pagina può inviare 200 mentre una dipendenza backend fallisce in silenzio e produce un blocco rotto invece del contenuto reale. La riga di stato dice solo «consegnato correttamente». Se il payload è corretto è una domanda separata, a cui il codice di stato non risponde. I professionisti non concordano sul fatto che un’API debba segnalare un errore con uno stato diverso da 200 o con un 200 che contiene un payload d’errore: è un contratto scelto dal team, non una regola HTTP. Per la SEO di questo sito, la versione a livello di pagina è il soft 404: non fidarti della sola riga di stato, guarda che cosa contiene davvero il body.

200 contro 204 e 304: non confonderli

Tre codici vengono spesso confusi, ma solo uno è il successo «ecco la tua pagina»:

204 è un vero codice di successo, ma il body vuoto non offre al crawler nulla da indicizzare: su un URL di pagina finisce nel gruppo soft 404 (è un articolo separato; non confondere il caso del body vuoto con un normale 200). 304 appartiene a un’altra famiglia: risponde a una richiesta condizionale (If-None-Match / If-Modified-Since) dicendo al client che la copia in cache è ancora aggiornata. Non porta body e non dice nulla sull’indicizzazione: è un meccanismo di efficienza del crawl, non un duplicato di 200. La domanda «200 e 304 non sono la stessa cosa?» confonde un’ottimizzazione della cache con una risposta di successo.

Controlla che cosa vede davvero Googlebot

Ecco una lacuna che quasi ogni articolo concorrente salta: richiedenti diversi possono ricevere codici diversi per lo stesso URL. Il browser può vedere un 200 pulito mentre Googlebot riceve altro: talvolta intenzionalmente (cloaking, violazione delle Search Essentials), più spesso accidentalmente per regole WAF o blocco bot, targeting geo-IP, logica CDN o un test A/B che funziona male per i bot.

Quindi «nel mio browser è 200» non prova che «Google vede 200». La diagnosi corretta è controllare ciò che ha ricevuto Googlebot:

• Ispezione URL di GSC: esegui un Live Test per vedere stato e contenuto renderizzato recuperati da Google, non ciò che vede la tua macchina.
• Log del server o CDN: la fonte di verità sul codice ricevuto da ciascun user agent.

Un semplice curl -I dal terminale è utile, ma è solo un altro richiedente che può incontrare regole edge diverse da Googlebot: trattalo come un dato, non come l’ultima parola.

Come controllare e monitorare le risposte di successo

• DevTools del browser: scheda Network, ricarica, seleziona la richiesta del documento e leggi la colonna Status.
• Riga di comando: curl -I https://example.com/page per gli header di una richiesta; curl -IL per seguire la catena di redirect.
• Google Search Console: URL Inspection mostra lo stato sottoposto a crawl e consente il Live Test.
• Bing Webmaster Tools: lo strumento URL Inspection è il modo lato Bing per confermare ciò che ha ricevuto Bingbot. (Bing non pubblica una guida dedicata a «come i codici influenzano l’indicizzazione» come Google; è meglio dirlo che inventare una policy.)
• Crawler: Screaming Frog e Ahrefs Site Audit mostrano in massa i codici di stato dell’intero sito; la barra SEO gratuita di Ahrefs mostra il codice della pagina aperta.

Una situazione «sana» significa che gli URL importanti e canonici restituiscono sempre 200 con contenuto reale, mentre le pagine che devono essere sparite o spostate restituiscono 404/410 o 301, invece di un 200 fuorviante.

La decisione in una riga

Fai coincidere il codice con la realtà. Voluto nell’indice → 200 con contenuto sostanziale. Sparito definitivamente → 404 o 410 (vedi 404-not-found). Spostato → 301. Duplicato di un altro URL → indica la versione preferita con un canonical tag invece di forzare un codice diverso da 200. Il 200 è il via libera per le pagine che lo meritano davvero: niente di più, niente di meno.

Riepilogo AI

Una sintesi della versione Advanced:

• 200 OK è il codice standard di successo 2xx (RFC 9110 §15.3.1): il server ha completato la richiesta e, per GET/HEAD, il body rappresenta la risorsa. È memorizzabile in cache per euristica. La RFC presenta il body come previsto, non assoluto: un 200 a lunghezza zero è tecnicamente valido, ma una pagina che vuoi indicizzare ha bisogno di un body reale.
• Necessario, non sufficiente, per l’indicizzazione. La documentazione Google dice che i sistemi “may index the content, but that’s not guaranteed.” (traduzione) «possono indicizzare il contenuto, ma non è garantito». Qualità, duplicazione, contenuto scarno e noindex vengono valutati sopra il 200.
• La trappola del soft 404: un 200 che contiene contenuto vuoto o d’errore viene rilevato a livello di contenuto e segnalato come soft 404 in Search Console. La documentazione lo riassume così: “if the content suggests an error… Search Console will show a soft 404 error.” (traduzione) «se il contenuto suggerisce un errore… Search Console mostrerà un errore soft 404». Un 200 su una pagina davvero sparita prepara questa situazione.
• Una trappola parallela: livello HTTP e applicativo possono non concordare: un 200 può contenere un payload API d’errore o un blocco backend rotto in silenzio. La riga di stato dichiara solo il successo del trasporto, non la correttezza del payload.
• 200 contro 204 e 304: 200 = successo con body reale (idoneo all’indicizzazione); 204 = successo con body vuoto, trattato come soft 404 sugli URL di pagina; 304 = segnale di caching per una richiesta condizionale, non decisione d’indicizzazione.
• Controlla che cosa ha ricevuto Googlebot. Richiedenti diversi possono vedere codici diversi per un URL a causa di cloaking, blocco bot, regole geo o configurazione CDN/WAF. «200 nel mio browser» ≠ «Google vede 200». Controlla GSC URL Inspection Live Test o i log del server, non solo browser o curl.
• Fai coincidere il codice con la realtà: voluto → 200 con contenuto reale; sparito → 404/410; spostato → 301; duplicato → canonical tag. Come dice Patrick, “200 OK – All good. Everything is successful.” (traduzione) «200 OK: tutto bene. Tutto è riuscito» — per una pagina che merita davvero di esserci.

Documentazione ufficiale

Riferimenti di prima parte per capire che cos’è 200 e come lo gestisce Google.

Specifica HTTP e riferimento browser

• RFC 9110 §15.3.1 — 200 OK — definizione autorevole: richiesta riuscita, semantica del body per metodo e memorizzabilità euristica.
• MDN — 200 OK — spiegazione in linguaggio semplice, memorizzabilità predefinita e dettaglio PUT/DELETE (201/204 sono più comuni).

Google Search Central

• Come i codici di stato HTTP e gli errori di rete e DNS influenzano la Ricerca Google — gestione dei 2xx (il contenuto può essere indicizzato, ma non è garantito) e riferimento ai soft 404.
• Soft 404 errors — Page indexing report — definizione Google del 200 che in realtà è un errore e motivo per cui un successo su una pagina sparita è una cattiva pratica.
• Cloaking — perché un URL può servire codice o contenuto diversi a utenti e Googlebot e perché farlo per manipolare il ranking viola le regole.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — il modo lato Bing per confermare la risposta HTTP ricevuta da Bingbot per un URL. (Non esiste una guida Bing-authored dedicata a come i codici influenzano l’indicizzazione.)

Citazioni dalla fonte

Dichiarazioni ufficiali. Ogni link porta direttamente al passaggio citato nella pagina fonte.

La specifica HTTP

• “The 200 (OK) status code indicates that the request has succeeded.” (traduzione) «Il codice di stato 200 (OK) indica che la richiesta è riuscita». — RFC 9110, HTTP Semantics, §15.3.1. Leggi la sezione

MDN Web Docs

• “The HTTP 200 OK success status response code indicates that a request has succeeded. A 200 OK response is cacheable by default.” (traduzione) «Il codice di risposta di successo HTTP 200 OK indica che una richiesta è riuscita. Una risposta 200 OK è memorizzabile in cache per impostazione predefinita». Vai alla citazione

Google Search Central — gestione 2xx/200

• «Google passa ciò che ha ricevuto alla fase successiva, specifica del prodotto. Per Google Search, la fase successiva è la pipeline di indicizzazione, i cui sistemi possono indicizzare il contenuto, ma non è garantito». (Traduzione italiana dell’originale citato nella sezione avanzata.) — Documentazione Google sui codici HTTP, voce 200. Documentazione Google sui codici

• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (traduzione) «Se il contenuto suggerisce un errore per Google Search, una pagina vuota o un messaggio d’errore, Search Console mostrerà un errore di pagina non trovata». — stessa documentazione, riferimento al soft 404. Documentazione Google sui codici

Patrick Stox — Ahrefs

• “200 OK – All good. Everything is successful.” — «200 OK: tutto bene. Tutto è riuscito.» — dalla mia guida ai codici di stato HTTP sul blog Ahrefs. Vai alla citazione

• “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (traduzione) «La guida Ahrefs osserva che la maggior parte dei codici di successo consente di indicizzare le pagine, mentre le risposte senza contenuto vengono trattate come errori soft e non vengono indicizzate». — dalla stessa guida, sulla gestione Google della famiglia 2xx. Vai alla citazione

200 OK: riferimento rapido

Che cos’è

200 e i codici fratelli confusi

Quale codice deve restituire questo URL?

• Voluto nell’indice → 200 con contenuto reale e sostanziale.
• Sparito definitivamente → 404 o 410 (vedi 404-not-found).
• Spostato a un nuovo URL → 301.
• Duplicato di un altro URL → mantieni 200 e aggiungi un canonical tag alla versione preferita.
• Vuoto intenzionalmente (API/beacon) → 204 (vedi 204-no-content), mai su una pagina.

Fatti rapidi

• Un 200 rende una pagina idonea all’indicizzazione, non indicizzata: Google decide separatamente in base a qualità, duplicazione, contenuto scarno e noindex.
• Un 200 su una pagina davvero sparita o vuota è un soft 404 agli occhi di Google.
• Richiedenti diversi possono vedere codici diversi per un URL: conferma ciò che ha ricevuto Googlebot con GSC URL Inspection o i log, non solo con browser o curl.
• Controlla i codici con DevTools Network, curl -I / curl -IL, GSC/Bing URL Inspection, Screaming Frog e Ahrefs Site Audit/Toolbar.

Miti comuni su 200 OK

«Un codice di stato 200 significa che la pagina è indicizzata.» Falso. 200 significa che il server ha restituito correttamente il contenuto; l’indicizzazione è una decisione separata a valle. La documentazione Google dice che i sistemi “may index the content, but that’s not guaranteed.” (traduzione) «possono indicizzare il contenuto, ma non è garantito». La qualità editoriale, i duplicati, i contenuti troppo scarni e la direttiva noindex restano criteri separati dal codice 200.

«Se Search Console mostra un soft 404, il server ha un bug.» Non necessariamente. Soft 404 non è un codice inviato dal server: è un’etichetta che Google applica quando lo stato 200 non coincide con contenuto che sembra un errore o una pagina vuota. Il server sta facendo ciò per cui è configurato (inviare 200); il problema è il contenuto, non l’header.

«200 è sempre positivo, senza eccezioni.» Non sempre. Un 200 su un URL che avrebbe dovuto restituire 404, come un prodotto eliminato, un annuncio scaduto o una pagina di ricerca vuota, è attivamente dannoso. Invita il trattamento soft 404 e può sprecare crawl su un URL senza nulla da offrire.

«Il mio browser mostra 200, quindi anche Google vede sicuramente 200.» Non è garantito. Blocco bot, cloaking, regole geo-IP e configurazione CDN/WAF possono servire a Googlebot una risposta diversa da quella del browser. Verifica con URL Inspection o i log del server.

«200 e 204 sono praticamente uguali: entrambi significano successo.» Sono entrambi 2xx, ma 204 ha intenzionalmente un body vuoto. Va bene per API e beacon, non per una pagina che vuoi indicizzare: un 204 su un URL di pagina viene trattato come soft 404 (vedi 204-no-content).

«200 e 304 non sono la stessa idea?» No. 304 Not Modified è un meccanismo di caching che risponde a una richiesta condizionale (If-None-Match / If-Modified-Since), dicendo al client di usare la copia in cache. Non contiene body e non è una decisione d’indicizzazione: è un concetto diverso da 200.

Perché una pagina 200 può comunque fallire

Search Console chiama l’URL soft 404

Sintomo: l’URL restituisce 200, ma Page Indexing lo segnala come soft 404.

Causa probabile: il body della risposta sembra vuoto, rotto o una pagina di errore. Casi comuni: prodotto dismesso senza informazioni utili, articolo eliminato dentro un template completo oppure ricerca senza risultati.

Correzione: fai coincidere la risposta con la realtà. Ripristina contenuto sostanziale se la pagina deve esistere, restituisci 404 o 410 se è sparita, oppure 301 se è stata spostata. Ripeti il Live Test di URL Inspection e conferma che risposta e contenuto renderizzato ora concordino.

Il browser riceve 200 ma Googlebot no

Sintomo: DevTools o curl mostrano 200, mentre Google non riesce a recuperare o indicizzare l’URL.

Causa probabile: CDN, WAF, regola geografica, regola bot o esperimento invia a Googlebot una risposta diversa. La tua richiesta non prova che Google abbia fatto la stessa richiesta.

Correzione: confronta una richiesta normale con una richiesta User-Agent Googlebot, poi controlla URL Inspection e i log server/CDN. Correggi la regola edge e conferma che il Live Test riceva 200 con lo stesso body sostanziale degli utenti.

La pagina è 200 ma non è ancora indicizzata

Sintomo: il codice di stato è sano, ma l’URL resta escluso dall’indice.

Causa probabile: 200 rende il contenuto idoneo alla fase di elaborazione, non lo indicizza. noindex, conflitto tra duplicati/canonical o contenuto di basso valore possono comunque escluderlo.

Correzione: smetti di cambiare il codice di stato. Controlla direttive di indicizzazione, canonical scelto da Google e contenuto effettivo. Una risposta HTTP riuscita non è un verdetto d’indicizzazione.

Risposte 200 che raccontano la storia sbagliata

Sono esempi semplificati. La riga di stato è tecnicamente corretta, ma è il body a determinare se quel successo è onesto.

Shell vuota di prodotto: 200 fuorviante

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Product unavailable</h1>
<p>There is nothing here.</p>

Se il prodotto è sparito definitivamente senza sostituto, restituisci 404 o 410. Se resta una pagina utile con specifiche, alternative, assistenza o informazioni di disponibilità, 200 può essere appropriato perché la pagina ha uno scopo reale.

Articolo eliminato con sostituto: usa un redirect

HTTP/1.1 301 Moved Permanently
Location: https://example.com/current-guide

Una pagina 200 da template che dice «articolo eliminato» abbandona gli utenti e invita la classificazione soft 404. Un sostituto pertinente dovrebbe essere la destinazione di un 301 lato server.

Ricerca interna senza risultati: utile o vuota

Un 200 può essere onesto quando la pagina aiuta gli utenti a riformulare la ricerca, navigare tra le categorie o trovare alternative. Una pagina scarna con solo «0 risultati» sembra un errore nonostante il codice di successo. La distinzione è l’utilità del body, non il numero 200.

Fai triage delle risposte 200 sospette

Incolla un export del crawl con URL, stato, titolo, canonical, indicizzabilità e un breve campione del testo del body. Questo prompt separa il successo HTTP dai problemi di contenuto e indicizzazione.

You are auditing URLs that return HTTP 200. Review the pasted rows without assuming that
"200" means "indexed" or "healthy."

For each URL:
1. Classify it as a substantive page, likely soft 404, redirect-needed page, genuinely gone
   page, duplicate/canonical case, or needs manual review.
2. Cite the exact evidence from the supplied title, body sample, canonical, and directives.
3. Recommend one response: keep 200, restore content, 301 to a relevant replacement,
   return 404/410, or fix canonical/noindex signals.
4. Flag any conclusion that cannot be made from the supplied data.

Do not invent page content, redirect targets, or indexing status. End with a prioritized
manual-check list.

PASTE CRAWL ROWS HERE

Controlla la risposta invece di fidarti della pagina

Ispeziona una risposta con curl

Esegui questi comandi su macOS, Linux o WSL. Il primo legge gli header della risposta; il secondo scarica anche il body, così puoi verificare che 200 contenga contenuto reale.

curl -sI https://example.com/page
curl -sS -D - https://example.com/page -o page.html

Cerca una riga di stato 200 e poi apri page.html. Gli header da soli non possono rivelare un soft 404.

Confronta una richiesta normale con uno 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"

Una differenza è un motivo per controllare regole CDN/WAF e log, non la prova che Googlebot abbia ricevuto la risposta della richiesta contraffatta. Conferma il fetch reale con URL Inspection.

Controlla una lista per risposte diverse da 200

Inserisci un URL per riga in urls.txt:

while IFS= read -r url; do
  curl -sS -o /dev/null -w "%{http_code}\t%{url_effective}\n" "$url"
done < urls.txt

Questo trova discrepanze di stato evidenti. Non può giudicare se il body 200 sia sostanziale, quindi verifica i template sospetti e i report soft 404.

Strumenti per convalidare le risposte 200

Lo strumento gratuito di Patrick

• Bulk HTTP Status Code Checker: incolla fino a 500 URL per raccogliere codici di stato, destinazioni finali, catene di redirect e latenza in un unico export. Usalo per trovare URL che non restituiscono davvero 200; poi controlla separatamente body e Search Console per gli errori soft, perché un controllo dello stato non può giudicare qualità del contenuto o indicizzazione.

Evidenze del motore di ricerca e del server

• Google Search Console URL Inspection: confronta il risultato indicizzato con un fetch live e controlla il contenuto renderizzato recuperabile da Google.
• Bing Webmaster Tools URL Inspection: controlla la risposta che Bingbot dichiara di aver ricevuto.
• Log server e CDN: conferma il codice ricevuto dai crawler reali; i log sono prove più solide del cambio di User-Agent in curl.
• Pannello Network di DevTools: verifica richiesta del documento, header e body della sessione browser.

Mettiti alla prova: 200 OK

Cinque domande rapide sul significato di 200 per la SEO. Scegli una risposta per ciascuna e poi controlla il risultato.

Cronologia modifiche