Codici di errore HTTP

TL;DR — I codici di errore HTTP sono le risposte “qualcosa è andato storto” che il server invia invece di un normale “200 OK”. Si dividono in due famiglie: 4xx (la pagina manca o è bloccata: un problema del client) e 5xx (è il server stesso ad avere difficoltà). Google li tratta in modo molto diverso: un 4xx rimuove semplicemente la pagina dalla ricerca; un 5xx rallenta il crawling dell’intero sito finché il server non si riprende. E nonostante il panico che provocano, gli errori 404 non sono una penalizzazione: devi correggere solo quelli che contano.

Che cosa sono i codici di errore HTTP

I codici di stato HTTP sono metadati di risposta standardizzati, raggruppati nelle classi di errore del client 4xx e di errore del server 5xx. Prova a sostegno di questa affermazione Primary standard or official documentation supporting the adjacent article claim. Ambito: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Attendibilità: alta · Verificato: 2026-07-14 RFC 9110: Status codes Google documenta una gestione distinta di crawling e indicizzazione per queste famiglie di risposte. Prova a sostegno di questa affermazione Primary standard or official documentation supporting the adjacent article claim. Ambito: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Attendibilità: alta · Verificato: 2026-07-14 Google: HTTP and network errors

Ogni volta che un browser o un bot dei motori di ricerca richiede una pagina, il server risponde con un codice di stato a tre cifre. 200 significa “ecco la pagina, tutto bene”. I codici di errore sono quelli nelle famiglie 400 e 500: indicano che la richiesta non è riuscita.

Esistono due famiglie e la differenza tra loro è la cosa più importante di questa pagina:

• 4xx — errori del client. Il problema è nella richiesta: la pagina è scomparsa (404), è stata rimossa definitivamente (410) oppure non puoi accedere (401, 403). Per un motore di ricerca, un 4xx dice in sostanza “qui non c’è contenuto”.
• 5xx — errori del server. Il problema è dalla tua parte: il server è andato in crash (500), un sistema da cui dipende ha fallito (502, 504) oppure è sovraccarico o fermo per manutenzione (503). Per un motore di ricerca, un 5xx dice “il server stesso è guasto in questo momento”.

Come reagisce Google a ciascuna famiglia

È qui che le due famiglie si separano:

• Una pagina 4xx viene semplicemente rimossa dalla ricerca. Google decide che il contenuto non esiste e nel tempo rimuove l’URL dal suo indice. È importante notare che molti 404 non rallentano il modo in cui Google esegue il crawling del resto del sito.
• Un 5xx rende più lento il crawling dell’intero sito da parte di Google. Quando il server restituisce errori, Google rallenta per evitare di peggiorare la situazione. Le pagine già indicizzate restano inizialmente nell’indice: Google inizia a rimuoverle solo se gli errori continuano. Quando il server torna sano, il crawling riprende da solo.

L’errore più comune

Una quantità di errori 404 non è una penalizzazione. John Mueller di Google ha detto chiaramente che i 404 non sono un segnale di qualità né un segnale SEO. Le pagine rotte e mancanti sono una parte normale del web. Quindi, quando apri Search Console e vedi migliaia di errori «Non trovata», non farti prendere dal panico: devi correggere solo quelli che contano davvero, cioè le pagine a cui le persone continuano a collegarsi, quelle nella sitemap e quelle che ricevevano traffico. Le pagine davvero morte possono restare semplicemente 404.

L’unico schema che ha uno svantaggio reale e documentato è un server che continua a restituire errori 5xx: è il caso in cui Google limita il crawling e alla fine rimuove le pagine. Anche questo è reversibile: correggi il server e il sistema si riprende.

Una rapida panoramica dei codici

Ognuno di questi codici ha una pagina di approfondimento dedicata; ecco la versione in una riga:

• 401 / 403 — la pagina è bloccata (devi effettuare l’accesso oppure non hai il permesso).
• 404 — pagina non trovata. 410 — pagina rimossa definitivamente.
• 429 — “troppe richieste” (rate limiting). Sembra un errore del client, ma Google lo tratta come un errore del server.
• 451 — bloccata per motivi legali (rimozione o blocco a livello di Paese).
• 500 / 502 / 503 / 504 — la famiglia degli errori del server (crash, gateway errato, non disponibile, timeout del gateway).
• Soft 404 — il caso insidioso: una pagina che dice “non trovata” ma restituisce un codice 200, quindi Google continua a controllarla.

Vuoi capire i meccanismi — come reagisce esattamente il tasso di crawling di Google, quando le pagine vengono deindicizzate, come oscurare correttamente un sito e come monitorare tutto in Search Console? Passa alla scheda Avanzato.

TL;DR — I codici di errore HTTP sono le classi di stato 4xx (client) e 5xx (server). Google traccia una netta linea comportamentale tra loro: 4xx (tranne 429) significa «il contenuto non esiste» e l’URL viene rimosso dall’indice senza effetti sul tasso di crawling; 5xx (e 429) significa “the server itself is failing.” (traduzione) «è il server stesso ad avere un guasto.» Google limita il crawling in proporzione, conserva inizialmente gli URL indicizzati e li deindicizza solo se gli errori persistono, poi aumenta nuovamente il tasso di crawling gradualmente dopo il recupero. 429 è numericamente un 4xx, ma Google lo definisce un errore del server. Il contenuto di qualsiasi risposta di errore viene ignorato. I 404 non sono un segnale di qualità (Mueller): fai triage in base a link e traffico, non correggere tutto e ricorda che l’impatto reale di un errore isolato dipende dall’URL (robots.txt ha una gestione speciale degli errori che una pagina ordinaria non ha). I soft 404 (un 200 che sembra «non trovato») sono segnalati da Google come spreco di crawl budget, soprattutto per i siti grandi, non come effetto garantito su ogni sito. Per un periodo di inattività pianificato usa 503 + Retry-After per pochi giorni al massimo e non usare mai 503 per robots.txt. Monitora la famiglia attraverso il report Page Indexing di GSC. Questo hub mappa e collega ogni singolo codice.

