robots.txt e sitemaps

Permissão não é o mesmo que exclusão

O robots.txt retira a permissão de baixar uma URL, e nada além disso. O Google diz sem rodeios que ele não é um mecanismo para manter uma página fora da Busca. As duas ideias são confundidas o tempo todo, e essa confusão produz uma falha específica e bem visível.

Uma URL bloqueada para a qual outros sites apontam ainda pode ser indexada. O Google sabe que o endereço existe porque alguém o linkou; ele apenas não consegue ver o que há ali. Então pode listar a URL sem descrição nenhuma — o pior dos dois mundos, já que a página fica pública nos resultados enquanto você não controla como ela aparece.

Ler e escrever o arquivo

O arquivo fica na raiz de um host e vale só para aquele host e aquele protocolo. As regras são agrupadas por user-agent, e um rastreador obedece ao único grupo mais específico que corresponde a ele — não a todo grupo que poderia corresponder. Dentro de um grupo, o Google resolve conflitos pela regra mais específica, não pela ordem.

User-agent: *
Disallow: /admin/
Disallow: /*.pdf$
Allow: /admin/public/

User-agent: Googlebot
Disallow: /drafts/

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

Dois detalhes desse exemplo concentram quase toda a confusão. A linha Allow é mais específica que o Disallow acima dela, então /admin/public/ continua acessível. E assim que existe um grupo Googlebot, o Googlebot obedece só a esse grupo — o grupo coringa deixa de valer para ele, de modo que aqui /admin/ fica acessível ao Googlebot. Quase nunca é o que o autor quis dizer.

• Bloquear um caminho não remove URLs já indexadas; apenas interrompe os downloads futuros.
• A diretiva Sitemap independe de qualquer grupo de user-agent e pode aparecer em qualquer ponto do arquivo.
• Um 5xx no próprio robots.txt pode levar um rastreador a se afastar do host inteiro, então sirva-o de algo confiável.

Onde uma regra do robots causa dano longe de si mesma

Os erros de robots.txt mais caros não são as páginas que você quis bloquear. São os recursos de que uma página precisa para renderizar. Os buscadores renderizam páginas antes de indexá-las, e renderizar puxa scripts, estilos e respostas de API.

Bloqueie um caminho de scripts ou uma rota de API e o rastreador continua baixando o HTML perfeitamente. Depois ele renderiza uma página quase vazia e indexa uma página quase vazia. Nenhum relatório vai dizer que a página estava bloqueada, porque a página não estava — só o que ela precisava.

Um sitemap é uma sugestão, não uma fila

Sitemaps ajudam na descoberta exatamente onde o linkeamento é mais fraco: sites grandes, sites recém-nascidos com poucos links de entrada e sites cheios de mídia sem texto de âncora natural. O Google afirma sem rodeios que listar uma URL não garante rastreamento nem indexação.

A própria orientação do Google é que um site menor e bem interligado pode não precisar de nenhum, porque o rastreador acha tudo seguindo links. Vale levar isso a sério antes de construir infraestrutura de sitemap para resolver um problema que o linkeamento interno resolveria melhor.

Quais tags são lidas, ignoradas ou postas em dúvida

É aqui que se desperdiça a maior parte do esforço com sitemaps. Duas das quatro tags comuns não fazem absolutamente nada, e uma terceira pode trabalhar contra você.

A condição do lastmod é a que morde. Se o seu build carimba cada URL com o horário do deploy, todo valor é ao mesmo tempo falso e fácil de desmentir: a página não mudou, e o buscador consegue perceber. Quando ele para de confiar no campo, para de usá-lo, e isso deixa você pior do que não enviar lastmod algum. Emita-o só para mudanças reais no conteúdo principal, e prefira omiti-lo a inventá-lo.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/guides/indexing/</loc>
    <lastmod>2026-06-14</lastmod>
  </url>
</urlset>

Escolher o instrumento certo

Quase toda pergunta desta área se resolve assim que você separa três tarefas que parecem iguais e não são.