Specifiche del file robots.txt

Riepilogo

di Google Developers Questo documento descrive in dettaglio come Google gestisce il file robots.txt che ti consente di controllare come i crawler dei siti web di Google eseguono la scansione e l’indicizzazione pubblicamente siti web accessibili.

Cosa è cambiato

Il 1 ° luglio 2019, Google ha annunciato che il protocollo robots.txt sta lavorando per diventare uno standard Internet. Tali modifiche si riflettono in questo documento.

Elenco delle modifiche

Ecco cosa è cambiato:

  • Rimossa la sezione “Lingua dei requisiti” in questo documento perché la lingua è specifica per Internet draft.
  • Robots.txt ora accetta tutti i protocolli basati su URI.
  • Google segue almeno cinque hop di reindirizzamento. Poiché non sono state ancora recuperate regole, i reindirizzamenti vengono seguiti per almeno cinque hop e se non viene trovato alcun file robots.txt, Google lo considera come un 404 per il file robots.txt. La gestione dei reindirizzamenti logici per il file robots.txt in base al contenuto HTML che restituisce 2xx (frame, JavaScript o reindirizzamenti di tipo meta refresh) è sconsigliata e il contenuto della prima pagina viene utilizzato per trovare le regole applicabili.
  • Per 5xx, se il file robots.txt è irraggiungibile per più di 30 giorni, viene utilizzata l’ultima copia memorizzata nella cache del file robots.txt o, se non disponibile, Google presume che non ci siano limitazioni di scansione.
  • Google considera le richieste non riuscite o i dati incompleti come un errore del server.
  • I “record” sono ora chiamati “righe” o “regole”, a seconda dei casi.
  • Google non supporta la gestione di <field> elementi con semplici errori o refusi (ad esempio, “useragent” invece di “user-agent”).
  • Google attualmente applica un limite di dimensione di 500 kibibyte (KiB) e ignora i contenuti dopo tale limite.
  • Sintassi formale aggiornata per essere valida Augmented Backus-Naur Form (ABNF) per RFC5234 e per coprire i caratteri UTF-8 nel file robots.txt.
  • Aggiornata la definizione di “gruppi “per renderlo più breve e più pertinente. Aggiunto un esempio per un gruppo vuoto.
  • Rimossi i riferimenti al deprecato Ajax Crawling Scheme.

Definizioni di base

Definizioni
Crawler Un crawler è un servizio o un agente che esegue la scansione di siti web. In generale, un crawler automaticamente e accede in modo ricorsivo agli URL noti di un host che espone contenuti a cui è possibile accedere con browser web standard. Man mano che vengono trovati nuovi URL (tramite vari mezzi, ad esempio da link su pagine esistenti sottoposte a scansione o da file Sitemap), anche questi vengono sottoposti a scansione allo stesso modo.
Utente- agente Un mezzo per identificare uno specifico crawler o un insieme di crawler.
Direttive L’elenco delle linee guida applicabili per un crawler o un gruppo di crawler indicati nel file robots.txt.
URL Uniform Resource Locator come definito nella RFC 1738.
Specifico di Google Questi elementi sono specifici dell’implementazione di robots.txt da parte di Google e potrebbero non essere pertinenti per altre parti.

Applicabilità

Le linee guida stabilite in questo documento sono seguite da tutti i crawler automatici di Google. Quando un agente accede agli URL per conto di un utente (ad esempio, per la traduzione, feed sottoscritti manualmente, analisi del malware), queste linee guida non devono essere applicate.

Fi posizione le e intervallo di validità

Il file robots.txt deve trovarsi nella directory di primo livello dell’host, accessibile tramite il protocollo e il numero di porta appropriati. I protocolli generalmente accettati per robots.txt sono tutti basati su URI e per la Ricerca Google in particolare (ad esempio, la scansione di siti web) sono “http” e “https”. Su http e https, il file robots.txt viene recuperato utilizzando una richiesta GET HTTP non condizionale.

