Il robots.txt di WordPress nel 2026: cosa metterci davvero

Un buon robots.txt per WordPress è lungo circa cinque righe. Blocca /wp-admin/, consenti admin-ajax.php, indica ai crawler la sitemap e fermati lì: le liste di blocco da 40 righe che si trovano nei forum per lo più rompono il rendering o non fanno assolutamente nulla. Il file completo:

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

Sitemap: https://example.com/wp-sitemap.xml

Sostituisci il dominio e, se usi un plugin SEO che gestisce le sitemap al posto del core, fai puntare la riga Sitemap all’indice di quel plugin. Tutto qui. Se il tuo file è più lungo, le righe in eccesso probabilmente ti stanno costando qualcosa.

WordPress ne genera già uno, finché non crei un file reale

WordPress fornisce un robots.txt virtuale. Quando arriva una richiesta a /robots.txt e nella root del sito non esiste alcun file, WordPress la intercetta e stampa una risposta in memoria. Sul disco non viene scritto nulla. L’output predefinito è il blocco per wp-admin visto sopra, più una riga Sitemap: per wp-sitemap.xml che il core emette dalla versione 5.5.

Due cose modificano quell’output. Se in Impostazioni → Lettura → Scoraggia i motori di ricerca dall’indicizzare questo sito la casella è spuntata, WordPress sostituisce tutto con Disallow: /, che blocca ogni cosa. Quella casella è la causa più comune in assoluto della scomparsa di un sito dai motori dopo il lancio. Seconda cosa: plugin e temi possono modificare l’output virtuale tramite il filtro robots_txt, ed è così che i plugin SEO inseriscono le proprie righe di sitemap e le proprie regole.

E ora la parte che fa perdere pomeriggi interi. Un file robots.txt fisico nella root del sito scavalca silenziosamente tutto il resto. Il web server trova un file reale sul disco, lo serve, e WordPress non viene nemmeno caricato. Il generatore virtuale non entra in funzione. Il filtro robots_txt non scatta. L’editor del robots.txt del tuo plugin SEO può continuare a mostrarti una bella interfaccia con le regole giuste dentro, e niente di tutto ciò arriva a un crawler.

Dove stanno le regole	Modificabili dalla bacheca WordPress	Prevalgono su una richiesta reale
Virtuali (nessun file sul disco)	Sì, tramite il filtro robots_txt o un plugin	Solo se non esiste alcun file fisico
File fisico nella root del sito	Solo se il plugin scrive sul disco	Sempre

Quindi, prima di indagare qualunque cosa: apri https://tuosito.com/robots.txt nel browser, poi collegati via SFTP o dal file manager del tuo hosting e verifica se un robots.txt reale si trova accanto a wp-config.php e .htaccess. Se c’è, quello è il tuo robots.txt. Modificalo lì oppure eliminalo e lascia fare a WordPress, ma scegli una delle due strade. Tenere entrambe è il modo tipico in cui un sito finisce con un URL di sitemap obsoleto che nessuno riesce a trovare.

Perché /wp-admin/ è bloccato ma admin-ajax.php è consentito

/wp-admin/ contiene la bacheca. Quegli URL sono inutili nei risultati di ricerca e scansionarli consuma crawl budget su pagine che rimandano a una schermata di login. Bloccare la cartella non è in discussione.

admin-ajax.php sta dentro quella cartella ma non è una pagina di amministrazione. È l’endpoint che plugin e temi usano per gestire le richieste AJAX del front-end: pulsanti “carica altro”, griglie di prodotti filtrate, calcolatori, moduli. Se un crawler non riesce a raggiungerlo, non vede i contenuti caricati da quelle funzioni, e Google visualizza la tua pagina come la vedrebbe un visitatore con la funzione rotta.

Se Google abbia davvero bisogno di scaricare admin-ajax.php sul tuo sito specifico dipende da quanto il tuo front-end lo usa. Risposta onesta: su molti siti moderni non cambia nulla, perché il tema usa la REST API su /wp-json/. La riga Allow è una polizza assicurativa a costo zero contro un problema reale, non un fattore di posizionamento. Tienila perché non costa niente.

Non bloccare /wp-content/ o /wp-includes/

Questo è il peggior consiglio sul robots.txt ancora in circolazione, e risale a un’epoca in cui Google non visualizzava le pagine.

