Robots.txt: cos’è, come si scrive e come si testa nel 2026

Il robots.txt è un file di testo pubblico, uno per host, che sta nella root del sito e dice ai crawler quali percorsi possono richiedere e quali no. Non toglie pagine da Google: quello è mestiere del noindex, e la confusione fra le due cose è l’errore che vedo più spesso nei file veri.

Nessuno è obbligato a rispettarlo: i crawler seri girano al largo, gli altri passano lo stesso. E un Disallow non nasconde la pagina, la segnala, perché il file è pubblico e un URL bloccato può comparire in SERP anche senza essere mai stato scansionato. Dal settembre 2022 il protocollo è uno standard IETF, RFC 9309, e i campi che Google supporta sono quattro.

Come si scrive una regola che colpisce quello che vuoi, quale direttiva vince quando due si contraddicono, cosa succede alla scansione se il file risponde 500, come si testa adesso che il robots.txt Tester di Search Console non c’è più e con quali token si fermano davvero i crawler AI: sono le domande a cui questo pezzo risponde, con gli esempi pronti da copiare.

Cos’è il robots.txt

Il robots.txt è un file di testo pubblico, uno per host, che sta nella root del sito e dice a ogni crawler quali percorsi può richiedere e quali no.

Tre fatti lo reggono, e sono tutti verificabili in dieci secondi. È pubblico: chiunque può aprire esempio.it/robots.txt nel browser, incluso il tuo concorrente. Sta in root e da nessun’altra parte, perché è lì che i crawler vanno a cercarlo. E gestisce il traffico di scansione, non l’indice: Google scrive che il robots.txt «non è un meccanismo che permette di escludere una pagina web da Google».

È il cartello all’ingresso di un cantiere. Dice dove si può passare, chi lo rispetta gira largo, e non impedisce fisicamente niente a nessuno.

Qui va corretta una cosa che si legge ancora in italiano, anche in cima alla SERP: Fattoretto apre la sua guida dichiarando che non esiste uno standard ufficiale e rimanda al documento del 1994. Non è più vero dal settembre 2022, quando il Robots Exclusion Protocol è diventato RFC 9309, standard IETF, firmato da Martijn Koster, Gary Illyes, Henner Zeller e Lizzi Sassman.

Dalla RFC arrivano gratis i punti su cui queste guide inciampano:

• posizione obbligatoria in /robots.txt sulla root dell’host;
• codifica UTF-8, media type text/plain;
• il matching parte dal primo ottetto del percorso ed è case-sensitive;
• fra due regole vince quella con più ottetti;
• i crawler devono processare almeno 500 KiB di file;
• un 4xx vale come «nessuna restrizione», un 5xx come disallow totale;
• i crawler dovrebbero seguire almeno cinque redirect consecutivi;
• la copia in cache non andrebbe usata per più di 24 ore.

Sono le stesse regole che poi ritrovi, con qualche dettaglio in più, nella documentazione di Google. Averle in uno standard IETF cambia il tono della discussione: non stai seguendo una convenzione di trent’anni fa per gentilezza, stai implementando un protocollo.

Il robots.txt è obbligatorio?

No. Il file è facoltativo, e un sito senza robots.txt viene scansionato senza restrizioni.

Roberto Serra scrive il contrario. La smentita sta nella pagina che tutti linkano senza leggerla: per Google un 4xx sul robots.txt (il 429 escluso) significa che il crawler procede come se il file non esistesse, quindi nessuna restrizione di scansione. Chi non ha niente da bloccare può lasciare quel 404 dov’è: il comportamento previsto è esattamente quello.

Serve quando hai qualcosa da limitare: un’area amministrativa, un carrello, un motore di ricerca interno che genera URL a valanga, un ambiente di staging. Se il tuo sito ha venti pagine e nessuna area riservata, il file più onesto che puoi pubblicare è nessun file.

Detto questo, un robots.txt che risponde 200 con dentro almeno la riga Sitemap: costa zero e ti evita di scoprire fra sei mesi che il server risponde 500 su quell’URL. Il motivo lo trovi più avanti, nella sezione sui codici di stato.

Dove deve stare il file (e per cosa vale)

Il file si chiama robots.txt, tutto minuscolo, e sta nella root dell’host: https://esempio.it/robots.txt. Un Robots.txt con la maiuscola o un file in /blog/robots.txt non viene letto da nessuno.

Il punto che quasi tutte queste guide si perdono è l’ambito di validità. Google lo documenta secco: il file si applica solo al protocollo, all’host e alla porta in cui è pubblicato. Tradotto in cose che ti capitano davvero:

• http://esempio.it/robots.txt e https://esempio.it/robots.txt sono due file distinti. Se hai migrato a HTTPS e il vecchio virtual host risponde ancora, hai due politiche di scansione in giro;
• esempio.it e shop.esempio.it sono due host, quindi due file. Le regole di uno non toccano l’altro;
• una porta diversa è un file diverso. https://esempio.it:8443/ vuole il suo;
• in sottodirectory non funziona. esempio.it/negozio/robots.txt è un file di testo come un altro, che nessun crawler andrà a cercare.

Su un multisito, o su un e-commerce con il blog su sottodominio, ti servono più file proprio per questo: uno per host, ognuno con la sua riga Sitemap:.

Sull’encoding: UTF-8, e il file deve essere testo semplice. Se il tuo editor ci mette davanti un BOM, Googlebot lo ignora (ne parlo nella lista degli errori), ma resta sporcizia che qualche parser di terze parti non digerisce.

Scansione e indicizzazione: la confusione che costa traffico

