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.

Voltar ao início

Linguagem dos requisitos

As palavras-chave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" no original deste documento devem ser interpretadas conforme descrito em RFC 2119 (em inglês).

Voltar ao início

Definições básicas

  • rastreador: um rastreador é um serviço ou um agente que rastreia sites. De modo geral, um rastreador acessa automática e recursivamente 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 do 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 um grupo de rastreadores estabelecidos no arquivo robots.txt.
  • URL: Uniform Resource Locator, conforme definido na RFC 1738.
  • específicos do Google: esses elementos são específicos para a implementação do robots.txt por parte do Google e podem não ser relevantes para outras partes.

Voltar ao início

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.

Voltar ao início

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 HTTP GET não condicional.

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 no qual o arquivo está hospedado.

Observação: o URL do arquivo robots.txt faz distinção entre maiúsculas e minúsculas, como outros URLs.

Voltar ao início

Exemplos de URLs robots.txt válidos:

URL robots.txtÉ válido para Não é válido paraComentários
http://example.com/robots.txt http://example.com/
http://example.com/folder/file
http://other.example.com/
https://example.com/
http://example.com:8181/
Este é o caso geral. Não é válido para outros subdomínios, protocolos ou números de porta. É válido para todos os arquivos em todos os subdiretórios no mesmo host, protocolo e número de porta.
http://www.example.com/robots.txt http://www.example.com/ http://example.com/
http://shop.www.example.com/
http://www.shop.example.com/
Um robots.txt em um subdomínio é válido somente para esse subdomínio.
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 http://www.müller.eu/
http://www.xn--mller-kva.eu/
http://www.muller.eu/ Os IDNs equivalem a suas versões punycode. Veja também RFC 3492.
ftp://example.com/robots.txt ftp://example.com/ http://example.com/ Específicos do Google: usamos o robots.txt para recursos de FTP.
http://212.96.82.21/robots.txt http://212.96.82.21/ http://example.com/ (mesmo se hospedado em 212.96.82.21) Um robots.txt com endereço IP como nome de host só será válido para o rastreamento desse endereço IP como nome do host. Ele não será válido automaticamente para todos os sites hospedados nesse endereço IP (embora seja possível que o arquivo robots.txt seja compartilhado, caso em que ele também estaria disponível no nome do host compartilhado).
http://example.com:80/robots.txt http://example.com:80/
http://example.com/
http://example.com:81/ Os números de porta padrão (80 para http, 443 para https e 21 para ftp) são equivalentes aos seus nomes de host padrão. Veja também [portnumbers].
http://example.com:8181/robots.txt http://example.com:8181/ http://example.com/ Arquivos robots.txt em números de porta não padrão são válidos somente para conteúdo disponibilizado por meio desses números de porta.

Voltar ao início

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: todo 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.
2xx (bem-sucedido)
Códigos de resultado HTTP que sinalizam resultado bem-sucedido em uma "permissão condicional" de rastreamento.
3xx (redirecionamento)
Os redirecionamentos geralmente serão seguidos até que um resultado válido possa ser encontrado (ou 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. O manuseio de redirecionamentos robots.txt para URLs não permitidos é indefinido e não é recomendado. O manuseio 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) é indefinido e não é recomendado.
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. Observação: isso inclui códigos de resultado HTTP 401 "Não autorizado" e 403 "Proibido".
5xx (erro do servidor)
Erros do 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 do servidor seja atingido. Um erro 503 (serviço indisponível) resultará em novas tentativas frequentes. Para suspender temporariamente o rastreamento, recomenda-se veicular um código de resultado HTTP 503. A manipulação de um erro permanente do servidor é indefinida.

Específicos do Google: se for possível determinar que um site foi configurado incorretamente de modo a retornar resultados 5xx em vez do resultado 404 para páginas ausentes, o erro 5xx desse site será tratado como um resultado 404.
Solicitações malsucedidas 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 de espera, respostas inválidas, conexões redefinidas/interrompidas, erros de agrupamento de HTTP etc. é indefinida.
Cache
Uma solicitação robots.txt geralmente é armazenada em cache por até um dia, mas pode ser armazenada por mais tempo em situações nas quais a atualização da versão em cache não é possível (por exemplo, devido a limites de tempo ou erros 5xx). A resposta em cache pode ser compartilhada por diferentes rastreadores. O Google pode aumentar ou diminuir a duração do cache baseado em cabeçalhos HTTP Cache-Control de período máximo.

