403 Vietato

TL;DR — Un 403 Forbidden significa che il server ha compreso la richiesta ma la rifiuta: chi l’ha inviata non ha il permesso. È diverso da un 404 («qui non c’è nulla») e da un 401 («accedi prima»). Per la SEO, una pagina che continua a restituire 403 a Googlebot non verrà indicizzata e, se lo era già, uscirà dall’indice: se vuoi che sia trovata, il 403 è un problema da risolvere.

Cosa significa davvero un 403

Se sei un visitatore che ha appena ricevuto un 403 su un sito che non gestisci, si tratta di una regola lato server, non di un problema del browser. Prova un’altra rete o un altro dispositivo, verifica di non usare una VPN bloccata dal sito e cancella i cookie; se il problema persiste, la correzione spetta al proprietario del sito: il resto di questo articolo è scritto per lui.

Quando tu (o un bot di un motore di ricerca) chiedi una pagina, il server restituisce un codice di stato. 200 significa «eccola». Un 403 Forbidden significa «ho capito cosa hai chiesto, ma rifiuto di dartelo». Il rifiuto non deve dipendere dalle credenziali: il server può rifiutare per altri motivi e può persino inviare un 404 se vuole nascondere del tutto l’esistenza di una risorsa vietata. Evidence for this claim A 403 response means the server understood the request but refuses to fulfill it, and authenticating does not necessarily make a difference. Scope: RFC 9110 defines the protocol semantics; it does not identify the application, firewall, or policy responsible for a specific response. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.4 — 403 Forbidden

Il modo più semplice per distinguere i codici 4xx:

• 404 Not Found — «Qui non c’è nulla». La pagina non esiste.
• 403 Forbidden — «Qui c’è qualcosa, ma non puoi averla». È un blocco attivo.
• 401 Unauthorized — «Devi accedere o autenticarti prima». (Un 403 è più forte: anche accedere non servirebbe.)

Quindi un 403 non significa che il server sia guasto. Significa che il server sta funzionando esattamente come gli è stato ordinato: la domanda è se gli sia stato ordinato ciò che serviva.

Perché conta per la SEO

Googlebot deve poter recuperare una pagina per indicizzarla. Se chiede la tua pagina e riceve 403, Google non può leggere alcun contenuto di quella risposta: il rifiuto avviene prima. Google non indicizzerà una pagina che restituisce 403 e una pagina che era indicizzata uscirà infine dai risultati se continua a restituirlo. Il risultato assomiglia molto all’aggiunta di un noindex: la pagina scompare da Google, ma il meccanismo è diverso. Un tag noindex deve essere recuperato e letto per funzionare, mentre un 403 impedisce a Google di leggere qualsiasi cosa fin dall’inizio. 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 indexing outcome for persistent 403 responses, not the article's analogy to noindex. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Ecco il dettaglio che rende utile capire i 403: Googlebot non accede mai. Non invia password né credenziali. Quindi un 403, che spesso significa «le tue credenziali non sono state accettate», non può avere proprio quel significato per Googlebot. Questo non vuol dire automaticamente che sia un errore: il blocco può essere intenzionale (un sito di staging, un’area admin, contenuti riservati che non volevi far scansionare). Vuol dire però che un 403 su una pagina che vuoi rendere pubblica merita un’indagine: una regola di sicurezza, un firewall o un plugin può aver deciso che Googlebot appariva sospetto. Anche la guida di Google è circoscritta così: se vuoi indicizzare la pagina, consenti il passaggio di Googlebot senza richiedere autenticazione.

Cause più comuni

Non ho dati solidi su quale causa sia più frequente: considera questo un elenco di controllo, non una graduatoria:

1. Un CDN o firewall (WAF) che blocca il bot: la modalità Bot Fight Mode di Cloudflare è spesso responsabile e può colpire Googlebot insieme ai bot dannosi.
2. Una regola del server o dell’hosting che blocca determinati indirizzi IP o user-agent.
3. Un file robots.txt o .htaccess configurato male.
4. Un plugin di sicurezza (come Wordfence su WordPress) troppo aggressivo.
5. Una barriera di accesso: tutto ciò che richiede autenticazione restituirà 403 a un bot per progettazione, e spesso si tratta di un blocco intenzionale anziché di un bug.
6. Errori nei permessi dei file sul server.

Percorso rapido per la correzione

1. In Google Search Console, apri il rapporto Indicizzazione delle pagine e cerca “Blocked due to access forbidden (403).” (traduzione) «Bloccata per accesso vietato (403)».
2. Passa l’URL nello strumento Ispezione URL e premi Testa URL pubblicato per vedere cosa riceve Googlebot in questo momento.
3. Se usi Cloudflare o un altro CDN/firewall, controlla i log di sicurezza per verificare se Googlebot è bloccato e consenti il passaggio dei bot di ricerca verificati.
4. Dopo aver corretto la regola, usa Convalida correzione in Search Console.

