Come verificare robots.txt per le pagine bloccate

Dove deve vivere robots.txt

Deve stare alla radice dell'host, come /robots.txt, in testo UTF-8 semplice. Si applica a esattamente uno schema, host e porta, quindi https://example.com/robots.txt non governa nulla su https://shop.example.com e nulla sulla versione http dello stesso host. Ogni sottodominio che vuoi controllare ha bisogno del proprio file.

Il codice di stato restituito dal file conta quanto il suo contenuto. Un 404 viene letto come "nessuna restrizione, scansiona tutto", che è uno stato perfettamente valido. Un 5xx ripetuto viene letto come un fallimento temporaneo e Google potrebbe mettere in pausa la scansione dell'host invece di presumere che sia autorizzato a continuare. Un 403 si comporta come un errore server a questo scopo. Se robots.txt è inaffidabile, la scansione diventa inaffidabile insieme a esso.

La sintassi, in cinque righe

User-agent: *
Disallow: /admin/
Allow: /admin/public-page.html
Disallow: /*?sessionid=
Sitemap: https://example.com/sitemap.xml

User-agent apre un gruppo. Disallow blocca un prefisso di percorso, Allow ritaglia un'eccezione da un blocco, * corrisponde a qualsiasi sequenza di caratteri e $ ancora la fine di un URL. Sitemap è indipendente da qualsiasi gruppo e prende un URL assoluto. Il formato è standardizzato come RFC 9309, quindi il comportamento descritto qui non è specifico di un fornitore.

Due regole di risoluzione decidono cosa succede realmente. Un crawler usa solo il gruppo più specifico che lo nomina, e ignora del tutto il gruppo * una volta che un gruppo lo nomina direttamente. All'interno di quel gruppo, vince la regola corrispondente più lunga, e un pareggio va ad Allow.

Gli errori che bloccano un intero sito

• Disallow: / rimasto da un deployment di staging. Un carattere, l'intero sito bloccato. Arriva esattamente nello stesso modo in cui arriva un noindex di staging: un file di configurazione promosso insieme a una release.
• Bloccare CSS e JavaScript. Google renderizza le pagine, quindi una directory di asset bloccata può far sembrare rotta al crawler una pagina che a te appare a posto.
• Aspettarsi che robots.txt rimuova una pagina dalla ricerca. Non può. Un URL bloccato può comunque essere elencato grazie a link esterni, di solito senza una descrizione, e poiché il crawler non può recuperarlo, un noindex su quella pagina non viene mai visto. Per rimuovere una pagina, permetti la scansione e servi noindex.
• Usare noindex: come direttiva dentro robots.txt. Non è mai stata parte dello standard e Google ha smesso di rispettarla il 1° settembre 2019. Oggi viene ignorata silenziosamente.
• Aggiungere un gruppo per un bot nominato aspettandosi che le regole con carattere jolly continuino ad applicarsi. Non è così. Una volta che esiste User-agent: Googlebot, Googlebot legge solo quel gruppo e nient'altro, quindi ogni regola condivisa deve essere ripetuta al suo interno.
• Una riga vuota dentro un gruppo. Una riga vuota chiude il gruppo, quindi le regole dopo di essa non appartengono a nulla fino alla successiva riga User-agent.
• Elencare percorsi privati. Il file è pubblico. Nominarci /internal-admin/ pubblica la posizione della cosa che stai cercando di nascondere.

Come testare un singolo percorso

Recupera il file e leggi prima il gruppo che si applica a te:

curl -s https://example.com/robots.txt

Poi applica a mano la regola della corrispondenza più lunga al percorso in questione. Con Disallow: /blog/ e Allow: /blog/public/, l'URL /blog/public/post è permesso perché la regola Allow corrispondente è più lunga. Per una proprietà che possiedi, il report robots.txt in Search Console mostra il file recuperato, quando è stato scaricato l'ultima volta e ogni errore di analisi, il che è il modo più veloce per confermare che il crawler sta leggendo quello che tu pensi che stia leggendo.

Conferma che sia raggiungibile da ovunque

Un robots.txt che si carica dalla tua scrivania può comunque fallire per un crawler. Le regole di protezione dai bot, i limiti di frequenza e i blocchi geografici restituiscono di routine 403 verso gli intervalli di indirizzi dei data center pur servendo normalmente i visitatori residenziali, e il risultato è un host che Google rallenta o smette di scansionare per motivi che nulla nei tuoi log chiama un errore.

Il modo per vederlo è richiedere il file da un posto che non è il tuo ufficio. Punta lo strumento gratuito di controllo HTTP su https://example.com/robots.txt e leggi il codice di stato restituito da postazioni in paesi diversi. Un 200 ovunque è la risposta sana; un 200 a casa tua e un 403 da tre regioni è la scoperta. Per testare se le regole bloccano una pagina specifica, il tester robots.txt gratuito controlla un URL rispetto al gruppo per tutti i crawler e riporta se è elencato nella sitemap. Robots.txt vive fuori dalla pagina, quindi l'opzione Indexability su un monitor HTTP di HostTracker non lo legge: sorveglia i tag noindex e canonical sulla pagina stessa, mentre la scansione pianificata, in beta, verifica incrociando ogni pagina scansionata con il robots.txt. Il monitoraggio SEO spiega cosa copre ciascuno.