La distinzione che regge tutto il tema

Il codice del protocollo descrive l’esito HTTP; un’etichetta di Search Console descrive il modo in cui Google ha classificato un fetch osservato. Prova a sostegno di questa affermazione Primary standard or official documentation supporting the adjacent article claim. Ambito: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Attendibilità: alta · Verificato: 2026-07-14 RFC 9110: Status codes Non dedurre una singola causa principale o un tempo esatto di rimozione dalla sola famiglia del codice. Prova a sostegno di questa affermazione Primary standard or official documentation supporting the adjacent article claim. Ambito: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Attendibilità: alta · Verificato: 2026-07-14 Google: HTTP and network errors

Quattro livelli vengono appiattiti in “è un 404” quando si parla di errori; tenerli separati è ciò che rende comprensibile il resto della pagina:

1. Semantica del protocollo — il significato del codice di stato secondo la specifica HTTP (un 404 significa “non trovato”, punto).
2. Fetch osservato — ciò che Googlebot ha effettivamente ricevuto in una richiesta specifica e in un momento specifico, che può differire da ciò che vede un browser.
3. Elaborazione della ricerca — il modo in cui la pipeline di indicizzazione di Google classifica e tratta quel fetch osservato (rimuove l’URL, limita il crawl, ignora il corpo).
4. Causa principale — il motivo effettivo sul tuo server (un deployment errato, un database sovraccarico, una regola WAF), che il solo codice di stato non rivela mai.

Conoscere la famiglia (4xx contro 5xx) ti dice quale dei primi tre livelli stai osservando. Non sostituisce mai il quarto: devi comunque scoprire perché è successo.

La documentazione di Google separa chiaramente i due casi e vale la pena interiorizzarlo prima di tutto: gli errori 4xx dicono “il contenuto non esiste”; gli errori 5xx dicono “il server stesso sta fallendo”. Sono due problemi completamente diversi e la pipeline di indicizzazione di Google reagisce in due modi completamente diversi.

Un’ancora utile: perfino un codice di successo non è una promessa. Google dice chiaramente che “for Google Search, an HTTP 2xx (success) status code doesn’t guarantee indexing.” I codici di errore sono in realtà la metà più deterministica del quadro: dicono a Google, senza ambiguità, “scomparso” oppure “guasto”.

Come Google tratta gli errori 4xx

Per gli errori del client, il comportamento di Google è uniforme e netto: non usa il contenuto degli URL che restituiscono codici 4xx diversi da 429 e comunica al sistema di elaborazione successivo che “the content doesn’t exist.” (traduzione) «il contenuto non esiste.» Anche se la tua pagina 403 o 404 renderizza molto testo reale, niente di quel testo viene indicizzato: il corpo della risposta di errore viene ignorato.

Ne conseguono due conseguenze:

• Gli URL indicizzati in precedenza vengono rimossi. Quando una pagina restituisce in modo affidabile un 4xx, Google la rimuove dall’indice nel tempo.
• Non c’è una penalizzazione sul tasso di crawling. I codici 4xx, tranne 429, non influenzano il tasso di crawling. Una montagna di 404 non rallenta il crawling del resto del sito da parte di Google.

Quest’ultimo punto elimina un cattivo riflesso: non provare a limitare Googlebot con un 401 o un 403. Google avverte esplicitamente di non usare questi codici per limitare il tasso di crawling. Un muro di autenticazione non rallenta il crawling: rende soltanto invisibile il contenuto.

Come Google tratta gli errori 5xx (e 429)

Gli errori del server attivano il ramo “the server is struggling” e qui Google protegge deliberatamente il tuo sito:

• Il tasso di crawling viene limitato per primo, in proporzione al volume. Gli errori 5xx e 429 inducono i crawler di Google a rallentare temporaneamente; la riduzione è proporzionale al numero di URL che restituiscono un errore del server. Alcuni 500 incidono appena; un’interruzione a livello di sito riduce drasticamente il crawling.
• Gli URL indicizzati vengono conservati… finché gli errori persistono. Gli URL già indicizzati vengono inizialmente mantenuti, ma alla fine Google rimuove quelli che continuano a restituire un errore del server. Un breve picco non ti deindicizza; un guasto prolungato sì.
• Anche il contenuto dei 5xx viene ignorato. Google ignora qualsiasi contenuto ricevuto da URL che restituiscono un codice 5xx.
• Il recupero è automatico ma graduale. Quando il server torna a rispondere con un codice 2xx, Google aumenta gradualmente il tasso di crawling del sito. Non c’è uno «sblocco» manuale: devi correggere la causa principale e aspettare.

Perché 429 rientra nella famiglia degli errori del server