Voltar ao início

Formato de 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> diferencia maiúsculas e minúsculas. O elemento <value> pode diferenciar maiúsculas e minúsculas, dependendo do elemento <field>.

A manipulação de elementos <field> com erros simples/erros de digitação (por exemplo, "useragent" em vez de "user agent") é indefinida e pode ser interpretada como uma diretiva correta por parte de 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 KB.

Voltar ao início

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 para "absoluteURI", "CTL", "CR", "LF", "LWS" é definida no RFC 1945. A sintaxe para "path" é definida no RFC 1808 .

Voltar ao início

Agrupamento de registros

Os registros são classificados 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 grupos)
    • 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.

      Voltar ao início

      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)
      

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

      Nome do rastreadorGrupo de registro seguido Comentários
      Googlebot-Google Notícias (grupo 1) Somente o grupo mais específico é seguido, todos os outros são ignorados.
      Googlebot (Web) (grupo 3) 
      Googlebot Images (grupo 3) Não há um grupo googlebot-images específico, de modo que o grupo mais genérico é seguido.
      Googlebot Notícias (ao rastrear imagens) (grupo 1) Essas imagens são rastreadas pelo Googlebot Notícias e para ele, portanto, somente o grupo Googlebot Notícias é seguido.
      Otherbot (Web)(grupo 2) 
      Otherbot (Notícias)(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

      Voltar ao início

      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 são também chamados de "diretivas" para os rastreadores. Essas diretivas estão especificadas na forma 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 domínio). O valor do caminho deve começar com "/" para designar a raiz. Se um caminho sem uma barra de início for encontrado, será possível supor que ela está lá. 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]
      

      Voltar ao início

      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.

      Observação: Os URLs "AJAX-Crawling" precisam ser especificados em suas versões rastreadas. Veja também nossa documentação sobre Como tornar os aplicativos AJAX rastreáveis.

      Google, Bing, Yahoo e Ask oferecem suporte a uma forma limitada de "caracteres curinga" para os valores de caminho. Estes são:

      1. * designa 0 ou mais instâncias de qualquer caractere válido
      2. $ designa o final do URL

      Exemplo de correspondências de caminho

      [path]Resultados correspondentes Não correspondeComentários
      /qualquer URL válido  Corresponde à raiz e a qualquer URL de nível mais baixo
      /*equivalente a / equivalente a / Equivalente a "/" -- o caractere curinga delimitador é ignorado.
      /fish/fish
      /fish.html
      /fish/salmon.html
      /fishheads
      /fishheads/yummy.html
      /fish.php?id=anything
      /Fish.asp
      /catfish
      /?id=fish
      Combinação que diferencia maiúsculas e minúsculas
      /fish*/fish
      /fish.html
      /fish/salmon.html
      /fishheads
      /fishheads/yummy.html
      /fish.php?id=anything
      /Fish.asp
      /catfish
      /?id=fish
      Equivalente a "/fish" -- o caractere curinga delimitador é ignorado.
      /fish//fish/
      /fish/?id=anything
      /fish/salmon.htm
      /fish
      /fish.html
      /Fish/Salmon.asp
      A barra delimitadora significa que isso corresponde a qualquer coisa nesta pasta.
      fish/equivalente a /fish/ equivalente a /fish/ equivalente a /fish/
      /*.php/filename.php
      /folder/filename.php
      /folder/filename.php?parameters
      /folder/any.php.file.html
      /filename.php/
      / (mesmo se mapear para /index.php)
      /windows.PHP
       
      /*.php$/filename.php
      /folder/filename.php
      /filename.php?parameters
      /filename.php/
      /filename.php5
      /windows.PHP
       
      /fish*.php/fish.php
      /fishheads/catfish.php?parameters
      /Fish.PHP  

      Voltar ao início

      Registros non-group-member com suporte no 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.

      Voltar ao início

      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:

      URLallow:disallow:Veredicto Comentários
      http://example.com/page /p /permitir 
      http://example.com/folder/page /folder/ /folderpermitir 
      http://example.com/page.htm /page /*.htmindefinido 
      http://example.com/ /$ /permitir 
      http://example.com/page.htm /$ /proibir 

      Voltar ao início