Bloccato per accesso vietato (403)

TL;DR — “Bloccato per accesso vietato (403)” nel rapporto Indicizzazione delle pagine significa che Googlebot ha provato a leggere la pagina e il server ha risposto “no, non sei autorizzato” (un HTTP 403). La pagina non verrà indicizzata. Se dovrebbe essere pubblica, è un bug da correggere: spesso un firewall, una CDN o un plugin di sicurezza blocca Google per errore, motivo per cui la pagina può apparire normale nel tuo browser ma risultare bloccata per Google. Se invece dovrebbe restare privata, il 403 potrebbe fare esattamente ciò che deve: la correzione è diversa.

Che cosa significa questo stato

Questa etichetta del rapporto significa che Google ha ricevuto una risposta HTTP 403 mentre richiedeva l’URL. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. 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 persistenti 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 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: 2026-07-14 Google: HTTP status codes

Quando apri il rapporto Indicizzazione delle pagine in Search Console e vedi “Bloccato per accesso vietato (403)”, il messaggio è semplice: Googlebot ha chiesto la pagina al server e il server ha rifiutato con un errore 403 Forbidden.

Poiché Google ha ricevuto un 403, non può leggere il contenuto della pagina, quindi non la indicizzerà e, se la pagina era già presente su Google, la rimuoverà dai risultati.

Devi davvero correggerlo?

Prima di inseguire una regola, decidi che cosa dovrebbe fare l’URL:

• Dovrebbe essere pubblico e indicizzato — il 403 è un bug. Continua a leggere: il resto della pagina contiene la correzione.
• Dovrebbe essere pubblico ma non indicizzato — non affidarti a robots.txt: un disallow di robots.txt è una barriera separata, con una propria motivazione nel rapporto, e da solo non può produrre un HTTP 403. Servi la normale risposta 200 e usa invece una direttiva noindex.
• Dovrebbe restare privato — il 403 può essere un controllo degli accessi corretto e funzionante. La correzione non è la regola firewall: assicurati che l’URL non si trovi nella sitemap o nei link interni da cui Google continua a scoprirlo.

Perché si carica per te ma non per Google

È la parte che confonde nel caso “dovrebbe essere pubblico”. Fai clic sull’URL nel browser e si carica perfettamente: come può Google ricevere un blocco?

Il browser invia segnali che un crawler non invia: cookie, uno user-agent da “browser normale” e (per le barriere con challenge JS o CAPTCHA) la capacità di superare la challenge. La richiesta di Googlebot in genere è diversa su tutti questi punti — niente cookie e user-agent da crawler — e spesso basta perché una regola per bot pensata per gli scraper scatti solo per il crawler, mentre i visitatori normali passano. Di solito la pagina non è guasta: una regola sta bloccando il visitatore sbagliato. (La scheda Advanced spiega come confermare la differenza esatta invece di indovinare.)

Un firewall o una CDN sono cause segnalate di frequente

Per gli URL che dovrebbero essere pubblici, un firewall, una CDN o uno strumento di sicurezza (come Cloudflare, un WAF o un plugin di sicurezza WordPress) che blocca Googlebot per errore è una delle cause segnalate più spesso, anche se non esiste una percentuale verificata in modo indipendente sulla frequenza esatta. Altre cause sono regole che bloccano per user-agent o Paese, protezione hotlink o contenuti messi dietro un accesso che dovrebbero essere pubblici.

Da dove cominciare per correggerlo

• In Search Console, usa Ispezione URL su un URL interessato e fai clic su Test live URL per confermare che Google riceva davvero un 403.
• Controlla le impostazioni della CDN, del firewall e del plugin di sicurezza (e i relativi log) per trovare qualcosa che blocchi Googlebot o i suoi intervalli IP.
• Assicurati che sia davvero Googlebot prima di farlo passare e mantieni l’eccezione stretta — il percorso e la regola specifici, non un’autorizzazione generalizzata. Molti bot falsificano il nome Googlebot. Le schede Advanced e Scripts mostrano come verificarlo.
• Dopo aver corretto la regola, la pagina dovrebbe restituire un normale 200. Poi usa Convalida correzione nel rapporto: la reindicizzazione segue automaticamente quando Google ripete il crawl del 200, anche se non esiste una tempistica garantita.

Uno stato gemello da conoscere è “Bloccato per richiesta non autorizzata (401)”: è la stessa idea, ma per le pagine dietro una barriera di accesso. Meccanismo diverso, stesso esito e correzione in gran parte uguale.

Vuoi il ciclo completo di diagnosi e correzione, i dettagli WAF e i comandi per verificare Googlebot? Passa alla scheda Advanced.

TL;DR — Un 403 nel rapporto Indicizzazione delle pagine significa che Googlebot ha ricevuto un HTTP 403 sull’URL, quindi Google non lo indicizzerà (e lo rimuove se era già indicizzato). La guida Indicizzazione delle pagine di Google presenta il 403 come credenziali fornite ma rifiutate: è la formulazione del rapporto, non la definizione completa di HTTP; RFC 9110 definisce il 403 in modo più ampio come “compreso ma rifiutato”, con o senza credenziali, quindi considera la formulazione di Google un’euristica, non la prova di una configurazione errata. Decidi prima se l’URL dovrebbe essere pubblico e indicizzabile: per gli URL che dovrebbero essere pubblici, un firewall/CDN/WAF che blocca Googlebot per errore è una causa segnalata frequentemente, motivo per cui la pagina spesso si apre per te ma restituisce 403 a Google; un 403 su un URL destinato a restare privato può invece funzionare come previsto. Google tratta 401 e 403 allo stesso modo per l’indicizzazione e dice esplicitamente di non usare 401/403 per limitare il crawl: usa 429 (o 503). Verifica il vero Googlebot (DNS inverso, intervalli IP pubblicati e categoria client corretta) prima di inserirlo in allowlist, limita l’eccezione al percorso e alla regola specifici, poi conferma un 200 in Ispezione URL → Test live URL ed esegui Convalida correzione.

