Errori di scansione: cosa sono e come risolverli

Un errore di scansione è quello che succede quando Googlebot (o un altro crawler) prova a raggiungere una tua pagina e non ci riesce, oppure riceve una risposta che gli impedisce di leggerla. Non è la stessa cosa di un problema di indicizzazione: una pagina può essere scansionata perfettamente e restare comunque fuori dall'indice per motivi che non c'entrano nulla con l'accesso, come contenuto duplicato, un tag noindex o una qualità percepita troppo bassa. L'errore di scansione riguarda invece il primo passaggio del processo: il crawler bussa alla porta e nessuno risponde, oppure risponde male.

In questa guida vediamo dove trovare questi errori senza indovinare, quali classi contano davvero e quali sono solo rumore di fondo del normale ciclo di vita di un sito, come diagnosticarli uno per uno con il fix corretto, e come costruire un ordine di priorità quando la lista è lunga invece di inseguire lo zero assoluto.

Errore di scansione o problema di indicizzazione: la differenza che conta

Il percorso di una pagina verso i risultati di ricerca ha tappe distinte: prima il crawler deve raggiungerla e scaricarla (scansione), poi Google la elabora e decide se e come inserirla nel proprio indice (indicizzazione). Un errore di scansione blocca la prima tappa: il crawler non ottiene una risposta utilizzabile, quindi non ha nemmeno materiale da valutare per l'indicizzazione.

Una pagina che risponde 200 OK, viene scaricata correttamente e poi finisce comunque etichettata come "Sottoposta a scansione, attualmente non indicizzata" non ha un errore di scansione: ha superato quella fase senza problemi ed è stata esclusa dopo, per una valutazione editoriale o tecnica successiva. Confondere le due cose porta a cercare la causa sbagliata: se il rapporto dice che la pagina è stata letta, correggere robots.txt o il server non serve a nulla.

Dove si vedono gli errori di scansione

Ci sono due fonti principali, e raccontano storie leggermente diverse. Search Console mostra una versione aggregata e campionata, comoda per farsi un'idea generale; i log del server mostrano ogni singola richiesta del crawler, ed è l'unica fonte davvero completa.

• Rapporto sull'indicizzazione delle pagine (in Search Console): elenca gli URL non indicizzati con un motivo specifico per ciascuno, compresi errori server, errori 404, redirect e blocchi da robots.txt.
• Statistiche di scansione (Impostazioni > Statistiche di scansione): mostra l'andamento delle richieste nel tempo, la distribuzione per codice di risposta, per tipo di file e per host, ed è il primo posto dove si nota un picco anomalo di errori server o problemi di connessione.
• Log del server: il registro grezzo di ogni richiesta in arrivo, filtrabile per user agent del crawler. È l'unica fonte in tempo reale e non campionata, utile per capire esattamente cosa ha visto il crawler in un dato momento, incluso il tempo di risposta.

Errori del server (5xx)

Un errore 5xx significa che il crawler ha raggiunto il server, ma il server ha risposto con un fallimento: 500 (errore generico), 502 e 504 (problemi a monte, spesso con un servizio o database), 503 (servizio non disponibile, spesso durante manutenzione o sovraccarico). È l'errore più serio della lista, perché se persiste su molte pagine Google inizia a rallentare la frequenza di scansione dell'intero sito, non solo delle pagine coinvolte.

Per diagnosticarlo, incrocia l'orario esatto degli errori nei log del server con lo storico dei deploy, i grafici di utilizzo di CPU e memoria dell'hosting e i log del firewall o del plugin di sicurezza: capita più spesso di quanto si pensi che un WAF blocchi per errore lo user agent di Googlebot scambiandolo per traffico sospetto.

Se la causa è un sovraccarico o un bug introdotto in un deploy, la correzione è tecnica e va alla radice: aumentare le risorse, ottimizzare una query lenta, correggere il codice. Se è manutenzione programmata, la risposta corretta non è un errore casuale ma un vero 503 con intestazione Retry-After, così il crawler sa che deve ripassare più tardi invece di considerare la pagina persa.

• Urgente: errori 5xx diffusi su molte pagine o che durano più di qualche ora.
• Rumore normale: un picco isolato durante una finestra di deploy che si risolve da solo in pochi minuti.

Pagine non trovate (404): quando è un problema e quando no

Un 404 dice semplicemente che quell'URL non esiste più. Non è di per sé un errore da correggere: un prodotto esaurito rimosso, un'offerta scaduta, un vecchio articolo del blog eliminato consapevolmente producono un 404 legittimo, ed è il comportamento corretto. Cercare di azzerare tutti i 404 di un sito che ha anni di storia è tempo sprecato.

Il 404 diventa un problema quando riguarda un URL che vale ancora qualcosa: pagine con backlink esterni che puntano lì (equity persa), pagine ancora linkate internamente dal menu o da altri articoli (link rotti, budget di scansione sprecato su un vicolo cieco), oppure URL che generavano impressioni e clic prima della rimozione. È anche un problema quando un 404 di massa compare all'improvviso su centinaia di URL insieme: quello quasi sempre segnala un errore di migrazione, di configurazione dello slash finale o di sensibilità alle maiuscole nel routing, non una rimozione volontaria.

• Verifica le impressioni storiche della pagina nel rapporto prestazioni di Search Console prima di decidere se vale la pena intervenire.
• Controlla chi linka ancora quell'URL, sia da fonti esterne sia dal rapporto Link di Search Console.
• Se il contenuto è stato spostato, usa un redirect 301 verso l'equivalente reale; se è sparito senza sostituto, lascialo rispondere 404 (o 410 se vuoi segnalare esplicitamente che è rimosso in modo permanente) e rimuovi i link interni che ancora puntano lì.