Una cosa da non fare: non usare mai un 403 per cercare di rallentare Googlebot. Non funziona e può far rimuovere le pagine dall’indice. Se un bot sta sovraccaricando il server, servono 429 e 503.

Vuoi la versione approfondita, con la diagnosi Cloudflare/WAF, il caso particolare del 403 su robots.txt e il modo corretto di autorizzare i bot? Passa alla scheda Advanced.

TL;DR — Un 403 significa che il server ha compreso la richiesta ma l’ha rifiutata per motivi di accesso: è diverso da 404 (scomparso) e 401 (autenticazione). Per l’indicizzazione il risultato ricorda un noindex: Google non indicizza un URL 403 e rimuove quello che era già indicizzato, anche se il meccanismo (blocco del server/CDN/WAF) non ha nulla a che vedere con un meta tag. Poiché Googlebot non invia credenziali, un 403 per Googlebot è quasi sempre una configurazione errata: soprattutto filtro bot CDN/WAF, blocchi IP/UA del server, plugin di sicurezza oppure .htaccess/permessi. Il 403 non incide sul crawl rate: non usarlo mai per limitare il crawling (a questo servono 429/503). Conta anche il caso inverso: un 403 sul file robots.txt viene trattato in modo permissivo, mentre un 403 su una pagina è un blocco rigido.

403, 401 e 404: prima metti a fuoco il modello mentale

Questi tre codici vengono continuamente confusi e la distinzione guida l’intera diagnosi. La definizione di base viene dalla specifica HTTP, RFC 9110 §15.5.4: il server ha compreso la richiesta e rifiuta di soddisfarla. Nella stessa sezione ci sono alcune sfumature più importanti di quanto si creda:

• Il rifiuto non deve dipendere dalle credenziali. RFC 9110 ammette un 403 per motivi estranei all’autenticazione: non dimostra sempre che il richiedente sia «conosciuto» o che siano state coinvolte credenziali. Non interpretare ogni 403 come una storia di autenticazione.
• Un 403 non deve ammettere che la risorsa esiste. La specifica consente esplicitamente a un server d’origine che vuole nascondere l’esistenza di una risorsa vietata di rispondere invece con 404. Vale anche il contrario: un 404 non significa sempre «qui non c’è mai stato nulla»; a volte significa «c’è qualcosa, ma non voglio che tu lo sappia».
• 401 e 403 non sono soltanto «più debole contro più forte». Un 401 è una sfida di autenticazione: la specifica richiede un header WWW-Authenticate che spieghi al client come autenticarsi. Un 403 non ha questo obbligo; è un rifiuto più ampio e non promette che una nuova autenticazione (con le stesse credenziali o con altre) cambierà qualcosa. La versione in linguaggio semplice di MDN è: un 403 è “similar to 401, except that … authenticating or re-authenticating makes no difference. The request failure is tied to application logic, such as insufficient permissions.” (traduzione) «simile a 401, salvo che autenticarsi o autenticarsi di nuovo non cambia nulla. Il fallimento della richiesta dipende dalla logica dell’applicazione, per esempio da permessi insufficienti.» Evidence for this claim A 403 response means the server understood the request but refuses to fulfill it, and authenticating does not necessarily make a difference. Scope: RFC 9110 defines the protocol semantics; it does not identify the application, firewall, or policy responsible for a specific response. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.4 — 403 Forbidden
• 404 Not Found, per contrasto: il caso ordinario è «qui non c’è nulla», salvo il punto sul nascondere l’esistenza spiegato sopra.

Questa differenza è uno dei motivi per cui un 403 a Googlebot merita un secondo esame invece di essere considerato normale. Un 401 a un bot su una pagina riservata ai membri può essere corretto: l’area richiede un accesso. Un 403 a un bot su una pagina che dovrebbe essere pubblica significa che una regola ha deciso che il richiedente non era benvenuto; come vedremo, però, conviene comunque confermare che la pagina fosse davvero destinata al pubblico prima di chiamarlo un bug.

Come tratta Google un 403 (risultato simile a noindex, meccanismo diverso)

