Lingue

Bloccato per richiesta non autorizzata (401)

Che cosa significa lo stato "Bloccato per richiesta non autorizzata (401)" nel rapporto Indicizzazione delle pagine di Google Search Console, in che cosa differisce dal 403 secondo RFC 9110, quali sono le cause comuni, come diagnosticarlo come bot e qual è la correzione giusta in base al tipo di pagina: pubblica, privata, falso positivo WAF o con paywall.

Prima pubblicazione: 23 giu 2026 · Ultimo aggiornamento: 11 ago 2026 · Advanced
Lingue
AIScritto daAI v2
2 segnali di evidenza in questa pagina

"Bloccato per richiesta non autorizzata (401)" è uno stato di Indicizzazione delle pagine in Google Search Console: Googlebot ha ricevuto un HTTP 401 (autenticazione richiesta) quando ha provato a eseguire il crawl dell’URL. Google non fornisce mai credenziali, quindi non può vedere la pagina: non verrà indicizzata e un URL già indicizzato che restituisce 401 viene infine rimosso. Secondo RFC 9110, 401 significa che la richiesta non contiene credenziali valide (non ne sono state inviate oppure quelle inviate sono state rifiutate); 403 significa che il server ha compreso la richiesta e l’ha rifiutata, per ragioni che non riguardano necessariamente le credenziali. Google tratta allo stesso modo tutti i 4xx tranne 429 per l’indicizzazione, quindi l’esito coincide, ma causa e correzione dipendono dal tipo reale di pagina: rimuovi l’autenticazione da una pagina pubblica bloccata per errore; fai passare Googlebot verificato tramite IP/DNS inverso (non tramite uno user-agent falsificabile) se una pagina pubblica è bloccata per errore dalla sicurezza dei bot; mantieni l’autenticazione sui contenuti davvero privati o di staging invece di aprirli per cancellare il rapporto; usa i dati strutturati per contenuti con paywall di Google invece di un 401 generalizzato sui contenuti in abbonamento indicizzabili. "Loads fine in my browser" ("Nel mio browser si carica") è una trappola: tu sei autenticato, Googlebot no. Non usare 401/403 per limitare il crawl. Diagnostica con Live Test dell’Ispezione URL e curl -I (l’assenza dell’header WWW-Authenticate significa che la risposta è malformata, non dimostra che l’abbia generata un WAF). Live Test e Convalida correzione confermano l’accesso, non l’indicizzazione: non esiste una cadenza di retry pubblicata.

TL;DR — “Bloccato per richiesta non autorizzata (401)” significa che Googlebot ha ricevuto un 401 (Unauthorized) HTTP — una barriera di autenticazione che non può superare. Google non fornisce mai credenziali, quindi il contenuto non viene visto: la pagina non sarà indicizzata e un URL già indicizzato che restituisce 401 viene rimosso nel tempo. 401 e 403, con precisione (RFC 9110): 401 = la richiesta non contiene credenziali valide (non ne sono state inviate oppure quelle inviate sono state rifiutate); 403 = il server ha compreso la richiesta e l’ha rifiutata, per ragioni che non riguardano sempre le credenziali. Google tratta allo stesso modo tutti i 4xx tranne 429 per l’indicizzazione, quindi l’esito converge, ma causa e correzione sono diverse e la correzione dipende dal tipo reale di pagina: rimuovi l’autenticazione da una pagina pubblica bloccata per errore; fai passare Googlebot verificato tramite IP/DNS inverso (mai tramite uno user-agent falsificabile) su una pagina pubblica bloccata dalla sicurezza dei bot; mantieni l’autenticazione sui contenuti davvero privati o di staging; usa i dati strutturati per contenuti con paywall di Google, non un 401 generalizzato, sui contenuti in abbonamento indicizzabili. “Nel mio browser si carica” è una trappola: tu sei autenticato, Googlebot no. Non usare 401/403 per limitare il crawl. Diagnostica come bot (Live Test dell’Ispezione URL, curl -I) — l’assenza dell’header WWW-Authenticate significa che la risposta è malformata, non che l’abbia causata un WAF. Live Test e Convalida correzione confermano l’accesso, non l’indicizzazione, e non esiste una cadenza di retry pubblicata.

Che cosa ti sta dicendo davvero Google

L’etichetta Indicizzazione delle pagine riporta la risposta osservata da Google; non identifica quale regola di autenticazione, CDN o applicazione l’abbia prodotta. Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: Page indexing report Il comportamento di indicizzazione sottostante deriva dalla gestione documentata da Google delle risposte 4xx. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: HTTP status codes