Redirect: catene e loop

Una catena di redirect è una sequenza A verso B verso C verso D prima di arrivare alla pagina finale; un loop è un caso degenere in cui A rimanda a B che rimanda di nuovo ad A, senza che il crawler raggiunga mai un contenuto reale. Le catene nascono quasi sempre da migrazioni sovrapposte nel tempo senza pulizia: ogni cambio di URL aggiunge un salto sopra i precedenti invece di sostituirli. I loop nascono spesso da regole che si scontrano, tipo una redirezione manuale http-to-https che convive con una regola automatica del CMS per lo slash finale, ognuna delle quali rimanda indietro all'altra.

Ogni salto costa budget di scansione e tempo, e oltre un certo numero di redirect concatenati il crawler può interrompere il tentativo prima di arrivare alla destinazione finale: in quel caso, agli occhi di Google, la pagina di destinazione semplicemente non è stata raggiunta. Per diagnosticare, traccia il percorso salto per salto con uno strumento di controllo redirect o con una richiesta manuale che segua le intestazioni Location una per una; un loop si riconosce perché l'URL di partenza ricompare nella sequenza.

• Correggi ogni redirect perché punti direttamente alla destinazione finale, in un solo salto, invece di lasciare la catena intatta.
• Per i loop, trova la regola specifica (spesso a livello di configurazione del server o di plugin) che fa ripuntare l'URL su se stesso ed elimina la ridondanza.

Bloccato da robots.txt

Quando robots.txt contiene una regola Disallow per un percorso, il crawler la rispetta e non prova nemmeno a scaricare quelle pagine: non è un errore del server, è un divieto esplicito che il crawler segue. Search Console lo segnala come pagina bloccata, non come pagina non raggiungibile.

La causa più comune è una regola troppo ampia dimenticata dopo un test, una configurazione predefinita del CMS che blocca intere sezioni per prudenza, oppure un blocco su una cartella che contiene, oltre a pagine irrilevanti, anche i file CSS o JavaScript necessari per il rendering delle pagine importanti: se Google non può scaricare quelle risorse, può interpretare male il layout o il contenuto reale della pagina.

Per verificare, apri direttamente il file all'indirizzo del tuo sito seguito da /robots.txt e testa l'URL specifico con lo strumento di ispezione URL di Search Console, che applica le regole live e dice chiaramente se un percorso è bloccato. La correzione è restringere o rimuovere la regola Disallow per tutto ciò che vuoi effettivamente scansionato, prestando particolare attenzione a non bloccare mai le risorse necessarie al rendering.

DNS, problemi di connessione e soft 404

I fallimenti DNS e di connessione sono la categoria più grave, perché il crawler non riesce nemmeno a stabilire un contatto con il server: dominio non risolto, certificato scaduto, nameserver momentaneamente irraggiungibili o hosting fermo. Nelle Statistiche di scansione compaiono come uno stato host degradato o come un picco di richieste senza risposta. Se il problema è in corso proprio ora, la priorità è massima: un sito irraggiungibile per il crawler può nel tempo scomparire dai risultati, non solo perdere posizioni. Vale la pena controllare regolarmente la scadenza del certificato SSL e lo stato di propagazione DNS con uno strumento esterno, non solo dal proprio browser che potrebbe avere la cache locale.

Il soft 404 è un caso diverso e più insidioso: la pagina risponde 200 OK, quindi tecnicamente ha successo, ma il contenuto dice in pratica "non c'è niente qui", per esempio un prodotto segnato come non disponibile senza alternative, una pagina categoria vuota o un messaggio d'errore mostrato dentro un layout normale. Google tratta questi casi come se fossero 404 reali, anche se il codice di stato non lo dice. Si trovano cercando l'etichetta specifica "Soft 404" nel rapporto sull'indicizzazione delle pagine; la correzione è restituire davvero un codice 404 o 410 se il contenuto non esiste più, oppure ripopolare la pagina con contenuto sostanziale se dovrebbe esistere.

Come dare priorità a una lista lunga (e come verificare che la correzione abbia funzionato)

Con un sito che ha qualche anno, la lista di errori nel rapporto di indicizzazione non arriverà mai a zero, e non deve: l'obiettivo realistico è che ogni voce sia lì per un motivo accettabile, non che la lista sia vuota. Prima di aprire la prima pagina della lista, ordina per impatto reale invece che per ordine di apparizione.

Dopo aver applicato una correzione, non fermarti al "sembra giusto": verifica sulla pagina reale con lo strumento di ispezione URL, che mostra il codice di stato live e segnala eventuali problemi nel caricamento delle risorse. Per un fix su singola pagina, richiedi da lì una nuova scansione. Per un fix diffuso su molte pagine, il conteggio degli errori nel rapporto di indicizzazione e nelle Statistiche di scansione scenderà gradualmente nei giorni successivi, non in un click: Google ripassa sulle pagine secondo i propri tempi. Tenere un registro con la data di ogni correzione applicata aiuta a distinguere un calo dovuto al fix da una coincidenza temporale con qualcos'altro.

• Prima i pattern sistemici: un errore che coinvolge un intero template o un'intera cartella batte una singola pagina isolata, anche se quella singola pagina compariva per prima nell'elenco.
• Poi il valore storico dell'URL: usa impressioni e clic passati, oppure i backlink in ingresso, per decidere se vale la pena investire tempo prima di agire.
• 5xx diffusi e fallimenti DNS restano sempre la priorità più alta, perché minacciano la scansione dell'intero sito, non solo delle pagine coinvolte.
• 404 isolati su contenuti rimossi volontariamente e senza link né traffico storico residuo: priorità bassa o nessuna azione, sono normali.