Google raggruppa il 403 con il resto della famiglia 4xx. La documentazione Search Central dice: “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 indicizza gli URL che restituiscono un codice di stato 4xx e rimuove dall’indice gli URL già indicizzati che restituiscono un 4xx». E aggiunge: “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 di Google informano il sistema di elaborazione successivo che il contenuto non esiste». Google nota inoltre che la frequenza di crawling di un URL noto diminuisce gradualmente più a lungo continua a restituire 4xx: è un effetto per singolo URL, distinto dal crawl rate complessivo del sito (torneremo sulla distinzione). 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 indexing outcome for persistent 403 responses, not the article's analogy to noindex. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Quindi il risultato ricorda un noindex: la pagina non entra nell’indice e, se era già presente, ne esce nel tempo. Il meccanismo, però, è davvero diverso, non solo nell’aspetto: un tag noindex deve essere recuperato e analizzato dall’HTML della pagina per avere effetto, mentre un 403 impedisce a Google di leggere qualsiasi contenuto: non esiste una pagina da elaborare. Sono due percorsi diversi che convergono nella stessa mancata presenza su Google Search. Per questo nella mia guida ai codici di stato HTTP descrivo il 403 semplicemente come “the client is known but doesn’t have access rights,” (traduzione) «il client è riconosciuto ma non ha i diritti di accesso», e noto che i 4xx fanno uscire le pagine dall’indice; «riconosciuto» è però l’abbreviazione del rapporto Google, non l’affermazione che ogni 403 coinvolga un richiedente autenticato.

Perché un 403 a Googlebot merita un’indagine (non sempre è un errore)

Questa sezione si basa sulla guida di Google sull’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. Tuttavia Googlebot non fornisce mai credenziali, quindi il server restituisce questo errore in modo errato. La pagina non verrà indicizzata». Va letto nel contesto: è una guida specifica per il rapporto su una pagina che Search Console presume tu voglia indicizzare, non un’affermazione universale che ogni 403 a Googlebot sia un bug. Googlebot non si autentica, per ciò un 403 presentato soltanto come «le tue credenziali non bastano» non si applica del tutto; ma molti 403 non riguardano affatto le credenziali e un server può legittimamente decidere che Googlebot (o chiunque altro) non debba ottenere una risorsa.

Prima di inseguire una correzione, chiediti: questa è davvero una pagina che vuoi rendere pubblica e indicizzare? Se è staging, un’area admin, un paywall o un contenuto riservato, un 403 a Googlebot è corretto e non c’è nulla da risolvere (vedi «Quando un 403 va bene»). Se è una pagina destinata al pubblico, probabilmente una regola è scattata contro il richiedente sbagliato: un WAF ha identificato il crawler come bot da bloccare, un blocco di intervallo IP ha coinvolto gli intervalli di Google o la paranoia predefinita di un plugin di sicurezza ha agito. Non ho però dati affidabili sulla frequenza reale di ciascuna causa: considera l’elenco sotto come insieme di ipotesi da verificare, non come diagnosi. Per una pagina che dovrebbe essere pubblica, Google consiglia di ammettere utenti non autenticati oppure consentire esplicitamente Googlebot senza autenticazione (dopo averne verificato l’identità, come vedremo).

Il 403 non incide sul crawl rate: non usarlo per limitare il crawling

Talvolta si usa 403 (o 404) per far rallentare Googlebot quando un server è in difficoltà. Non farlo. Google è esplicito: “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 4xx, tranne 429, non incidono sul crawl rate». Occorre però precisare l’ambito: Google dice separatamente che la frequenza di crawling di un singolo URL noto diminuisce gradualmente più a lungo resta in 4xx; è una riduzione dell’interesse per quell’URL, non un limite al crawl rate dell’intero sito. Per ottenere quest’ultimo effetto, il 403 non serve.

Gary Illyes ha scritto un intero post sul tema (Don’t 404 my yum): “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (traduzione) «Tutti i codici di stato HTTP 4xx (di nuovo, tranne 429) faranno rimuovere il tuo contenuto da Google Search». La leva d’emergenza corretta è restituire 500, 503 o 429 per una finestra breve (ore, non giorni), e nemmeno questo è un lasciapassare: Google avverte che risposte 5xx persistenti per più giorni rischiano anch’esse di far rimuovere le pagine dall’indice, quindi contano ambito e durata, non solo il codice scelto. Il resoconto di Barry Schwartz su un incidente precedente rende chiara la gravità: i siti hanno “lost load[s] of their pages from our index because they were serving them with a 403 status code instead of a 503.” (traduzione) «perso un gran numero di pagine dall’indice perché le servivano con un codice 403 invece di 503». Un 503 viene interpretato come temporaneo; un 403 ti fa uscire dall’indice.

Il caso particolare di robots.txt: un 403 è permissivo, non restrittivo

Ecco una distinzione che quasi tutti gli articoli concorrenti trascurano, e che capovolge l’intuizione. Un 403 su una pagina è un blocco rigido. Un 403 sul file robots.txt stesso, invece, viene trattato nel modo opposto. La specifica robots.txt di Google dice: “Google’s crawlers treat all 4xx errors, except 429, as if a valid robots.txt file didn’t exist. This means that Google assumes that there are no crawl restrictions.” (traduzione) «I crawler di Google trattano tutti gli errori 4xx, tranne 429, come se non esistesse un file robots.txt valido. Ciò significa che Google presume che non vi siano restrizioni di crawling». Evidence for this claim A 403 on `/robots.txt` is handled differently from a 403 on a page: Google treats a non-429 4xx robots response as if no valid robots file exists and assumes no restrictions from that file. Scope: robots.txt fetch only Confidence: high · Verified: 2026-07-16 How Google interprets the robots.txt specification

