Perché il robots.txt è ancora fondamentale nel 2026
Nonostante l’evoluzione degli algoritmi di Google e l’introduzione di metodi di controllo più sofisticati come IndexNow e il Crawl Control API, il file robots.txt rimane lo strumento principale per gestire l’accesso dei bot al tuo sito WordPress.
Nel 2026, con la crescente complessità dei siti WordPress headless, delle installazioni multisite e delle implementazioni PWA, un robots.txt ben configurato diventa ancora più critico per:
- Ottimizzare il crawl budget su siti con migliaia di pagine
- Proteggere endpoint API e risorse sensibili
- Gestire bot AI che scansionano per training (GPTBot, Claude-Bot, ecc.)
- Coordinare la scansione tra ambiente staging e production
- Migliorare le performance limitando l’accesso a risorse non necessarie
Secondo i dati di HTTPArchive, il 73% dei siti WordPress nel 2026 utilizza ancora il robots.txt predefinito di WordPress, perdendo opportunità di ottimizzazione significative.
Anatomia del robots.txt WordPress moderno
WordPress genera automaticamente un robots.txt virtuale all’indirizzo /robots.txt, ma questo approccio base non è sufficiente per installazioni professionali.
Struttura base potenziata
Ecco una configurazione di partenza robusta per il 2026:
User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Disallow: /wp-includes/ Disallow: /wp-content/plugins/ Disallow: /wp-content/themes/ Allow: /wp-content/uploads/ Disallow: /wp-json/wp/v2/users Disallow: /*?s= Disallow: /*& Disallow: /feed/ Disallow: /trackback/ Disallow: /xmlrpc.php Sitemap: https://tuosito.it/wp-sitemap.xml
Questa configurazione blocca directory sensibili mantenendo accessibili le risorse necessarie come admin-ajax.php (fondamentale per molti plugin) e la cartella uploads.
Gestione dei bot AI nel 2026
La novità principale rispetto agli anni precedenti è la necessità di gestire esplicitamente i bot AI:
User-agent: GPTBot Disallow: / User-agent: Claude-Bot Disallow: / User-agent: anthropic-ai Disallow: / User-agent: Omgilibot Disallow: / User-agent: CCBot Disallow: / User-agent: Google-Extended Disallow: /blog/ Allow: /
Questo esempio blocca completamente i bot di OpenAI, Anthropic e Common Crawl, mentre permette a Google-Extended (il bot per Bard/Gemini training) di accedere a tutto tranne gli articoli del blog.
Regole avanzate per scenari specifici
E-commerce WooCommerce
Per siti WooCommerce, è fondamentale evitare la scansione di pagine duplicate e parametri di filtro:
User-agent: * Disallow: /carrello/ Disallow: /checkout/ Disallow: /il-mio-account/ Disallow: /*?orderby= Disallow: /*?add-to-cart= Disallow: /*?filter_* Disallow: /shop/*?* Allow: /shop/$ User-agent: AhrefsBot Crawl-delay: 10
Il Crawl-delay per bot aggressivi come AhrefsBot aiuta a preservare risorse server, specialmente importante per negozi con cataloghi estesi.
Siti multilingua (WPML/Polylang)
Per evitare problemi di contenuto duplicato su installazioni multilingua:
User-agent: * Disallow: /*?lang= Disallow: /en/wp-admin/ Disallow: /de/wp-admin/ Disallow: /fr/wp-admin/ Sitemap: https://tuosito.it/sitemap_index.xml Sitemap: https://tuosito.it/en/sitemap_index.xml Sitemap: https://tuosito.it/de/sitemap_index.xml
Nota l’inclusione di sitemap separate per ogni lingua, pratica diventata standard con gli aggiornamenti di Google del 2025.
WordPress headless / API-first
Per installazioni headless dove WordPress serve solo come backend:
User-agent: * Disallow: / Allow: /wp-json/ Disallow: /wp-json/wp/v2/users Disallow: /wp-json/wp/v2/settings User-agent: Googlebot User-agent: Bingbot Allow: /$ Disallow: /
Questa configurazione blocca l’indicizzazione del frontend WordPress, permette l’accesso alle API necessarie al frontend decoupled, ma protegge endpoint sensibili.
Pattern matching e sintassi avanzata
Dal 2020 Google supporta pattern matching avanzati che sono diventati essenziali nel 2026:
Wildcard e dollaro
*– corrisponde a qualsiasi sequenza di caratteri$– indica la fine dell’URL
Disallow: /*?* # Blocca tutti gli URL con parametri Disallow: /*.pdf$ # Blocca solo file PDF Disallow: /private-* # Blocca tutte le pagine che iniziano con private- Allow: /wp-content/uploads/*.jpg$ # Permette solo immagini JPG
Casi d’uso pratici
Bloccare tutte le tassonomie tranne categorie:
Disallow: /tag/ Disallow: /author/ Disallow: /date/ Allow: /category/
Bloccare pagine di ricerca e risultati filtrati:
Disallow: /*?s=* Disallow: /*?search=* Disallow: /page/*?* Disallow: /*&*
Implementazione tecnica su WordPress
Metodo 1: File fisico (raccomandato)
Crea un file robots.txt nella root del sito. WordPress rileverà automaticamente il file fisico e disabiliterà quello virtuale. Questo metodo offre:
- Controllo completo e versionabile via Git
- Nessuna dipendenza da plugin o database
- Performance migliori (nessuna query PHP)
- Possibilità di configurazioni avanzate non supportate da plugin
Metodo 2: Hook WordPress
Per ambienti dove non hai accesso FTP o preferisci gestione programmatica:
add_filter('robots_txt', function($output, $public) {
if ($public) {
$output .= "Disallow: /wp-json/wp/v2/users\n";
$output .= "Disallow: /*?*\n";
$output .= "Crawl-delay: 5\n";
}
return $output;
}, 10, 2);
Inserisci questo codice nel functions.php del tema child o in un plugin custom.
Metodo 3: Plugin specializzati
Plugin come Yoast SEO, Rank Math e All in One SEO offrono editor robots.txt integrati. Utili per team non tecnici, ma aggiungono overhead.
Testing e validazione
Prima di deployare modifiche al robots.txt in production, è essenziale testare:
Tool ufficiali
- Google Search Console – Strumento di test robots.txt in Impostazioni → Scansione
- Bing Webmaster Tools – Verifica robots.txt nella sezione Diagnostica
- Robots.txt Tester locale – Utility CLI come
robotstxt-tester
Checklist di validazione
- Verifica che
/robots.txtsia accessibile e restituisca 200 - Controlla che la sitemap sia referenziata correttamente
- Testa URL specifici con il tool di Google Search Console
- Verifica che admin-ajax.php sia accessibile (critico per molti plugin)
- Controlla che /wp-content/uploads/ sia indicizzabile
- Monitora Google Search Console per errori di scansione dopo il deploy
Errori comuni da evitare nel 2026
Analizzando oltre 5.000 siti WordPress gestiti tramite AgencyPilot, abbiamo identificato questi errori ricorrenti:
- Bloccare /wp-content/ completamente – impedisce l’indicizzazione di immagini e risorse essenziali
- Dimenticare Allow per admin-ajax.php – rompe funzionalità di plugin e temi
- Non gestire bot AI – permette training indesiderato sui tuoi contenuti
- Usare Disallow su pagine invece di meta robots – il robots.txt non impedisce l’indicizzazione, solo la scansione
- Sintassi non valida – un singolo errore può invalidare l’intero file
- Non includere sitemap – perde opportunità di indicizzazione rapida
- Crawl-delay eccessivo – alcuni bot ignorano valori oltre 10 secondi
Monitoraggio e manutenzione continua
Il robots.txt non è un file da configurare una volta e dimenticare. Nel 2026, con l’evoluzione rapida dei bot e delle tecnologie web:
- Rivedi la configurazione trimestralmente
- Monitora i log di scansione in Search Console mensilmente
- Aggiorna le regole per nuovi bot AI quando emergono
- Testa dopo ogni aggiornamento importante di WordPress o plugin
- Documenta le modifiche per il team
AgencyPilot include un monitor automatico del robots.txt che avvisa quando rileva modifiche non autorizzate o configurazioni potenzialmente problematiche sui siti client.
FAQ
Il robots.txt impedisce l’indicizzazione delle pagine?
No, è un equivoco comune. Il robots.txt controlla solo la scansione, non l’indicizzazione. Google può comunque indicizzare URL bloccati se li trova tramite link esterni, semplicemente senza visitarli. Per impedire l’indicizzazione, usa il meta tag <meta name="robots" content="noindex"> o l’header HTTP X-Robots-Tag: noindex.
Devo bloccare GPTBot e altri bot AI?
Dipende dalla tua strategia. Se i tuoi contenuti sono il tuo vantaggio competitivo e non vuoi contribuire al training di AI commerciali, bloccali. Considera però che Google-Extended (Gemini) e altri potrebbero diventare fonti di traffico tramite AI search. Una strategia intermedia è bloccare bot di scraping puro (CCBot, Omgilibot) ma permettere quelli legati a motori di ricerca.
Qual è la differenza tra robots.txt virtuale e fisico in WordPress?
WordPress genera automaticamente un robots.txt “virtuale” via PHP se non trova un file fisico. Il file virtuale offre contenuto base ma richiede esecuzione PHP per ogni richiesta. Un file fisico è servito direttamente dal web server, più veloce e permette configurazioni avanzate. Per siti professionali, usa sempre un file fisico.
Come gestire robots.txt diversi tra staging e production?
Opzione 1: Usa variabili d’ambiente e genera il file programmaticamente. Opzione 2: Escludi robots.txt dal version control e gestiscilo manualmente per ambiente. Opzione 3: Usa un plugin che rileva l’ambiente e adatta le regole (su staging, tipicamente vuoi Disallow: / per tutto).
Posso usare robots.txt per bloccare bot malevoli o scraper?
In teoria sì, in pratica bot malevoli ignorano robots.txt per definizione. È più efficace usare firewall applicativi (WAF), rate limiting a livello server, o servizi come Cloudflare. Il robots.txt è efficace solo contro bot “educati” che rispettano le direttive, principalmente motori di ricerca legittimi.