Robots.txt: i 5 errori più comuni nel 2026 (che bloccano l’indicizzazione e i crawler AI)
Sono Jeansy Sese, consulente SEO e GEO a Pisa. Il robots.txt è il file di testo alla radice del dominio che dice ai crawler quali parti del sito possono visitare e quali no. È il file più piccolo e più pericoloso della SEO tecnica: una riga sbagliata può escludere dall’indice intere sezioni del sito, e nel 2026 il danno è doppio, perché oltre a Googlebot il file governa anche i crawler delle intelligenze artificiali (GPTBot, ClaudeBot, PerplexityBot). In questo articolo definisco cosa fa e cosa non fa il robots.txt, analizzo i 5 errori più comuni che incontro negli audit, spiego come impostare l’accesso dei crawler AI in base alla tua strategia e ti lascio un esempio di file corretto per un sito WordPress.
Il principio da tenere a mente per tutto l’articolo: il robots.txt gestisce la scansione (crawling), non l’indicizzazione. Confondere i due piani è l’origine di quasi tutti gli errori che seguono.
Indice
- Cosa fa davvero il robots.txt (e cosa non fa)
- Errore 1: bloccare CSS e JavaScript
- Errore 2: usare Disallow per deindicizzare una pagina
- Errore 3: bloccare i crawler AI senza una strategia
- Errore 4: dimenticare il file dopo staging e migrazioni
- Errore 5: sintassi sbagliata e regole in conflitto
- Il robots.txt corretto per un sito WordPress
- Domande frequenti sul robots.txt
Cosa fa davvero il robots.txt (e cosa non fa)
Il robots.txt fa una cosa sola: comunica ai crawler educati quali percorsi del sito non devono scansionare. Ogni blocco di regole ha uno User-agent (il crawler a cui si rivolge) e una o più direttive Disallow o Allow (i percorsi vietati o permessi). Il file vive sempre alla radice: dominio.it/robots.txt.
Le cose che il robots.txt non fa sono altrettanto importanti. Non deindicizza: una pagina bloccata può restare nell’indice se altri siti la linkano, mostrata senza descrizione. Non protegge: è un file pubblico, e i bot malevoli lo ignorano; i contenuti riservati si proteggono con l’autenticazione, non con il Disallow. Non è obbligatorio: un sito senza robots.txt viene scansionato per intero, e per molti siti piccoli questa è la configurazione migliore.
Nel 2026 il file ha assunto un secondo ruolo: è il punto di controllo dell’accesso dei crawler AI ai contenuti. Prima di arrivarci, però, vanno tolti di mezzo gli errori classici, perché continuano a fare più danni di tutti. Il primo è un residuo storico che non muore mai.
Errore 1: bloccare CSS e JavaScript
Il blocco delle risorse (Disallow su /wp-includes/, sulle cartelle dei CSS o dei JavaScript) è un’eredità delle vecchie configurazioni WordPress che circola ancora in migliaia di file copiati da guide datate. Il problema: Google renderizza le pagine come un browser, e se non può scaricare CSS e JS vede una pagina rotta, la valuta come tale, e la giudica anche sul piano mobile.
La verifica richiede un minuto: lo strumento Controllo URL di Search Console mostra la pagina come Google la vede, e l’elenco delle risorse bloccate dal robots.txt. Se nella lista compaiono fogli di stile o script del tema, il file va pulito.
La regola del 2026 è semplice: nessun Disallow sulle risorse che servono al rendering. I percorsi tecnici di WordPress che ha senso escludere sono pochi e precisi, e li vediamo nell’esempio finale. Questo errore danneggia il modo in cui Google vede le pagine; il secondo danneggia qualcosa di più profondo, perché nasce dalla confusione tra scansione e indicizzazione.
Errore 2: usare Disallow per deindicizzare una pagina
L’errore concettuale più frequente: una pagina non deve comparire su Google, quindi la si blocca nel robots.txt. Il risultato è l’opposto dell’intenzione: il blocco impedisce a Googlebot di visitare la pagina, quindi Google non può leggere l’eventuale tag noindex, e se la pagina riceve link da altri siti resta nell’indice come risultato “nudo”, con l’URL e la dicitura che nessuna informazione è disponibile.
La procedura corretta per deindicizzare è inversa: la pagina deve restare scansionabile, con il meta tag robots noindex nell’HTML (o l’header X-Robots-Tag). Google la visita, legge l’istruzione, la rimuove dall’indice. Solo dopo la rimozione, se si vuole anche risparmiare scansione, si può aggiungere il Disallow.
La combinazione peggiore è Disallow più noindex insieme fin dall’inizio: il blocco di scansione rende invisibile l’istruzione di deindicizzazione, e il problema si cristallizza. Il rapporto Indicizzazione di Search Console segnala esattamente questo stato con la voce “Indicizzata ma bloccata da robots.txt”: il workflow per intercettarlo ogni settimana è nella mia guida su Google Search Console. Se questo errore riguarda ciò che Google vede, il prossimo riguarda ciò che le AI possono citare.
Errore 3: bloccare i crawler AI senza una strategia
Dal 2023 in poi molti siti hanno aggiunto blocchi generalizzati ai crawler AI (GPTBot di OpenAI, ClaudeBot di Anthropic, PerplexityBot, Google-Extended per l’addestramento di Gemini), spesso copiando liste da articoli allarmistici, senza una decisione consapevole. Nel 2026 questa scelta ha un costo misurabile: un sito invisibile ai crawler AI è un sito che non può essere citato nelle risposte di ChatGPT e Perplexity, cioè fuori da un canale dove i clienti fanno domande e ricevono nomi.
La decisione corretta dipende dal modello di business. Un editore che vive di contenuti può avere ragioni per bloccare l’addestramento; un’azienda che vende prodotti o servizi ha l’interesse opposto, perché la citazione nelle risposte AI è visibilità commerciale gratuita. Per i miei clienti la regola di partenza è: crawler AI aperti, perché la presenza nelle risposte generative è un obiettivo, non un rischio. È il ragionamento che sviluppo nella guida alla visibilità su ChatGPT per i business italiani.
Una distinzione tecnica da conoscere: Google-Extended controlla solo l’uso dei contenuti per l’addestramento di Gemini, non la presenza nelle AI Overview, che dipende dalla normale scansione di Googlebot. Bloccare Google-Extended non ti toglie dalle AI Overview; bloccare Googlebot sì, insieme a tutto il resto. La consapevolezza è tutto; la dimenticanza, invece, è il territorio del quarto errore.
Errore 4: dimenticare il file dopo staging e migrazioni
Il “Disallow: /” (blocco totale) è corretto su un ambiente di staging e catastrofico in produzione. L’errore classico delle migrazioni è proprio questo: il sito nuovo va online con il robots.txt dello staging, nessuno se ne accorge, e il traffico organico inizia a scendere nel giro di giorni. In WordPress l’equivalente è la spunta “Scoraggia i motori di ricerca” attivata durante lo sviluppo e mai rimossa.
Il sintomo è riconoscibile: calo di impressioni in Search Console su tutto il sito insieme, e nel rapporto Indicizzazione l’esplosione della voce “Bloccata da robots.txt”. Il controllo del file è la prima voce della mia checklist post-migrazione, prima ancora dei redirect.
La prevenzione costa poco: il robots.txt va trattato come codice, incluso nei controlli di ogni rilascio, e il primo crawl dopo la messa in produzione va fatto entro il giorno stesso. Anche con il file giusto al posto giusto, però, resta l’ultima famiglia di errori: quelli scritti dentro le regole.
Errore 5: sintassi sbagliata e regole in conflitto
Il robots.txt perdona poco: ogni direttiva vale per il blocco User-agent che la precede, i percorsi distinguono maiuscole e minuscole, e le regole si applicano per prefisso. Gli errori di sintassi che incontro più spesso sono riassunti qui:
| Errore di sintassi | Effetto reale | Forma corretta |
|---|---|---|
| Direttive senza User-agent | Regole ignorate | Ogni blocco inizia con User-agent |
| Disallow: /cartella (senza slash finale) | Blocca anche /cartella-altro.html | Disallow: /cartella/ |
| Maiuscole sbagliate nel percorso | La regola non corrisponde a nulla | Rispettare il case reale degli URL |
| Wildcard usate a caso (* e $) | Blocchi più ampi o più stretti del voluto | Testare ogni pattern prima di pubblicare |
| Sitemap assente | Occasione persa di segnalazione | Riga Sitemap: con URL assoluto |
Il conflitto tipico è tra regole Allow e Disallow sovrapposte: la precedenza va alla regola più specifica (quella con il percorso più lungo), un comportamento che sorprende chi si aspetta l’ordine di lettura. Il test prima della pubblicazione non è opzionale: lo strumento di verifica del robots.txt in Search Console e un crawl con Screaming Frog mostrano l’effetto reale delle regole su URL veri.
Con gli errori mappati, la chiusura naturale è il modello positivo: come deve essere il file per un sito WordPress standard nel 2026.
Il robots.txt corretto per un sito WordPress
Per la maggior parte dei siti WordPress orientati alla visibilità (su Google e nelle AI), il file corretto è corto. Questo è il modello di partenza che uso:
`User-agent: *`
`Disallow: /wp-admin/`
`Allow: /wp-admin/admin-ajax.php`
`Disallow: /?s=`
`Disallow: /search/`
`Sitemap: https://www.tuosito.it/sitemap_index.xml`
La logica riga per riga: l’area di amministrazione è esclusa perché non ha valore di ricerca, con l’eccezione di admin-ajax.php che serve a funzioni del front-end; le pagine di ricerca interna sono escluse perché generano URL infiniti a contenuto duplicato; la sitemap è dichiarata con URL assoluto. Nessun blocco su CSS, JavaScript, immagini o cartelle dei contenuti; nessun blocco sui crawler AI, in coerenza con l’obiettivo di essere citati.
Il principio finale, che vale più di ogni modello: nel robots.txt meno righe ci sono, meno cose possono rompersi. Ogni Disallow deve avere una ragione che sai spiegare; se la ragione non c’è, la riga non deve esserci. È lo stesso impianto di essenzialità che applico a tutta la SEO tecnica del metodo SEOSESE: ogni istruzione al motore deve essere vera, necessaria e verificata.
Domande frequenti sul robots.txt
Il robots.txt serve a rimuovere una pagina da Google?
No, il robots.txt gestisce la scansione, non l’indicizzazione: una pagina bloccata può restare nell’indice se riceve link esterni. Per deindicizzare serve il meta tag noindex su una pagina scansionabile: Google deve poter visitare la pagina per leggere l’istruzione di rimozione.
Devo bloccare GPTBot e gli altri crawler AI?
Dipende dalla strategia: un business che vende prodotti o servizi ha interesse a lasciare i crawler AI aperti, perché la citazione nelle risposte di ChatGPT e Perplexity è un canale di visibilità commerciale. Il blocco ha senso solo per chi vive della vendita diretta dei propri contenuti e lo decide consapevolmente.
Bloccare Google-Extended mi esclude dalle AI Overview?
No: Google-Extended controlla l’uso dei contenuti per l’addestramento dei modelli Gemini, mentre la presenza nelle AI Overview dipende dalla normale scansione di Googlebot. Per uscire dalle AI Overview bisognerebbe bloccare Googlebot, che significa uscire da tutta la ricerca Google.
Un sito senza robots.txt è un problema?
No, in assenza del file i crawler scansionano tutto il sito, e per un sito piccolo con URL puliti questa è una configurazione legittima. Il file diventa utile quando c’è qualcosa di preciso da escludere (ricerca interna, aree tecniche) o da dichiarare (la sitemap); il file vuoto o assente è meglio di un file sbagliato.
Come verifico se il mio robots.txt sta bloccando qualcosa di importante?
Tre controlli: il rapporto Indicizzazione di Google Search Console (voci “Bloccata da robots.txt” e “Indicizzata ma bloccata”), lo strumento Controllo URL sulla singola pagina per vedere le risorse bloccate, e un crawl completo con un tool come Screaming Frog che applica le regole del file e mostra cosa resta fuori.
Ogni quanto va controllato il robots.txt?
A ogni rilascio che tocca il sito (tema, migrazione, ristrutturazione) e almeno a ogni audit periodico: il file cambia raramente da solo, ma le migrazioni e i plugin possono sovrascriverlo. Il controllo dopo una messa in produzione va fatto il giorno stesso, perché un blocco totale dimenticato brucia visibilità in pochi giorni.
Se vuoi sapere se il tuo robots.txt, e la tua SEO tecnica in generale, stanno aiutando o sabotando la visibilità del tuo sito su Google e nelle risposte AI, il punto di partenza è una verifica reale. Prenota l’Audit di Visibilità, scrivimi su WhatsApp o invia una mail a info@seosese.com.