Quindi, se il firewall inizia a restituire 403 per robots.txt, Google conclude che non hai alcuna regola e scansiona liberamente, comprese le directory che volevi vietare. Nella versione colorita di Illyes: se avevi una regola che vietava la tua «biancheria sporca», ora Googlebot la conosce comunque. Non confondere «il mio robots.txt ha restituito 403» (Google ignora le regole) con «le mie pagine hanno restituito 403» (quegli URL vengono rimossi dall’indice). Gli effetti sono opposti e diagnosticare male il caso significa correggere la cosa sbagliata.

Come tratta Bing il 403

Onestamente, la documentazione pubblica di Bing sul 403 è più scarna di quella di Google, quindi restringo l’ambito invece di riempire il testo. Bingbot viene negato dagli stessi meccanismi di Googlebot: regole robots.txt, blocchi IP/user-agent a livello server e regole WAF/firewall. Bing Webmaster Tools mostra gli errori di crawling nei relativi avvisi. La conclusione pratica è la stessa per entrambi i motori: consenti il passaggio del crawler verificato attraverso il livello di sicurezza e verifica il bot tramite intervalli IP pubblicati e DNS inverso, non fidandoti di una stringa user-agent. Considera Bing come un promemoria: «correggere Googlebot» non equivale automaticamente a «correggere tutti i bot»; dopo una modifica al WAF, controlla gli strumenti di entrambi i motori.

Cause comuni (non in ordine: non ho dati di prevalenza tra i siti)

Protezione bot CDN/WAF: la causa più trascurata nei contenuti SEO esistenti. È da qui che inizierei a controllare nel 2026, anche se non posso dire quanto spesso sia la causa effettiva rispetto alle altre sotto. Bot Fight Mode e Super Bot Fight Mode di Cloudflare, le WAF Managed Rules e le regole firewall personalizzate restituiscono regolarmente 403 a Googlebot e Bingbot come danno collaterale. Il segnale è che il blocco avviene al bordo: server d’origine e CMS sembrano perfettamente puliti mentre GSC continua a mostrare 403. Controlla gli Security Events nel pannello del CDN per vedere se il crawler è stato sottoposto a una sfida o bloccato.

2. Blocchi IP o user-agent a livello server/hosting. Alcuni host bloccano per user-agent o applicano un rate limit predefinito; i blocchi di intervalli IP pensati per il traffico abusivo possono intercettare gli intervalli dei crawler.

3. Configurazione errata di robots.txt / .htaccess. Un Deny from rimasto per errore o una regola di rewrite rotta può vietare un’intera directory. (Ricorda il caso particolare di robots.txt descritto sopra.)

4. Plugin di sicurezza. Wordfence, iThemes Security e strumenti simili hanno impostazioni predefinite aggressive contro i bot, che possono colpire crawler legittimi.

5. Barriere di accesso e contenuti autenticati. Tutto ciò che è protetto dall’autenticazione restituisce 403 a un bot per progettazione: Googlebot non accede mai. Spesso questo blocco è intenzionale (vedi l’ultima sezione).

6. Errori nei permessi di file o directory. La causa classica lato amministrazione server. Su WordPress, Rank Math documenta valori ragionevoli: directory 755/750, file 644/640, wp-config.php 400/440; tra le correzioni comuni c’è «rigenerare .htaccess» dalle impostazioni dei permalink.

7. Malware o sito compromesso che inietta regole di accesso errate e 8. blocchi geografici che intercettano inavvertitamente l’intervallo IP di un crawler.

Diagnosticare un 403: isola quale livello lo emette

Molte guide saltano direttamente a «disabilita i plugin». La vera abilità è trovare quale livello rifiuta la richiesta: un semplice codice di stato 403 non lo rivela da solo. Servono header di risposta, log o un evento di sicurezza che indichi davvero CDN, WAF, applicazione, host, permessi, geografia o cache prima di chiamare in causa un colpevole. Non concludere subito «probabilmente è il WAF» senza prove. Ecco come cambia la correzione in base al livello:

1. Indicizzazione delle pagine GSC → «Bloccata per accesso vietato (403)» per vedere gli URL interessati, poi Ispezione URL → Testa URL pubblicato per la risposta live attuale.
2. Riproducilo con curl, cambiando user-agent, per confermare lo stato che il server restituisce davvero:

   # As a generic client
   curl -I https://example.com/page/
   # Spoofing Googlebot's UA (tests UA-based rules)
   curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/

   Se uno user-agent di browser normale riceve 200 ma quello di Googlebot riceve 403, hai trovato una regola basata sullo user-agent.
