401 Unauthorized: guida all’autenticazione HTTP

TL;DR — Un 401 Unauthorized significa che il server vuole che tu effettui l’accesso prima di consegnarti la pagina: le credenziali mancano, sono errate o sono scadute. I motori di ricerca non effettuano mai l’accesso, quindi se una pagina restituisce 401 a Googlebot Google non può vederla e non la inserisce nei risultati. È esattamente ciò che vuoi per le pagine private (staging, aree riservate ai membri) e un problema solo quando succede a una pagina che vuoi davvero far trovare.

Che cosa significa 401

Quando il browser (o il crawler di un motore di ricerca) chiede una pagina al server, il server risponde con un codice di stato. 401 Unauthorized è il modo con cui il server dice: “non ti mostrerò questa pagina finché non dimostri chi sei”. Le credenziali inviate mancavano, non erano valide o erano scadute: devi effettuare l’accesso. Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.2 — 401 Unauthorized

Lo hai visto ogni volta che una pagina mostrava una casella per nome utente e password o ti portava a una schermata di login. Dietro le quinte, spesso si tratta di un 401.

Perché conta per la SEO

Ecco il punto: Googlebot e Bingbot non effettuano mai l’accesso. Non hanno nome utente e password per il tuo sito e non compilano caselle di login. Quando un crawler incontra un 401, quindi, non può superare il cancello. Per Google il contenuto di quella pagina, di fatto, non esiste.

Il risultato pratico:

• Una pagina che restituisce 401 non verrà indicizzata: non può comparire nella ricerca.
• Una pagina che prima si posizionava ma ora restituisce 401 uscirà dall’indice nel tempo. Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the Search indexing outcome for 401 responses; it does not address access decisions for private users. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Quando un 401 va bene (e quando è un problema)

Un 401 non è automaticamente un bug da correggere. È la risposta giusta per le pagine che devono essere private:

• 401 corretto: sito di staging, area riservata ai membri, strumento amministrativo interno o portale clienti. Vuoi che restino nascosti a Google e un login wall svolge il lavoro.
• 401 errato: articolo del blog, pagina prodotto o landing page che dovrebbe essere pubblica ma all’improvviso chiede il login, di solito a causa di un firewall configurato male, di una protezione con password rimasta attiva, di un token scaduto o di un conflitto tra plugin.

Il falso allarme più comune è “ma da me si carica!”: sei autenticato, mentre il crawler non lo è. Per vedere ciò che vede Googlebot, apri la pagina in una finestra privata/in incognito o usa lo strumento URL Inspection di Google Search Console.

401 vs 403: versione rapida

Vedrai spesso 401 accanto a 403 Forbidden. Sembrano simili ma significano cose diverse:

• 401 = “Chi sei?” Mancano le credenziali: effettua l’accesso.
• 403 = “So chi sei e no”. Il server ha capito la richiesta ma rifiuta comunque l’accesso.

Per Google, però, il risultato è lo stesso: nessuno dei due viene indicizzato, perché in entrambi i casi il crawler non riesce a raggiungere il contenuto.

Vuoi i dettagli tecnici, l’header esatto che un 401 deve inviare, ciò che dicono davvero i documenti Google e come correggere un 401 indesiderato? Passa alla scheda Advanced.

TL;DR — 401 Unauthorized è un errore client (RFC 9110 §15.5.2, che ha sostituito RFC 7235) e significa che la richiesta non contiene credenziali di autenticazione valide, comprese credenziali inviate ma rifiutate, non solo credenziali mai inviate; un 401 conforme invia anche un header WWW-Authenticate che indica lo schema atteso. È diverso da 403, un rifiuto che non richiede quella challenge e può non avere alcun rapporto con le credenziali, ma Google tratta tutti i 4xx tranne 429 allo stesso modo per l’indicizzazione: il contenuto “non esiste”, quindi non viene indicizzato e gli URL indicizzati in precedenza scompaiono nel tempo. Poiché il normale Googlebot non invia mai credenziali, un 403 a Googlebot è, secondo le parole di Google, di solito una configurazione errata del server. 401/403 non hanno effetto sul crawl rate complessivo del sito (un mito ripetuto spesso), anche se un singolo URL che continua a restituire 4xx viene riesplorato meno spesso nel tempo. Un 401 è il modo corretto e approvato da Google per proteggere contenuti davvero privati; è un problema solo quando colpisce una pagina che vuoi indicizzare. Per i contenuti a pagamento esiste una strada autorizzata che non consiste in un 401 generalizzato.

