Especificações de robots.txt

Resumo

Este documento detalha como o Google lida com o arquivo robots.txt, que permite controlar como os rastreadores de sites do Google rastreiam e indexam sites de acesso público.

Linguagem dos requisitos

As palavras-chave "DEVE", "NÃO DEVE", "TEM QUE", "PRECISA", "NÃO PRECISA", "DEVERIA", "NÃO DEVERIA", "RECOMENDADO", "PODE" e "OPCIONAL" neste documento devem ser interpretadas conforme descrito em RFC 2119 (em inglês).

Definições básicas

Definições
Rastreador Um rastreador é um serviço ou agente que rastreia sites. De modo geral, um rastreador acessa de forma automática e recursiva URLs conhecidos de um host que expõe conteúdo que pode ser acessado com navegadores padrão da Web. À medida que novos URLs são encontrados (por vários meios, como a partir de links em páginas existentes e rastreadas ou de arquivos de Sitemap), eles também são rastreados da mesma forma.
User agent Um meio de identificar um rastreador específico ou um conjunto de rastreadores.
Diretivas A lista de diretrizes aplicáveis a um rastreador ou grupo de rastreadores definidos no arquivo robots.txt.
URL Uniform Resource Locators, conforme definido no RFC 1738 (em inglês).
Específico do Google Estes elementos são específicos da implementação do robots.txt por parte do Google e podem não ser relevantes para outras partes.

Aplicabilidade

As diretrizes estabelecidas neste documento são seguidas por todos os rastreadores automáticos do Google. Quando um agente acessar URLs em nome de um usuário (por exemplo, para tradução, feeds assinados manualmente, análise de malware etc.), essas diretrizes não precisarão ser seguidas.

Localização do arquivo e intervalo de validade

O arquivo robots.txt deve estar no diretório de nível superior do host, podendo ser acessado por meio do protocolo e número de porta adequado. Geralmente, os protocolos aceitos para o robots.txt (e para o rastreamento de sites) são "http" e "https". Para http e https, o arquivo robots.txt é buscado por meio de uma solicitação GET não condicional HTTP.

específicos do Google: o Google também aceita e segue arquivos robots.txt para sites FTP. Os arquivos robots.txt baseados em FTP são acessados por meio do protocolo FTP usando um login anônimo.

As diretivas listadas no arquivo robots.txt se aplicam somente ao host, ao protocolo e ao número de porta em que o arquivo está hospedado.

Exemplos de URLs robots.txt válidos

Exemplos de URLs robots.txt
http://example.com/robots.txt Válido para:
  • http://example.com/
  • http://example.com/folder/file
Inválido para:
  • http://other.example.com/
  • https://example.com/
  • http://example.com:8181/
http://www.example.com/robots.txt

Válido para: http://www.example.com/

Inválido para:

  • http://example.com/
  • http://shop.www.example.com/
  • http://www.shop.example.com/
http://example.com/folder/robots.txt Não é um arquivo robots.txt válido. Os rastreadores não procurarão arquivos robots.txt em subdiretórios.
http://www.müller.eu/robots.txt Válido para:
  • http://www.müller.eu/
  • http://www.xn--mller-kva.eu/

Inválido para: http://www.muller.eu/

ftp://example.com/robots.txt

Válido para: ftp://example.com/

Inválido para: http://example.com/

Específicos do Google: usamos o robots.txt para recursos de FTP.

http://212.96.82.21/robots.txt

Válido para: http://212.96.82.21/

Inválido para: http://example.com/ (mesmo se hospedado em 212.96.82.21)

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

Válido para:

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

Inválido para: http://example.com:81/

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

Válido para: http://example.com:8181/

Inválido para: http://example.com/

Como lidar com códigos de resultado HTTP

Em geral, há três resultados diferentes quando os arquivos robots.txt são buscados:

  • permissão total: odo o conteúdo pode ser rastreado.
  • proibição total: nenhum conteúdo pode ser rastreado.
  • permissão condicional: as diretivas no robots.txt determinam a capacidade de rastrear determinado conteúdo.
