Bloccato per altro problema 4xx

TL;DR — “Bloccato per altro problema 4xx” in Google Search Console è il gruppo residuale degli errori client che non sono già separati come 401, 403 o 404. Googlebot ha chiesto la pagina e ha ricevuto un altro errore 4xx (per esempio 400, 410 o 451), quindi la pagina non può essere indicizzata. Google non pubblica un elenco preciso dei codici che finiscono qui: il primo compito è scoprire quale codice sia davvero, perché la correzione dipende interamente da quello.

Che cosa significa questo stato

Questo gruppo di Search Console comprende una risposta 4xx che non è rappresentata dai tipi di problema più specifici del rapporto. Evidence for this claim The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google tratta le risposte 4xx diverse da 429 come contenuto non disponibile per l’indicizzazione. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Quando apri il rapporto Indicizzazione delle pagine in Search Console e vedi “Bloccato per altro problema 4xx”, significa che Googlebot ha tentato di recuperare l’URL e il server ha risposto con un errore client 4xx, ma non con uno dei codici già separati da Google. 401 (accesso richiesto), 403 (vietato) e 404 (non trovato) hanno righe dedicate. La formulazione di Google per questa riga è semplicemente “a 4xx error not covered by any other issue type” (traduzione) «un errore 4xx non coperto da nessun altro tipo di problema»: non pubblica una mappa esaustiva di ogni codice che vi confluisce. Nella pratica, 400, 405, 408, 410 Gone, 411, 413, 414, 421, 422 e 451 sono candidati comuni da controllare, non una garanzia di appartenenza.

Poiché Google ha ricevuto un errore invece della pagina, non può leggere il contenuto, quindi la pagina non verrà indicizzata; se era già indicizzata, viene rimossa.

L’etichetta è un contenitore: trova il codice reale

È il punto che trae in inganno. “Altro 4xx” è un gruppo, non una diagnosi. Un 410 Gone (pagina eliminata deliberatamente) e un 400 Bad Request (URL difettoso) finiscono nella stessa riga, ma la risposta corretta è opposta. Prima di “correggere” qualcosa, trova il codice di stato effettivo:

• In Search Console, usa Ispezione URL e fai clic su Testa URL pubblicato per vedere che cosa riceve Google in questo momento.
• Apri la pagina in DevTools → Network e guarda il codice di stato, oppure richiedila dalla riga di comando con curl -I.
• Controlla i log del server per sapere quale codice ha ricevuto davvero Googlebot.

È davvero un problema?

A volte “altro 4xx” funziona come previsto. Un 410 Gone su una pagina rimossa definitivamente è corretto: diventa un problema solo se la pagina è ancora in una sitemap o viene ancora collegata quando non dovrebbe. Se invece una pagina che vuoi indicizzare restituisce uno strano 4xx, è un errore reale da correggere alla fonte.

Una nota rapida sul 429

Potresti aver letto che 429 (“troppe richieste”, cioè un limite di frequenza) appartiene a questo gruppo. Google tratta 429 come un segnale di sovraccarico del server, non come un normale errore client, e lo usa per rallentare il crawl invece di eliminare subito la pagina. La documentazione di Google non dice in quale riga di Indicizzazione delle pagine compaia davvero un URL 429: non dare per scontato né che sia incluso né che sia escluso. In ogni caso, non disattivare il rate limiting per “correggere” un altro 4xx: nella scheda Advanced trovi i dettagli.

Vuoi la guida completa codice per codice, la sfumatura del 429, il confronto 410/404 e il decision tree diagnostico? Passa alla scheda Advanced.

TL;DR — “Bloccato per altro problema 4xx” è la riga residuale del rapporto Indicizzazione delle pagine: un 4xx ricevuto da Googlebot che non è già separato come tipo di problema (401/403/404). Google non pubblica una mappa esaustiva di ogni codice che finisce qui: 400, 405, 408, 410, 411, 413, 414, 421, 422, 451 e altri sono rami diagnostici da verificare dopo aver trovato il codice reale, non una lista garantita. La regola di Google è che tutti i 4xx tranne 429 sono trattati allo stesso modo: il contenuto è considerato inesistente, quindi la pagina non viene indicizzata e il codice non influisce sulla velocità di crawl. L’etichetta dice quasi nulla, perciò il primo passo è sempre identificare il codice reale (Live Test di Ispezione URL → Crawl Stats → riproduzione del metodo originale → log correlati di server/CDN/WAF/app), perché la correzione di un 410 (rimozione intenzionale) è opposta a quella di un 400 o di un 429. Il mito da eliminare è che 429 sia un normale 4xx: Google lo considera un errore del server sovraccarico e rallenta il crawl, ma questo comportamento non dimostra quale riga del rapporto riceva l’URL 429; considera la collocazione non confermata. Non usare 4xx per limitare Googlebot: usa 429 o 503. Identifica → correggi la causa (o conferma che sia intenzionale) → verifica un 200 nel Live Test → usa Convalida correzione, che rende l’URL idoneo alla reindicizzazione ma non la garantisce.

Che cosa dice davvero Google

L’etichetta del rapporto è una categoria: ispeziona l’URL per determinare codice e causa effettivi. Evidence for this claim The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Il comportamento HTTP è documentato separatamente dalla tassonomia del rapporto. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

La documentazione Google sul rapporto Indicizzazione delle pagine descrive lo stato in modo diretto: il server ha incontrato un errore 4xx non coperto da nessuno degli altri tipi di problema separati dal rapporto e il consiglio è eseguire il debug con lo strumento Ispezione URL. Per definizione, è il gruppo residuale: ogni 4xx che non ha già una riga propria (401 non autorizzato, 403 vietato, 404 non trovato). Google non pubblica una tabella completa che associ ogni codice rimanente a questa riga; qualsiasi elenco di “codici che finiscono qui”, compreso quello seguente, va trattato come insieme di candidati osservati, non come appartenenza ufficiale o completa.

Il comportamento sottostante proviene dalla documentazione separata di Google sui codici di stato HTTP e c’è una regola centrale: tutti gli errori 4xx, tranne 429, sono trattati allo stesso modo — i crawler Google informano il sistema di elaborazione successivo che il contenuto non esiste. Per l’indicizzazione, il risultato è identico a un 404: la pagina è considerata inesistente e non viene indicizzata, oppure viene rimossa se lo era già. E, cosa importante, i codici 4xx (di nuovo, tranne 429) non influiscono sulla velocità di crawl: non rallentano Googlebot, ma tolgono la pagina dalla valutazione. La frequenza di crawl di un URL che continua a restituire errori può comunque calare nel tempo perché Google continua a non trovare una pagina utilizzabile.

Quali codici 4xx finiscono spesso qui

La definizione residuale di Google non li nomina uno per uno: questi sono i casi che compaiono nella pratica dopo aver confermato il codice reale. Per ciascuno, ecco che cosa controllare e quale inferenza sbagliata evitare:

