Robots.txt: cos'è, come si scrive e quali bot AI bloccare

Il robots.txt è un file di testo, nella radice del sito, con cui dici ai crawler quali URL possono scansionare. Serve a gestire il traffico dei bot, non a togliere pagine da Google e non a proteggere dati: è una richiesta che i bot corretti rispettano, non un lucchetto.

Su seo.srl il file non è scritto a mano: lo genera il server e cambia a seconda dell'indirizzo da cui lo chiedi. In produzione apre il sito a tutti i crawler che mi interessano, sul sito di prova lo chiude. Ti mostro entrambe le versioni, riga per riga, poi passo agli esempi pronti, ai bot AI e ai modi per testare il file.

Cosa fa il robots.txt e cosa non fa#

Secondo l'introduzione di Google al robots.txt (ultimo aggiornamento della pagina: 10 dicembre 2025), il file dice ai crawler quali URL possono raggiungere e serve soprattutto a evitare di sovraccaricare il server. Google è esplicito su un punto: non è un meccanismo per tenere una pagina fuori da Google. Per quello servono noindex o una password.

Ne seguono tre limiti pratici.

• Non deindicizza. Google scrive che può trovare e indicizzare un URL bloccato se è linkato da altre pagine del web. L'URL può comparire nei risultati, senza descrizione.
• Non protegge dati. Lo standard lo dice senza giri: l'RFC 9309 (Proposed Standard, settembre 2022) precisa che le regole non sono una forma di autorizzazione all'accesso e che elencare dei percorsi in un file pubblico può renderli più facili da scoprire. Per i documenti riservati servono login e permessi sul server.
• Non obbliga nessuno. Rispettarlo spetta al crawler, e crawler diversi possono interpretare la sintassi in modo diverso.

Il robots.txt governa la scansione, il noindex l'indicizzazione: due leve diverse, che sulla stessa pagina possono annullarsi. La visione d'insieme dei controlli tecnici è nella guida alla SEO tecnica.

Dove sta e come è fatto un file robots.txt#

Nelle specifiche di Google (aggiornate il 31 agosto 2026) il file si chiama robots.txt, sta nella radice dell'host (https://tuosito.it/robots.txt), è testo semplice in UTF-8 e vale solo per il protocollo, l'host e la porta su cui è pubblicato. Un sottodominio ha il suo file; un file in una sottocartella non viene cercato.

Un file robots.txt è fatto di gruppi. Ogni gruppo comincia con una o più righe User-agent e continua con le regole che valgono per quei crawler. Google supporta quattro campi:

• User-agent: il nome del crawler a cui si applica il gruppo; * vale per tutti quelli senza un gruppo proprio.
• Disallow: un percorso che il crawler non deve scansionare.
• Allow: un percorso consentito, utile per fare un'eccezione dentro un percorso vietato.
• Sitemap: l'indirizzo della sitemap. Non appartiene a un gruppo e puoi metterne più di una; ne parlo nella guida alle sitemap. Dichiararla nel robots.txt non è obbligatorio, ma raccoglie in un punto solo gli indirizzi da leggere.

Google precisa che altri campi, come crawl-delay, non sono supportati. Anthropic dichiara invece di supportare Crawl-delay per ClaudeBot: è un'estensione non standard, quindi dipende dal bot.

Le regole di sintassi che cambiano il risultato#

Tutti i punti vengono dalle specifiche di Google, tranne dove indico l'RFC.

• Maiuscole. I nomi dei campi e i valori di User-agent non distinguono maiuscole e minuscole. I percorsi di Allow e Disallow sì: /Foto/ e /foto/ sono due percorsi diversi.
• Caratteri jolly. * sta per zero o più caratteri qualsiasi, $ segna la fine dell'URL. Disallow: /*.pdf$ blocca gli URL che finiscono in .pdf.
• Regola più specifica. Se più regole corrispondono, vince quella con il percorso più lungo. Se sono in conflitto, vince la meno restrittiva. L'RFC 9309 dice la stessa cosa del percorso più lungo.
• Un solo gruppo per crawler. Ogni crawler usa il gruppo il cui User-agent lo descrive meglio e ignora gli altri. I gruppi specifici non si fondono con quello *: un bot con un gruppo proprio non eredita le regole del gruppo generale. L'ordine dei gruppi non conta.
• Dimensione. Google legge al massimo 500 KiB; il resto viene ignorato. L'RFC fissa lo stesso minimo di 500 kibibyte per chi implementa un parser.
• Cache. Google di norma rilegge il file al massimo ogni 24 ore. Dopo una modifica non aspettarti effetto immediato.
• Risposta HTTP. Un errore 4xx (tranne 429) vale come "nessun robots.txt valido": nessun limite alla scansione. Un errore 5xx ferma la scansione per le prime 12 ore, poi Google usa l'ultima copia buona per un massimo di 30 giorni. Dopo 30 giorni, se il sito risponde, agisce come se il file non esistesse. L'RFC è più drastico: con un 5xx il crawler deve assumere un divieto totale.