Questa è la sfumatura che manca nella maggior parte delle guide. 429 Too Many Requests è numericamente un 4xx, ma i crawler di Google lo interpretano come segnale di sovraccarico e lo considerano un errore del server. Quindi un WAF o un rate limiter che inizia a restituire 429 a Googlebot limiterà il crawling proprio come un’ondata di 500: non rimuoverà le singole pagine come farebbe un 404. Quando scompongo i codici nella mia guida ai codici di stato HTTP su Ahrefs, metto 429 insieme agli errori del server proprio per questo motivo: è una forma di limitazione delle richieste che protegge il server e fa rallentare Google.

La mappa delle famiglie di codici di errore

Ecco la vista rapida di triage dell’intera famiglia. Ogni codice qui sotto ha un approfondimento autonomo annidato sotto questo hub (sono anche nella barra laterale):

Errori di blocco/accesso

• 401 Unauthorized — il client non si è identificato o verificato quando necessario. Googlebot viene bloccato dietro una richiesta di autenticazione.
• 403 Forbidden — il client è noto ma non dispone dei diritti di accesso.

Errori di mancata trovata

• 404 Not Found — la risorsa richiesta non è stata trovata.
• 404 vs 410 — la differenza pratica tra “non trovato” e “rimosso” (è più piccola di quanto si pensi).
• 410 Gone — come un 404, ma dice anche che la risorsa non tornerà. Rimuove le pagine leggermente più velocemente.

Il codice dalla doppia identità

• 429 Too Many Requests — rate limiting; numericamente 4xx, ma Google lo tratta come un errore del server ai fini del tasso di crawling.

Legale

• 451 Non disponibile per motivi legali — bloccato per un motivo legale: blocchi a livello di Paese e rimozioni DMCA.

Errori del server (5xx)

• 500 Internal Server Error — il server ha incontrato un problema che non riesce a gestire.
• 502 Bad Gateway — una risposta errata da un server upstream.
• 503 Service Unavailable — il server è sovraccarico o fermo per manutenzione (il codice corretto per un periodo di inattività pianificato).
• 504 Gateway Timeout — nessuna risposta tempestiva da un server upstream.

Il caso insidioso

• Soft 404 — una pagina che restituisce 200 OK ma sembra “non trovata”. Il peggio dei due mondi: ne parleremo più avanti.

I redirect rotti sono adiacenti agli errori ma vengono classificati separatamente (Google li mostra come “Redirect error” in Search Console, distinto da una normale “Page with redirect” funzionante). Per impostazione predefinita i crawler di Google “follow up to 10 redirect hops” prima di arrendersi; una catena troppo lunga, un loop o un URL errato si trasformano in quello stato di Redirect error.

Un errore HTTP danneggia la SEO?

Partiamo dalla conclusione: un errore isolato su una pagina ordinaria è quasi mai un problema e i 404, nello specifico, non sono un segnale di ranking o qualità. Mueller lo ha detto esplicitamente e più volte. Il riflesso “ho 50 000 errori 404, quindi il mio sito deve essere penalizzato” è il mito numero uno da sfatare. Gli errori sono una parte normale del web; avere pagine 404 o 410 è il modo tecnicamente corretto di gestire URL che non esistono.

“Isolato” non significa però “sempre innocuo”: l’impatto reale dipende da ciò che restituisce l’errore. Un 404 su una pagina ordinaria è un non-evento; una risorsa speciale è diversa. Google assegna a robots.txt regole proprie di gestione degli errori, distinte da quelle degli URL normali, quindi un errore del server su robots.txt può influire sul crawling in un modo in cui il 404 di una pagina ordinaria non lo farebbe. Valuta un errore in base all’URL su cui compare e a ciò che dipende da esso, non soltanto in base al codice di stato.

L’unico schema con un meccanismo reale e documentato è l’errore 5xx persistente e diffuso: limitazione del tasso di crawling → eventuale deindicizzazione. Anche questo è proporzionato al numero di URL che restituiscono errori e in genere è reversibile quando il server si riprende. Google descrive il ritorno alla normalità come graduale, non istantaneo: considera quindi il tempo esatto, la frequenza dei retry e la velocità del recupero dipendenti dalle prove (ciò che descrivono i documenti di Google), non una garanzia fissa. La distinzione di Mueller da ricordare è che il tasso di crawling reagisce agli errori del server (429/500/503/timeout), non ai 404.

Spreco di crawl e deindicizzazione: due danni diversi

È utile separare i due modi in cui gli errori possono costarti:

• Deindicizzazione — 4xx persistenti (pagina rimossa come “scomparsa”) o 5xx persistenti (pagine rimosse dopo un guasto prolungato del server). Riguarda le pagine che escono dall’indice.
• Spreco di crawl budget — soprattutto un problema dei siti grandi. Google spiega: “if the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traduzione) «Se il sito rallenta o risponde con errori del server, il limite diminuisce e Google esegue meno crawling.» Il vero spreco di budget è il soft 404: “soft 404 pages will continue to be crawled, and waste your budget.” (traduzione) «Le pagine soft 404 continueranno a essere sottoposte a crawling e sprecheranno il budget.» Poiché sembrano attive (restituiscono 200), Google ricontrolla pagine che in realtà non esistono. È per questo che il soft 404 è il caso peggiore: non scompare in modo netto come un vero 404, resta e consuma richieste.

Il caso soft 404 ha due cause comuni, entrambe da nominare: un template personalizzato “pagina non trovata” che restituisce 200 invece di un vero 404 e un redirect generalizzato di ogni URL morto alla homepage; Google riconosce anche questo schema come soft 404. Una pagina 404 utile e cordiale è positiva per l’esperienza utente e pienamente raccomandata, a condizione che restituisca comunque il vero codice di stato HTTP 404.

