Il file robots.txt dice ai crawler quali URL o aree di un sito possono scansionare e quali dovrebbero evitare. La distinzione importante è proprio questa: gestisce il crawling, non è uno strumento per rendere privata una pagina e non è il metodo corretto per eliminarla dall’indice di Google.
Google lo chiarisce nella propria documentazione su robots.txt: una pagina bloccata alla scansione può comunque comparire nei risultati se Google ne conosce l’URL attraverso link o altre fonti. Per impedire l’indicizzazione servono strumenti diversi, come noindex; per proteggere informazioni riservate servono invece autenticazione o altri controlli di accesso.
Questo dettaglio cambia completamente il modo in cui conviene configurare il file. Un robots.txt più complesso non è necessariamente migliore: ogni regola dovrebbe risolvere un problema preciso e avere un effetto che hai verificato.
Su WordPress, inoltre, potresti avere già un robots.txt generato dal CMS senza aver mai creato manualmente un file. Vediamo quindi come funziona il meccanismo, come gestirlo su WordPress, quali configurazioni hanno senso e quali errori possono creare problemi reali di crawling e visibilità.
Cos’è robots.txt e cosa controlla davvero
robots.txt è un file di testo basato sul Robots Exclusion Protocol (REP). Quando un crawler conforme arriva su un sito, può recuperare il file e usare le regole che contiene per stabilire quali percorsi gli è consentito scansionare.
L’indirizzo, nel caso più comune, è:
https://www.example.com/robots.txt
Le istruzioni possono valere per tutti i crawler oppure per user-agent specifici. In pratica stai comunicando qualcosa del tipo:
“Questo crawler può accedere a queste aree, ma non a queste altre.”
Il punto critico è capire cosa succede dopo. Impedire a Googlebot di recuperare una pagina significa impedirgli di leggerne direttamente il contenuto. Non significa ordinare a Google di cancellarne l’URL dal proprio indice. Google documenta esplicitamente che un URL bloccato può comunque essere indicizzato senza contenuto o snippet se viene scoperto in altri modi.
Crawling, indicizzazione e sicurezza: perché non sono la stessa cosa
Tre problemi diversi richiedono tre famiglie di strumenti diverse:
| Obiettivo | Strumento principale | Cosa fa |
|---|---|---|
| Limitare la scansione di URL o percorsi | robots.txt | Indica ai crawler conformi cosa non scansionare |
| Evitare che una risorsa compaia nei risultati | noindex / X-Robots-Tag | Comunica che la risorsa non deve essere indicizzata |
| Rendere una risorsa realmente privata | autenticazione, password, controlli server | Impedisce l’accesso a chi non è autorizzato |
È una distinzione semplice, ma evita molti errori.
Immagina una pagina che vuoi eliminare dai risultati di ricerca. Se inserisci:
User-agent: * Disallow: /pagina-da-rimuovere/
Googlebot non può più scansionarla. Se però Google conosce già quell’URL, il blocco non garantisce la sua scomparsa dalla ricerca.
Se invece vuoi usare noindex, Google deve poter accedere alla pagina per leggere la direttiva. La documentazione Google sul noindex specifica infatti che, se una risorsa è contemporaneamente bloccata da robots.txt, il crawler può non vedere la direttiva noindex.
Per approfondire il passaggio successivo al crawling puoi leggere la guida Creativemotions su come funziona l’indicizzazione di Google.
Quando usare robots.txt e quando servono noindex, X-Robots-Tag o password
Usa robots.txt quando il problema è la scansione.
Può avere senso, per esempio, per impedire a un crawler di attraversare determinate famiglie di URL che non gli servono, purché tu abbia verificato che quelle risorse non debbano essere scansionate per altri motivi.
Usa invece noindex quando la pagina può essere pubblicamente accessibile ma non vuoi che compaia nell’indice.
Per una normale pagina HTML puoi usare il meta tag:
<meta name="robots" content="noindex">
Per risorse sulle quali il meta tag HTML non è disponibile, come alcuni PDF o altri file, può essere più appropriato un header HTTP:
X-Robots-Tag: noindex
Se invece il contenuto è realmente riservato — area di staging, documenti privati, pannelli interni, dati sensibili — robots.txt è lo strumento sbagliato. Il file è pubblico e i crawler non sono obbligati tecnicamente a rispettarlo. La protezione deve avvenire a livello di autenticazione, web server, applicazione o infrastruttura.
Come funziona robots.txt: sintassi, user-agent e regole
La sintassi di base è semplice. La parte più delicata non è scrivere una direttiva, ma capire quale gruppo verrà applicato e quale regola vincerà quando più istruzioni corrispondono allo stesso URL.
Google documenta come campi supportati user-agent, allow, disallow e sitemap; altre direttive che potresti incontrare online, come crawl-delay, non sono supportate dal parser robots.txt di Google.
User-agent, Disallow, Allow e Sitemap
Un esempio completo può essere:
User-agent: * Disallow: /area-tecnica/ Allow: /area-tecnica/manuale-pubblico.html Sitemap: https://www.example.com/sitemap.xml
Vediamo cosa significa.
User-agent identifica il crawler a cui si applicano le istruzioni.
User-agent: *
L’asterisco, in questo contesto, identifica tutti i crawler che non hanno un gruppo più specifico applicabile.
Disallow indica invece un percorso che il crawler non dovrebbe scansionare:
Disallow: /area-tecnica/
Allow può creare un’eccezione più specifica all’interno di un percorso bloccato:
Allow: /area-tecnica/manuale-pubblico.html
Infine:
Sitemap: https://www.example.com/sitemap.xml
indica la posizione di una sitemap. La URL deve essere assoluta, quindi deve comprendere protocollo e hostname. La presenza della sitemap nel robots.txt non obbliga Google a indicizzare le URL contenute nella sitemap: serve a comunicarne la posizione.
La specifica robots.txt interpretata da Google è la fonte da usare quando devi verificare sintassi, matching e comportamento effettivo di Googlebot.
Come funzionano le regole in conflitto, * e $
Supponiamo di avere:
User-agent: * Disallow: /documenti/ Allow: /documenti/pubblici/
e che Googlebot debba raggiungere:
/documenti/pubblici/guida.pdf
Non basta dire che Disallow viene prima o dopo Allow. Per Google conta la regola più specifica che corrisponde all’URL, determinata dalla lunghezza del percorso corrispondente. Quando due regole in conflitto hanno la stessa specificità, Google applica quella meno restrittiva.
Quindi l’ordine visivo delle direttive non è una strategia per far “vincere” quella che preferisci.
Google supporta inoltre due caratteri utili nel path matching:
*corrisponde a zero o più caratteri;$identifica la fine dell’URL.
Per esempio:
Disallow: /*.pdf$
corrisponde a un percorso che termina con .pdf, mentre una URL come:
/documento.pdf?download=1
non termina più con .pdf e quindi non corrisponde a quella stessa regola.
Anche i gruppi degli user-agent richiedono attenzione. Google cerca il gruppo con lo user-agent più specifico. Se esistono più gruppi per quello stesso user-agent specifico, le relative regole vengono combinate; il gruppo specifico non viene invece semplicemente sommato a quello globale *.
Questa è una delle ragioni per cui copiare un robots.txt molto articolato da un altro sito può produrre effetti inattesi.
Dove deve trovarsi robots.txt e a quali host, protocolli e sottodomini si applica
Il file deve essere pubblicato alla radice dell’host al quale deve applicarsi.
Questo è valido:
https://example.com/robots.txt
Questo non lo è come robots.txt dell’intero sito:
https://example.com/cartella/robots.txt
C’è poi una conseguenza meno intuitiva: le regole valgono per la combinazione di host, protocollo e porta sulla quale il file è disponibile. Un robots.txt presente su:
https://example.com/robots.txt
non governa automaticamente:
https://shop.example.com/
né la versione:
http://example.com/
Google documenta esplicitamente questo scope.
Se gestisci sottodomini distinti, ambienti su host differenti o configurazioni particolari, controlla quindi il robots.txt effettivamente servito da ciascun host invece di dare per scontato che esista una configurazione globale.
Il file deve inoltre essere testo semplice codificato UTF-8. Google applica un limite di 500 KiB e ignora ciò che si trova oltre quel limite. Per un normale sito WordPress arrivare a quelle dimensioni sarebbe comunque un forte segnale che la configurazione è diventata inutilmente complessa.
Robots.txt su WordPress: cosa genera WordPress e quando modificarlo
Su WordPress non è obbligatorio creare manualmente un file fisico.
Il core dispone della funzione do_robots(), utilizzata per generare l’output robots.txt. La configurazione di base comprende l’esclusione dell’area amministrativa e l’eccezione per admin-ajax.php.
Per un’installazione nella root, la parte fondamentale appare così:
User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php
Se WordPress è installato in un sottopercorso, il core tiene conto anche di quel path. Plugin, hook o altre componenti possono inoltre modificare l’output che vedi realmente.
Per questo il primo controllo non dovrebbe essere “come creo robots.txt?”, ma:
https://tuodominio.it/robots.txt
Aprilo nel browser e verifica che cosa viene effettivamente restituito dal tuo sito.
Il robots.txt virtuale predefinito di WordPress
L’approccio di WordPress è interessante perché evita alcune vecchie configurazioni eccessivamente aggressive.
La directory /wp-admin/ viene normalmente esclusa, mentre admin-ajax.php resta accessibile. Bloccare in massa altre directory WordPress semplicemente perché “sono tecniche” non è automaticamente una buona idea.
In particolare, non c’è una buona ragione generale per aggiungere regole come:
Disallow: /wp-content/
solo perché quella directory contiene file del tema o dei plugin. CSS, JavaScript, immagini e altre risorse possono servire ai motori per eseguire il rendering e comprendere correttamente la pagina. La stessa documentazione Google usa esempi nei quali CSS e JavaScript vengono resi accessibili proprio perché necessari al rendering.
Un’altra modifica importante del core WordPress risale alla versione 5.3: quando viene scoraggiata la visibilità ai motori, WordPress non genera più automaticamente Disallow: /, ma utilizza il layer robots meta. È una scelta tecnicamente coerente con la distinzione che abbiamo visto prima: controllare l’indicizzazione e controllare il crawling sono due problemi differenti.
File personalizzato e filtro robots_txt: cosa cambia
Puoi personalizzare l’output, ma prima devi sapere da dove arriva quello attuale.
A seconda della configurazione, ciò che trovi su /robots.txt può essere influenzato dal core, da un plugin SEO, da codice personalizzato o dalla configurazione del server.
WordPress espone anche il filtro robots_txt, quindi uno sviluppatore può modificare l’output senza dover trattare robots.txt come un file statico.
Per esempio, se utilizzi la sitemap nativa di WordPress e vuoi aggiungerla programmaticamente, un’implementazione può essere:
add_filter( 'robots_txt', function( $output, $public ) {
$output .= 'Sitemap: ' . home_url( '/wp-sitemap.xml' ) . "\n";
return $output;
}, 10, 2 );
Questo è soltanto un esempio: non copiarlo se il tuo sito usa una sitemap differente. Plugin SEO e configurazioni personalizzate possono usare URL diverse, come un sitemap index proprietario.
La regola pratica è semplice: prima individua la sitemap realmente pubblicata dal sito, poi inserisci quella URL se ha senso farlo.
Quando il robots.txt predefinito è già sufficiente
Per molti siti WordPress editoriali o aziendali, il punto di partenza migliore è una configurazione semplice.
Non aggiungerei regole soltanto per:
- avere un robots.txt “più SEO”;
- copiare quello di un concorrente;
- bloccare cartelle che sembrano tecniche;
- ridurre genericamente il crawl budget;
- impedire l’indicizzazione di pagine che dovrebbero invece ricevere
noindex.
Personalizzerei il file quando esiste un pattern di URL concreto da gestire, un crawler specifico da controllare o un problema di crawling verificato.
Più direttive inserisci, più aumenta anche il rischio di creare interazioni che devi ricordarti di controllare quando cambiano struttura, plugin o architettura del sito.
Esempi di robots.txt per i casi più comuni
Gli esempi sono utili solo se viene chiarito a quale problema rispondono. Un robots.txt corretto per un sito può essere completamente sbagliato per un altro.
Consentire tutto o bloccare una directory specifica
Una configurazione che non impone restrizioni può essere:
User-agent: * Disallow:
Per impedire invece la scansione di una directory pubblica che hai deciso consapevolmente di non far attraversare ai crawler:
User-agent: * Disallow: /archivio-tecnico/
La seconda configurazione non rende privata quella directory e non garantisce che eventuali URL già conosciuti scompaiano dall’indice.
Significa soltanto che i crawler conformi destinatari della regola non dovrebbero recuperare quei percorsi.
Consentire un file dentro una directory bloccata
Puoi creare un’eccezione:
User-agent: * Disallow: /archivio-tecnico/ Allow: /archivio-tecnico/documento-pubblico.pdf
Per Google, la regola Allow è più specifica rispetto al blocco della directory e consente il crawling di quella particolare risorsa.
Questo tipo di configurazione va però mantenuto nel tempo. Se cambiano URL o struttura del sito, una vecchia eccezione può diventare inutile o non corrispondere più alla risorsa prevista.
Inserire la sitemap senza trasformarla in una scorciatoia per l’indicizzazione
Puoi dichiarare una sitemap in questo modo:
User-agent: * Disallow: Sitemap: https://www.example.com/sitemap_index.xml
La direttiva Sitemap aiuta i crawler compatibili a individuare la sitemap, ma le due tecnologie svolgono funzioni differenti:
robots.txt → gestione dell’accesso alla scansione
sitemap → segnalazione degli URL che vuoi far conoscere al motore
Inserire una pagina nella sitemap non garantisce che venga indicizzata. Allo stesso modo, bloccarla nel robots.txt mentre continui a segnalarla nella sitemap crea segnali operativi poco coerenti: stai comunicando l’esistenza dell’URL ma impedendo al crawler di recuperarne il contenuto.
Parametri e risultati di ricerca interni: quando vale davvero la pena bloccarli
I parametri possono generare grandi quantità di URL differenti che mostrano contenuti molto simili: filtri, ordinamenti, ricerche interne, tracking applicativo o combinazioni di faccette.
In alcuni siti di grandi dimensioni può avere senso impedire la scansione di pattern chiaramente inutili. Ma qui bisogna evitare una scorciatoia pericolosa:
URL duplicata o poco utile ≠ URL da bloccare automaticamente con robots.txt.
Se Google deve accedere a una pagina per vedere un canonical o un noindex, impedirgli il crawling può essere controproducente.
Supponiamo che una ricerca interna produca sempre URL come:
/?s=parola
Una regola tecnicamente possibile sarebbe:
User-agent: * Disallow: /?s=
Ma funziona soltanto se quello è davvero il pattern delle URL che vuoi gestire. Con permalink, plugin, ecommerce o sistemi di filtro differenti il pattern può cambiare completamente.
Prima di bloccare parametri conviene quindi controllare URL reali, log del crawler e Search Console. Il robots.txt deve essere la conseguenza della diagnosi, non il punto da cui partire.
Gli errori di robots.txt che possono danneggiare crawling e visibilità
I problemi più seri nascono spesso da configurazioni formalmente valide ma utilizzate per lo scopo sbagliato.
Usare Disallow per cercare di deindicizzare una pagina
È probabilmente l’errore più comune.
Se vuoi rimuovere una pagina dall’indice, scrivere:
Disallow: /pagina/
non equivale a:
<meta name="robots" content="noindex">
Nel primo caso impedisci la scansione. Nel secondo chiedi al motore di non indicizzare la risorsa dopo che ha potuto leggerne la direttiva.
Anzi, combinare le due cose può impedire a Google di vedere il noindex. Google avverte esplicitamente che la pagina deve essere accessibile al crawler affinché la direttiva possa essere elaborata.
Se una URL già presente nei risultati deve essere rimossa in modo permanente, il percorso corretto dipende dal caso: noindex, autenticazione, risposta HTTP appropriata o rimozione della risorsa. Robots.txt da solo non risolve il problema.
Bloccare CSS, JavaScript o altre risorse necessarie al rendering
Un crawler moderno non legge necessariamente soltanto il testo HTML iniziale. Google può dover recuperare CSS, JavaScript e altre risorse per renderizzare e interpretare correttamente una pagina.
Bloccare indiscriminatamente directory tecniche può quindi impedire l’accesso a elementi utili.
Questo è particolarmente importante su WordPress, dove temi e plugin caricano normalmente risorse da directory che qualcuno potrebbe essere tentato di bloccare solo perché non contengono “pagine SEO”.
La domanda corretta non è:
Questa cartella contiene contenuti che voglio posizionare?
ma:
Google ha bisogno delle risorse contenute qui per capire o renderizzare le pagine che voglio rendere visibili?
Se la risposta può essere sì, il blocco va rivalutato.
Usare robots.txt per proteggere staging o contenuti privati
Un ambiente di staging non dovrebbe essere considerato sicuro perché contiene:
User-agent: * Disallow: /
Quella configurazione comunica a crawler conformi di non scansionarlo. Non impedisce a una persona, a un bot che ignora REP o a chi conosce l’URL di aprirlo.
Per staging e contenuti riservati usa un vero controllo di accesso: autenticazione HTTP, login applicativo, restrizioni di rete, firewall o altra soluzione adeguata all’infrastruttura.
È anche un modello mentale utile da ricordare:
robots.txt esprime una policy di crawling; non crea un confine di sicurezza.
Ottimizzare il crawl budget quando il sito non ne ha realmente bisogno
Il crawl budget esiste, ma viene spesso usato per giustificare configurazioni robots.txt molto più aggressive del necessario.
La guida corrente di Google al crawl budget è destinata principalmente a siti molto grandi, siti con contenuti che cambiano rapidamente o progetti con una quota elevata di URL “Discovered – currently not indexed”. Google aggiunge che, se il sito non ha molte pagine che cambiano velocemente e le nuove pagine vengono normalmente scansionate in tempi ragionevoli, mantenere aggiornata la sitemap e controllare il report di indicizzazione è generalmente sufficiente.
Quindi, su un normale sito aziendale o blog WordPress con poche centinaia o migliaia di URL, non partirei da decine di Disallow per “conservare crawl budget”.
Partirei prima da:
qualità dell’architettura → linking interno → sitemap → status HTTP → duplicazioni reali → prestazioni del server → pattern di crawling osservati.
Solo dopo chiederei se robots.txt può risolvere un problema specifico.
Come controllare robots.txt e risolvere gli errori
Una configurazione corretta sulla carta non basta. Devi verificare quale file riceve realmente il crawler e quale regola si applica alla URL che ti interessa.
Il primo controllo è banale ma indispensabile:
https://tuodominio.it/robots.txt
Aprilo e verifica che restituisca testo, che il contenuto sia quello previsto e che non esistano regole ereditate da vecchi plugin, ambienti di staging o configurazioni precedenti.
Il rapporto robots.txt di Google Search Console
Google Search Console dispone di un rapporto dedicato a robots.txt, utile per controllare il file conosciuto da Google e diagnosticare problemi di recupero.
Per una singola URL è altrettanto importante usare Ispezione URL e verificare il motivo concreto per cui Google riesce o non riesce a scansionarla.
Quando modifichi robots.txt, non limitarti quindi a vedere che il file “si apre nel browser”. Controlla almeno:
- che il server restituisca lo status HTTP previsto;
- che Google possa recuperarlo;
- che la regola corrisponda veramente al path che vuoi gestire;
- che non entri in conflitto con ciò che vuoi ottenere a livello di indicizzazione.
“Indicizzata ma bloccata da robots.txt”: cosa significa
Questo stato sembra contraddittorio soltanto se consideriamo crawling e indicizzazione come la stessa cosa.
Google può scoprire una URL attraverso link, sitemap o altre fonti e conoscerne quindi l’esistenza anche se robots.txt gli impedisce di recuperare il contenuto. Google conferma che, in queste condizioni, l’URL può comparire nei risultati senza una normale descrizione.
La soluzione dipende da ciò che vuoi ottenere.
Se la pagina deve essere indicizzata, devi rimuovere o correggere la regola che ne impedisce la scansione e poi verificare che non esistano altri ostacoli.
Se la pagina non deve comparire nei risultati, non basta lasciare il Disallow. Devi scegliere un meccanismo adatto all’obiettivo, come noindex per una pagina pubblicamente accessibile oppure una vera protezione se il contenuto deve essere privato.
Non correggere quindi l’avviso in modo meccanico. Prima decidi qual è lo stato corretto che quella URL dovrebbe avere.
Cosa succede se robots.txt restituisce redirect, 404 o errori 5xx
Lo status HTTP del file ha effetti molto diversi.
Secondo la documentazione Google corrente:
| Risposta di robots.txt | Comportamento di Google |
|---|---|
2xx | elabora normalmente il file |
3xx | segue almeno cinque redirect; se non ottiene il file, tratta poi il caso come file non disponibile secondo la specifica |
4xx, eccetto 429 | generalmente considera assenti le restrizioni di crawling |
5xx | inizialmente interrompe il crawling del sito e continua a riprovare il recupero del file |
Per gli errori 5xx, Google documenta un comportamento particolarmente prudente: durante le prime 12 ore interrompe il crawling mentre tenta di recuperare nuovamente robots.txt; successivamente può utilizzare per un periodo la versione valida precedentemente memorizzata.
Questa è una ragione concreta per cui la disponibilità di robots.txt è più importante di quanto sembri. Un errore server sul file non equivale a non aver creato il file.
Al contrario, se non vuoi imporre alcuna restrizione, un robots.txt semplice e valido è molto più prevedibile di una configurazione complessa che occasionalmente restituisce errori.
Cache del file e tempi di aggiornamento
Le modifiche non vengono necessariamente recepite all’istante.
Google dichiara di memorizzare generalmente robots.txt in cache fino a circa 24 ore, con la possibilità di mantenerlo più a lungo quando non riesce ad aggiornare la copia, per esempio a causa di timeout o errori 5xx.
Se hai appena corretto una regola, quindi, non concludere dopo pochi minuti che la modifica non funziona.
Verifica:
- il file live;
- lo status HTTP;
- la versione vista dagli strumenti di Google;
- il comportamento della URL interessata dopo che il crawler ha avuto il tempo di aggiornare la configurazione.
Robots.txt e crawler AI nel 2026
Il principio di robots.txt non riguarda soltanto Googlebot. Sempre più servizi pubblicano user-agent specifici che permettono ai webmaster di esprimere preferenze sul crawling.
La parte importante è non mettere tutti i crawler AI nella stessa categoria, perché possono svolgere funzioni differenti.
Crawler per la ricerca e crawler per il training: perché vanno distinti
Un esempio concreto è OpenAI.
La documentazione ufficiale sui crawler OpenAI distingue attualmente OAI-SearchBot e GPTBot. Le preferenze sono indipendenti: OAI-SearchBot è associato alle funzionalità di ricerca di ChatGPT, mentre GPTBot riguarda il crawling di contenuti che possono essere utilizzati per l’addestramento dei modelli generativi.
Questo significa che una configurazione può, per esempio, differenziare i due:
User-agent: OAI-SearchBot Allow: / User-agent: GPTBot Disallow: /
Non è una configurazione che consiglio automaticamente: serve soltanto a mostrare che “crawler AI” non identifica una singola finalità.
OpenAI specifica inoltre che le modifiche alle preferenze di Search possono richiedere circa 24 ore per essere recepite dai propri sistemi.
Se vuoi approfondire la differenza tra una policy di crawling e file pensati per offrire una mappa informativa ai sistemi AI, puoi leggere anche la guida Creativemotions su llms.txt.
Cosa può controllare robots.txt e cosa richiede WAF o controlli server-side
Anche con i crawler AI resta valida la stessa distinzione vista per Googlebot.
Robots.txt funziona quando il crawler sceglie di rispettare quella policy.
Non è il livello giusto per:
- autenticare un visitatore;
- impedire tecnicamente l’accesso a una risorsa;
- proteggere informazioni riservate;
- applicare rate limiting;
- bloccare traffico malevolo.
Queste funzioni appartengono al web server, al CDN, al WAF, all’applicazione o ad altri controlli infrastrutturali.
Vale anche il ragionamento inverso: se vuoi permettere a un crawler legittimo di accedere al sito, una regola Allow nel robots.txt non serve a nulla se il firewall lo blocca a livello di rete. Nel caso di OAI-SearchBot, per esempio, OpenAI pubblica anche gli intervalli IP utilizzati e raccomanda di consentirne le richieste quando l’obiettivo è rendere il sito disponibile alle proprie funzionalità di ricerca.
Quindi la configurazione corretta va letta su due livelli distinti:
policy del crawler → robots.txt
controllo tecnico dell’accesso → server/CDN/WAF/applicazione
Confondere i due livelli porta allo stesso errore di fondo che abbiamo visto parlando di staging e contenuti privati.
Conclusione
Un buon robots.txt non è quello con più direttive: è quello che risolve un problema di crawling preciso senza ostacolare ciò che deve rimanere accessibile.
Su molti siti WordPress la configurazione di base è già sufficiente. Prima di aggiungere regole conviene chiedersi quale risultato stai cercando:
se vuoi controllare la scansione → valuta robots.txt;
se vuoi impedire l’indicizzazione → usa il controllo di indicizzazione appropriato;
se vuoi proteggere un contenuto → applica un vero controllo di accesso.
La verifica finale va sempre fatta sul comportamento reale del sito, non sullo snippet copiato da una guida. Apri il file effettivamente pubblicato, controlla Search Console e prova le URL che contano.
Se trovi segnali contraddittori tra robots.txt, noindex, canonical, sitemap e stato di indicizzazione, il problema non è più “scrivere il file giusto”: diventa una diagnosi di SEO tecnica. In quel caso un SEO audit può aiutare a individuare la causa senza correggere un singolo sintomo alla volta.