Il robots.txt è un file di testo che sta nella radice di un sito e dice ai crawler quali URL possono scaricare e quali devono lasciare stare.
Quello che non fa è decidere cosa compare nei risultati di ricerca. Un URL bloccato lì dentro può finire lo stesso su Google, senza descrizione sotto il titolo, se qualcun altro lo linka. Per tenere una pagina fuori dall’indice serve il noindex, che è un’altra istruzione e sta in un altro posto.
Una sola posizione possibile
Il file si chiama robots.txt tutto minuscolo e vale solo per la combinazione esatta di protocollo, host e porta da cui è stato scaricato. https://esempio.it/robots.txt non dice niente su https://shop.esempio.it/, né su http://esempio.it/, né su https://esempio.it:8181/: ognuno di questi indirizzi ha bisogno del proprio file. La specifica di Google elenca i casi uno per uno, punycode e FTP compresi.
Un robots.txt dentro una sottocartella non esiste: nessun crawler lo cerca lì. Il formato è testo semplice in UTF-8, e Google scarta le righe che non riesce a leggere invece di buttare via tutto il file. Il limite di dimensione è 500 kibibyte, oltre i quali il resto viene ignorato, e la copia in cache dura al massimo 24 ore.
Le quattro righe che Google legge davvero
La sintassi è campo: valore, una direttiva per riga, con # per i commenti. I campi che i crawler di Google interpretano sono quattro, e tutto il resto viene saltato.
| Direttiva | Cosa fa | Esempio | |
|---|---|---|---|
| user-agent | Apre un gruppo e dice a quale crawler è rivolto | User-agent: Googlebot | Sì |
| disallow | Percorso che non deve essere scaricato | Disallow: /carrello/ | Sì |
| allow | Eccezione dentro un percorso bloccato | Allow: /carrello/guida.html | Sì |
| sitemap | URL assoluto di una sitemap, valido per tutti i bot | Sitemap: https://esempio.it/sitemap.xml | Sì |
| crawl-delay | Secondi di attesa fra due richieste | Crawl-delay: 5 | No |
| host, noindex | Dominio preferito, esclusione dall’indice | Host: esempio.it | No |
Il nome del campo non distingue maiuscole e minuscole, il valore sì: Disallow: /listino non blocca /Listino. I caratteri jolly ammessi sono due, * che sostituisce qualsiasi sequenza e $ che àncora la fine dell’URL, quindi Disallow: /*.pdf$ prende solo i percorsi che finiscono davvero in .pdf e lascia passare /scheda.pdf?v=2.
Quando due regole si contraddicono vince quella più lunga, cioè quella che combacia con più caratteri dell’URL. A parità di lunghezza lo standard dice di preferire allow. È il punto in cui i file scritti a mano si comportano più spesso in modo diverso da come si aspettava chi li ha scritti.
C’è poi il caso che si vede in metà degli audit: un gruppo specifico batte quello generico, ma non lo eredita. Se scrivi tre Disallow sotto User-agent: * e più sotto apri un blocco User-agent: Googlebot con una riga sola, Googlebot legge quella riga e ignora le altre tre. Le regole vanno ripetute dentro il gruppo specifico.
Bloccare la scansione non è togliere dai risultati
Google lo mette in evidenza nella sua introduzione ai file robots.txt: il file «non è un meccanismo che permette di escludere una pagina web da Google». Se altre pagine rimandano a un URL bloccato, Google può indicizzarlo senza averlo mai scaricato, e lo mostra nei risultati senza descrizione.
Il rovescio è più insidioso. Se metti il noindex su una pagina e poi blocchi la stessa URL nel robots.txt, il crawler non scarica la pagina, quindi non legge mai il noindex, e l’indirizzo resta in indice a volte per mesi. Le due istruzioni non si sommano: la seconda annulla la prima.
Terzo effetto, quello che si nota molto dopo: i link dentro una pagina bloccata non vengono scoperti. Se un articolo è raggiungibile solo da una pagina in Disallow, per Google quell’articolo non esiste.
Cosa succede quando il server risponde male
Questa parte manca in quasi tutte le guide in circolazione, e riguarda l’incidente più costoso che un robots.txt possa causare.
| Risposta HTTP a /robots.txt | Comportamento del crawler |
|---|---|
| 2xx | Il file viene elaborato e le regole applicate |
| 3xx | Google segue almeno cinque redirect, poi tratta la richiesta come un 404 |
| 4xx, escluso il 429 | Come se il file non esistesse: nessuna restrizione di scansione |
| 429 | Errore temporaneo, non assenza di file |
| 5xx | Regole indefinite: il crawler deve assumere il divieto completo sul sito |
La riga che conta è l’ultima. Se il server risponde 500 o 503 alla richiesta di /robots.txt, lo standard impone al crawler di comportarsi come se l’intero sito fosse in Disallow, perché le regole risultano indefinite. Non è un blocco parziale su qualche cartella: è tutto il sito che smette di essere scansionato, finché il file non torna raggiungibile o non passa abbastanza tempo (l’RFC indica trenta giorni come esempio) perché il crawler lo consideri semplicemente assente.
È il motivo per cui un robots.txt generato da un plugin, da un middleware o da una regola di firewall che va in errore sotto carico può fermare le scansioni senza che nessuno abbia toccato una riga di configurazione. Quando il traffico organico cala e il sito smette di comparire senza una causa evidente, il codice di stato del robots.txt è uno dei primi controlli di un audit tecnico, prima di guardare i contenuti.
Dal 1994 a uno standard vero
Il file nasce nel giugno 1994 da una discussione sulla mailing list robots-request, dopo che un crawler aveva messo in ginocchio un server. La proposta è di Martijn Koster. Per ventotto anni è rimasta una convenzione: tutti la rispettavano, nessuno l’aveva messa per iscritto in un documento normativo.
Nel 2022 l’IETF ha pubblicato l’RFC 9309, Robots Exclusion Protocol, su Internet Standards Track. Da lì il protocollo ha una sintassi formale in ABNF, regole obbligatorie sulla gestione degli errori, sulla cache e sui limiti di parsing, che devono essere di almeno 500 kibibyte. Lo stesso documento chiarisce in una riga cosa il robots.txt non è: «These rules are not a form of access authorization».
Buona parte del materiale in italiano è ferma a prima di quella data. La voce di Wikipedia in italiano scrive ancora che «non esiste un vero e proprio standard per il protocollo robots», e robotstxt.org, che diverse guide indicano come riferimento, riflette la versione del 1994: senza caratteri jolly, senza Allow, senza Sitemap.
Chi lo legge oggi, oltre a Googlebot
Il traffico dei crawler non arriva più solo dai motori di ricerca. Sulla rete Cloudflare, a maggio 2025, Googlebot valeva il 50% delle richieste di questa categoria, con un aumento del 96% in un anno, e GPTBot di OpenAI era salito al 7,7% con un +305%. È un campione globale, non italiano, ma l’ordine di grandezza indica dove sta andando la cosa.
Sull’adozione i numeri sono meno lusinghieri. Il 6 giugno 2025 Cloudflare ha trovato un robots.txt su 3.816 dei primi 10.000 domini, poco meno di quattro su dieci. Fra questi, 546 (circa il 14%) contenevano una regola rivolta esplicitamente ai bot AI. Il token più bloccato era GPTBot, con 312 domini, seguito da CCBot e Google-Extended.
Su Google-Extended serve una nota tecnica, perché genera confusione: non è uno user agent che vedrai nei log del server. È un token che serve solo a dire a Google se i contenuti possono essere usati per l’addestramento dei modelli, mentre le richieste continuano ad arrivare da Googlebot. Chi cerca corrispondenze fra le righe del robots.txt e gli access log per quel nome non ne troverà mai. Discorso diverso per llms.txt, che è una proposta separata e non sostituisce niente di tutto questo.
Come si verifica, ora che il tester non c’è più
Lo strumento che molte guide continuano a citare non esiste da anni. Google ha pensionato il Tester dei file robots.txt a novembre 2023, sostituendolo con il report robots.txt dentro Search Console, nella sezione Impostazioni.
Il report mostra i file trovati per i primi 20 host della proprietà, quando sono stati scaricati l’ultima volta, la dimensione in byte e gli eventuali errori di parsing. Conserva anche le versioni recuperate negli ultimi 30 giorni, ed è la parte più utile: quando qualcuno ricarica per sbaglio una vecchia copia del file, lì si vede il momento esatto in cui è successo.
Per sapere se un singolo indirizzo è bloccato si usa Controllo URL. Per provare le regole in locale, Google pubblica su GitHub la libreria open source robotstxt, che è lo stesso parser usato nella Ricerca; Screaming Frog permette di caricare un file personalizzato e vedere cosa bloccherebbe prima di pubblicarlo. Il report va guardato quando si mette mano al file, non ogni settimana: nella checklist SEO sta fra i controlli trimestrali.
Il file migliore, per molti siti, è quello che non c’è
Un robots.txt assente restituisce un 404, e un 404 significa nessuna restrizione: Google scansiona tutto. Per un sito di quaranta pagine è esattamente il comportamento che vuoi, e un file scritto male fa più danni di un file mancante. Serve quando hai davvero qualcosa da escludere: filtri di navigazione che moltiplicano gli URL su un ecommerce, risultati di ricerca interna, carrelli, pagine di confronto generate al volo. In quei casi il lavoro vero è capire quali indirizzi tagliare, che è la prima cosa che guardiamo quando prendiamo in carico la SEO di un sito; scrivere le righe è la parte da cinque minuti.
Una cosa che si dice poco: il file è pubblico e lo leggono anche le persone. Mettere Disallow: /area-riservata-clienti/ non nasconde quella cartella, la annuncia a chiunque apra l’indirizzo. Il NIST lo scrive da anni nelle sue linee guida sulla sicurezza dei server, e vale qui alla lettera: la sicurezza di un sistema non può dipendere dalla segretezza dei suoi componenti.
Domande frequenti sul file robots.txt
No. Se non c'è niente da escludere dalla scansione, l'assenza del file va benissimo: Google la interpreta come nessuna restrizione e scansiona tutto. Un robots.txt scritto male fa più danni di un robots.txt mancante.
No. Blocca il download della pagina, non la sua presenza nei risultati. Un URL bloccato ma linkato da altri siti può comparire lo stesso, senza descrizione sotto il titolo. Per tenerlo fuori dall'indice serve il meta tag noindex o l'intestazione X-Robots-Tag, e la pagina deve restare scansionabile perché il crawler possa leggerli.
No. I campi interpretati dai crawler di Google sono solo user-agent, allow, disallow e sitemap. Altri motori, fra cui Bing e Yandex, la riconoscono ancora, ognuno con la propria interpretazione. Per ridurre la frequenza di scansione di Googlebot si passa dalle impostazioni di Search Console.
Sì, e lo stesso vale per ogni protocollo e ogni porta. Le regole si applicano soltanto all'host, al protocollo e alla porta esatti da cui il file è stato scaricato: https://esempio.it/robots.txt non vale per https://blog.esempio.it/ né per http://esempio.it/.
In genere meno di 24 ore, che è la durata massima della copia in cache. Se serve prima, dal report robots.txt di Search Console si può chiedere una nuova scansione del file.
Secondo l'RFC 9309 il crawler deve considerare le regole indefinite e comportarsi come se l'intero sito fosse vietato. Un errore server prolungato su quel singolo file può quindi fermare la scansione di tutto il sito, anche se nessuna direttiva è cambiata.