Che cos’è davvero un 401

401 Unauthorized è una risposta di errore del client. La definizione di MDN è la formulazione tecnica più chiara:

“The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource. This status code is sent with an HTTP WWW-Authenticate response header that contains information on the authentication scheme the server expects the client to include to make the request successfully.” (traduzione) «Il codice di stato di errore client HTTP 401 indica che una richiesta non ha avuto successo perché non contiene credenziali di autenticazione valide per la risorsa richiesta. Questo codice viene inviato con un header di risposta HTTP WWW-Authenticate che contiene informazioni sullo schema di autenticazione che il server si aspetta che il client includa per completare correttamente la richiesta.»

Da qui vale la pena ricavare due cose. Primo, “authentication”: chi effettua la richiesta non ha dimostrato chi è. Di solito significa credenziali mancanti, non valide o scadute, ma un 401 può anche seguire credenziali inviate e rifiutate; non presumere che non ci sia affatto un header di autenticazione senza controllare la richiesta. Secondo, un 401 conforme alla specifica deve contenere un header WWW-Authenticate: secondo RFC 9110 §15.5.2, che ha sostituito il precedente RFC 7235, comunica al client quale schema o quali schemi si aspetta (HTTP Basic Auth, un token Bearer, un flusso con cookie di sessione e così via). Se stai facendo il debug di un 401, quello è il primo header da controllare: se esiste e quale schema nomina. Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.2 — 401 Unauthorized

Nella mia guida ai codici di stato riassumo il 401 così: “the client hasn’t identified or verified itself when needed” (traduzione) «il client non si è identificato o verificato quando era necessario.» È tutta l’idea: nessuno ha ancora dichiarato chi è.

401 vs 403 Forbidden: la distinzione che conta

È qui che la maggior parte delle persone diventa vaga, quindi rendiamola netta. In una riga:

• 401 = “Chi sei?”: le credenziali sono mancanti o non valide; autentica il client e riprova.
• 403 = “So chi sei, ma no”. La richiesta è stata capita, ma l’accesso è negato indipendentemente dalle credenziali.

MDN la descrive allo stesso modo:

“A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.” (traduzione) «Un 401 Unauthorized è simile alla risposta 403 Forbidden, salvo che un 403 viene restituito quando una richiesta contiene credenziali valide ma il client non ha i permessi per eseguire una determinata azione.»

Nella mia guida traccio la stessa differenza: 401 è “the client hasn’t identified or verified itself when needed” (traduzione) «il client non si è identificato o verificato quando era necessario», mentre 403 è “the client is known but doesn’t have access rights” (traduzione) «il client è noto ma non ha i diritti di accesso». Autenticazione contro autorizzazione.

Questa frase è una scorciatoia affidabile, ma se devi scegliere tra i due codici nel codice o in una regola WAF esiste un test di protocollo più preciso: 401 richiede la challenge WWW-Authenticate, perché RFC 9110 la rende obbligatoria; 403 non la richiede, poiché un rifiuto 403 può dipendere da ragioni del tutto estranee alle credenziali (blocco IP, regola di permessi, criterio di rate limit). Quindi “erano presenti le credenziali?” da solo non basta per distinguerli: un 401 può seguire credenziali rifiutate, non solo mancanti. Se devi decidere quale codice restituire, chiediti invece: sto emettendo una challenge di autenticazione (401) o un rifiuto netto (403)?

Ecco la sfumatura SEO non ovvia, ed è il punto di Google sul 403. Il normale Googlebot non invia mai credenziali. Quindi un 403 servito specificamente a Googlebot significa, secondo le parole di Google, che il server sta sbagliando:

“HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.” (traduzione) «HTTP 403 significa che lo user agent ha fornito credenziali, ma non ha ottenuto l’accesso. Tuttavia Googlebot non fornisce mai credenziali, quindi il server sta restituendo questo errore in modo errato. La pagina non verrà indicizzata.»

È un diagnostico utile. Un 401 a Googlebot può essere intenzionale (la pagina è protetta per scelta). Un 403 a Googlebot indica di solito una configurazione errata: Googlebot non ha inviato credenziali, quindi nulla dovrebbe attivare per lui una risposta “credenziali rifiutate”. Se vedi 403 sulle pagine che Googlebot dovrebbe raggiungere, sospetta prima CDN, WAF o configurazione del server. (Questo descrive i crawler comuni di Google. Google documenta crawler speciali e fetcher attivati dagli utenti come categorie separate, con comportamenti propri: non presumere che la regola “non invia mai credenziali” valga per ogni integrazione di prodotto Google senza controllare.)

L’ultima riga è la conclusione: per l’indicizzazione Google li tratta allo stesso modo.

Come tratta Google le pagine 401

Il documento di Google sui codici di stato HTTP è netto sulla famiglia 4xx:

“Google doesn’t use the content from URLs that return 4xx status codes. If a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time. In the case of Google Search, Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” (traduzione) «Google non usa il contenuto degli URL che restituiscono codici di stato 4xx. Se un URL era usato in precedenza ma ora restituisce un codice di stato 4xx, i sistemi Google smetteranno di usarlo nel tempo. In Google Search, Google non indicizza gli URL che restituiscono un codice di stato 4xx e gli URL già indicizzati che restituiscono un codice di stato 4xx vengono rimossi dall’indice.» Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the Search indexing outcome for 401 responses; it does not address access decisions for private users. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

E 401 non è un’eccezione all’interno di quella famiglia. Nella tabella del documento, 401 (unauthorized) e 403 (forbidden) sono righe separate che condividono una sola spiegazione:

“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, sono trattati allo stesso modo: i crawler Google informano il sistema di elaborazione successivo che il contenuto non esiste.»

Quindi l’esito è binario, non un declassamento. Una pagina che restituisce 401 non “si posiziona più in basso”: non viene indicizzata affatto o viene rimossa completamente se prima era indicizzata. Non esiste una penalizzazione parziale. Questo coincide con la tesi di base della mia guida: i 4xx fanno uscire le pagine dall’indice. Questo articolo è l’approfondimento specifico sui 401.

Una precisazione sui tempi: la rimozione avviene “nel tempo”, non al primo fetch errato. I documenti Google descrivono un processo graduale e il sistema di crawling è stato storicamente descritto come tollerante verso errori di breve durata prima di considerare un URL realmente scomparso.

Il mito del crawl rate: il 401 NON rallenta il crawling

Questo punto confonde molti articoli altrimenti validi, quindi voglio essere preciso. Un 401 (o 403) non rallenta il crawl rate di Google. Google lo dice direttamente:

“Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (traduzione) «Non usare i codici di stato 401 e 403 per limitare il crawl rate. I codici di stato 4xx, tranne 429, non hanno effetto sul crawl rate.»

È importante perché troverai consigli secondo cui proteggere pagine dietro un 401 “risparmia crawl budget” o “spreca crawl budget”: entrambe le formulazioni sono sbagliate. Solo 429 e segnali di tipo 5xx, come 503, dicono a Googlebot di rallentare. Un 401 non è un throttle: è un segnale di indicizzazione “il contenuto non esiste”, punto. Se vuoi davvero rallentare temporaneamente un crawl, usa 429/503, non 401/403.

Una precisazione sull’ambito, perché è facile confondere queste due affermazioni: “nessun effetto sul crawl rate” riguarda il crawl rate complessivo del sito. Separatamente, Google dice che un singolo URL che continua a restituire 4xx viene riesplorato meno spesso nel tempo: la frequenza dei tentativi diminuisce gradualmente. Sono ambiti diversi: il crawl budget del sito non viene limitato, ma un URL che continua specificamente a restituire 401 viene controllato meno spesso mentre Google ne riduce la priorità.

