Webmaster: controlli rapidi quando il robots.txt blocca Google

Quando sospettare un problema nel robots.txt

Il file robots.txt è piccolo, ma può bloccare in modo netto la scansione di intere sezioni del sito. Se Google smette di visitare pagine importanti, se in Search Console compaiono esclusioni legate al robots o se nuove URL restano invisibili nonostante il sito sia online, il primo controllo da fare è proprio questo file.

La cosa utile del robots.txt è che il problema si vede in fretta: basta un carattere sbagliato, un percorso errato o una regola troppo ampia per fermare bot e crawler. Per questo conviene trattarlo come un punto di diagnosi rapido, non come un dettaglio secondario.

Diagnosi probabile

Le cause più comuni sono poche e concrete:

• una direttiva Disallow troppo ampia, ad esempio su / o su una cartella che contiene contenuti pubblici;
• un file robots.txt non raggiungibile, con errore 404, 403 o redirect anomalo;
• un robots.txt valido ma scritto male, con sintassi errata o regole in conflitto;
• un blocco accidentale di risorse utili al rendering, come CSS o JavaScript;
• un robots.txt diverso tra ambiente reale e staging, con copia errata in produzione.

La verifica va fatta sempre partendo dall’effetto reale: Google può leggere il file? e quale sezione viene bloccata?

Verifiche immediate

1. Apri il file direttamente nel browser visitando https://dominio.tld/robots.txt. L’esito atteso è un testo leggibile, senza pagina 404, 403 o redirect strani.
2. Controlla che il file esista nel percorso corretto. In hosting classico si trova nella root del sito, cioè nella stessa area pubblica del dominio. L’esito atteso è vedere un solo robots.txt per il dominio principale.
3. Leggi le regole principali. Cerca in particolare User-agent: *, Disallow: e Sitemap:. L’esito atteso è capire subito se è bloccata una directory importante.
4. Verifica Search Console. Nel tester del robots o nei controlli di scansione, l’esito atteso è che l’URL testato risulti consentito oppure che venga evidenziata la regola esatta che lo blocca.
5. Controlla i log del server se li hai disponibili. L’esito atteso è vedere richieste dei bot verso /robots.txt e capire se il file viene servito correttamente.

Soluzione consigliata passo-passo

La strada più sicura è correggere il file con una modifica minima, poi ricontrollare il comportamento dei crawler.

1. Fai una copia di sicurezza del file prima di toccarlo. Se lavori da terminale, salva il backup con un nome chiaro, ad esempio robots.txt.bak. Se lavori dal pannello hosting, usa il file manager e duplica il file prima della modifica.
2. Apri il robots.txt e cerca regole troppo ampie. Un esempio classico da verificare è Disallow: /, che blocca tutto il sito. Se il blocco era involontario, rimuovilo o restringilo alla sola cartella da escludere.
3. Correggi la sintassi. Ogni gruppo deve essere chiaro e pulito. Un file semplice e sano può essere del tipo:
   

   User-agent: *
   Disallow: /admin/
   Allow: /admin/ajax/
   Sitemap: https://dominio.tld/sitemap.xml

   Questo non è un modello universale, ma un esempio di struttura leggibile e non aggressiva.
4. Evita di bloccare file utili al rendering. Se il sito usa CSS o JavaScript per mostrare i contenuti, non impedire a Google di accedervi, altrimenti il rendering può risultare incompleto e la diagnosi diventa più confusa.
5. Salva il file e ripeti il test. Riapri /robots.txt nel browser e verifica che la versione online sia quella corretta. L’esito atteso è vedere subito le modifiche senza errori di caching o vecchi contenuti.
6. Riprova il test dell’URL bloccato nello strumento di analisi del robots. L’esito atteso è che la pagina ora risulti consentita, oppure che il blocco residuo sia limitato a percorsi voluti.

Come leggere un robots.txt senza perdere tempo

La regola utile è semplice: non cercare di interpretare tutto subito, ma separa il file in tre domande.

1. Chi viene colpito? Se il blocco è sotto User-agent: *, riguarda tutti i crawler. Se è sotto uno user agent specifico, il problema può essere più circoscritto.

2. Cosa viene bloccato? Un Disallow: /cartella/ è molto diverso da un Disallow: /. Il primo limita una sezione, il secondo ferma quasi tutto.

3. Il file è davvero quello giusto? In siti complessi può esserci un robots.txt vecchio in cache, un file di staging pubblicato per errore o una riscrittura lato server che modifica la risposta.

Questa lettura rapida evita di perdere tempo su ipotesi troppo astratte.

Errore tipico: il sito funziona, ma Google non vede le pagine

È uno dei casi più frequenti. Il sito è online, le pagine si aprono, ma Search Console segnala esclusioni o la scansione sembra ferma. In queste situazioni il robots.txt può non bloccare tutta la pagina, ma impedire a Google di leggere risorse essenziali o di entrare in sezioni chiave.

Se hai appena pubblicato nuove pagine, controlla anche che non siano collocate in directory escluse per abitudine, ad esempio aree tecniche, cartelle temporanee o percorsi usati dal CMS per contenuti dinamici.

Errore tipico: il file esiste ma restituisce 404 o 403

Se /robots.txt non risponde correttamente, il problema non è solo SEO: è un problema di accesso al file pubblico. In questo caso verifica il document root del dominio, i permessi del file e le regole del web server o del pannello hosting.

Nel file manager del pannello, il robots.txt deve stare nella root web del dominio. Se il dominio è ospitato in una sottocartella o dietro una configurazione particolare, il percorso reale può essere diverso da quello che immagini. La verifica da fare è sempre sul file effettivamente servito dal dominio, non su quello che pensi di aver modificato.

Se usi WordPress o un CMS

Con WordPress è importante distinguere tra il file fisico e le regole generate dal CMS. Alcuni plugin SEO permettono di modificare il robots.txt virtuale, mentre altri usano il file reale. Se cambi il file sbagliato, la modifica non avrà effetto oppure verrà sovrascritta.

Controlla quindi se il tuo CMS o il plugin SEO gestisce il robots da interfaccia. L’esito atteso è trovare una sola fonte di verità per evitare conflitti. Se il pannello genera il robots in automatico, conserva il backup prima di ogni modifica manuale.

Soluzione alternativa B

Se non riesci a capire subito quale regola blocca il traffico, fai un test di isolamento:

1. rinomina temporaneamente il robots.txt, mantenendo una copia di backup;
2. pubblica un file minimale e pulito con solo le regole indispensabili;
3. verifica se la scansione riparte;
4. se il problema sparisce, reintroduci le regole una alla volta fino a trovare quella incriminata.

Questo metodo è lento ma molto affidabile, soprattutto quando il file è stato accumulato nel tempo da più persone o più plugin.

Controlli finali / rollback

1. Riapri https://dominio.tld/robots.txt e conferma che il file online sia quello corretto. L’esito atteso è una risposta 200 con contenuto leggibile.
2. Rifai il test in Search Console su una URL rappresentativa. L’esito atteso è che il crawler non venga più bloccato dalla regola sbagliata.
3. Controlla le pagine importanti dopo qualche ora o giorno, in base alla frequenza di scansione. L’esito atteso è un ritorno progressivo della copertura o almeno dell’accesso al file.
4. Rollback: se dopo la modifica il comportamento peggiora, ripristina subito il backup del robots.txt e verifica di nuovo l’URL pubblico prima di fare altri cambiamenti.

Assunzione operativa: il sito espone un robots.txt pubblico e modificabile, con accesso al file manager del pannello hosting o a un editor equivalente.