Che cosa dice davvero Google su un 403 — e che cosa dice davvero HTTP

L’etichetta riporta la risposta osservata, non lo specifico WAF, CDN o controllo degli accessi che l’ha causata. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. 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 La conseguenza sull’indicizzazione segue la gestione generale dei 4xx da parte di Google. 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: 2026-07-14 Google: HTTP status codes

La documentazione del rapporto Indicizzazione delle pagine di Google la descrive così: un HTTP 403 significa che lo user-agent ha fornito credenziali ma non ha ottenuto l’accesso; tuttavia Googlebot non fornisce mai credenziali, quindi, secondo la formulazione di Google, il server restituisce l’errore per errore. La pagina non verrà indicizzata. Se vuoi indicizzarla, la correzione indicata da Google è ammettere gli utenti non autenticati oppure autorizzare esplicitamente le richieste di Googlebot senza autenticazione.

Questa è però la formulazione della guida di Google, non la definizione HTTP completa. RFC 9110 definisce il 403 in modo più ampio: “the server understood the request but refuses to fulfill it,” (traduzione) «il server ha compreso la richiesta ma rifiuta di soddisfarla.» Le credenziali possono essere coinvolte, ma la RFC dice esplicitamente che una richiesta può essere vietata per ragioni completamente non legate alle credenziali: una policy, una regola di controllo degli accessi, una decisione di sicurezza dell’edge o qualunque altra scelta del proprietario del server. Quindi la conclusione utile non è “un 403 a Googlebot significa sempre per definizione che una regola è rotta”, ma “scopri se questo URL dovrebbe essere raggiungibile e poi trova la regola esatta che ha restituito 403”. Per una pagina che dovrebbe essere pubblica e indicizzata, un 403 a Googlebot è quasi sempre qualcosa da correggere. Per una pagina deliberatamente privata o vietata, il 403 può essere una decisione di accesso valida e funzionante: il problema di solito è che Google non avrebbe dovuto scoprire l’URL (vedi il controllo d’intento), non che il firewall sia errato.

Qualunque sia il caso, la documentazione separata di Google sui codici di stato HTTP è netta sulle conseguenze per l’indicizzazione: non usa il contenuto degli URL che restituiscono codici 4xx, tutti gli errori 4xx tranne 429 sono trattati allo stesso modo (il crawler comunica al sistema successivo che il contenuto non esiste) e la pipeline di indicizzazione rimuove l’URL dall’indice se era già stato indicizzato.

Decidi che cosa deve fare l’URL prima di correggere qualsiasi cosa

Non tutte le righe di questo rapporto richiedono la stessa correzione. Prima inserisci l’URL in una di queste quattro categorie:

1. Pubblico e destinato all’indicizzazione. Il 403 è involontario: esegui il ciclo diagnosi → correzione → validazione qui sotto.
2. Pubblico ma non destinato all’indicizzazione. Non usare robots.txt per risolvere il problema: un disallow di robots.txt è una barriera di crawl separata, con la propria motivazione Indicizzazione delle pagine (“bloccato da robots.txt”); da solo non produce l’HTTP 403 riportato da questo stato. Servi la normale risposta 200 e usa una direttiva noindex (o un redirect/rimozione corretti).
3. Deliberatamente privato o vietato. Un 403 può essere l’esito corretto e voluto per una risorsa che il richiedente non dovrebbe raggiungere. Se compare in questo rapporto, il problema operativo di solito è che l’URL è scopribile — nella sitemap, nei link interni o altrove — non che la regola di accesso sia sbagliata. Pulisci il segnale di scoperta invece di aprire la porta.
4. Un URL che non dovrebbe esistere o di cui non vuoi confermare l’esistenza. Scegli la risposta in base alla policy di sicurezza dell’applicazione, non a una scorciatoia SEO: qui possono essere legittimi sia un 403 sia un 404, se non vuoi confermare che l’URL esista.

Da qui in avanti si presume il caso 1: un URL che vuoi davvero sottoporre a crawl e indicizzare.

403 vs 401: come distinguerli

Questi due stati sono gemelli nel rapporto e la maggior parte degli articoli li semplifica con una regola empirica (“403 = non sono state chieste credenziali, 401 = barriera di accesso”) che da sola non è affidabile: anche un livello di autenticazione configurato male può restituire 403 e finire in questa riga. Il segnale vero è la risposta stessa:

• 401 (unauthorized) — secondo RFC 9110, un 401 significa nello specifico che mancano credenziali di autenticazione valide e la risposta deve contenere una challenge WWW-Authenticate (autenticazione HTTP, barriera di accesso). A Google è stato detto che doveva autenticarsi e non ha potuto.
• 403 (accesso vietato) — un rifiuto più ampio. RFC 9110 lo definisce come “il server ha compreso la richiesta ma rifiuta di soddisfarla”, con o senza credenziali. In pratica questa riga riguarda più spesso un blocco di firewall/CDN/WAF o una regola di sicurezza, ma può anche essere un’applicazione che restituisce 403 per un controllo auth rotto, un limitatore di velocità o una decisione intenzionale di controllo degli accessi.

Per distinguerli davvero su un determinato URL, controlla stato e header restituiti — la risposta contiene un header WWW-Authenticate? — invece di dedurre il meccanismo dalla sola etichetta del rapporto. Condividono l’esito (non indicizzato) e spesso la correzione (far passare Googlebot verificato o aprire il contenuto agli utenti anonimi), quindi, una volta capito quale stai osservando, puoi applicare lo stesso ciclo diagnostico a entrambe le righe.