Come gestire correttamente un periodo di inattività pianificato

Quando metti intenzionalmente offline un sito (o una sezione), il codice corretto è 503 Service Unavailable con un header Retry-After: mai un 4xx. Le indicazioni di Google “Pause your online business” sono specifiche:

• Se devi disattivare urgentemente il sito per uno o due giorni, restituisci una pagina informativa di errore con codice HTTP 503.
• È una misura estrema da usare soltanto per pochi giorni: chiudere completamente un sito anche solo per qualche settimana può danneggiare la sua indicizzazione.
• Non bloccare il sito restituendo codici HTTP 403, 404 o 410 durante il periodo di inattività: un 4xx dice «scomparso definitivamente», esattamente il segnale sbagliato per un’interruzione temporanea.
• Il tranello che quasi tutti perdono: non restituire un codice HTTP 503 per il file robots.txt, perché bloccherebbe tutto il crawling. Usa 503 per le pagine, non per robots.txt.

Come monitorare l’intera famiglia in Search Console

Giorno per giorno incontrerai questi errori nel report Indicizzazione delle pagine di Search Console, dove ciascuno corrisponde a uno stato distinto:

• Non trovata (404) — la pagina ha restituito un errore 404 quando è stata richiesta.
• Errore del server (5xx) — il server ha restituito un errore di livello 500 quando la pagina è stata richiesta.
• Bloccata per richiesta non autorizzata (401) — una richiesta di autorizzazione ha impedito a Googlebot di accedere alla pagina.
• Bloccata per accesso vietato (403) — sono state fornite credenziali ma l’accesso non è stato concesso.
• Bloccata per un altro problema 4xx — un errore non coperto da un altro stato; usa Controllo URL per eseguire il debug.
• Errore morbido 404 — un messaggio amichevole di pagina non trovata che non restituisce un vero codice HTTP 404.
• Errore di reindirizzamento — catena troppo lunga, ciclo, URL eccessivamente lungo o URL errato nella catena.

Ogni stato indica una causa principale e un percorso di correzione diversi. Dopo averne risolto uno, usa Convalida correzione per richiedere un nuovo crawling, ma mantieni aspettative realistiche sui tempi: il nuovo passaggio non è istantaneo. È normale che un URL non sia indicizzato per ragioni corrette, per esempio un 404 relativo a una pagina rimossa senza sostituzione. Non ogni errore richiede un intervento.

Search Console da sola non basta per agire: è un punto di osservazione campionato e ritardato. Quando registri un errore per il triage, annota almeno URL, momento in cui l’hai osservato, punto di osservazione (Search Console, controllo live o log del server/CDN), user agent della richiesta, metodo HTTP, codice di stato finale e percorso della risposta (compresa la catena di redirect), se è un caso isolato o ricorrente e un passaggio di verifica dopo la correzione una volta effettuato il redeploy. Confrontare GSC con un controllo di stato live e con i tuoi log trasforma una riga obsoleta del report in un problema confermato e correggibile.

Come correggere e stabilire la priorità degli errori

• Fai triage dei 404 in base al valore. Correggi quelli con collegamenti in ingresso, collegamenti interni, presenza nella sitemap o traffico residuo: reindirizzali con un 301 verso una pagina pertinente per recuperare il valore dei link. Lascia che gli URL davvero morti restituiscano 404 o 410. Nella maggior parte dei casi importanti basta reindirizzare ogni pagina con un 301 verso una destinazione pertinente, quando esiste. Non reindirizzare tutto alla homepage: è un soft 404.
• 410 contro 404 è una differenza marginale. Un 410 rimuove una pagina leggermente più velocemente di un 404; la differenza SEO pratica è ridotta. Usa 410 quando vuoi dichiarare esplicitamente che qualcosa è scomparso per sempre, ma non aspettarti un risultato molto migliore.
• Individua la causa dei 5xx. Le correzioni sono lato server: capacità e timeout per i 500, salute di upstream/CDN per 502/504 e regole WAF o di rate limiting che colpiscono erroneamente Googlebot per 403/429. Conferma il bot reale con un controllo DNS inverso/diretto prima di applicargli il rate limiting.
• Cause principali comuni da nominare: errori dell’applicazione e del database e host sovraccarichi (5xx), guasti upstream/CDN (502/504), rate limiting o WAF che blocca i bot (403/429), migrazioni interrotte e link interni obsoleti (404), pagine di errore “amichevoli” configurate male (soft 404).

Bing: uno schema simile, non verificato codice per codice in modo indipendente

Le dichiarazioni pubbliche di Bing vanno nella stessa direzione dell’approccio di Google: i codici nell’intervallo 400 vengono trattati come contenuti mancanti o vietati e quelli nell’intervallo 500 segnalano problemi del server che ostacolano l’efficienza del crawling. Tuttavia non ho verificato in modo indipendente una parità completa e aggiornata, codice per codice, con la documentazione di Bing; trattala quindi come indicazione, non come corrispondenza uno a uno confermata. Fabrice Canel descrive come principio guida la scansione di un URL soltanto quando il contenuto è stato aggiunto o aggiornato; gli errori persistenti vanno direttamente contro questo obiettivo perché consumano risorse su URL privi di contenuti freschi e indicizzabili. Bing raccomanda inoltre un 503 con Retry-After per i periodi di inattività pianificati, invece di servire pagine di errore come 200. Troverai questi errori negli Strumenti per webmaster di Bing, in Controllo URL, Controllo scansione e Analisi del sito.

