Errori 401 e 403 in Search Console: quando Google non può accedere alle pagine

Distingui il requisito di accesso dal rifiuto della richiesta

Un codice 401 segnala che la richiesta non dispone dell’autenticazione necessaria. Può comparire, per esempio, quando una protezione con credenziali è rimasta davanti a pagine destinate al pubblico. Il 403 comunica invece che l’accesso è negato: la causa va cercata nella configurazione che ha deciso di respingere quella richiesta.

La documentazione sui codici HTTP spiega che Google non indicizza le pagine che restituiscono questi errori; quelle già presenti possono uscire dall’indice nel tempo. Il codice non identifica da solo il componente da correggere.

Non usare 401 o 403 per limitare la scansione: gli eventuali problemi di carico del server richiedono il percorso pertinente.

Separa le pagine da trovare su Google dalle aree riservate

Prima di intervenire, assegna a ogni URL un obiettivo. Una pagina che descrive un servizio dovrebbe essere leggibile dal nuovo cliente. Il pannello ordini personale, le fatture e l’amministrazione del sito devono invece mantenere i controlli di accesso previsti.

Prepara tre esempi: una pagina pubblica segnalata, una pagina pubblica funzionante e un’area che deve restare privata. Questa distinzione diventa anche il criterio con cui verificare la correzione.

Il file robots.txt gestisce la scansione e non costituisce una protezione dei dati riservati. Non sostituire quindi una vera autenticazione con una regola per i crawler. Se Google ha trovato un indirizzo privato, la priorità è conservare la riservatezza e verificare perché quell’URL venga collegato dal sito, non renderlo pubblico per eliminare un avviso.

Prova la pagina senza la tua sessione di accesso

Apri l’URL esatto in una finestra privata del browser, senza entrare nel pannello del sito. Controlla se appare il contenuto previsto, una richiesta di password oppure una schermata che impedisce di proseguire. Annota anche l’eventuale cambio di indirizzo.

Il confronto è utile perché il tuo browser abituale può conservare una sessione autorizzata. Una pagina visibile dopo il login non dimostra che la stessa risposta venga inviata ai nuovi visitatori.

Se in ufficio la pagina si apre e fuori compare un rifiuto, chiedi al tecnico di verificare eventuali regole legate alla rete. È un indizio da approfondire, non una diagnosi.

Confronta la segnalazione con il test attuale di Search Console

Nel report Indicizzazione delle pagine apri il gruppo degli URL bloccati e scegli un campione. Per ogni indirizzo controlla le informazioni dell’ultima scansione e avvia il test dell’URL pubblicato attraverso Controllo URL.

Conserva entrambi gli esiti: il report può descrivere un blocco passato mentre la prova attuale riesce, oppure mostrare che il problema è ancora presente. Registra l’ora del test per permettere il confronto con i registri tecnici.

Quando il recupero riesce, verifica anche la pagina effettivamente restituita. Un codice 200 accompagnato da una schermata di accesso non equivale alla disponibilità del servizio descritto. Se Google riesce a leggere i contenuti ma l’URL resta escluso, approfondisci separatamente lo stato di indicizzazione del sito.

Fai individuare il componente che applica il blocco

Invia a chi gestisce il sito URL, codice rilevato, orario e differenze tra le prove. Chiedi di ricostruire quale componente abbia generato la risposta: applicazione, server, protezione dell’hosting o servizio intermedio.

• È rimasta una protezione introdotta durante lo sviluppo?
• Una cartella pubblica eredita permessi destinati a un’area privata?
• Un aggiornamento ha cambiato le regole di accesso?
• La richiesta viene respinta prima di raggiungere il sito?

Queste sono piste da verificare, non cause deducibili dal solo messaggio. Un utile riscontro tecnico identifica la regola coinvolta e l’insieme delle pagine interessate. “È il firewall” è ancora troppo generico: occorre capire quale criterio produca il rifiuto e quale modifica consenta l’accesso previsto senza coinvolgere altri percorsi.

Correggi la regola e verifica l’origine delle richieste Google

La soluzione deve riguardare il percorso pubblico e la regola responsabile. Disattivare tutte le protezioni dell’hosting o rendere leggibile l’intera amministrazione non è necessario per pubblicare una pagina servizi.

Se il fornitore deve riconoscere richieste provenienti da Google, usa i metodi della documentazione ufficiale di verifica dei crawler. Il nome Googlebot dichiarato nella richiesta non basta a provarne l’origine. Il controllo deve considerare anche il tipo di crawler o strumento coinvolto nella prova.

Chiedi un cambiamento circoscritto e annotato: quale regola viene corretta, per quali URL e con quale verifica successiva. I contenuti resi accessibili ai motori devono corrispondere a quelli che l’attività intende offrire ai visitatori, senza esporre dati riservati durante il controllo.

Verifica pagine pubbliche e aree protette dopo l’intervento

Ripeti il campione iniziale: pagina segnalata, pagina di confronto e area riservata. Le prime devono mostrare il contenuto previsto nelle condizioni di accesso pubblico; l’ultima deve continuare a richiedere l’autorizzazione corretta.

Ripeti il test in Search Console e conserva l’esito. Se il report propone la convalida, avviala dopo avere corretto la causa del gruppo interessato. Non occorre trasformare una serie di URL privati in pagine indicizzabili per ottenere un report senza esclusioni.

I dati sulle scansioni precedenti non si riscrivono immediatamente. Segui i controlli successivi e verifica che il blocco non ritorni dopo aggiornamenti o manutenzioni. La correzione permette di recuperare la pagina: la sua indicizzazione e visibilità dipendono anche dagli altri requisiti del sito.