Boas práticas de sitemap XML: o guia direto
Um sitemap bem mantido lista só o que merece ser indexado e diz a verdade sobre quando cada página mudou. O resto é ruído — inclusive changefreq e priority.
Um bom sitemap XML lista apenas URLs canônicas, indexáveis e que respondem 200, com um lastmod verdadeiro em cada entrada — e nada além disso. Ele é regenerado quando o conteúdo muda, declarado no robots.txt e enviado ao Google e ao Bing uma única vez. Este guia cobre cada uma dessas práticas e desmonta os mitos mais persistentes.
O que entra no sitemap
O sitemap é a sua lista de páginas dignas de índice. Cada URL listada deve passar em três testes:
- Canônica: é a versão que a própria página aponta na tag canonical. Variações com parâmetros, versões http e duplicatas ficam de fora.
- Indexável: sem noindex, sem bloqueio no robots.txt.
- Status 200: nada de redirecionamentos, 404 ou páginas atrás de login.
Tudo que reprova em algum teste sai da lista: páginas de busca interna, filtros com parâmetros, páginas de agradecimento, rascunhos, paginação profunda que você não quer indexada. Um sitemap enxuto é um sinal mais forte do que um sitemap completo.
lastmod: o único campo opcional que importa
O Google usa o lastmod para decidir o que rastrear de novo — mas apenas enquanto ele for consistentemente verdadeiro. Se o campo carimbar a data de geração do arquivo em todas as entradas, ou marcar mudanças que não aconteceram, o Google simplesmente passa a ignorá-lo naquele site. A regra prática: preencha o lastmod com a data da última modificação real do conteúdo (no formato W3C, como 2026-07-16), e só a atualize quando a página mudar de verdade. Ajustes cosméticos no rodapé não contam.
changefreq e priority: pode parar de ajustar
Sejamos diretos: o Google ignora <changefreq> e <priority>, e já confirmou isso publicamente; o Bing, em grande parte, também. Nenhuma combinação de valores acelera o rastreamento nem melhora o ranqueamento. Os campos são XML válido e não causam erro, mas cada hora gasta calibrando priority é uma hora perdida. O que de fato orienta o rastreamento é o lastmod confiável e a estrutura de links internos do site.
Limites de tamanho e quando dividir
Cada arquivo de sitemap aceita no máximo 50.000 URLs e 50 MB descompactado. Ao se aproximar de qualquer um dos limites, divida em vários arquivos e liste todos em um índice de sitemaps — o formato está detalhado no nosso guia de índices. Mesmo longe do limite, dividir por tipo de conteúdo (produtos, posts, categorias) facilita a vida: o relatório do Search Console mostra a cobertura por arquivo, e você descobre em minutos qual seção do site tem problema.
Comprima com gzip
Sitemaps comprimidos como .xml.gz são aceitos por todos os buscadores relevantes, e o limite de 50 MB vale para o conteúdo descompactado. Para arquivos grandes, o gzip corta o tráfego e o tempo de resposta sem nenhum custo de compatibilidade. Se o seu servidor já aplica compressão HTTP na resposta, o efeito é o mesmo.
Autodescoberta: a linha Sitemap: do robots.txt
Declare o sitemap no robots.txt para que qualquer rastreador o encontre sem envio manual:
Sitemap: https://example.com/sitemap.xmlA linha aceita URL absoluta e pode aparecer mais de uma vez, mas o padrão mais limpo é declarar apenas o índice, que aponta para o resto. É também o único mecanismo que permite a um sitemap referenciar URLs de outro host de forma válida.
Envio ao Google e ao Bing
No Google Search Console, use o relatório Sitemaps e envie a URL uma única vez — o Google revisita o arquivo sozinho a partir daí. No Bing Webmaster Tools, o processo é equivalente. Reenviar manualmente a cada atualização não acelera nada; o que importa é o arquivo estar sempre atual na mesma URL. Depois do envio, o relatório de cobertura passa a ser seu termômetro: URLs enviadas versus URLs indexadas.
Com que frequência regenerar
A resposta certa é: sempre que o conteúdo mudar. Publicou, atualizou ou removeu uma página, o sitemap deve refletir isso — de preferência no mesmo deploy ou por um job que rode pelo menos uma vez por dia em sites que publicam com frequência. Um sitemap que lista páginas removidas há meses, ou que não conhece as publicadas ontem, treina os buscadores a não confiar nele.
Geração dinâmica ou estática?
As duas funcionam; o que muda é onde mora o risco. A geração estática (no build ou por cron) é simples e à prova de picos de tráfego, mas fica defasada entre execuções. A dinâmica (gerada na requisição) está sempre atual, mas precisa de cache para não virar gargalo e pode quebrar em silêncio se uma consulta falhar. Para a maioria dos sites, o meio-termo ideal é gerar estático a cada publicação. Seja qual for a escolha, valide o resultado de tempos em tempos — geradores também têm bugs.
Mitos e realidade
| Mito | Realidade |
|---|---|
| priority alta melhora o ranqueamento | O Google ignora o campo por completo |
| changefreq controla a frequência de rastreamento | Ignorado; o rastreamento segue demanda e lastmod |
| Toda página do site deve estar no sitemap | Apenas canônicas, indexáveis e com status 200 |
| Estar no sitemap garante indexação | O sitemap é uma dica de descoberta, não uma ordem |
| lastmod pode ser a data de geração do arquivo | Deve ser a modificação real; senão o Google o descarta |
| É preciso reenviar o sitemap a cada mudança | Enviado uma vez, ele é revisitado automaticamente |
Quer saber onde o seu arquivo está hoje em relação a tudo isso? Rode-o no nosso validador de sitemap XML: ele verifica namespace, limites, datas, escapes e duplicatas em segundos, e explica cada achado com a correção. Se aparecerem erros, o guia de correção de erros cobre um por um.