• 400 Bad Request — destinazione della richiesta, sintassi o framing Host/routing malformati (spesso un URL rotto o codificato male). Inferenza sbagliata: “è rotto il codice della pagina”; confronta la richiesta esatta ricevuta dal server con quella che volevi generare.
• 405 Method Not Allowed — il metodo HTTP usato non è consentito per quell’URL; la risposta dovrebbe includere un header Allow che nomina i metodi permessi. Inferenza sbagliata: un errore di curl -I (HEAD) prova che il GET di Googlebot fallisce allo stesso modo; testa i due metodi separatamente.
• 408 Request Timeout — la connessione o la richiesta non è terminata in tempo. Inferenza sbagliata: “il server è genericamente offline”; correla i tempi a livello di connessione, proxy e origine.
• 410 Gone — la risorsa è stata rimossa permanentemente. Spesso è intenzionale: vedi la sezione seguente.
• 411 Length Required — il server pretende un header Content-Length per una richiesta con corpo. È insolito in un normale fetch di pagina: conferma che la richiesta avesse davvero contenuto e quale livello l’abbia rifiutata prima di cambiare una regola.
• 413 Payload Too Large — il contenuto della richiesta supera un limite. Conferma corpo e header della richiesta in ingresso, non la dimensione della risposta della pagina.
• 414 URI Too Long — l’URI della richiesta supera un limite. Di solito è un problema di generazione di parametri o catene di redirect, non del contenuto della pagina.
• 415 / 422 (Unsupported Media Type / Unprocessable Entity) — il tipo di contenuto o le istruzioni della richiesta sono stati rifiutati. Come 411/413, descrivono condizioni del contenuto della richiesta: non allentare la validazione senza prove sulla richiesta reale.
• 421 Misdirected Request — la connessione è stata indirizzata male; Google documenta anche il 421 come modo intenzionale per escludere una route dal crawl HTTP/2. Non presumere che la pagina sia rotta su ogni protocollo: controlla se Google ha riprovato con HTTP/1.1 e quale risposta finale ha ricevuto.
• 451 non disponibile per motivi legali — blocco legale o di policy. Coinvolgi chi possiede la revisione legale/policy, non trattarlo come una normale configurazione geo/WAF.
• 429 Too Many Requests — limite di frequenza. È un caso speciale: vedi sotto.

Il senso dell’elenco non è impararlo come verità assoluta, ma usarlo come insieme iniziale di rami diagnostici. Devi comunque controllare il codice reale e il livello che lo ha prodotto prima di scegliere una correzione.

Il 429 è l’eccezione: separa semantica ed etichetta del rapporto

Molti articoli di terze parti inseriscono 429 in “altro 4xx”. Così confondono tre domande diverse: che cosa significa 429 in HTTP, come lo gestiscono davvero i crawler Google e in quale riga di Indicizzazione delle pagine viene riportato. Le prime due sono documentate; la terza no. I crawler Google trattano il codice di stato 429 come un segnale che il server è sovraccarico e lo considerano un errore del server, non un normale errore client. Le conseguenze pratiche sono:

• Un 429 fa rallentare Googlebot invece di eliminare subito la pagina.
• Poiché viene gestito come errore del server, è plausibile che un 429 autentico compaia come problema del server/crawl e non come “Bloccato per altro problema 4xx”; la documentazione Google descrive però il comportamento di elaborazione, non la tassonomia del rapporto. Considera quindi la collocazione non confermata.
• La scelta sbagliata è disattivare un rate limiting legittimo per “correggere” un altro 4xx. Se il server è davvero sotto carico, mantieni il limite e invia un header Retry-After: RFC 6585 lo rende facoltativo e la documentazione Google esaminata non dice che Googlebot pianifichi il crawl successivo dal suo valore. Invialo come buona pratica, non come istruzione garantita. Come scrivo nella mia guida Ahrefs sui codici di stato HTTP, “429s are a little special because they are generally treated as server errors and will cause Google to slow down crawling. But eventually, Google will drop these pages from the index as well.” (traduzione) «I 429 sono un caso particolare perché in genere vengono trattati come errori del server e fanno rallentare il crawling di Google. Alla fine, però, Google rimuoverà anche queste pagine dall’indice.» Quindi 429 non è gratuito: compra tempo, non mantiene per sempre la pagina nell’indice.

410 contro 404: di solito non è un problema

Un 410 Gone è il codice intenzionale più comune di questo gruppo: hai rimosso una pagina e vuoi che sparisca. Ci si sofferma spesso sul confronto 410/404, ma la differenza pratica è piccola. La documentazione Google sul crawl include 410 tra i codici 4xx che ricevono lo stesso trattamento downstream “content doesn’t exist” di un 404. Come ho scritto nella mia guida Ahrefs sui codici di stato HTTP, “404s and 410s have a similar treatment. Both drop pages from the index, but 410s are slightly faster.” (traduzione) «404 e 410 ricevono un trattamento simile. Entrambi fanno uscire le pagine dall’indice, ma i 410 sono un po’ più rapidi.» John Mueller ha detto che il divario è al massimo dell’ordine di pochi giorni e che nel medio-lungo periodo Google tratta 404 e 410 allo stesso modo: entrambi vengono rimossi dall’indice. Il fatto che Google elenchi 410 nella gestione condivisa dei 4xx non conferma da solo in quale riga del rapporto venga mostrato. Se un 410 in questo gruppo è intenzionale, è coerente con il progetto: agisci solo se la pagina dovrebbe essere attiva e conferma lo stato in Search Console, senza dedurlo dal codice soltanto.

Perché succede

La maggior parte degli “altri 4xx” del mondo reale nasce da una di queste situazioni:

• Regole WAF / protezione bot / CDN che restituiscono un 4xx insolito (spesso diverso da un 403 pulito) quando il pattern della richiesta di Googlebot attiva una regola.
• Plugin di sicurezza (per esempio plugin WordPress) che bloccano o sfidano client non-browser.
• Blocchi IP / geografici che colpiscono Googlebot, il quale esegue il crawl soprattutto da IP statunitensi.
• Rate limiting aggressivo che restituisce un 4xx dopo N richieste (dovrebbe essere 429: vedi sopra).
• URL malformati (400), limiti di dimensione della richiesta (413) o fallimenti di validazione (422) causati dal modo in cui un URL è stato generato o collegato.
• Rimozioni intenzionali (410) che semplicemente non dovrebbero più comparire in una sitemap.

Una fonte importante di problemi autoindotti è usare 4xx per limitare Googlebot. Google ha chiesto a proprietari di siti e CDN di smettere di usare 404 e altri 4xx per ridurre la velocità di crawl: non rallentano il crawl, eliminano solo il contenuto dalla Ricerca. Se vuoi che Googlebot rallenti, restituisci 500, 503 o 429, non un 4xx.

Come diagnosticare il codice reale

Trattalo come un decision tree, dall’alto verso il basso. Nessuno strumento garantisce da solo il codice esatto: concatenali:

