Google Search Console: leggere e correggere gli errori di scansione

Perché gli errori di scansione contano davvero

Quando Google non riesce a scansionare una pagina, il problema non è solo “tecnico”: quella URL può smettere di aggiornarsi nell’indice, perdere visibilità o essere interpretata in modo incompleto. In pratica, un errore di scansione può bloccare la crescita organica di una sezione intera del sito, anche se il contenuto è buono e il server sembra funzionare.

La parte utile di Google Search Console non è il numero dell’errore, ma il tipo di blocco che segnala. Un 404, un 5xx, un problema DNS, un redirect errato o un timeout non si correggono allo stesso modo. Il principio giusto è semplice: prima capire chi sta fallendo, poi correggere il punto esatto della catena — DNS, web server, CMS, plugin, rete o contenuto.

Come leggere gli errori di scansione senza confondersi

In Search Console, gli errori non vanno letti come “pagina rotta” in senso generico. Vanno invece interpretati come un sintomo. Se Google segnala un problema, devi chiederti: la pagina è davvero irraggiungibile, risponde troppo lentamente, restituisce un codice sbagliato, oppure è stata bloccata da regole di accesso?

Le categorie più comuni sono queste:

• Errore server (5xx): il server ha risposto male o non ha risposto affatto.
• Errore di reindirizzamento: il percorso dei redirect è rotto o troppo lungo.
• URL non trovata (404): la pagina non esiste più o il link è errato.
• Bloccata da robots.txt: Google non può accedere alla risorsa.
• Problemi DNS: il dominio non risolve correttamente.
• Soft 404: la pagina sembra vuota o inutile, anche se restituisce un 200.

Il punto chiave è distinguere tra errore reale del server e scelta intenzionale. Un 404 su una pagina rimossa può essere corretto. Un 404 su una pagina che dovrebbe esistere è invece un guasto da risolvere subito.

Diagnosi pratica: da dove partire

Prima di toccare il sito, conviene raccogliere tre informazioni: l’URL esatta, il tipo di errore e il momento in cui è apparso. Senza questi elementi si rischia di intervenire nel punto sbagliato. L’obiettivo è capire se il problema è limitato a una singola pagina o riguarda una sezione, un template, un plugin, un DNS o l’intero hosting.

Un controllo rapido utile è aprire l’URL in navigazione anonima e verificare se il comportamento è coerente con quanto segnala Search Console. Se la pagina si apre dal browser ma Google la vede come errore, il sospetto si sposta su blocchi per user-agent, firewall, rate limit, CDN o differenze tra HTTP e HTTPS.

Se invece la pagina non si apre nemmeno dal browser, il problema è più concreto: il server non serve correttamente la risorsa, il CMS genera un errore, oppure la rotta è stata rimossa o spostata.

Le cause più frequenti e il modo giusto di intervenire

1) Errori 404 e contenuti rimossi

Il caso più comune è la pagina eliminata o spostata senza redirect. Se l’URL non deve più esistere, il 404 è corretto e non va “riparato”. Se invece la pagina è stata spostata, va creato un redirect 301 verso la nuova destinazione, evitando catene di redirect e loop.

La verifica migliore è controllare se esistono link interni ancora puntati all’URL vecchio. Se ci sono, vanno aggiornati. Un redirect è utile, ma non deve sostituire una pulizia dei link interni.

2) Errori 5xx e instabilità del server

Gli errori 5xx indicano che il server non sta completando la richiesta. Le cause tipiche sono PHP in crash, memory limit insufficiente, query lente, plugin problematici, timeout del web server o saturazione di CPU/RAM/I/O. In questo caso il problema non è “Google”, ma la capacità del sito di rispondere in modo stabile.

La correzione più sicura parte dai log. Se il sito usa WordPress, controlla errori PHP e plugin recenti. Se usa un pannello hosting, verifica i log dell’account, gli error log del dominio e lo stato dei servizi web e database. Se il 5xx è intermittente, il problema può essere legato al carico o a un job schedulato.

3) Problemi DNS

Se Google non riesce a risolvere il dominio, la pagina non è nemmeno raggiungibile. Questo succede spesso con record errati, nameserver non aggiornati, TTL incoerenti o propagazione incompleta. Il sintomo può sembrare un down del sito, ma in realtà il web server può essere perfettamente attivo.

In questi casi bisogna controllare che il dominio punti all’IP corretto, che i record A e AAAA siano coerenti e che eventuali cambi di provider siano stati completati. Se usi CDN o proxy, verifica anche che il record non sia stato lasciato in uno stato misto tra vecchio e nuovo provider.

4) Robots.txt e blocchi involontari

Un file robots.txt troppo restrittivo o una regola lato CMS può impedire la scansione di sezioni importanti. È un errore frequente dopo migrazioni, staging messi online per sbaglio o hardening troppo aggressivo. Anche un meta robots noindex inserito in un template può far sparire le pagine dall’indice.

