Vai al contenuto
OneKitly

Come scrivere un robots.txt: direttive, corrispondenza e ciò che non può nascondere

Pubblicato il 21/05/2026 · 9 min di lettura · Strumenti per sviluppatori

Daniel Okonkwo

Daniel OkonkwoSviluppatore front-end e redattore Tech presso OneKitly

Performance web · Formati di file

Verificato su 2 fonti

Vedi il profilo
In breve

Un robots.txt è un file di testo UTF-8 semplice che deve stare nel percorso di primo livello di un host, in /robots.txt tutto minuscolo, e vale solo per quell'host, protocollo e porta esatti — https e http, e ogni sottodominio, ne richiedono ciascuno uno proprio. Contiene gruppi. Un gruppo inizia con una o più righe User-agent che nominano i crawler destinatari, con * a indicare tutti, e prosegue con righe Disallow e Allow i cui valori sono prefissi di percorso URL. Una riga Sitemap fornisce l'URL assoluto di una mappa del sito ed è indipendente da qualsiasi gruppo. Google onora solo user-agent, disallow, allow e sitemap, e ignora ogni altro campo. Nei percorsi sono ammessi due caratteri speciali: * corrisponde a zero o più caratteri qualsiasi e $ ancora la fine dell'URL. Quando più regole corrispondono vince la più specifica, misurata dalla lunghezza del percorso della regola in ottetti; a parità di specificità vince la meno restrittiva, quindi un Allow batte un Disallow della stessa lunghezza. Il punto cruciale è ciò che il file non è. È un'istruzione di scansione, non un controllo d'accesso e non un meccanismo di deindicizzazione. Un URL vietato può comunque comparire nei risultati se altri siti vi rimandano, perché il collegamento e il suo testo di ancoraggio bastano a indicizzare l'indirizzo senza scaricare la pagina. Una riga noindex nel robots.txt non è supportata e non fa nulla. E il file è pubblico per definizione: ogni percorso che vieti è un percorso che hai pubblicizzato.

Quattro direttive, due caratteri jolly, un file nella radice dell'host. È un'istruzione di scansione e nulla più: non toglie una pagina dai risultati, non limita l'accesso e pubblica ogni percorso che vi elenchi.

Un'istruzione di scansione, non una serratura né una gomma

Google lo dice senza giri di parole: il robots.txt non è un meccanismo per tenere una pagina fuori da Google, e una pagina vietata nel robots.txt può comunque essere indicizzata se altri siti la collegano. Il meccanismo si vede facilmente una volta detto. Disallow chiede a un crawler educato di non scaricare l'URL. Non dice nulla sul fatto che l'indirizzo possa comparire in un indice, e un collegamento da un altro sito fornisce abbastanza — l'URL stesso, più il testo di ancoraggio che vi punta — per elencare la pagina senza mai scaricarla. Il risultato è il noto risultato di ricerca con un URL nudo, senza titolo preso dalla pagina né descrizione, esattamente dove il proprietario del sito credeva di averla rimossa.

Gli strumenti giusti dipendono da che cosa vuoi davvero. Per tenere una pagina fuori dai risultati, servi un noindex — o un meta robots nella testa del documento, o un'intestazione di risposta X-Robots-Tag, che funziona anche per file privi di testa HTML, come i PDF. Per sottrarre un contenuto a chiunque, mettilo dietro un'autenticazione; nulla di dichiarativo in un file di testo pubblico ha mai limitato l'accesso, e la RFC 9309 lo dice apertamente definendo il protocollo un non sostituto di vere misure di sicurezza. E c'è una trappola di ordine per chi combina le due cose: se vieti un URL, il crawler non lo scaricherà mai, non vedrà mai il noindex che vi hai messo, e la pagina può restare a tempo indefinito nell'indice. Lasciala scansionabile finché non esce, e vietala dopo, se ancora vuoi.

Come funziona la corrispondenza: prefissi, due jolly e la regola più lunga