Esiste anche un caso speciale: un 401 su una pagina normale e un 401 sullo stesso /robots.txt non vengono trattati allo stesso modo. Se il file robots.txt restituisce un 4xx diverso da 429 (compreso 401), Google lo tratta come se non esistesse alcun robots.txt: presume che quel file non imponga restrizioni al crawl, non che l’intero sito sia irraggiungibile. Non mettere /robots.txt dietro lo stesso muro di autenticazione delle pagine private.

Un 401 è sempre un problema? No.

Un 401 è un bug solo quando è involontario su una pagina che vuoi pubblica. Se la pagina è davvero privata, un 401 è il modo corretto per tenerla fuori dalla ricerca ed è ciò che raccomanda Google. John Mueller lo ha detto chiaramente (riportato da Search Engine Journal): l’approccio ideale è un’autenticazione lato server che impedisca agli utenti normali di vedere il contenuto, “that would include GoogleBot” (traduzione) «e questo includerebbe GoogleBot». (Riportato da Search Engine Journal a partire da un hangout Google del 2019; trattalo come una dichiarazione del rappresentante accuratamente parafrasata, non come una citazione verificata per frammento.)

L’autenticazione lato server, che è ciò che produce un 401, è il meccanismo raccomandato per nascondere contenuti non pubblici, prima di robots.txt, proprio perché blocca davvero l’accesso invece di limitarsi a chiedere ai bot di non entrare.

Quindi il quadro decisionale è semplice:

• Deve restare 401: ambienti di staging, aree riservate ai membri, strumenti interni e qualsiasi contenuto realmente privato. Funziona come progettato. Non “correggerlo”.
• Va corretto: una pagina pubblica e indicizzabile che restituisce 401 per errore, per un falso positivo CDN/WAF, Basic Auth rimasto attivo, token scaduto o conflitto tra plugin/middleware.

Implicazioni SEO e la trappola “da me funziona”

I modi pratici in cui può fallire:

• Le pagine che vuoi indicizzare restano invisibili finché il cancello non viene rimosso.
• Le pagine che prima si posizionavano scompaiono se iniziano a restituire 401.
• La trappola “da me funziona”: chi esegue il test è autenticato, ha effettuato l’accesso o usa un IP in allowlist, mentre il crawler no. La guida di Google per il caso 401 dice: “You can verify this error by visiting the page in incognito mode.” (traduzione) «Puoi verificare questo errore visitando la pagina in modalità in incognito.» Meglio ancora, testa senza autenticazione con curl -I https://example.com/page oppure usa URL Inspection/Live Test di Search Console.

Quando devi davvero lasciar passare un crawler reale, verificalo tramite IP / reverse-DNS, mai affidandoti soltanto allo user-agent: gli user-agent sono facilissimi da falsificare, quindi inserire “Googlebot” in allowlist per nome è una falla di sicurezza, non una soluzione.

E i contenuti a pagamento o riservati agli abbonati?

Un 401 generalizzato a tutti, Googlebot compreso, non è l’unica opzione se vuoi che i contenuti protetti continuino a posizionarsi. Google supporta l’indicizzazione dei contenuti a pagamento tramite i dati strutturati isAccessibleForFree, insieme alla concessione dell’accesso alle identità crawler dedicate di Google per i contenuti riservati ad abbonati o utenti registrati. Il punto del markup è:

“This structured data helps Google differentiate paywalled content from the practice of cloaking, which violates spam policies.” (traduzione) «Questi dati strutturati aiutano Google a distinguere i contenuti a pagamento dalla pratica del cloaking, che viola le norme antispam.»

L’avvertenza incorporata è questa: servire silenziosamente il contenuto completo solo a Googlebot, senza dichiararlo nei dati strutturati, è cloaking, un rischio rispetto alle norme antispam. Se vuoi indicizzare contenuti protetti, usa il metodo approvato (markup + accesso al crawler), non un bypass silenzioso.

Come correggere un 401 indesiderato

