Como validar sitemap e robots.txt de um site criado por IA

Um site multipágina criado por IA pode chegar ao deploy com um sitemap.xml copiado do template e um robots.txt que ainda bloqueia tudo. Também pode acontecer o inverso: os arquivos parecem corretos na fonte, mas ficaram fora de public/ ou apontam para o domínio temporário.

Validar sitemap e robots.txt é conferir três coisas ao mesmo tempo: quais URLs o site apresenta para descoberta, quais caminhos permite rastrear e quais arquivos realmente chegaram à URL pública.

Este guia mostra como fazer essa revisão sem confundir rastreamento com indexação e sem usar robots.txt como mecanismo de privacidade.

Entenda o papel de cada arquivo

O sitemap e o robots.txt conversam com crawlers, mas resolvem problemas diferentes.

A documentação do Google sobre sitemaps trata o arquivo como uma forma de informar páginas e arquivos importantes. Enviar um sitemap é uma pista, não uma garantia de rastreamento, indexação ou posição.

Já o guia de robots.txt descreve regras para controlar acesso de crawlers a caminhos. Bloquear um caminho não o transforma em privado. Uma URL ainda pode ser descoberta por links, e qualquer pessoa que conheça o endereço pode tentar abri-lo.

Para conteúdo confidencial, use autenticação ou remova o arquivo da publicação.

Comece pela lista de rotas autorizadas

Antes de gerar arquivos, inventarie o que a versão atual realmente publica:

domínio oficial:
versão ou commit:
pasta publicável:
rotas públicas:
rotas removidas:
rotas de campanha temporárias:
arquivos que não são páginas:
áreas que exigem controle de acesso:

Compare essa lista com a saída da build. Em um site estático, procure os documentos HTML e entenda como o hosting resolve pastas e arquivos. Não inclua uma rota apenas porque o agente a mencionou no briefing; ela precisa existir no pacote final.

O inventário também define o escopo. Uma landing de uma página pode funcionar sem sitemap. Um catálogo, documentação ou site institucional com várias rotas ganha mais valor com uma lista atualizada.

Monte um sitemap com URLs canônicas

Um sitemap XML básico pode ser assim:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.exemplo.com/</loc>
  </url>
  <url>
    <loc>https://www.exemplo.com/servicos/</loc>
  </url>
</urlset>

Use URLs absolutas do domínio oficial. Inclua páginas canônicas que o site pretende tornar descobertas. Remova:

• URLs de preview ou localhost;
• páginas apagadas ou que retornam erro;
• duplicatas com parâmetros descartáveis;
• rotas bloqueadas para rastreamento;
• páginas com noindex intencional;
• arquivos que não representam conteúdo relevante para o sitemap escolhido.

Se uma página declara canonical para outro endereço, o sitemap deve preferir esse destino. O guia de revisão de canonical detalha como alinhar domínio, rotas e links internos.

Use lastmod somente com dado confiável

O protocolo permite informar a última modificação. Não preencha todas as URLs com a hora da build se o conteúdo não mudou. Um valor impreciso vira ruído operacional.

Quando a origem possui data confiável por página, use o formato aceito pelo protocolo. Quando não possui, omitir é melhor que fabricar.

Divida somente quando houver necessidade

Sites pequenos não precisam de índice de sitemaps nem de automação complexa. Comece com um arquivo simples e reproduzível. Se o projeto crescer além dos limites do formato, siga a orientação oficial para criar e enviar sitemaps e passe a gerar múltiplos arquivos com um índice.

Escreva robots.txt como política de rastreamento

O arquivo fica na raiz do host:

https://www.exemplo.com/robots.txt

Uma configuração simples que permite rastreamento e aponta o sitemap pode ser:

User-agent: *
Allow: /

Sitemap: https://www.exemplo.com/sitemap.xml

Para bloquear um caminho de um site público:

User-agent: *
Disallow: /rascunhos/

Antes de adicionar a regra, pergunte por que o caminho existe na publicação. Se contém informação privada, o conserto não é avisar crawlers para não entrar. O conserto é remover o conteúdo público ou protegê-lo adequadamente.

Evite regras amplas copiadas de homologação:

User-agent: *
Disallow: /

Esse bloqueio pode ser intencional em um ambiente de teste e desastroso quando segue para o domínio de produção.

Faça os arquivos concordarem

Uma boa revisão procura contradições entre sitemap, robots, canonical, metadata e respostas HTTP.

Nem toda divergência é automaticamente inválida, mas cada uma exige uma justificativa registrada. Não peça ao agente para “fazer os arquivos passarem” removendo regras sem entender a política.

Confira a fonte e a build