Lo stato viene direttamente dal codice di risposta del server. Googlebot ha richiesto l’URL e ha ricevuto un HTTP 401, lo stato “Unauthorized”: la pagina è dietro una barriera di autenticazione (HTTP Basic Auth, una schermata di accesso o una regola di controllo degli accessi). La definizione di Google nel rapporto Indicizzazione delle pagine dice che Googlebot è stato bloccato da una richiesta di autorizzazione e che, se vuoi indicizzare la pagina, devi rimuovere il requisito di autorizzazione oppure far passare Googlebot verificandone l’identità.

Nel mio articolo Codici di stato HTTP e loro impatto sulla SEO descrivo un 401 come il caso in cui il client non si è identificato o verificato quando necessario: è un modello mentale utile, ma non la definizione completa del protocollo. La regola precisa di RFC 9110 è che un 401 indica che la richiesta non contiene credenziali di autenticazione valide per la risorsa; può anche seguire credenziali che il server rifiuta. Quindi un 401 non significa sempre che Googlebot (o un browser) non abbia inviato proprio nulla: significa che ciò che è stato presentato non era valido. In ogni caso, l’esito pratico per Googlebot è lo stesso: non ha credenziali da offrire e non supera mai la barriera.

Che cosa fa Google con un 401

Nulla di buono, se volevi che la pagina fosse indicizzata. La documentazione di Google sui codici di stato HTTP dice esplicitamente che tutti gli errori 4xx tranne 429 vengono trattati allo stesso modo: i crawler informano il sistema di elaborazione successivo che il contenuto non esiste. Di fatto, un 401 dice a Google “qui non c’è nulla”. Le conseguenze:

  • La pagina non verrà indicizzata. Google non ha mai visto il contenuto, quindi non c’è nulla da indicizzare.
  • Una pagina già indicizzata viene rimossa. Non è una caratteristica esclusiva del 401: è il comportamento della famiglia 4xx. Come scrivo nell’articolo Ahrefs sui codici di stato HTTP, i 4xx fanno uscire le pagine dall’indice. Un 401 che compare su una pagina già indicizzata da Google, dopo crawl ripetuti, farà uscire quell’URL dai risultati.
  • Non limita il crawl. Google dice chiaramente di non usare i codici di stato 401 e 403 per limitare la velocità di crawl. I 4xx (tranne 429) non hanno effetto sulla velocità di crawl, quindi non puoi usare un 401 come leva “rallenta”: per quello esistono 503 e 429.

Non ti darò una cadenza di retry specifica. Google ripete il crawl nel tempo, ma la documentazione non pubblica un calendario garantito del tipo “Googlebot riprova un 401 ogni N giorni”, quindi non fingerò che esista. Considera il nuovo crawl come “tornerà a controllare, prima o poi”, non come un cronometro.

401 vs 403 vs gli altri 4xx: la distinzione che conta

È la distinzione che la maggior parte degli articoli sfuma, e qui sta il valore reale. Per l’indicizzazione Google tratta 401 e 403 allo stesso modo (la regola 4xx tranne 429). Ma causa e correzione sono diverse perché i codici significano cose diverse:

  • 401 Unauthorized, secondo la definizione di RFC 9110: la richiesta non contiene credenziali di autenticazione valide per la risorsa richiesta. Comprende due casi: non sono state inviate credenziali oppure sono state inviate e il server le ha rifiutate. Una risposta 401 conforme deve contenere un header WWW-Authenticate con almeno una challenge. La mia versione compatta — “il client non si è identificato o verificato quando necessario” — è una scorciatoia utile per il caso comune, ma trattala come un modello mentale, non come la regola esaustiva.
  • 403 Forbidden, secondo la stessa RFC: il server ha compreso la richiesta ma rifiuta di soddisfarla. Le credenziali sono una possibile ragione, ma la specifica dice esplicitamente che una richiesta “può essere vietata per ragioni non legate alle credenziali”. Quindi 403 non significa sempre “il client è noto/autenticato ma non ha i diritti”: è uno schema comune nel mondo reale, non una garanzia. Nel rapporto Indicizzazione delle pagine di Google, un 403 verso Googlebot (che non invia mai credenziali) di solito significa che il server restituisce l’errore per errore, spesso a causa di un firewall, WAF o regola per bot configurata male. Per questo esiste lo stato gemello Bloccato per accesso vietato (403), con un flusso diagnostico molto simile.

