Validador de sitemap XML

Como validar um sitemap XML

Três passos, todos nesta página. O validador lê o arquivo que você entrega — ele não busca o seu site, então cole o XML ou solte o arquivo em vez de digitar uma URL.

1. Cole ou solte o arquivo. Cole o XML na caixa da esquerda, ou arraste o sitemap.xml (ou sitemap.xml.gz — seu navegador descompacta) para cima dela. A validação roda na hora, a cada tecla.
2. Desça pelos achados. Cada achado vem com o número da linha e a correção. Erros são coisas que um rastreador vai recusar ou ler errado; avisos são XML válido que ainda assim custa alguma coisa, como um lastmod no futuro ou uma URL repetida.
3. Copie o relatório, corrija, verifique de novo. O painel da direita traz um relatório em texto puro — tipo de arquivo, quanto falta para os limites de 50.000 URLs e 50 MB, e todos os achados — que dá para colar numa tarefa. Corrija, cole o arquivo novo e confirme que ele volta limpo.

O que este validador de sitemap verifica

Ele passa três vezes pelo arquivo que você cola. Primeiro, se o XML está bem formado: tags sem fechar ou mal aninhadas, um & sem escape numa query string, um prefixo de namespace não declarado — cada coisa apontada na linha em que acontece, e não como um único "erro de parsing". Depois, o protocolo do sitemaps.org: a raiz é <urlset> ou <sitemapindex> no namespace http://www.sitemaps.org/schemas/sitemap/0.9, cada entrada tem exatamente um <loc> absoluto, <lastmod> é um W3C Datetime de verdade, <priority> fica entre 0.0 e 1.0 e <changefreq> é uma das sete palavras permitidas. Por fim, os limites e as referências cruzadas: 50.000 URLs, 50 MB sem compactação, URLs repetidas, hosts misturados e as anotações hreflang de xhtml:link conferidas nos dois sentidos.

Um sitemap XML é um arquivo publicado em uma URL fixa que lista as páginas que você quer que sejam rastreadas: cada uma como um elemento <loc>, opcionalmente com <lastmod>, agrupadas sob uma raiz <urlset> — ou sob um <sitemapindex> que aponta para vários arquivos desse tipo. O protocolo é isso, e continua sendo o esquema 0.9 que os buscadores combinaram. É justamente por isso que vale rodar um validador de sitemap exatamente uma vez a cada mudança no gerador: as falhas são mecânicas, e cada uma vira uma correção de uma linha assim que alguma coisa te diz qual é a linha.

E o que ele não responde, dito logo: se a página do <loc> devolve mesmo 200, se ela tem noindex, se o robots.txt aponta para o arquivo. Isso exige uma requisição por URL — trabalho de servidor, e não algo que uma página rodando no seu navegador consiga fazer (o motivo está mais abaixo). Formato correto e conteúdo correto são duas perguntas diferentes; esta página cuida da primeira.

pt-BR, pt-PT ou só pt: os códigos que vazam do sistema para o sitemap

Se você já abriu um arquivo de tradução, um config/locales ou uma variável de ambiente, você viu pt_BR escrito com underscore mil vezes. É a forma de locale do POSIX, do Java, do gettext, do Rails — e é a forma que a aplicação tem à mão na hora de gerar o sitemap. Daí para a anotação de hreflang é um passo, e é um passo errado: hreflang usa hífen. pt_BR é um erro aqui, e o validador aponta. Não é descuido de quem escreveu: é o identificador certo, do lugar errado.

Essa última linha merece atenção porque é a única da tabela que nenhum validador pega, nem este. br existe no ISO 639-1, então é um código de idioma perfeitamente válido — só que o idioma é o bretão, e não o português do Brasil. O arquivo passa limpo, o Google aceita a anotação, e a sua versão brasileira fica anunciada como se fosse escrita para leitores da Bretanha. Ninguém avisa. O mesmo vale para uk, que é ucraniano e não Reino Unido. A regra que evita a família toda de enganos: o que vem antes do hífen é sempre um idioma; país só depois do hífen. Brasil é BR em pt-BR, nunca sozinho.

