In che modo Google interpreta la specifica del file robots.txt

I crawler automatici di Google supportano il protocollo di esclusione robot (REP). Ciò significa che, prima di eseguire la scansione di un sito, i crawler di Google scaricano e analizzano il file robots.txt del sito per estrarre informazioni su quali parti del sito possono essere sottoposte a scansione. Il REP non è applicabile ai crawler di Google controllati dagli utenti (ad esempio le iscrizioni ai feed) o a quelli utilizzati per aumentare la sicurezza degli utenti (ad esempio l'analisi di malware).

In questa pagina viene descritta l'interpretazione del REP da parte di Google. Per conoscere lo standard originale, consulta il documento RFC 9309.

Che cos'è un file robots.txt

Se non vuoi che i crawler accedano a determinate sezioni del tuo sito, puoi creare un file robots.txt con regole appropriate. Un file robots.txt è un semplice file di testo contenente delle regole che stabiliscono quali crawler possono accedere a determinate parti di un sito. Ad esempio, il file robots.txt di example.com potrebbe avere il seguente aspetto:

# This robots.txt file controls crawling of URLs under https://example.com.
# All crawlers are disallowed to crawl files in the "includes" directory, such
# as .css, .js, but Google needs them for rendering, so Googlebot is allowed
# to crawl them.
User-agent: *
Disallow: /includes/

User-agent: Googlebot
Allow: /includes/

Sitemap: https://example.com/sitemap.xml

Se hai poca familiarità con questo tipo di file, consulta la nostra introduzione ai file robots.txt. Puoi anche consultare i suggerimenti per la creazione di un file robots.txt.

Posizione del file e intervallo di validità

Il file robots.txt deve essere inserito nella directory di primo livello di un sito, su un protocollo supportato. L'URL del file robots.txt è sensibile alle maiuscole, come gli altri URL. Nel caso della Ricerca Google, i protocolli supportati sono HTTP, HTTPS e FTP. Nei protocolli HTTP e HTTPS, i crawler recuperano il file robots.txt con una richiesta HTTP GET non condizionale; nei protocolli FTP, i crawler impiegano un comando RETR (RETRIEVE) standard, utilizzando l'accesso anonimo.

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

Esempi di URL di file robots.txt validi

La seguente tabella contiene esempi di URL di file robots.txt e per quali percorsi degli URL sono validi. La colonna 1 contiene l'URL di un file robots.txt, mentre la colonna 2 contiene i domini a cui il file robots.txt sarebbe applicabile e non.

Esempi di URL di file robots.txt
https://example.com/robots.txt

Questo è il caso generico. Non è valido per altri sottodomini, protocolli o numeri di porta. È valido per tutti i file in tutte le sottodirectory dello stesso host, protocollo e numero di porta.

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

Un file robots.txt in un sottodominio è valido solo per questo sottodominio.

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

Non valido per:

  • https://example.com/
  • https://shop.www.example.com/
  • https://www.shop.example.com/
https://example.com/folder/robots.txt Non è un file robots.txt valido. I crawler non verificano la presenza di file robots.txt nelle sottodirectory.
https://www.exämple.com/robots.txt

I nomi IDN corrispondono alle rispettive versioni punycode. Consulta anche il documento RFC 3492.

Valido per:
  • https://www.exämple.com/
  • https://xn--exmple-cua.com/

Non valido per: https://www.example.com/

ftp://example.com/robots.txt

Valido per: ftp://example.com/

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

https://212.96.82.21/robots.txt

Un file robots.txt con indirizzo IP come nome host è valido solo per la scansione di questo indirizzo IP come nome host. Non sarà automaticamente valido per tutti i siti web ospitati su quell'indirizzo IP (anche se è possibile che il file robots.txt sia condiviso; in tal caso, sarà disponibile anche nel nome host condiviso).

Valido per: https://212.96.82.21/

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

https://example.com:443/robots.txt

I numeri di porta standard (80 per HTTP, 443 per HTTPS, 21 per FTP) corrispondono ai relativi nomi host predefiniti.

Valido per:

  • https://example.com:443/
  • https://example.com/

Non valido per: https://example.com:444/

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

I file robots.txt sui numeri di porta non standard sono validi solo per i contenuti resi disponibili tramite questi numeri di porta.

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

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

Gestione degli errori e dei codici di stato HTTP

Quando viene richiesto un file robots.txt, il codice di stato HTTP della risposta del server influisce sul modo in cui il file robots.txt verrà utilizzato dai crawler di Google. La seguente tabella riassume il modo in cui Googlebot tratta i file robots.txt in base ai diversi codici di stato HTTP.

Gestione degli errori e dei codici di stato HTTP
2xx (success) I codici di stato HTTP che indicano un esito positivo richiedono ai crawler di Google di elaborare il file robots.txt fornito dal server.
3xx (redirection)

Google segue almeno cinque hop di reindirizzamento come definito dal documento RFC 1945, poi si interrompe e lo considera come un errore 404 per il file robots.txt. Questo vale anche per tutti gli URL non consentiti nella catena di reindirizzamento, dato che il crawler non è riuscito a recuperare le regole a causa dei reindirizzamenti.

Google non segue i reindirizzamenti logici nei file robots.txt (frame, JavaScript o reindirizzamenti di aggiornamento dei metadati).

4xx (client errors)

I crawler di Google trattano tutti gli errori 4xx, ad eccezione del 429, come se non esistesse un file robots.txt valido. Ciò significa che Google presume che non vi siano restrizioni di scansione.

5xx (server errors)

Dato che il server non è stato in grado di fornire una risposta definitiva alla richiesta robots.txt di Google, Google interpreta temporaneamente gli errori del server 5xx e 429 come se il sito fosse interamente non consentito. Google tenterà di eseguire la scansione del file robots.txt finché non otterrà un codice di stato HTTP che non corrisponda a un errore del server. Un errore 503 (service unavailable) genera ripetizioni abbastanza frequenti. Se il file robots.txt non è raggiungibile per più di 30 giorni, Google utilizzerà l'ultima copia del file memorizzata nella cache. Se non è disponibile, Google presume che non vi siano restrizioni di scansione.

Se devi sospendere temporaneamente la scansione, ti consigliamo di fornire un codice di stato HTTP 503 per ogni URL del sito.

Se Google stabilisce che un sito è configurato in modo errato e restituisce 5xx anziché un codice di stato 404 per le pagine mancanti, tratterà l'errore 5xx restituito da questo sito come errore 404. Ad esempio, se il messaggio di errore in una pagina che restituisce un codice di stato 5xx è "Pagina non trovata", interpreteremo il codice di stato come 404 (not found).

Altri errori 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 considerato come un errore del server.

Memorizzazione nella cache

In genere, Google memorizza nella cache i contenuti del file robots.txt per un massimo di 24 ore, ma può conservarli 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 file robots.txt deve essere un file di testo normale codificato in UTF-8 e le righe devono essere separate da CR, CR/LF o LF.

Google ignora le righe non valide nei file robots.txt, tra cui il carattere Unicode Byte Order Mark (BOM) all'inizio del file robots.txt e utilizza solo righe valide. Ad esempio, se i contenuti scaricati sono HTML anziché regole robots.txt, Google tenterà di analizzare i contenuti ed estrarre le regole, ignorando tutto il resto.

Allo stesso modo, se la codifica dei caratteri del file robots.txt non è UTF-8, Google potrebbe ignorare i caratteri che non fanno parte dell'intervallo UTF-8, rendendo non valide le regole del file robots.txt.

Attualmente Google applica un limite di dimensioni del file robots.txt di 500 kibibyte (KiB). I contenuti che superano questa dimensione massima vengono ignorati. Puoi ridurre le dimensioni del file robots.txt raggruppando le regole che genererebbero un file robots.txt di grandi dimensioni. Ad esempio, posiziona il materiale escluso in una directory separata.

Sintassi

Le righe valide del file robots.txt sono composte da un campo, due punti e un valore. Gli spazi sono facoltativi, ma consigliati per una maggiore leggibilità. Lo spazio all'inizio e alla fine della riga viene ignorato. Per includere un commento, anteponi il carattere #. Tieni presente che tutto ciò che segue il carattere # verrà ignorato. Il formato generale è <field>:<value><#optional-comment>.

Google supporta i seguenti campi:

  • user-agent: identifica a quale crawler si applicano le regole.
  • allow: un percorso dell'URL che può essere sottoposto a scansione.
  • disallow: un percorso dell'URL che non può essere sottoposto a scansione.
  • sitemap: l'URL completo di una Sitemap.

I campi allow e disallow sono anche denominati regole (o istruzioni). Queste sono sempre specificate nel formato rule: [path], dove [path] è facoltativo. Per impostazione predefinita, non esistono limitazioni di scansione per i crawler designati. I crawler ignorano le regole senza un valore [path].

Il valore [path], se specificato, è relativo al percorso principale del sito web da cui è stato recuperato il file robots.txt (utilizzando lo stesso protocollo, numero di porta, nome host e nome di dominio). Il valore del percorso deve iniziare con / per indicare il percorso principale e il valore è sensibile alle maiuscole. Scopri di più sulla corrispondenza degli URL in base ai valori del percorso.

user-agent

La riga user-agent identifica a quale crawler si applicano le regole. Consulta la pagina relativa ai crawler di Google e alle stringhe dello user agent per un elenco completo di stringhe dello user agent da utilizzare nel file robots.txt.

Il valore della riga user-agent è sensibile alle maiuscole.

disallow

La regola disallow specifica i percorsi a cui i crawler non devono accedere dalla riga user-agent con cui la regola disallow è raggruppata. Senza un percorso, i crawler ignorano la regola.

Google non è in grado di indicizzare i contenuti delle pagine di cui non è consentita la scansione, ma può comunque indicizzare l'URL e mostrarlo nei risultati di ricerca senza uno snippet. Scopri come bloccare l'indicizzazione.

Il valore della regola disallow è sensibile alle maiuscole.

Utilizzo:

disallow: [path]

allow

La regola allow specifica i percorsi a cui i crawler designati possono accedere. Quando non sono specificati percorsi, la regola viene ignorata.

Il valore della regola allow è sensibile alle maiuscole.

Utilizzo:

allow: [path]

sitemap

Google, Bing e altri motori di ricerca principali supportano il campo sitemap nel file robots.txt, come definito da sitemaps.org.

Il valore del campo sitemap è sensibile alle maiuscole.

Utilizzo:

sitemap: [absoluteURL]

La riga [absoluteURL] rimanda alla posizione di una Sitemap o di un file indice Sitemap. Deve essere un URL completo, inclusi protocollo e host, e non deve essere codificato tramite URL. L'URL può anche non trovarsi sullo stesso host del file robots.txt. Puoi specificare più campi sitemap. Il campo Sitemap non è associato ad alcun user agent specifico e può essere seguito da tutti i crawler, a patto che sia consentito eseguirne la scansione.

Ad esempio:

user-agent: otherbot
disallow: /kale

sitemap: https://example.com/sitemap.xml
sitemap: https://cdn.example.org/other-sitemap.xml
sitemap: https://ja.example.org/テスト-サイトマップ.xml

Raggruppamento di righe e regole

Puoi raggruppare le regole che si applicano a più user agent ripetendo le righe user-agent per ogni crawler.

Ad esempio:

user-agent: a
disallow: /c

user-agent: b
disallow: /d

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

user-agent: h

In questo esempio sono presenti quattro gruppi di regole distinti:

  • Un gruppo per lo user agent "a".
  • Un gruppo per lo user agent "b".
  • Un gruppo per gli user agent "e" e "f".
  • Un gruppo per lo user agent "h".

Per la descrizione tecnica di un gruppo, consulta la sezione 2.1 del REP.

Ordine di precedenza degli user agent

Solo un gruppo è valido per un determinato crawler. I crawler di Google determinano il gruppo di regole corretto individuando nel file robots.txt il gruppo con lo user agent più specifico corrispondente allo user agent del crawler, mentre gli altri gruppi vengono ignorati. Tutto il testo senza corrispondenza 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 è stato dichiarato più di un gruppo specifico per un user agent, tutte le regole dei gruppi applicabili allo user agent specifico vengono combinate internamente in un unico gruppo. I gruppi specifici di user agent e quelli globali (*) non vengono combinati.

Esempi

Corrispondenza dei campi user-agent

user-agent: googlebot-news
(group 1)

user-agent: *
(group 2)

user-agent: googlebot
(group 3)

Di seguito è riportato il modo in cui i crawler scelgono il gruppo pertinente:

Gruppo seguito per crawler
Googlebot-News googlebot-news segue il gruppo 1, perché è quello più specifico.
Googlebot (Web) googlebot segue il gruppo 3.
Google StoreBot Storebot-Google segue il gruppo 2, perché non esiste un gruppo Storebot-Google specifico.
Googlebot-News (durante la scansione delle immagini) Durante la scansione delle immagini, googlebot-news segue il gruppo 1. googlebot-news non esegue la scansione delle immagini per Google Immagini, pertanto segue solo il gruppo 1.
Otherbot (web) Gli altri crawler di Google seguono il gruppo 2.
Otherbot (News) Gli altri crawler di Google che eseguono la scansione dei contenuti di notizie, ma non vengono identificati come googlebot-news seguono il gruppo 2. Anche se esiste un'occorrenza per un crawler correlato, questa è valida solo in caso di corrispondenza specifica.

Raggruppamento delle regole

Se in un file robots.txt sono presenti più gruppi pertinenti per uno specifico user agent, i crawler di Google uniscono internamente i gruppi. Ad esempio:

user-agent: googlebot-news
disallow: /fish

user-agent: *
disallow: /carrots

user-agent: googlebot-news
disallow: /shrimp

I crawler raggruppano internamente le regole in base allo user agent, ad esempio:

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

user-agent: *
disallow: /carrots

Le regole diverse da allow, disallow e user-agent vengono ignorate dall'analizzatore sintattico robots.txt. Ciò significa che il seguente snippet del file robots.txt viene considerato come un singolo gruppo, pertanto user-agent a e b sono interessati dalla regola disallow: /:

user-agent: a
sitemap: https://example.com/sitemap.xml

user-agent: b
disallow: /

Quando i crawler elaborano le regole del file robots.txt, ignorano la riga sitemap. Ad esempio, questo è il modo in cui i crawler interpretano lo snippet del file robots.txt precedente:

user-agent: a
user-agent: b
disallow: /

Corrispondenza degli URL in base ai valori del percorso

Google utilizza il valore relativo al percorso nelle regole allow e disallow come base per determinare se una regola si applica o meno a un URL specifico in un sito. A tale scopo, confronta la regola con il componente del percorso dell'URL che il crawler sta cercando di recuperare. I caratteri ASCII non a 7 bit in un percorso possono essere inclusi sotto forma di caratteri UTF-8 o caratteri con codifica UTF-8 e segno di percentuale a fungere da carattere di escape in base al documento RFC 3986.

Google, Bing e i più importanti motori di ricerca supportano una serie limitata di caratteri jolly per i valori relativi al percorso. Questi caratteri jolly sono:

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

Nella tabella seguente viene illustrato in che modo i diversi caratteri jolly influiscono sull'analisi:

Esempi di corrispondenze di percorso
/ Corrisponde all'URL principale e a ogni URL di livello inferiore
/* Equivalente a /. Il carattere jolly finale viene ignorato
/$ Corrisponde solo all'URL principale. È consentita la scansione di qualsiasi URL di livello inferiore
/fish

Corrisponde a qualsiasi percorso che inizia con /fish Tieni presente che la corrispondenza è sensibile alle maiuscole.

Corrisponde a:

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

Non corrisponde a:

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

Equivalente a /fish. Il carattere jolly finale viene ignorato

Corrisponde a:

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

Non corrisponde a:

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

Corrisponde a ogni elemento nella cartella /fish/

Corrisponde a:

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

Non corrisponde a:

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

Corrisponde a qualsiasi percorso contenente .php

Corrisponde a:

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

Non corrisponde a:

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

Corrisponde a qualsiasi percorso che termina con .php

Corrisponde a:

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

Non corrisponde a:

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

Corrisponde a qualsiasi percorso contenente /fish e .php nell'ordine indicato

Corrisponde a:

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

Non corrisponde a: /Fish.PHP

Ordine di precedenza per le regole

Nell'individuare le corrispondenze tra le regole del file robots.txt e gli URL, i crawler utilizzano la regola più specifica basata sulla lunghezza del relativo percorso. In caso di regole in conflitto, incluse quelle con caratteri jolly, Google utilizza la regola meno restrittiva.

I seguenti esempi mostrano quale regola applicheranno i crawler di Google a un determinato URL.

Situazioni di esempio
https://example.com/page
allow: /p
disallow: /

Regola applicabile: allow: /p, perché è più specifica.

https://example.com/folder/page
allow: /folder
disallow: /folder

Regola applicabile: allow: /folder, perché, in caso di regole in conflitto, Google utilizza quella meno restrittiva.

https://example.com/page.htm
allow: /page
disallow: /*.htm

Regola applicabile: disallow: /*.htm, perché il percorso della regola è più lungo e corrisponde a più caratteri nell'URL, quindi è più specifico.

https://example.com/page.php5
allow: /page
disallow: /*.ph

Regola applicabile: allow: /page, perché, in caso di regole in conflitto, Google utilizza quella meno restrittiva.

https://example.com/
allow: /$
disallow: /

Regola applicabile: allow: /$, perché è più specifica.

https://example.com/page.htm
allow: /$
disallow: /

Regola applicabile: disallow: /, perché la regola allow si applica solo all'URL principale.