Specifiche relative al file robots.txt

Abstract

In questo documento viene illustrato in che modo Google gestisce il file robots.txt che ti consente di controllare come i crawler dei siti web di Google sottopongono a scansione e indicizzano i siti web pubblicamente accessibili.

Che cosa è cambiato

Il 1° luglio 2019, Google ha annunciato che il protocollo robots.txt sarebbe diventato uno standard Internet. Queste modifiche sono riportate nel presente documento.

Definizioni di base

Definizioni
Crawler Un crawler è un servizio o agente che sottopone a scansione i siti web. In termini generali, un crawler accede automaticamente e ripetutamente agli URL conosciuti di un host che pubblica contenuti accessibili tramite i browser web standard. Man mano che vengono rilevati nuovi URL (in vari modi, ad esempio, dai link nelle pagine analizzate esistenti o dai file Sitemap), anche questi vengono sottoposti a scansione nello stesso modo.
User-agent Mezzo per identificare un crawler o un insieme di crawler specifici.
Istruzioni Elenco delle linee guida applicabili per un crawler o gruppo di crawler impostate nel file robots.txt.
URL Uniform Resource Locator, così come definito nel documento RFC 1738.
Specifico di Google Riferito a elementi specifici dell'implementazione del file robots.txt di Google, che potrebbero risultare non pertinenti per altre parti.

Applicabilità

Le linee guida contenute nel presente documento sono seguite da tutti i crawler automatizzati di Google. Quando un agente accede agli URL per conto di un utente (ad esempio, per traduzione, feed registrati manualmente, analisi malware), non è necessario seguire queste linee guida.

Posizione del file e intervallo di validità

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

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

Le istruzioni contenute nel file robots.txt si applicano solo all'host, al protocollo e al numero di porta in cui è ospitato il file.

Esempi di URL di file robots.txt validi

Esempi di URL di file robots.txt
http://example.com/robots.txt Valido per:
  • http://example.com/
  • http://example.com/folder/file
Non valido per:
  • http://other.example.com/
  • https://example.com/
  • http://example.com:8181/
http://www.example.com/robots.txt

Valido per: http://www.example.com/

Non valido per:

  • http://example.com/
  • http://shop.www.example.com/
  • http://www.shop.example.com/
http://example.com/folder/robots.txt Non è un file robots.txt valido. I crawler non verificano la presenza di file robots.txt nelle sottodirectory.
http://www.müller.eu/robots.txt Valido per:
  • http://www.müller.eu/
  • http://www.xn--mller-kva.eu/

Non valido per: http://www.muller.eu/

ftp://example.com/robots.txt

Valido per: ftp://example.com/

Non valido per: http://example.com/

Specifico di Google: Google utilizza il file robots.txt per le risorse FTP.

http://212.96.82.21/robots.txt

Valido per: http://212.96.82.21/

Non valido per: http://example.com/ (anche se ospitato su 212.96.82.21)

http://example.com:80/robots.txt

Valido per:

  • http://example.com:80/
  • http://example.com/

Non valido per: http://example.com:81/

http://example.com:8181/robots.txt

Valido per: http://example.com:8181/

Non valido per: http://example.com/

Gestione dei codici risultato HTTP

In genere, esistono tre diversi risultati quando vengono recuperati i file robots.txt:

  • full allow: tutti i risultati possono essere sottoposti a scansione.
  • full disallow: nessun risultato può essere sottoposto a scansione.
  • conditional allow: le istruzioni nel file robots.txt definiscono la capacità di sottoporre a scansione determinati contenuti.
Gestione dei codici risultato HTTP
2xx (esito positivo) I codici risultato HTTP che indicano un esito positivo generano un'istruzione di scansione di tipo "conditional allow".
3xx (reindirizzamento) Google segue almeno cinque hop di reindirizzamento come definito dal documento RFC 1945 per HTTP/1.0 quindi si interrompe e lo tratta come un errore 404. La gestione dei reindirizzamenti dal file robots.txt agli URL non consentiti non è consigliata; poiché non sono ancora state recuperate regole, i reindirizzamenti vengono seguiti per almeno cinque hop e, se non viene trovato alcun file robots.txt, Google lo considera come un errore 404. La gestione dei reindirizzamenti logici per il file robots.txt basata su contenuti HTML che restituisce un errore di tipo 2xx (frame, JavaScript o reindirizzamenti di aggiornamento dei metadati) non è consigliata e i contenuti della prima pagina vengono utilizzati per trovare le regole applicabili.
4xx (errori client) Tutti gli errori 4xx vengono trattati allo stesso modo e si presume che non esista un file robots.txt valido. Si presuppone che non vi siano restrizioni. Si tratta di un'istruzione di scansione di tipo "full allow".
5xx (errore del server)

