O sitemap XML declara ao Google quais páginas do seu site realmente importam

Todo site tem duas listas de páginas: as que existem e as que você quer que o Google conheça. Um sitemap XML é a segunda lista, escrita em um formato que o buscador lê sem ambiguidade. É a forma mais direta de dizer quais URLs você considera as definitivas.

Ele não força nada. Não obriga o Google a indexar, não melhora posição e não compensa conteúdo fraco. O que ele faz é acelerar a descoberta e revelar divergências: quando o que você declara não bate com o que o buscador encontra, o relatório de cobertura mostra a diferença.

Este artigo trata do arquivo em si: o que entra, o que fica de fora, como preencher as datas, quais são os limites de tamanho e o erro de domínio que anula um sitemap XML inteiro sem dar mensagem de erro.

O que é um sitemap XML e para que ele serve

É um arquivo que lista URLs do seu site, uma por entrada, com metadados opcionais. Fica em um endereço público, normalmente /sitemap.xml, e é declarado ao buscador de duas formas: pelo Search Console e por uma linha no arquivo de exclusão de robôs.

O ganho real aparece em três situações: sites grandes, onde a descoberta por links é lenta; sites novos, com poucos links externos apontando para eles; e sites com páginas profundas, acessíveis apenas depois de vários cliques.

Em um site de dez páginas, todas no menu principal, o efeito é próximo de zero. Vale manter mesmo assim — o custo é nulo e o valor de diagnóstico é alto.

O que deve entrar no sitemap XML?

Só URLs que satisfaçam todas estas condições ao mesmo tempo:

• Respondem 200, sem redirecionamento no caminho.
• São canônicas, com a tag canonical apontando para elas mesmas.
• Não têm meta noindex.
• Não estão bloqueadas para rastreamento.
• Você quer mesmo que apareçam na busca.

Se uma URL falha em qualquer item, ela não entra. A lista precisa ser um conjunto de afirmações verdadeiras, porque é assim que o buscador a trata.

O que deve ficar de fora

Páginas de resultado de busca interna, filtros e ordenações com parâmetro, páginas de login e área do cliente, carrinho e checkout, páginas de agradecimento, versões de impressão e qualquer URL que redirecione. Também ficam de fora as páginas de tag geradas automaticamente que não têm conteúdo próprio.

O critério é sempre o mesmo: você mandaria essa URL como resposta para alguém que busca no Google? Se a resposta é não, ela não pertence ao sitemap XML.

Como preencher lastmod sem estragar o arquivo

O campo lastmod informa quando o conteúdo mudou pela última vez. É o único metadado que ainda tem peso prático — o Google já declarou publicamente que ignora priority e changefreq.

A regra é uma só: lastmod deve refletir alteração real de conteúdo. Se o seu sistema carimba a data de hoje em todas as URLs a cada geração do arquivo, o campo vira ruído e o buscador passa a ignorá-lo. Isso é pior que não ter o campo.

Use o formato de data ISO, com fuso horário quando possível. E não confunda alteração de conteúdo com deploy: republicar o site sem mudar um parágrafo não é motivo para atualizar a data.

Quais são os limites de tamanho?

Cada sitemap XML aceita no máximo 50 mil URLs e 50 MB descompactado. Passou disso, ele precisa ser dividido.

A divisão se faz por um arquivo índice, que não lista URLs — lista outros arquivos. Um índice pode apontar para até 50 mil arquivos, o que cobre qualquer catálogo real.

Mesmo abaixo do limite, dividir ajuda no diagnóstico. Separar por tipo de conteúdo — produtos, categorias, artigos, páginas institucionais — permite ver no Search Console qual grupo está com problema de cobertura. Um índice com quatro arquivos temáticos entrega muito mais informação que um arquivo único com 12 mil linhas. Essa organização é parte da mesma disciplina descrita no mapa completo da camada técnica de um site.

O erro de domínio que anula tudo

Este é o problema mais comum que encontramos, e o mais silencioso.

O site responde em https://exemplo.com.br. O canonical de cada página aponta para lá. Mas o arquivo declarado no Search Console é https://www.exemplo.com.br/sitemap.xml, e as URLs listadas dentro dele também usam www.

Resultado: cada entrada aponta para uma URL que redireciona. O buscador segue o redirecionamento, chega na versão sem www, compara com o que foi declarado e registra divergência. Nenhuma mensagem de erro grave aparece — só um aumento discreto de páginas com problema no relatório.

O mesmo vale para HTTP contra HTTPS e para barra final contra ausência de barra final. A verificação é rápida: abra o arquivo, copie três URLs de linhas diferentes e cole no navegador. Se alguma delas muda de endereço na barra, corrija a geração do arquivo antes de qualquer outra coisa.

Como validar o arquivo?

Quatro checagens resolvem quase tudo:

1. Abra o arquivo no navegador. Ele precisa carregar e ser XML bem formado. Erro de parsing derruba o arquivo inteiro, não só a linha com problema.

2. Confira o cabeçalho HTTP. Deve responder 200 e vir com Content-Type de XML. Servidor que entrega o arquivo como HTML causa recusa.

3. Teste uma amostra de URLs. Pegue dez linhas espalhadas pelo arquivo e confirme que todas respondem 200, sem redirecionamento e sem noindex.

4. Envie no Search Console e volte depois. O relatório mostra quantas URLs foram descobertas e quantas foram indexadas. A diferença entre esses dois números é onde mora o trabalho, e o caminho para investigá-la é o mesmo descrito em como ler os motivos de exclusão do relatório de páginas.

Erros que aparecem depois

Três padrões costumam surgir meses após o arquivo estar correto.

O primeiro é a URL removida: o produto saiu do catálogo, a página passou a responder 404, mas continua listada no sitemap XML. Isso precisa sumir do arquivo na mesma operação que despublica o item.

O segundo é a contradição com o bloqueio de robôs. Listar no sitemap uma URL que o próprio site impede de rastrear é enviar dois comandos opostos — e a diferença entre bloquear o acesso e bloquear a indexação explica por que essa combinação costuma produzir o pior dos dois mundos.

O terceiro é o arquivo estático esquecido. Alguém gerou uma vez, subiu por FTP, e ele nunca mais mudou. Se a geração não está automatizada no sistema, ela vai desatualizar. Em projetos que fazemos, a geração faz parte do próprio trabalho de estrutura e SEO do site, justamente para tirar esse arquivo da lista de tarefas manuais.

O que esperar em termos de resultado

Descoberta mais rápida de páginas novas e um diagnóstico melhor no Search Console. É isso. Não há ganho de posicionamento por ter um sitemap XML, nem penalidade por não ter.

Trate o arquivo como um documento de verdade sobre a sua arquitetura. Quando ele diz a verdade, o relatório de cobertura vira uma ferramenta confiável. Quando mente, você perde a única fonte objetiva para comparar o que publicou com o que o Google aceitou.