3. Controlla lo stato proprio di robots.txt (restituisce lui 403? È un problema diverso: vedi sopra).
4. Esamina gli Security Events del CDN/WAF per verificare se il crawler è stato sottoposto a una sfida o bloccato.
5. Verifica che il crawler sia davvero Googlebot tramite DNS inverso e diretto, non tramite la stringa UA (che è facile da falsificare).
6. Isola il problema disabilitando per fasi: una regola WAF o un plugin alla volta, finché il 403 non scompare.

Correggerlo: autorizza i bot nel modo giusto

La correzione tentatrice è autorizzare la stringa user-agent di Googlebot. Non fermarti lì: le stringhe UA sono facili da falsificare, quindi autorizzare solo in base allo UA crea una falla di sicurezza e lascia passare qualunque scraper che dichiari di essere Googlebot. Verifica così:

• Conferma i bot tramite DNS inverso + DNS diretto oppure confrontandoli con gli intervalli IP pubblicati da Google/Bing.
• La maggior parte dei CDN/WAF offre una categoria «verified bots» che esegue questa verifica: preferiscila a una regola di autorizzazione UA grezza.
• Correggi la regola specifica (una regola gestita WAF, una regola firewall o un’impostazione di un plugin) invece di disattivare tutta la sicurezza.
• Poi usa Convalida correzione nel rapporto Indicizzazione delle pagine di GSC e, se è urgente, richiedi una nuova indicizzazione tramite Ispezione URL.

Quando un 403 va bene: non «correggere» questi casi

Non ogni 403 è un bug. Un 403 è corretto e intenzionale per siti di staging, aree admin, sezioni private per membri e contenuti a pagamento/riservati che non hai mai voluto indicizzare. In un audit Ahrefs o Screaming Frog, un 403 su queste risorse non è un problema: la correzione serve solo quando una pagina destinata a essere pubblica e indicizzabile viene bloccata per errore. Non «risolvere» automaticamente ogni 403 segnalato da un audit; prima conferma che la pagina debba davvero entrare nell’indice.

Per la famiglia più ampia, le differenze tra 4xx e 5xx e il posto del 403 al suo interno, consulta la mia guida ai codici di stato HTTP e al loro impatto SEO e gli approfondimenti fratelli 401 Unauthorized e 404 Not Found di questo cluster.

Riepilogo AI

Una sintesi della versione Advanced:

• 403 = «compreso, ma rifiutato». Per RFC 9110, il rifiuto non deve dipendere dalle credenziali e il server può persino inviare 404 per nascondere l’esistenza della risorsa vietata. È diverso da 404 (di solito la risorsa non esiste) e 401 (una sfida di autenticazione specifica che richiede l’header WWW-Authenticate): riautenticarsi non risolve in modo affidabile un 403.
• Il risultato di indicizzazione ricorda noindex, ma il meccanismo è diverso. Un tag noindex deve essere recuperato e letto; un 403 impedisce a Google di leggere qualsiasi contenuto. In entrambi i casi la pagina non appare su Search, ma per percorsi diversi.
• Un 403 a Googlebot merita un’indagine, non è automaticamente un errore. Prima verifica che la pagina debba essere pubblica. Se sì, la causa probabile è una regola scattata male (WAF, blocco IP, plugin di sicurezza), ma non ci sono dati affidabili sulla causa più frequente: considera le cause una lista di controllo, non una graduatoria.
• Il 403 non incide sul crawl rate del sito. La frequenza di crawling di un URL noto cala gradualmente quanto più a lungo resta in 4xxs, ma non equivale a rallentare l’intero sito. Non usare mai 401/403 per limitare Googlebot; usa 429/503/500 per una finestra breve, sapendo che anche questi possono causare deindicizzazione se restano attivi troppo a lungo.
• Caso particolare di robots.txt (effetto opposto): un 403 su una pagina è un blocco rigido; un 403 sul file robots.txt è trattato come permissivo: Google presume che non esistano regole di crawling.
• Diagnostica basata sulle prove, non sulle ipotesi. Un 403 isolato non identifica la fonte: conferma con header di risposta, log o eventi di sicurezza CDN prima di accusare un livello. Indicizzazione GSC + Testa URL pubblicato → curl con/senza UA Googlebot → Security Events CDN → verifica bot tramite DNS/IP, non UA → disabilita per fasi.
• Correzione: autorizza bot verificati (DNS/IP o categoria CDN «verified bots»), non la stringa UA grezza. Poi usa Convalida correzione in GSC.
• Alcuni 403 sono corretti: staging, admin, membri, contenuti a pagamento; non «correggerli». Controlla l’intento prima di presumere un bug.

Documentazione ufficiale