Gli errori del server vengono considerati come errori temporanei che generano un'istruzione di scansione di tipo "full disallow". La richiesta viene ripetuta fino a ottenere un codice risultato HTTP che non corrisponde a un errore del server. Un errore 503 (Servizio non disponibile) genera ripetizioni abbastanza frequenti. Se il file robots.txt non è raggiungibile per più di 30 giorni, viene utilizzata l'ultima copia memorizzata nella cache. Se non disponibile, Google presume che non vi siano restrizioni di scansione. Per sospendere temporaneamente la scansione, consigliamo di pubblicare un codice risultato HTTP 503.

Specifico di Google: se Google riesce a stabilire che un sito è configurato in modo errato e restituisce un errore di tipo 5xx anziché 404 per le pagine mancanti, l'errore 5xx restituito da tale sito viene trattato come errore 404.

Richieste non riuscite o dati incompleti La gestione di un file robots.txt che non può essere recuperato a causa di problemi di rete o DNS come timeout, risposte non valide, connessioni ripristinate/interrotte ed errori di suddivisione HTTP viene considerata come un errore del server.
Memorizzazione nella cache In genere, i contenuti del file robots.txt vengono memorizzati nella cache per 24 ore al massimo, ma possono essere archiviati più a lungo nei casi in cui non sia possibile aggiornare la versione memorizzata nella cache (ad esempio, a causa di timeout o di errori di tipo 5xx). La risposta memorizzata nella cache può essere condivisa da diversi crawler. Google potrebbe aumentare o diminuire la durata della cache in base alle intestazioni HTTP max-age Cache-Control.

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 righe di testo valide. Le altre verranno eliminate senza avviso o errore.

Se viene utilizzata una codifica i cui caratteri non appartengono a UTF-8, i contenuti del file potrebbero essere analizzati in modo errato.

Un carattere Unicode facoltativo BOM (byte order mark) 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 una maggiore leggibilità). I commenti possono essere inclusi in qualsiasi punto del file utilizzando il carattere "#"; tutti i contenuti dopo l'inizio di un commento fino alla fine della riga vengono trattati come commento e ignorati. Il formato generale è <field>:<value><#optional-comment>. Lo spazio vuoto all'inizio e alla fine della riga viene ignorato.

L'elemento <field> non prevede la distinzione tra maiuscole e minuscole. L'elemento <value> potrebbe fare distinzione tra maiuscole e minuscole, a seconda dell'elemento <field>.

La gestione degli elementi <field> contenenti errori semplici o di digitazione (ad esempio, "useragent" invece di "user-agent") non è supportata.

Potrebbe essere applicata una dimensione massima del file per crawler. I contenuti che superano tale dimensione massima vengono ignorati. Attualmente Google applica un limite di dimensione pari a 500 kibibyte (KiB). Per ridurre le dimensioni del file robots.txt, consolida le istruzioni che genererebbero un file robots.txt di grandi dimensioni. Ad esempio, posiziona il materiale escluso in una directory separata.

Definizione/sintassi formale