Il Disallow ferma la scansione, non l’indicizzazione. Una pagina bloccata dal robots.txt può comunque comparire in SERP, senza descrizione, se qualcun altro la linka: Google lo scrive nella pagina introduttiva sul robots.txt.

Ragionaci un attimo e il meccanismo si spiega da solo. Il crawler non entra nella pagina, quindi non ne conosce il contenuto. Ma l’URL lo conosce lo stesso, perché gliel’ha passato un link da un altro sito. Ha un indirizzo e nessuna idea di cosa ci sia dentro, e quello che ne esce in SERP è esattamente questo: un titolo pescato dagli anchor text e la riga «Non è disponibile una descrizione per questo risultato».

Da qui nasce la trappola vera, quella che costa traffico e che vedo applicata con le migliori intenzioni: mettere noindex sulla pagina e in più bloccarla con Disallow. Le due istruzioni si annullano. Google: «Se la pagina è bloccata da un file robots.txt oppure non è possibile accedervi, il crawler non rileverà mai la regola noindex». Hai messo un cartello dentro una stanza chiusa a chiave e ti aspetti che qualcuno lo legga.

La frase operativa che manca in tutte e cinque le guide italiane: per togliere una pagina dall’indice devi rimuovere il Disallow, lasciare che il crawler entri e legga il noindex, e lasciarcelo entrare anche dopo, perché il noindex vale solo finché Google può rileggerlo. Se rimetti il blocco, l’URL può rientrare in indice dai link degli altri, senza descrizione.

Qui va corretto anche il verso della spiegazione. Roberto Serra la racconta al rovescio, come se un URL in disallow finisse in indice «con l’unica eccezione del meta noindex»: è proprio il caso in cui il noindex non può funzionare. PrimoSuGoogle scrive invece che il Disallow impedisce l’indicizzazione, che è la stessa cosa detta dall’altra parte.

Cosa usare per ottenere cosa:

Regola pratica da appiccicare al monitor: se la pagina non deve essere vista da nessuno, autenticazione. Se non deve stare in SERP, noindex e nessun blocco. Se non deve consumare scansione, Disallow e amen se l’URL resta lì.

La sintassi: le quattro direttive che Google supporta

Google supporta quattro campi: user-agent, allow, disallow, sitemap. Testuale dalla documentazione: «Altri campi, come crawl-delay, non sono supportati».

Un file valido è fatto di gruppi. Un gruppo comincia con una o più righe User-agent e prosegue con le regole che valgono per quegli user-agent, fino alla riga vuota o al gruppo successivo.

# Vale per tutti i crawler che non hanno un gruppo dedicato
User-agent: *
Disallow: /carrello/
Disallow: /checkout/
Allow: /carrello/guida-alle-taglie/

# Gruppo separato: Googlebot legge questo e ignora quello sopra
User-agent: Googlebot
Disallow: /stampa/

Sitemap: https://esempio.it/sitemap_index.xml

Le regole della grammatica, in fila:

• una direttiva per riga. User-agent: *Disallow: /wp-admin/ sembra una riga, ma sono due direttive incollate e non funziona. È l’errore che si vede nelle guide dove i blocchi di codice mancano e le direttive collassano dentro il paragrafo;
• ogni gruppo ha la sua riga User-agent. Netsons pubblica uno snippet con Crawl-delay: 5 senza nessun User-agent sopra: copiato così, non fa niente;
• i nomi delle direttive non sono case-sensitive, i percorsi sì. disallow: e Disallow: sono equivalenti, /Prodotti/ e /prodotti/ no;
• i commenti cominciano con # e valgono fino a fine riga;
• un crawler legge un solo gruppo, quello più specifico che lo nomina. Se esiste User-agent: Googlebot, Googlebot ignora il gruppo *, comprese le regole che lì avevi messo per tutti;
• Disallow: vuoto significa «niente di bloccato», non «tutto bloccato»;
• il match del nome dello user-agent non guarda maiuscole e minuscole: googlebot, Googlebot e GOOGLEBOT sono lo stesso bot.

Quello sul gruppo unico è il punto che si paga più caro. Metti un gruppo per Googlebot per aggiungere una singola riga, e senza accorgertene hai buttato via tutte le regole del gruppo generico per il crawler che ti interessa di più.

Wildcard * e $: come funziona davvero il matching

Il match è per prefisso, a partire dal primo carattere del percorso, e Google supporta due caratteri speciali: * per zero o più caratteri qualsiasi, $ per la fine dell’URL.

Quindi Disallow: /priv blocca /privato/, /privacy e /privilegi/nascosti.html, perché tutti e tre cominciano con quella sequenza. È il comportamento standard, e chi si aspetta un match sulla cartella intera si ritrova a bloccare la pagina privacy per sbaglio.

Gli esempi dalla documentazione ufficiale:

User-agent: Googlebot
# Blocca tutti i .gif
Disallow: /*.gif$

Il caso che chiarisce tutto è quello del dollaro. Disallow: /*.xls$ non blocca /cats.xls?personality=loki, perché quell’URL non finisce con .xls: finisce con la query string. Il $ ancora il match alla fine dell’URL e la fine dell’URL comprende i parametri.

Qui va corretto PrimoSuGoogle, che presenta la wildcard /wp*/ come una sintassi «non recepita da tutti i motori». Google documenta * e $ nella pagina sulle regole utili, con tanto di snippet. Che altri crawler minori le implementino male è un’altra questione, e riguarda loro.

Se due regole si contraddicono, quale vince

Vince la regola con il percorso più lungo. A parità di lunghezza vince la meno restrittiva, cioè Allow. Non è «dipende»: è una regola deterministica documentata e puoi verificarla contando i caratteri.