Como lidar com códigos de resultado HTTP
2xx (bem-sucedido) Códigos de resultado HTTP que sinalizam resultado bem-sucedido em uma "permissão condicional" de rastreamento.
3xx (redirecionamento) Geralmente, os redirecionamentos serão seguidos até que um resultado válido possa ser encontrado (ou que um loop seja reconhecido). Um número limitado de saltos de redirecionamento será acompanhado (o RFC 1945 para HTTP/1.0 permite até cinco saltos) e interrompido, e o resultado será tratado como um 404. A manipulação de redirecionamentos de robots.txt para URLs não permitidos é indefinida e não é recomendada. A manipulação de redirecionamentos lógicos para o arquivo robots.txt com base no conteúdo HTML que retorna 2xx (frames, JavaScript ou redirecionamentos do tipo meta-atualização) é indefinida e não é recomendada.
4xx (erros de cliente) O Google trata todos os erros 4xx da mesma forma e presume que não existe um arquivo robots.txt válido. Ele presume que não há restrições. Isso significa uma "permissão total" para o rastreamento
5xx (erro do servidor)

Erros de servidor são vistos como erros temporários que resultam na "proibição total" do rastreamento. A solicitação é repetida até que um código de resultado HTTP sem erro de servidor seja atingido. Um erro 503 (Serviço indisponível) resultará em novas tentativas frequentes. Para suspender temporariamente o rastreamento, é recomendado veicular um código de resultado HTTP 503. A manipulação de um erro permanente do servidor é indefinida.

Específico do Google: se for possível determinar que um site está incorretamente configurado para retornar 5xx em vez do resultado 404 para páginas ausentes, o erro 5xx desse site será tratado como um resultado 404.

Solicitações falhas ou dados incompletos A manipulação de um arquivo robots.txt que não pode ser buscado devido a problemas de DNS ou de rede, como tempos limite, respostas inválidas, conexões redefinidas / interrompidas, erros de agrupamento de HTTP etc., é indefinida.
Armazenando em cache Geralmente, uma solicitação robots.txt é armazenada em cache por até um dia, mas pode ser armazenada por mais tempo nos casos em que não é possível atualizar a versão em cache (por exemplo, devido a tempo limite ou erros 5xx). A resposta em cache pode ser compartilhada por diferentes rastreadores. O Google pode aumentar ou diminuir o ciclo de vida do cache com base em cabeçalhos HTTP do tipo Controle de cache de período máximo.

Formato do arquivo

O formato de arquivo esperado é o texto simples codificado em UTF-8. O arquivo consiste de registros (linhas) separados por CR, CR/LF ou LF.

Somente os registros válidos serão considerados, todos os outros conteúdos serão ignorados. Por exemplo, se o documento resultante for uma página HTML, somente as linhas de texto válidas serão levadas em consideração. O resto será descartado sem envio de aviso ou erro.

Se a adoção de uma codificação de caracteres resultar no uso de caracteres que não fazem parte de um subconjunto de UTF-8, isso poderá gerar erros na análise dos conteúdos do arquivo.

Um Unicode opcional BOM (marca de ordem de byte, na sigla em inglês) no início do arquivo robots.txt será ignorado.

Cada registro consiste de um campo, um sinal de dois pontos e um valor. Os espaços são opcionais (mas são recomendados para melhorar a legibilidade). Os comentários podem ser incluídos em qualquer local no arquivo usando o caractere "#". Todo o conteúdo após o início de um comentário até ao final do registro é tratado como um comentário e ignorado. O formato geral é <field>:<value><#optional-comment>. O espaço em branco no início e no final do registro é ignorado.

O elemento <field> é indiferente a maiúsculas. O elemento <value> pode diferenciar maiúsculas e minúsculas, dependendo do elemento <field>.

A manipulação de elementos <field> com erros simples / de digitação (por exemplo, "useragent" em vez de "user agent") é indefinida e pode ser interpretada como uma diretiva correta por alguns user agents.

Um tamanho máximo de arquivo pode ser imposto pelo rastreador. Conteúdos acima do tamanho máximo do arquivo podem ser ignorados. Atualmente, o Google impõe um limite de tamanho de 500 kilobytes (KB).

Sintaxe / definição formal

Esta é uma descrição semelhante à de Backus-Naur Form (BNF) que usa as convenções de RFC 822, exceto pelo fato de "|" ser usada para designar alternativas. As literais são expressas com "", os parênteses "(" e ")" são usados para agrupar elementos, os elementos opcionais são dispostos em [colchetes], e os elementos podem ser precedidos por <n>* para designar n ou mais repetições do seguinte elemento (n tem como padrão 0).