Segue un esempio di descrizione ABNF (Augmented Backus-Naur Form), come descritto nel documento RFC 5234

    robotstxt = *(group / emptyline)
    group = startgroupline                    ; We start with a user-agent
            *(startgroupline / emptyline)     ; ... and possibly more user-agents
            *(rule / emptyline)               ; followed by rules relevant for UAs

    startgroupline = *WS "user-agent" *WS ":" *WS product-token EOL

    rule = *WS ("allow" / "disallow") *WS ":" *WS (path-pattern / empty-pattern) EOL

    ; parser implementors: add additional lines you need (for example, Sitemaps), and
    ; be lenient when reading lines that don’t conform. Apply Postel’s law.

    product-token = identifier / "*"
    path-pattern = "/" *(UTF8-char-noctl)    ; valid URI path pattern; see 3.2.2
    empty-pattern = *WS

    identifier = 1*(%x2d / %x41-5a / %x5f / %x61-7a)
    comment = "#" *(UTF8-char-noctl / WS / "#")
    emptyline = EOL
    EOL = *WS [comment] NL         ; end-of-line may have optional trailing comment
    NL = %x0D / %x0A / %x0D.0A
    WS = %x20 / %x09

    ; UTF8 derived from RFC3629, but excluding control characters
    UTF8-char-noctl = UTF8-1-noctl / UTF8-2 / UTF8-3 / UTF8-4
    UTF8-1-noctl    = %x21 / %x22 / %x24-7F  ; excluding control, space, '#'
    UTF8-2          = %xC2-DF UTF8-tail
    UTF8-3          = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
                      %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
    UTF8-4          = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
                      %xF4 %x80-8F 2( UTF8-tail )
    UTF8-tail       = %x80-BF
    

Raggruppamento di righe e regole

Una o più righe user-agent seguite da una o più regole. Il gruppo viene terminato da una riga user-agent o quando si raggiunge la fine del file. L'ultimo gruppo potrebbe non avere regole; in questo caso si autorizza tutto in modo implicito.

Gruppi di esempio:

    user-agent: a
    disallow: /c

    user-agent: b
    disallow: /d

    user-agent: e
    user-agent: f
    disallow: /g

    user-agent: h
    

Sono specificati quattro gruppi distinti, uno per "a", uno per "b", nonché uno per "e" e "f". A parte l'ultimo gruppo, ogni gruppo ha una riga group-member propria. L'ultimo gruppo è vuoto. Tieni presente l'utilizzo facoltativo di spazi e righe vuoti per migliorare la leggibilità.

Ordine di precedenza degli user-agent

Solo un gruppo è valido per un determinato crawler. Il crawler deve determinare il gruppo di righe corretto individuando il gruppo con lo user-agent corrispondente più specifico. Tutti gli altri gruppi vengono ignorati dal crawler. Lo user-agent fa distinzione tra maiuscole e minuscole. Tutto il testo che non corrisponde viene ignorato (ad esempio, googlebot/1.2 e googlebot* corrispondono entrambi a googlebot). L'ordine dei gruppi all'interno del file robots.txt non è rilevante.

Se è presente più di un gruppo per uno specifico user-agent, vengono combinate tutte le regole dei gruppi applicabili a quello specifico user-agent.

Esempio

Prendiamo il seguente file robots.txt:

    user-agent: googlebot-news
    (group 1)

    user-agent: *
    (group 2)

    user-agent: googlebot
    (group 3)
    

Ecco in che modo i crawler sceglierebbero il 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 Immagini 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 di immagini) >Il gruppo seguito è il gruppo 1. Le immagini vengono sottoposte a scansione per e da Googlebot News e, 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 esiste un'occorrenza per un crawler correlato, questa è valida solo se corrisponde in modo specifico.

Consulta anche l'articolo Stringhe user-agent e crawler di Google.

Regole Group-member

In questa sezione vengono trattate solo le regole group-member standard. Questi tipi di regole vengono denominate anche "istruzioni" per i crawler. Queste istruzioni sono specificate nel formato directive: [path], dove [path] è facoltativo. Per impostazione predefinita, non esistono limitazioni di scansione per i crawler designati. Le istruzioni senza un valore [path] vengono ignorate.

Il valore [path], se specificato, va considerato come derivato dal percorso principale del sito web per cui è stato recuperato il file robots.txt (utilizzando lo stesso protocollo, numero di porta, nome host e di dominio). Tale valore deve iniziare con "/" per indicare il percorso principale. Il percorso fa distinzione tra maiuscole e minuscole. Sono disponibili ulteriori informazioni nella sezione "Corrispondenza degli URL in base ai valori del percorso" qui sotto.

disallow