Dove andare dopo

Questa pagina è l’hub concettuale della famiglia dei codici di errore. Si trova nel cluster più ampio dei codici di stato HTTP (il quadro completo 1xx–5xx, oltre a redirect e codici di successo); questo sub-hub è la mappa della metà dedicata agli errori. Ogni codice qui sotto ha un approfondimento autonomo:

Blocco/accesso

• 401 Non autorizzato — che cosa attiva lo stato «Bloccata per richiesta non autorizzata» e perché i muri di autenticazione non limitano Googlebot.
• 403 Forbidden — credenziali fornite ma accesso negato e schemi WAF/blocco bot che causano falsi 403 a Googlebot.

Non trovato

• 404 Not Found — come Google gestisce le pagine mancanti, perché non è una penalizzazione e quali 404 correggere davvero.
• 404 contro 410 — la differenza reale e piccola e quando scegliere l’uno o l’altro.
• 410 Gone — il segnale “scomparso definitivamente” e la sua rimozione leggermente più rapida.

Rate limiting

• 429 Too Many Requests — il 4xx che si comporta come un 5xx e come evitare che i rate limit limitino il tuo crawling.

Legale

• 451 Non disponibile per motivi legali — rimozioni, blocchi a livello di Paese e modo in cui vengono visualizzate le rimozioni legali.

Errori del server

• 500 Internal Server Error — il guasto generico del server e come individuarne la causa.
• 502 Bad Gateway — guasti upstream/proxy.
• 503 Service Unavailable — il codice corretto per manutenzione e inattività pianificata (con il tranello di robots.txt).
• 504 Gateway Timeout — timeout upstream.

Il caso insidioso

• Soft 404 — il 200 che sembra una pagina scomparsa, perché spreca crawl budget e come trasformarlo in un vero 404.

I redirect rotti vengono gestiti separatamente come stato Redirect error: sono correlati, ma classificati autonomamente in Search Console.

Riepilogo AI

Una sintesi della versione Avanzata:

• Due famiglie, due comportamenti. 4xx = “il contenuto non esiste”; 5xx = “il server sta fallendo”. La pipeline di indicizzazione di Google reagisce ai due casi in modo molto diverso.
• 4xx (tranne 429): il contenuto viene ignorato, l’URL esce dall’indice e non c’è “no effect on crawl rate”. Non usare 401/403 per limitare Googlebot: Google dice esplicitamente di non farlo.
• 5xx (e 429): Google limita prima il crawling (in proporzione al numero di URL in errore), conserva inizialmente gli URL indicizzati e deindicizza solo se gli errori persistono. Il recupero è automatico, ma il tasso di crawling riprende gradualmente.
• 429 è l’eccezione: numericamente 4xx, ma Google lo tratta come “a server error” ai fini del tasso di crawling: si comporta come un 5xx.
• I 404 non sono un segnale di qualità/ranking (Mueller). Non farti prendere dal panico per il conteggio degli errori: fai triage in base a link, presenza nella sitemap e traffico; fai un 301 di quelli importanti e lascia che le pagine morte restituiscano 404/410.
• L’impatto di un errore isolato dipende dall’URL, non soltanto dal codice di stato: un 404 su una pagina ordinaria è un non-evento, ma risorse speciali come robots.txt hanno una gestione propria e possono influire diversamente sul crawling.
• Il soft 404 è il tranello: un 200 che sembra “non trovato”, che Google segnala come spreco di crawl budget perché continua a ricontrollare una pagina che sembra viva, soprattutto nei siti grandi e non necessariamente su ogni sito.
• 410 contro 404 è una differenza marginale: il 410 rimuove leggermente più velocemente; la differenza pratica è ridotta.
• Inattività pianificata: usa 503 + Retry-After, “a few days at most”, mai 403/404/410 e mai 503 per robots.txt (blocca tutto il crawling).
• Monitora attraverso il report Indicizzazione delle pagine di GSC — sette stati (404, 5xx, 401, 403, altro 4xx, soft 404 ed errore di reindirizzamento) — oltre ai controlli dal vivo e ai log del server, usando Convalida correzione.
• Le dichiarazioni pubbliche di Bing vanno nella stessa direzione di quelle di Google, ma la parità completa codice per codice non è verificata in modo indipendente; anche Bing raccomanda 503 + Retry-After per l’inattività.

Documentazione ufficiale

Documentazione primaria dei motori di ricerca.

Google

• Codici di stato HTTP, errori di rete ed errori DNS — la documentazione definitiva su come Google gestisce 4xx, 5xx, 429, redirect ed errori di rete/DNS.
• Report Indicizzazione delle pagine (Guida di Search Console) — tutti gli stati di errore che vedrai giorno per giorno (404, 5xx, 401, 403, altro 4xx, soft 404 ed errore di reindirizzamento) e Convalida correzione.
• Ottimizzare il crawl budget — come gli errori del server riducono il limite di crawling e perché i soft 404 sprecano budget.
• Mettere in pausa la propria attività online nella Ricerca Google — il playbook 503 + Retry-After per l’inattività pianificata e che cosa non fare.
• Errori soft 404 — che cosa sono i soft 404 e come correggerli.
• Rendere più utili le pagine 404 — indicazioni meno recenti ma ancora valide: una pagina 404 utile va bene purché restituisca un vero codice 404.

Bing / Microsoft