Ogni valore di Disallow e Allow viene confrontato come prefisso del percorso dell'URL, quindi Disallow: /admin blocca allo stesso modo /admin, /admin/, /administrator e /admin-tools. Aggiungere una barra finale restringe alla directory. Due caratteri speciali affinano il tutto: * rappresenta zero o più caratteri qualsiasi e $ ancora la fine dell'URL, così Disallow: /*.pdf$ blocca ogni URL che termina in .pdf lasciando raggiungibile /report.pdf?download=1, perché la stringa di query viene dopo l'ancora. Un jolly finale non aggiunge nulla: /* è la stessa regola di /. I percorsi distinguono le maiuscole, quindi /Admin e /admin sono due regole diverse, mentre i nomi delle direttive no.

Quando più di una regola corrisponde a un URL, vince la più specifica, e qui specificità non significa nulla di più sofisticato della lunghezza del percorso della regola in ottetti. Disallow: /reports/ e Allow: /reports/public/ corrispondono entrambi a /reports/public/q3.html; l'Allow è più lungo, quindi il file è scansionabile. Inverti le lunghezze e vince il Disallow. Se due regole corrispondenti hanno esattamente la stessa lunghezza, il pareggio va alla meno restrittiva, cioè all'Allow. L'ordine nel file è irrilevante — un Disallow scritto dopo un Allow non lo annulla, e già solo questo spiega buona parte dei robots.txt che non si comportano come il loro autore li legge. Altri due limiti da conoscere: Google legge al massimo 500 kibibyte e ignora tutto ciò che segue, e un valore Disallow vuoto significa che nulla è bloccato, la forma idiomatica per scrivere un gruppo che consente tutto.

Dove vive il file e perché pubblicizza ciò che volevi nascondere

La regola sulla posizione è assoluta e non si configura. La RFC 9309 richiede che le regole siano accessibili in un file chiamato /robots.txt, tutto minuscolo, nel percorso di primo livello del servizio, e Google aggiunge che valgono solo per host, protocollo e porta dove il file è ospitato. Leggilo con attenzione, perché le conseguenze fanno inciampare di continuo. Un file su https://example.com/robots.txt non governa nulla su http://example.com, nulla su https://shop.example.com e nulla su https://example.com:8443 — ciascuno di questi indirizzi è un'origine distinta che richiede un proprio file. Un file messo in una sottodirectory non viene letto affatto. E un sito dietro una CDN o un proxy inverso vale quanto vale il suo instradamento: se la piattaforma serve il proprio robots.txt alla radice, il tuo lato applicazione non entra mai in gioco.

Ora la parte senza giri di parole. Il file viene servito a chiunque lo chieda, non ha autenticazione ed è di gran lunga la prima cosa che uno scanner automatico legge. Scrivere Disallow: /internal/backup-2019/ non nasconde quella directory: ne pubblica l'esistenza, il percorso esatto e il fatto che tu l'abbia ritenuta degna di essere nascosta, in un documento che hai invitato l'intera internet a leggere. Ogni strumento di ricognizione mai scritto parte da lì, esattamente per questo. Se un percorso non deve essere raggiunto, mettilo dietro un'autenticazione o toglilo dall'host pubblico; se soltanto non deve essere scansionato, vieta un ampio prefisso superiore invece di nominare la foglia delicata. E tratta il file come codice: tienilo sotto controllo di versione, rivedi le modifiche come qualsiasi altro rilascio e controllalo dopo ogni migrazione di piattaforma, perché un Disallow: / finito per sbaglio in produzione è il modo più rapido di togliere un intero sito dalla ricerca e uno dei più lenti da cui riprendersi.

Le righe che puoi mettere in un robots.txt, e le due che si scrivono lo stesso
RigaChe cosa faStatoLa trappola
User-agent: *Apre un gruppo e nomina i crawler destinatari; * si rivolge a qualsiasi crawler privo di un gruppo proprioOnorataUn crawler obbedisce a esattamente un gruppo — il più specifico che lo nomina — e ignora del tutto il gruppo * appena ne ha uno proprio
Disallow: /pathChiede ai crawler di questo gruppo di non scaricare URL il cui percorso inizi con quel prefissoOnorataBlocca il recupero, non l'indicizzazione — un URL bloccato ma collegato dall'esterno può restare nei risultati, senza anteprima
Allow: /path/fileRitaglia un'eccezione da un Disallow più ampio nello stesso gruppoOnorataVince solo se il suo percorso è più lungo del Disallow che affronta; a parità di lunghezza vince l'Allow, se più corto perde
Sitemap: https://…/sitemap.xmlIndica ai crawler una mappa del sito; può comparire ovunque nel file e non appartiene ad alcun gruppoOnorataIl valore deve essere un URL assoluto completo, schema compreso; un percorso relativo viene scartato in silenzio
Crawl-delay: 10Chiede a un crawler di attendere fra le richieste; estensione di fornitore, mai parte del protocolloIgnorata da GoogleAlcuni crawler la rispettano e altri no, quindi non serve per controllare il carico; limita il ritmo sul server
Noindex: /pathNulla. Sembra debba togliere una pagina dall'indice e non lo faNon supportataUsa un meta robots noindex nella testa della pagina, o un'intestazione di risposta X-Robots-Tag, e lascia l'URL scansionabile perché la regola possa essere letta
Generatore di robots.txtCrea un robots.txt corretto da campi strutturati: il crawler da targettizzare, i percorsi da consentire e bloccare, una o più sitemap (i percorsi relativi diventano assoluti), e righe opzionali crawl-delay e host. Gestisce come i motori scansionano il tuo sito — ricorda che è una direttiva di scansione, non una barriera di sicurezza.Prova lo strumento

Domande frequenti

Posso usare il robots.txt per tenere una pagina privata fuori da Google?
No, su entrambi i fronti. Google dice apertamente che il robots.txt non è un meccanismo per tenere una pagina fuori da Google, e un URL vietato ma collegato da un qualsiasi altro sito può comunque essere elencato usando solo il collegamento e il suo testo di ancoraggio. Né la pagina è privata in alcun senso reale: il robots.txt è solo una richiesta, rispettata dai motori di ricerca e ignorata da tutto ciò che ha interesse a ignorarla, e il file stesso diffonde il percorso. Per la visibilità in ricerca usa un noindex, servito come meta robots o come intestazione X-Robots-Tag. Per la riservatezza vera usa l'autenticazione. Sono due problemi distinti e il robots.txt non ne risolve nessuno.
I sottodomini e http contro https condividono un unico robots.txt?
No. Le regole valgono solo per host, protocollo e porta esatti che hanno servito il file, quindi https://example.com, http://example.com, https://www.example.com e https://api.example.com sono quattro ambiti distinti che richiedono quattro file distinti — anche se puntano allo stesso server e alla stessa radice dei documenti. È il secondo errore di configurazione più comune dopo il mettere il file in una sottodirectory, dove non viene mai letto. Conseguenza pratica: se reindirizzi http verso https, il crawler segue il reindirizzamento per scaricare il file, quindi la copia https governa di fatto entrambi; se non reindirizzi, l'origine http non ha regole e viene scansionata liberamente.
Ho vietato una pagina ma è ancora nei risultati. E adesso?
È il comportamento atteso, e la soluzione è invertire l'ordine delle operazioni. Togli il Disallow perché la pagina torni scansionabile, aggiungi un noindex — meta robots o intestazione X-Robots-Tag — e attendi che la pagina venga riscansionata e rimossa. L'approccio iniziale è fallito per circolarità: finché l'URL è vietato il crawler non lo scarica mai, quindi non vede mai il noindex che vi hai messo, e l'inserimento costruito sui collegamenti in entrata persiste a tempo indefinito. Una volta uscita dall'indice puoi ripristinare il Disallow per risparmiare budget di scansione, anche se a quel punto di solito rende molto poco.

Articoli che potrebbero interessarti

Tutte le guide
GuidaCodici di stato HTTP spiegati: quelli che davvero si confondono301 contro 308, 302 contro 307, 401 contro 403, 404 contro 410 — più che cosa promette davvero Retry-After su un 429 o un 503. Le coppie in cui scegliere il codice sbagliato cambia il comportamento, non solo le parole.TutorialCome scrivere un'espressione cron: cinque campi e la regola OR di cui nessuno parlaMinuto, ora, giorno del mese, mese, giorno della settimana. Le trappole: un passo è un'andatura dentro un intervallo e non una cadenza, e i due campi del giorno si combinano con OR — quindi 0 0 1 * 1 scatta il giorno 1 e ogni lunedì.SpiegazioneCome funzionano i permessi dei file Unix: leggere 755 senza tirare a indovinareLettura 4, scrittura 2, esecuzione 1, e ciascuna delle tre cifre descrive un soggetto diverso. Ciò che quasi tutte le spiegazioni sbagliano è cosa fa il bit di esecuzione su una directory: concede l'attraversamento, non il diritto di eseguire qualcosa.GuidaChe cosa rende buono uno slug di URL: stabilità, leggibilità e il conflitto fra le dueUno slug ha due compiti che tirano in direzioni opposte: è un identificatore permanente ed è un testo leggibile. Lunghezza, trattini, parole vuote, date, caratteri non ASCII e il modello identificatore + slug che ottiene entrambe le proprietà — con i numeri reali di un sito che localizza 1736 slug di strumenti in sei lingue.GuidaTag title, meta description, e che cosa ci fanno i motori di ricercaChe cosa dice la documentazione di Google sulla riscrittura dei titoli e sulla meta description, invece di quel che dice il folklore SEO. Poi la parte misurabile: i titoli vengono troncati per larghezza in pixel, quindi due titoli di esattamente sessanta caratteri possono renderizzarsi a 204,55 pixel di distanza e solo uno sopravvive.SpiegazioneLa densità di parole chiave è una metrica morta, ed ecco che cosa l'ha sostituitaLa densità contava le occorrenze perché il recupero contava le occorrenze. TF-IDF, poi BM25 con la sua curva di saturazione, poi gli embedding l'hanno sostituita. Ecco la stessa pagina da 800 parole valutata in tre modi, e perché i tre non concordano.

Strumenti correlati

Fonti

Hai notato un errore in questo articolo?