Che effetto ha un 403 sull’indicizzazione

Quando Googlebot riceve un 403, seguono tre cose:

1. Il contenuto viene ignorato. Google non usa il contenuto degli URL 4xx, quindi nulla della pagina può essere indicizzato.
2. L’URL viene rimosso se era indicizzato. Un 403 può deindicizzare una pagina che in precedenza si posizionava: non è solo un problema di “non verrà aggiunta”, ma anche di “scompare dai risultati”.
3. La frequenza di crawl diminuisce. Nel tempo Google sottopone a crawl gli URL 4xx meno spesso, quindi un 403 di lunga durata viene visitato meno e recupera più lentamente dopo la correzione.

Perché Googlebot riceve 403 mentre il browser no

È la domanda che fa girare le persone in tondo. La pagina si carica nel browser, quindi il contenuto è chiaramente a posto, ma Google riporta un 403. La spiegazione probabile è che browser e Googlebot producano richieste molto diverse e una regola di gestione dei bot costruita per fermare gli scraper scatti per il crawler mentre serve normalmente le persone. Trattala però come una ipotesi da confermare, non come un fatto già dimostrato: l’attributo che conta davvero varia da sito a sito:

• Il browser invia cookie, un vero user-agent da browser e può risolvere una challenge JS o CAPTCHA; la richiesta di Googlebot in genere non contiene nulla di questo: niente cookie, user-agent da crawler e nessuna capacità di risolvere una challenge interattiva (anche se Google-InspectionTool esegue JavaScript e riporta l’output renderizzato, quindi la supposizione “Googlebot has no JavaScript” non è corretta per ogni parte del processo).
• Oltre alle differenze lato client, le due richieste possono differire anche per IP/categoria sorgente, area geografica, metodo, referrer, stato della cache e regola che è effettivamente scattata: una qualunque di queste può essere il vero innesco.

Non indovinare quale attributo l’abbia causato. Confronta i log esatti di edge e origine per una richiesta realmente bloccata con quelli di una visita normale nel browser — stesso ID regola, header di risposta, metodo, UA, IP sorgente e categoria verificata, area geografica, cookie, referrer, stato della cache ed esito della challenge — e modifica un attributo alla volta finché trovi quello che fa cambiare la risposta. È così che confermi che il 403 sia selettivo invece di darlo per scontato.

Cause comuni

• Gestione dei bot su CDN/WAF. Cloudflare (Bot Fight Mode / Super Bot Fight Mode, Browser Integrity Check, Managed Challenge), Akamai, Imperva/Incapsula, Sucuri e AWS WAF possono sottoporre a challenge o restituire 403 ai client non browser, incluso Googlebot. Per gli URL che dovrebbero essere pubblici è una delle cause segnalate più spesso e quasi sempre involontaria, anche se non esiste una percentuale verificata in modo indipendente sul suo peso.
• Firewall del server/regole di sicurezza. mod_security / OWASP CRS, fail2ban o firewall a livello host che interpretano il pattern di Googlebot come abusivo.
• Regole user-agent/referrer/hotlink. Regole che restituiscono 403 a ogni richiesta senza uno user-agent o un referrer simile a quello di un browser.
• Blocco geografico o IP. Esclusione degli intervalli IP da cui esegue il crawl Googlebot (soprattutto IP statunitensi), quindi un blocco per Paese può intercettarlo senza che sia evidente.
• Barriere di accesso o credenziali. Richiesta di cookie o accesso per vedere contenuti che dovrebbero essere pubblici: è il caso gemello del 401.
• Regole di rate limiting che restituiscono 403 dopo N richieste. Non farlo: vedi qui sotto.

Non usare il 403 per rallentare Googlebot

È l’anti-pattern che vale la pena chiamare per nome. Persone (e alcune CDN) restituiscono 403 o 404 per rallentare Googlebot e ridurre il carico sul server. Google è stato esplicito: non funziona e non va fatto: non usare i codici di stato 401 e 403 per limitare la velocità di crawl. Non hanno alcun effetto sul crawl, ma deindicizzano la pagina. Se hai davvero bisogno che Googlebot rallenti, restituisci 429 (o un 5xx come 503): sono i codici che Google interpreta come “rallenta” e l’effetto è temporaneo, non permanente.

Come diagnosticarlo

1. Ispezione URL → Test live URL. Passa un URL interessato in Search Console e usa Test live URL per confermare che Google riceva attualmente un 403, non un rapporto obsoleto. Ricorda che il test è Google-InspectionTool, un client Google specifico: un test live superato dice che InspectionTool è passato in quel momento, non che il Googlebot programmato seguirà lo stesso percorso WAF, geografico, di cache o rate limit al prossimo crawl.
2. Riproduci come Googlebot. Non provare dal browser normale: recupera l’URL con lo user-agent di Googlebot, idealmente dall’esterno della tua rete e da più di una regione (Google esegue soprattutto il crawl da IP statunitensi ma può spostarsi in altri Paesi se le richieste dagli Stati Uniti vengono bloccate, quindi un esito positivo da una sola regione non dimostra l’accesso globale). In questo modo fai scattare la stessa regola. I comandi sono nella scheda Scripts.
3. Leggi i log CDN/WAF/firewall. Trova la regola esatta scattata sulla richiesta di Googlebot: confronta header di risposta, ID regola e trigger (user-agent, IP, challenge o rate limit) con la voce del log di una visita normale, invece di supporre quale attributo abbia causato il blocco.
4. Verifica il vero Googlebot e la sua categoria. Prima di autorizzare qualcosa, conferma che le richieste siano davvero di Googlebot tramite DNS inverso + diretto o intervalli IP pubblicati da Google e controlla quale client Google abbia effettuato la richiesta: Googlebot comune, crawler speciali e fetcher attivati dall’utente (come Google-InspectionTool) usano maschere host e liste IP diverse, quindi verificare contro la lista sbagliata può far sembrare falsificata una richiesta autentica.

