Sitemap.xml e robots.txt: o guia definitivo do controle de rastreamento

Todo site conversa com os buscadores por meio de dois arquivos de texto que quase ninguém abre para ler: o robots.txt e o sitemap.xml. Eles não aparecem na tela do usuário, não têm design e cabem em poucas linhas — e mesmo assim decidem se o Googlebot vai gastar tempo rastreando as páginas certas ou se vai tropeçar em armadilhas que tiram o site inteiro do índice.

A confusão mais cara de SEO técnico nasce exatamente aqui: gente que acha que o robots.txt "esconde" uma página do Google, gente que preenche campos de sitemap que o buscador ignora há anos, gente que sobe um Disallow: / em produção sem perceber. Este guia disseca os dois arquivos até o osso — o que fazem, o que não fazem, a sintaxe exata, os erros que derrubam sites e como validar tudo antes de dormir tranquilo.

robots.txt: o porteiro do rastreamento#

O robots.txt é um arquivo de texto puro que fica na raiz do domínio, sempre em https://seusite.com/robots.txt. Ele segue o Robots Exclusion Protocol, um padrão que existe desde 1994 e que o Google ajudou a formalizar como RFC em 2019. A função dele é uma só: dizer aos rastreadores quais caminhos eles podem ou não podem acessar.

Repare na palavra: acessar. Não é indexar, não é esconder, não é proteger. É controle de rastreamento, e essa distinção é a raiz de quase todo erro que veremos adiante.

A sintaxe, campo por campo#

Um robots.txt é uma sequência de blocos. Cada bloco começa com uma ou mais linhas User-agent e é seguido por diretivas. Os campos que importam:

• User-agent — define a qual rastreador o bloco se aplica. * significa "todos"; Googlebot, Bingbot, GPTBot miram bots específicos.
• Disallow — o caminho que o bot não deve rastrear. Disallow: /admin/ bloqueia tudo sob /admin/. Disallow: / bloqueia o site inteiro. Disallow: (vazio) não bloqueia nada.
• Allow — abre exceções dentro de um caminho bloqueado. Útil para liberar uma subpasta específica sem abrir a pasta-mãe.
• Sitemap — aponta a URL absoluta do sitemap. É a única diretiva independente de User-agent e pode aparecer em qualquer lugar do arquivo.

Um exemplo comentado:

```txt # Bloco para todos os rastreadores User-agent: Disallow: /admin/ Disallow: /carrinho/ Disallow: /?sessionid= Allow: /admin/ajuda-publica/

# Bloco específico para o Googlebot User-agent: Googlebot Disallow: /rascunhos/

# Bloqueia um bot de IA inteiro User-agent: GPTBot Disallow: /

# Referência ao sitemap (URL sempre absoluta) Sitemap: https://seusite.com/sitemap.xml ```

A ordem dos blocos não importa, mas a especificidade sim: o Google escolhe o bloco de User-agent mais específico que casa com o bot e ignora todos os outros. Se existe um bloco Googlebot, o Googlebot obedece só a ele e ignora o bloco * por completo. Esquecer isso gera a falsa sensação de que uma regra global vale para todo mundo.

Wildcards e casamento de padrões#

O Google suporta dois caracteres especiais nos caminhos:

• ***** casa qualquer sequência de caracteres. Disallow: /*.pdf$ bloqueia todo PDF.
• $ ancora o fim da URL. Sem ele, Disallow: /pagina bloqueia também /pagina-nova e /pagina/sub.

Combinando os dois você bloqueia parâmetros de URL sem afetar as páginas limpas:

``txt User-agent: Disallow: /? # qualquer URL com query string Allow: /?page= # menos a paginação legítima Disallow: /.json$ # todos os endpoints JSON ``

Cuidado: nem todo rastreador entende wildcards. Google e Bing entendem; bots menos sofisticados leem * como caractere literal. Escreva pensando no bot que você quer mesmo controlar.

O <code>crawl-delay</code> e por que o Google o ignora#

A diretiva crawl-delay: 10 pede que o bot espere 10 segundos entre requisições. O Bing e o Yandex respeitam. O Googlebot não — ele ignora crawl-delay desde sempre. Para modular a taxa de rastreamento do Google, o caminho é ajustar dentro do Search Console (ou, na prática, servir respostas rápidas e um 503 quando o servidor está sob pressão, que o Googlebot lê como "pega leve").

A armadilha clássica: Disallow não é noindex#

Aqui está o erro que aparece em auditoria toda semana. Alguém quer tirar uma página do Google e escreve:

``txt User-agent: * Disallow: /pagina-secreta/ ``

E fica surpreso quando a página continua aparecendo na busca, muitas vezes com o texto "Não há informações disponíveis para esta página" na descrição.

O motivo é simples e precisa ficar gravado: Disallow impede o rastreamento, não a indexação. São coisas diferentes.

• Rastrear é o bot baixar e ler o conteúdo da página.
• Indexar é o bot registrar a URL no índice de busca.

Quando você faz Disallow de uma URL, o Google não entra nela — mas se outros sites apontam links para ela, o Google sabe que ela existe e pode indexá-la mesmo sem nunca ter lido o conteúdo. Pior: como ele foi proibido de rastrear, ele nunca vê a tag <meta name="robots" content="noindex"> que você porventura colocou no HTML. O Disallow sabota o noindex.

A regra correta:

• Para tirar uma página do índice, use noindex (meta tag ou header HTTP X-Robots-Tag) e deixe a página rastreável, para o Google poder ler o noindex.
• Para economizar orçamento de rastreamento em áreas irrelevantes (facetas de filtro infinitas, carrinho, busca interna), use Disallow.
• Para proteger conteúdo sensível, não use nenhum dos dois — use autenticação de verdade. O robots.txt é público; listar /admin/ nele é entregar o mapa da casa.

Nunca combine Disallow e noindex na mesma URL esperando reforço. Eles se anulam.

Os erros que bloqueiam o site inteiro#

O robots.txt é poderoso demais para um arquivo de texto, e um deslize custa tráfego.

1. O Disallow: / esquecido. Ambientes de staging costumam bloquear tudo. Quando o site vai para produção e alguém copia o arquivo errado, o resultado é:

``txt User-agent: * Disallow: / ``

Isso manda todo rastreador embora. Em dias, o site some da busca. É o incidente de SEO mais comum e mais devastador que existe.

2. Bloquear CSS e JS. Um tempo atrás era moda bloquear /wp-includes/ e /assets/. Hoje o Google renderiza a página como um navegador; se ele não pode carregar o CSS e o JavaScript, vê um layout quebrado e pode penalizar a experiência mobile. Deixe recursos de renderização livres.

3. Barra final que muda tudo. Disallow: /blog bloqueia /blog, /blog-novo e /blogueiros. Disallow: /blog/ bloqueia só o que está dentro de /blog/. Um caractere muda o escopo inteiro.

4. Arquivo no lugar errado. O robots.txt só é lido na raiz do host. seusite.com/pasta/robots.txt não vale nada. E cada subdomínio tem o seu: blog.seusite.com precisa do próprio arquivo.

5. Devolver 5xx. Se o robots.txt responde com erro de servidor, o Google pode interpretar como "não sei, melhor não rastrear nada" e travar o rastreamento do site todo até o arquivo voltar. Ele precisa responder 200 (ou 404, que o Google lê como "sem restrições").

sitemap.xml: o convite, não a garantia#

Se o robots.txt é o porteiro que diz onde o bot não pode ir, o sitemap.xml é o mapa que diz onde estão as coisas que valem a pena. Ele lista as URLs que você quer que os buscadores conheçam.

Mas atenção à segunda meia-verdade do SEO técnico: o sitemap ajuda na descoberta, não garante a indexação. Estar no sitemap não obriga o Google a indexar nada. Ele é uma sugestão, um mapa de descoberta — especialmente útil para sites grandes, páginas novas, páginas órfãs (sem links internos apontando para elas) e conteúdo que muda com frequência. Para um blog de 30 páginas bem interligadas, o ganho é marginal. Para um e-commerce de 200 mil produtos, é essencial.

A estrutura XML#

O formato é padronizado pelo protocolo Sitemaps 0.9. Um sitemap básico:

``xml <?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <url> <loc>https://seusite.com/</loc> <lastmod>2026-08-06</lastmod> </url> <url> <loc>https://seusite.com/artigo-importante</loc> <lastmod>2026-08-01T14:30:00-03:00</lastmod> </url> </urlset> ``

Os campos:

• <loc> — a URL completa e absoluta. Obrigatório. Precisa incluir o protocolo (https://) e casar exatamente com a versão canônica: mesmo domínio, mesmo esquema, mesma barra final.
• <lastmod> — a data da última modificação real, em formato W3C (AAAA-MM-DD ou com hora e fuso). Opcional, mas leve a sério: o Google usa o lastmod para priorizar o que recrawlear — desde que ele confie no dado. Se todo <lastmod> do site tem a data de hoje, o Google percebe que é lixo e ignora o campo por completo.

Os campos que o Google ignora#

O protocolo permite dois campos que sobreviveram por nostalgia:

• <priority> — de 0.0 a 1.0, supostamente a importância relativa da URL.
• <changefreq> — daily, weekly, monthly, quão frequente a página muda.

O Google ignora ambos e já disse isso publicamente. Eles não influenciam rastreamento nem ranqueamento. Pode incluí-los se algum outro consumidor do sitemap os usa, mas não perca tempo calibrando priority achando que muda algo no Google. É energia desperdiçada.

Os limites que forçam um sitemap index#

Um único arquivo de sitemap tem dois tetos rígidos:

• 50.000 URLs por arquivo.
• 50 MB descompactado.

Estourou qualquer um dos dois, você quebra em vários arquivos e cria um sitemap index — um sitemap de sitemaps:

``xml <?xml version="1.0" encoding="UTF-8"?> <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <sitemap> <loc>https://seusite.com/sitemap-posts-1.xml</loc> <lastmod>2026-08-06</lastmod> </sitemap> <sitemap> <loc>https://seusite.com/sitemap-produtos-1.xml</loc> <lastmod>2026-08-05</lastmod> </sitemap> </sitemapindex> ``

Um sitemap index também tem teto de 50.000 sitemaps filhos, o que dá até 2,5 bilhões de URLs — mais do que qualquer site normal vai precisar. Dividir por tipo de conteúdo (posts, produtos, categorias) tem um bônus: no Search Console você vê a taxa de indexação por segmento e descobre rápido que "os produtos indexam bem, mas as categorias não".

Sitemaps podem ser comprimidos com gzip (.xml.gz) para respeitar o limite de tamanho — o de 50 MB vale sobre o arquivo descompactado.

Sitemaps especializados#

Além das páginas HTML, existem extensões do protocolo para tipos específicos de mídia, cada uma com seu namespace:

• Imagens — namespace image, com <image:loc> dentro de cada <url>, para ajudar o Google Imagens a descobrir figuras que só carregam via JavaScript.
• Vídeo — namespace video, com título, thumbnail, duração e URL do player.
• Notícias — o Google News tem seu próprio sitemap, com regra estrita: só URLs publicadas nas últimas 48 horas, com <news:publication> e data. É a exceção "notícia" do protocolo — para conteúdo evergreen ele não se aplica.

Use o especializado só quando o tipo de mídia é central para o negócio. Um blog de texto não precisa de sitemap de vídeo.

O que incluir e o que deixar de fora#

Um sitemap sujo é pior que sitemap nenhum — ele treina o Google a desconfiar do seu arquivo. A regra de ouro: só entra no sitemap URL que você defende com convicção como resultado de busca. Na prática:

Inclua apenas URLs que são, ao mesmo tempo:

• Canônicas — a versão oficial da página. Nunca liste uma URL cujo rel=canonical aponta para outra.
• Indexáveis — sem noindex, sem Disallow no robots.
• Status 200 — página que carrega de verdade.

Deixe de fora:

• Redirects (301/302) — liste o destino final, não o atalho.
• Erros 404 e 410.
• Páginas com noindex.
• URLs bloqueadas no robots.txt — é contraditório listar no mapa o que você proibiu de rastrear.
• Variações não-canônicas (com parâmetros de tracking, ordenação, paginação de filtro).

Cada URL divergente dessas dilui a confiança do Google no arquivo inteiro.

Geração automática vence a manual#

Manter sitemap na mão em site que publica com frequência é receita para desatualização. A abordagem certa é gerar automaticamente no build ou por um processo que varre o inventário real de conteúdo, garantindo que só entram URLs 200, canônicas e indexáveis. CMSs sérios e frameworks modernos fazem isso nativamente. O sitemap deve se regenerar a cada publicação — nunca ser um arquivo estático que alguém lembra de editar.

Como o Google descobre seu sitemap#

Duas formas, use as duas:

1. Referência no robots.txt — a linha Sitemap: https://seusite.com/sitemap.xml. É a descoberta passiva, funciona para qualquer buscador.
2. Submissão no Google Search Console — em Sitemaps, você envia a URL e passa a ver relatórios de quantas URLs foram descobertas, indexadas e por quê. É aqui que o sitemap vira ferramenta de diagnóstico, não só de descoberta.

Aponte sempre o sitemap index no Search Console, não cada filho individualmente. O Google segue os filhos sozinho.

Checklist de validação#

Antes de considerar o controle de rastreamento pronto, passe por esta lista:

robots.txt

• [ ] Está em https://seusite.com/robots.txt (raiz de cada host e subdomínio).
• [ ] Responde com status 200.
• [ ] Não existe um Disallow: / acidental herdado de staging.
• [ ] CSS, JS e imagens de renderização estão liberados.
• [ ] Nenhuma página que precisa de noindex está bloqueada por Disallow (senão o Google nunca lê o noindex).
• [ ] A linha Sitemap: aponta a URL absoluta e correta.
• [ ] Nada sensível está apenas "escondido" no robots — conteúdo privado tem autenticação real.
• [ ] Testado no validador de robots do Search Console.

sitemap.xml

• [ ] XML válido, com o namespace correto e encoding UTF-8.
• [ ] Todas as <loc> são absolutas, https, canônicas e retornam 200.
• [ ] Zero URLs com noindex, redirect, 404 ou bloqueadas no robots.
• [ ] <lastmod> reflete a data real de modificação, não a data de geração.
• [ ] Nenhum arquivo passa de 50.000 URLs ou 50 MB (use index se passar).
• [ ] Sitemap se regenera automaticamente a cada publicação.
• [ ] Index submetido no Search Console, sem erros no relatório.
• [ ] Referenciado no robots.txt.

Dois arquivos, poucas linhas, e o destino do seu tráfego orgânico. O robots.txt decide onde o bot pisa; o sitemap.xml mostra o que vale a pena visitar. Trate os dois com o rigor de configuração de servidor — porque é exatamente isso que eles são — e você elimina de uma vez a classe de problemas de SEO técnico que mais assombra quem descobre, tarde demais, que uma linha errada apagou o site do Google.