Specifico di Google: Google accetta e segue anche i file robots.txt per i siti FTP. I file robots.txt basati su FTP sono accessibili tramite il protocollo FTP, utilizzando un accesso anonimo.

Le direttive elencate nel file robots.txt si applicano solo all’host, al protocollo e al numero di porta in cui è ospitato il file .

Esempi di URL robots.txt validi

Gestione dei codici dei risultati HTTP

Ci sono generalmente tre risultati diversi quando vengono recuperati i file robots.txt:

  • full allow: tutto il contenuto può essere sottoposto a scansione.
  • full disallow: nessun contenuto può essere sottoposto a scansione.
  • conditional allow: le direttive nel file robots.txt determinano la capacità di eseguire la scansione di determinati contenuti.
Gestione dei codici dei risultati HTTP
2xx (riuscito) Codici risultato HTTP che segnalano il risultato positivo in un “permesso condizionale” di gattonare.
3xx (reindirizzamento) Google segue almeno cinque hop di reindirizzamento come definito da RFC 1945 per HTTP / 1.0, quindi si ferma e lo considera come un 404 La gestione dei reindirizzamenti robots.txt a URL non consentiti è sconsigliata; poiché non sono state ancora recuperate regole, i reindirizzamenti vengono seguiti per almeno cinque hop e se non viene trovato alcun file robots.txt, Google lo considera un 404 per il file robots.txt. La gestione dei reindirizzamenti logici per il file robots.txt in base al contenuto HTML che restituisce 2xx (frame, JavaScript o reindirizzamenti di tipo meta refresh) è sconsigliata e il contenuto della prima pagina viene utilizzato per trovare le regole applicabili.
4xx (errori client) Tutti gli errori 4xx vengono trattati allo stesso modo e si presume che non esista alcun file robots.txt valido. presume che non ci siano restrizioni. Questo è un “permesso completo” per la scansione.
5xx (errore del server)

Vengono visualizzati errori del server come errori temporanei che si traducono in un “blocco completo” della scansione. La richiesta viene ritentata fino a quando non viene ottenuto un codice di risultato HTTP non di errore del server. Un errore 503 (Servizio non disponibile) si traduce in ripetizioni abbastanza frequenti. Se il file robots.txt è irraggiungibile per più di 30 giorni, viene utilizzata l’ultima copia memorizzata nella cache del file robots.txt. Se non è disponibile, Google presume che non vi siano limitazioni di scansione. Per sospendere temporaneamente la scansione, si consiglia di fornire un codice risultato HTTP 503.

Specifico di Google: se siamo in grado di determinare che un sito è configurato in modo errato per restituire 5xx invece di 404 per le pagine mancanti, consideriamo un errore 5xx da quel sito come 404.

Non riuscito richieste o dati incompleti La gestione di un file robots.txt che non può essere recuperato a causa di problemi DNS o di rete, come timeout, risposte non valide, connessioni ripristinate o interrotte ed errori di blocchi HTTP, viene trattata come un errore del server.
La memorizzazione nella cache del contenuto del file robots.txt viene generalmente memorizzata nella cache per un massimo di 24 ore, ma può essere memorizzata nella cache più a lungo in situazioni in cui l’aggiornamento della cache la versione non è possibile (ad esempio, a causa di timeout o errori 5xx). La risposta memorizzata nella cache può essere condivisa da diversi crawler. Google può aumentare o diminuire la durata della cache in base alle intestazioni HTTP Cache-Control max-age.

Formato file

Il formato file previsto è testo normale codificato in UTF-8. Il file è composto da righe separate da CR, CR / LF o LF.

Vengono considerate solo le righe valide; tutti gli altri contenuti vengono ignorati. Ad esempio, se il documento risultante è una pagina HTML, vengono prese in considerazione solo le righe di testo valide, il resto viene scartato senza avvertimenti o errori.