Come correggerlo

• Limita l’eccezione per Googlebot verificato nel WAF o firewall: usa un’identità verificata (DNS inverso + diretto, abbinata alla categoria client corretta) oppure gli attuali intervalli IP dei crawler pubblicati da Google, non la fiducia nella sola stringa user-agent. Mantieni l’eccezione stretta: i percorsi specifici che ne hanno bisogno e la regola specifica che blocca, invece di un’eccezione generalizzata per tutto Google. Lascia attivi gli altri controlli di sicurezza, i rate limit e i log e imposta una data di scadenza/revisione, così un’allowlist obsoleta non sopravvive silenziosamente al motivo per cui era stata creata. Chiedi al fornitore della CDN o del firewall di confermare che Googlebot sia autorizzato e automatizza un controllo delle regole di blocco contro le sottoreti IP pubblicate correnti da Google, per evitare che un futuro aggiornamento degli intervalli IP lo blocchi di nuovo senza avviso.
• Apri il contenuto pubblico agli utenti anonimi. Se il 403 nasce da un requisito di accesso/cookie su contenuti che dovrebbero essere pubblici, rimuovi quel requisito (è anche la correzione condivisa con il caso gemello 401).
• Sostituisci il rate limit 403 con 429. Se una regola restituisce 403 dopo una soglia di richieste, cambiala per restituire 429 (o 503), così Googlebot lo interpreta come “rallenta” invece di “vattene”.

Valida la correzione e fai reindicizzare la pagina

Dopo la correzione della regola, l’URL dovrebbe restituire 200. Poi:

1. Ispezione URL → Test live URL per confermare che la risposta live sia ora 200.
2. Richiedi l’indicizzazione per gli URL ad alta priorità e/o fai clic su Convalida correzione sulla riga “Bloccato per accesso vietato (403)” nel rapporto Indicizzazione delle pagine.
3. La reindicizzazione segue automaticamente quando Google esegue di nuovo il crawl di un 200: non esiste una garanzia ufficiale sulla velocità esatta e l’URL deve comunque superare un crawl normale prima di ricomparire. Non devi attivare altro manualmente oltre a rimuovere il blocco, confermare una risposta sana e dare tempo a Google di ripetere il crawl.

Per il quadro generale dei motivi di non indicizzazione presenti qui e del modo in cui il rapporto li raggruppa, consulta la panoramica del rapporto Indicizzazione delle pagine. Per lo stato gemello, “Bloccato per richiesta non autorizzata (401)” è la versione 401 dello stesso problema.

Riepilogo IA

Una sintesi della versione Advanced:

• Che cos’è. “Bloccato per accesso vietato (403)” nel rapporto Indicizzazione delle pagine di GSC = Googlebot ha eseguito il crawl dell’URL e il server ha restituito HTTP 403. Google non lo indicizzerà e lo rimuove se era già indicizzato.
• Formulazione di Google vs HTTP. La guida di Google descrive il 403 come credenziali fornite ma rifiutate: è la formulazione del rapporto, non la definizione HTTP completa. RFC 9110 definisce il 403 più ampiamente: un rifiuto che il server può emettere con o senza credenziali, per qualunque ragione.
• Decidi prima l’intento dell’URL. Pubblico e destinato all’indicizzazione → correggi il 403. Pubblico ma non destinato all’indicizzazione → usa noindex, non robots.txt (che è una barriera separata e da solo non può produrre un 403). Deliberatamente privato → il 403 può essere corretto; pulisci invece il modo in cui Google scopre l’URL.
• Una causa segnalata frequentemente (per gli URL pubblici). Un firewall/CDN/WAF (Cloudflare, Akamai, Imperva/Incapsula, Sucuri, AWS WAF) o un plugin di sicurezza che blocca Googlebot, quasi sempre senza intenzione; non esiste però una percentuale verificata sulla frequenza di questa causa specifica.
• Perché si carica per te ma non per Google. Il browser porta in genere cookie, un user-agent reale e capacità di risolvere challenge che la richiesta di Googlebot non porta: conferma il vero trigger confrontando i log invece di supporlo.
• 401 vs 403. Controlla la risposta: 401 richiede una challenge WWW-Authenticate; 403 è un rifiuto più ampio che può verificarsi con o senza credenziali. Google li tratta allo stesso modo per l’indicizzazione e le correzioni spesso si sovrappongono.
• Non usarlo per rallentare. Non usare 401/403 per limitare il crawl: deindicizzano soltanto. Usa 429 (o 503) per chiedere di “rallentare”.
• Diagnosi. Ispezione URL → Test live URL (conferma l’accesso di Google-InspectionTool in quel momento, non il percorso esatto del Googlebot programmato); riproduci come Googlebot da più di una regione; confronta i log WAF/firewall riga per riga; verifica il vero Googlebot e la sua categoria client prima di autorizzarlo.
• Correzione e validazione. Crea un’eccezione stretta per Googlebot verificato (oppure apri il contenuto); sostituisci il rate limit 403 con 429; conferma un 200 in Test live URL; esegui Convalida correzione. La reindicizzazione segue automaticamente quando Google ripete il crawl di un 200, senza una tempistica garantita.

Documentazione ufficiale

Documentazione primaria dei motori di ricerca.

Google