Documentazione primaria su come vengono trattati il 403 e la famiglia 4xx.

Protocollo

• RFC 9110 §15.5.4: 403 Forbidden — la specifica HTTP di base: il rifiuto non deve dipendere dalle credenziali e un’origine può inviare 404 per nascondere una risorsa vietata.

Google

• Come i codici di stato HTTP influenzano i crawler di Google — la dichiarazione definitiva: gli URL 4xx (tranne 429) vengono rimossi dall’indice e non incidono sul crawl rate.
• Rapporto Indicizzazione delle pagine — Guida Search Console — lo stato «Bloccata per accesso vietato (403)» e la spiegazione «Googlebot non fornisce mai credenziali».
• Non usare 403 o 404 per limitare il rate — Gary Illyes, febbraio 2023, spiega perché i codici 4xx sono lo strumento sbagliato per rallentare il crawling.
• Ridurre il crawl rate di Google — l’approccio corretto: restituire brevemente 500/503/429, non 403/404.
• Come interpreta Google la specifica robots.txt — la sfumatura per cui un 4xx su robots.txt viene trattato come assenza di restrizioni.
• Verificare Googlebot — DNS inverso e intervalli IP pubblicati, per autorizzare i bot nel modo corretto.

Bing / Microsoft

• Elenco degli avvisi sugli errori di crawling — Bing Webmaster Tools — le categorie di errori di crawling di Bing.

CDN/WAF

• Rilevamento di bot falsi che blocca richieste legittime — la documentazione Cloudflare mostra come le regole gestite contro i bot falsi possano produrre blocchi errati; è utile per confermare, non presumere, che il livello emittente sia una regola WAF.

Riferimento web generale

• MDN — 403 Forbidden — la definizione autorevole di base e la distinzione chiara tra 401 e 403.

Citazioni dalla fonte

Dichiarazioni pubbliche. Ogni link porta direttamente al passaggio citato nella pagina fonte.

Google: come vengono trattati 4xx e 403

• “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: non indicizza gli URL che restituiscono 4xx e rimuove dall’indice quelli già indicizzati che restituiscono 4xx». — Documentazione 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, vengono trattati allo stesso modo: i crawler di Google informano il sistema di elaborazione successivo che il contenuto non esiste». Vai alla citazione
• “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 401 e 403 per limitare il crawl rate: i codici 4xx, salvo 429, non modificano la frequenza di crawling». Vai alla citazione

Google: «Googlebot non si autentica mai»

• “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) «lo user agent ha fornito credenziali ma non ha ottenuto l’accesso; Googlebot non invia credenziali, quindi il server restituisce questo errore in modo improprio e la pagina non entrerà nell’indice». — Guida Search Console, «Bloccata per accesso vietato (403)». Vai alla citazione

Gary Illyes, Google: non limitare il rate con i 4xx

• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search. What’s worse, if you also serve your robots.txt file with a 4xx HTTP status code, it will be treated as if it didn’t exist.” (traduzione) «i codici HTTP 4xx, salvo 429, fanno rimuovere il contenuto da Google Search; se anche robots.txt restituisce 4xx, viene considerato inesistente». — Blog Google Search Central, febbraio 2023. Vai alla citazione
• “Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (traduzione) «Restituisci a Googlebot un codice di stato HTTP 500, 503 o 429 quando esegue il crawling troppo velocemente». Vai alla citazione

Google: il capovolgimento del 403 su robots.txt

• “Google’s crawlers treat all 4xx errors, except 429, as if a valid robots.txt file didn’t exist. This means that Google assumes that there are no crawl restrictions.” (traduzione) «I crawler di Google trattano tutti gli errori 4xx, tranne 429, come se non esistesse un robots.txt valido. Google presume quindi che non vi siano restrizioni di crawling». — Come interpreta Google la specifica robots.txt. Vai alla citazione

MDN: definizione generale e distinzione tra 401 e 403

• “The HTTP 403 Forbidden client error response status code indicates that the server understood the request but refused to process it. This status is similar to 401, except that for 403 Forbidden responses, authenticating or re-authenticating makes no difference.” (traduzione) «Il codice di stato della risposta di errore client HTTP 403 Forbidden indica che il server ha compreso la richiesta ma ha rifiutato di elaborarla. Questo stato è simile a 401, salvo che, per le risposte 403 Forbidden, autenticarsi o riautenticarsi non cambia nulla». — MDN Web Docs. Vai alla citazione

Barry Schwartz, Search Engine Roundtable: gravità del 403 rispetto al 503 Resoconto indiretto di una dichiarazione Google, non pagina Google di prima parte; inoltre l’URL fonte stesso restituisce 403 ai fetcher automatici (un’ironia in tema): verifica in un browser prima di considerarlo definitivo.

• Riportando l’avvertimento di Google: i siti hanno “lost load[s] of their pages from our index because they were serving them with a 403 status code instead of a 503.” (traduzione) «perso un gran numero di pagine dall’indice perché le servivano con un codice 403 invece di 503». Leggi la copertura

Diagnosticare un 403: albero decisionale

Parti da ciò che riceve davvero Googlebot, poi restringi il livello responsabile.

Q1. Il 403 riguarda una pagina che vuoi indicizzare?

• No (staging, admin, solo membri, paywall) → probabilmente è corretto. Lascialo così. Fermati qui.
• Sì → continua.

Q2. È la pagina a restituire 403 o robots.txt?

• robots.txt restituisce 403 → problema diverso: Google ora ignora tutte le regole di crawling (tratta robots.txt come assente). Correggi robots.txt perché restituisca 200; il 403 della pagina potrebbe essere un problema separato.
• La pagina restituisce 403 → continua.

Q3. curl lo riproduce e dipende dallo user-agent?

curl -I https://example.com/page/
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/

• UA browser = 200, UA Googlebot = 403 → una regola user-agent blocca il bot (WAF, configurazione server o plugin). Vai a Q4.
• Entrambi = 403 → è un blocco più ampio (intervallo IP, permessi directory, Deny in .htaccess). Controlla configurazione server e permessi dei file.
• Entrambi = 200 ma GSC mostra ancora 403 → il blocco è probabilmente lato edge/CDN e dipende da IP o stato di bot verificato. Vai a Q4 e controlla gli Security Events del CDN.

Q4. Sei dietro un CDN/WAF (Cloudflare ecc.)?

• Sì → controlla gli Security Events per vedere se il crawler è stato sottoposto a una sfida o bloccato. Sospetta Bot Fight Mode / Super Bot Fight Mode, WAF Managed Rules o una regola firewall personalizzata. Consenti i bot di ricerca verificati, non un UA grezzo.
• No → controlla i blocchi IP/UA a livello server, poi i plugin di sicurezza (Wordfence ecc.) e infine .htaccess e permessi dei file.

Q5. Hai corretto la regola?

• Autorizza in base a bot verificato / DNS / intervallo IP, mai alla sola stringa UA → Convalida correzione in Indicizzazione delle pagine GSC → se è urgente, richiedi una nuova indicizzazione tramite Ispezione URL.

Anti-pattern: errori 403 che vedo continuamente

Usare 403 (o 404) per rallentare Googlebot. Il mito dice che restituire 403 limiti il crawling. Non è così: i 4xx (tranne 429) non incidono sul crawl rate e invece deindicizzano le pagine a cui hai restituito 403. Se devi rallentare il crawling, restituisci 429, 503 o 500 per una finestra breve (da ore a uno o due giorni) oppure usa il rapporto sul crawl rate di Search Console. Il 403 non è mai lo strumento di controllo del crawling, nemmeno temporaneamente.

Trattare un 403 esattamente come un 404 in un audit. Entrambi fanno uscire l’URL dall’indice nel tempo, quindi è facile metterli nello stesso gruppo. Ma un 404 di solito significa «scomparso», mentre un 403 significa «l’accesso è stato rifiutato attivamente»: talvolta per una configurazione errata correggibile, talvolta per un blocco intenzionale. Unificarli nasconde il problema reale in entrambi i casi. Diagnostica causa e intento, non solo il risultato.

Supporre che Googlebot abbia «fatto qualcosa di sospetto» per meritare il blocco. Googlebot non invia credenziali, quindi un 403 presentato come «credenziali errate» non si applica davvero. Questo non significa che ogni blocco sia un bug: prima conferma che la pagina fosse destinata al pubblico. Se lo era, non razionalizzare il blocco come qualcosa provocato da Googlebot; trova invece la regola scattata (WAF, blocco IP, plugin).

Autorizzare usando soltanto la stringa user-agent. Gli UA sono facilissimi da falsificare, quindi una regola allow if UA contains "Googlebot" fa passare direttamente la sicurezza a ogni scraper che finge di essere Google. Verifica tramite DNS inverso + diretto o intervalli IP pubblicati, oppure usa la categoria verified-bots del CDN.

Confondere un 403 su robots.txt con un 403 sulle pagine. Gli effetti sono opposti. Un 403 su una pagina è un blocco rigido che la deindicizza. Un 403 su robots.txt fa presumere a Google che tu non abbia alcuna regola di crawling, quindi può scansionare percorsi che volevi vietare. Diagnostica quale dei due stai davvero vedendo prima di correggere qualsiasi cosa.

«Correggere» 403 intenzionali. Siti di staging, aree admin, contenuti solo per membri e contenuti a pagamento devono restituire 403 ai crawler. Risolvere d’impulso ogni 403 in un audit può esporre risorse che non hai mai voluto indicizzare. Prima conferma che la pagina debba essere pubblica.