Primo caso. Disallow: /privato/ è lungo 9 caratteri, Allow: /privato/media/ ne ha 15: per l’URL /privato/media/foto.jpg vince l’Allow, e il file passa.

Secondo caso, quello che hai già nel robots.txt di WordPress senza averlo mai letto. Disallow: /wp-admin/ sono 10 caratteri, Allow: /wp-admin/admin-ajax.php sono 24: l’area admin resta chiusa, il singolo endpoint AJAX resta aperto. Ecco perché quelle due righe convivono nel file di default senza contraddirsi.

Terzo caso, quello che nelle cinque guide italiane non trovi: anche con una wildcard di mezzo l’esito è documentato. Google scrive che la regola vale «including those with wildcards», e l’esempio ce l’ha in pagina. Per https://example.com/page.htm, con allow: /page da una parte e disallow: /*.htm dall’altra, la regola applicabile è il disallow, «because the rule path is longer and it matches more characters in the URL, so it’s more specific»: cinque caratteri contro sei, e l’URL resta bloccato.

Morale: il conteggio dei caratteri risponde sempre, wildcard comprese. Solo che contare a occhio i caratteri di una wildcard è più facile a dirsi che a farsi, quindi quella regola testala con il parser locale, che trovi più avanti.

Direttive morte: noindex, nofollow e crawl-delay

Dentro il robots.txt, noindex, nofollow e crawl-delay non fanno niente per Google. Data precisa: il codice che le gestiva è stato ritirato il 1° settembre 2019, annunciato il 2 luglio con un post su Search Central.

Nessuna delle cinque guide italiane cita la data o il post. Continuano a circolare file con dentro Noindex: /cartella/, che è una riga che il parser di Google salta come se fosse un commento. Se ce l’hai, cancellala: ti sta solo dando l’impressione di aver protetto qualcosa.

Le alternative indicate nel post ufficiale sono il noindex nei meta tag, lo status 404 o 410, la protezione con password.

Poi c’è il seguito, e qui la faccenda diventa quasi comica. Fattoretto e Roberto Serra, dopo aver detto che il crawl-delay non serve con Google, ti rimandano allo strumento di limitazione della frequenza di scansione di Search Console. Quello strumento è stato deprecato l’8 gennaio 2024. Due istruzioni operative morte nella stessa pagina, una che rimanda all’altra. Googlebot oggi regola da solo la velocità in base alle risposte del server: se gli mandi 500 persistenti o tempi di risposta lunghi, rallenta senza che tu gli chieda niente.

Il crawl-delay sopravvive su Bing, che lo documenta dal 2012: «BingBot honors the Crawl-delay directive». Nello stesso post c’è la parte che quasi nessuno riporta: il numero non è una frequenza, è la dimensione di una finestra temporale, da 1 a 30 secondi, dentro cui BingBot passa una volta sola. Su Yandex no: è fuori uso dal 22 febbraio 2018, sostituito dall’impostazione di velocità di scansione dentro Yandex Webmaster. Tienilo solo se ti serve per Bing, e mettilo dentro il suo gruppo User-agent: Bingbot, non nel gruppo generico dove Google se lo trova davanti e lo scavalca.

È il terzo strato della stessa storia: una direttiva morta per un motore, viva per un altro, e morta da otto anni per un terzo, che continua a circolare in italiano come se fosse una sola cosa.

La direttiva Sitemap

Sitemap è l’unica direttiva non-standard che tutti i motori principali supportano, e vuole l’URL assoluto.

Sitemap: https://esempio.it/sitemap_index.xml
Sitemap: https://esempio.it/sitemap-news.xml

Due cose che quelle guide non dicono, e che cambiano il modo in cui scrivi il file.

La prima: è indipendente dal gruppo user-agent. Non appartiene a nessun gruppo, vale per chiunque legga il file, e la posizione nel documento non conta. Puoi metterla in cima, in fondo o in mezzo a due gruppi: il risultato è lo stesso. Molte guide la infilano dentro un gruppo User-agent: * come se fosse una regola di quel gruppo, e la cosa non fa danni, ma racconta male come funziona.

La seconda: l’URL relativo non funziona. Sitemap: /sitemap.xml è una riga inutile. Ci vuole protocollo e host, sempre.

Righe multiple per sitemap multiple, oppure una riga sola che punta a un sitemap index. Se il sito ha più host, la scelta pulita è che ogni robots.txt punti alle sitemap del proprio host, ma non è un obbligo: la specifica dice che l’URL «doesn’t have to be on the same host as the robots.txt file». Il vincolo vero è dentro il file, non su dove lo ospiti — ogni sitemap deve contenere solo URL del sito a cui si riferisce. Come funziona, e quando conviene centralizzarle, l’ho scritto in Sitemap XML.

Esempi di robots.txt pronti da copiare

Blocchi copiabili, tutti allineati alle regole ufficiali di Google. Sostituisci il dominio e vai.

Sito tutto aperto. Il Disallow vuoto significa «niente di bloccato».

User-agent: *
Disallow:

Sito tutto chiuso. Con l’avvertenza che conta: questo ferma la scansione, non l’indicizzazione. Gli URL già noti a Google possono restare in SERP senza descrizione, e nessun noindex verrà mai letto perché il crawler non entra.

User-agent: *
Disallow: /

Una cartella (e le sue sottocartelle). La barra finale è tutt’altro che decorativa: senza, blocchi anche /calendario-eventi.html.

User-agent: *
Disallow: /calendar/
Disallow: /junk/

Se il bersaglio è un crawler solo e gli altri restano liberi, il suo gruppo viene prima di quello generico.

User-agent: Unnecessarybot
Disallow: /

User-agent: *
Allow: /

Per un’estensione sola serve il $, che ancora il match alla fine dell’URL.

User-agent: Googlebot
Disallow: /*.gif$

URL con parametri. Segue dalle wildcard documentate: * copre zero o più caratteri, quindi /*?ordina= prende qualunque URL con quel parametro, ovunque si trovi.

User-agent: *
Disallow: /*?ordina=
Disallow: /*?filtro=

Occhio a Disallow: /*? secco, che si vede spesso copiato in giro: blocca ogni URL con un punto interrogativo, comprese le pagine che magari volevi in indice. Nella regola va il nome del parametro per intero.

Per lo staging il blocco totale va bene come promemoria, ma da solo non ti protegge: chiunque può aprire il file e leggere l’indirizzo che stai cercando di nascondere. La protezione seria è l’autenticazione HTTP davanti all’ambiente.

User-agent: *
Disallow: /

File completo per WordPress.

# robots.txt - esempio.it
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

# Ricerca interna: URL infiniti, zero valore in indice
Disallow: /?s=
Disallow: /search/

Sitemap: https://esempio.it/wp-sitemap.xml

File completo per un e-commerce generico.

# robots.txt - negozio.it
User-agent: *

# Area transazionale e account
Disallow: /carrello/
Disallow: /checkout/
Disallow: /account/

# Ricerca interna e ordinamenti: combinazioni infinite
Disallow: /*?ordina=
Disallow: /*?cerca=

# Il feed dei prodotti serve al comparatore, non a Google
Disallow: /feed-prodotti.xml

Sitemap: https://negozio.it/sitemap_index.xml

Sui filtri di navigazione, prima di riempire il robots.txt di Disallow, conviene decidere quali combinazioni meritano di esistere come URL. Il blocco viene dopo.

Cosa il robots.txt non protegge

Il robots.txt non protegge niente. È un file pubblico, e ogni riga che ci scrivi è un indirizzo che stai pubblicando.

Google lo dice nella pagina introduttiva: gli URL in Disallow possono comunque essere indicizzati, e per tenere fuori dei contenuti servono la protezione tramite password oppure il noindex. Per i file che non sono HTML (PDF, immagini, fogli di calcolo) la terza via è l’header X-Robots-Tag, documentato qui.

Mettere Disallow: /admin-segreto-2019/ nel robots.txt è come attaccare sulla porta di casa un biglietto con scritto «per favore non guardate sotto lo zerbino». Hai appena detto a tutti dove guardare, e chi non ha buone intenzioni il tuo file lo apre per primo, proprio per quello.

Secondo punto, meno drammatico ma più diffuso: non bloccare CSS e JavaScript. Googlebot renderizza la pagina, e se le risorse che servono a costruirla sono in Disallow la vede storta, o non la vede proprio. Regole tipo Disallow: /wp-content/themes/ o Disallow: /*.js$ sono un residuo di manuali del 2012 che ogni tanto risorge in qualche file ereditato. Se lo trovi, toglilo e verifica il rendering con Controllo URL.

Come si testa il robots.txt oggi

Lo strumento di verifica che Google documenta oggi è il rapporto robots.txt in Search Console, non il vecchio robots.txt Tester. Le guide che ti rimandano al tester sono ferme al 2023, e sono quattro delle cinque che ho analizzato.

La cosa buffa è che il tester è la parte più «pratica» di quelle guide: screenshot, frecce rosse, il campo dove incolli l’URL. Una cabina telefonica ben tenuta.

Oggi i modi sono quattro, dal più immediato al più preciso, e ognuno risponde a una domanda diversa:

1. curl, per sapere cosa risponde davvero il server (status code e contenuto reale, non quello che credi di aver caricato);
2. il rapporto robots.txt in Search Console, per sapere cosa ha visto Google e quando;
3. Controllo URL, per sapere se una singola pagina è bloccata;
4. il parser open source di Google, per testare una regola in locale senza aspettare nessuno.

I primi due rispondono a «il file va bene». Gli altri due a «questo URL passa». Sono domande diverse e vanno fatte tutte e due.

Il rapporto robots.txt in Search Console

Il rapporto sta in Search Console, sotto Impostazioni, ed è disponibile solo per le proprietà a livello di dominio o con prefisso URL senza percorso. Se la tua proprietà è esempio.it/blog/, il rapporto non lo vedi: è il primo motivo per cui la gente pensa che sia sparito anche questo.

Cosa mostra, riga per riga, per i 20 host principali della proprietà:

• il percorso del file, host per host (dominio principale, sottodomini, versione http e https, che come hai visto sono file diversi);
• lo stato del recupero: Recuperato, Non recuperato - Non trovato (404), Non recuperato - Qualsiasi altro motivo;
• la data dell’ultima scansione riuscita;
• la dimensione del file;
• il numero di problemi rilevati.

Un 404 lì dentro non è un allarme: significa che il file non c’è e che il sito viene scansionato senza restrizioni. Non recuperato - Qualsiasi altro motivo invece merita attenzione, perché lì dentro finiscono gli errori di server e le configurazioni che rompono il recupero.

Qui si risponde anche all’unica PAA che la SERP italiana mostra su questo argomento: «Cosa significa robots.txt non è valido?». Nella pratica sono tre cose, in ordine di frequenza:

• il file risponde 500 invece che 200, di solito per un errore dell’applicazione o del proxy;
• il file arriva con un Content-Type sbagliato, tipo text/html, perché a rispondere non è un file ma una pagina generata (spesso una 404 vestita bene);
• il file è dietro a una catena di redirect troppo lunga: oltre il quinto salto Google smette e tratta il tutto come un 404.

Se hai appena corretto il file e vuoi che Google se ne accorga, dal rapporto puoi usare Richiedi una nuova scansione. Serve, perché la copia in cache può restare in giro più a lungo di quanto immagini.

Controllo URL: la risposta sulla singola pagina

Lo strumento è Controllo URL in Search Console, e risponde all’altra domanda: non «il file va bene», ma «questo URL passa».

Incolli l’URL nella barra in alto, e nella sezione Copertura leggi «Scansione consentita?» con il suo sì o no. Ti dice se l’URL è bloccato dal robots.txt, non quale riga lo blocca: per quella Google stessa rimanda a un validatore, e il parser locale della sezione successiva fa lo stesso lavoro in casa. Ecco perché i quattro metodi servono tutti e non si sovrappongono.

Due limiti da tenere presenti. Funziona solo sulle proprietà che verifichi tu, quindi il sito di un concorrente non lo controlli da lì. E ti dà lo stato dell’ultima scansione: se hai modificato il robots.txt cinque minuti fa, usa «Testa URL pubblicato» per vedere la situazione aggiornata invece della copia in archivio.

curl e il parser open source di Google

Due controlli che puoi fare adesso, senza Search Console e senza aspettare Google.

curl, per vedere cosa risponde davvero il server:

# Status code e header (il Content-Type deve essere text/plain)
curl -sI https://esempio.it/robots.txt

# Il contenuto effettivo, non quello che credi di aver caricato
curl -s https://esempio.it/robots.txt

# Segui i redirect e conta i salti
curl -sIL https://esempio.it/robots.txt | grep -i "^HTTP/"

# I primi tre byte: se leggi efbbbf, c'è un BOM UTF-8
curl -s https://esempio.it/robots.txt | head -c 3 | xxd

Quattro righe smascherano il 500 travestito, il file servito come HTML e la catena di redirect che nessuna interfaccia grafica ti mostra.

Il parser open source di Google. Google ha pubblicato su github.com/google/robotstxt il proprio parser con licenza Apache 2.0, descritto nel repository come codice di produzione leggermente modificato rispetto a quello usato da Googlebot. Lo compili con Bazel o CMake e ti ritrovi un binario che risponde a una domanda sola:

# robots <file locale> <user-agent> <URL>
robots ~/robots.txt "Googlebot" "https://esempio.it/carrello/"
# stampa ALLOWED oppure DISALLOWED
# exit code 0 = permesso, 1 = negato

L’exit code lo rende infilabile in uno script: metti i tuoi venti URL critici in un file, ci passi sopra un ciclo, e sai in dieci secondi se una regola nuova ti sta chiudendo qualcosa che non volevi chiudere.

Riproduce il parsing e il matching di Googlebot riga per riga. Quello che non riproduce è la logica che un crawler applica fuori dal matching, per esempio Googlebot-Image che ricade sulle regole di User-agent: Googlebot quando non trova un gruppo suo: quello il binario non lo modella, e il README lo dice esplicitamente. Con quel limite in testa, resta il modo più diretto per far girare il controllo dentro una pipeline di deploy, invece che scoprire l’errore dal calo delle impression tre settimane dopo.

Codici di stato HTTP: quando il file rompe la scansione

Un errore 500 sul solo robots.txt può spegnere la scansione dell’intero sito. Il capitolo è da incidente di produzione, e fra le cinque guide lo copre un competitor solo, a metà.

Cosa fa Google, status per status:

• 2xx: il file viene elaborato normalmente. È l’unico caso in cui le tue regole contano.
• 3xx: Google segue almeno cinque salti di redirect. Oltre il quinto smette e tratta il file come un 404. I redirect logici (meta refresh, JavaScript) non li segue affatto.
• 4xx, con l’eccezione del 429: nessuna restrizione di scansione. Il crawler procede come se il file non esistesse.
• 429: l’unica eccezione ai 4xx. Google lo esclude da quel trattamento, «Google’s crawlers treat all 4xx errors, except 429, as if a valid robots.txt file didn’t exist», e non scrive cosa fa del robots.txt che risponde 429. Altrove però il 429 compare accanto a 500 e 503, in un contesto diverso: se ti serve ridurre in fretta la frequenza di scansione per un periodo breve, un paio d’ore o un giorno o due, la pagina su come ridurre la frequenza di scansione dice di restituire «500, 503, or 429 HTTP response status code instead of 200», e avverte di non tenerlo oltre uno o due giorni. Il rallentamento scatta quando Google ne incontra un numero significativo, non su un URL solo. Quella è una leva volontaria su tutto il sito, non una regola sul file: sul robots.txt che risponde 429 resti senza documentazione, e il comportamento prudente da parte tua è trattarlo come un 5xx.
• 5xx: Google sospende la scansione per 12 ore e usa la copia in cache del robots.txt fino a 30 giorni. Se una copia in cache non ce l’ha, assume che non ci siano restrizioni. Passati i 30 giorni con l’errore ancora lì la strada si biforca: se il sito per il resto è raggiungibile, Google si comporta come se il robots.txt non esistesse e continua a richiederlo; se invece anche il sito ha problemi di disponibilità, smette di scansionarlo e torna solo ogni tanto a chiedere il file.

Rileggi la riga dei 5xx e guardala dal punto di vista di chi ha appena fatto un deploy sbagliato. Il sito funziona, le pagine rispondono 200, e il solo /robots.txt finisce in errore perché il framework non lo trova più. Da quel momento Googlebot smette di scansionare tutto il sito, e la prima copia in cache che ha in mano è quella vecchia. Il grafico delle scansioni cade a picco e in Search Console non c’è nessun errore rosso da nessuna parte, perché le pagine stanno benissimo.

Di errori SEO che si comportano come l’interruttore generale ne conosco uno solo, e sta qui: una leva sola, e va giù tutto il quadro.

Due numeri per chiudere. Il limite di dimensione è 500 KiB: quello che sta oltre viene ignorato, quindi se hai un file gigantesco generato da uno script, le regole in fondo potrebbero non esistere per Google. E la cache: «In genere, Google memorizza nella cache i contenuti del file robots.txt per un massimo di 24 ore, ma può conservarli più a lungo nei casi in cui non sia possibile aggiornare la versione memorizzata nella cache». Quel «può conservarli più a lungo» spiega la situazione in cui ti sei trovato almeno una volta: hai corretto il file, passa un giorno, e Google si comporta ancora come prima. Per accorciare l’attesa esiste la procedura ufficiale di aggiornamento, che finisce con «Richiedi una nuova scansione» dal rapporto robots.txt.

Il robots.txt su WordPress

Su WordPress il robots.txt di solito non esiste come file. Lo genera al volo la funzione do_robots(), che risponde con header Content-Type: text/plain; charset=utf-8 e produce un contenuto virtuale.

Il default è questo, e ora sai perché le due righe non si contraddicono (10 caratteri contro 24):

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

L’opzione «Scoraggia i motori di ricerca dall’indicizzare questo sito» merita un paragrafo suo, perché quasi tutto quello che si legge in italiano è fermo a com’era otto anni fa. Da WordPress 5.3 do_robots() non emette più Disallow: / quando la visibilità è scoraggiata. L’opzione blog_public viene solo passata come secondo argomento al filtro robots_txt, e al suo posto WordPress mette un meta noindex tramite wp_robots_no_robots(). Il changelog della funzione lo scrive testualmente: «@since 5.3.0 Remove the “Disallow: /” output if search engine visibility is discouraged in favor of robots meta HTML tag via wp_robots_no_robots() filter callback».

Quindi la casella rimasta spuntata dopo il lancio, quel classico che si scopre dopo tre settimane di silenzio, non ti sta bloccando la scansione: ti sta tenendo fuori dall’indice. Il che, se hai letto la sezione su scansione e indicizzazione, è esattamente il modo giusto di fare una cosa che però non volevi fare.

Per aggiungere le tue righe al file virtuale c’è il filtro robots_txt:

add_filter( 'robots_txt', function ( $output, $public ) {
	$output .= "Disallow: /?s=\n";
	$output .= "Sitemap: https://esempio.it/wp-sitemap.xml\n";
	return $output;
}, 10, 2 );

Yoast e Rank Math fanno la stessa cosa con un editor grafico, e ti fanno scrivere sopra il virtuale senza toccare il codice. Va benissimo.

Quando serve un file fisico in root? Quando ti serve controllo pieno o quando il virtuale non risponde. Un robots.txt vero dentro la root del sito vince sul virtuale: il server lo serve prima che WordPress entri in gioco, e da quel momento tutti i filtri e i pannelli dei plugin diventano decorativi. Capita più spesso di quanto sembri: modifichi il file da Yoast, salvi, ricarichi la pagina e non cambia niente, perché c’è un file fisico lasciato lì da una migrazione che se lo mangia.

Controllo veloce: curl -sI https://esempio.it/robots.txt. Se nella risposta manca charset=utf-8 nel Content-Type, con ogni probabilità stai leggendo un file fisico e non l’output di do_robots().

Crawler AI: come si governano davvero

Il robots.txt è l’unico canale che le pagine ufficiali di OpenAI, Anthropic e Perplexity indicano tutte e tre per dire di no. Accanto pubblicano gli intervalli IP dei propri bot, che però servono ad altro: verificarli o filtrarli dal firewall, cioè a valle.

Anthropic è la più esplicita sul punto, e lo scrive contro il proprio interesse: bloccare gli IP «may not work correctly or persistently guarantee an opt-out, as doing so impedes our ability to read your robots.txt file». Se gli chiudi la porta in faccia, non può leggere il cartello con cui gli stavi dicendo di andarsene.

Su questo territorio le guide italiane sono quasi mute: di cinque, quattro non nominano nessuno dei bot AI, e la quinta se la cava con una frase e un link a un altro suo articolo.

Il punto è che bloccare «l’AI» tutta insieme è quasi sempre la scelta sbagliata, e non per ragioni ideologiche: quei bot fanno tre mestieri diversi e tu ne stai giudicando uno solo.

Addestramento, ricerca, fetch on-demand: tre mestieri diversi

I bot AI si dividono in tre categorie, e confonderle costa visibilità.

Addestramento. Raccolgono contenuti che possono finire nei dati di training dei modelli. Bloccarli ti esclude dall’addestramento e non ti toglie niente altro. Qui stanno GPTBot per OpenAI e ClaudeBot per Anthropic.

Ricerca. Alimentano l’indice che il prodotto interroga quando risponde a una domanda con le fonti a fianco. OAI-SearchBot serve a mostrare i siti nei risultati di ricerca di ChatGPT, Claude-SearchBot analizza i contenuti per la qualità dei risultati di Claude, PerplexityBot indicizza i siti per i risultati di Perplexity e la documentazione precisa che non serve ad addestrare modelli. Se li blocchi, esci dai risultati. Non dai dataset: dai risultati, cioè dal posto dove qualcuno avrebbe potuto trovarti e cliccare.

Fetch on-demand. Non è crawling: è una richiesta che parte da un utente in quel momento, perché ha incollato un link o ha chiesto di aprire una pagina. ChatGPT-User per OpenAI, Claude-User per Anthropic, Perplexity-User per Perplexity. Qui il robots.txt ha molta meno presa, e Perplexity lo dichiara nero su bianco: Perplexity-User «generally ignores robots.txt rules», perché la richiesta è un’azione dell’utente e non una scansione automatica.

La conseguenza pratica sta tutta in una riga. Se metti User-agent: * seguito da Disallow: / per «tenere fuori l’AI», hai chiuso anche OAI-SearchBot, Claude-SearchBot e PerplexityBot: sei uscito dai risultati di ricerca generativa, non solo dai dataset di addestramento. È come cancellarsi dall’elenco telefonico per non ricevere pubblicità.

La scelta ragionevole per la maggior parte dei siti è asimmetrica: blocchi il training, lasci passare la ricerca.

# Fuori dall'addestramento
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

# Dentro ai risultati di ricerca AI
User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Se invece la tua posizione è l’opposto, cioè vuoi essere addestrato e non ti interessano i risultati generativi, il file si scrive al contrario. Va bene l’una e va bene l’altra. Quello che non va bene è scoprire quale hai scelto tre mesi dopo.

I token esatti dei crawler AI

I token vanno scritti esatti, presi dalle pagine ufficiali dei singoli lab. Non da una lista copiata: il nome sbagliato non dà errore, semplicemente non fa niente, e tu resti convinto di aver bloccato qualcosa.

Due avvertenze sulla prima colonna. Il match del nome non guarda maiuscole e minuscole, quindi gptbot funziona quanto GPTBot, ma il trattino e la grafia esatta contano: Claude-Bot non è ClaudeBot, e non blocca niente.

Google-Extended e Applebot-Extended non sono crawler

Bloccare Google-Extended non ti fa perdere posizioni su Google. Sta scritto nella documentazione, testuale: «Google-Extended non influisce sull’inclusione di un sito nella Ricerca Google né viene utilizzato come indicatore di ranking».

Il motivo è che Google-Extended non è uno user-agent HTTP. Non c’è nessun bot che si presenta con quel nome nei tuoi log, perché non esiste come crawler. È un token di controllo: serve a decidere se i contenuti che Googlebot ha già scansionato possono essere usati per addestrare le future generazioni di Gemini, alimentare l’API Vertex AI per Gemini e il grounding. La scansione l’ha già fatta un altro; questo è l’interruttore su cosa succede dopo.

Se cerchi Google-Extended nei log e non lo trovi, il tuo file funziona lo stesso: quel nome è una casella da spuntare, e le caselle nei log non ci finiscono.

Stessa logica per Applebot-Extended, con la stessa frase quasi identica dalla parte di Apple: «Applebot-Extended does not crawl webpages». Governa l’uso dei dati già raccolti da Applebot per addestrare i modelli generativi di Apple, e disabilitarlo non rimuove il sito dai risultati di ricerca.

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

Queste quattro righe tolgono i tuoi contenuti dall’addestramento di Gemini e dei modelli Apple, e non toccano una virgola della tua visibilità in Ricerca Google, in Spotlight, in Siri e in Safari. È l’unico punto di tutta questa sezione in cui la scelta è a costo zero dichiarato dal fornitore.

robots.txt e llms.txt

Sono due file con due mestieri opposti e non si sostituiscono a vicenda.

Il robots.txt toglie accesso: dice a un crawler cosa non può prendere, ed è il canale che le pagine ufficiali dei lab AI indicano per farlo. llms.txt offre un indice a chi è già entrato: non blocca niente, e nessuno dei motori che ho verificato scrivendo il pezzo su llms.txt dichiara di leggerlo.

Puoi averli entrambi, uno solo o nessuno dei due senza che si parlino. Il ragionamento completo sui numeri, su chi lo legge davvero e su quando ha senso pubblicarlo sta nel pezzo dedicato a llms.txt.

Gli errori che vedo più spesso

Undici errori, ognuno con il sintomo da cui lo riconosci e la correzione. I primi tre sono quelli che costano di più.

1. Disallow: / rimasto in produzione dopo una migrazione. Sintomo: le impression crollano in pochi giorni, Search Console segnala «Bloccata da robots.txt» a raffica. Succede quando lo staging va online così com’è. Correzione: apri esempio.it/robots.txt in incognito, adesso, prima di finire di leggere questa riga.

2. Noindex: scritto dentro il robots.txt. Sintomo: nessuno, ed è il problema. La riga viene ignorata e tu credi di aver deindicizzato. Fuori uso per Google dal 1° settembre 2019. Correzione: cancellala e metti un <meta name="robots" content="noindex"> nella pagina.

3. noindex su una pagina bloccata da Disallow. Sintomo: la pagina resta in indice, spesso senza descrizione, per mesi. Il crawler non entra, quindi il noindex non lo legge mai. Correzione: togli il Disallow, aspetta la deindicizzazione, poi decidi se rimetterlo.

4. Sitemap con URL relativo. Sintomo: la sitemap non viene mai rilevata dal robots.txt. Correzione: URL assoluto con protocollo e host.

5. Riga User-agent mancante sopra le direttive. Sintomo: il file sembra pieno di regole e non ne applica nessuna. È lo snippet pubblicato da Netsons, con un Crawl-delay: 5 orfano e un Disallow: * che per giunta non è la sintassi per bloccare tutto. Correzione: ogni gruppo comincia con User-agent:, e per bloccare tutto si scrive Disallow: /.

6. Maiuscole nei percorsi. Sintomo: Disallow: /Prodotti/ non blocca /prodotti/. Il matching dei percorsi è case-sensitive per RFC 9309. Correzione: copia il percorso dall’URL vero, non riscriverlo a memoria.

7. Blocco di CSS e JavaScript. Sintomo: la pagina renderizzata in Controllo URL sembra uscita dal 1998. Correzione: rimuovi i Disallow su temi, asset e /*.js$, e ricontrolla il rendering.

8. Robots.txt usato per nascondere dati riservati. Sintomo: il tuo file elenca i percorsi che volevi tenere segreti. Correzione: autenticazione davanti alla risorsa, e togli quelle righe dal file, che è pubblico.

9. Regole messe in una sottodirectory. Sintomo: esempio.it/blog/robots.txt esiste, è scritto benissimo e non lo legge nessuno. Correzione: root dell’host, sempre. E un file per ogni host, protocollo e porta.

10. File oltre 500 KiB. Sintomo: le regole in fondo al file non hanno effetto. Google si ferma al limite e ignora il resto. Correzione: curl -s https://esempio.it/robots.txt | wc -c, e se il file è generato da uno script, accorpa le regole con le wildcard invece di elencare diecimila URL.

11. BOM UTF-8 in testa al file. Googlebot lo ignora, e lo scrive nella specifica: «Google ignora le righe non valide nei file robots.txt, tra cui il carattere Unicode Byte Order Mark (BOM) all’inizio del file robots.txt e utilizza solo righe valide». Non lo ignorano tutti: alcuni checker e parser di terze parti si fermano alla prima riga, quindi resta una pulizia da fare, non una causa di blocco su Google. Correzione: salva in UTF-8 senza BOM, verifica con curl -s https://esempio.it/robots.txt | head -c 3 | xxd.

Due correzioni in più, prese dalle cinque guide che ho analizzato, perché se le hai lette potresti averle in casa. Il crawl-delay si esprime in secondi, non in millisecondi, come scrive Roberto Serra: un Crawl-delay: 10 copiato credendo di aspettare un centesimo di secondo dice a Bing di passare una volta ogni dieci secondi. E l’Allow non è una direttiva «solo per Google», sempre da Roberto Serra: sta in RFC 9309, cioè nello standard.

La checklist prima di pubblicare

Otto controlli in ordine, tutti verificabili in meno di dieci minuti.

1. Il file risponde 200 su https://tuodominio.it/robots.txt, con Content-Type: text/plain. Verifica: curl -sI.
2. Igiene dell’encoding: UTF-8, e già che ci sei senza BOM. Googlebot il BOM lo ignora, quindi non è un controllo bloccante, ma un file pulito non fa inciampare gli strumenti di terze parti.
3. Ogni gruppo ha la sua riga User-agent, e nessuna direttiva orfana galleggia in mezzo al file.
4. Nessuna direttiva morta: noindex, nofollow e crawl-delay fuori, a meno che il crawl-delay non ti serva per Bing, e in quel caso dentro il suo gruppo User-agent: Bingbot.
5. Sitemap con URL assoluto, una riga per ogni sitemap o una sola verso il sitemap index.
6. Gli URL critici testati uno per uno con il parser locale di Google: home, categorie principali, un paio di pagine prodotto, le landing che ti portano traffico.
7. Richiesta di nuova scansione dal rapporto robots.txt in Search Console, così non aspetti che scada la cache.
8. Un giro di controllo dopo ogni migrazione, cambio di ambiente, cambio di hosting o passaggio di CDN. In quei passaggi il file cambia da solo, e nessuno se ne accorge finché non è tardi.

Se hai più host, la checklist va rifatta per ognuno. Sottodomini compresi, versione http compresa se risponde ancora.

Cinque righe da portarsi via

Cosa fa e cosa non fa. Il robots.txt governa la scansione, non l’indice. Per togliere una pagina da Google serve un noindex leggibile, quindi non bloccato.

Chi vince. Fra due regole in conflitto vince il percorso più lungo, a parità vince Allow. Le wildcard entrano nel conteggio come tutto il resto: /*.htm batte /page, sei caratteri contro cinque.

Come si testa. Non con il vecchio tester: curl per lo status, il rapporto robots.txt per la vista di Google, Controllo URL per la singola pagina e il parser open source per la verifica in locale.

Se risponde 500. Google sospende la scansione per 12 ore e va avanti con la copia in cache fino a 30 giorni. Un solo URL rotto spegne il quadro di tutto il sito, e non te lo segnala nessun errore rosso.

Sui bot AI. Blocca l’addestramento se vuoi (GPTBot, ClaudeBot, CCBot, Google-Extended, Applebot-Extended) e lascia passare la ricerca (OAI-SearchBot, Claude-SearchBot, PerplexityBot), altrimenti esci anche dai risultati generativi. Google-Extended non tocca la Ricerca Google, e a dirlo è Google.

Da leggere accanto a questo: il pezzo su llms.txt, che sta dall’altra parte del banco, e il repo dell’audit SEO, dove il controllo del robots.txt è uno dei primi passaggi. Da qui parte la guida alla sitemap XML, che è l’altro file con cui governi cosa i motori trovano; in coda al piano resta il crawl budget.

Se hai un file che si comporta in modo strano e non ne vieni a capo, mandamelo. Sto raccogliendo i casi in cui il robots.txt fa danni senza che Search Console segnali niente, e finora il pattern più ricorrente è proprio quello del 500 silenzioso.

Domande frequenti