• Rapporto Indicizzazione delle pagine — il rapporto stesso, comprese le voci “Blocked due to access forbidden (403)” e “Blocked due to unauthorized request (401)” e il loro significato.
• Come i codici di stato HTTP e gli errori di rete e DNS influiscono su Ricerca Google — come Google gestisce i 4xx (contenuto ignorato, URL rimosso dall’indice) e la regola contro l’uso di 401/403 per limitare il crawl.
• Verificare Googlebot e gli altri crawler Google — DNS inverso + diretto e intervalli IP pubblicati dei crawler, per autorizzare il vero Googlebot e non un falsificatore.
• Panoramica dei crawler e fetcher Google — ogni user-agent di Google e i file JSON degli intervalli IP da confrontare.
• Non restituire 404 al mio cibo (blog Search Central, 2023) — la richiesta di Google ai proprietari dei siti e alle CDN di smettere di usare 403/404 per rallentare Googlebot e che cosa usare invece.

Bing / Microsoft

• Bing Webmaster Tools — Crawl Control — Bingbot, come Googlebot, non può indicizzare una pagina su cui riceve 403; verifica che regole firewall/CDN non blocchino Bingbot (gli hostname risolvono in *.search.msn.com) e usa Crawl Control per gestire la velocità invece di bloccarlo.

Standard HTTP

• RFC 9110 — HTTP Semantics, §15.5.2 (401) e §15.5.4 (403) — le definizioni di protocollo usate qui per correggere la formulazione più stretta, basata sulle credenziali, della guida Google: 401 richiede una challenge WWW-Authenticate, mentre 403 è un rifiuto più ampio che può verificarsi con o senza credenziali.

Citazioni dalla fonte

Dichiarazioni verificabili di Google. Ogni link è un deep link che porta direttamente al passaggio citato nella pagina sorgente.

Google — che cosa significa un 403 per l’indicizzazione (rapporto Indicizzazione delle pagine)

• “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. Googlebot però non fornisce mai credenziali, quindi il server restituisce erroneamente questo errore. La pagina non verrà indicizzata.» — Google Search Console Help, “Page Indexing report”. Vai alla citazione

Google — come gestisce i 4xx (compreso il 403)

• “Google doesn’t use the content from URLs that return 4xx status codes.” (traduzione) «Google non utilizza i contenuti degli URL che restituiscono codici di stato 4xx.» — Google Search Central docs. 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, vengono trattati allo stesso modo: i crawler Google comunicano al sistema di elaborazione successivo che il contenuto non esiste.» Vai alla citazione

Google — non usare 401/403 per limitare la velocità di crawl

• “Don’t use 401 and 403 status codes for limiting the crawl rate.” (traduzione) «Non usare i codici di stato 401 e 403 per limitare la velocità di scansione.» — Google Search Central docs. Vai alla citazione

Checklist diagnosi → correzione → validazione del 403

Eseguila su ogni URL che mostra “Bloccato per accesso vietato (403)”:

• Decidi l’intento dell’URL — pubblico/indicizzabile, pubblico/non indicizzabile, deliberatamente privato oppure non dovrebbe essere scoperto. Solo il caso pubblico e indicizzabile richiede il resto della checklist.
• Conferma che sia live, non obsoleto — Ispezione URL → Test live URL mostra un 403 attuale (conferma l’accesso di Google-InspectionTool, non necessariamente il percorso esatto del Googlebot programmato).
• Riproduci come Googlebot — recupera l’URL con lo user-agent Googlebot (e dall’esterno della tua rete, idealmente da più regioni), non dal browser normale.
• Trova la regola — confronta i log CDN/WAF/firewall/plugin della richiesta bloccata con una visita normale nel browser (ID regola + trigger: user-agent, IP, challenge o rate limit), invece di supporre la causa.
• Verifica il vero Googlebot e la sua categoria client — DNS inverso + diretto (l’host termina in googlebot.com, google.com o googleusercontent.com) oppure intervallo IP della categoria corretta, prima di autorizzare qualsiasi cosa.
• Limita l’eccezione per Googlebot verificato — percorso/i e regola specifici, per identità/intervallo IP, con log e data di scadenza/revisione; non un’autorizzazione generale e mai la sola fiducia nello user-agent.
• Apri il contenuto pubblico — se il 403 è un requisito di accesso/cookie su contenuti che dovrebbero essere pubblici, rimuovilo.
• Sostituisci ogni rate limit 403 con 429 (o 503) — non usare mai 401/403 per rallentare il crawl.
• Conferma un 200 — Ispezione URL → Test live URL ora restituisce 200.
• Valida — fai clic su Convalida correzione sulla riga 403 e/o su Richiedi indicizzazione per gli URL prioritari; la reindicizzazione avverrà automaticamente al nuovo crawl.
• Preparati al futuro — automatizza il controllo delle regole di blocco rispetto alle sottoreti IP pubblicate da Google, così un aggiornamento degli intervalli non blocca di nuovo Googlebot senza avviso.

I modelli mentali

1. Chiedi “dovrebbe essere pubblico?” prima di “chi è configurato male?” La formulazione della guida Google presenta il 403 come credenziali inviate e rifiutate, ma RFC 9110 lo definisce più ampiamente: una richiesta che il server ha compreso e rifiutato, con o senza credenziali. Per una pagina che dovrebbe essere pubblica e indicizzata, un 403 a Googlebot è quasi sempre una regola scattata sul visitatore sbagliato: trattalo come “trova la regola”, non come un giudizio sulla pagina. Per una pagina deliberatamente privata, il 403 potrebbe fare il suo lavoro; la correzione consiste nel rimuovere l’URL dal percorso di scoperta di Google, non nell’aprire il firewall.

2. Stessa regola, visitatore dall’aspetto diverso: conferma quale differenza conta. La pagina può caricarsi per te e restituire 403 a Google perché il browser porta cookie, un user-agent reale e la capacità di risolvere challenge che la richiesta di Googlebot non porta. Non supporre però quale attributo abbia fatto scattare la regola: confronta i log e modifica un attributo alla volta. Fai il debug costruendo la richiesta di Googlebot, non la tua, e lascia che i log spieghino il perché invece di affidarti a un’ipotesi.