/wp-content/ contiene temi, plugin e caricamenti: i fogli di stile, gli script e le immagini che fanno sembrare le tue pagine delle pagine. /wp-includes/ contiene il JavaScript del core da cui dipendono i plugin. Google visualizza le pagine con un browser headless prima di valutarle. Blocca quelle cartelle e il renderer riceve una pagina senza CSS e senza immagini. Quello che Google valuta è un muro di testo senza stile con il layout a pezzi, e questo incide su come comprende i tuoi contenuti e su come giudica l’usabilità da mobile.

Se hai ereditato un file con queste righe, cancellale:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Il danno puoi verificarlo di persona con lo strumento Controllo URL di Google Search Console. Esegui un test in tempo reale su una pagina qualsiasi, guarda lo screenshot del rendering e controlla l’elenco delle risorse della pagina per vedere quali risultano bloccate. Se il CSS compare come bloccato, la causa è quella.

La direttiva Sitemap

Una riga, URL assoluto, e può stare in qualsiasi punto del file: non è legata a un gruppo User-agent.

Sitemap: https://example.com/wp-sitemap.xml

Usa l’URL che si apre davvero. Il core di WordPress serve wp-sitemap.xml. La maggior parte dei plugin SEO disattiva le sitemap del core e serve il proprio indice a un percorso diverso, di solito sitemap_index.xml. Carica il tuo URL nel browser prima di scriverlo: una riga Sitemap che punta a un 404 è peggio di nessuna riga, perché in un audit sembra corretta.

Elencare più sitemap va bene, una per riga. Inviare le sitemap in Search Console resta comunque utile a parte; la direttiva nel robots.txt è il modo in cui la trovano i crawler che non vedranno mai il tuo account Search Console.

Il robots.txt non è un noindex e non è sicurezza

Questi due fraintendimenti causano quasi tutti i danni legati al robots.txt.

Bloccare un URL non lo rimuove da Google. Il robots.txt governa la scansione. Se un altro sito collega un URL bloccato, Google può indicizzare l’URL in sé: ottieni un risultato con il solo indirizzo e la nota che non sono disponibili informazioni. E c’è una trappola peggiore: se una pagina ha già un meta tag noindex e poi la blocchi nel robots.txt, Google non può scansionarla, non può vedere il noindex, e la pagina può restare indicizzata a tempo indeterminato. Per rimuovere una pagina, consenti la scansione e servi un meta tag robots noindex nell’head della pagina oppure un’intestazione HTTP X-Robots-Tag. Google ha smesso di supportare le direttive noindex dentro il robots.txt nel 2019.

Bloccare un percorso non lo protegge. Il tuo robots.txt è pubblico per definizione. Elencare /file-clienti-riservati/ dice a ogni visitatore e a ogni scanner esattamente dove guardare, e il rispetto delle regole è volontario: Google le onora, i bot ostili no. Tutto ciò che va protetto ha bisogno di autenticazione, di una restrizione per IP o di regole a livello di server in .htaccess, non di una riga in un file di testo che segnala il bersaglio.

Regole che vale la pena aggiungere e regole da lasciar perdere

Due aggiunte sono davvero utili su molti siti. Bloccare il percorso dei risultati di ricerca impedisce ai crawler di generare URL a bassissimo valore dalla ricerca interna. Bloccare il percorso del carrello o del checkout su WooCommerce tiene fuori dalla scansione gli URL con parametri di sessione.

Disallow: /?s=
Disallow: /search/

Da evitare:

• Crawl-delay — Google la ignora completamente. Se hai un vero problema di carico sul server, usa i controlli della frequenza di scansione in Search Console.
• Bloccare /feed/ o /trackback/ — sono URL innocui, e i feed sono utili.
• Lunghi elenchi di nomi di singoli bot — la maggior parte dei bot che si cerca di bloccare non si identifica onestamente.
• Bloccare /wp-json/ — potrebbe essere ciò che il tuo tema usa per mostrare i contenuti.

Costruisci il file con il generatore di robots.txt per WordPress, che produce la versione minima corretta e ti permette di aggiungere le regole per ricerca ed e-commerce senza scrivere la sintassi a mano.

Dopo averlo modificato

Carica direttamente https://tuosito.com/robots.txt e verifica che i byte serviti siano quelli che ti aspetti, non quelli che ti mostra l’editor del plugin. Poi esegui un controllo URL in tempo reale in Search Console su una pagina normale e assicurati che nessuna risorsa CSS o JavaScript risulti bloccata. Google memorizza il robots.txt nella cache per circa un giorno, quindi una correzione non ha effetto immediato, e nemmeno un errore. Proprio questo ritardo è il motivo per verificare con attenzione invece di provare in produzione e aspettare.