robotstxt = *entries
entries = *( ( <1>*startgroupline
  *(groupmemberline | nongroupline | comment)
  | nongroupline
  | comment) )
startgroupline = [LWS] "user-agent" [LWS] ":" [LWS] agentvalue [comment] EOL
groupmemberline = [LWS] (
  pathmemberfield [LWS] ":" [LWS] pathvalue
  | othermemberfield [LWS] ":" [LWS] textvalue) [comment] EOL
nongroupline = [LWS] (
  urlnongroupfield [LWS] ":" [LWS] urlvalue
  | othernongroupfield [LWS] ":" [LWS] textvalue) [comment] EOL
comment = [LWS] "#" *anychar
agentvalue = textvalue

pathmemberfield = "disallow" | "allow"
othermemberfield = ()
urlnongroupfield = "sitemap"
othernongroupfield = ()

pathvalue = "/" path
urlvalue = absoluteURI
textvalue = *(valuechar | SP)
valuechar = <any UTF-8 character except ("#" CTL)>
anychar = <any UTF-8 character except CTL>
EOL = CR | LF | (CR LF)

A sintaxe de "absoluteURI", "CTL", "CR", "LF", "LWS" é definida no RFC 1945. A sintaxe de "path" é definida no RFC 1808.

Agrupamento de registros

Os registros são categorizados em diferentes tipos, com base no tipo de elemento <field>:

  • start-of-group
  • group-member
  • non-group

Todos os registros de group-member (membro de grupo) após um registro de start-of-group (início de grupo) até o próximo registro de start-of-group são tratados como um grupo de registros. O único elemento de campo start-of-group é user-agent. Várias linhas start-of-group diretamente em sequência seguirão os registros group-member, seguindo a linha start-of-group final. Todos os registros group-member sem um registro start-of-group anterior serão ignorados. Todos os registros que não pertencem a grupos serão válidos independentemente de todos os grupos.

Os elementos <field> válidos, que serão detalhados individualmente mais adiante neste documento, são:

  • user-agent (início do grupo)
  • disallow (válido somente como um registro de group-member)
  • allow (válido somente como um registro de group-member)
  • sitemap (registro não pertencente a grupo)

Todos os outros elementos <field> podem ser ignorados.

O elemento start-of-group user-agent é usado para especificar para qual rastreador o grupo é válido. Somente um grupo de registros é válido para um determinado rastreador. A ordem de precedência será discutida mais adiante neste documento.

Exemplo de grupos:

user-agent: a
disallow: /c

user-agent: b
disallow: /d

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

Três grupos distintos estão especificados, um para "a", outro para "b", bem como um para "e" e "f". Cada grupo tem seu próprio registro de group-member. O uso do espaço em branco (uma linha vazia) para melhorar a legibilidade é opcional.

Ordem de precedência para user agents

Somente um grupo de registros de group-member é válido para um determinado rastreador. O rastreador tem de determinar o grupo de registros correto localizando o grupo com o user agent mais específico que ainda corresponde. Todos os outros grupos de registros são ignorados pelo rastreador. O user agent não distingue maiúsculas e minúsculas. Todo o texto não correspondente é ignorado (por exemplo, googlebot/1.2 e googlebot* são equivalentes a googlebot). A ordem dos grupos no arquivo robots.txt é irrelevante.

Exemplo

No seguinte arquivo robots.txt:

user-agent: googlebot-news
(group 1)

user-agent: *
(group 2)

user-agent: googlebot
(group 3)

Esta é a forma como os rastreadores escolheriam o grupo relevante:

Grupo de registro seguido de acordo com o rastreador
Googlebot News O grupo de registro seguido é o grupo 1. Somente o grupo mais específico é seguido, todos os demais são ignorados.
Googlebot (Web) O grupo de registro seguido é o grupo 3.
Googlebot Images O grupo de registro seguido é o grupo 3. Não há um grupo googlebot-images específico, então o grupo mais genérico é seguido.
Googlebot Notícias (ao rastrear imagens) >O grupo de registro seguido é o grupo 1. Essas imagens são rastreadas pelo Googlebot News e para ele, portanto, somente o grupo Googlebot News é seguido.
Otherbot (Web) O grupo de registro seguido é o grupo 2.
Otherbot (Notícias) O grupo de registro seguido é o grupo 2. Mesmo que haja uma entrada para um rastreador relacionado, ela só será válida se for especificamente correspondente.