La scorciatoia mentale pratica resta utile per il triage: 401 ≈ “una barriera di autenticazione che ho dimenticato di rimuovere” (sito di staging, autenticazione HTTP rimasta attiva), mentre 403 ≈ “una regola di sicurezza che blocca Googlebot per errore”. L’esito sull’indicizzazione è uguale, ma la causa principale è diversa: non trattare nessuna delle due scorciatoie come il confine effettivo del protocollo. La tabella decisionale è nella scheda Cheat Sheets.

Perché lo vedi: le cause comuni

Su una pagina che vuoi davvero indicizzare, un 401 è quasi sempre una di queste cose:

  • Un sito di staging o sviluppo dietro Basic Auth. Hai protetto con una password l’ambiente di staging (scelta corretta), ma Google ha scoperto l’URL in qualche modo: un link interno, una sitemap o un riferimento fuoriuscito. Ora segnala il 401. Se l’URL di staging non dovrebbe essere pubblico, è previsto (vedi la sezione sul 401 intenzionale).
  • Autenticazione HTTP rimasta per errore su una sezione pubblica. Una regola .htpasswd, un plugin “coming soon” o una barriera di manutenzione lasciata attiva su una directory che dovrebbe essere online.
  • Un WAF, una CDN o un’allowlist IP che blocca Googlebot. È il caso subdolo. Cloudflare, Akamai, Sucuri o un’allowlist geografica/IP restituiscono 401 (o 403) agli IP di Googlebot mentre servono normalmente le persone. La pagina “funziona per tutti” perché tutti quelli che la provano arrivano da un IP consentito.
  • Una barriera di accesso su contenuti in abbonamento o con paywall che vuoi davvero indicizzare. Un 401 generalizzato tiene completamente fuori Googlebot: la correzione non è indebolire la barriera, ma usare i dati strutturati per i contenuti con paywall supportati da Google (vedi il quarto ramo più avanti).

Come diagnosticarlo: prova come un bot, non come un browser

La trappola più grande è “da me funziona”. Certo che funziona: sei autenticato, il tuo IP è in allowlist o il browser ha un cookie di sessione. Googlebot non ha nulla di tutto questo. Quindi fai la diagnosi come un bot:

  • Ispezione URL → Live Test (GSC). È il modo più vicino per vedere la risposta reale ricevuta da Googlebot. Eseguilo sull’URL interessato: se non riesce a recuperarlo a causa dell’autorizzazione, hai confermato che il 401 è reale e riproducibile.

  • curl -I da un contesto non autenticato. Richiedi l’URL senza cookie e senza credenziali e leggi la riga di stato:

    curl -I https://www.example.com/page/
# Look for:  HTTP/1.1 401 Unauthorized
# and a WWW-Authenticate: header confirming an auth gate

Se curl (che non invia sessione né autenticazione) riceve 401 mentre il browser riceve 200, quella differenza è il bug: il browser è autenticato e Googlebot no. RFC 9110 richiede che un 401 conforme contenga l’header WWW-Authenticate: la sua presenza conferma una vera challenge di autenticazione. La sua assenza però non risolve il caso: indica che la risposta è malformata o incompleta, non quale livello l’abbia generata. Non concludere subito “dev’essere il WAF” solo per l’header mancante.

  • Controlla se è limitato all’IP. Se curl dalla tua macchina restituisce 200 ma il Live Test di GSC fallisce, è un segnale concreto che qualcosa dipenda dall’IP sorgente o dall’instradamento della richiesta. Confermalo confrontando i log dell’edge/CDN, dell’origine, dell’applicazione e dell’identity provider prima di attribuire la causa al WAF. Una richiesta HEAD (quella inviata da curl -I) può anche essere instradata o memorizzata in cache diversamente da una GET: verifica anche con una GET anonima.

Come correggerlo: quattro rami in base a ciò che la pagina è davvero

Non esiste una sola correzione: ce ne sono quattro, e scegliere quella sbagliata espone contenuti che volevi proteggere oppure lascia una pagina indicizzabile bloccata per sempre. Classifica l’URL in uno di questi casi prima di modificare la configurazione:

1. Contenuto davvero privato o di staging → mantieni l’autenticazione, non toccarla. Se l’URL non dovrebbe essere pubblico, il 401 funziona come previsto: l’autenticazione lato server è un modo legittimo e raccomandato da Google per tenere il contenuto lontano da tutti, Googlebot compreso. John Mueller ha spiegato questo punto per i siti di staging: per nascondere un sito bisogna usare l’autenticazione lato server, per IP, cookie o normale autenticazione server, così gli utenti normali — e quindi anche Googlebot — non possono vedere il contenuto. Non autorizzare Googlebot attraverso una barriera che protegge contenuti davvero privati solo per cancellare questa riga del rapporto: vanificheresti lo scopo della barriera. Qui la correzione riguarda la scoperta, non l’accesso: conferma che l’URL non sia collegato, incluso in sitemap o inviato a questa proprietà Search Console, e lascia attiva l’autenticazione.

