Como escrever um robots.txt: diretivas, correspondência e o que não consegue esconder

Uma instrução de rastreio, nem uma fechadura nem uma borracha

O Google di-lo sem rodeios: o robots.txt não é um mecanismo para manter uma página fora do Google, e uma página proibida no robots.txt pode continuar a ser indexada se outros sites lhe apontarem. O mecanismo vê-se com facilidade depois de enunciado. O Disallow pede a um rastreador bem-comportado que não descarregue o URL. Não diz nada sobre se o endereço pode aparecer num índice, e uma ligação de outro site fornece o suficiente — o próprio URL, mais o texto âncora que lhe aponta — para listar a página sem nunca a descarregar. O resultado é o conhecido resultado de pesquisa com um URL nu, sem título retirado da página nem descrição, exatamente onde o dono do site julgava tê-la removido.

As ferramentas certas dependem do que quer de facto. Para manter uma página fora dos resultados, sirva um noindex — ou uma etiqueta meta robots no cabeçalho do documento, ou um cabeçalho de resposta X-Robots-Tag, que funciona também para ficheiros sem cabeçalho HTML, como os PDF. Para subtrair um conteúdo a toda a gente, ponha-o atrás de autenticação; nada de declarativo num ficheiro de texto público alguma vez restringiu o acesso, e a RFC 9309 di-lo às claras ao chamar ao protocolo um não substituto de medidas reais de segurança. E há uma armadilha de ordem para quem combina as duas: se proibir um URL, o rastreador nunca o descarregará, nunca verá o noindex que lhe acrescentou, e a página pode persistir indefinidamente no índice. Deixe-a rastreável até desaparecer e proíba-a depois, se ainda quiser.

Como funciona a correspondência: prefixos, dois caracteres universais e a regra mais longa

Cada valor de Disallow e Allow é comparado como prefixo do caminho do URL, pelo que Disallow: /admin bloqueia por igual /admin, /admin/, /administrator e /admin-tools. Acrescentar uma barra final estreita ao diretório. Dois caracteres especiais afinam isto: * representa zero ou mais caracteres quaisquer e $ ancora o fim do URL, de modo que Disallow: /*.pdf$ bloqueia todo o URL terminado em .pdf e deixa acessível /report.pdf?download=1, porque a cadeia de consulta vem depois da âncora. Um carácter universal no fim não acrescenta nada: /* é a mesma regra que /. Os caminhos distinguem maiúsculas, pelo que /Admin e /admin são duas regras distintas, embora os nomes das diretivas não distingam.

Quando mais do que uma regra corresponde a um URL, ganha a mais específica, e aqui especificidade não significa nada mais sofisticado do que o comprimento do caminho da regra em octetos. Disallow: /reports/ e Allow: /reports/public/ correspondem ambos a /reports/public/q3.html; o Allow é mais longo, logo o ficheiro é rastreável. Inverta os comprimentos e ganha o Disallow. Se duas regras correspondentes tiverem exatamente o mesmo comprimento, o empate vai para a menos restritiva, ou seja o Allow. A ordem no ficheiro é irrelevante — um Disallow escrito depois de um Allow não o anula, e só isto explica boa parte dos robots.txt que não se comportam como o seu autor os lê. Mais dois limites a conhecer: o Google lê no máximo 500 kibibytes e ignora tudo o que vem depois, e um valor Disallow vazio significa que nada é bloqueado, a forma idiomática de escrever um grupo que permite tudo.

Onde vive o ficheiro e porque anuncia o que queria esconder

A regra de localização é absoluta e não se configura. A RFC 9309 exige que as regras sejam acessíveis num ficheiro chamado /robots.txt, tudo em minúsculas, no caminho de topo do serviço, e o Google acrescenta que se aplicam apenas ao host, protocolo e porta onde o ficheiro está alojado. Leia com atenção, porque as consequências fazem tropeçar sem parar. Um ficheiro em https://example.com/robots.txt não governa nada em http://example.com, nada em https://shop.example.com e nada em https://example.com:8443 — cada um desses endereços é uma origem distinta que precisa do seu próprio ficheiro. Um ficheiro colocado num subdiretório não é lido de todo. E um site atrás de um CDN ou de um proxy inverso vale o que valer o seu encaminhamento: se a plataforma servir o seu próprio robots.txt na raiz, o seu, do lado da aplicação, nunca chega a correr.

Agora a parte sem rodeios. O ficheiro é servido a quem o pedir, não tem autenticação e é de longe a primeira coisa que um scanner automatizado lê. Escrever Disallow: /internal/backup-2019/ não esconde esse diretório: publica a sua existência, o seu caminho exato e o facto de o ter considerado digno de esconder, num documento que convidou a internet inteira a ler. Todas as ferramentas de reconhecimento alguma vez escritas começam aí, exatamente por isso. Se um caminho não pode ser alcançado, ponha-o atrás de autenticação ou tire-o do host público; se apenas não deve ser rastreado, proíba um prefixo pai largo em vez de nomear a folha sensível. E trate o ficheiro como código: guarde-o em controlo de versões, reveja as alterações como qualquer outra implantação e verifique-o após cada migração de plataforma, porque um Disallow: / perdido que chega a produção é a forma mais rápida de retirar um site inteiro da pesquisa e uma das mais lentas de recuperar.

Perguntas frequentes

Posso usar o robots.txt para manter uma página privada fora do Google?

Não, em ambos os sentidos. O Google diz às claras que o robots.txt não é um mecanismo para manter uma página fora do Google, e um URL proibido ligado a partir de qualquer outro site pode continuar listado usando apenas a ligação e o seu texto âncora. Nem a página é privada em qualquer sentido real: o robots.txt é só um pedido, respeitado pelos motores de busca e ignorado por tudo o que tenha interesse em ignorá-lo, e o próprio ficheiro difunde o caminho. Para visibilidade na pesquisa use um noindex, servido como etiqueta meta robots ou como cabeçalho X-Robots-Tag. Para privacidade a sério use autenticação. São dois problemas distintos e o robots.txt não resolve nenhum.

Os subdomínios e http versus https partilham um só robots.txt?

Não. As regras aplicam-se apenas ao host, protocolo e porta exatos que serviram o ficheiro, pelo que https://example.com, http://example.com, https://www.example.com e https://api.example.com são quatro âmbitos distintos que precisam de quatro ficheiros distintos — mesmo que resolvam para o mesmo servidor e a mesma raiz de documentos. É o segundo erro de configuração mais comum, a seguir a colocar o ficheiro num subdiretório, onde nunca é lido. Consequência prática: se redirecionar http para https, o rastreador segue o redirecionamento para descarregar o ficheiro, pelo que a cópia https governa ambos de facto; se não redirecionar, a origem http não tem regras e é rastreada livremente.

Proibi uma página mas ela continua nos resultados. E agora?

É o comportamento esperado, e a correção é inverter a ordem das operações. Retire o Disallow para a página voltar a ser rastreável, acrescente um noindex — etiqueta meta robots ou cabeçalho X-Robots-Tag — e espere que a página seja de novo rastreada e retirada. A abordagem original falhou por circularidade: enquanto o URL está proibido o rastreador nunca o descarrega, logo nunca vê o noindex que lá pôs, e a listagem construída a partir de ligações de entrada persiste indefinidamente. Depois de a página sair do índice, pode repor o Disallow para poupar orçamento de rastreio, embora nessa altura isso costume render muito pouco.