• Avvisi sugli errori di crawling (Guida di Bing Webmaster Tools) — dove Bing mostra gli errori di crawling.
• Serie bingbot: massimizzare l’efficienza del crawling — la “crawl efficiency north star” di Bing, contro cui gli errori persistenti lavorano.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google e Bing. Ogni link è un deep link che porta al passaggio citato nella pagina originale.

Google — la distinzione tra 4xx e 5xx

• “For Google Search, an HTTP 2xx (success) status code doesn’t guarantee indexing.” (traduzione) «Per la Ricerca Google, un codice HTTP 2xx di successo non garantisce l’indicizzazione.» — documentazione ufficiale. Vai alla citazione
• “Google doesn’t use the content from URLs that return 4xx status codes.” (traduzione) «Google non usa il contenuto degli URL che restituiscono codici di stato 4xx.» Vai alla citazione
• “The 4xx status codes, except 429, have no effect on crawl rate.” (traduzione) «I codici di stato 4xx, tranne 429, non influiscono sul tasso di crawling.» Vai alla citazione

Google — 5xx e 429

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling.” (traduzione) «Gli errori del server 5xx e 429 inducono i crawler di Google a rallentare temporaneamente il crawling.» Vai alla citazione
• “already indexed URLs are preserved in the index, but eventually dropped.” (traduzione) «Gli URL già indicizzati vengono conservati nell’indice, ma alla fine vengono rimossi.» Vai alla citazione
• “Any content Google receives from URLs that return a 5xx status code is ignored.” (traduzione) «Qualsiasi contenuto ricevuto da URL che restituiscono un codice 5xx viene ignorato.» Vai alla citazione
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (traduzione) «I crawler di Google interpretano il codice 429 come segnale di sovraccarico del server e lo considerano un errore del server.» Vai alla citazione

Google — crawl budget e soft 404

• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traduzione) «Se il sito rallenta o risponde con errori del server, il limite diminuisce e Google esegue meno crawling.» Vai alla citazione
• “Soft 404 pages will continue to be crawled, and waste your budget.” (traduzione) «Le pagine soft 404 continueranno a essere sottoposte a crawling, sprecando il budget.» Vai alla citazione

Google — inattività pianificata

• “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code.” (traduzione) «Se devi disattivare urgentemente il sito per uno o due giorni, restituisci una pagina informativa di errore con codice di risposta HTTP 503.» Vai alla citazione
• “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.” (traduzione) «Non restituire un codice HTTP 503 per il file robots.txt, perché blocca tutto il crawling.» Vai alla citazione

Google — va bene non essere indicizzati

• “It’s fine for a URL not to be indexed for the right reasons — for example, an expected robots.txt rule on your site, a noindex tag on the page, a duplicate URL, or a 404 for a page that you’ve removed and have no replacement for.” (traduzione) «È normale che un URL non sia indicizzato per ragioni corrette, come una regola robots.txt prevista, un tag noindex, un URL duplicato o un 404 per una pagina rimossa senza sostituzione.» — Guida di Search Console. Vai alla citazione

John Mueller, Google — i 404 non sono un segnale di qualità

• “404s are not a quality signal, it’s not a SEO signal.” (traduzione) «I 404 non sono un segnale di qualità né un segnale SEO.» Leggi la copertura
• Sulle reazioni del tasso di crawling: “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts… (404s are generally fine & once discovered, Googlebot will retry them anyway)… Once things settle down on the server, the crawl rate will return to normal automatically.” (traduzione) «Mi aspetterei una reazione così rapida soltanto con risposte 429, 500, 503 o timeout; i 404 in genere vanno bene e Googlebot li riprova comunque. Quando il server si stabilizza, il tasso torna automaticamente alla normalità.» Leggi la copertura

Fabrice Canel, Microsoft Bing

• “Our crawl efficiency north star is to crawl a URL only when the content has been added (URL not crawled before), updated (fresh on-page context or useful outbound links).” (traduzione) «Il nostro principio guida per l’efficienza consiste nel sottoporre un URL a crawling soltanto quando il contenuto è stato aggiunto o aggiornato.» Vai alla citazione

Quale errore devo affrontare per primo?

Quando compare un gruppo di errori, esegui il triage in questo ordine: prima la salute del server, poi le pagine mancanti, perché è lì che si trova il danno reale a livello di sito.

1. Stai vedendo 5xx o 429 (errore del server o un picco di timeout)?

• Sì → Trattalo come urgente. È il ramo che limita il crawling a livello di sito e può deindicizzare le pagine se persiste. Individua subito la causa: capacità/timeout del server (500), salute upstream/CDN (502/504) oppure WAF/rate limiter che colpisce erroneamente Googlebot (403/429). Il recupero è automatico quando restituisci 2xx, ma il tasso di crawling riprende gradualmente.
• No → Passa oltre: i 4xx non influiscono sul tasso di crawling.

2. È un soft 404 (un 200 che sembra “non trovato”)?

• Sì → Correggi il codice di risposta. Restituisci un vero 404/410 oppure, se la pagina è stata spostata, reindirizzala con un 301 verso una pagina pertinente. Smetti di reindirizzare in modo generalizzato gli URL morti alla homepage. I soft 404 sprecano crawl budget perché Google continua a ricontrollarli.
• No → Continua.

3. È un 404 / 410 (Non trovato / Scomparso)?

• L’URL ha link in ingresso, link interni, presenza nella sitemap o traffico residuo?
  • Sì → Reindirizzalo con un 301 verso una pagina pertinente per recuperare l’equity.
  • No → Lascialo così. Una pagina davvero morta dovrebbe restituire semplicemente 404/410: non è una penalizzazione e non devi correggerla.