1. Ispezione URL → Testa URL pubblicato. Conferma la disponibilità attuale: Google riceve ora un 4xx oppure la riga del rapporto è vecchia? Un Live Test fallito non mostra sempre gli header o la riga di stato grezza, quindi usalo prima come controllo di disponibilità, non come diagnosi completa.
2. Rapporto Statistiche di scansione. Mostra esempi rappresentativi delle richieste di crawl di Google (codice, tempo di risposta, tipo di file), utile per corroborare ciò che ha visto un crawl pianificato, perché il Live Test usa Google-InspectionTool e non il crawler comune.
3. Riproduci la richiesta originale. Apri l’URL nella scheda Network di DevTools o usa curl; se sospetti una regola bot, invia lo user-agent di Googlebot (idealmente anche da fuori rete) per attivarla. Riproduci anche il metodo: curl -I invia HEAD e può dare un risultato diverso dal GET usato da Google.
4. Leggi i log correlati di server / CDN / WAF / proxy auth / applicazione. Di solito sono l’unico posto in cui trovi codice esatto, livello che ha negato e regola o condizione che ha prodotto la risposta, soprattutto quando il Live Test non espone gli header grezzi.
5. Verifica separatamente l’identità del richiedente. Uno user-agent non dimostra che la richiesta sia di Googlebot: conferma DNS inverso + diretto o gli intervalli IP pubblicati da Google prima di decidere se il blocco colpisce un crawler legittimo.
6. Collega il codice alla causa. 400/405/408/414 → framing, metodo, timeout o URI; 411/413/415/422 → problema del contenuto della richiesta solo con prove del metodo e del corpo; 410 → rimozione intenzionale; 421 → possibile uscita documentata da HTTP/2; 4xx di un livello di sicurezza → eccezione stretta per il client verificato e per la route; un 429 → rate limiting, da trattare come carico del server.

Come correggerlo, codice per codice

• 400 / 405 / 408 / 414 (framing, metodo, tempi, lunghezza URI). Correggi la fonte della richiesta malformata, l’URL rotto o troppo lungo, il metodo non consentito oppure la connessione lenta/incompleta al livello che lo genera davvero. Confronta la richiesta esatta vista dal server con quella che l’applicazione voleva inviare.
• 411 / 413 / 415 / 422 (errori del contenuto della richiesta). Descrivono condizioni legate a corpo, lunghezza o tipo di contenuto della richiesta, insolite per un normale GET di pagina. Prima di allentare un limite o una regola di validazione, controlla nei log quale metodo e quale contenuto hanno attivato il rifiuto e quale livello l’ha prodotto.
• 410 — è intenzionale? Se la pagina deve essere scomparsa, il 410 è corretto: rimuovila da sitemap e link interni perché smetta di apparire come “problema”. Se dovrebbe essere online, il 410 è un errore da annullare.
• 421 — controlla se è un’uscita intenzionale da HTTP/2. Google documenta il 421 come modo per escludere una route dal crawl HTTP/2. Verifica il fallback HTTP/1.1 e la risposta finale prima di trattarlo come pagina rotta.
• 429 — rate limiting corretto. Non eliminare un rate limiting legittimo. Mantienilo, aggiungi un header Retry-After come buona pratica (è facoltativo per la specifica HTTP e la documentazione Google non conferma un calendario di Googlebot) e ricorda che Google legge 429 come “rallenta”, non “deindicizza”. Se una regola restituisce 4xx solo per limitare Googlebot, cambiala in 429 o 503.
• 451 — conferma prima il contesto legale/policy. Non trattarlo come una normale configurazione geo/WAF: indirizzalo al responsabile delle decisioni legali o di policy.
• Blocchi WAF / CDN / plugin di sicurezza. Identifica prima livello e regola esatti. Inserisci in allowlist Googlebot verificato tramite DNS inverso o intervalli IP pubblicati, mai fidandoti soltanto dello user-agent falsificabile; limita l’eccezione alla route e al client previsti, invece di aprire tutto il traffico. La correzione deve portare l’URL a 200.

Non usare 4xx per rallentare Googlebot

Vale la pena dirlo da solo perché è una causa frequente di “altro 4xx” autoindotto: restituire codici 4xx per limitare Googlebot non funziona e rimuove il contenuto dalla Ricerca. Come riassumo la regola nella mia guida Ahrefs sui codici di stato HTTP, “4xxs will cause pages to drop from the index.” (traduzione) «I 4xx faranno uscire le pagine dall’indice.» Se il vero obiettivo è rallentare il crawl, usa 429 o 503: sono i codici che Google interpreta come “torna più tardi” e l’effetto è temporaneo.

Dopo la correzione

Dopo aver risolto la causa sottostante (oppure confermato che il 410 è intenzionale e ripulito sitemap e link):

1. Ispezione URL → Testa URL pubblicato per confermare che la risposta live sia ora 200.
2. Richiedi indicizzazione per gli URL prioritari e/o fai clic su Convalida correzione sulla riga “Bloccato per altro problema 4xx” del rapporto Indicizzazione delle pagine.
3. Una risposta 200 rende l’URL idoneo al crawl, all’elaborazione e a una possibile indicizzazione dopo il nuovo crawl: non garantisce l’indicizzazione né una tempistica fissa. Non inviare richieste in massa prima di correggere la causa, altrimenti rientrerai nello stesso gruppo.

Danneggia la SEO?

Solo se le pagine che vuoi davvero indicizzare restituiscono un 4xx: escono dall’indice e perdono posizionamento finché non le correggi. Se il 4xx è intenzionale (un 410 per una pagina cancellata o un blocco deliberato su un percorso amministrativo che non dovrebbe essere in sitemap), funziona come previsto e non sta danneggiando nulla.

I fratelli da conoscere sono “Bloccato per accesso vietato (403)” e “Bloccato per richiesta non autorizzata (401)”, le righe dedicate a firewall e accesso, e “Non trovato (404)”, il suo gruppo. Questo stato copre tutto il resto della famiglia 4xx. Per il rapporto e il modo in cui raggruppa le cause di mancata indicizzazione, consulta la panoramica del rapporto Indicizzazione delle pagine.

Riepilogo IA

Una sintesi della versione Advanced:

