Bloccata per richiesta non autorizzata (401): pagine dietro un login
Ultimo aggiornamento: 2026-10-30
Questo stato significa che il server ha risposto a Googlebot con 401 Unauthorized, chiedendo credenziali che Googlebot non ha. Se la pagina è privata, è corretto e resta fuori da Google. Se dovrebbe essere pubblica, rimuovi il requisito di autorizzazione o, se devi mantenerlo, lascia passare le richieste verificate di Googlebot.
Etichetta esatta in Search Console: Blocked due to unauthorized request (401)
Cosa significa
La guida di Google sull’indicizzazione delle pagine dice che la pagina è stata bloccata a Googlebot da una richiesta di autorizzazione (una risposta 401). Se vuoi che Googlebot indicizzi la pagina, rimuovi il requisito di autorizzazione oppure consenti a Googlebot di accedervi verificandone l’identità. Google suggerisce di controllare la pagina in una finestra di navigazione anonima per vedere cosa riceve un visitatore non autenticato.
Google non usa il contenuto degli URL che restituiscono codici 4xx e non li indicizza, e le pagine che erano indicizzate e iniziano a restituire 401 vengono rimosse col tempo. Google dice anche di non usare 401 o 403 per limitare la scansione, perché questi codici non hanno effetto sulla frequenza di scansione.
È un problema?
No per aree private come pagine account, schermate di amministrazione, intranet o siti di staging protetti da autenticazione HTTP; tenerle fuori da Google è lo scopo. È un problema quando pagine pubbliche restituiscono 401, per esempio quando la protezione con password dello staging resta attiva dopo il lancio, o quando un’intera sezione finisce dietro un login per errore.
Cause comuni
Pagine private collegate pubblicamente
URL di account, amministrazione o area riservata che Google ha scoperto tramite link. È previsto.
Protezione di staging rimasta attiva
Autenticazione HTTP basic o password di hosting ancora attive dopo la messa online del sito.
Regole di autenticazione su intere sezioni
Una regola di server o CDN che richiede il login per un modello di percorso che copre anche pagine pubbliche.
Pagine collegate a un’API autenticata
Pagine che restituiscono 401 alle richieste non autenticate invece di mostrare una versione pubblica.
Come risolverlo
- Controlla cosa riceve un visitatore non autenticato. Apri l’URL in una finestra anonima, come suggerisce Google. Se ti viene chiesto di accedere, succede lo stesso a Googlebot.
- Rimuovi l’autenticazione dalle pagine pubbliche. Disattiva la protezione con password per il sito live, o restringi la regola di autenticazione perché copra solo i percorsi privati.
- Consenti solo Googlebot verificato, se devi. Se il contenuto deve restare riservato alle persone ma visibile a Google, verifica Googlebot con reverse DNS o con gli intervalli IP pubblicati da Google prima di farlo passare, e leggi prima le norme antispam di Google su cloaking e paywall.
- Tieni private le pagine private. Per gli URL che non dovrebbero mai stare in Google, un 401 va bene. Rimuovi i link dalle pagine pubbliche e dalla sitemap così smettono di comparire.
- Testa, chiedi l’indicizzazione e verifica. Esegui Test URL live sulle pagine che hai aperto, chiedi l’indicizzazione per le più importanti e clicca Verifica correzione per il gruppo.
Verificalo con GSC Magic
gsc_inspect_urls_batch mostra lo stato di recupero della pagina registrato da Google per ogni URL, così il tuo assistente può elencare ogni URL bloccato con 401 e separare per directory i percorsi privati da quelli pubblici. report_index_health segnala ogni 401 nella tua sitemap, che dovrebbe elencare solo pagine pubbliche.
Prompt da copiare
Controlla questi URL ed elenca ogni caso bloccato per richiesta non autorizzata (401), raggruppato per directory.
Esegui un controllo di salute dell’indice sulla mia sitemap e dimmi se qualche URL elencato restituisce 401 o 403 a Google.
Abbiamo appena rimosso il login da queste pagine. Controllale e dimmi quali Google riporta ancora come bloccate da 401.
Guide sul blog
Stati correlati
Blocked due to access forbidden (403) Questo stato significa che il tuo server ha restituito 403 Forbidden a Googlebot. Google sottolinea che Googlebot non invia mai credenziali, quindi un 403 a Googlebot di solito viene restituito per errore. Se la pagina deve stare in Google, trova la regola di firewall, CDN o server che la blocca e consenti Googlebot verificato.
Blocked due to other 4xx issue Questo stato significa che Googlebot ha ricevuto un errore client 4xx che non è uno dei codici con una riga propria, come 401, 403 o 404. Google non dà altri dettagli, quindi il primo passo è trovare il codice esatto restituito dal tuo server. Poi correggi il modo in cui il server gestisce la richiesta per le pagine che dovrebbero essere pubbliche.
Excluded by 'noindex' tag Questo stato significa che Google ha scansionato la pagina, ha trovato una regola noindex in un robots meta tag o in un header HTTP X-Robots-Tag, e quindi non l’ha indicizzata. Se non vuoi la pagina in Google, funziona così. Se la vuoi, rimuovi il noindex alla fonte, conferma con Test URL live e chiedi l’indicizzazione.
Domande frequenti
Un 401 è un buon modo per tenere le pagine fuori da Google?
Per contenuti privati, sì. Le indicazioni di Google sulla rimozione elencano la protezione con password tra i modi per tenere una pagina fuori dai risultati di ricerca in modo permanente.
Posso dare a Googlebot un nome utente e una password?
No. Googlebot non effettua il login. Le indicazioni di Google sono di rimuovere il requisito di autorizzazione o consentire le richieste verificate di Googlebot.
Qual è la differenza tra 401 e 403 qui?
Un 401 chiede credenziali. Google dice che un 403 significa che le credenziali sono state fornite ma l’accesso è stato negato, e poiché Googlebot non invia mai credenziali, un 403 a Googlebot di solito viene restituito per errore.
Fonti
- support.google.com https://support.google.com/webmasters/answer/7440203
- developers.google.com https://developers.google.com/crawling/docs/troubleshooting/http-status-codes
- developers.google.com https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests
- developers.google.com https://developers.google.com/search/docs/crawling-indexing/remove-information
- developers.google.com https://developers.google.com/search/docs/essentials/spam-policies