Il framework di intento, ambito e livello emittente

Un audit 403 diventa più rapido quando rispondo a tre domande in ordine:

1. Intento: la risorsa deve essere pubblica? Lascia intatto un blocco deliberato di un’area privata. Considera un 403 su una pagina indicizzabile un incidente.
2. Ambito: il problema riguarda un URL, una directory, uno user-agent, una zona geografica o ogni richiesta? Il confine di solito identifica la regola responsabile più rapidamente che cambiare plugin a caso.
3. Livello emittente: confronta l’evento CDN/WAF, il log di accesso dell’origine, il log dell’applicazione e gli header di risposta. Cambia il primo livello che emette davvero il 403, non ogni livello che potrebbe farlo.

Dopo la correzione, verifica separatamente l’accesso anonimo e quello del crawler verificato. Uno user-agent dichiarato Googlebot è utile per riprodurre una regola UA, ma non prova l’identità del crawler.

Prompt: isola un 403 per livello

Diagnose this HTTP 403 using only the evidence I paste. Classify the likely issuing
layer as CDN/WAF, web server, application/security plugin, filesystem permissions,
or intentional access control. Compare generic and claimed-bot responses, identify
which observation supports each conclusion, and give the smallest safe change plus
an anonymous curl test and Search Console validation. Do not recommend disabling all
security or trusting a user-agent string as identity.

[PASTE SANITIZED HEADERS, CURL OUTPUT, SECURITY EVENT, AND LOG LINES]

Prompt: esamina un’eccezione WAF

Review this WAF rule intended to stop 403s for legitimate search crawlers. Check its
scope, whether crawler identity is verified, what non-crawler traffic it could admit,
and whether robots.txt behaves differently from page URLs. Return a least-privilege
rewrite, test cases, and rollback conditions. Do not invent provider syntax.

[PASTE RULE AND PROVIDER]

Strumenti per diagnosticare risposte 403

• Bulk HTTP Status Code Checker: scopri se il blocco è isolato o riguarda un modello di URL, senza portare con te la sessione di accesso.
• HTTP Header Checker: esamina fingerprint CDN, ID richiesta e header di sicurezza che aiutano a identificare il livello emittente.
• Verificatore Googlebot: valida le prove IP prima di consentire il passaggio a un crawler; non considerare mai lo user-agent da solo una prova.
• Indicizzazione delle pagine e Ispezione URL di Search Console: ottieni l’insieme segnalato, testa live la risposta corrente e valida dopo la correzione.
• Eventi di sicurezza CDN/WAF e log dell’origine: se l’edge registra un blocco e l’origine non registra alcuna richiesta, la correzione appartiene all’edge.

Mettiti alla prova: 403 Vietato

Cinque domande rapide sul significato di 403 e su come gestirlo. Scegli una risposta per ciascuna e poi controlla.

Risorse che vale la pena leggere

I miei articoli correlati

• Codici di stato HTTP e il loro impatto SEO — la panoramica completa di 4xx/5xx, il posto del 403 tra i codici e il meccanismo per cui i 4xx fanno uscire le pagine dall’indice.
• La guida per principianti alla SEO tecnica — dove si collocano nel quadro generale i problemi di accesso al crawling e all’indice come i 403.
• Robots.txt e SEO: tutto ciò che devi sapere — per la sfumatura del 403 su robots.txt e il funzionamento effettivo dei controlli di crawling.

I miei interventi

• Come funziona la ricerca (SlideShare) — il percorso crawl → render → index → serve; un 403 è un fallimento al primo cancello. (Avvertenza permanente: «Questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%».)

Dall’industria

• Non usare 403 o 404 per limitare il rate (Google Search Central Blog) — Gary Illyes spiega perché i 4xx sono lo strumento sbagliato per rallentare il crawling.
• Ridurre il crawl rate di Google (Google Search Central) — l’approccio corretto 500/503/429, per confronto.
• Google avverte sull’uso improprio dei codici 403 (Search Engine Roundtable) — l’aneddoto sulla gravità 403 rispetto a 503 (verifica in un browser; la pagina restituisce 403 ai bot).
• Google: non usare risposte 403/404 per limitare il rate di Googlebot (Search Engine Journal) — resoconto della guida del 2023.
• Come correggere «Bloccata per accesso vietato (403)» in Google Search Console (SEOTesting) — struttura solida di cause e correzioni, compresa la domanda «devi correggere ogni 403?».
• Come correggere l’errore «Bloccata per accesso vietato (403)» (Rank Math) — valori chmod concreti per WordPress e flusso Health Check.
• Codici di stato HTTP: perché il mio sito non viene scansionato? (Screaming Frog) — diagnosi dal lato crawler (cambio UA, rendering JS, autorizzazione IP/UA).

Cronologia modifiche