• Che cos’è. “Bloccato per altro problema 4xx” nel rapporto Indicizzazione delle pagine di GSC significa che Googlebot ha ricevuto un 4xx non separato come 401/403/404. Google non pubblica un elenco esaustivo: 400, 405, 408, 410, 411, 413, 414, 421, 422 e 451 sono candidati comuni da verificare, non una lista garantita. La pagina non viene indicizzata e viene rimossa se lo era.
• La regola centrale. Tutti i 4xx tranne 429 sono trattati allo stesso modo: Google considera il contenuto inesistente, come per un 404, senza effetto sulla velocità di crawl.
• L’etichetta è un contenitore. Non dice la causa: trova prima il codice reale (Live Test di Ispezione URL → Crawl Stats → riproduzione del metodo originale → log correlati di server/CDN/WAF; curl -I è HEAD, non GET, quindi testa entrambi).
• 429 è l’eccezione e un mito comune. Google lo tratta come errore del server sovraccarico e rallenta il crawl invece di eliminare subito la pagina, ma questo comportamento non conferma in quale riga venga riportato l’URL 429: considera la collocazione non confermata. Mantieni il rate limiting e invia Retry-After come buona pratica (facoltativo; i documenti Google non dicono che Googlebot lo usi per pianificare il crawl). Non disattivare la protezione per “correggere” un altro 4xx.
• 410 contro 404. 410 (Gone) è il codice intenzionale più comune; Google gli applica lo stesso trattamento downstream “content doesn’t exist” del 404 e la differenza pratica di tempi è piccola. Se è intenzionale, funziona come previsto: conferma l’intento prima di toccarlo.
• Anche 421 può essere intenzionale. Google documenta il 421 come modo per escludere una route dal crawl HTTP/2: controlla fallback HTTP/1.1 e risposta finale prima di presumere che la pagina sia rotta.
• Perché accade. Blocchi WAF/CDN/plugin, IP o geografia, rate limiting, URL malformati o troppo lunghi (400/414), condizioni del corpo della richiesta (411/413/415/422, da provare con log) o rimozioni intenzionali (410).
• Non limitare con 4xx. Usare 404 o altro 4xx per rallentare Googlebot rimuove il contenuto dalla Ricerca: usa 429 o 503.
• Correggi e valida. Identifica il codice (non fermarti a un Live Test fallito: usa Crawl Stats e log correlati) → correggi la causa o conferma che sia intenzionale e ripulisci sitemap/link → verifica 200 nel Live Test → usa Convalida correzione. Un 200 rende l’URL idoneo alla reindicizzazione, ma non la garantisce né garantisce tempi.

Documentazione ufficiale

Documentazione primaria dei motori di ricerca.

Google

• Rapporto Indicizzazione delle pagine — il rapporto, compresa la voce “Blocked due to other 4xx issue” (un 4xx non coperto da altri tipi) e i gruppi 401/403/404.
• Come i codici di stato HTTP e gli errori di rete e DNS influiscono su Ricerca Google — la regola per cui tutti i 4xx tranne 429 sono trattati allo stesso modo, 429 come segnale di sovraccarico e i 4xx diversi da 429 senza effetto sulla velocità di crawl.
• Non restituire 404 al mio cibo (blog Search Central, 2023) — la richiesta di Google a proprietari e CDN di non usare 404 e altri 4xx per limitare Googlebot e di usare invece 500/503/429.
• Verificare Googlebot e gli altri crawler Google — DNS inverso + diretto e intervalli IP pubblicati per inserire in allowlist il Googlebot reale prima di cambiare una regola WAF/firewall.

Bing / Microsoft

• Bing Webmaster Tools — Crawl Control — Bing non usa l’etichetta esatta “other 4xx” di Google, ma il principio è lo stesso: un 4xx impedisce a Bingbot di recuperare contenuto utilizzabile, quindi l’URL non viene indicizzato. Usa Crawl Control per gestire la velocità di Bingbot invece di bloccarlo con codici di errore.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google e, per la mia guida Ahrefs sui codici di stato, parole mie che posso attribuire direttamente a me stesso. Ogni link è un deep link che porta al passaggio citato nella pagina sorgente.

Google — come vengono gestiti i 4xx (tranne 429)

• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (traduzione) «Tutti gli errori 4xx, tranne 429, vengono trattati allo stesso modo: i crawler Google comunicano al sistema di elaborazione successivo che il contenuto non esiste.» — Google Search Central docs. Vai alla citazione

Google — 429 è trattato come errore 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.” (traduzione) «I crawler di Google trattano il codice di stato 429 come un segnale che il server è sovraccarico e lo considerano un errore del server.» — Google Search Central docs. Vai alla citazione

Google — non usare 4xx per limitare la velocità di crawl

• “The 4xx status codes, except 429, have no effect on crawl rate.” (traduzione) «I codici di stato 4xx, tranne 429, non hanno effetto sulla velocità di crawling.» — Google Search Central docs. Vai alla citazione

John Mueller, Google — 410 contro 404 (parafrasi)

John Mueller di Google ha descritto il divario tra 410 e 404 come una piccola differenza, dell’ordine di pochi giorni al massimo, e ha detto che nel medio-lungo periodo Google tratta 404 e 410 allo stesso modo: entrambi escono dall’indice. Il commento è riportato da Google offre indicazioni sui codici di stato 404 e 410 (SEJ). (Qui è parafrasato invece di essere citato alla lettera in attesa di un controllo indipendente della formulazione: verifica la fonte prima di usare una citazione diretta.)

Patrick Stox (io) — dalla mia guida Ahrefs sui codici di stato

• “4xxs will cause pages to drop from the index.” (traduzione) «I 4xx faranno uscire le pagine dall’indice.» — Patrick Stox, “Codici di stato HTTP e relativo impatto SEO,” Ahrefs. Vai alla citazione
• “404s and 410s have a similar treatment. Both drop pages from the index, but 410s are slightly faster.” (traduzione) «404 e 410 ricevono un trattamento simile: entrambi fanno uscire le pagine dall’indice, ma i 410 sono un po’ più rapidi.» Vai alla citazione
• “429s are a little special because they are generally treated as server errors and will cause Google to slow down crawling. But eventually, Google will drop these pages from the index as well.” (traduzione) «I 429 sono un caso particolare perché in genere vengono trattati come errori del server e fanno rallentare il crawling di Google. Alla fine, però, Google rimuoverà anche queste pagine dall’indice.» Vai alla citazione

Nota su Retry-After: RFC 6585 consente (ma non richiede) che una risposta 429 includa l’header Retry-After. Inviarlo è una pratica ragionevole per un client ben educato, ma la documentazione Google esaminata per questa pagina non dice che Googlebot usi quel valore come calendario letterale del crawl successivo: presentalo come metadato di risposta facoltativo, non come istruzione Googlebot confermata.

Checklist: diagnostica → correzione → validazione dell’altro 4xx

Applica questa lista a qualsiasi URL che mostra “Bloccato per altro problema 4xx”:

• Trova prima il codice reale — Ispezione URL → Testa URL pubblicato, Statistiche di scansione per dettagli rappresentativi, scheda Network di DevTools / curl (HEAD e GET) e log correlati di server-CDN-WAF. L’etichetta del gruppo non è la diagnosi e Google non pubblica una mappa completa codice-riga.
• Conferma che sia attuale, non vecchio — Testa URL pubblicato mostra un 4xx corrente, non una vecchia riga del rapporto; se il test fallito non espone gli header grezzi, corrobora il risultato nei log.
• Classificalo. Errore di framing/metodo/URI o tempi (400/405/408/414)? Condizione del contenuto della richiesta che richiede prove del corpo (411/413/415/422)? Rimozione intenzionale (410)? Possibile uscita HTTP/2 (421)? Questione legale/policy (451)? Blocco di un livello di sicurezza? Un possibile 429 (rate limit)?
• Se è 410 (Gone): la pagina dovrebbe essere scomparsa? Se sì, è corretto: rimuovila da sitemap e link interni. Se no, ripristina la pagina.
• Se è 421: conferma che sia un’uscita HTTP/2 intenzionale e controlla fallback HTTP/1.1 e risposta finale prima di trattarlo come rotto.
• Se è un errore di richiesta/framing: correggi alla fonte l’URL malformato o troppo lungo, il metodo consentito oppure il problema di timeout/connessione; smetti di collegare o elencare l’URL errato.
• Se è un errore del contenuto della richiesta (411/413/415/422): conferma metodo e corpo reali nei log prima di allentare un limite o una regola di validazione.
• Se è un blocco di sicurezza/WAF/CDN: verifica il Googlebot reale (DNS inverso o intervalli IP pubblicati), poi inserisci in allowlist solo identità/IP e route necessarie: non lo user-agent e non un’apertura globale.
• Se riguarda davvero il throttling: non usare 4xx: restituisci 429 o 503 e aggiungi Retry-After come buona pratica. Mantieni il rate limiting legittimo e non dare per scontato che Googlebot programmi il crawl successivo da quell’header.
• Conferma un 200 — Testa URL pubblicato ora restituisce 200 per le pagine che vuoi indicizzare.
• Valida — fai clic su Convalida correzione sulla riga “altro 4xx” e/o richiedi l’indicizzazione degli URL prioritari. Questo rende l’URL idoneo alla reindicizzazione, non la garantisce: non inviare richieste in massa prima di aver corretto la causa.

I modelli mentali

1. L’etichetta è un gruppo, non una diagnosi. “Altro 4xx” è la riga residuale di Google per ogni 4xx che non è già separato come tipo di problema: Google non pubblica l’elenco esatto, anche se 400, 405, 408, 410, 411, 413, 414, 421, 422 e 451 sono candidati comuni. Il primo gesto non è mai “correggilo”, ma chiedersi: “quale codice è davvero?” Tutto il resto dipende dalla risposta.

2. Per l’indicizzazione, altro 4xx = 404. Google tratta tutti i 4xx tranne 429 allo stesso modo: il contenuto è considerato inesistente. Qualunque sia il codice specifico, il risultato per l’indicizzazione è quello di un 404: non indicizzato, rimosso se lo era già. E questo significa anche nessun effetto sulla velocità di crawl.

3. 429 è un errore del server, non del client — e la sua riga nel rapporto è una domanda separata e non confermata. Google legge 429 come “server sovraccarico” e rallenta invece di rimuovere subito la pagina: questo è documentato. Non è documentato, in un senso o nell’altro, dove venga mostrato un URL 429 in questo rapporto: non considerare risolta la collocazione. Non disattivare il rate limiting per far sparire la riga; invia Retry-After come buona pratica, senza presumere che Googlebot lo segua secondo un calendario.

4. Intenzione o errore. Un 410 su una pagina cancellata o un 421 che esclude una route da HTTP/2 possono funzionare come previsto; un 400 su una pagina che vuoi indicizzare è un bug. Chiediti “questo URL dovrebbe essere attivo e su quale protocollo?” prima di correggerlo. Se non dovrebbe essere attivo, la correzione consiste nel non elencarlo più (sitemap, link), non nel trasformarlo in 200.

5. 4xx è il throttling sbagliato. Se vuoi rallentare Googlebot, un 4xx non lo fa: deindicizza. I codici “torna più tardi” sono 429 e 5xx/503. Scegli il codice coerente con l’intento: “è scomparso” (4xx) oppure “sono sovraccarico, riprova dopo” (429/503).

Scheda rapida degli altri 4xx

Codici che compaiono spesso qui e correzione tipica (Google non pubblica una lista completa di appartenenza a questa riga: considera la tabella un insieme di rami diagnostici da verificare dopo aver trovato il codice, non una garanzia.)

Gli stati fratelli in Indicizzazione delle pagine

Scegli il codice in base all’intento

Trova il codice di stato reale

L’etichetta di GSC non dice quale 4xx stai affrontando: controllalo direttamente. -I invia una richiesta HEAD, non il GET che Google usa per recuperare una pagina. Un risultato solo HEAD (per esempio 405) non dimostra che cosa restituisca il GET: testa entrambi i metodi.

macOS / Linux

# HEAD only — read the status line (e.g. "HTTP/1.1 410 Gone")
curl -s -I https://www.example.com/page/

# GET — reproduces the method Google actually uses to fetch page content
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

# If you suspect a bot-specific block, fetch as Googlebot's user-agent (GET)
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

Windows (PowerShell)

