Percorsi sensibili nel robots.txt

Come funziona questo controllo

Scanaris scarica il tuo /robots.txt e verifica prima che sia un robots vero: risponde 200, non è HTML e contiene almeno una direttiva (User-agent, Disallow, Allow o Sitemap). Poi scorre ogni riga Disallow: e guarda se il percorso contiene uno di questi indicatori: wp-admin, phpmyadmin, /admin, backup, .git, .env, /private, /secret, dump, .sql, password o credential. Se qualcuno corrisponde, apre un rilievo di gravità bassa con i percorsi trovati. La lista è volutamente corta: parole come test, old, tmp o logs compaiono in robots perfettamente legittimi e davano falsi positivi.

Perché è importante

robots.txt è pubblico per definizione: chiunque può leggerlo, ed è anzi tra i primi file che uno strumento di ricognizione consulta. Quando scrivi Disallow: /backups/ o Disallow: /vecchio-admin/ non stai nascondendo quei percorsi; li stai indicando a chi li cerca, con la garanzia aggiuntiva che ti stanno a cuore. Google non li scansionerà, ma un attaccante non legge robots per obbedirgli, lo legge per sapere dove andare. È un rilievo di gravità bassa perché elencare un percorso non lo rende accessibile; il problema nasce quando il percorso elencato, per di più, non è protetto.

Come risolvere

• Togli da robots.txt i percorsi che non vuoi annunciare. Se non vuoi che Google indicizzi un'area privata, la cosa giusta è che quell'area richieda il login; ciò che sta dietro un'autenticazione non viene indicizzato comunque.
• Se ti serve che una pagina raggiungibile resti fuori dai motori senza annunciarla, usa l'header X-Robots-Tag: noindex o il meta robots in quella pagina. I motori lo rispettano e non resta scritto in un file pubblico.
• Proteggi il percorso davvero. Un pannello in /admin ha bisogno di autenticazione, non di una riga in robots. Una cartella /backups/ non dovrebbe proprio stare nella directory pubblica; i controlli file sensibili e elenco directory coprono quei casi.
• WordPress: il robots virtuale che genera include Disallow: /wp-admin/ di default. Non è grave, perché wp-admin richiede già il login e invia noindex; puoi lasciarlo o sostituire robots con uno tuo senza quella riga. L'importante è che il login abbia password forti, limite di tentativi e, se puoi, doppio fattore.

Un robots.txt sano di solito è corto: uno User-agent: *, magari un paio di Disallow per la ricerca interna o i parametri, e la riga Sitemap:. Se il tuo ha venti righe di percorsi "privati", sta facendo il lavoro di un sistema di permessi, e male.

Verifica che sia risolto

curl -s https://tuodominio.it/robots.txt | grep -iE "^disallow:.*(admin|phpmyadmin|backup|\.git|\.env|private|secret|dump|\.sql|password|credential)"

Non deve uscire nulla. E per ogni percorso che hai tolto, controlla che chieda davvero autenticazione o restituisca 404:

curl -s -o /dev/null -w "%{http_code}\n" https://tuodominio.it/admin/

Domande frequenti

Se tolgo /admin da robots.txt, Google lo indicizzerà?

Se /admin chiede il login, Google vede solo la schermata di accesso, e di norma quella schermata porta noindex. Se non chiede il login, il problema non è l'indicizzazione, è che il tuo pannello è aperto.

Posso bloccare tutto ed elencare solo ciò che è pubblico?

Per un sito che vuole traffico organico, no: bloccare tutto con Disallow: / lo toglie dai motori di ricerca. Se vuoi controllare la scansione, il controllo robots e sitemap verifica che tu non stia bloccando te stesso.

E i bot di IA?

Bloccare o permettere GPTBot, ClaudeBot e compagnia è una decisione di business diversa e va nello stesso file. Non ha a che fare con questo controllo, che guarda solo i percorsi sensibili.