Qui la correzione è delicata: non basta rimuovere il blocco, bisogna verificare che il sito non stia esponendo aree sensibili. Il principio corretto è autorizzare la scansione solo dove serve, lasciando protette le parti amministrative e i contenuti privati.

Procedura consigliata per correggere gli errori

La sequenza giusta è sempre: verifica, correzione minima, controllo finale. Cambiare tutto insieme rende impossibile capire cosa ha funzionato. Per questo conviene lavorare su una sola classe di errore alla volta.

1. Apri il report in Search Console e annota l’URL, il tipo di errore e la data del primo rilevamento.
2. Verifica l’URL dal browser in modalità anonima. Se possibile, prova anche da rete diversa o da un tool esterno.
3. Controlla i log del server e del CMS per l’ora esatta dell’errore. Cerca 404, 500, timeout, errori PHP o blocchi WAF.
4. Correggi il problema alla radice: redirect 301, ripristino pagina, fix DNS, aumento risorse, correzione plugin, rimozione blocco involontario.
5. Richiedi la convalida in Search Console solo dopo aver verificato che l’URL risponda correttamente.

Questo approccio evita il classico errore di chi “spinge il tasto di convalida” senza aver risolto nulla. La convalida non cura il problema: serve solo a farlo ricontrollare da Google.

Come distinguere un errore vero da un falso allarme

Non tutto ciò che appare come problema in Search Console richiede un intervento urgente. Alcuni errori sono normali, soprattutto su siti grandi o in evoluzione. Un 404 su contenuti vecchi può essere fisiologico. Un redirect su URL obsoleti può essere atteso. Un errore temporaneo di scansione può rientrare da solo se il server è tornato stabile.

Diventa invece prioritario quando il problema riguarda:

• homepage o pagine strategiche;
• un numero elevato di URL dello stesso pattern;
• errori 5xx ricorrenti;
• blocchi che impediscono l’accesso alle nuove pagine;
• calo di pagine indicizzate o di traffico organico.

In altre parole: non ogni segnale è un incendio, ma ogni segnale va classificato. La differenza la fa il volume, la ripetizione e l’impatto sulle pagine che generano traffico o conversioni.

Checklist tecnica per il fix corretto

Prima di chiudere il problema, controlla sempre questi punti:

• l’URL restituisce il codice atteso, ad esempio 200, 301 o 404;
• non esistono redirect loop o catene troppo lunghe;
• il DNS punta al server giusto;
• i log non mostrano errori ricorrenti sulla stessa risorsa;
• robots.txt e meta robots non bloccano per errore la pagina;
• la pagina è accessibile sia da browser sia per Googlebot, senza filtri anomali.

Se il sito usa WordPress o un altro CMS, dopo ogni correzione conviene svuotare cache applicativa, cache del server e cache CDN, se presente. Una pagina corretta ma ancora servita dalla cache vecchia può far credere che il problema persista.

Quando usare redirect, quando lasciare 404 e quando ripristinare

Il redirect 301 è la scelta giusta quando una pagina si è spostata in modo permanente e ha un sostituto reale. Il 404 è corretto quando il contenuto è stato rimosso senza alternativa. Il ripristino è la strada giusta quando la pagina dovrebbe esistere ancora ma è sparita per errore, cancellazione accidentale o deploy difettoso.

Il errore più dannoso è fare redirect “di massa” verso la home o verso pagine non pertinenti. Questo confonde utenti e motori di ricerca, e spesso peggiora la qualità percepita del sito. Meglio un 404 onesto che un redirect fuorviante.

Controllo post-intervento

Dopo la correzione, non fidarti solo della schermata di Search Console. Fai almeno questi controlli:

1. ricontrolla l’URL con un browser e con un controllo HTTP, verificando il codice di risposta;
2. verifica che il contenuto mostrato sia quello atteso e non una pagina cache vecchia;
3. controlla di nuovo i log per vedere se l’errore ricompare;
4. richiedi la convalida solo dopo esito positivo dei test;
5. osserva per alcuni giorni la copertura e la scansione delle pagine più importanti.

Se il problema si ripresenta, il fix era solo superficiale. In quel caso bisogna risalire un livello: server, database, CDN, plugin o configurazione DNS. La regola pratica è semplice: se l’errore torna, la causa non è stata rimossa.

Conclusione operativa

Gli errori di scansione non vanno affrontati come messaggi generici, ma come tracce tecniche da seguire fino alla causa. La soluzione migliore è quasi sempre quella più banale e precisa: correggere l’URL, sistemare il redirect, ripristinare il contenuto, stabilizzare il server o rimuovere il blocco involontario. Con una diagnosi ordinata, Search Console diventa uno strumento di controllo, non un elenco di allarmi incomprensibili.

Il metodo più affidabile è sempre lo stesso: identificare il tipo di errore, verificare dove si rompe la catena, intervenire nel punto giusto e confermare il risultato con un controllo reale. È meno spettacolare di una “soluzione magica”, ma è l’unico modo che funziona davvero nel tempo.

Principio utile: non correggere l’avviso, correggi la causa che ha generato l’avviso.