Cos’è il robots.txt e come funziona
Il file robots.txt è un semplice file di testo posizionato nella root del dominio (/robots.txt
). Implementa il protocollo Robots Exclusion Standard per comunicare ai crawler (Googlebot, Bingbot, ecc.) quali aree del sito possono essere esplorate e quali vanno evitate. Non “blocca l’indicizzazione” di per sé: indica cosa scansionare e cosa no. L’indicizzazione è un effetto della scansione, ma può avvenire anche senza accesso al contenuto (ad esempio via link esterni) se non usi politiche più rigide come noindex
via meta/header.
In pratica, il crawler richiede https://tuodominio.it/robots.txt
prima di esplorare il sito e applica le direttive corrispondenti al proprio User-agent. Se non trova il file, assume che tutta la superficie sia scan-friendly.
Perché è importante per SEO e performance
- Ottimizza il crawl budget: i bot hanno risorse finite; eliminare dalla scansione pagine inutili (search interni, parametri di tracking) permette di concentrare l’attenzione su categorie, schede prodotto, articoli.
- Migliora il rendering: consentire asset (CSS/JS/immagini/font) permette a Google di “vedere” la pagina come un utente, con effetti positivi su indicizzazione e Core Web Vitals.
- Riduce duplicazioni: alcune combinazioni di parametri/ordinamenti generano varianti duplicative. Gestirle nel robots.txt (o in GSC Parametri) aiuta a consolidare segnali SEO.
- Protegge aree sensibili: blocchi su carrello, checkout, account e pannelli admin evitano indicizzazione di pagine inutili o potenzialmente problematiche.
Struttura, sintassi e priorità delle regole
Le direttive principali sono:
- User-agent: specifica a quale crawler si applicano le regole (es.
User-agent: *
per tutti). - Disallow / Allow: bloccano o consentono specifici percorsi; gli Allow servono a “riaprire” porzioni all’interno di directory disabilitate.
- Sitemap: indica le sitemap del sito (accettato anche fuori da blocchi
User-agent
). - Crawl-delay: accettato da alcuni bot (Bing, Yandex), ignorato da Google.
Priorità: per Google vale la regola del matching più specifico. Una regola Allow
più specifica vince su un Disallow
più generico. Non tutti i bot interpretano esattamente allo stesso modo; per compatibilità evita blocchi “a tappeto” sulle directory di asset.
Best practice moderne (2025)
- Non bloccare CSS/JS/immagini/font: Google deve renderizzare la pagina come un utente. Se blocchi asset, rischi contenuti non letti o layout errati.
- Non usare robots.txt per “noindex”: per escludere una pagina dall’indice usa
<meta name="robots" content="noindex">
o headerX-Robots-Tag
. Il robots.txt governa la scansione, non l’indicizzazione. - Inserisci le Sitemap: aiuta il discovery di nuove URL e velocizza la scansione.
- Blocca solo ciò che è inutile o dannoso: carrello, checkout, risultati di ricerca interni, parametri di tracking (utm, gclid, fbclid…).
- Attento ai pattern: prima di disabilitare parametri come
?sort
o?page
, verifica che non servano a Google per raggiungere contenuti importanti. - Testa e monitora: usa gli strumenti di Search Console (“Ispezione URL”, “Scannerizza come Google/Visualizza pagina testata”) per vedere se asset o pagine importanti risultano bloccati.
Errori comuni da evitare
- Disallow: /wp-content/ (WordPress): contiene CSS/JS/immagini → bloccarlo danneggia il rendering.
- Bloccare /themes/ o /assets/ senza Allow specifici per le estensioni: molti bot non gestiscono bene gli override.
- Bloccare parametri strutturali (es.
?lingua=
o?format=
) se il CMS li usa per generare le pagine principali. - Usare robots.txt per nascondere dati sensibili: è pubblico; non è uno strumento di sicurezza.
- Confondere Disallow con noindex: una pagina disallow può comunque finire in indice se ci sono link esterni; Google la mostrerà senza snippet.
Esempi per e-commerce
Ecco un robots.txt “conservativo” che consente il rendering e blocca aree sensibili e tracking, senza interferire con la generazione delle pagine:
# e-commerce base
Sitemap: https://www.esempio.it/sitemap_index.xml
User-agent: *
# Consentire asset
Allow: /*.css$
Allow: /*.js$
Allow: /*.mjs$
Allow: /*.json$
Allow: /*.jpg$
Allow: /*.jpeg$
Allow: /*.png$
Allow: /*.webp$
Allow: /*.svg$
Allow: /*.woff$
Allow: /*.woff2$
# Aree sensibili
Disallow: /carrello
Disallow: /checkout
Disallow: /pagamento
Disallow: /account
Disallow: /login
Disallow: /logout
Disallow: /wp-admin
Allow: /wp-admin/admin-ajax.php
# Ricerca interna & tracking
Disallow: /search
Disallow: /*?*q=
Disallow: /*?*utm_
Disallow: /*?*gclid=
Disallow: /*?*fbclid=
# Parametri di ordinamento/paginazione (valutare con cautela)
# Disallow: /*?*sort=
# Disallow: /*?*order=
# Disallow: /*?*page=
Quando essere più aggressivi? Se hai URL canoniche pulite e parametri “solo UI”, puoi disalloware di più. Ma testalo: evita di nascondere percorsi reali per categorie/prodotti.
Esempi per siti multilingua
Se usi sottocartelle (/it/
, /en/
) mantieni un solo robots.txt alla root e gestisci le sitemap per lingua:
Sitemap: https://www.sito.com/sitemap_it.xml
Sitemap: https://www.sito.com/sitemap_en.xml
User-agent: *
Allow: /
# Evita di bloccare i percorsi /it/ o /en/ se sono canonici
# Gestisci eventuali parametri di lingua con attenzione:
# Disallow: /*?lang= <-- solo se non usato come URL canonico
Ricorda di usare anche gli hreflang
nelle pagine, che non dipendono dal robots.txt ma aiutano la geolocalizzazione linguistica.
Parametri URL: come decidere cosa bloccare
I parametri sono di tre tipi:
- Strutturali: generano contenuti principali (es.
?categoria=
,?lingua=
). Non bloccarli. - Funzionali: ordinamenti, filtri, paginazione (
?sort=
,?page=
). Valuta caso per caso; spesso è meglio gestirli con canonical e impostazioni “Parametri URL” in Search Console. - Tracciamento:
?utm_*
,?gclid
,?fbclid
. Puoi disalloware senza rischi.
Una strategia solida è: non bloccare parametri che creano pagine a valore, consolidare via canonical e disalloware solo tracking e duplicati palesi.
Rendering: perché consentire CSS/JS/immagini
Google esegue un rendering avanzato della pagina. Se CSS/JS sono bloccati, il motore può valutare male layout, contenuti dinamici e segnali UX (Core Web Vitals). L’indicizzazione può soffrirne e le anteprime in SERP risultare imprecise. Per questo conviene non disalloware cartelle come /wp-content/
, /themes/
, /assets/
e simili.
Se per qualche motivo devi disalloware una directory, usa Allow per estensione (più specifiche del Disallow) — tenendo presente che alcuni bot non interpretano bene le eccezioni.
Crawl budget: come non sprecarlo
- Blocca pagine a basso valore SEO: risultati di ricerca interni, cartelle di log, endpoint con infinite combinazioni di parametri.
- Evita catene di redirect: sprecano crawl budget; rendi le URL canoniche accessibili e coerenti.
- Sitemap pulite: includi solo pagine indicizzabili (200 OK, non-noindex, canonical a sé stesse).
- Prestazioni server: un sito veloce “invoglia” i bot a scansionare di più e più spesso.
Sicurezza e privacy: robots.txt non è un antifurto
Il robots.txt è pubblico e “onorevole”: chiede gentilmente ai bot di non scansionare alcune aree. Ma non impedisce a malintenzionati o a bot non conformi di visitarle. Non inserire percorsi sensibili che non vuoi rivelare: usa autenticazione, IP whitelisting o protezione via server.
Se devi rimuovere dall’indice contenuti già indicizzati, usa meta noindex o header X-Robots-Tag: noindex e, se urgente, lo strumento di rimozione in Search Console.
Test, monitoraggio e debugging
- Search Console → Ispezione URL: verifica “Indicizzazione consentita?”, “Risorse della pagina” e screenshot del rendering.
- Log di accesso: analizza le visite di Googlebot per capire dove “spreca” crawl budget.
- Controllo header: con
curl -I
verifica che gli asset rispondano 200 e non abbianoX-Robots-Tag: noindex
. - Tester robots.txt: valuta una manciata di URL critiche (home, categoria, prodotto, pagina filtrata, asset CSS/JS).
- Monitoraggio periodico: quando cambi CMS/tema o regole CDN/WAF, ricontrolla robots, sitemap e accesso agli asset.
Template pronti (copiabili)
1) Base “allow rendering”
Sitemap: https://www.sito.it/sitemap_index.xml
User-agent: *
Allow: /*.css$
Allow: /*.js$
Allow: /*.mjs$
Allow: /*.json$
Allow: /*.jpg$
Allow: /*.jpeg$
Allow: /*.png$
Allow: /*.webp$
Allow: /*.svg$
Allow: /*.woff$
Allow: /*.woff2$
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
# Evita search interni e tracking
Disallow: /search
Disallow: /*?*utm_
Disallow: /*?*gclid=
Disallow: /*?*fbclid=
2) E-commerce conservativo
Sitemap: https://www.shop.it/sitemap_index.xml
User-agent: *
Allow: /*.css$
Allow: /*.js$
Allow: /*.webp$
Allow: /*.svg$
Allow: /*.woff$
Allow: /*.woff2$
# Aree sensibili
Disallow: /carrello
Disallow: /checkout
Disallow: /account
Disallow: /login
Disallow: /logout
# Ricerca interna & tracking
Disallow: /search
Disallow: /*?*utm_
Disallow: /*?*gclid=
Disallow: /*?*fbclid=
3) Multilingua con sitemap separate
Sitemap: https://www.sito.com/sitemap_it.xml
Sitemap: https://www.sito.com/sitemap_en.xml
User-agent: *
Allow: /
# Non bloccare /it/ e /en/ se canonici
# Valuta i parametri lingua solo se non usati come URL principali
# Disallow: /*?lang=
4) Staging/Dev (meglio protezione con login/IP)
# ATTENZIONE: robots non è sicurezza.
# Usa HTTP auth o IP whitelisting. In aggiunta:
User-agent: *
Disallow: /
FAQ essenziali
Il robots.txt blocca l’indicizzazione?
No. Blocca la scansione. Per evitare l’indice usa “noindex” via meta o header.
Posso elencare le Sitemap nel robots.txt?
Sì, è raccomandato. Mantienile aggiornate.
Devo usare Crawl-delay?
Google lo ignora; Bing/Yandex lo rispettano. Usalo solo se hai reali problemi server.
Meglio Disallow su /wp-content/?
No: contiene asset fondamentali. Evitalo o prevedi Allow specifici (comunque meno compatibili).
Ho bloccato una pagina e continuo a vederla in SERP:
se ha link esterni e non può essere scansionata, può apparire come “URL conosciuta” senza snippet. Aggiungi noindex
(meta/header) o usa lo strumento di rimozione in GSC.
Checklist operativa
- La home, categorie, prodotti e articoli sono Allow e rispondono 200 OK.
- CSS/JS/immagini/font non sono bloccati.
- Carrello/checkout/account Disallow.
- Search interni e parametri di tracking (
utm_
,gclid
,fbclid
) Disallow. - Sitemap dichiarate in robots.txt e inviate in Search Console.
- Parametri di filtro/ordinamento gestiti (canonical/GSC) e non bloccano contenuti a valore.
- Nessun uso del robots.txt per “noindex”.
- Test con GSC → Ispezione URL → Rendering e risorse bloccate.
- Controllo periodico dopo deploy, cambio tema/CDN o migrazioni.
Conclusione: un robots.txt ben progettato non è un semplice “file di cortesia”. È un componente strategico della tua SEO tecnica: guida i bot, libera risorse, mantiene pulito l’indice e supporta performance e sicurezza complessive del sito.