La conseguenza pratica del terzo e quarto punto è questa: se aggiungi un Disallow al gruppo * ma un bot ha un gruppo suo, quel bot continua a entrare.

Il robots.txt di seo.srl, gruppo per gruppo#

Il file di produzione nasce dall'elenco di crawler che teniamo nel codice del sito. Questo è il testo che il server restituisce su seo.srl:

# SEO SRL - https://seo.srl/
# Indice del sito per le AI: https://seo.srl/llms.txt
# Testo completo per le AI: https://seo.srl/llms-full.txt

User-agent: *
Allow: /

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot-Extended
Allow: /

User-agent: Bingbot
Allow: /

Sitemap: https://seo.srl/sitemap.xml
Sitemap: https://seo.srl/news-sitemap.xml

Cosa fa ogni parte, e perché l'ho scritta così.

1. I commenti in cima. Le righe con # sono ignorate dai crawler, ma le legge chi apre il file. Rimandano a llms.txt e llms-full.txt, che il sito genera dai propri contenuti. Cosa sono e perché non li considero una leva di posizionamento lo spiego nella guida a llms.txt.
2. Il gruppo User-agent: * con Allow: /. Dice che tutto il sito è scansionabile da qualunque crawler. Un file vuoto avrebbe lo stesso effetto; scriverlo rende la scelta leggibile.
3. Nove gruppi espliciti. Per ogni bot di OpenAI, Anthropic, Perplexity, Google, Apple e Bing c'è un gruppo con Allow: /. Oggi non cambiano nulla rispetto al gruppo generale. Li tengo per due motivi. Il primo: ogni nome è una decisione dichiarata, e aprire GPTBot, ClaudeBot, Google-Extended e Applebot-Extended significa accettare l'uso dei contenuti per l'addestramento. Il secondo: per la regola del gruppo più specifico, se un giorno aggiungessi un Disallow al gruppo *, questi bot resterebbero comunque aperti, finché non li tocco io.
4. Le due righe Sitemap. Una per la sitemap principale, una per la news-sitemap, che elenca le notizie uscite nelle ultime 48 ore (vuota se non ce ne sono).

Sullo staging, cioè il sito di prova e le anteprime, lo stesso indirizzo /robots.txt risponde un'altra cosa:

User-agent: *
Disallow: /

Nessuna riga Sitemap, nessun gruppo dedicato. Il server decide in base all'host della richiesta: sono staging gli indirizzi che finiscono in .lovable.app o .lovableproject.com e quelli locali; tutto il resto, compreso www.seo.srl, è produzione. Se gli host di una richiesta sono contrastanti, per esempio con un proxy che riscrive l'host, vince la produzione: un blocco per errore sul sito vero costa molto più di un'anteprima aperta.

Staging: perché il Disallow da solo non basta#

Lo staging non ha solo il robots.txt che blocca tutto. Il server aggiunge a ogni risposta l'intestazione X-Robots-Tag: noindex, nofollow e riscrive il meta robots delle pagine HTML nello stesso modo. La doppia protezione è voluta.

Un Disallow impedisce al crawler di scaricare la pagina, e quindi di leggere il noindex che c'è dentro. Se un sito di prova è già finito nell'indice, magari perché un link è uscito in una mail o in un documento, aggiungere Disallow: / non lo toglie: l'URL resta, come Google stesso avverte, anche senza descrizione. Il noindex funziona solo se il crawler può scaricare la pagina; il blocco nel robots.txt lo rende invisibile. Le due regole si annullano a vicenda, come Google segnala quando scrive che combinare regole di scansione e di indicizzazione può farle contrastare.

Per togliere dall'indice un sito di prova già indicizzato, quindi, il robots.txt non è lo strumento. Le alternative che Google elenca nella sua nota sulle regole non supportate sono un noindex in intestazione o nel meta tag (con la scansione consentita), un 404 o 410, una pagina dietro login, e lo strumento di rimozione degli URL di Search Console, che però è una rimozione temporanea. In pratica: rimozione in Search Console per l'effetto immediato, login o noindex leggibile per quello che dura.

Per questo l'header c'è fin dal primo giorno. Non sostituisce il robots.txt: copre i casi in cui qualcuno scarica la pagina comunque, per esempio un crawler che non rispetta il file, e vale quando il blocco nel robots.txt viene tolto. La regola che non rompo mai è un'altra: il sito vero non deve ricevere né l'header né il blocco. Un Disallow: / uscito dallo staging e rimasto dopo il lancio è l'errore più costoso di questa pagina, e lo trovi nella tabella degli errori.

Esempi pronti#

Sono modelli da adattare: percorsi e parametri sono ipotetici. Per lo staging vale il blocco totale visto sopra, in coppia con un login. Provali sempre con i metodi della sezione sui test.

Sito WordPress#

Esempio: area di amministrazione chiusa, eccetto il file che molti temi e plugin chiamano dal front-end. Vince la regola più lunga, quindi l'Allow sul file singolo prevale sul Disallow della cartella.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.tuosito.it/sitemap.xml

