Robots.txt avanzato: allow/deny reali

Il file robots.txt è uno degli strumenti più fondamentali e, allo stesso tempo, più fraintesi nel panorama della SEO tecnica e della gestione dei siti web. Sebbene la sua sintassi base sia semplice, l’interazione tra le direttive Allow e Disallow può generare comportamenti inattesi se non compresa a fondo. Questo articolo è rivolto a sviluppatori e SEO specialist che vogliono andare oltre le nozioni di base e padroneggiare il controllo del crawling attraverso un uso avanzato del file robots.txt e delle sue direttive allow e deny nel loro comportamento reale.

Cos’è il robots.txt e perché è importante

Il file robots.txt è un semplice file di testo posizionato nella directory principale di un sito web (es. tuosito.it/robots.txt). Agisce come una “gentile richiesta” ai web crawler (come Googlebot, Bingbot, ecc.) su quali parti del sito possono o non dovrebbero visitare (fare il crawling). Non è un meccanismo di sicurezza per nascondere contenuti sensibili, ma piuttosto uno strumento per gestire il carico sul server dovuto al crawling e per guidare i bot verso i contenuti più importanti.

È fondamentale per diversi motivi:

1. Gestione del Crawl Budget: Su siti molto grandi o con molte pagine poco rilevanti, un robots.txt ben configurato aiuta i bot a concentrare il loro “crawl budget” (il numero di pagine che un bot scansiona su un sito in un dato periodo) sulle aree di valore, migliorando potenzialmente la frequenza di scansione dei contenuti chiave.
2. Prevenzione di Sovraccarichi: Impedisce ai crawler di scansionare aree che potrebbero generare un carico eccessivo sul server (es. script CGI pesanti, infinite directory calendaristiche).
3. Controllo dell’Accesso: Permette di bloccare l’accesso a sezioni private, aree di staging, risultati di ricerca interni, pagine di login, ecc., che non dovrebbero apparire nei risultati dei motori di ricerca.

Per una panoramica più ampia sulla SEO tecnica, puoi consultare la nostra guida completa alla SEO tecnica per developer.

Differenza tra crawling e indicizzazione

Prima di addentrarci nelle specifiche di Allow e Disallow, è cruciale capire la distinzione tra crawling e indicizzazione:

• Crawling (Scansione): È il processo con cui i web crawler scoprono e scaricano le pagine e le risorse di un sito web. Il robots.txt controlla questo processo.
• Indicizzazione: È il processo con cui un motore di ricerca analizza il contenuto di una pagina scansionata, ne comprende l’argomento e la salva nel suo indice per poterla mostrare nei risultati di ricerca per query pertinenti.

Un errore comune: Bloccare una pagina tramite Disallow nel robots.txt impedisce ai bot di scansionarla, ma non garantisce che non venga indicizzata. Se una pagina bloccata da robots.txt riceve link da altre pagine scansionabili (sia interne che esterne), i motori di ricerca potrebbero comunque indicizzarla, mostrandone solo l’URL e, a volte, uno snippet basato sul testo dei link che puntano ad essa (il cosiddetto “indexed, though blocked by robots.txt”).

Per impedire l’indicizzazione di una pagina, anche se scansionabile, si deve usare il meta tag <meta name="robots" content="noindex"> o l’header HTTP X-Robots-Tag: noindex. Il robots.txt controlla l’accesso, non l’inclusione nell’indice.

Come funziona realmente robots.txt

Il file robots.txt è interpretato dai crawler riga per riga, dall’alto verso il basso. Un file tipico è composto da uno o più blocchi, ciascuno iniziato da una direttiva User-agent:.

• User-agent:: Specifica a quale crawler si applicano le direttive successive. User-agent: * si rivolge a tutti i crawler che non hanno un blocco specifico. Puoi avere blocchi separati per Googlebot, Bingbot, GPTBot (per l’addestramento di modelli AI, vedi anche Cos’è il file llms.txt e perché è fondamentale per AI e siti web), ecc.
• Disallow:: Specifica i percorsi (relativi alla root del dominio) che il bot non deve scansionare. Disallow: / blocca l’intero sito. Disallow: /privata/ blocca la cartella /privata/ e tutto il suo contenuto.
• Allow:: Specifica i percorsi che il bot può scansionare all’interno di un percorso altrimenti bloccato da un Disallow. Questa è la chiave dell’uso avanzato e del comportamento dei robots.txt allow deny.
• Sitemap:: Indica l’URL delle Sitemap XML del sito. Non è una direttiva di controllo crawling/indexing, ma è utile per informare i bot dove trovare l’elenco delle pagine importanti.

Le direttive supportano i wildcard:

• *: Corrisponde a qualsiasi sequenza di caratteri.
• $: Corrisponde alla fine dell’URL.

Esempio base:

User-agent: *
Disallow: /admin/
Disallow: /private/
Allow: /private/public-content/

In questo esempio, tutti i bot (*) non possono accedere alle cartelle /admin/ e /private/, tranne alla sottocartella /private/public-content/ che viene esplicitamente consentita.

Limitazioni reali del robots.txt

Come accennato, robots.txt è solo una raccomandazione.

1. Non è una barriera di sicurezza: Crawler malevoli o non standard potrebbero ignorarlo completamente.
2. Non impedisce l’indicizzazione: Blocca solo la scansione. Le URL bloccate potrebbero comunque apparire nei risultati di ricerca se linkate.
3. Le URL bloccate sono (spesso) pubbliche: Il file robots.txt è accessibile pubblicamente. Non inserire in esso percorsi a contenuti veramente sensibili (es. cartelle con nomi utente/password nel percorso), perché chiunque potrebbe leggerli.

Allow e Deny effettivi: come si comportano i crawler

Qui sta la parte più complessa e interessante, dove il comportamento reale di robots.txt allow deny mostra le sue sfumature. Quando un bot deve decidere se scansionare un URL, applica delle regole di precedenza:

1. Il bot cerca il blocco User-agent più specifico. Se trova un blocco per “Googlebot” e uno per “*”, userà le direttive del blocco “Googlebot” per Googlebot.
2. All’interno del blocco User-agent corretto, il bot confronta tutte le direttive Allow e Disallow che corrispondono all’URL in questione.
3. La regola con il percorso più lungo (quella più specifica) vince. Se c’è un Disallow: /cartella/sotto/ e un Allow: /cartella/sotto/pagina.html, l’URL /cartella/sotto/pagina.html corrisponde a entrambe. Poiché /cartella/sotto/pagina.html è più lungo di /cartella/sotto/, la regola Allow vince e la pagina è scansionabile.
4. In caso di parità di lunghezza del percorso tra una regola Allow e una Disallow che corrispondono all’URL, Googlebot dà precedenza all’Allow. Altri crawler potrebbero comportarsi diversamente, dando priorità al Disallow. Per questo motivo, è una best practice basarsi sulla specificità del percorso (Disallow: /abc e Allow: /abc/xyz -> Allow vince per /abc/xyz) piuttosto che sulla parità di lunghezza.

Capire la priorità basata sulla specificità è la chiave per padroneggiare i robots.txt allow deny.

Esempi pratici di precedenza:

Esempio 1: Disallow generale vs Allow specifico

User-agent: *
Disallow: /prodotti/
Allow: /prodotti/offerte/

• /prodotti/scarpe/pagina.html: Corrisponde a Disallow: /prodotti/. Bloccato.
• /prodotti/offerte/pagina.html: Corrisponde sia a Disallow: /prodotti/ che a Allow: /prodotti/offerte/. Allow: /prodotti/offerte/ è più specifico. Consentito.

Esempio 2: Allow generale vs Disallow specifico

User-agent: *
Allow: /
Disallow: /immagini/private/

• /pagina.html: Corrisponde ad Allow: /. Consentito.
• /immagini/private/logo.jpg: Corrisponde sia ad Allow: / che a Disallow: /immagini/private/. Disallow: /immagini/private/ è più specifico. Bloccato.

Esempio 3: Parità di lunghezza (comportamento di Googlebot)

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

• /private: Corrisponde solo a Disallow: /private. Bloccato.
• /private.html: Corrisponde sia a Disallow: /private che a Allow: /private.html. Le lunghezze sono uguali. Per Googlebot, Allow ha la precedenza. Consentito. (Attenzione: altri bot potrebbero bloccarlo).

Esempio 4: Uso del $

User-agent: *
Allow: /file.pdf$
Disallow: /file

• /file.pdf: Corrisponde sia ad Allow: /file.pdf$ che a Disallow: /file. Allow: /file.pdf$ è più specifico (corrisponde all’intera stringa del nome file). Consentito.
• /file/documento.doc: Corrisponde solo a Disallow: /file. Bloccato.
• /file_vecchio.txt: Corrisponde solo a Disallow: /file. Bloccato.

Questi esempi mostrano perché una comprensione approfondita delle interazioni robots.txt allow deny è essenziale.

Esempi avanzati di configurazione

Vediamo alcuni scenari comuni e come risolverli con Allow e Disallow avanzati.

Bloccare tutte le immagini tranne quelle in una specifica cartella: Se hai molte immagini che non sono rilevanti per la SEO e vuoi conservare il crawl budget, ma devi permettere l’accesso a quelle in una cartella specifica (es. /assets/immagini-prodotti/) perché sono vitali per il rendering o sono immagini prodotto indicizzabili.

