Il file robots.txt è uno degli strumenti più antichi e potenti nell'arsenale di un webmaster. Posizionato nella root di ogni dominio, questo file di testo semplice indica ai crawler quali parti del tuo sito possono accedere e quali dovrebbero lasciare stare. Nonostante la sua semplicità, il robots.txt è anche uno dei file più frequentemente mal configurati sul web. Una singola regola fuori posto può nascondere un intero sito ai motori di ricerca o esporre sezioni che intendevi mantenere private.

Questa guida copre tutto, dalla sintassi fondamentale ai pattern avanzati, così potrai scrivere regole robots.txt con sicurezza.

Dove si trova robots.txt e come i crawler lo trovano

Ogni crawler conforme, prima di richiedere qualsiasi altro URL su un dominio, recupera /robots.txt alla root:

https://example.com/robots.txt

Regole chiave sul file stesso:

• Deve essere servito al percorso esatto /robots.txt — non /Robots.txt, non dentro una sottodirectory.
• Deve restituire un codice di stato 200 con content type text/plain. Se il server restituisce un 404, i crawler presumono che tutto sia consentito. Un errore 5xx fa sì che la maggior parte dei crawler sospenda il crawling fino a quando il file non torna disponibile.
• Il file si applica per origine (schema + host + porta). Una regola su https://example.com/robots.txt non governa https://blog.example.com né http://example.com.
• La dimensione massima del file rispettata da Google è 500 KiB. Tutto ciò che supera quel limite viene ignorato.

Sintassi di base

Un file robots.txt è composto da uno o più gruppi di regole. Ogni gruppo inizia con una o più righe User-agent, seguite da direttive Disallow e/o Allow:

User-agent: Googlebot
Disallow: /private/
Allow: /private/public-page.html

User-agent: *
Disallow: /tmp/
Disallow: /internal/

User-agent

La riga User-agent specifica a quale crawler si applicano le regole seguenti. Il wildcard * corrisponde a qualsiasi crawler che non abbia un proprio blocco specifico. I crawler si associano al blocco User-agent più specifico disponibile. Se esistono sia User-agent: * che User-agent: Googlebot, Googlebot utilizza solo il blocco specifico per Googlebot e ignora completamente il blocco wildcard.

Disallow

Disallow: /path/ indica al crawler corrispondente di non accedere a nessun URL che inizi con /path/. Un Disallow: vuoto (senza percorso) significa che nulla è vietato — equivalente all'accesso completo.

Allow

Allow: /path/ consente esplicitamente l'accesso agli URL che corrispondono al pattern, anche se un Disallow più ampio li bloccherebbe altrimenti. È essenziale per creare eccezioni.

Wildcard e pattern matching

La specifica originale del robots.txt del 1994 non includeva i wildcard, ma Google, Bing e la maggior parte dei crawler moderni supportano due importanti caratteri di pattern matching:

L'asterisco: *

Corrisponde a qualsiasi sequenza di caratteri (inclusa la stringa vuota). Esempi:

• Disallow: /*.pdf — blocca tutti gli URL che contengono .pdf in qualsiasi posizione del percorso.
• Disallow: /directory/*/page — blocca URL come /directory/anything/page.

Il segno del dollaro: $

Ancora la corrispondenza alla fine dell'URL. Senza $, i pattern corrispondono come prefissi. Esempi:

• Disallow: /*.pdf$ — blocca gli URL che terminano con .pdf ma consente /file.pdf?view=1 (perché l'URL non termina con .pdf).
• Allow: /page$ — consente esattamente /page ma non /page/subpage o /page?q=1.

Allow vs Disallow: quale prevale?

Quando un URL corrisponde sia a una regola Allow che a una Disallow, la risoluzione dipende dalla specificità (lunghezza del percorso). L'implementazione di Google segue questa logica:

1. La regola con il percorso di corrispondenza più lungo vince.
2. Se entrambe le regole hanno la stessa lunghezza, Allow ha la precedenza.

Esempio:

User-agent: *
Disallow: /directory/
Allow: /directory/public/

Qui, /directory/public/page.html è consentito perché /directory/public/ (20 caratteri) è più lungo di /directory/ (11 caratteri). Ma /directory/secret.html resta bloccato.

Questa è una fonte comune di confusione. Testa sempre le tue regole con un tester robots.txt per confermare il risultato per URL specifici.

La direttiva Crawl-delay

Crawl-delay richiede al crawler di attendere un determinato numero di secondi tra le richieste successive:

User-agent: Bingbot
Crawl-delay: 10

Avvertenze importanti:

• Google ignora completamente Crawl-delay. Per controllare la frequenza di crawling di Googlebot, usa l'impostazione Velocità di scansione in Google Search Console.
• Bing lo rispetta. Un valore di 10 significa che Bingbot attenderà 10 secondi tra le richieste.
• Yandex, Baidu e alcuni altri crawler lo rispettano, anche se le implementazioni variano.
• Impostare un valore eccessivamente alto (ad es. 60) blocca di fatto il crawling. Usalo con parsimonia e solo quando il tuo server non riesce genuinamente a gestire il carico.

La direttiva Sitemap

Puoi dichiarare le sitemap direttamente nel robots.txt:

Sitemap: https://example.com/sitemap.xml
Sitemap: https://example.com/sitemap-news.xml

Punti chiave:

• La direttiva Sitemap non è legata a nessun blocco User-agent. Posizionala all'inizio o alla fine del file — si applica globalmente.
• L'URL deve essere completamente qualificato (URL assoluto con schema).
• Puoi elencare più sitemap.
• È un suggerimento per la scoperta, non una garanzia. L'invio delle sitemap tramite Search Console o Bing Webmaster Tools è più affidabile.

Errori comuni che compromettono il crawling

1. Bloccare CSS e JavaScript

User-agent: *
Disallow: /assets/
Disallow: /js/
Disallow: /css/

I motori di ricerca moderni renderizzano le pagine per valutare contenuti e layout. Se blocchi le risorse necessarie per il rendering, il crawler vede una pagina rotta — e potrebbe declassarla o saltarla. Blocca solo le risorse genuinamente irrilevanti per il rendering dei contenuti pubblici.

2. Usare Disallow per tenere le pagine fuori dall'indice

Disallow impedisce il crawling, non l'indicizzazione. Se altre pagine linkano a un URL bloccato, Google può comunque indicizzarlo — semplicemente non avrà contenuti da mostrare, risultando in un listing criptico. Per rimuovere veramente una pagina dall'indice, usa un meta tag noindex o un header X-Robots-Tag e consenti al crawler di vedere la pagina.

3. Dimenticare lo slash finale

Disallow: /private   # blocca /private, /private.html, /privately, ecc.
Disallow: /private/  # blocca solo i percorsi dentro la directory /private/

Il primo pattern è più ampio di quanto la maggior parte delle persone intenda. Valuta sempre se hai bisogno dello slash finale.

4. Blocchi wildcard e specifici in conflitto

Avere un blocco User-agent: * e un blocco specifico per bot dove il blocco specifico è vuoto dà effettivamente a quel bot accesso completo — anche se il blocco wildcard è restrittivo. Questo è progettato così, ma sorprende chi presume che le regole si accumulino.

5. Servire robots.txt dietro un redirect

Se /robots.txt restituisce un 301 o 302, la maggior parte dei crawler seguirà il redirect. Tuttavia, catene di redirect, loop di redirect o il redirect a una risposta non text/plain faranno sì che i crawler trattino il file come non disponibile. Mantieni la semplicità: servi il file direttamente alla root con una risposta 200.

6. Non considerare i crawler IA

Se il tuo robots.txt ha solo un blocco User-agent: *, qualsiasi crawler IA che non hai esplicitamente bloccato avrà lo stesso accesso di Googlebot. Considera l'aggiunta di regole specifiche per bot come GPTBot, ClaudeBot, PerplexityBot e Bytespider.

Testare il tuo robots.txt

Non distribuire mai modifiche al robots.txt senza testarle. Strumenti disponibili:

• Google Search Console — il robots.txt Tester mostra come Google interpreta le tue regole per URL specifici.
• Bing Webmaster Tools — funzionalità di test simile per Bingbot.
• Spider.es — verifica quali crawler (motori di ricerca, bot IA, strumenti SEO) possono accedere a qualsiasi URL sul tuo dominio, con la regola specifica che controlla ciascun verdetto.
• Strumenti da riga di comando — librerie come urllib.robotparser di Python permettono di automatizzare i test nelle pipeline CI/CD.

Un template di partenza solido

# Motori di ricerca: accesso completo
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /
Crawl-delay: 5

# Crawler IA: accesso selettivo
User-agent: GPTBot
Disallow: /premium/
Allow: /blog/

User-agent: Google-Extended
Disallow: /

# Default: consenti con restrizioni
User-agent: *
Disallow: /admin/
Disallow: /tmp/
Disallow: /search?*

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

Adattalo alle tue esigenze. Il principio è semplice: sii esplicito su ciò che consenti, deliberato su ciò che blocchi e testa prima di distribuire.

Considerazioni finali

Il robots.txt è ingannevolmente semplice. Poche righe di testo controllano se milioni di persone possono scoprire i tuoi contenuti tramite motori di ricerca e strumenti IA. Trattalo con la stessa cura che dedichi alla configurazione di sicurezza del tuo sito. Verificalo regolarmente — specialmente quando compaiono nuovi crawler IA — e usa strumenti come Spider.es per verificare che la tua policy intesa corrisponda alla realtà.