Non bloccare le cartelle con CSS, JavaScript e immagini del tema: Google avverte che i file di risorse si possono bloccare solo se la pagina non ne risente in modo significativo, perché bloccare ciò che serve a capire la pagina può peggiorarne l'analisi.

E-commerce con filtri e ordinamenti#

Esempio: un negozio che genera migliaia di URL con parametri di filtro e ordinamento. Il robots.txt riduce la scansione di quelle varianti, ma non risolve i duplicati: per quello ci sono il tag canonical e una struttura di link interni pulita.

User-agent: *
Disallow: /*?ordina=
Disallow: /*?*filtro=
Disallow: /carrello/
Disallow: /checkout/
Disallow: /account/

Sitemap: https://www.tuosito.it/sitemap.xml

Controlla che le categorie da posizionare non finiscano sotto un'espressione con * troppo larga: con i jolly un carattere sbagliato blocca centinaia di URL.

Quali bot AI bloccare e cosa succede#

La distinzione che conta è tra bot di addestramento e bot di ricerca o di risposta. Bloccare un bot di addestramento chiede ai produttori di non usare i tuoi contenuti per i modelli. Bloccare un bot di ricerca ti toglie dalle risposte di quel prodotto. Sono scelte diverse e puoi prenderle separatamente. Le informazioni nella tabella vengono dalle pagine ufficiali di OpenAI, Anthropic, Perplexity, Google e Apple.

Due conseguenze pratiche. La prima: bloccare GPTBot non ti toglie da ChatGPT search, che usa OAI-SearchBot; chi vuole restare nelle risposte ma non nell'addestramento scrive due gruppi diversi, come spiego nella guida a GPTBot. La seconda: Google-Extended non è un interruttore per AI Overview e AI Mode: per comparirvi come link, scrive Google nella pagina sulle funzioni AI e il tuo sito, la pagina deve essere indicizzata e idonea alla Ricerca con uno snippet. Per il confronto piattaforma per piattaforma e per i controlli oltre il robots.txt (log, firewall, CDN) c'è la pagina su come comparire nelle risposte AI.

Se il sito vive di visibilità, lascio aperti i bot di ricerca e valuto caso per caso quelli di addestramento. Se vendi contenuti a pagamento o hai vincoli di licenza, blocco l'addestramento e tengo aperta la ricerca. Esempio: un editore vuole restare in ChatGPT e Perplexity ma non nei modelli.

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Perplexity scrive che i sistemi possono impiegare fino a 24 ore per recepire le modifiche; OpenAI indica circa 24 ore per le modifiche che riguardano OAI-SearchBot. I bot avviati da un utente (ChatGPT-User, Perplexity-User) non si governano con il robots.txt; se vuoi limitarli, serve una regola sul server.

Come testare il robots.txt#

Chi cerca un "tester robots txt" ricorda il vecchio strumento di Search Console. Quello strumento è stato sostituito dal report robots.txt: lo riporta Search Engine Land, citando la decisione di Google di dismettere il tester. Non prova regole: mostra come Google ha letto il file.

Dalla guida di Search Console il report mostra i file robots.txt trovati per i primi 20 host del sito, con l'indirizzo, lo stato del recupero (recuperato o non recuperato), la data dell'ultimo controllo, la dimensione e il numero di problemi di analisi. Gli errori impediscono di usare una regola, gli avvisi no. Puoi aprire l'ultima versione recuperata, con errori evidenziati, vedere le versioni dei 30 giorni precedenti e chiedere una nuova scansione dopo una correzione. Per lo strumento in generale c'è la guida a Google Search Console.

Per provare una regola prima di pubblicarla serve un parser. Google pubblica su GitHub la sua libreria robotstxt, in C++ e con licenza Apache 2.0: il suo README la descrive come una versione leggermente modificata del parser e del matcher che Googlebot usa per decidere quali URL può scansionare. Contiene un programma da riga di comando, robots_main, che dato un file, un user agent e un URL risponde ALLOWED o DISALLOWED (codice di uscita 0 o 1). Si compila con Bazel o CMake, quindi serve un po' di dimestichezza col terminale.

bazel run robots_main -- ./robots.txt Googlebot https://www.tuosito.it/carrello/

Per chi non vuole compilare nulla, il controllo minimo che consiglio a ogni rilascio:

1. Apri /robots.txt nel browser: deve essere testo semplice, senza HTML.
2. Controlla il codice di risposta con curl -I https://tuosito.it/robots.txt: deve essere 200. Un 5xx ferma la scansione, un 404 vale "tutto consentito".
3. Guarda nel report di Search Console se il file risulta recuperato e senza errori.
4. Con Controllo URL verifica due o tre pagine importanti: non devono risultare bloccate dal robots.txt.

Errori tipici#

Se stai sistemando un sito intero, il robots.txt è una voce di un controllo più ampio, che trovi nell'audit SEO in 12 passaggi.