Se viene utilizzata una codifica dei caratteri, vengono utilizzati caratteri che non sono un sottoinsieme di UTF-8, ciò potrebbe comportare un’analisi errata del contenuto del file.

Un BOM Unicode (contrassegno dell’ordine dei byte) opzionale all’inizio del file robots.txt viene ignorato.

Ogni riga valida è composta da un campo, due punti e un valore. Gli spazi sono facoltativi (ma consigliati per migliorare la leggibilità). I commenti possono essere inclusi in qualsiasi posizione nel file utilizzando il carattere “#”; tutto il contenuto dopo l’inizio di un commento fino alla fine della riga viene trattato come un commento e ignorato. Il formato generale è <field>:<value><#optional-comment>. Gli spazi all’inizio e alla fine della riga vengono ignorati.

L’elemento <field> non fa distinzione tra maiuscole e minuscole. L’elemento < value > può fare distinzione tra maiuscole e minuscole, a seconda del campo < > elemento.

Gestione di <field> elementi con semplici errori o refusi (ad esempio, “useragent” invece di ” user-agent “) non è supportato.

È possibile applicare una dimensione massima del file per crawler. Il contenuto che si trova dopo la dimensione massima del file viene ignorato. Google attualmente applica un limite di dimensione di 500 kibibyte (KiB). Per ridurre le dimensioni del file robots.txt, consolida le direttive che risulterebbero in un file robots.txt di grandi dimensioni. Ad esempio, collocare il materiale escluso in una directory separata.

Sintassi / definizione formale

Ecco una descrizione ABNF (Augmented Backus-Naur Form), come descritto nella RFC 5234

Raggruppamento di righe e regole

Una o più user-agent righe seguite da una o più regole. Il gruppo viene terminato da una riga user-agent o dalla fine del file. L’ultimo gruppo potrebbe non avere regole, il che significa che consente implicitamente tutto.

Gruppi di esempio:

user-agent: adisallow: /cuser-agent: bdisallow: /duser-agent: euser-agent: fdisallow: /guser-agent: h

Sono specificati quattro gruppi distinti :

  • Un gruppo per “a”
  • Un gruppo per “b”
  • Un gruppo per “e” e “f”
  • Un gruppo per “h”

Ad eccezione dell’ultimo gruppo (gruppo “h”), ogni gruppo ha la propria linea di membri del gruppo. L’ultimo gruppo (gruppo “h”) è vuoto.Nota l’uso facoltativo di spazi e righe vuote per migliorare la leggibilità.

Ordine di precedenza per i programmi utente

Solo un gruppo è valido per un particolare crawler. Il crawler deve determinare il gruppo di righe corretto trovando il gruppo con l’agente utente più specifico che ancora corrisponde. Tutti gli altri gruppi vengono ignorati dal crawler. Il programma utente fa distinzione tra maiuscole e minuscole. Tutto il testo non corrispondente viene ignorato (ad esempio, sia googlebot/1.2 e googlebot* sono equivalenti a googlebot). L’ordine dei gruppi all’interno del file robots.txt è irrilevante.

Se esiste più di un gruppo dichiarato per uno specifico programma utente, tutte le regole dei gruppi applicabili allo specifico programma utente vengono combinate in un unico gruppo.

Esempi

Esempio 1

Supponendo il seguente file robots.txt:

 user-agent: googlebot-news (group 1) user-agent: * (group 2) user-agent: googlebot (group 3) 

Questo è il modo in cui i crawler sceglierebbero gruppo pertinente:

Gruppo seguito per crawler
Googlebot News Il gruppo seguito è il gruppo 1. Viene seguito solo il gruppo più specifico, tutti gli altri vengono ignorati.
Googlebot (web) Il gruppo seguito è il gruppo 3.
Googlebot Images Il gruppo seguito è il gruppo 3. Non esiste un gruppo googlebot-images specifico, quindi viene seguito il gruppo più generico .
Googlebot News (durante la scansione delle immagini) > Il gruppo seguito è il gruppo 1. Queste immagini vengono sottoposte a scansione per e da Googlebot News, pertanto viene seguito solo il gruppo Googlebot News.
Otherbot (web) Il gruppo seguito è il gruppo 2.
Otherbot (News) Il gruppo seguito è il gruppo 2. Anche se c’è una voce per un crawler correlato, è valido solo se corrisponde specificatamente.

Esempio 2

Supponendo il seguente file robots.txt:

 user-agent: googlebot-news disallow: /fish user-agent: * disallow: /carrots user-agent: googlebot-news disallow: /shrimp 

Questo è il modo in cui i crawler unirebbero i gruppi pertinenti a uno specifico agente utente:

 user-agent: googlebot-news disallow: /fish disallow: /shrimp user-agent: * disallow: /carrots 

Vedi anche i crawler e le stringhe user-agent di Google.

Regole dei membri del gruppo

Solo standard le regole dei membri del gruppo sono trattate in questa sezione. Queste regole sono anche chiamate “direttive” per i crawler. Queste direttive sono specificate nella forma di directive: dove è opzionale. Per impostazione predefinita, non ci sono restrizioni per la scansione per i crawler designati. Le direttive senza un vengono ignorate.

Il valore , se specificato, deve essere visto relativo dal radice del sito Web per il quale è stato recuperato il file robots.txt (utilizzando lo stesso protocollo, numero di porta, host e nomi di dominio). Il valore del percorso deve iniziare con “/” per designare la radice. Il percorso fa distinzione tra maiuscole e minuscole. Ulteriori informazioni sono disponibili nella sezione “Corrispondenza URL basata sui valori del percorso” di seguito.

disallow

La direttiva disallow specifica i percorsi che non deve essere accessibile dai crawler designati. Quando non viene specificato alcun percorso, la direttiva viene ignorata.

Utilizzo:

disallow: 

allow

Il allow specifica i percorsi a cui possono accedere i crawler designati. Quando non viene specificato alcun percorso, la direttiva viene ignorata.

Utilizzo:

allow: 

Corrispondenza URL basata sui valori di percorso

Il valore del percorso viene utilizzato come base per determinare se una regola si applica o meno a un URL specifico su un sito. Ad eccezione dei caratteri jolly, il percorso viene utilizzato per abbinare l’inizio di un URL (e qualsiasi URL valido che inizia con lo stesso percorso). I caratteri ASCII non a 7 bit in un percorso possono essere inclusi come caratteri UTF-8 o come caratteri codificati UTF-8 con escape percentuale per RFC 3986.

Google, Bing e altri importanti motori di ricerca supportano un forma limitata di “caratteri jolly” per i valori di percorso. Questi sono:

  • * indica 0 o più istanze di qualsiasi carattere valido.
  • $ indica la fine dell’URL.

Linee non membri di gruppi supportate da Google

Google, Bing e altri importanti motori di ricerca supportano sitemap, come definito da sitemaps.org.

Utilizzo:

sitemap: 

punta a una Sitemap, a un file Indice Sitemap o a un URL equivalente. L’URL non deve trovarsi sullo stesso host del file robots.txt. Possono esistere più voci sitemap. In quanto linee non membri del gruppo, queste non sono legate ad alcun programma utente specifico e possono essere seguite da tutti i crawler, a condizione che non siano disabilitate.

Ordine di precedenza per le righe dei membri del gruppo

A livello di membro del gruppo, in particolare per allow e disallow, la regola più specifica basata sulla lunghezza della voce prevale sulla regola meno specifica (più breve). In caso di regole in conflitto, comprese quelle con caratteri jolly, viene utilizzata la regola meno restrittiva.

Test del markup robots.txt

Google offre due opzioni per testare il markup robots.txt:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *