robots.txt: compreender crawl, indexação e erros a evitar

O ficheiro robots.txt é curto, público e capaz de provocar efeitos muito amplos. Uma única regra pode impedir a exploração de uma pasta inteira. Por outro lado, remover uma diretiva não significa que uma página será imediatamente indexada.

Para o utilizar corretamente é essencial distinguir crawl, indexação e controlo de acesso.

Onde fica o robots.txt?

Para um site como:

https://example.com/

o ficheiro encontra-se normalmente na raiz:

https://example.com/robots.txt

É deliberadamente público. Por isso, nunca deve ser utilizado como uma lista de diretórios “secretos” que se pretende proteger.

Estrutura mínima

Um exemplo simples:

User-agent: *
Disallow: /admin-temporario/

User-agent identifica o robô. * representa todos os robôs que aplicam estas regras. Disallow indica um caminho que se pede para não explorar.

Também é possível declarar:

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

Um gerador ajuda com a sintaxe, mas é necessário compreender primeiro o que se pretende realmente bloquear.

Bloquear o crawl não é pedir noindex

Esta é a distinção principal. Se um robô não conseguir explorar uma página, também pode não conseguir ler as diretivas presentes nessa página.

Uma URL bloqueada por robots.txt pode continuar conhecida através de links internos ou externos e, consoante o contexto, pode ainda aparecer de forma limitada num índice.

Se pretende que uma página acessível seja explorada mas não indexada, é necessária outra estratégia, como uma diretiva noindex que o robô possa efetivamente ler.

robots.txt → controlar a exploração
noindex    → pedir para não indexar uma página acessível ao robô

robots.txt não é um mecanismo de segurança

Se /faturas-privadas/ contiver dados sensíveis, escrever:

Disallow: /faturas-privadas/

não impede um utilizador de abrir a URL se o servidor permitir o acesso. Para proteger conteúdo use autenticação, autorização do lado do servidor, controlo de acesso ou redes privadas quando adequado.

SEO e segurança resolvem aqui problemas diferentes.

Atenção a regras demasiado amplas

Esta regra é particularmente perigosa:

User-agent: *
Disallow: /

O / representa a raiz, pelo que a diretiva pede para não explorar nada no site. Pode fazer sentido num ambiente temporário, mas em produção pode ser um erro grave.

Antes de publicar, leia cada regra como se fosse o robô e confirme exatamente que caminhos correspondem à diretiva.

Não bloqueie recursos necessários ao rendering

Motores modernos podem precisar de CSS, JavaScript e imagens para interpretar corretamente uma página. Bloquear indiscriminadamente /assets/, /scripts/ ou /styles/ pode prejudicar a compreensão do conteúdo se esses ficheiros forem necessários ao rendering.

O objetivo não é reduzir o número de ficheiros explorados a qualquer custo, mas evitar crawl desnecessário sem impedir a interpretação do conteúdo principal.

Para que serve Allow?

Uma regra Allow pode criar uma exceção dentro de uma zona mais ampla bloqueada:

Disallow: /private/
Allow: /private/guia-publico.html

Quando as regras se tornam complexas, devem ser testadas em vez de adivinhadas. Em muitos sites pequenos, um ficheiro simples é mais seguro e mais fácil de manter.

Parâmetros e muitas variantes de URL

Um catálogo pode gerar URLs como:

/catalogo?sort=price
/catalogo?sort=name
/catalogo?color=blue
/catalogo?page=2

Bloquear todas as variantes com robots.txt não é automaticamente a solução. Primeiro determine quais têm valor para os utilizadores, quais devem ser indexáveis, qual é a URL canonical e se os links internos estão a produzir variantes em excesso.

Sitemap e robots.txt devem ser coerentes

O sitemap assinala principalmente as URLs que pretende tornar fáceis de descobrir; robots.txt define restrições de exploração. Colocar uma URL no sitemap e bloqueá-la ao mesmo tempo envia sinais contraditórios.

Verificar antes de publicar

Antes de alterar o ficheiro:

1. identifique as zonas realmente afetadas;
2. confirme os caminhos exatos;
3. evite Disallow: / sem intenção explícita;
4. verifique que CSS e JavaScript necessários continuam acessíveis;
5. confirme a coerência com sitemap e canonical;
6. não coloque dados confidenciais no ficheiro;
7. teste as URLs importantes.

A pergunta final é simples: pretende impedir o acesso, a exploração ou a indexação? Estes três objetivos exigem mecanismos diferentes.