1. Conferma che sia davvero indesiderato. La pagina dovrebbe essere pubblica? Se è staging o riservata ai membri, non c’è nulla da correggere.
2. Rimuovi il requisito di autenticazione dalle pagine pubbliche: elimina Basic Auth rimasto (.htaccess/nginx), correggi i token scaduti e risolvi i conflitti tra plugin/middleware.
3. Controlla CDN/WAF e non presumere di sapere già quale strato abbia emesso il 401. La risposta, insieme al suo header WWW-Authenticate, dimostra che è avvenuta una challenge; non dice da dove proviene: applicazione, proxy di identità/autenticazione, regole di gestione dei bot della CDN o del WAF e server d’origine possono generarla. I falsi positivi delle regole edge di bot management sono una causa comune: ispeziona i log a ogni livello e verifica Googlebot tramite reverse DNS prima di inserire eccezioni in allowlist.
4. Lascia passare i crawler verificati tramite IP/reverse-DNS, non tramite user-agent.
5. Non usare 401 per deindicizzare una pagina che potresti rendere pubblica: usa invece noindex (lasciando consentito il crawling). Un login wall serve a contenuti che devono essere realmente privati.
6. Valida la correzione con il Live Test di URL Inspection, ma considera il superamento una conferma del fetch attuale, non una garanzia. Google non si impegna su una tempistica fissa per ricrawl, reindicizzazione o recupero del ranking dopo la correzione di un 401: un Live Test riuscito dimostra che il fetch live di Google è passato, non che crawling programmato o indicizzazione siano aggiornati. Lascia passare tempo e ricontrolla il report Page Indexing invece di aspettarti un’inversione immediata.

Per il flusso completo di diagnosi, correzione e validazione in Google Search Console specifico dello stato Page Indexing “Blocked due to unauthorized request (401)”, consulta l’articolo compagno dedicato: questo pezzo resta al livello di protocollo e concetti.

Bing

Bing si comporta sostanzialmente allo stesso modo: un URL che restituisce 401 (o 403) a Bingbot è inaccessibile e non viene indicizzato. Bingbot ha bisogno di accesso non autenticato proprio come Googlebot e va verificato tramite gli intervalli IP pubblicati per l’allowlist, non tramite lo user-agent.

Riepilogo AI

Una sintesi della versione Advanced:

• 401 = credenziali mancanti, non valide o rifiutate (“chi sei?”). RFC 9110 §15.5.2, che ha sostituito RFC 7235, richiede un header WWW-Authenticate che nomini lo schema da usare; un 401 non dimostra che non siano state inviate credenziali, perché può seguire credenziali inviate e rifiutate.
• 401 vs 403, il test affidabile: 401 richiede la challenge WWW-Authenticate; 403 no, perché un rifiuto 403 può essere del tutto estraneo alle credenziali (blocco IP, regola di permessi, rate limit). Poiché il normale Googlebot non invia mai credenziali, un 403 a Googlebot è di solito, secondo Google, una configurazione errata del server. Google documenta separatamente altre identità di crawler/fetcher, quindi non generalizzare questa regola a ogni client Google.
• Esito dell’indicizzazione identico: Google tratta allo stesso modo tutti i 4xx tranne 429: il contenuto “non esiste”, quindi non viene indicizzato e gli URL già indicizzati scompaiono nel tempo. È un esito binario, non un declassamento.
• Nessun effetto sul crawl rate del sito, ma diminuisce la frequenza per singolo URL: 401/403 non limitano il crawl complessivo; lo fanno solo 429 e i segnali 5xx. Separatamente, un singolo URL che continua a restituire 4xx viene riesplorato meno spesso nel tempo. Inoltre un 401 sullo stesso /robots.txt viene trattato come “non esiste alcun robots.txt”, non come un blocco.
• Un 401 spesso è corretto: l’autenticazione lato server è il modo approvato da Google per nascondere pagine di staging, per membri o private. È un problema solo quando colpisce una pagina che vuoi indicizzare; inoltre la sola risposta non dice quale strato, app, proxy di identità, CDN/WAF o origine, l’abbia prodotta.
• Trappola “da me funziona”: tu sei autenticato, il crawler no. Testa in incognito, con curl -I o URL Inspection; un Live Test superato conferma solo il fetch corrente, non una tempistica garantita per ricrawl o recupero.
• Paywall: usa markup isAccessibleForFree + accesso al crawler, non un 401 generalizzato. Servire silenziosamente contenuto completo a Googlebot è cloaking.
• Correzione: rimuovi il requisito di autenticazione, verifica i crawler tramite IP/reverse-DNS (mai user-agent) e usa noindex, non 401, per deindicizzare una pagina che potresti rendere pubblica.