L'istruzione disallow specifica i percorsi a cui i crawler designati non devono accedere. Quando non sono specificati percorsi, l'istruzione viene ignorata.

Utilizzo:

    disallow: [path]
    

allow

L'istruzione allow specifica i percorsi a cui i crawler designati possono accedere. Quando non sono specificati percorsi, l'istruzione viene ignorata.

Utilizzo:

    allow: [path]
    

Corrispondenza degli URL in base ai valori del percorso

Il valore relativo al percorso viene utilizzato come base per stabilire se una regola è applicabile a un URL specifico in un sito. Ad eccezione dei caratteri jolly, il percorso viene utilizzato in modo che corrisponda all'inizio di un URL (e a qualsiasi URL valido che inizia con lo stesso percorso). I caratteri ASCII non a 7 bit in un percorso possono essere inclusi sotto forma di caratteri UTF 8 o caratteri UTF 8 sottoposti a escape con segno di percentuale in base al documento RFC 3986.

Google, Bing e altri principali motori di ricerca supportano una serie limitata di "caratteri jolly" per i valori relativi al percorso. Questi sono:

  • * che indica 0 o più istanze di un valore valido.
  • $ che indica la fine dell'URL.
Esempi di corrispondenze di percorso
/ Corrisponde all'URL principale e a ogni URL di livello inferiore
/* Equivalente a /. Il carattere jolly finale viene ignorato.
/fish

Corrispondenze:

  • /fish
  • /fish.html
  • /fish/salmon.html
  • /fishheads
  • /fishheads/yummy.html
  • /fish.php?id=anything

Nessuna corrispondenza:

  • /Fish.asp
  • /catfish
  • /?id=fish
/fish*

Equivalente a /fish. Il carattere jolly finale viene ignorato.

Corrispondenze:

  • /fish
  • /fish.html
  • /fish/salmon.html
  • /fishheads
  • /fishheads/yummy.html
  • /fish.php?id=anything

Nessuna corrispondenza:

  • /Fish.asp
  • /catfish
  • /?id=fish
/fish/

La barra finale indica che corrisponde a ogni elemento contenuto nella cartella.

Corrispondenze:

  • /fish/
  • /fish/?id=anything
  • /fish/salmon.htm

Nessuna corrispondenza:

  • /fish
  • /fish.html
  • /Fish/Salmon.asp
/*.php

Corrispondenze:

  • /filename.php
  • /folder/filename.php
  • /folder/filename.php?parameters
  • /folder/any.php.file.html
  • /filename.php/

Nessuna corrispondenza:

  • / (anche se indirizza a /index.php)
  • /windows.PHP
/*.php$

Corrispondenze:

  • /filename.php
  • /folder/filename.php

Nessuna corrispondenza:

  • /filename.php?parameters
  • /filename.php/
  • /filename.php5
  • /windows.PHP
/fish*.php

Corrispondenze:

  • /fish.php
  • /fishheads/catfish.php?parameters

Nessuna corrispondenza: /Fish.PHP

Righe non-group-member supportate da Google

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

Utilizzo:

    sitemap: [absoluteURL]
    

[absoluteURL] indirizza a una Sitemap, file Indice Sitemap o URL equivalente. L'URL non deve trovarsi sullo stesso host del file robots.txt. Possono esistere più occorrenze sitemap. In qualità di righe non-group-member, questi gruppi non sono legati a nessuno user-agent specifico e possono essere seguiti da tutti i crawler, a patto che siano consentiti.

Ordine di precedenza per le righe group-member

A livello di record group-member, soprattutto per le istruzioni allow e disallow, la regola più specifica basata sulla lunghezza della voce [path] ha la precedenza sulla regola meno specifica (più breve). In caso di regole in conflitto, incluse quelle con caratteri jolly, viene utilizzata la regola meno restrittiva.

Situazioni di esempio
http://example.com/page

allow: /p

disallow: /

Esito: allow

http://example.com/folder/page

allow: /folder

disallow: /folder

Esito: allow

http://example.com/page.htm

allow: /page

disallow: /*.htm

Esito: undefined

http://example.com/

allow: /$

disallow: /

Esito: allow

http://example.com/page.htm

allow: /$

disallow: /

Esito: disallow