Pubblicato il - Aggiornato il
Robots.txt: guida completa al protocollo di esclusione dei crawler
Se stai cercando “robots rxt”, quasi sicuramente intendi robots.txt: un file minuscolo che può determinare se Google vede (o non vede) le tue pagine più importanti. Un’istruzione sbagliata qui può tagliare fuori categorie, schede prodotto o landing, con impatto diretto su indicizzazione e performance organica. In questa guida trovi esempi “copia-incolla” e un metodo pratico per testare e validare ogni modifica, senza dover dipendere sempre dall’IT. L’obiettivo non è “fare SEO tecnica per sport”, ma collegare ogni scelta a KPI reali: traffico qualificato, conversioni e ROI.
Indice dei contenuti
Cos’è robots.txt e perché impatta (davvero) su SEO e KPI
Prima di mettere mano al file, conviene chiarire cosa stai controllando: robots.txt non è “magia SEO”, è un set di regole che dice ai crawler dove possono (o non possono) fare crawling. Se lo usi bene, aiuti i motori a spendere risorse sulle pagine che contano e a scoprire più in fretta contenuti nuovi o aggiornati. Se lo usi male, puoi tagliare fuori intere sezioni del sito e vedere scendere traffico e revenue senza capire subito il perché.
Crawling, indicizzazione e performance: la catena causa-effetto
Il robots.txt agisce sul crawling, non sull’indicizzazione in senso stretto. In pratica: puoi impedire a Google di scaricare una pagina, ma se quella URL viene trovata altrove (link interni, sitemap, link esterni), può comunque comparire in SERP come “URL bloccata da robots.txt”, spesso con snippet povero e risultati poco controllabili. Questa distinzione è cruciale perché molti “errori tecnici” nascono proprio dal confondere blocco del crawl con rimozione dall’indice.
Dal punto di vista business, il collegamento ai KPI è lineare: se blocchi (anche involontariamente) pagine che generano traffico qualificato, interrompi la catena discovery → ranking → sessioni → conversioni. Al contrario, se non blocchi aree che generano infinite combinazioni (filtri, parametri, ricerca interna), rischi di sprecare crawl budget e rallentare la scoperta di nuove schede prodotto o categorie, proprio quando ti serve velocità di indicizzazione.
Un’ultima cosa pratica: robots.txt è “una sola leva” dentro un sistema più grande. Per gestire indicizzazione e visibilità in modo robusto lo affianchi a meta robots, canonical, struttura interna e qualità dei contenuti. Il vantaggio è che puoi fare molto con modifiche piccole, purché validate con metodo.
Differenze con il file llms.txt
Il file llms.txt è stato introdotto come evoluzione del più noto robots.txt, con l’obiettivo di fornire indicazioni specifiche per i Large Language Models (LLMs). A differenza del robots.txt, che indirizza i crawler tradizionali sui contenuti da indicizzare, llms.txt si concentra esclusivamente sulla gestione dell’accesso e dell’utilizzo dei dati da parte dei modelli di intelligenza artificiale avanzati, garantendo una maggiore precisione nel controllo delle informazioni.
Dove si trova robots.txt e come verificarlo in 60 secondi
Il file vive in un posto preciso e non ammette interpretazioni: se non è lì, per Google “non esiste”. Prima ancora di discutere direttive e pattern, il primo controllo è capire se il tuo sito lo sta servendo correttamente e con che contenuto. Questo step ti evita ore di ragionamenti su un file che magari è in 404 o viene riscritto dal CMS.
Percorso corretto, status code e check rapido (browser + curl)
Il percorso è sempre: https://tuodominio.tld/robots.txt (radice del dominio o sottodominio). Deve rispondere 200 OK e restituire testo in chiaro: se risponde 301/302, 404 o (peggio) 500, stai già introducendo ambiguità e rischi comportamenti non prevedibili lato crawler.
Un check rapido lo fai anche senza strumenti “da sviluppatori”. Apri l’URL nel browser e controlla che:
- il contenuto sia quello atteso (non una pagina HTML del tema);
- non ci siano caratteri “strani” o encoding rotti;
- non ci sia un blocco totale non voluto (tipico:
Disallow: /lasciato da ambienti di staging).
Se vuoi un controllo più “pulito” (utile per ridurre dipendenza dall’IT), usa un comando tipo:
curl -I https://tuodominio.tld/robots.txt
curl https://tuodominio.tld/robots.txt
Il primo ti dice status e redirect, il secondo ti mostra il contenuto. In ottica debug, è spesso tutto quello che serve per iniziare.
Sintassi del robots.txt: direttive base (copiaincolla) e cosa supportano i motori
La sintassi è semplice, ma è facile fare danni con un carattere fuori posto o un pattern troppo aggressivo. Qui l’obiettivo è darti una base solida: capire le direttive che contano davvero, come ragiona Google e dove iniziano le “zone grigie” (direttive non standard o supportate solo da alcuni motori).
User-agent, Disallow e Allow: le regole che userai il 90% delle volte
Il file è composto da “gruppi”: ogni gruppo inizia con un User-agent e poi elenca cosa bloccare o permettere. Il caso più comune è definire regole valide per tutti:
User-agent: *
Disallow:
Sì: questo file “vuoto” è valido e significa “non blocco nulla”. È un buon punto di partenza quando vuoi evitare errori grossi e spostare i blocchi su strumenti più specifici (meta robots / X-Robots-Tag) dove serve davvero.
Quando vuoi bloccare una cartella:
User-agent: *
Disallow: /private/
E quando vuoi fare un’eccezione (molto utile con CMS), entra in gioco Allow:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Questa combinazione evita di bloccare una risorsa tecnica necessaria a funzionalità e rendering, riducendo effetti collaterali su UX e segnali di performance.
Sitemap, wildcard (*, $) e pattern: come evitare blocchi “a strascico”
Dichiarare la Sitemap nel robots.txt non è obbligatorio, ma è una buona pratica “pulita” perché rende immediata la discovery:
Sitemap: https://tuodominio.tld/sitemap.xml
Se hai sitemap multiple, puoi inserirne più di una (una per riga). È una scelta che ha senso anche lato governance: chi mette mano al file vede subito quali feed stanno guidando l’indicizzazione.
Per gestire URL con parametri o pattern ripetuti, Google supporta wildcard * e terminatore $. Esempio tipico: bloccare una funzione specifica indipendentemente dal resto della query:
User-agent: *
Disallow: /*?add-to-cart=
Oppure bloccare solo un “finale” preciso:
User-agent: *
Disallow: /*.pdf$
Qui la cautela è d’obbligo: pattern troppo generici possono bloccare anche URL utili, con impatto su landing e pagine di conversione. Se l’obiettivo è controllare indicizzazione (non solo crawl), spesso è meglio agire con regole “più chirurgiche” (e misurabili), come spiego nella sezione su quando usare robots.txt vs meta robots.
Direttive non standard e supporto dei motori (Crawl-delay, Host, Clean-param)
Esistono direttive che trovi spesso in guide vecchie o in forum, ma che non sono uno standard universalmente supportato. La più famosa è Crawl-delay: alcuni motori la considerano, ma Google non la supporta nel robots.txt. Se il tuo obiettivo è rallentare Googlebot per motivi infrastrutturali, la strada corretta passa da capacity planning, caching, CDN e — quando appropriato — impostazioni server, non da una riga nel robots.txt.
Un’altra direttiva che circola è Host (storicamente legata a Yandex). Per Google non è rilevante: la gestione del dominio canonico avviene tramite redirect, canonical, configurazioni corrette di hosting e coerenza interna.
Infine, Clean-param è un caso delicato: è stata usata in alcuni contesti per gestire parametri, ma oggi è da considerare deprecata e non una base affidabile per strategie moderne. Se stai combattendo parametri “infiniti” (filtri, tracking, sorting), lavora su una combinazione di architettura, canonical, regole lato applicazione e controllo dei link interni; usa il robots.txt solo dove bloccare il crawl è davvero la scelta più sostenibile.
Esempi pratici di robots.txt: template pronti all’uso
Questa è la parte “operativa”: esempi copiaincolla da cui partire e poi adattare. L’idea non è trovare “il file perfetto”, ma un asset semplice, versionabile e testabile, che rispecchi le priorità del tuo sito (scoperta delle pagine che convertono, riduzione sprechi, meno errori in produzione).
Esempio base pronto all’uso
Se vuoi un file minimale, corretto e utile, questo è un buon template:
User-agent: *
Disallow:
Sitemap: https://tuodominio.tld/sitemap.xml
È intenzionalmente “conservativo”: non blocca nulla e dichiara la sitemap. È ideale quando stai ripulendo situazioni confuse o quando preferisci controllare l’indicizzazione con strumenti più espliciti (meta robots, canonical) invece di bloccare il crawl in modo massivo.
Tre cose che, nella pratica, evita di bloccare a cuor leggero perché possono danneggiare rendering e segnali SEO:
- CSS/JS necessari al rendering (Google deve poter renderizzare bene per valutare layout e contenuto).
- Cartelle immagini se ti interessa traffico da Google Immagini o se le immagini sono parte dell’esperienza (ecommerce incluso).
/wp-admin/su WordPress senza l’eccezione suadmin-ajax.php(se usi WP/WooCommerce, vedi anche la sezione CMS).
Se devi aggiungere blocchi, fallo per obiettivi chiari e misurabili (es. ridurre crawl su pagine a bassa qualità). E soprattutto: una modifica alla volta, così riesci a correlare causa ed effetto sui KPI.
Ecommerce: bloccare filtri e parametri senza sabotare categorie e prodotti
Negli ecommerce, il rischio più comune è lasciare aperto un universo di combinazioni: filtri colore/taglia, sorting, paginazioni “alternative”, parametri marketing. Il robots.txt può aiutarti a limitare il crawl di URL che non vuoi far esplodere, ma non deve diventare un cerotto su problemi di architettura o linking interno.
Un esempio prudente (da adattare ai parametri reali del tuo sito) è bloccare alcune funzioni chiaramente non SEO-friendly:
User-agent: *
Disallow: /*?sort=
Disallow: /*?orderby=
Disallow: /*?filter=
Disallow: /*&filter=
Disallow: /*?add-to-cart=
Nota la differenza tra ? e &: spesso i parametri non stanno solo all’inizio della query. Bloccare solo ?filter= e dimenticare &filter= è un classico motivo per cui il crawl continua “a perdita d’occhio”.
La regola d’oro è questa: se una pagina filtrata è pensata per portare traffico (quindi ha contenuto, title, internal linking e una logica di domanda reale), non bloccarla. In quel caso la gestisci come una vera pagina SEO (anche con template e contenuti scalabili). Se invece è solo una combinazione tecnica senza valore, bloccare il crawl può essere sensato per proteggere crawl budget e discovery delle pagine che fatturano.
Staging e ambienti di test: blocco totale (sicuro) senza effetti collaterali
Su staging e ambienti di test, il blocco totale è spesso corretto, ma va fatto con attenzione per non finire in produzione con lo stesso file. Il classico robots.txt da staging è:
User-agent: *
Disallow: /
Questo impedisce il crawling di tutto. Funziona, ma è anche il “kill switch” SEO: se arriva in produzione, puoi vedere crolli importanti di traffico in pochi giorni (o ore, se Google ricrawl frequente).
Per rendere il processo più sostenibile, affianca sempre al robots.txt anche controlli di ambiente: protezione con password, restrizioni IP o header X-Robots-Tag: noindex lato server sugli ambienti non pubblici. E, soprattutto, inserisci una validazione nel tuo flusso di deploy: se il file contiene Disallow: /, deve essere un “fail” automatico prima della messa online.
Best practice SEO per robots.txt: scelte tecniche che reggono il confronto con i numeri
Un robots.txt “buono” è quello che ti aiuta a prendere decisioni e a mantenerle nel tempo: poche regole, leggibili, coerenti con l’architettura e misurabili. Qui trovi le best practice più utili per chi lavora con obiettivi di crescita e vuole evitare sorprese in indicizzazione e performance.
Quando usare robots.txt, meta robots e X-Robots-Tag (senza confonderli)
Usa robots.txt quando vuoi impedire il crawling di intere aree o pattern di URL (tipico: parametri inutili, endpoint tecnici, aree private). È una scelta “preventiva”: riduci lo spreco di crawl e togli di mezzo URL che non dovrebbero proprio essere visitate (aree tecniche, combinazioni infinite, endpoint interni). È utile quando il problema è volume di crawling o carico sul server, non quando vuoi controllare con precisione cosa appare in SERP.
Usa meta robots (es. noindex,follow) quando l’obiettivo è l’indicizzazione: vuoi permettere al bot di scansionare la pagina, leggerla e poi decidere di non inserirla (o rimuoverla) dall’indice. Qui c’è un punto pratico che evita molti disastri: se blocchi una URL via robots.txt, Google spesso non può vedere il noindex presente nella pagina, quindi rischi di ottenere l’effetto opposto (URL che resta indicizzata come “bloccata da robots.txt”, ma non pulita davvero).
Usa X-Robots-Tag quando devi controllare indicizzazione e snippet su risorse non-HTML (PDF, file generati, allegati) o quando vuoi applicare regole a livello server in modo consistente. È la scelta più “governabile” nei progetti grandi perché centralizza la logica e riduce dipendenze dal template.
Se vuoi una regola semplice per decidere al volo:
- se vuoi ridurre crawling → robots.txt
- se vuoi rimuovere/evitare indicizzazione → meta robots o X-Robots-Tag
- se vuoi gestire PDF e file binari → X-Robots-Tag (quasi sempre)
Coordinare robots.txt, noindex, canonicals e Sitemap
Qui si gioca la differenza tra un sito “che funziona” e un sito che accumula eccezioni. Robots.txt, noindex, canonical e Sitemap sono leve diverse: se le usi in modo scollegato, crei segnali contrastanti e diventa difficile capire cosa sta succedendo (anche guardando i report). Se le coordini, invece, l’indicizzazione diventa più stabile e prevedibile.
Il caso più comune da evitare: metti Disallow su una directory e poi aggiungi noindex sulle pagine dentro quella directory per “essere sicuro”. In pratica hai appena tolto a Google la possibilità di leggere il noindex, quindi stai pagando due volte senza ottenere il risultato. Se vuoi de-indicizzare una pagina già presente in SERP, in genere funziona meglio questa sequenza: consenti il crawl, applica noindex (meta o header), rimuovi la URL dalla Sitemap e riduci gradualmente la linkabilità interna.
Anche il canonical va ragionato con coerenza: è un segnale che Google valuta dopo aver scansionato la pagina. Quindi, se una variante parametrica è bloccata da robots.txt, non stai davvero “guidando” la canonicalizzazione: stai solo impedendo la lettura del segnale. Per i parametri, spesso la combinazione più pulita è: internal linking verso le URL canoniche, canonical coerenti, e robots.txt usato solo per ciò che genera crawling inutile (es. sorting e add-to-cart).
Permettere il crawling di risorse essenziali: impatto su crawl budget e Page Experience
Bloccare CSS/JS “per tenere pulito il crawl” è uno degli errori più costosi: risparmi poche richieste e rischi di compromettere rendering, interpretazione del layout e segnali legati alla Page Experience. Google, per valutare correttamente contenuto e usabilità, deve poter recuperare le risorse fondamentali: CSS, JS, font, immagini critiche e API chiamate dal rendering (quando indispensabili).
Dal punto di vista KPI, il danno non è teorico. Se Google renderizza male una pagina, puoi avere:
- contenuto percepito come “thin” o incompleto (con impatto su ranking),
- layout instabile (effetti su CLS e UX),
- problemi su mobile (e quindi su conversioni, soprattutto ecommerce).
Quando ha senso bloccare risorse? Quasi mai in modo “a cartella”. Se vuoi ridurre crawling su asset non utili, punta a essere chirurgico (pattern precisi) e misura l’effetto con strumenti di rendering: in Google Search Console usa Controllo URL (pagina resa) e confronta prima/dopo. Se il sito è grande, la validazione vera passa dai log server: vedi se stai spostando il crawl dalle pagine che contano a richieste inutili (o viceversa).
Dettagli tecnici del file robots.txt: posizionamento, formato e caching
Quando robots.txt “sembra giusto” ma i bot si comportano in modo inatteso, spesso il problema non è la regola: è come il file viene servito. Percorso, maiuscole/minuscole, encoding, status code e cache (CDN inclusi) possono cambiare completamente l’effetto. Questa sezione serve per evitare errori invisibili, quelli che scopri solo dopo un calo di traffico o un audit tecnico.
Percorso in root, maiuscole/minuscole, encoding e dimensioni
Robots.txt deve vivere in root dell’host: https://esempio.com/robots.txt. Non vale metterlo in una sottocartella, e non vale “quasi uguale”: robots.TXT, Robot.txt o percorsi alternativi non sono affidabili. In più, ogni sottodominio ha il suo file: blog.esempio.com/robots.txt non controlla www.esempio.com.
Il file deve essere testo semplice. L’ideale è UTF‑8 senza caratteri strani; attenzione a editor che inseriscono BOM o “virgolette smart” quando incolli. Anche i commenti sono ok (con #), ma evita di trasformare il file in documentazione: più è lungo e complesso, più aumenta il rischio di conflitti e regressioni.
C’è anche un tema di dimensioni: Google ha limiti di parsing (se il file è enorme, può ignorarne parti). In pratica: se stai arrivando a centinaia di righe, è un segnale che stai usando robots.txt per compensare un problema strutturale (URL che esplodono, faceted navigation senza governance). In quei casi conviene fermarsi e fare un intervento di architettura e linking interno: è più sostenibile e più misurabile.
HTTP status, redirect e cache dei crawler
Per i crawler, robots.txt è un file “speciale”: il modo in cui risponde il server cambia le regole del gioco. In generale, punta a servire robots.txt con 200 OK e senza redirect. I redirect (301/302) spesso vengono seguiti, ma aggiungono complessità inutile, soprattutto con CDN, WAF o regole di geolocalizzazione.
Alcuni casi pratici che fanno la differenza:
- 404 Not Found: in genere viene interpretato come “nessuna regola” (quindi crawling consentito).
- 401/403: può essere interpretato in modo conservativo (molti bot si fermano o considerano tutto bloccato).
- 5xx/timeout: i bot possono usare la versione in cache; se l’errore persiste, tendono a ridurre/fermare il crawling per non peggiorare la situazione.
Poi c’è la cache: Google e gli altri bot non ricaricano robots.txt a ogni richiesta. Lo tengono in memoria per un po’ e lo riusano, quindi un fix “urgente” potrebbe non avere effetto immediato se il file è stato cacheato (o se una CDN sta servendo una versione vecchia). Per questo, quando fai una modifica critica, l’approccio corretto è: verifica con curl, controlla gli header di caching e monitora il comportamento reale nei log.
Creare il file robots.txt su Windows/macOS/Linux/CLI
La creazione è semplice, ma ci sono dettagli che fanno inciampare spesso: estensioni doppie, encoding errato, upload nella cartella sbagliata. Su Windows usa un editor che salvi davvero in testo (es. Notepad) e fai attenzione a non ritrovarti con robots.txt.txt. Su macOS, se usi TextEdit, assicurati di salvare in plain text, non in formato “ricco”.
Da terminale (Linux/macOS/CLI), spesso è la soluzione più pulita perché riduce sorprese:
cat > robots.txt <<'EOF'
User-agent: *
Disallow:
Sitemap: https://tuodominio.tld/sitemap.xml
EOF
Caricalo poi nella root corretta del sito (non quella del progetto, ma quella servita dal web server) e valida subito:
curl -I https://tuodominio.tld/robots.txt
curl https://tuodominio.tld/robots.txt
Se vuoi rendere il processo sostenibile, trattalo come codice: versioning, revisione e una semplice checklist di deploy. È una micro‑automazione che evita errori molto costosi.
Robots.txt per CMS e piattaforme
Nei CMS, robots.txt non è solo un file: è anche un “punto di integrazione” con routing, plugin, cache e CDN. Alcune piattaforme lo generano in modo dinamico, altre lo trattano come un file statico, altre ancora lo fanno personalizzare via template. Qui trovi indicazioni pratiche per evitare i classici blocchi involontari.
WordPress (incluso WooCommerce)
Su WordPress puoi avere un robots.txt fisico (file in root) oppure uno virtuale generato dal core/plugin. In ottica governance, quasi sempre preferisco un file fisico: è più semplice da versionare, testare e non cambia “a sorpresa” dopo un aggiornamento.
Un template tipico, pulito e compatibile con la maggior parte dei setup:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://tuodominio.tld/sitemap.xml
Su WooCommerce, i parametri possono esplodere il crawling (sorting, filtri, add-to-cart). Qui robots.txt può aiutare a proteggere crawl budget, ma va coordinato con canonical e linking interno: se una pagina filtrata è strategica, non bloccarla “per comodità”. Se invece stai solo evitando combinazioni infinite, le regole sui parametri sono spesso sensate, soprattutto su siti grandi.
Un errore frequente è bloccare troppo: Disallow: /wp-content/ o Disallow: /wp-includes/ può impedire l’accesso a CSS/JS e alterare il rendering. Se stai ottimizzando davvero le performance, il percorso migliore è lavorare su caching e asset delivery, non togliere al bot i file necessari a capire la pagina.
Shopify
Su Shopify, la configurazione predefinita del file robots.txt è già adeguatamente ottimizzata per la maggior parte dei negozi online. Tuttavia, per personalizzare ulteriormente il comportamento del crawl dei motori di ricerca, è possibile intervenire manualmente. Ecco un esempio di codice per configurare correttamente il file robots.txt su Shopify:
User-agent: *
Disallow: /cart
Disallow: /checkout
Disallow: /orders
Allow: /collections
Allow: /products
Sitemap: https://www.tuonome.com/sitemap.xml
Assicurati di adattare le regole alle esigenze specifiche del tuo e-commerce, mantenendo un equilibrio tra l’indicizzazione dei contenuti rilevanti e la protezione di aree riservate.
Prestashop
Per configurare correttamente il file robots.txt in Prestashop, è necessario accedere al back-office della piattaforma e navigare nella sezione dedicata alle preferenze SEO & URL. Una volta lì, sarà possibile generare automaticamente il file robots.txt aggiornato, assicurandosi che le direttive siano ottimizzate per i motori di ricerca. Di seguito è riportato un esempio di configurazione standard per un e-commerce basato su Prestashop:
User-agent: *
Disallow: /admin/
Disallow: /cgi-bin/
Disallow: /modules/
Disallow: /translations/
Disallow: /themes/
Disallow: /docs/
Disallow: /readme.html
# Sitemap
Sitemap: https://www.tuodominio.com/sitemap.xml
Questo file indica ai crawler dei motori di ricerca quali sezioni del sito devono essere escluse dall’indicizzazione, proteggendo così dati sensibili e migliorando la gestione del crawling budget. Dopo aver generato o modificato il file robots.txt, è consigliabile testarlo utilizzando strumenti come il Google Search Console per assicurarsi che sia configurato correttamente.
Dai crawler ai KPI: fai lavorare robots.txt per la tua crescita
Robots.txt è una leva piccola ma ad alto impatto: governa il crawling, quindi decide dove Google investe tempo e risorse sul tuo sito. Usato con metodo ti aiuta a dare priorità alle pagine che generano valore; usato “a intuito” può bloccare sezioni strategiche e spezzare la catena discovery → traffico → conversioni, spesso senza segnali immediati.
Il passo successivo è semplice e pragmatico: verifica che il file sia servito correttamente, allinea le regole agli obiettivi (non solo alla “pulizia” tecnica) e valida ogni modifica con test e monitoraggio, collegando gli effetti a KPI chiari. Se vuoi evitare dipendenze infinite dall’IT e mettere ordine tra crawling, indicizzazione e performance, cominciamo dai dati: un audit mirato su robots.txt + tracciamento ti dice cosa sta limitando la crescita e cosa conviene ottimizzare prima.
Mirko Ciesco
Data-Driven Growth Specialist
Aiuto aziende e startup a prendere decisioni migliori per crescere in modo misurabile. Sono specializzato in Web Analytics e performance digitale e lavoro all’intersezione tra dati, strategia e crescita.