Documentazione ufficiale

Documentazione da fonti primarie di Google e dalla specifica HTTP.

Google

• Come i codici di stato HTTP, gli errori di rete e DNS influenzano Google Search — la gestione dei 4xx, la regola “treated the same” e l’avvertenza sul crawl rate per 401/403.
• Report sull’indicizzazione delle pagine — le definizioni degli stati “Blocked due to unauthorized request (401)” e “Blocked due to access forbidden (403)”.
• Dati strutturati per abbonamenti e contenuti a pagamento — isAccessibleForFree e l’alternativa approvata a un 401 generalizzato.
• Verifica di Googlebot e degli altri crawler Google — verifica tramite IP/reverse-DNS, non user-agent, prima di inserire eccezioni in allowlist.

Standard / riferimento

• RFC 9110 §15.5.2 — HTTP Semantics: 401 Unauthorized — la specifica attuale di 401 + WWW-Authenticate (sostituisce RFC 7235).
• MDN — 401 Unauthorized — definizione tecnica rivolta agli sviluppatori (secondaria, non specifica per la SEO).

Citazioni dalla fonte

Dichiarazioni pubbliche. Ogni link è un deep link che porta al passaggio citato nella pagina sorgente.

Google: come vengono gestiti i 4xx (compreso 401)

• “Google doesn’t use the content from URLs that return 4xx status codes… Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” (traduzione) «Google non usa il contenuto degli URL che restituiscono codici di stato 4xx… Google non indicizza gli URL che restituiscono un codice di stato 4xx e gli URL già indicizzati che restituiscono un codice di stato 4xx vengono rimossi dall’indice.» — Documenti Google Search Central. Vai alla citazione
• “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, sono trattati allo stesso modo: i crawler Google informano il sistema di elaborazione successivo che il contenuto non esiste.» Vai alla citazione
• «Non usare i codici 401 e 403 per rallentare la scansione: tra le risposte 4xx, solo 429 influisce sul crawl rate». (Resa italiana della citazione completa presente nella sezione Advanced.) Vai alla citazione

Google: assistenza Search Console, voci 401 e 403

• “The page was blocked to Googlebot by a request for authorization (401 response)… You can verify this error by visiting the page in incognito mode.” (traduzione) «La pagina è stata bloccata per Googlebot da una richiesta di autorizzazione (risposta 401)… Puoi verificare questo errore visitando la pagina in modalità in incognito.» — Guida di Google Search Console, report Page Indexing. Vai alla citazione
• «HTTP 403 indica che lo user agent ha presentato credenziali senza ottenere l’accesso. Poiché Googlebot non invia credenziali, questa risposta gli impedisce l’accesso e la pagina non viene indicizzata; il confronto con 401 resta quello descritto sopra». (Versione italiana della citazione già riportata nella sezione Advanced.) Vai alla citazione

Google: contenuti a pagamento

• “This structured data helps Google differentiate paywalled content from the practice of cloaking, which violates spam policies.” (traduzione) «Questi dati strutturati aiutano Google a distinguere i contenuti a pagamento dalla pratica del cloaking, che viola le norme antispam.» — Documenti Google Search Central. Vai alla citazione

MDN: la definizione tecnica

• “The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource.” (traduzione) «Il codice di stato di errore client HTTP 401 indica che una richiesta non ha avuto successo perché non contiene credenziali di autenticazione valide per la risorsa richiesta.» — MDN Web Docs (riferimento tecnico secondario, non specifico per la SEO). Vai alla citazione
• “A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.” (traduzione) «Un 401 Unauthorized è simile alla risposta 403 Forbidden, salvo che un 403 viene restituito quando una richiesta contiene credenziali valide, ma il client non ha i permessi per eseguire una determinata azione.» Vai alla citazione