2. Pagina pubblica bloccata per errore → rimuovi il requisito di autorizzazione. Se la pagina dovrebbe essere indicizzata e la barriera è rimasta attiva — Basic Auth, schermata di accesso o plugin di manutenzione — disattivala per quel percorso. È il caso semplice: appena una richiesta anonima riceve 200, la pagina è aperta a Googlebot.

3. Pagina pubblica bloccata per errore dalla sicurezza dei bot → ammetti Googlebot verificato, non la stringa user-agent. Quando WAF, CDN o allowlist IP respingono Googlebot su una pagina che vuoi davvero rendere pubblica, inserisci in allowlist Googlebot verificato tramite IP/DNS inverso. Lo user-agent è facilissimo da falsificare: chiunque può dichiararsi Googlebot. Il percorso raccomandato da Google è verificare il crawler tramite gli intervalli IP pubblicati o un controllo DNS inverso seguito da DNS diretto, poi far passare dalla barriera solo quelle richieste specifiche: non rimuovi la regola di sicurezza, ma ne crei un’eccezione verificata. Per correggere il falso positivo:

  • Identifica la regola che restituisce 401/403 a Googlebot (eventi Firewall di Cloudflare, log Akamai/Sucuri o log del tuo edge, dell’origine o dell’applicazione).
  • Inserisci in allowlist gli intervalli IP verificati di Google (o la categoria del bot) invece di disattivare tutta la protezione.
  • Ripeti il test con Live Test dell’Ispezione URL finché Google riesce a recuperare la pagina.

4. Contenuti in abbonamento o con paywall che vuoi indicizzare → non usare affatto un 401 generalizzato. Se la pagina è protetta da registrazione o abbonamento ma vuoi che sia scoperta nella Ricerca, un 401 rigido è lo strumento sbagliato qualunque sia la causa: Googlebot non può comunque recuperarla. Google documenta invece un’implementazione supportata del paywall: servi la pagina con i dati strutturati appropriati per i contenuti a pagamento (isAccessibleForFree, hasPart e proprietà correlate), così Google può indicizzare la parte di anteprima gratuita senza che tu debba aprire l’intera pagina. È una modifica ai markup e alla risposta del server, non alla barriera di autenticazione.

Valida la correzione e fissa le aspettative

Dopo aver aperto davvero la pagina (e aver confermato con curl/Live Test che una richiesta non autenticata restituisce 200), sii preciso su ciò che ogni passaggio conferma:

  • Live Test conferma l’accesso, non l’indicizzazione. La documentazione di Google sull’Ispezione URL dice che il test live conferma soltanto se Google-InspectionTool riesce attualmente ad accedere e analizzare la pagina: non esiste un test che garantisca che la pagina finirà nell’indice o apparirà nei risultati. Un Live Test superato significa che la barriera è aperta, non che il seguito sia garantito.
  • Convalida correzione è facoltativa, non obbligatoria. Google aggiorna il conteggio del problema quando esegue di nuovo il crawl di una pagina, indipendentemente dal fatto che tu abbia fatto clic su Convalida correzione. Usala per il tuo monitoraggio su una correzione reale: non validare un URL che dovrebbe restare privato e non considerare la convalida un acceleratore della reindicizzazione.
  • Non aspettarti una reindicizzazione immediata. Nuovo crawl e nuova indicizzazione richiedono tempo e, come detto sopra, non esiste una cadenza di retry pubblicata da citare. Monitora separatamente il risultato realmente indicizzato e il rendimento nella Ricerca: né Live Test né Convalida correzione garantiscono la selezione canonical o la comparsa nei risultati.
  • Un mito da abbandonare: un 401 in GSC non è una penalizzazione né un’azione manuale. È uno stato di accesso al crawl. Non danneggia il ranking delle altre pagine e non mette il sito in una “blacklist”: mantiene semplicemente la pagina protetta fuori dall’indice.

Dove si colloca

Questo è uno degli stati dei codici HTTP nel rapporto Indicizzazione delle pagine. I casi gemelli includono Bloccato per accesso vietato (403), gli altri stati 4xx e 404 e lo stato di errore server 5xx. Per il rapporto e per capire la tabella “Perché le pagine non sono indicizzate”, consulta l’hub del rapporto Indicizzazione delle pagine. I meccanismi sottostanti — come Googlebot recupera le pagine e che cosa significano per lui i codici di stato — sono trattati nelle sezioni crawling e indicizzazione.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.