SEO Basic

Il file robots.txt è un semplice file di testo che sta nella root del dominio e dice ai crawler cosa possono scansionare e cosa no. È uno dei primi file che guardo in un audit SEO, perché un robots.txt rotto può rendere invisibile un intero sito in pochi minuti. Ed è anche uno dei file più fraintesi: blocca la scansione, non l’indicizzazione, e questa distinzione è cruciale.

Cosa fa (e cosa non fa) robots.txt

Cosa fa:

  • Indica ai crawler conformi quali URL non devono scaricare
  • Segnala la posizione della sitemap XML
  • Può limitare la frequenza di scansione di alcuni crawler (direttiva crawl-delay, non supportata da Googlebot)

Cosa NON fa:

  • Non impedisce l’indicizzazione. Una URL bloccata in robots.txt ma linkata da altri siti può comunque apparire nei risultati di ricerca, senza snippet e con descrizione generica
  • Non protegge contenuti riservati. Chi vuole accedere a un file, lo fa comunque: robots.txt è pubblico e leggibile da chiunque
  • Non vincola tutti i crawler. Googlebot, Bingbot e gli altri crawler “ufficiali” rispettano robots.txt. Scraper aggressivi lo ignorano

Regola mentale: robots.txt controlla il crawling, non l’indicizzazione. Per la deindicizzazione serve noindex.

Sintassi base

Il file si chiama esattamente robots.txt (minuscolo) e sta nella root del dominio: https://esempio.com/robots.txt. Deve essere UTF-8, con righe separate da newline.

Struttura di base:

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

User-agent: Googlebot
Disallow: /area-riservata/

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

Regole:

  • User-agent: a chi si applicano le regole seguenti (* = tutti i bot, oppure nome specifico)
  • Disallow: percorsi da non scansionare (relativi alla root)
  • Allow: percorsi da scansionare, anche dentro una Disallow più ampia (utile per eccezioni)
  • Sitemap: URL assoluta della sitemap XML (una o più righe)
  • # all’inizio di una riga: commento

Ogni blocco User-agent: è indipendente: quando Googlebot legge il file, applica solo le direttive sotto User-agent: Googlebot se presenti; altrimenti quelle sotto User-agent: *.

Come Google interpreta i path

Alcuni dettagli che fanno la differenza:

1. Le direttive sono case-sensitive su percorsi URL.

Disallow: /Private/   ← blocca /Private/ ma NON /private/

2. Il trailing slash conta.

Disallow: /admin      ← blocca /admin, /admin/, /administrator
Disallow: /admin/     ← blocca /admin/ e sottocartelle, NON /administrator

3. I wildcard sono supportati da Google:

  • * corrisponde a qualsiasi sequenza di caratteri
  • $ indica la fine della URL