Falta a decisão que não é de sintaxe: pt sozinho já cobre todo mundo que busca em português. Só vale separar pt-BR de pt-PT se as versões forem diferentes de verdade — preço em real e em euro, CPF e NIF, frete, formas de pagamento, atendimento. Se a versão de Portugal é a brasileira com o mesmo texto, duas anotações regionais não te dão nada e ainda te dão um grafo maior para manter em dia. E o inverso é pior: anunciar pt-PT quando o seu único português é o brasileiro entrega ao leitor português uma página que fala de PIX e de boleto. Se você tem as duas versões de verdade, o padrão que funciona é pt-BR + pt-PT + um x-default para quem não é nenhum dos dois.

O botão Exemplo com erros lá em cima carrega exatamente esse cenário: pt_BR com underscore, br passando calado, pt-br em minúscula, uma data 01/09/2026, um changefreq traduzido para "diariamente" e um caminho com cedilha sem codificar. Para montar a anotação certa desde o começo em vez de depurar, o gerador de tags hreflang produz de um único padrão de URL tanto o bloco <link> do head quanto o bloco xhtml:link do sitemap — gere lá, cole aqui, e os links de retorno saem certos por construção.

50.000 URLs, 50 MB e como dividir direito

Dois números duros: 50.000 URLs e 50 MB sem compactação por arquivo de sitemap. O tamanho é medido antes do gzip, então compactar um arquivo de 60 MB não o coloca abaixo do limite — só encurta o download. O relatório acima dos achados mostra o quanto você está perto dos dois, e esse é o número que vale acompanhar num site que cresce, porque passar de qualquer um dos limites invalida o arquivo inteiro em vez de cortá-lo.

Passado isso, divida por seção e publique um <sitemapindex>: um arquivo por tipo de conteúdo, ou por mês — o que deixar os valores de <lastmod> honestos. Um índice comporta até 50.000 entradas <sitemap>, cada uma com um <loc> e, opcionalmente, um <lastmod> — sem <priority>, sem <changefreq> e sem elementos <url> misturados, coisas que este validador aponta. O protocolo não deixa um índice listar outro índice, então a árvore tem exatamente dois níveis. Cole um arquivo de índice aqui e o validador troca para as regras de índice sozinho; seguir as URLs filhas ele não consegue, já que não busca nada.

Uma última que não é limite mas se comporta como um: mantenha o arquivo honesto. Toda URL nele deve devolver 200 e ser indexável — um <loc> que redireciona, dá 404 ou carrega noindex ensina o rastreador a confiar menos no sitemap. Conferir isso custa uma requisição por URL, o que é trabalho de servidor. É o que o clize seo check --domain seudominio.com.br faz, colocando o resultado lado a lado com os dados do Search Console.

Depois de válido: o ping de sitemap acabou

Várias ferramentas ainda oferecem "avisar o Google" quando o seu arquivo passa. Aquele endpoint — google.com/ping?sitemap= — foi descontinuado em 2023 e não faz mais nada. Se um validador ainda vende isso como recurso, isso te diz quando aquela página foi mexida pela última vez.

O que substitui é mais sem graça e funciona. Coloque a URL absoluta do sitemap no robots.txt, como uma linha Sitemap: — todo rastreador lê por conta própria, no ritmo dele, e não exige conta nenhuma. Envie o arquivo uma vez no Search Console e no Bing Webmaster Tools, e depois deixe quieto; reenviar não acelera nada. Mantenha o <lastmod> correto, porque é o único campo do arquivo que o Google diz que usa, e é um valor correto que torna um novo rastreamento digno de ser agendado. Se você usa IndexNow, avise na publicação — esse está vivo.

E depois disso, meça em vez de adivinhar. O clize seo check --domain seudominio.com.br lê o seu sitemap e a sua propriedade do Search Console juntos e mostra as páginas que estão no arquivo mas nunca conseguiram uma impressão, com o status HTTP e o estado de indexação atuais — a resposta honesta para "adiantou ter enviado?", que nenhum validador consegue dar. Ainda na camada legível por máquinas, dois vizinhos seguem a mesma regra desta página, a de gerar o arquivo de uma fonte só em vez de editar na mão: o validador de llms.txt, para o índice que os agentes leem, e o gerador de schema de FAQ, para uma marcação que precisa bater palavra por palavra com a página visível.

$ npm i -g @clize/clize && clize install
$ clize seo check --domain seudominio.com.br