Veja também Rastreadores do Google e strings user agent.

Registros group-member

Somente os tipos de registro de group-member gerais e específicos do Google são abordados nesta seção. Esses tipos de registro também são chamados de "diretivas" para os rastreadores. Essas diretivas estão especificadas no formulário de directive: [path], em que [path] é opcional. Por padrão, não há restrições para os rastreadores designados. As diretivas sem um [path] são ignoradas.

O valor [path], se especificado, relaciona-se à raiz do site para o qual o arquivo robots.txt foi buscado (usando o mesmo protocolo, número de porta, nomes de host e de domínio). O valor do caminho precisa começar com "/" para designar a raiz. O caminho faz distinção de maiúsculas e minúsculas. Mais informações podem ser encontradas na seção "Correspondência de URLs com base em valores de caminho" abaixo.

disallow

A diretiva disallow especifica caminhos que não devem ser acessados pelos rastreadores designados. Quando nenhum caminho é especificado, a diretiva é ignorada.

Uso:

disallow: [path]

allow

A diretiva allow especifica caminhos que podem ser acessados pelos rastreadores designados. Quando nenhum caminho é especificado, a diretiva é ignorada.

Uso:

allow: [path]

Correspondência de URLs com base em valores de caminho

O valor do caminho é usado como base para determinar se uma regra se aplica a um URL específico em um site. Com a exceção de caracteres curinga, o caminho é usado para combinar o início de um URL (e quaisquer URLs válidos que começam com o mesmo caminho). Caracteres ASCII que não contêm sete bits em um caminho podem ser incluídos como caracteres UTF-8 ou como caracteres codificados UTF-8 com porcentagem de escape, de acordo com o RFC 3986.

Google, Bing, Yahoo e Ask são compatíveis com uma forma limitada de "caracteres curinga" para os valores de caminho. São elas:

  • * designa 0 ou mais instâncias de qualquer caractere válido.
  • $ designa o final do URL.
Exemplo de correspondências de caminho
/ Corresponde à raiz e a qualquer URL de nível mais baixo
/* Equivalente a /. O caractere curinga delimitador é ignorado.
/fish

Correspondências:

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

Sem correspondência:

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

Equivalente a /fish. O caractere curinga delimitador é ignorado.

Correspondências:

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

Sem correspondência:

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

A barra delimitadora significa que isso corresponde a qualquer item nesta pasta.

Correspondências:

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

Sem correspondência:

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

Correspondências:

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

Sem correspondência:

  • / (mesmo se mapear para /index.php)
  • /windows.PHP
/*.php$

Correspondências:

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

Sem correspondência:

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

Correspondências:

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

Sem correspondência: /Fish.PHP

Registros non-group-member compatíveis com o Google

Sitemap

Com suporte no Google, Ask, Bing e Yahoo, definidos em sitemaps.org.

Uso:

sitemap: [absoluteURL]

[absoluteURL] aponta para um sitemap, arquivo de índice de sitemap ou URL equivalente. O URL não precisa estar no mesmo host que o arquivo robots.txt. Várias entradas de sitemap podem existir. Como registros non-group-member, elas não estão vinculadas a user agents específicos e podem ser seguidas por todos os rastreadores, contanto que não estejam proibidas.

Ordem de precedência para registros non-group-member

Em um nível de group-member, em especial para diretivas allow e disallow, a regra mais específica baseada no tamanho da entrada [path] se sobrepõe à regra menos específica (mais curta). A ordem de precedência para as regras com caracteres curinga é indefinida.

Situações de exemplo
http://example.com/page

Permitir: /p

Proibir: /

Veredito: permitir

http://example.com/folder/page

Permitir: /folder

Proibir: /folder

Veredito: permitir

http://example.com/page.htm

Permitir: /page

Proibir: /*.htm

Veredito: indefinido

http://example.com/

Permitir: /$

Proibir: /

Veredito: permitir

http://example.com/page.htm

Permitir: /$

Proibir: /

Veredito: proibir

Enviar comentários sobre…