Disallow: /*?          ← blocca tutte le URL con query string
Disallow: /*.pdf$      ← blocca tutti i PDF
Disallow: /*utm_*      ← blocca URL con parametri UTM

4. In caso di conflitto tra Allow e Disallow, vince la regola più specifica.

Disallow: /blog/
Allow: /blog/importante/

→ /blog/pippo bloccato, /blog/importante/pippo consentito.

Esempi pratici per diversi CMS

WordPress (installazione base)

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /*?s=
Allow: /wp-admin/admin-ajax.php

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

Note:

  • wp-admin/admin-ajax.php è ammesso perché serve al frontend (WooCommerce, form dinamici)
  • /?s= e /*?s= bloccano la ricerca interna (produce URL infinite inutili)
  • Non bloccare /wp-content/ o /wp-includes/: Google ha bisogno di CSS e JS per renderizzare

WooCommerce

Aggiunge alla configurazione WordPress base:

Disallow: /carrello/
Disallow: /checkout/
Disallow: /mio-account/
Disallow: /*add-to-cart=
Disallow: /*?orderby=
Disallow: /*?filter_

Magento 2

User-agent: *
Disallow: /admin/
Disallow: /catalogsearch/
Disallow: /checkout/
Disallow: /customer/
Disallow: /sendfriend/
Disallow: /review/
Disallow: /wishlist/
Disallow: /*?SID=
Disallow: /*?p=
Disallow: /*?dir=
Disallow: /*?order=
Disallow: /*?limit=

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

Staging / ambiente di sviluppo

Mai lasciare questo in produzione:

User-agent: *
Disallow: /

Bloccare completamente un sito di staging evita che finisca in indice. Controlla sempre che in produzione non ci sia questa direttiva.

Cosa NON bloccare

Errori ricorrenti che ho visto in audit reali:

1. Non bloccare CSS e JavaScript. Google ha bisogno di renderizzare le pagine per valutarle. Bloccare /wp-content/themes/ o /assets/ significa che Google vede una pagina spezzata, con valutazione UX pessima.

2. Non bloccare immagini se vuoi visibilità in Google Images. A meno che tu abbia motivi specifici, le immagini vanno scansionate.

3. Non bloccare la sitemap stessa. Sembra ovvio ma succede: template di robots.txt con Disallow: /sitemap.xml.

4. Non bloccare URL che vuoi deindicizzare. Se blocchi via robots.txt una URL che era indicizzata, Google non può più crawlarla, quindi non può vedere il noindex che stavi impostando. La URL resta in indice, magari per mesi. Sequenza corretta per deindicizzare:

  1. Imposta noindex sulla pagina
  2. Aspetta che Google la ricrawli e veda il noindex
  3. Solo dopo la deindicizzazione, eventualmente bloccala in robots.txt per risparmiare crawl budget

Dimensione e limiti

Google ha limiti pratici:

  • Dimensione massima: 500 KiB. Oltre, Google legge solo i primi 500 KiB
  • Cache: Google tipicamente ricrawla robots.txt ogni 24 ore; in caso di errore (5xx), usa l’ultima versione in cache per un giorno, poi comincia a scansionare come se non ci fosse
  • Posizione fissa: https://dominio/robots.txt. Non funziona in sottocartelle. Per sottodomini, ogni sottodominio ha il suo robots.txt

Testare robots.txt

1. Visita direttamente l’URL. https://tuosito.com/robots.txt deve restituire 200 con il file. Se restituisce 404, Google assume che non ci siano restrizioni (comportamento ok, ma perdi il segnale sitemap).

2. Usa il tester in Google Search Console. Impostazioni > robots.txt mostra la versione vista da Google e permette di testare URL specifiche. Fondamentale prima di andare live.

3. Verifica con Screaming Frog in “Crawl Configuration”. Puoi simulare un crawl rispettando o ignorando robots.txt. Utile per audit.

Casi critici da monitorare

Situazioni in cui controllo sempre il robots.txt:

  • Subito dopo una migrazione: staging può avere Disallow: / ancora attivo
  • Dopo un aggiornamento di CMS o plugin SEO: alcuni plugin sovrascrivono il robots.txt
  • Calo improvviso di traffico organico: prima ipotesi sempre robots.txt
  • Quando vedi URL indicizzate che non dovrebbero esserlo: forse hai bloccato il crawling di pagine che avevano noindex, Google non ha potuto leggere il noindex
  • Su siti multi-dominio o multi-sottodominio: ogni sottodominio deve avere il proprio

Alternativa: X-Robots-Tag nell’header HTTP

Per file non HTML (PDF, immagini, video) dove non puoi mettere meta tag nel <head>, usa l’header HTTP:

HTTP/1.1 200 OK
X-Robots-Tag: noindex, nofollow
Content-Type: application/pdf

Configurazione tipica in .htaccess:

<FilesMatch "\.(pdf)$">
  Header set X-Robots-Tag "noindex, nofollow"
</FilesMatch>

Takeaway

  • Robots.txt controlla il crawling, non l’indicizzazione
  • Per deindicizzare serve noindex (nella pagina o nell’header), non robots.txt
  • Non bloccare MAI CSS e JavaScript: Google ha bisogno di renderizzare
  • Wildcard supportati (* e $): utili per bloccare pattern complessi
  • In caso di migrazione o aggiornamento plugin, verifica sempre robots.txt: è la prima cosa che può rompersi
  • Staging e produzione devono avere robots.txt diversi: lo staging Disallow: /, produzione le regole reali

Link interni suggeriti:

Altri articoli sulla SEO:

Torna in alto