Localize onde os arquivos nascem. Eles podem estar em uma pasta pública, ser copiados por um framework ou gerados durante a build.

Depois de gerar a saída, confirme:

find dist -maxdepth 2 -type f \
  \( -name 'robots.txt' -o -name 'sitemap*.xml' -o -name '*.html' \) \
  -print

Abra os dois arquivos e verifique:

• sintaxe e codificação;
• domínio e protocolo;
• rotas presentes e removidas;
• ausência de placeholders;
• correspondência com canonical;
• presença na raiz correta da saída publicável.

Não edite apenas dist/ quando a pasta é regenerada. Corrija a fonte ou a configuração que produz o arquivo e execute a build novamente.

Valide cada URL do sitemap

Para sites pequenos, percorra todas as entradas. Para cada URL, registre:

URL:
status HTTP:
canonical encontrado:
meta robots:
bloqueio em robots.txt:
links internos para a página:
decisão: manter, corrigir ou remover do sitemap

Uma resposta 200 não encerra a revisão. A página pode servir conteúdo errado, declarar outro canonical ou conter um noindex acidental. Da mesma forma, uma página válida não precisa entrar no sitemap se não faz parte do conjunto que o projeto quer apresentar.

O checklist de links quebrados ajuda a encontrar rotas órfãs, redirects inesperados e referências a páginas removidas antes de fechar o mapa.

Inclua os arquivos em public/

No Site no Ar, public/ precisa conter os artefatos finais. O guia de Publicação descreve index.html, Pages e assets esperados.

Antes do deploy, confira que:

• robots.txt está em public/;
• sitemap.xml está no caminho referenciado;
• as Pages listadas existem;
• o domínio nos arquivos é o aprovado;
• a build corresponde à versão registrada.

Depois do deploy, abra diretamente:

https://www.exemplo.com/robots.txt
https://www.exemplo.com/sitemap.xml

Confirme o conteúdo servido e teste uma amostra das URLs listadas. A existência local não prova que o arquivo entrou no upload, e um deploy concluído não prova que a versão certa foi ativada.

Use ferramentas externas como evidência adicional

Quando o domínio estiver sob controle da equipe, mecanismos de busca podem oferecer ferramentas para enviar o sitemap e inspecionar URLs. Use esses relatórios como mais uma camada de evidência, não como substituto para validar o arquivo publicado.

Mudanças de rastreamento e indexação não precisam aparecer imediatamente. Registre data, versão e ação antes de repetir alterações. Evite republicar o mesmo arquivo várias vezes apenas porque um painel ainda não refletiu a mudança.

Peça uma revisão delimitada ao agente

Um prompt seguro separa diagnóstico, correção e publicação:

Revise sitemap.xml e robots.txt deste site sem alterar arquivos ainda.

Domínio oficial: [domínio]
Pasta publicável: [pasta]
Rotas que devem ser públicas: [lista]
Rotas que não devem ser publicadas: [lista]

Compare fonte, build e configuração. Retorne:
- URLs do sitemap com status esperado;
- divergências de canonical e noindex;
- regras de robots.txt e impacto;
- arquivos ausentes ou copiados de outro ambiente;
- correções mínimas propostas.

Não remova bloqueios, não exponha conteúdo privado e não publique.
Pare quando a política de uma rota não estiver documentada.

Depois da aprovação, peça a correção na fonte, a build e um diff. Só então autorize a republicação no mesmo Site e a verificação das URLs reais.

A auditoria SEO do Site no Ar também verifica presença de sitemap e robots.txt na publicação. Ela encontra ausência e inconsistências básicas; a equipe ainda precisa decidir quais rotas pertencem ao mapa e quais regras são intencionais.

Checklist final

Antes de considerar a entrega pronta:

• domínio oficial confirmado;
• rotas públicas inventariadas na build;
• sitemap contém URLs absolutas e canônicas;
• páginas removidas, duplicadas e noindex saíram da lista;
• lastmod é confiável ou foi omitido;
• robots.txt não herdou bloqueio de homologação;
• conteúdo privado usa proteção real, não apenas Disallow;
• sitemap, robots e canonical não se contradizem;
• ambos os arquivos estão na raiz correta do pacote;
• arquivos publicados foram abertos pela URL final;
• uma amostra — ou todas as URLs de um site pequeno — foi testada;
• versão e evidências ficaram registradas.

Sitemap e robots.txt não são acessórios para marcar como concluídos. Eles expressam uma política sobre descoberta e rastreamento. Quando derivam das rotas reais, concordam com as URLs canônicas e são verificados depois do deploy, deixam de ser arquivos esquecidos do template e passam a fazer parte de uma publicação controlada.