3. Verifica l’identità, poi limita l’eccezione. Chiunque può falsificare lo user-agent Googlebot. L’ordine è sempre: conferma identità e categoria client (DNS inverso / intervallo IP corrispondente) → poi autorizza; anche in quel caso limita l’eccezione al percorso e alla regola specifici, con log e data di scadenza/revisione, invece di creare un’allowlist generale per Google. Autorizzare in base al solo user-agent, o in modo troppo ampio, apre una falla agli scraper che fingono di essere Google.

4. Il 403 è il throttle sbagliato. Se vuoi rallentare Googlebot, 401/403 non lo fanno: deindicizzano. I codici “rallenta” sono 429 e 5xx/503. Scegli il codice che corrisponde al tuo intento: “vattene per sempre” (deindicizza) oppure “torna più tardi” (limita la velocità).

5. 403 e 401 sono cugini stretti, distinti dalla risposta. 401 richiede una challenge WWW-Authenticate: una vera barriera di autorizzazione. 403 è un rifiuto più ampio, possibile con o senza credenziali, quindi non dedurre il meccanismo dalla sola etichetta: controlla la risposta reale. Una volta capito quale stai osservando, condividono esito (non indicizzato) e spesso correzione (ammettere Googlebot verificato o aprire il contenuto): diagnosticali con lo stesso ciclo.

Cheat sheet del 403

Gli stati gemelli in Indicizzazione delle pagine

Codici di stato e crawl: scegli quello giusto

Che cosa fa un 403 su una pagina che dovrebbe essere indicizzata

• Contenuto ignorato (Google non usa il contenuto 4xx).
• URL rimosso dall’indice se era già indicizzato.
• La frequenza di crawl diminuisce mentre il 403 persiste.

Riferimento rapido per verificare Googlebot

• DNS inverso dell’IP → l’host deve terminare in googlebot.com, google.com o googleusercontent.com.
• DNS diretto dell’host → deve risolvere di nuovo allo stesso IP.
• In alternativa, confronta l’IP con i file JSON degli intervalli IP dei crawler correnti di Google per la categoria client corretta: Googlebot comune, crawler speciali e fetcher attivati dall’utente (come Google-InspectionTool) pubblicano liste separate.

Riproduci il 403 come Googlebot

Non provare dal browser normale: non farà scattare la regola per bot. Recupera l’URL con lo user-agent di Googlebot per vedere ciò che vede Google.

macOS / Linux

# Fetch headers only, as Googlebot's user-agent — look at the status line
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -I https://www.example.com/page/
# A "HTTP/1.1 403 Forbidden" here reproduces what Googlebot is getting.

Windows (PowerShell)

