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. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Status codes Google documenta una gestione distinta di crawling e indicizzazione per queste famiglie di risposte. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 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 “not a quality signal, it’s not a SEO signal”. 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”: l’URL viene rimosso dall’indice, con “no effect on crawl rate”; 5xx (e 429) significa “il server sta fallendo”: 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 “a server error”. 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, limitato a “a few days at most”, 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. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Status codes Non dedurre una singola causa principale o un tempo esatto di rimozione dalla sola famiglia del codice. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 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: “Google doesn’t use the content from URLs that return 4xx status codes,” e “Google crawlers inform the next processing system that the content doesn’t exist.” 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. Questo sfata il mito: “The 4xx status codes, except 429, have no effect on crawl rate.” 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: “don’t use 401 and 403 status codes for limiting the crawl rate.” 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. “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling,” e “the decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error.” Alcuni 500 incidono appena; un’interruzione a livello di sito riduce drasticamente il crawling.
• Gli URL indicizzati vengono conservati… finché gli errori persistono. “Already indexed URLs are preserved in the index, but eventually dropped,” e Google “removes from the index URLs that persistently return a server error.” Un breve picco non ti deindicizza; un guasto prolungato sì.
• Anche il contenuto dei 5xx viene ignorato. “Any content Google receives from URLs that return a 5xx status code is ignored.”
• Il recupero è automatico ma graduale. “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” Google rallenta rapidamente ed è prudente nel riprendere: 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 Google lo tratta come un segnale del server: “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” 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: è “a form of rate-limiting to protect the 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 Unavailable For Legal Reasons — 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. La guida di Google sul crawl budget osserva che “if the site slows down or responds with server errors, the limit goes down and Google crawls less.” Ma il vero spreco di budget è il soft 404: “soft 404 pages will continue to be crawled, and waste your budget.” Poiché un soft 404 sembra attivo (restituisce 200), Google continua a ricontrollare una pagina che in realtà non esiste. È per questo che il soft 404 è il caso “peggiore”: non scompare in modo netto come un vero 404, resta e consuma fetch.

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:

• “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.”
• “This is an extreme measure that should only be taken for a very short period of time (a few days at most),” perché “completely closing a site even for just a few weeks can have negative consequences on Google’s indexing of your site.”
• “Don’t block the website by returning 403, 404, 410 HTTP status codes” durante il periodo di inattività: un 4xx dice “scomparso definitivamente”, esattamente il segnale sbagliato per un’interruzione temporanea.
• Il tranello che quasi tutti perdono: “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all 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 Page Indexing di Search Console, dove ciascuno corrisponde a uno stato distinto:

• Not found (404) — “this page returned a 404 error when requested.”
• Server error (5xx) — “your server returned a 500-level error when the page was requested.”
• Blocked due to unauthorized request (401) — “the page was blocked to Googlebot by a request for authorization.”
• Blocked due to access forbidden (403) — un 403 in cui sono state fornite credenziali ma l’accesso non è stato concesso.
• Blocked due to other 4xx issue — un 4xx non coperto da un altro stato; usa URL Inspection per eseguire il debug.
• Soft 404 — un messaggio “user-friendly ‘not found’ message but not a 404 HTTP response code.”
• Redirect error — catena troppo lunga, loop, 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 Validate Fix per richiedere un nuovo crawling, ma mantieni aspettative realistiche sui tempi: il recrawl non è istantaneo. E ricorda l’impostazione di Google: “it’s fine for a URL not to be indexed for the right reasons — for example… a 404 for a page that you’ve removed and have no replacement for.” Non ogni errore è un’attività da svolgere.

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 link in ingresso, link interni, presenza nella sitemap o traffico residuo: reindirizzali con un 301 verso una pagina pertinente per recuperare l’equity dei link. Lascia che gli URL davvero morti restituiscano 404 o 410. Come scrivo nella mia guida Ahrefs, per la maggior parte di questi casi la correzione pratica è “you just need to 301 redirect each of these pages to a relevant page”, ma solo quando esiste una destinazione pertinente. 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 definisce l’obiettivo di Bing come “crawl efficiency north star … to crawl a URL only when the content has been added … updated,” e gli errori persistenti vanno direttamente contro questo obiettivo: Bing consuma spazio di crawling su URL che non forniscono 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 le superfici degli errori di crawling di Bing in Bing Webmaster Tools (URL Inspection, Crawl Control, Site Scan).

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 Unauthorized — che cosa attiva lo stato “Blocked due to unauthorized request” 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 Unavailable For Legal Reasons — 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 Page Indexing di GSC — sette stati (404, 5xx, 401, 403, altro 4xx, soft 404, Redirect error) — oltre ai tuoi controlli live e ai log del server, usando Validate Fix.
• 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 Page Indexing (Guida di Search Console) — tutti gli stati di errore che vedrai giorno per giorno (404, 5xx, 401, 403, altro 4xx, soft 404, Redirect error) e Validate Fix.
• 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.” — documentazione di Google Search Central. Vai alla citazione
• “Google doesn’t use the content from URLs that return 4xx status codes.” Vai alla citazione
• “The 4xx status codes, except 429, have no effect on crawl rate.” Vai alla citazione

Google — 5xx e 429

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling.” Vai alla citazione
• “already indexed URLs are preserved in the index, but eventually dropped.” Vai alla citazione
• “Any content Google receives from URLs that return a 5xx status code is ignored.” 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.” 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.” Vai alla citazione
• “Soft 404 pages will continue to be crawled, and waste your 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.” Vai alla citazione
• “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all 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.” — 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.” 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.” 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).” 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 Not found (404) · Server error (5xx) · Blocked due to unauthorized request (401) · Blocked due to access forbidden (403) · Blocked due to other 4xx issue · Soft 404 · Redirect error — poi esegui Validate Fix 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 dei soft 404.
• 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

• Googlebot Crawl Slump? Mueller Points To Server Errors (Search Engine Journal) — l’articolo alla base della distinzione “il tasso di crawling reagisce a 429/500/503/timeout, non ai 404”, nelle parole di Mueller.
• 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