Search Console segnala problemi dell’host: come capire se Google riesce a visitare il sito

Identificare l’host e il periodo dell’avviso

Apri Impostazioni e Statistiche di scansione nella proprietà corretta. Il rapporto è disponibile per proprietà di dominio e proprietà con prefisso URL a livello radice. Se l’attività usa più sottodomini, individua quello segnalato: sito principale, negozio e area di prenotazione possono avere configurazioni diverse.

Registra la prima e l’ultima data interessate, la categoria e alcuni esempi. Il rapporto distingue problemi recenti da disponibilità risultata problematica soltanto nel passato. Prima di intervenire, verifica quindi se l’evento coincida con manutenzione, migrazione o un guasto già risolto.

Una richiesta utile al fornitore potrebbe essere: “Dal giorno indicato compaiono errori di connessione su questo host; questi sono gli URL di esempio e gli orari disponibili”. Una richiesta generica come “Google non legge il sito” lascia invece aperte troppe interpretazioni e rende difficile assegnare il problema alla persona giusta.

Separare DNS, server e recupero del robots.txt

Lo stato dell’host considera il recupero del robots.txt, la risoluzione DNS e la connettività del server. Queste categorie aiutano a scegliere chi coinvolgere: gestore del dominio, hosting, amministratore della rete o sviluppatore. Un problema applicativo non si risolve necessariamente modificando le impostazioni DNS.

Conserva la distinzione anche nel verbale dell’intervento. Se il fornitore corregge il DNS, chiedi una prova sulla risoluzione e sull’apertura delle risorse, non soltanto una conferma che il pannello di gestione sia tornato accessibile.

Controllare la risposta del robots.txt

Il robots.txt viene richiesto alla radice dell’host. Google usa la sua risposta per gestire la scansione: un errore di recupero non equivale a una regola che esclude volontariamente una cartella. Anche una pagina di errore restituita dal firewall al posto del file merita attenzione.

Chiedi di conservare codice HTTP, eventuali reindirizzamenti e contenuto della risposta. Nella documentazione Google, un robots.txt assente con risposta 404 è trattato diversamente da un errore del server o di rete: il primo non impedisce di per sé la scansione, mentre i secondi possono rallentarla o sospenderla. La sequenza dipende dal tipo di errore e dalle informazioni già disponibili a Google.

Non cancellare tutte le regole per tentare di togliere l’avviso. Prima separa disponibilità e contenuto del file; poi controlla le esclusioni effettivamente volute. La guida su robots.txt e noindex chiarisce quale controllo appartiene a ciascuno strumento.

Esaminare errori e tempi insieme alle modifiche del sito

Se compaiono errori 5xx, timeout o connessioni interrotte, chiedi al tecnico di cercare la causa nell’intervallo segnalato. I codici del server e gli errori di rete aiutano a capire perché una richiesta non sia arrivata a buon fine; non descrivono da soli il componente responsabile. Un sovraccarico, un servizio indisponibile e una configurazione errata possono presentare sintomi simili.

Confronta il calendario con pubblicazioni, aggiornamenti, cambi di hosting e picchi di attività. In un esempio ipotetico, un catalogo importa dati ogni notte e le risposte peggiorano durante l’importazione. L’ipotesi va verificata con tempi e registri, prima di proporre un server più costoso.

Se il sito risponde ma impiega molto tempo, la diagnosi della risposta lenta del server offre un percorso complementare. Se è irraggiungibile anche per i clienti, la priorità operativa è ripristinare il servizio e documentare poi l’evento.

Incrociare il rapporto con i registri tecnici

Il tecnico dovrebbe confrontare gli esempi con i registri disponibili su server, proxy, CDN e protezioni di accesso. Le richieste che falliscono prima di raggiungere il server applicativo possono non comparire nel suo registro. Per questo l’assenza di una riga non dimostra automaticamente che il problema non sia esistito.

La guida alla lettura dei log di Google e Bing spiega come riconoscere richieste e risposte. Prima di creare eccezioni nel firewall occorre verificare l’identità del crawler con i metodi ufficiali; il solo nome dichiarato nella richiesta non è sufficiente.

Condividi soltanto le informazioni necessarie alla diagnosi, evitando credenziali e dati dei clienti. Per ciascuna ipotesi chiedi una conclusione verificabile: confermata, esclusa oppure ancora da provare. Un elenco di possibili cause senza riscontro non consente di decidere quale modifica sia opportuna.

Correggere la causa e collaudare il percorso completo

Concorda una modifica mirata e una procedura di verifica. Se si interviene su una protezione, il controllo deve confermare che le pagine pubbliche siano accessibili e che le aree riservate mantengano le loro regole. Disattivare indiscriminatamente il firewall non è una soluzione da considerare conclusa.

Ripeti i controlli sull’host interessato e su alcuni indirizzi rappresentativi: homepage, pagina di servizio, file statico e robots.txt. Prova anche il percorso del cliente, soprattutto quando cambiano proxy, certificati o instradamento. Un collegamento al modulo o al booking può usare un sottodominio diverso da quello appena corretto.

• Annotare la modifica e l’ora di applicazione.
• Conservare la risposta HTTP osservata prima e dopo.
• Verificare gli indirizzi che avevano mostrato il problema.
• Ripetere una richiesta utile al cliente con dati di prova.

Gli interventi più ampi richiedono un piano di ripristino concordato con chi gestisce l’infrastruttura.

Seguire l’esito senza confondere scansione e posizionamento

Controlla se gli errori tornano nelle verifiche attuali e se il rapporto registra nuovi eventi dopo la correzione. Conserva separato lo storico: un avviso relativo al passato non prova che il guasto sia ancora attivo. Un monitoraggio della disponibilità può aiutare a intercettare ricorrenze e collegarle ai lavori sul sito.

Non interpretare ogni oscillazione del numero di richieste come un problema. Il contesto è più utile del totale isolato: indirizzi, risposte, tempi e intervalli devono raccontare una situazione coerente. Se non esistono errori e il dubbio riguarda una pagina esclusa, passa alla verifica dell’indicizzazione.

Rendere il sito nuovamente accessibile elimina un ostacolo tecnico, ma non garantisce scansione immediata, indicizzazione completa o recupero di posizioni. Chiudi l’assistenza con causa accertata, prove e responsabile dei controlli successivi: sono questi gli elementi che rendono il lavoro verificabile.

Domande frequenti

Il sito si apre dal mio computer: posso ignorare l’avviso?

No. Controlla data, host e categoria: il problema può essere passato oppure riguardare richieste e percorsi diversi dalla tua visita. Una verifica attuale serve a capire se sia ancora attivo.

Un problema dell’host significa che devo cambiare hosting?

Non necessariamente. Occorre prima identificare la causa. Una configurazione DNS, una regola del firewall o un’operazione applicativa possono richiedere interventi diversi da un trasferimento.

Più richieste di scansione significano automaticamente più visite?

No. La scansione descrive gli accessi del motore alle risorse; le visite dei clienti e il rendimento nei risultati sono misure diverse. Valuta separatamente disponibilità, indicizzazione e traffico.