4. È un 401 / 403 (Bloccato)?

• La pagina dovrebbe essere pubblica? Sì → Correggi la configurazione di autenticazione/permessi o la regola WAF che blocca Googlebot. No → Va bene che sia bloccata, ma non aspettarti che 401/403 limitino Googlebot: rendono solo invisibile il contenuto.

5. È un 451 (Legale)?

• È una rimozione legale o un blocco geografico, non un bug tecnico: gestiscilo attraverso il processo legale/compliance, non quello SEO.

6. È un Redirect error?

• Accorcia la catena (Google segue fino a circa 10 hop), interrompi il loop oppure correggi l’URL errato o eccessivamente lungo nella catena, così risolve verso un unico 200 finale.

Deindicizzazione o spreco di crawl: quale danno sto davvero affrontando?

• Le pagine escono dall’indice? → Cerca 4xx persistenti (rimosse come “scomparse”) o 5xx persistenti (rimosse dopo un guasto prolungato). Gli errori isolati non producono questo risultato.
• Il crawl budget viene consumato (siti grandi)? → Cerca soft 404 ed errori diffusi: le pagine che continuano a essere ricrawlate perché sembrano vive.

Scheda rapida codice di errore → comportamento → correzione

Come Google tratta ciascun codice

Fatti rapidi

• 4xx (tranne 429): contenuto ignorato, URL rimosso, zero effetti sul tasso di crawling.
• 5xx + 429: prima limita, deindicizza solo se persiste, il recupero è graduale.
• I 404 non sono un segnale di qualità/ranking: fai triage in base a link e traffico.
• Soft 404 = il tranello: 200 che sembra scomparso → spreca crawl budget.
• Inattività pianificata = 503 + Retry-After, “a few days at most”, mai 403/404/410 e mai 503 per robots.txt (blocca tutto il crawling).
• Redirect: Google segue fino a circa 10 hop; le catene troppo lunghe o con loop = “Redirect error” in GSC.

Stati Page Indexing di GSC da tenere d’occhio Non trovata (404) · Errore del server (5xx) · Bloccata per richiesta non autorizzata (401) · Bloccata per accesso vietato (403) · Bloccata per altro problema 4xx · Soft 404 · Errore di reindirizzamento — poi esegui Convalida correzione una volta risolto.

Risorse che meritano il tuo tempo

I miei articoli correlati

• Codici di stato HTTP e il loro impatto sulla SEO — la mia analisi completa codice per codice: 4xx, 5xx, 429 e correzioni pratiche nell’intero intervallo dei codici di stato.
• 11 tipi di redirect e il loro impatto sulla SEO — il lato dei redirect, una causa principale sia degli errori di redirect sia degli errori soft di pagina non trovata.
• La guida per principianti alla SEO tecnica — dove si collocano i codici di stato nel quadro più ampio.

I miei interventi

• How Search Works (SlideShare) — la mia panoramica di crawling, rendering, indicizzazione e pubblicazione, compreso il modo in cui i codici di stato regolano la pipeline. (Vale la mia consueta precisazione: “Questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%”.)

Dal settore

• Calo del crawling di Googlebot? Mueller indica gli errori del server (Search Engine Journal) — l’articolo alla base della distinzione: il tasso di crawling reagisce a 429, 500, 503 e timeout, non alle pagine semplicemente mancanti.
• La guida definitiva ai codici di stato HTTP per la SEO (Search Engine Land) — un riferimento ampio per ogni classe di stato.
• Spiegazione dei codici di stato HTTP (Semrush) — panoramica delle famiglie di codici orientata all’implementazione.
• Una guida SEO ai codici di stato HTTP (Search Engine Journal) — riferimento codice per codice con contesto SEO.
• r/TechSEO — la community per il debug degli errori di crawling e indicizzazione.

Il modello dei due danni: scomparsa contro limitazione del crawling

Non stabilire la priorità di un errore HTTP in base alla prima cifra. Chiediti quale dei due danni crea.

Danno 1: l’URL dice che il contenuto non esiste

La maggior parte delle risposte 4xx dice a Google che il contenuto richiesto non è disponibile. Google non indicizza il corpo restituito e un URL interessato in modo persistente può uscire dall’indice. L’ambito è di solito il singolo URL: le risposte 4xx ordinarie non dicono a Google che l’intero server non è sano. L’eccezione è 429, che Google gestisce come un problema di disponibilità del server.

Domanda decisionale: questo URL dovrebbe esistere, ricevere traffico o conservare i link? Se sì, correggi lo stato errato o invia gli utenti verso una destinazione davvero equivalente. Se no, un 404 o 410 può essere il risultato corretto, non un problema SEO.

Danno 2: il server dice che non può rispondere in modo affidabile

Le risposte 5xx e 429 segnalano problemi di disponibilità o capacità. Google può ridurre il crawling per evitare di aggiungere carico; solo i guasti persistenti minacciano gli URL indicizzati. Il danno può quindi estendersi oltre un singolo URL non funzionante e rallentare scoperta e aggiornamento in tutto il sito.

Domanda decisionale: il guasto è persistente o abbastanza ampio da cambiare il comportamento dei crawler? Se sì, trattalo come un incidente infrastrutturale e ripristina risposte affidabili. Non “correggerlo” dentro Search Console.

Priorità aggiuntiva: valore e intento

Dopo aver scelto il danno, ordina gli URL interessati in base al fatto che debbano essere live, abbiano link interni o esterni, compaiano in una sitemap, ricevano traffico dalla ricerca o rappresentino un template critico. Un conteggio degli errori senza questo contesto non è un elenco di priorità.

Matrice evidenze/azione: che cosa registrare per ogni errore

Il modello dei due danni ti dice quale problema stai affrontando. Questa matrice indica che cosa registrare davvero per ogni URL interessato prima di decidere cosa fare: saltare una di queste colonne è il modo in cui una lista di triage diventa un’ipotesi:

Prompt: trasforma un export di errori GSC in una coda di triage

Esporta da Search Console l’elenco degli URL interessati e arricchiscilo quando possibile con codice di stato, presenza nella sitemap, clic/impressioni organiche, link interni, link esterni e stato previsto dell’URL. Incolla solo dati non sensibili.

You are triaging an HTTP-error URL export for technical SEO. Use only the supplied
columns. Do not assume that every 404 is a problem or that every 5xx is permanent.

For each URL:
1. Classify the response as 4xx disappearance risk, 5xx/429 crawl-throttling risk,
   soft-404 mismatch, or insufficient evidence.
2. Decide whether the URL appears intended to exist, based only on sitemap presence,
   links, traffic, template, and the supplied intended-state field.
3. Assign priority: incident-now, high, medium, low, or expected/no fix.
4. Explain the priority using the exact supplied signals.
5. Recommend the next verification, not a guessed root cause.

Prioritize broad or persistent 5xx/429 incidents first, then intended URLs with
traffic or links, then sitemap/internal-link hygiene. Keep intentional 404/410 URLs
out of the fix queue. Return a table plus a short list of missing data that would
change the ranking.

DATA:
[PASTE SANITIZED EXPORT HERE]

Verifica l’output rispetto ai controlli di stato live e alla mappa degli URL prevista dal sito prima di assegnare il lavoro.

Strumenti per il triage degli errori

• Bulk HTTP Status Code Checker — incolla gli URL esportati per raccogliere codici di stato live, catene di redirect, destinazioni e latenza; poi filtra ed esporta il risultato. Trasforma una riga obsoleta del report in prove HTTP aggiornate.
• Website Down Checker — controlla se un sospetto incidente 5xx è riproducibile dall’esterno prima di modificare le impostazioni dell’applicazione o dei crawler.
• Report Page Indexing di Google Search Console — individua i gruppi di motivi di Google e gli esempi interessati; usa URL Inspection per un controllo live rappresentativo.
• Log di accesso del server o della CDN — misura i tassi di errore lato crawler e distingue un problema su un singolo URL da uno schema di disponibilità a livello di sito.

Search Console riporta ciò che Google ha osservato; non sostituisce una richiesta live o le prove del server necessarie per trovare la causa.

URL previsti che restituiscono errori

Metrica: conteggio e quota degli URL che dovrebbero essere live ma restituiscono 4xx, 5xx o 429, segmentati per famiglia di risposta e template.

Che cosa indica: separa i veri difetti di disponibilità/indicizzazione dalla pulizia intenzionale di 404/410.

Come estrarla: unisci un crawl attuale o un export di Bulk HTTP Status Code Checker con sitemap, grafo dei link interni e inventario degli URL previsti.

Benchmark / intervallo realistico: l’obiettivo è zero errori involontari sugli URL che devono essere live. Gli URL ritirati previsti vanno tracciati separatamente, non costretti dentro un obiettivo inventato di tasso di errore a livello di sito.

Frequenza: ogni giorno per i template critici e durante i rilasci; ogni settimana per l’inventario più ampio.

Tasso di errore delle richieste dei crawler

Metrica: richieste dei motori di ricerca che restituiscono 4xx, 429 o 5xx come quota delle richieste dei crawler verificati, suddivise per stato, hostname e gruppo di percorsi.

Che cosa indica: mostra se lo spreco dei crawler è concentrato negli URL ritirati o se i guasti del server possono sopprimere la domanda di crawling.

Come estrarla: aggrega le richieste dei crawler verificati dai log di accesso della CDN o del server; non fidarti della stringa user-agent da sola quando è disponibile la verifica.

Benchmark / intervallo realistico: stabilisci la composizione normale per il tuo sito. I 404 intenzionali possono essere legittimi; le risposte 5xx/429 non spiegate su URL previsti non devono essere trattate come rumore normale della baseline.

Frequenza: monitora continuamente gli alert 5xx/429; esamina ogni settimana le tendenze segmentate.

Tendenza dell’inventario degli errori di Search Console

Metrica: conteggi degli URL interessati per motivo di Page Indexing, associati allo stato rappresentativo dell’URL e alla data di aggiornamento del report.

Che cosa indica: se l’inventario osservato da Google si sta riducendo dopo le correzioni o si sta espandendo verso altri template.

Come estrarla: esporta le tabelle dei motivi di Page Indexing e conserva snapshot datati; controlla a campione gli esempi con URL Inspection e richieste live.

Benchmark / intervallo realistico: confronta il risultato con lo stato previsto del sito e con i suoi snapshot precedenti. Search Console è campionata e ritardata, quindi non inventare una soglia di superamento in tempo reale.

Frequenza: ogni settimana e dopo che Google ha avuto il tempo di ricrawlare una correzione distribuita; usa log e controlli live per il monitoraggio immediato degli incidenti.

Mettiti alla prova: codici di errore HTTP

Cinque domande rapide su come Google gestisce gli errori 4xx e 5xx. Scegli una risposta per ciascuna e poi controlla.

Cronologia modifiche