John Mueller, Google (riportato da Search Engine Journal)

• Sulla protezione dei contenuti non pubblici: l’autenticazione lato server che impedisce agli utenti normali di vedere il contenuto, «e questo includerebbe GoogleBot», è l’approccio ideale. Secondo Search Engine Journal da un hangout Google del 2019; va considerata una parafrasi accurata della dichiarazione del rappresentante, non una citazione testuale verificata per frammento.

401 vs 403: quale sto vedendo davvero e devo correggerlo?

Le due domande reali dei lettori sono: è un 401 o un 403? e è un problema? Apri la sezione per scoprirlo.

Prompt: diagnostica un 401 indesiderato

Incolla gli header della risposta anonima di un URL interessato insieme alla configurazione pertinente di autenticazione, CDN o middleware. Rimuovi prima token, cookie e segreti.

Diagnose why this public URL returns HTTP 401 to an unauthenticated client. Check for
a valid WWW-Authenticate challenge, separate origin authentication from CDN/WAF and
application middleware, and distinguish an intentional private gate from a public-page
regression. Return: evidence, likely issuing layer, minimum safe fix, and exact
anonymous validation requests. Do not recommend user-agent-only bot allowlisting.

[PASTE SANITIZED HEADERS, LOG EVENT, AND CONFIG]

Prompt: esamina un’eccezione di autenticazione

Review this proposed crawler-access rule for a gated site. Identify whether it relies
only on a spoofable user-agent, whether crawler identity is verified by published IP
ranges or reverse-and-forward DNS, and whether serving different content would create
a cloaking risk. Give a least-privilege alternative and a rollback test.

[PASTE SANITIZED RULE]

Shell: ispeziona la challenge anonima

Esegui in un terminale senza cookie o credenziali del browser.

URL='https://example.com/private'
curl -sS -D - -o /dev/null "$URL"

Per un 401 reale, esamina WWW-Authenticate. Un URL pubblico che restituisce 401 in forma anonima ma 200 nel browser autenticato è la trappola dello stato di autenticazione descritta sopra.

PowerShell: ispeziona la stessa risposta anonima

$response = Invoke-WebRequest -Uri 'https://example.com/private' -SkipHttpErrorCheck
$response.StatusCode
$response.Headers['WWW-Authenticate']

Shell: confronta user-agent generico e user-agent che dichiara di essere un bot

URL='https://example.com/page'
curl -sS -o /dev/null -w 'generic %{http_code}\n' "$URL"
curl -sS -o /dev/null -w 'claimed-bot %{http_code}\n' -A 'Googlebot' "$URL"

Il confronto può far emergere una regola basata sullo user-agent, ma non verifica Googlebot: qualunque client può inviare quella stringa. Conferma separatamente il traffico del crawler reale tramite IP o DNS inverso e diretto prima di modificare le regole di accesso.

Strumenti per trovare lo strato che restituisce 401

• Bulk HTTP Status Code Checker: conferma quali URL pubblici restituiscono 401 senza la sessione del browser ed esporta l’insieme interessato.
• HTTP Header Checker: ispeziona WWW-Authenticate, header cache/CDN e hop di redirect per trovare indizi sullo strato che emette la risposta.
• Googlebot Verifier: valida le prove sull’IP del crawler prima di creare un’eccezione di accesso: lo user-agent da solo non dimostra nulla.
• URL Inspection di Search Console, Live Test: conferma ciò a cui può accedere il fetch live di Google dopo la correzione.
• Eventi di sicurezza CDN/WAF e log dell’origine: collega ID della richiesta e orario per determinare se il 401 è stato generato dall’edge, dall’applicazione o dall’origine.

Mettiti alla prova: 401 Unauthorized

Cinque domande rapide su che cosa significa un 401 e come lo gestiscono i motori di ricerca. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche