Come configurare il file robots.txt senza errori

Il file robots.txt indica ai crawler quali URL possono richiedere e quali non dovrebbero scansionare. Deve trovarsi nella radice dell’host, per esempio https://esempio.it/robots.txt, e va configurato con attenzione perché una regola errata può bloccare sezioni importanti del sito.

Robots.txt controlla principalmente la scansione. Non è uno strumento di sicurezza e non garantisce l’esclusione di un URL dai risultati di ricerca.

Che cos’è il file robots.txt?

È un file di testo letto dai crawler prima di visitare un sito. Ogni gruppo di regole specifica uno o più user-agent e le directory o risorse che possono essere richieste.

Google spiega nella propria introduzione a robots.txt che il file serve soprattutto a gestire l’accesso dei crawler e non a mantenere una pagina fuori dall’indice.

Dove deve essere inserito?

Il file deve essere disponibile nella radice esatta di protocollo, host e porta a cui si applica.

Ogni sottodominio deve avere il proprio file. Se il sito risponde sia con www sia senza www, è opportuno verificare redirect e host canonico.

Qual è la sintassi di base?

User-agent: *
Disallow: /area-privata/
Allow: /area-privata/file-pubblico.pdf

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

Le direttive principali sono:

• User-agent: crawler a cui si applica il gruppo;
• Disallow: percorso che non dovrebbe essere scansionato;
• Allow: eccezione consentita all’interno di un percorso bloccato;
• Sitemap: URL assoluto della sitemap XML.

Le righe vuote separano i gruppi. I commenti iniziano con #.

Come consentire la scansione di tutto il sito?

User-agent: *
Disallow:

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

Una direttiva Disallow vuota non blocca percorsi. Anche l’assenza del file permette normalmente la scansione, ma pubblicarlo può essere utile per indicare la sitemap e documentare le regole.

Come bloccare l’intero sito?

User-agent: *
Disallow: /

Questa configurazione impedisce ai crawler conformi di richiedere il sito. È pericolosa in produzione e viene spesso lasciata per errore dopo il passaggio da staging a pubblico.

Non usarla per proteggere dati riservati: il file è pubblico e crawler malevoli possono ignorarlo.

Robots.txt può rimuovere una pagina da Google?

No. Se una pagina è bloccata, Google potrebbe non leggerne il contenuto ma conoscere comunque l’URL attraverso link esterni o sitemap. L’URL può quindi apparire senza snippet.

Per escludere una pagina dall’indice si utilizza una direttiva noindex nella pagina o nell’header HTTP, lasciandola accessibile al crawler. La documentazione ufficiale spiega come bloccare l’indicizzazione con noindex.

Per contenuti realmente privati servono autenticazione, autorizzazione o protezione con password.

Robots.txt per WordPress

WordPress può generare un file virtuale quando non esiste un robots.txt fisico. È comunque possibile crearne uno nella document root o modificarne l’output tramite plugin e codice.

Un esempio prudente:

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

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

Non è necessario bloccare automaticamente /wp-content/, /wp-includes/, CSS o JavaScript. I motori possono aver bisogno di queste risorse per renderizzare correttamente le pagine.

Quali directory WordPress non bisogna bloccare alla cieca?

• file CSS e JavaScript del tema;
• immagini e media necessari alla pagina;
• endpoint utilizzati dal frontend;
• risorse di plugin che influenzano rendering e interazione;
• pagine pubbliche generate da WooCommerce o altri plugin.

Prima di aggiungere una regola, controlla quali URL corrispondono realmente al percorso e se sono necessari agli utenti o ai crawler.

Come gestire parametri e filtri?

Siti e-commerce e cataloghi possono generare molti URL tramite filtri, ordinamenti e parametri. Robots.txt può ridurre alcune richieste, ma non dovrebbe essere l’unico strumento.

Valuta anche:

• canonical corretti;
• link interni che non producano combinazioni infinite;
• gestione dei filtri realmente indicizzabili;
• noindex per pagine accessibili ma non utili in ricerca;
• configurazione della navigazione a faccette;
• sitemap contenente solo URL canonici.

Bloccare tutti gli URL con un carattere ? può impedire la scansione di pagine utili e di risorse necessarie.

Come indicare la sitemap?

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

L’URL deve essere assoluto. È possibile inserire più righe Sitemap. La presenza nel robots.txt non sostituisce l’invio e il monitoraggio attraverso Google Search Console.

Regole per crawler differenti

User-agent: Googlebot
Disallow: /test/

User-agent: *
Disallow: /area-temporanea/

Le regole specifiche e generiche devono essere valutate separatamente. Non creare gruppi complessi senza necessità, perché aumentano il rischio di comportamenti inattesi.

Caratteri jolly e fine URL

Google e altri crawler principali supportano comunemente:

• * per una sequenza di caratteri;
• $ per indicare la fine dell’URL.

User-agent: *
Disallow: /*?print=
Disallow: /*.pdf$

Queste regole vanno testate con URL reali. Un pattern troppo ampio può bloccare molte più pagine del previsto.

Errori comuni nel file robots.txt

• lasciare Disallow: / dopo la pubblicazione;
• inserire il file in una sottocartella;
• usare robots.txt per nascondere informazioni riservate;
• bloccare CSS, JavaScript e immagini necessari;
• pensare che Disallow equivalga a noindex;
• indicare una sitemap non raggiungibile;
• creare pattern non verificati;
• modificare il file senza controllare cache e CDN;
• avere file differenti su host che dovrebbero reindirizzare;
• bloccare endpoint utilizzati dall’applicazione.

Come verificare il file?

1. apri direttamente /robots.txt nel browser;
2. verifica HTTP 200 e contenuto restituito;
3. controlla che non venga mostrata una pagina HTML;
4. prova URL consentiti e bloccati con gli strumenti disponibili;
5. controlla Search Console per errori di scansione;
6. verifica la sitemap indicata;
7. svuota cache server e CDN dopo la modifica;
8. monitora log e scansione nei giorni successivi.

È utile conservare una copia precedente prima di ogni modifica.

Esempio per un sito WordPress pubblico

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

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

Questo è soltanto un punto di partenza. WooCommerce, aree riservate, ricerca interna e parametri possono richiedere regole diverse.

Esempio per un ambiente di staging

User-agent: *
Disallow: /

Per uno staging è comunque preferibile aggiungere autenticazione HTTP o limitazione IP. Robots.txt non impedisce l’accesso a chi conosce l’URL.

Cosa succede se robots.txt non è raggiungibile?

Il comportamento dipende dal codice HTTP e dal crawler. Un errore temporaneo del server può indurre il motore a sospendere la scansione per evitare di ignorare regole che potrebbero esistere. Un file non trovato viene invece generalmente interpretato come assenza di restrizioni.

Per questo il file dovrebbe restituire rapidamente una risposta coerente e non dipendere da plugin fragili, redirect multipli o pagine di errore HTML.

Cache, CDN e modifiche non visibili

Robots.txt può essere memorizzato da server, plugin, proxy e CDN. Dopo una modifica, apri il file senza autenticazione, controlla gli header e verifica la risposta da più reti quando possibile.

Se il contenuto continua a essere quello precedente:

1. svuota la cache del sito;
2. esegui il purge dell’URL /robots.txt;
3. controlla la cache del CDN;
4. verifica eventuali regole del web server;
5. controlla se WordPress genera un file virtuale;
6. assicurati che non esista un file fisico differente.

Robots.txt, canonical e sitemap devono essere coerenti

Una sitemap non dovrebbe includere URL bloccati, non canonici o reindirizzati. Allo stesso modo, una pagina canonica importante non dovrebbe essere impedita alla scansione.

Durante l’audit confronta:

• URL presenti nelle sitemap;
• regole Disallow;
• tag canonical;
• meta robots;
• redirect;
• link interni.

Contraddizioni tra questi segnali rallentano la diagnosi e possono impedire al motore di leggere direttive importanti.

Come gestire più domini e sottodomini?

Ogni host necessita del proprio robots.txt. Un file pubblicato su www.esempio.it non governa automaticamente shop.esempio.it o staging.esempio.it.

Per installazioni multisito crea una tabella con host, URL del file, sitemap e ambiente. Questo evita che regole di staging vengano replicate per errore sul dominio pubblico.

Domande frequenti

Il file robots.txt è obbligatorio?

No. Se manca, i crawler possono normalmente scansionare il sito. È utile per definire regole e indicare la sitemap.

Posso usare noindex nel robots.txt?

Non è una soluzione supportata da Google. Usa il meta tag robots o l’header HTTP e lascia la pagina accessibile alla scansione.

Quanto tempo serve perché una modifica venga recepita?

Dipende dalla frequenza con cui il crawler recupera il file e dalla cache. Controlla gli strumenti del motore e i log del server.

Devo bloccare wp-admin?

È una regola comune per ridurre scansioni inutili, mantenendo consentito admin-ajax.php quando serve al frontend.

Robots.txt protegge dagli scraper?

Solo i crawler che rispettano il protocollo seguono le regole. Per bot aggressivi servono firewall, rate limit e altri controlli.

Per una revisione più ampia della visibilità organica consulta anche la guida SEO per WordPress. Dopo modifiche importanti controlla inoltre sitemap, canonical e stato di indicizzazione delle pagine principali.

Quando il file viene gestito da WordPress o da un plugin SEO, conserva una copia della configurazione e verifica il risultato pubblico: la schermata del plugin non garantisce che proxy, cache o regole del server restituiscano lo stesso contenuto.

Conclusione

Configurare robots.txt significa controllare la scansione senza ostacolare contenuti e risorse importanti. Le regole devono essere semplici, documentate e testate.

Ricorda la distinzione fondamentale: Disallow gestisce l’accesso dei crawler, noindex gestisce l’indicizzazione e l’autenticazione protegge i contenuti privati.