# GET request, matching what Google actually uses to fetch page content
$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Get `
  -UserAgent $ua -SkipHttpErrorCheck | Select-Object StatusCode, StatusDescription

Se il codice differisce tra HEAD e GET, o tra una richiesta normale e una richiesta con user-agent Googlebot, hai trovato una regola specifica del metodo o del bot. Un WAF sofisticato può usare anche IP, protocollo o categoria client invece del solo user-agent; per una riproduzione completa, testa da fuori la tua rete e non presumere che una corrispondenza dello user-agent dimostri che la stessa regola colpisca il Googlebot reale.

Verifica che un bot sia davvero Googlebot (prima dell’allowlist)

Se il 4xx arriva da un livello di sicurezza e stai per far passare il crawler, conferma prima che sia davvero Googlebot: lo user-agent è banale da falsificare e sostituire solo quello in una richiesta di test non riproduce IP sorgente, categoria client, protocollo o percorso della regola edge di Google.

macOS / Linux

# 1) Reverse DNS the IP from your logs — must end in googlebot.com / google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Se la ricerca inversa non termina in un dominio Google, oppure la ricerca diretta non restituisce l’IP originale, non è Googlebot: non inserirlo in allowlist. Puoi anche confrontare l’IP con gli intervalli pubblicati da Google (googlebot.json). L’allowlist deve basarsi su identità/IP verificati, mai soltanto sulla stringa user-agent.

Invia Retry-After su un 429 (non eliminare il rate limiting)

Se un URL è davvero soggetto a rate limiting, restituisci 429 con Retry-After come buona pratica HTTP invece di disattivare la protezione o restituire un 4xx “vero”. Retry-After è facoltativo secondo RFC 6585 e la documentazione Google non conferma che Googlebot programmi il crawl dal valore: consideralo igiene ragionevole, non una correzione dimostrata. Gli snippet seguenti sono punti di partenza illustrativi: confrontali con configurazione server/CDN e policy di sicurezza prima di distribuirli.

Apache (.htaccess / config)

# Example: return 429 with a 1-hour Retry-After for rate-limited responses
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 429"

Nginx

# limit_req_status makes throttled requests return 429 instead of 503
limit_req_status 429;
# add a Retry-After hint on 429 responses
error_page 429 = @rate_limited;
location @rate_limited {
    add_header Retry-After 3600 always;
    return 429;
}

Risorse che vale la pena consultare

Ufficiali

• Rapporto Indicizzazione delle pagine (Google) — la voce “other 4xx” e i gruppi fratelli 401/403/404.
• How HTTP status codes affect Google Search (Google) — regola tutti-i-4xx-tranne-429, sfumatura 429 come errore del server e “no effect on crawl rate”.
• Don’t 404 my yum (Google, 2023) — non usare 404/altro 4xx per limitare Googlebot.
• Verifying Googlebot (Google) — DNS inverso + intervalli IP pubblicati.

I miei articoli correlati

• Codici di stato HTTP e relativo impatto SEO — la guida completa al significato SEO dei codici, compresi 4xx, 410/404 e 429 citati qui.
• Guida introduttiva alla SEO tecnica — il quadro generale in cui collocare errori di crawl e indicizzazione come questo.

Di altri autori

• r/TechSEO — community per il debug di crawl e indicizzazione, compresi i thread sugli “strani 4xx in GSC”.
• Google sconsiglia 403 o 404 per limitare la velocità di crawling (Search Engine Land) — il resoconto della guida di Gary Illyes “Don’t 404 my yum”: usare 500/503/429.
• Google: 404 e 410 — differenze minime (Search Engine Roundtable) — il commento di Mueller sul divario pratico minimo tra 410 e 404.
• Google offre indicazioni sui codici di stato 404 e 410 (Search Engine Journal) — fonte riportata delle osservazioni Mueller sulla velocità 410/404; conferma il testo esatto nella pagina live prima di citarlo.
• How to Fix Blocked due to other 4xx issue (Onely) — guida dettagliata sui codici comuni, utile per audit di sitemap e link interni; le sue affermazioni sull’appartenenza sono la lettura dell’autore, non tassonomia Google confermata.
• Blocked due to other 4xx issue (SEOTesting) — log del server e monitoraggio preventivo, con 422, 405, 413 e 414; stessa cautela sulle affermazioni di appartenenza.

Trova il codice reale dietro “altro 4xx”

“Altro 4xx” è un contenitore, perciò l’unico primo passo utile è identificare quale codice sta davvero scattando: è questo che la sezione diagnostica chiama “trattalo come un decision tree, dall’alto verso il basso”. Conferma prima il codice live, poi scegli il ramo in base alla famiglia prima di toccare la configurazione.

Tieni sotto controllo il gruppo “altro 4xx”, non solo la sua esistenza

L’unico numero da osservare è quanti URL si trovano nel tempo nella riga “Bloccato per altro problema 4xx” del rapporto Indicizzazione delle pagine: una singola fotografia non dice se una correzione ha funzionato o se stanno entrando nuovi codici problematici, soprattutto perché il gruppo mescola cause intenzionali e accidentali.

Conteggio del gruppo altro 4xx nel tempo

• Metrica — numero di URL sotto “Bloccato per altro problema 4xx” nel rapporto Indicizzazione delle pagine di GSC, seguito settimana per settimana e, idealmente, separato per codice reale una volta identificato per URL.
• Che cosa dice — se le correzioni di richiesta/validazione (400/405/411/413/422) e l’allowlist WAF/CDN stanno funzionando. Per URL il cui codice reale è un 410 intenzionale, il conteggio dovrebbe restare piatto dopo aver ripulito sitemap e link interni; se sale, di solito nuove pagine “rimosse” vengono ancora collegate o inserite in sitemap per errore.
• Come estrarla — rapporto Indicizzazione delle pagine di GSC, filtrato alla riga “altro 4xx”; controlla campioni con Ispezione URL → Testa URL pubblicato per confermare che il rapporto non mostri una fotografia vecchia.
• Benchmark / intervallo realistico — non esiste un obiettivo universale: dipende da quanti URL restituisci intenzionalmente con 410 o simili. Il criterio onesto è zero altri 4xx tra gli URL che vuoi indicizzare e un conteggio piatto, non crescente, per gli URL rimossi deliberatamente. Stabilisci una baseline prima di giudicare la direzione.
• Cadenza — ogni settimana subito dopo una correzione, finché il conteggio si stabilizza; poi mensile come controllo di regressione, soprattutto se usi un WAF/CDN con regole che possono cambiare indipendentemente dai tuoi deploy.

Runbook: identifica, correggi, valida

Il flusso “altro 4xx” è lo stesso breve ciclo per ogni URL del gruppo, qualunque sia il codice specifico: identifica prima il codice reale, perché da lì i rami di correzione divergono nettamente.

1. Conferma il codice live. Usa Ispezione URL → Testa URL pubblicato per confermare che Google riceva ancora un 4xx e vedere che cosa ha ricevuto: la riga del rapporto può essere vecchia e un Live Test fallito non espone sempre gli header grezzi. Confronta con il rapporto Statistiche di scansione per esempi rappresentativi di ciò che ha ricevuto il crawler pianificato.

2. Riproduci la richiesta originale. Apri l’URL nella scheda Network di DevTools o usa curl: prova il metodo GET, non solo curl -I, che invia HEAD e può restituire un risultato diverso. Se sospetti una regola specifica per bot, invia lo user-agent di Googlebot e, idealmente, prova da fuori la tua rete per attivare la stessa regola; ricorda però che cambiare solo lo user-agent non riproduce IP, protocollo o categoria client reali di Google.

3. Leggi i log. Controlla i log di server, CDN, WAF e proxy di autenticazione per il codice esatto e la regola o condizione che lo ha prodotto: di solito è più rapido che indovinare dal solo browser e spesso è l’unico modo per vedere i dati grezzi che il Live Test non espone.

4. Collega il codice alla causa. 400/405/408/414 → framing della richiesta, metodo, timeout o lunghezza URI. 411/413/415/422 → diagnostica come problema del contenuto solo con prove del metodo/corpo effettivi. 410 → rimozione intenzionale, da confermare. 421 → controlla l’uscita HTTP/2 documentata da Google e il fallback HTTP/1.1. 451 → revisione legale/policy. 4xx di un livello di sicurezza → blocco da limitare strettamente. Un possibile 429 → rate limiting trattato come carico del server; la sua collocazione nel rapporto non è confermata.

5. Correggi in base alla causa. Errori di framing → correggi la fonte (URL errato/troppo lungo, metodo sbagliato, timeout) e smetti di collegare o elencare l’URL difettoso. Errori del contenuto → conferma nei log la richiesta reale prima di allentare un limite. 410 intenzionale o uscita 421 → lasciali, ripulendo sitemap e link (410) o confermando il fallback di protocollo (421). 451 → revisione legale/policy. Blocco del livello di sicurezza → verifica Googlebot reale con DNS inverso o intervalli IP pubblicati e limita l’allowlist a identità e route, mai allo user-agent o a una regola globale. 429/rate limit → mantieni il limite, aggiungi Retry-After come buona pratica (facoltativo secondo RFC 6585 e non un calendario Googlebot confermato); se una regola usa 4xx solo per rallentare Googlebot, passa a 429 o 503.

6. Valida e fermati. Conferma che Testa URL pubblicato restituisca ora 200 per le pagine da indicizzare, poi fai clic su Convalida correzione sulla riga “altro 4xx” e/o richiedi l’indicizzazione degli URL prioritari. Una risposta 200 rende l’URL idoneo a un nuovo crawl e a una possibile reindicizzazione, ma non è una garanzia né una tempistica fissa: non inviare richieste in massa prima che la causa sia davvero risolta, altrimenti rientrerai nello stesso gruppo.

Prompt IA pronti all’uso

Prompt da copiare per classificare il codice “altro 4xx” e la correzione appropriata a partire dall’output diagnostico grezzo. Conferma sempre la conclusione contro la configurazione reale del server/WAF prima di cambiare qualcosa.

Classifica codice e causa dall’output di curl

I'm diagnosing a "Blocked due to other 4xx issue" status in Google Search
Console. Below is the raw output of GET and HEAD requests to the URL (note
that curl -I alone only tests HEAD, which can differ from what Google's GET
request receives). Tell me the exact status code, and classify the likely
cause as one of: (1) a request-framing/timeout/URI-length issue (400, 405,
408, 414), (2) a request-content condition needing body evidence (411, 413,
415, 422), (3) an intentional 410 Gone, (4) a possible HTTP/2 opt-out (421),
(5) a legal/policy block (451), (6) a WAF/CDN/security-plugin block, or (7) a
mislabeled 429 rate limit. Explain which detail in the output pointed you to
that answer, and flag anything you can't determine from this output alone.

CURL OUTPUT (GET and HEAD):
[paste]

Classifica una riga di log WAF/server

I'm investigating an "other 4xx" status Googlebot is hitting on a page I want
indexed. Below is a log line (or a few) from my server/CDN/WAF showing the
blocked request. Tell me whether this looks like a bot-identity rule
(user-agent or IP based), a rate-limit/challenge rule that should really be
returning 429, or a request/validation error, and what I'd need to change or
allowlist to fix it without disabling the underlying protection.

LOG LINE(S):
[paste]

Controllo di buon senso prima di distribuire una correzione

I'm about to change how a URL responds because it's currently returning
[status code] and showing as "Blocked due to other 4xx issue" in Search
Console. Here's what I'm about to change: [describe]. Point out anything I
might be missing — for example, whether this could accidentally expose or
re-index a page that's supposed to stay gone (a 410 I'm about to undo), or
whether I should allowlist verified Googlebot instead of loosening a security
rule for everyone.

Mettiti alla prova: “Bloccato per altro problema 4xx”

Cinque domande sul significato del gruppo “altro 4xx”, sull’eccezione 429 e su come diagnosticarlo e correggerlo. Scegli una risposta per ogni domanda, poi controlla.

Strumenti per diagnosticare e correggere gli stati “altro 4xx”

• HTTP Status Checker — incolla l’URL interessato (o un gruppo) per confermare il codice reale dietro l’etichetta GSC, vedere l’intera catena di risposta e trovare redirect che avvengono prima del 4xx.
• Googlebot Verifier — controlla che un IP che dichiara di essere Googlebot sia autentico (intervalli IP pubblicati + DNS inverso) prima di inserirlo in allowlist oltre WAF, CDN o plugin di sicurezza.
• Google Search Console — Ispezione URL → Testa URL pubblicato — il modo più vicino per vedere la risposta esatta ricevuta ora da Googlebot, invece di una possibile riga vecchia del rapporto.
• curl -I — il modo più rapido per leggere la riga di stato grezza e ripetere la richiesta con user-agent Googlebot se sospetti una regola bot.
• Dashboard dei log di server/CDN/WAF (Cloudflare, Akamai, Sucuri, log di un plugin di sicurezza e simili) — trova codice esatto e regola o condizione che lo ha prodotto.

Problemi comuni, codice per codice

Ogni codice che finisce in “altro 4xx” è una situazione indipendente di sintomo, causa e correzione: il gruppo non ha una sola causa radice. Tratta quindi le schede seguenti come ricerche separate, non come un’unica catena.

400 Bad Request

Sintomo: l’URL interessato restituisce 400 a una richiesta.

Causa probabile: destinazione della richiesta malformata o codificata male, problema di sintassi o framing Host/routing che l’applicazione o l’edge rifiutano subito (parametri query errati, caratteri non validi, routing imprevisto).

Correzione + controllo: confronta la richiesta esatta ricevuta dal server con quella che volevi generare; correggi l’URL e smetti di generare o collegare la versione difettosa. Ricontrolla con una richiesta GET, non solo con curl -I (HEAD), finché restituisce 200.

405 Method Not Allowed

Sintomo: l’URL restituisce 405 a certe richieste anche se la pagina sembra funzionare nel browser.

Causa probabile: il metodo HTTP usato non è consentito per quella route; spesso una regola del server o della CDN consente solo GET, mentre qualcuno invia HEAD o un altro metodo. Controlla l’header Allow per sapere che cosa è permesso e non presumere che un errore solo HEAD (come un semplice curl -I) dimostri che il GET fallisca allo stesso modo.

Correzione + controllo: abilita il metodo corretto per la route. Ripeti il test con HEAD e GET.

408 Request Timeout

Sintomo: l’URL restituisce occasionalmente 408, oppure la connessione resta sospesa prima di restituire uno stato.

Causa probabile: la connessione o la richiesta non è terminata entro la finestra di timeout del server, proxy o CDN; è un problema di tempi/connessione, non una prova di indisponibilità generale del server.

Correzione + controllo: correla i tempi di connessione e richiesta lungo la catena proxy/CDN/origine e il protocollo usato. Ripeti il test dopo aver corretto il percorso lento dell’origine o il timeout pertinente.

410 Gone

Sintomo: l’URL restituisce 410 e il conteggio “altro 4xx” include pagine che sei certo di aver eliminato intenzionalmente.

Causa probabile: rimozione intenzionale; funziona come previsto per pagine che devono scomparire. Se la pagina dovrebbe essere online, il 410 è un errore.

Correzione + controllo: se è intenzionale, rimuovilo da sitemap e link interni perché smetta di apparire come “problema”. Altrimenti ripristina la pagina.

411 Length Required

Sintomo: l’URL restituisce 411 a determinate richieste.

Causa probabile: il server pretende un header Content-Length su una richiesta che contiene un corpo, cosa insolita per un normale GET di pagina. Conferma nei log che la richiesta contenesse davvero dati prima di trattarlo come problema di crawl ordinario.

Correzione + controllo: conferma prima metodo e corpo reali; correggi o allenta il requisito lato server oppure fai sì che la richiesta includa l’header. Ripeti il test con lo stesso metodo e contenuto.

413 Payload Too Large

Sintomo: l’URL restituisce 413, di solito a richieste con corpo o header/cookie grandi.

Causa probabile: il contenuto della richiesta supera un limite impostato da server, CDN o WAF; riguarda la richiesta in ingresso, non la dimensione della risposta della pagina.

Correzione + controllo: conferma nei log la richiesta in ingresso prima di alzare un limite; correggi ciò che la genera oppure aumenta il limite solo se è davvero troppo restrittivo per una richiesta legittima. Ripeti il test e verifica che una richiesta di dimensione normale ora restituisca 200.

414 URI Too Long

Sintomo: l’URL restituisce 414, di solito per un URL generato o parametrizzato molto lungo.

Causa probabile: l’URI della richiesta supera un limite, spesso perché la generazione di parametri o la catena di redirect è sfuggita di mano, non per un problema del contenuto della pagina.

Correzione + controllo: correggi alla fonte la generazione dell’URL o dei redirect invece di alzare il limite alla cieca, e ripulisci sitemap e link interni che puntano al pattern troppo lungo.

415 / 422 (Unsupported Media Type / Unprocessable Entity)

Sintomo: l’URL restituisce 415 o 422 anche se la richiesta sembra ben formata nel browser.

Causa probabile: il server ha compreso la richiesta ma ha rifiutato il suo tipo di contenuto oppure una regola di validazione del contenuto/istruzioni; è insolito per un normale GET di pagina. Conferma il contenuto della richiesta reale prima di considerarlo un problema generico della pagina.

Correzione + controllo: conferma la richiesta nei log, poi correggi la regola di validazione o la gestione del tipo di contenuto, oppure ciò che genera la richiesta rifiutata. Ripeti il test finché la risposta è 200.

421 Misdirected Request

Sintomo: l’URL restituisce 421, a volte solo su HTTP/2.

Causa probabile: la connessione è stata indirizzata male; Google documenta però anche il 421 come modo intenzionale per escludere una route dal crawl HTTP/2, quindi non è automaticamente una pagina rotta.

Correzione + controllo: conferma se la richiesta è ricaduta su HTTP/1.1 e quale risposta finale ha ricevuto. Se è un’uscita HTTP/2 deliberata, non va corretta; se non esiste fallback e la pagina è irraggiungibile su ogni protocollo, correggi routing della connessione, SNI o gestione Host.

451 non disponibile per motivi legali

Sintomo: l’URL restituisce 451.

Causa probabile: blocco legale o di policy, che può essere intenzionale (per esempio contenuto limitato in determinate giurisdizioni); non trattarlo come una normale configurazione geo/WAF.

Correzione + controllo: coinvolgi chi possiede le decisioni legali o di policy per confermare che il blocco sia voluto. Se lo è, funziona come previsto: ripulisci sitemap e link che puntano all’URL. Se non lo è, rimuovi il blocco.

429 scambiato per “altro 4xx”

Sintomo: ti aspettavi un normale 4xx nel gruppo ma il codice reale è 429.

Causa probabile: il rate limiting sta scattando sulle richieste di Googlebot. Google tratta 429 come segnale di sovraccarico del server, non come errore client come gli altri codici del gruppo; è quindi plausibile che un 429 autentico venga segnalato come problema di crawl/server invece di restare “altro 4xx”. La documentazione descrive il comportamento di elaborazione, non la tassonomia del rapporto: considera non confermata la riga esatta.

Correzione + controllo: non disattivare il rate limiting legittimo; aggiungi un header Retry-After come buona pratica (facoltativo secondo RFC 6585; Google non conferma che Googlebot programmi il crawl dal valore). Se una regola restituisce 4xx solo per rallentare Googlebot, cambiala in 429 o 503.

Dimostra che la correzione ha funzionato davvero

Dopo aver corretto l’errore di richiesta/validazione, ripulito un 410 intenzionale, inserito in allowlist il Googlebot verificato o confermato che il rate limit sia gestito correttamente, questi controlli separano “la configurazione è cambiata” da “Google ora riesce davvero a raggiungere la pagina”. Eseguili nell’ordine indicato.

Test 1 — Una richiesta nuova restituisce lo stato previsto

• Test da eseguire — esegui curl con una richiesta GET sull’URL interessato (lo stesso metodo usato da Google: curl -I da solo testa HEAD) oppure controllalo con HTTP Status Checker.
• Risultato atteso — per una pagina da indicizzare, la riga di stato è HTTP/1.1 200 OK. Per una pagina rimossa intenzionalmente, è corretto che resti 410: il test decisivo è il Test 3.
• Interpretazione del fallimento — lo stesso 4xx significa che la correzione non è stata applicata a quel percorso o stai testando URL/ambiente sbagliati. Un 4xx diverso (per esempio 400 diventato 403) significa che hai sostituito un blocco con un altro: controlla la regola WAF/CDN.
• Finestra di monitoraggio — immediata: il server risponde appena la modifica è live.
• Segnale di rollback — se allentare una regola di validazione o dimensione apre un comportamento non voluto, ripristina la regola e correggi la causa alla radice (per esempio correggi la richiesta invece di alzare il limite).

Test 2 — Google conferma di poter raggiungere la pagina

• Test da eseguire — esegui Ispezione URL → Testa URL pubblicato in Google Search Console sull’URL interessato.
• Risultato atteso — per una pagina da indicizzare, il Live Test riesce e mostra 200 senza un 4xx.
• Interpretazione del fallimento — se il Live Test continua a mostrare un 4xx dopo che il test curl anonimo passa, sospetta una regola limitata agli intervalli IP di Googlebot (problema di allowlist WAF/CDN), non un problema generale della richiesta.
• Finestra di monitoraggio — immediata o pochi minuti dopo la correzione.
• Segnale di rollback — N/A: è un test in sola lettura. Se fallisce ancora, torna al ramo di fallimento del Test 1 invece di eseguire un rollback.

Test 3 — Lo stato scompare o resta intenzionalmente piatto nel rapporto Indicizzazione delle pagine

• Test da eseguire — usa Convalida correzione sulla riga “Bloccato per altro problema 4xx” e osserva il conteggio nelle settimane successive (vedi la scheda Come misurare).
• Risultato atteso — gli URL corretti diventano idonei a uscire dal gruppo dopo che Google ripete il crawl del 200: non è una garanzia di reindicizzazione o di tempi, solo idoneità. Gli URL con 410 intenzionale restano nel gruppo, ma sitemap e link interni non li indicano più.
• Interpretazione del fallimento — non esiste una cadenza di retry pubblicata: una validazione lenta non è una nuova failure. Se dopo un paio di settimane il conteggio degli URL effettivamente corretti non scende, ripeti il Test 1 per confermare che la correzione sia ancora presente (redeploy o cache CDN possono reintrodurre la vecchia regola senza farsi notare).
• Finestra di monitoraggio — da giorni a qualche settimana, seguendo il conteggio del gruppo.
• Segnale di rollback — torna alla correzione sottostante solo se il Test 1 ricomincia a fallire: non inseguire i tempi del rapporto.

Cronologia modifiche