Alert quando cambia il robots.txt: come farsi avvisare subito

Un alert sulle modifiche al robots.txt ti avvisa quando qualcuno cambia le regole di scansione di un sito, così un Disallow: / finito online per sbaglio viene tolto prima che il sito perda la scansione. Il robots.txt è un semplice file di testo che può impedire a Googlebot di richiedere qualsiasi URL di un dominio, e quando succede sul sito non sembra rotto niente.

Una sequenza tipica è questa. Un deploy copia in produzione la configurazione dello staging, il Disallow: / va online e il sito continua a caricarsi normalmente, sia per i visitatori sia per i controlli di uptime. Una o due settimane dopo le impression in Search Console iniziano a calare, e solo allora qualcuno apre il file. Questa guida serve ad accorgersene prima. Per leggere e validare il file, parti da come controllare il robots.txt.

Quali modifiche meritano un alert

Molte modifiche al robots.txt sono innocue, come un plugin che aggiunge una regola per il proprio percorso di amministrazione. Queste invece vanno gestite in giornata.

Modifica	Effetto	Urgenza
Disallow: / sotto User-agent: *	Blocca ogni URL per ogni crawler	Da trattare come un incidente
Nuovo Disallow su una cartella di contenuti come /blog/ o /products/	Toglie un'intera sezione dalla scansione	In giornata
Nuovo gruppo User-agent: Googlebot	Googlebot segue solo quel gruppo e ignora le regole di *	In giornata, leggendo cosa contiene
Il file inizia a restituire un 5xx	Google sospende la scansione, poi si affida a una copia in cache	In giornata
File eliminato o in 404	Google considera il sito senza restrizioni e la riga Sitemap: sparisce	Da verificare, raramente urgente
Riga Sitemap: rimossa o che punta a un URL vecchio	Le nuove pagine vengono scoperte più lentamente	Bassa
Regole aggiunte per GPTBot, ClaudeBot, PerplexityBot o Google-Extended	Blocca i crawler AI, senza effetti su Google Search	Verifica che fosse voluto

La riga su Googlebot inganna in entrambe le direzioni. Qualcuno aggiunge per Googlebot un gruppo con un solo Disallow: /search e, siccome ora Googlebot ignora il gruppo *, le regole su /cart/ e /checkout/ che prima valevano anche per lui non si applicano più. Copia l'intero set di regole nel nuovo gruppo, altrimenti sarà più permissivo del previsto.

Quella sui crawler AI a volte è una scelta precisa, a volte un'impostazione predefinita attivata da un plugin di sicurezza o SEO che nessuno ha approvato. In ogni caso il cliente dovrebbe saperlo.

Una pagina bloccata può comunque essere indicizzata

Il robots.txt controlla la scansione, il noindex controlla l'indicizzazione. Un URL bloccato nel robots.txt può comparire nei risultati, di solito senza descrizione, perché Google lo conosce dai link ma non ha mai avuto il permesso di scaricarlo. Search Console lo segnala come "Indicizzata, ma bloccata da robots.txt".

La trappola è combinare le due cose. Se metti un noindex su una pagina e la blocchi anche nel robots.txt, Google non la scansiona mai, non legge mai il noindex e l'URL può restare indicizzato. Per togliere una pagina dai risultati lasciala scansionabile e servi il noindex. La guida al tag noindex copre questa metà del discorso.

Cosa ti dice Search Console, e quando

Il report robots.txt di Search Console (Impostazioni > robots.txt) mostra le versioni scaricate da Google, quando le ha scaricate e se il recupero è andato a buon fine o ha incontrato problemi di parsing. È utile per la diagnosi quando sai già che qualcosa non va, ma non ti manda un'email quando cambia una riga. Il primo segnale automatico di solito è un aumento di "Bloccata da robots.txt" nel report Pagine, che compare solo dopo che Google ha riscansionato gli URL con le nuove regole. Google inoltre tiene in cache il robots.txt fino a 24 ore, quindi anche il suo recupero può arrivare un giorno dopo la modifica.

Un controllo di base fatto in casa

Con pochi siti e l'accesso a un server, un piccolo script lanciato ogni ora da cron copre le basi:

#!/bin/sh
URL="https://example.com/robots.txt"
DIR="/var/lib/robots-watch"
mkdir -p "$DIR" && touch "$DIR/last.txt"
STATUS=$(curl -s -o "$DIR/new.txt" -w "%{http_code}" "$URL")
if [ "$STATUS" != "200" ]; then
  echo "robots.txt returned $STATUS" | mail -s "robots.txt error" you@example.com
  exit 1
fi
if ! cmp -s "$DIR/new.txt" "$DIR/last.txt"; then
  diff "$DIR/last.txt" "$DIR/new.txt" | mail -s "robots.txt changed" you@example.com
fi
mv "$DIR/new.txt" "$DIR/last.txt"

Lo script controlla lo status code oltre al contenuto, e non è un dettaglio, perché un 5xx persistente è grave quanto una regola sbagliata. I punti deboli emergono quando l'elenco dei siti cresce. Ti serve una voce per ogni sito e un invio email funzionante, non scopri nulla sulle modifiche a noindex o sitemap arrivate con lo stesso deploy, e nessuno si accorge se il cron job smette di girare.

Alert sulle modifiche al robots.txt con Deltio

Deltio scarica il robots.txt di ogni sito che aggiungi durante il controllo giornaliero, lo confronta con la versione del controllo precedente e, se è cambiato, invia un alert su Slack e via email per quel sito. Lo stesso passaggio controlla noindex, canonical, title e gli URL nella sitemap, così un deploy dallo staging che rompe più cose insieme arriva come un unico gruppo di alert. Gli alert sulle modifiche SEO elencano tutto ciò che viene controllato.

Il limite, detto onestamente, è la frequenza. Con un controllo giornaliero, una modifica fatta subito dopo un controllo viene segnalata il giorno seguente, mentre uno script orario come quello qui sopra la intercetterebbe prima. Considerando la cache di Google sul file e il tempo che serve per una nuova scansione, un alert in giornata o il giorno dopo di norma arriva comunque prima che il danno si veda in Search Console.

Come primo sito scegli quello che ti preoccupa di più, che sia quello con i deploy più frequenti o quello i cui sviluppatori ti raccontano meno. Tutti i piani includono una prova gratuita di 14 giorni.