Come controllare il tuo robots.txt (e la riga che deindicizza un sito)

Per controllare il robots.txt apri https://tuosito.it/robots.txt nel browser, leggi ogni gruppo User-agent e cerca le regole Disallow che coprono pagine che vuoi nei risultati di ricerca, a partire da un Disallow: / senza nient'altro. Su un sito piccolo basta un minuto. Poi verifica nel report robots.txt di Search Console cosa ha scaricato davvero Google, perché il file che vedi tu e quello ricevuto da Googlebot non sempre coincidono.

La maggior parte dei file robots.txt è fatta di poche righe, ed è proprio per questo che quasi nessuno li legge. Valgono però per l'intero host, quindi una sola riga sbagliata ha effetto su ogni URL.

Scansione, non indicizzazione

Il robots.txt dice ai crawler quali URL possono richiedere. Non decide cosa compare nei risultati di ricerca. Un URL bloccato nel robots.txt può comunque essere indicizzato se altre pagine lo linkano: Google lo mostra senza descrizione e Search Console lo elenca come "Indicizzata, ma bloccata da robots.txt".

La differenza conta quando si usa il robots.txt per nascondere delle pagine. Se blocchi una pagina e le aggiungi anche un noindex, Google non può scansionarla, non vede mai il noindex e l'URL può restare nell'indice. Per togliere una pagina dai risultati lasciala scansionabile e servi il noindex. Questo lato del problema lo trovi in il tag noindex, spiegato.

Dove trovare il file

Il robots.txt sta sempre nella root di un host, per esempio https://example.com/robots.txt. Le sue regole valgono solo per il protocollo, l'host e la porta da cui viene servito, quindi https://shop.example.com ha bisogno di un file suo.

Su molte piattaforme non esiste un file fisico da aprire. WordPress genera un robots.txt virtuale finché non carichi un file vero nella root del sito, e plugin SEO come Yoast e Rank Math permettono di modificarlo dal pannello di amministrazione. Shopify serve un file predefinito che puoi personalizzare aggiungendo al tema un template robots.txt.liquid. Se ti colleghi via FTP e il file non c'è, di solito il motivo è questo.

Leggerlo riga per riga

Un robots.txt è composto da gruppi. Ogni gruppo si apre con una o più righe User-agent, seguite dalle sue regole:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*?s=
Disallow: /cart/

User-agent: GPTBot
Disallow: /

Sitemap: https://example.com/sitemap_index.xml

Leggendo l'esempio dall'alto, tutti i crawler restano fuori da /wp-admin/, tranne che da admin-ajax.php, dai risultati della ricerca interna (?s=) e dal carrello. GPTBot ha un gruppo tutto suo ed è bloccato ovunque. La riga Sitemap non appartiene a nessun gruppo e vale per l'intero file.

Alcune regole di parsing spiegano la maggior parte delle sorprese. Un crawler segue solo il gruppo più specifico che corrisponde al suo nome. Qui Googlebot non trova un gruppo User-agent: Googlebot, quindi usa *; se quel gruppo ci fosse, ignorerebbe del tutto le regole di * invece di sommarle. I percorsi distinguono tra maiuscole e minuscole, quindi /Blog/ e /blog/ sono regole diverse. * corrisponde a qualsiasi sequenza di caratteri e $ indica la fine dell'URL, per cui Disallow: /*.pdf$ blocca i PDF e nient'altro. Quando a un URL corrispondono sia un Allow sia un Disallow, Google applica la regola più lunga e specifica. Un Disallow: vuoto non blocca nulla.

Google ignora le righe Crawl-delay e Noindex nel robots.txt. Bing invece rispetta Crawl-delay.

Le due righe che bloccano un intero sito

User-agent: *
Disallow: /

Queste due righe dicono a tutti i crawler di stare lontani da tutti gli URL. È la configurazione normale per un sito di staging o di sviluppo, ed è proprio così che arriva sui siti live: un deploy copia il file dello staging, oppure una migrazione si porta dietro tutta la configurazione. WordPress ha una trappola simile. Se spunti "Scoraggia i motori di ricerca dall'indicizzazione di questo sito" in Impostazioni > Lettura, le versioni attuali aggiungono un meta tag robots noindex a ogni pagina, quindi dopo un lancio conviene controllare sia il file sia il sorgente delle pagine.

Quando succede, i visitatori non notano nulla. Le pagine si caricano, i moduli funzionano, i controlli di uptime restano verdi. Intanto la scansione rallenta e nelle settimane successive le pagine escono dai risultati.

Come controllare il robots.txt: le verifiche utili

1. Apri direttamente /robots.txt e guarda lo status HTTP oltre al contenuto. Lo trovi nella scheda Network di Chrome DevTools. Devi vedere un 200 e le regole che ti aspetti.
2. Cerca nel file un Disallow: / isolato e le regole sulle cartelle che contengono pagine che vuoi posizionare, come /blog/, /products/ o /category/.
3. Verifica che la riga Sitemap: punti a una sitemap che si carica e che sia quella attuale, non un residuo di un plugin precedente.
4. In Search Console apri Impostazioni > robots.txt. Il report elenca i file robots.txt che Google ha trovato per gli host principali della proprietà, quando ciascuno è stato scansionato l'ultima volta, lo stato del recupero ed eventuali righe che non è riuscito a interpretare. Dopo aver risolto un problema urgente, da lì puoi richiedere una nuova scansione.
5. Per un singolo URL usa Controllo URL. Se l'URL è bloccato, la sezione sull'indicizzazione della pagina riporta "Bloccata da robots.txt".
6. Su un sito più grande lancia un crawler come Screaming Frog in modalità predefinita, che rispetta il robots.txt, e rivedi gli URL che segnala come bloccati.

Google ha dismesso il vecchio Tester dei file robots.txt nel 2023, quindi le guide che ti mandano lì non sono aggiornate.

Lo status code conta quanto le regole. Google tratta un 404, o qualsiasi altro 4xx tranne il 429, come se il robots.txt non esistesse, e quindi tutto può essere scansionato. Un 5xx viene gestito in un altro modo: Google interrompe la scansione per un certo periodo, poi ripiega su una copia in cache mentre continua a riprovare. Google inoltre tiene il file in cache fino a 24 ore e legge solo i primi 500 KiB, per cui in un file insolitamente lungo le regole oltre quel limite vengono ignorate.

Sapere quando il file cambia

Tutte le verifiche qui sopra ti mostrano cosa contiene il robots.txt oggi. Nessuna ti dice che martedì un plugin lo ha riscritto o che un cambio di hosting ha ripristinato una versione vecchia. Su un sito puoi riaprirlo dopo ogni rilascio. Su un portfolio di clienti in cui gli sviluppatori pubblicano senza avvisare non lo farai, e il primo segnale di una modifica sbagliata di solito è un calo della scansione in Search Console, settimane dopo. La guida agli alert sulle modifiche al robots.txt spiega quali modifiche meritano un alert.

Deltio scarica il robots.txt di ogni sito cliente durante il controllo giornaliero, lo confronta con la versione precedente e, se è cambiato, invia un alert su Slack o via email per quel sito. Lo stesso passaggio controlla noindex, canonical e gli URL nella sitemap, perché un deploy dallo staging tende a romperne diversi insieme. Il controllo gira una volta al giorno, quindi una modifica viene segnalata in giornata o il giorno dopo, non nel giro di minuti. Gli alert sulle modifiche SEO spiegano come sono organizzati, e se vuoi aggiungere un sito c'è una prova gratuita di 14 giorni.