# -SkipHttpErrorCheck so PowerShell shows the 403 instead of throwing
$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Head `
  -UserAgent $ua -SkipHttpErrorCheck | Select-Object StatusCode, StatusDescription

Se questo restituisce 403 ma una richiesta dal browser normale restituisce 200, hai confermato un blocco specifico per i bot. Nota: un WAF sofisticato può usare anche l’IP come criterio, quindi per una riproduzione completa prova dall’esterno della tua rete.

Verifica che un bot sia davvero Googlebot (prima di inserirlo in allowlist)

Molto traffico falsifica lo user-agent Googlebot. Conferma l’identità con un controllo DNS inverso + diretto prima di far passare un IP dal firewall.

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 con un dominio Google o la ricerca diretta non corrisponde all’IP originale, non è Googlebot: non inserirlo in allowlist. Puoi anche confrontare l’IP con gli intervalli pubblicati da Google (googlebot.json). Nota che googlebot.json copre soltanto Googlebot comune: crawler speciali e fetcher attivati dall’utente (come Google-InspectionTool) pubblicano file di intervalli IP separati, quindi confronta con la lista del client reale che vuoi verificare. Conferma prima l’identità, poi limita l’eccezione al percorso e alla regola specifici; non autorizzare mai in base al solo user-agent e non aprire un’eccezione generale.

Diagnosi di un 403: blocco WAF, barriera di accesso o rate limit usato male?

Il primo bivio controlla la risposta stessa: un 403 senza header WWW-Authenticate o richiesta di accesso punta lontano dal caso gemello 401 e verso un rifiuto di regola di sicurezza o di controllo degli accessi. Da lì i rami seguono il ciclo diagnosi-poi-correzione già visto nella scheda Advanced: considera ogni esito un’ipotesi da confermare nei log, non una certezza. Segui il percorso.

Misura il gruppo 403, non solo la sua esistenza

Il numero da osservare è quanti URL si trovano nella riga “Bloccato per accesso vietato (403)” del rapporto Indicizzazione delle pagine nel tempo, non solo se la riga esiste: una singola fotografia non dice se una correzione ha funzionato o se stanno accumulandosi nuovi 403.

Conteggio del gruppo 403 nel tempo

• Metrica — il numero di URL nella voce “Bloccato per accesso vietato (403)” del rapporto Indicizzazione delle pagine di GSC, monitorato settimana dopo settimana.
• Che cosa indica — se una correzione dell’allowlist o della regola firewall ha funzionato e se compaiono nuovi 403. Dopo aver autorizzato Googlebot verificato o aperto un percorso pubblico, il conteggio dovrebbe scendere verso zero per gli URL corretti. Se resta stabile, va bene solo quando hai deciso deliberatamente che quegli URL non debbano mai essere sottoposti a crawl; un aumento di solito significa che una regola WAF/CDN o un aggiornamento degli intervalli IP sta iniziando a intercettare Googlebot.
• Come recuperarlo — rapporto Indicizzazione delle pagine di GSC, filtrato alla riga 403; controlla singoli URL con Ispezione URL → Test live URL per verificare che non sia una fotografia obsoleta.
• Benchmark/intervallo realistico — non esiste un obiettivo universale: dipende da quanti URL vuoi davvero indicizzare. L’asticella onesta è zero 403 tra gli URL che vuoi indicizzare e un conteggio stabile (non crescente) altrove. Stabilisci il tuo conteggio di base prima di giudicare la direzione della tendenza.
• Cadenza — ogni settimana subito dopo una correzione, finché il conteggio si stabilizza; poi ogni mese come controllo di regressione, perché una CDN o un aggiornamento degli intervalli IP di Googlebot può reintrodurre il blocco senza avviso.

Runbook: diagnosi, correzione, validazione

Il flusso 403 è un breve ciclo ordinato: non passare ad autorizzare prima di aver riprodotto il blocco come Googlebot e confermato l’identità di ciò che stai per far passare.

1. Conferma che sia live, non obsoleto. Esegui Ispezione URL → Test live URL in GSC sull’URL interessato per confermare che Google riceva attualmente un 403, non un rapporto memorizzato in cache.

2. Riproducilo come Googlebot, non come te stesso. Recupera l’URL con lo user-agent di Googlebot, idealmente dall’esterno della tua rete e da più di una regione: il browser normale invia cookie, un user-agent reale e può superare challenge JS/CAPTCHA che la richiesta di Googlebot normalmente non può superare, quindi potrebbe non far scattare la stessa regola. Confronta le voci di log risultanti una accanto all’altra invece di supporre quale differenza abbia causato il blocco.

3. Trova la regola. Leggi i log CDN/WAF/firewall per la regola esatta scattata sulla richiesta di Googlebot: ID della regola e trigger (user-agent, IP, challenge o rate limit) dicono che cosa devi cambiare.

4. Verifica il vero Googlebot e la sua categoria prima di inserirlo in allowlist. Conferma che le richieste che stai per autorizzare siano davvero di Googlebot tramite DNS inverso + diretto oppure l’elenco degli intervalli IP corrispondente alla categoria del client (Googlebot comune, crawler speciali e fetcher attivati dall’utente pubblicano liste separate): altrimenti apri un varco agli impostori o verifichi contro la lista sbagliata.

5. Correggi in base alla causa. Regola WAF/CDN → limita un’eccezione stretta per Googlebot verificato al percorso e alla regola specifici, tramite identità/intervallo IP. Requisito login/cookie su contenuto pubblico → rimuovilo. Regola rate limit che restituisce 403 → sostituiscila con 429 (o 503).

6. Valida. Conferma che Ispezione URL → Test live URL ora restituisca 200, poi fai clic su Convalida correzione sulla riga 403 e/o su Richiedi indicizzazione per gli URL prioritari. La reindicizzazione avviene automaticamente quando Google ripete il crawl di un 200: se dopo un paio di settimane il conteggio del gruppo 403 non scende, torna al passaggio 2 e riproduci di nuovo il problema invece di indovinare una causa nuova.

Prompt IA pronti all’uso

Prompt da copiare e incollare per classificare un 403 a partire da output diagnostici grezzi. Aiutano a restringere rapidamente la causa probabile: conferma sempre la conclusione nella configurazione effettiva del server o del firewall prima di modificarla.

Classifica la causa probabile dall’output di curl

I'm diagnosing a "Blocked due to access forbidden (403)" status in Google
Search Console. Below is the raw output of a request made with Googlebot's
user-agent (curl -A "...Googlebot..." -I). Based on this output alone,
classify the most likely cause as one of: (1) CDN/WAF bot-management
challenging or blocking non-browser clients, (2) server firewall / mod_security
rule flagging the crawl pattern as abuse, (3) user-agent or referrer/hotlink
rule, (4) geo/IP blocking excluding Googlebot's IP ranges, (5) a login/cookie
requirement on content that should be public, (6) a rate-limit rule misusing
403 instead of 429. Explain which specific header or detail in the output
pointed you to that answer, and tell me what's missing if you can't tell for
sure.

CURL OUTPUT:
[paste]

Classifica la causa da una riga del log WAF/firewall

I'm investigating why Googlebot is getting a 403 on a page I want indexed.
Below is a log line (or a few) from my WAF/CDN showing a blocked request. Tell
me whether this looks like a bot-identity rule (blocking by user-agent or IP
range), a challenge/CAPTCHA rule, or a rate-limit rule misusing 403, and what
I'd need to allowlist — by IP range or reverse-DNS — to let verified Googlebot
through without disabling the rule entirely.

LOG LINE(S):
[paste]

Controllo di buon senso prima di distribuire una correzione

I'm about to allowlist a set of IPs as "Googlebot" in my WAF, because a page
I want indexed is currently returning 403 to the crawler. Here's the evidence
I have that these requests are genuinely Googlebot: [describe reverse-DNS or
IP-range check]. Point out anything I might be missing — e.g. whether I should
verify by both reverse and forward DNS, whether I should match Google's
published IP-range JSON instead, or whether allowlisting by user-agent alone
would leave a hole for spoofers.

Mettiti alla prova: “Bloccato per accesso vietato (403)”

Cinque domande su che cosa significa un 403, in che cosa differisce da un 401 e come diagnosticarlo e correggerlo. Scegli una risposta per ogni domanda, poi controlla.

Strumenti per diagnosticare e correggere un 403

• HTTP Status Checker — incolla l’URL interessato (o un gruppo di URL) per confermare il codice di stato 403, vedere tutta la catena di risposta e intercettare eventuali redirect prima del blocco.
• Googlebot Verifier — controlla se un IP che dichiara di essere Googlebot è autentico (intervalli IP pubblicati più conferma tramite DNS inverso) prima di inserirlo in allowlist oltre una regola WAF o firewall.
• Google Search Console — Ispezione URL → Test live URL — il modo più vicino per vedere la risposta esatta ricevuta da Googlebot in questo momento.
• curl -A "...Googlebot..." — il modo più rapido per recuperare un URL con lo user-agent di Googlebot e leggere riga di stato e header grezzi.
• Il log degli eventi firewall del WAF/CDN (Cloudflare, Akamai, Sucuri ecc.) — trova la regola specifica che restituisce 403 agli intervalli IP di Googlebot.

Dimostra che la correzione ha funzionato davvero

Dopo aver autorizzato Googlebot verificato, aperto contenuti pubblici o sostituito una regola di rate limit con 429, questi controlli separano “la configurazione è cambiata” da “Google ora riesce davvero a raggiungere la pagina”. Eseguili in ordine.

Test 1 — Una richiesta con user-agent Googlebot ora restituisce 200

• Test da eseguire — recupera l’URL interessato con lo user-agent di Googlebot (oppure controllalo con HTTP Status Checker).
• Risultato atteso — la riga di stato è HTTP/1.1 200 OK.
• Interpretazione di un fallimento — se è ancora 403, la regola firewall/WAF non è stata davvero aggiornata oppure hai autorizzato l’intervallo IP sbagliato. Un 401 al posto di 403 significa che hai sostituito un blocco con una barriera auth: controlla separatamente quel percorso.
• Finestra di monitoraggio — immediata: il server risponde appena la modifica della regola è attiva.
• Segnale di rollback — se aprire il percorso espone contenuti che volevi mantenere riservati, ripristina il blocco e autorizza invece Googlebot verificato tramite IP/DNS inverso su una regola più stretta.

Test 2 — Google conferma di poter raggiungere la pagina

• Test da eseguire — esegui Ispezione URL → Test live URL in Google Search Console sull’URL interessato.
• Risultato atteso — il test live riesce e mostra il contenuto della pagina, senza segnalare un errore di accesso vietato.
• Interpretazione di un fallimento — se Test live URL segnala ancora un 403 dopo che il fetch con user-agent Googlebot è riuscito, sospetta una regola limitata specificamente agli intervalli IP pubblicati di Google invece dello user-agent: controlla nei log firewall la presenza di una seconda regola.
• Finestra di monitoraggio — da immediata a pochi minuti dopo la correzione.
• Segnale di rollback — n/d: è un test di sola lettura; se fallisce ancora, torna al ramo di fallimento del Test 1 invece di fare rollback.

Test 3 — Lo stato 403 scompare dal rapporto Indicizzazione delle pagine

• Test da eseguire — usa Convalida correzione sul problema “Bloccato per accesso vietato (403)” del rapporto Indicizzazione delle pagine e osserva il conteggio del gruppo nelle settimane successive (vedi la scheda Come misurare).
• Risultato atteso — l’URL esce dal gruppo 403 e, se era già indicizzato, ricompare nell’indice nel tempo mentre Google ripete il crawl della pagina ora 200.
• Interpretazione di un fallimento — la reindicizzazione è automatica ma non immediata: una convalida lenta non è un nuovo errore. Se dopo un paio di settimane il conteggio del gruppo 403 non scende, ripeti il Test 1 per confermare che la correzione sia ancora attiva: la cache CDN o un aggiornamento degli intervalli IP di Googlebot possono reintrodurre il blocco senza avviso.
• Finestra di monitoraggio — da alcuni giorni a qualche settimana, tramite il conteggio del gruppo 403.
• Segnale di rollback — torna a modificare la regola soltanto se il Test 1 ricomincia a fallire: non inseguire i tempi del rapporto Indicizzazione delle pagine.

Risorse che meritano il tuo tempo

Ufficiali

• Rapporto Indicizzazione delle pagine (Google) — le voci 403 e 401, alla lettera.
• Come i codici di stato HTTP influiscono su Ricerca Google — gestione dei 4xx e regola contro 401/403 per il rate limiting.
• Verificare Googlebot (Google) — DNS inverso + intervalli IP pubblicati.
• Non restituire 404 al mio cibo (Google, 2023) — non usare 403/404 per rallentare Googlebot.

I miei articoli correlati

• Guida introduttiva alla SEO tecnica — dove si collocano nel quadro generale problemi di accesso al crawl come questo.
• Robots.txt e SEO: tutto ciò che devi sapere — l’altro modo comune in cui le pagine vengono bloccate involontariamente dal crawl.

Di altri autori

• r/TechSEO — la community per il debug di crawl e indicizzazione, compresi i thread su Googlebot bloccato da CDN.
• Google sconsiglia i codici 403 o 404 per limitare la scansione di Googlebot (Search Engine Land) — copertura delle indicazioni di Gary Illyes “Don’t 404 my yum” e di ciò che usare invece (429/503).
• Google: non usare risposte di errore 403/400 per limitare Googlebot (Search Engine Journal) — il resoconto SEJ dello stesso post di Illyes, con contesto aggiuntivo.
• La causa più comune del blocco di Googlebot sono firewall e CDN (Search Engine Roundtable) — Google Search Relations spiega che la grande maggioranza dei blocchi di Googlebot deriva involontariamente da regole CDN/firewall.
• Bot che impersonano Googlebot (johnmu.com) — John Mueller spiega perché devi verificare Googlebot tramite DNS inverso prima di inserirlo in allowlist, invece di fidarti solo dello user-agent.
• Come correggere «Bloccato per accesso vietato (403)» (Onely) — guida pratica sui dettagli WAF/CDN e sul ciclo diagnosi → correzione.

Cronologia modifiche