User-agent: *
# Blocca tutte le URL che terminano con .jpg, .jpeg, .png, .gif, .webp
Disallow: /*.jpg$
Disallow: /*.jpeg$
Disallow: /*.png$
Disallow: /*.gif$
Disallow: /*.webp$

# Consenti specificamente le immagini nella cartella desiderata
Allow: /assets/immagini-prodotti/*.jpg$
Allow: /assets/immagini-prodotti/*.jpeg$
Allow: /assets/immagini-prodotti/*.png$
Allow: /assets/immagini-prodotti/*.gif$
Allow: /assets/immagini-prodotti/*.webp$

Questo approccio blocca la maggior parte delle immagini, ma consente specificamente quelle nel percorso indicato.

Consentire il crawling solo a determinati bot ( whitelist): Se vuoi che solo bot specifici (es. Googlebot e Bingbot) scansionino il tuo sito, bloccando tutti gli altri (inclusi i “Good bot” come quelli di Majestic o Ahrefs, se non li desideri, o potenziali bot meno “gentili”).

User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

User-agent: *
Disallow: /

In questo caso, il blocco User-agent: * con Disallow: / è la regola più generale e bloccherebbe tutto. Tuttavia, i bot Googlebot e Bingbot troveranno il loro blocco specifico (User-agent: Googlebot e User-agent: Bingbot) e applicheranno la regola Allow: /, che consente loro l’accesso all’intero sito, ignorando il blocco generico.

Impedire crawling di query string e pagine di ricerca interna: Le URL con parametri di query (es. ?sid=..., ?sort=...) o le pagine di ricerca interna possono generare una quantità enorme di URL duplicate o di basso valore per la SEO, sprecando crawl budget.

User-agent: *
# Blocca qualsiasi URL contenente un "?" (inizio di query string)
Disallow: /*?

# Esempio specifico per una pagina di ricerca interna (se ha un percorso dedicato)
Disallow: /ricerca/risultati/
Disallow: /search/

La direttiva Disallow: /*? è molto potente e blocca tutte le URL che iniziano con qualsiasi cosa (*) e contengono un punto interrogativo. Fai attenzione ad usarla se hai URL con parametri che devono essere scansionati (es. paginazione ?pagina=2). In quel caso, potresti aver bisogno di regole Allow specifiche per quei parametri essenziali o bloccare solo parametri noti e indesiderati.

Robots.txt e SEO

L’uso corretto del robots.txt ha un impatto diretto sulla SEO:

Quando bloccare risorse è utile:

Pagine di login, aree admin, profili utente privati: Mantengono queste aree fuori dall’indice e dal crawl inutile.

Risultati di ricerca interni: Evitano la scansione di pagine dinamiche e spesso duplicate generate dalle query degli utenti.

URL con parametri di filtro/ordinamento non canonici: Aiuta a consolidare il crawl budget sulle URL “pulite” e canoniche. Le canonical tag sono l’alternativa o il complemento ideale qui.

Contenuti di staging/sviluppo: Impedisce che versioni non definitive del sito finiscano nell’indice.

Script o stili non essenziali: In teoria, potresti bloccare CSS/JS non necessari per risparmiare crawl budget, ma fai molta attenzione.

Quando può creare problemi di indicizzazione (es. CSS e JS bloccati): Con l’indicizzazione mobile-first, Googlebot scansiona e renderizza le pagine come farebbe un utente mobile. Per fare ciò correttamente, Googlebot deve poter accedere alle risorse CSS e JavaScript che definiscono l’aspetto e il comportamento della pagina. Bloccare file CSS o JS essenziali nel robots.txt è un errore grave che impedisce a Google di renderizzare la pagina correttamente, compromettendo la sua capacità di comprenderne il contenuto e potenzialmente portando a un posizionamento inferiore o all’esclusione dall’indice. Assicurati sempre che i percorsi che contengono i tuoi file .css, .js, font o altre risorse critiche per il rendering siano consentiti nel tuo robots.txt. Per esempio:

User-agent: *
Disallow: /wp-admin/ # Esempio di blocco comune per WordPress
Disallow: /wp-includes/ # Blocca file non essenziali (vedi nota sotto)

# Assicurati che /wp-content/ (dove stanno temi, plugin, upload) sia consentito
Allow: /wp-content/
# Anche se wp-includes contiene file come js/css, spesso si sconsiglia di bloccarlo
# completamente perché alcuni file potrebbero essere usati per il rendering.
# È meglio essere permissivi su cartelle come /wp-includes/ o specifiche sottocartelle essenziali.

In un ambiente WordPress, è comune bloccare /wp-admin/, ma bloccare integralmente /wp-includes/ è rischioso. Molti temi e plugin caricano risorse cruciali da qui. È più sicuro lasciare /wp-includes/ scansionabile o, se necessario bloccare specifiche sottocartelle non essenziali, usare regole Allow precise per quelle critiche. Per gestire script in modo ottimale in WordPress, consulta anche l’articolo su Hook wp_enqueue_script: caricare JavaScript in modo ottimale.

Alternative e best practice

Mentre robots.txt è utile, non è l’unico strumento e non è sempre il migliore.

• Meta Tag noindex o Header X-Robots-Tag: Se l’obiettivo è impedire l’indicizzazione (mostrare la pagina nei risultati di ricerca), usa <meta name="robots" content="noindex"> nel <head> della pagina HTML o l’header HTTP X-Robots-Tag: noindex. Questo è più affidabile del Disallow per rimuovere pagine dall’indice. L’X-Robots-Tag è utile per risorse non HTML come PDF o immagini.
• Canonical Tag: Per gestire contenuti duplicati (es. versioni con parametri, versioni AMP), usa il <link rel="canonical" href="..."> per indicare la versione preferita. Questo guida i motori di ricerca a consolidare i segnali di ranking sull’URL canonica.
• Sitemap XML: Aiuta i motori di ricerca a scoprire le pagine che vuoi che scansionino e indicizzino. Non include le pagine bloccate nel robots.txt.
• Reindirizzamenti 301: Se una pagina non esiste più, reindirizzala (301) a una pagina rilevante per consolidare il valore SEO.

Best practice:

• Mantieni il tuo robots.txt il più semplice possibile. Regole complesse aumentano il rischio di errori.
• Usa Allow solo quando devi creare un’eccezione all’interno di un Disallow più ampio.
• Non bloccare risorse essenziali per il rendering (CSS, JS, font, immagini cruciali).
• Testa sempre le modifiche.

Testing e validazione

Modificare il robots.txt può avere effetti drastici sulla visibilità del tuo sito. Il testing è fondamentale.

• Strumenti di Google Search Console: Il robots.txt Tester in Google Search Console è lo strumento più affidabile per verificare come Googlebot interpreterà il tuo file. Puoi incollare il tuo file, selezionare User-agent e inserire URL per vedere se verrebbero bloccate o consentite secondo le regole attuali o una versione di prova. È indispensabile per verificare l’interazione dei tuoi robots.txt allow deny rules.
• Screaming Frog SEO Spider: Questo tool desktop simula il comportamento di un crawler e ti mostra come il tuo robots.txt influisce sulla capacità dello spider di accedere alle varie URL del tuo sito. È ottimo per un test locale prima di caricare il file online.
• Altri SEO audit tool: Molti software di SEO auditing includono controlli sul robots.txt per identificare errori di sintassi o conflitti.

Debugging di Allow/Disallow in situazioni complesse: Quando hai regole Allow e Disallow che si sovrappongono, usa il tester di Google Search Console:

1. Incolla il tuo robots.txt.
2. Seleziona il User-agent che ti interessa (es. Googlebot Smartphone).
3. Inserisci l’URL che stai testando.
4. Lo strumento ti dirà se l’URL è consentita o bloccata e, soprattutto, quale regola specifica ha determinato quella decisione. Questo è cruciale per capire perché una certa URL si comporta in un modo inaspettato secondo le tue direttive robots.txt allow deny.

Conclusione

Il file robots.txt è uno strumento potente per gestire il comportamento dei web crawler, ma richiede una comprensione precisa del suo funzionamento, in particolare dell’interazione e della precedenza delle direttive Allow e Disallow. Ricorda che controlla il crawling, non l’indicizzazione, e che bloccare risorse cruciali (come CSS e JS) può danneggiare la tua SEO.

Padroneggiare i robots.txt allow deny reali ti consente di ottimizzare il crawl budget, proteggere aree private e assicurare che i motori di ricerca possano accedere alle risorse necessarie per comprendere e posizionare correttamente le tue pagine.

Ecco una checklist per un robots.txt performante e sicuro:

Checklist per un robots.txt performante e sicuro:

• È posizionato nella root directory (/robots.txt)?
• È accessibile pubblicamente?
• Contiene un User-agent: * come fallback?
• Sono presenti direttive Disallow per aree private (admin, login, ecc.)?
• Sono presenti direttive Disallow per URL con parametri non desiderati o pagine di ricerca interna?
• Sono presenti direttive Allow per creare eccezioni necessarie all’interno di blocchi Disallow più ampi? (Hai verificato l’interazione robots.txt allow deny?)
• Non blocca risorse essenziali per il rendering (CSS, JS, font)? Questo è vitale per la SEO mobile-first.
• Punta alla Sitemap XML corretta?
• È stato testato con il robots.txt Tester di Google Search Console o strumenti simili?
• Non contiene percorsi che rivelano informazioni sensibili?

Revisionare periodicamente il tuo file robots.txt è essenziale, specialmente dopo aggiornamenti importanti del sito, migrazioni o installazione di nuovi plugin/funzionalità che potrebbero creare nuove aree da gestire.