Validador de Sitemap Gratuito

O que é um sitemap.xml e por que é importante?

Um sitemap é um documento XML estruturado que lista os URLs de um site que pretende que os motores de busca conheçam. É disponibilizado a partir de um caminho estável, quase sempre /sitemap.xml, e segue o Protocolo de Sitemap — uma pequena especificação publicada originalmente pelo Google em 2005 e adotada como norma conjunta pelo Google, Yahoo e Microsoft um ano depois. O formato é simples: um elemento raiz <urlset> contendo um elemento <url> por página, com metadados opcionais sobre quando cada URL foi modificado pela última vez, com que frequência muda e qual a sua prioridade em relação às outras páginas do mesmo site.

O objetivo de um sitemap é a descoberta, não o ranking. Os motores de busca rastreiam a web seguindo links de página em página. Num site pequeno com links internos limpos, todas as páginas são acessíveis a partir da página inicial com alguns cliques, e os crawlers encontram tudo sem ajuda. Num site grande, num site com paginação profunda, num site com landing pages isoladas para as quais nenhum link interno aponta, ou num site que acabou de publicar novo conteúdo, os crawlers podem demorar dias ou semanas a descobrir URLs apenas através de links. O sitemap resolve isto ao entregar ao crawler uma lista completa desde o início.

Os sitemaps não garantem indexação. O Google afirmou isto explicitamente na sua documentação desde o lançamento do protocolo: um URL no seu sitemap é um sinal de que pretende que seja indexado, não uma ordem de que o será. Páginas de baixa qualidade, com conteúdo duplicado ou informação escassa serão ignoradas independentemente de estarem incluídas no sitemap. O que o sitemap muda é a eficiência do crawl. Com um sitemap, o Google pode rastrear as suas páginas novas e atualizadas primeiro, priorizá-las com base no campo lastmod, e evitar desperdiçar pedidos em URLs desatualizados ou arquivados.

Os sitemaps também são importantes para a cauda longa. Um site com 100.000 páginas de produto, 5.000 artigos de blogue e 200 landing pages de categoria tem demasiado conteúdo para que qualquer padrão de links internos exponha todos os URLs em poucos cliques. Sem sitemap, o site depende do rastreamento exploratório do Googlebot para encontrar os URLs mais profundos, o que funciona mas é lento. Com um sitemap, todos os URLs são imediatamente conhecidos pelo Google, e o crawler pode dedicar o seu orçamento a verificações de atualização e qualidade de conteúdo em vez de descoberta. Para e-commerce, publicadores de notícias, marketplaces e sites com muito conteúdo, o sitemap não é opcional.

Como utilizar este verificador

O verificador recebe um URL de sitemap ou um domínio raiz e devolve um relatório estruturado sobre validade, completude e acessibilidade.

Passo 1 — Introduza o URL do sitemap. Cole o URL completo do seu sitemap, ou apenas o domínio — o verificador fará a autodescoberta via robots.txt e tentará caminhos comuns como /sitemap.xml, /sitemap_index.xml e /sitemap.xml.gz. Também segue automaticamente ficheiros sitemap-index e percorre todos os sitemaps filhos incluídos.

Passo 2 — Reveja o relatório de validade. O verificador valida o XML contra o esquema do Protocolo de Sitemap, assinala valores lastmod mal formados, verifica URLs acima do limite de 2048 caracteres de caminho, e confirma que o ficheiro está abaixo dos limites máximos de 50 MB não comprimido e 50.000 URLs. Cada problema é apresentado com o URL exato ou número de linha que o originou.

Passo 3 — Verifique a acessibilidade. Para uma amostra de URLs do sitemap, o verificador executa um pedido HEAD e reporta o código de resposta. URLs que retornam 404, 301, 302 ou 5xx no seu sitemap são ruído que desperdiça orçamento de crawl; o relatório apresenta-os agrupados para que os possa corrigir ou remover.

O protocolo de sitemap em profundidade

Um sitemap válido mínimo tem este aspeto:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-04-27T12:00:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/article</loc>
    <lastmod>2026-04-15</lastmod>
  </url>
</urlset>

Apenas <loc> é obrigatório. Os outros três campos opcionais são <lastmod>, <changefreq> e <priority>, e a melhor prática moderna trata cada um de forma diferente.

Limites máximos e o padrão sitemap-index

Um único ficheiro de sitemap pode conter no máximo 50.000 URLs e deve ter menos de 50 MB não comprimido. Estes limites existem no protocolo desde o lançamento e são aplicados por todos os principais crawlers. Ficheiros acima do limite não são simplesmente truncados — são rejeitados inteiramente pelo Googlebot, que depois reporta um erro no Search Console. Para um site com mais URLs do que cabem num único ficheiro, o protocolo define um formato sitemap-index que lista múltiplos sitemaps filhos:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
</sitemapindex>

O índice pode listar até 50.000 sitemaps filhos, cada um contendo 50.000 URLs, para um limite teórico de 2,5 mil milhões de URLs em todo o site. Na prática, organizar por tipo de conteúdo — páginas, produtos, artigos de blogue, etiquetas, categorias — produz uma estrutura gerível que também permite regenerar apenas o sub-sitemap alterado em cada deploy. A convenção é nomear o índice sitemap.xml ou sitemap_index.xml e os filhos com caminhos descritivos.

Precisão do lastmod e quando o Google confia nele

O Google afirmou repetidamente que utiliza lastmod quando o valor é preciso, e desconsidera-o em todo o sitemap quando parece não ser fiável. Um site que reporta sempre a data de hoje para todos os URLs está a reportar uma atualização que não existe; o Google deteta o padrão e deixa de valorizar o campo. O mesmo se aplica a valores de lastmod que nunca são atualizados mesmo quando o conteúdo muda — a ausência de sinal é, em si mesma, um sinal.

Utilize o formato datetime completo ISO 8601, incluindo o deslocamento de fuso horário: 2026-04-27T12:00:00+00:00. A forma apenas com data 2026-04-27 é válida e aceite, mas a forma datetime é preferida para sites de alta frequência onde a hora do dia é relevante. Defina lastmod com a hora de modificação real do conteúdo da página, não com a hora de deploy da aplicação. Páginas que não foram alteradas devem manter o seu valor lastmod anterior, mesmo quando o resto do sitemap é regenerado.

changefreq e priority: maioritariamente ignorados

Os campos <changefreq> e <priority> foram definidos no protocolo original para dar aos proprietários de sites uma forma de expressar com que frequência uma página muda (always, hourly, daily, weekly, monthly, yearly, never) e uma prioridade relativa dentro do site (um decimal entre 0,0 e 1,0). O Google moderno ignora ambos. O crawler determina a frequência de rastreamento a partir dos padrões de mudança observados e determina a prioridade a partir da qualidade do conteúdo e da equidade de links, não de declarações no sitemap.

A recomendação prática é omitir ambos os campos. Tornam o sitemap maior e mais complexo sem alterar o comportamento do crawler. A documentação do Bing sugere que ainda considera changefreq de forma fraca, mas o impacto é pequeno o suficiente para que manter valores precisos raramente valha o custo de desenvolvimento. Um sitemap limpo apenas com <loc> e <lastmod> é o padrão moderno.

Autodescoberta via robots.txt vs submissão no Search Console

Duas formas de informar o Google sobre um sitemap: declará-lo no robots.txt ou submetê-lo via Search Console. Ambas funcionam, ambas são recomendadas, e ambas em conjunto é a melhor prática atual.

User-agent: *
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

A declaração no robots.txt é lida por todos os crawlers bem-comportados — Googlebot, Bingbot, DuckDuckBot, Yandex e a maioria das ferramentas de SEO — sem qualquer configuração por plataforma. A submissão no Search Console é específica do Google, mas desbloqueia os relatórios de indexação que mostram quantos URLs do sitemap estão indexados, quantos foram excluídos e porquê. Para um site que leva o SEO a sério, submeta através do Search Console para visibilidade e declare no robots.txt para portabilidade.

Extensões de sitemap para imagens, vídeos e notícias

O protocolo base tem extensões para conteúdo de imagem, vídeo e notícias. Os sitemaps de imagem adicionam um elemento <image:image> que lista as imagens em cada página, o que ajuda o Google a descobrir imagens em páginas renderizadas com JavaScript onde os URLs das imagens não estão no HTML inicial. Os sitemaps de vídeo adicionam um elemento <video:video> com título, descrição, miniatura e duração, e continuam a ser a forma canónica de disponibilizar vídeo ao Google Vídeo. Os sitemaps de notícias utilizam um elemento <news:news> separado com data de publicação e namespace obrigatório, e são obrigatórios para inclusão no Google Notícias.

Para um site de marketing ou conteúdo típico, um sitemap de URL simples cobre completamente o caso de uso. As extensões valem a complexidade apenas quando a descoberta de imagens, vídeo ou inclusão em notícias é uma fonte de tráfego significativa.

Erros comuns que prejudicam o SEO

404s e redirecionamentos no sitemap. Listar URLs que retornam 404 ou redirecionam para um URL diferente polui o sitemap com ruído. O Google assinala estes casos no Search Console como erros de sitemap e pode descontar o resto do sitemap. Audite o sitemap em cada deploy e remova URLs que não retornem 200. Os redirecionamentos devem ser substituídos pelo URL de destino.

Incluir URLs não canónicos. Páginas com rel="canonical" apontando para um URL diferente não devem aparecer no sitemap. O sitemap é uma lista de páginas que pretende indexar; páginas com canonical para outro URL são páginas que indicou explicitamente aos motores de busca para ignorarem. Incluí-las cria sinais contraditórios.

lastmod sempre atual. Definir lastmod com a data de hoje para todos os URLs em cada regeneração indica ao Google que o campo não é fiável, e o crawler deixa de o valorizar. Defina lastmod a partir da hora de modificação real do conteúdo da página, não da hora de deploy. Páginas que não foram alteradas devem manter o seu lastmod anterior.

Sitemap bloqueado pelo robots.txt. Uma linha Disallow: /sitemap.xml, ou um Disallow: /sitemap mais abrangente que corresponda ao ficheiro, impede os crawlers de aceder ao sitemap. Teste sempre com curl ou um verificador de sitemap depois de modificar o robots.txt para confirmar que o URL do sitemap é acessível.

Sub-sitemaps num sitemap-index a retornar 404. Um sitemap-index que lista dez sitemaps filhos mas apenas nove deles resolvem faz com que o que falta seja assinalado como erro. Pior ainda, se o padrão de caminhos mudar entre deploys, todos os URLs de sub-sitemap antigos tornam-se 404 até o índice ser regenerado. Gere o índice a partir da mesma fonte de verdade dos filhos para os manter sincronizados.

Misturar protocolos num sitemap. Um sitemap disponibilizado em https://example.com/sitemap.xml deve conter apenas URLs https://. URLs http:// misturados são tratados como um host diferente e ignorados pelo processador de sitemap do host canónico. O mesmo se aplica à inconsistência entre www e não-www: escolha um e utilize-o em todo o sitemap.

Esquecer de escapar caracteres especiais nos URLs. O XML requer que &, <, >, " e ' sejam escapados dentro de valores de atributos e elementos. URLs com ampersands não escapados quebram o parser XML, e todo o sitemap falha na validação. Gere URLs através de uma biblioteca que trate do escape em vez de concatenar strings manualmente.

Casos extremos que ninguém menciona

Um sitemap.xml disponibilizado com o content type errado quebra alguns crawlers. O content type correto é application/xml ou text/xml. Alguns servidores retornam text/plain ou text/html para ficheiros .xml quando o tipo MIME não está configurado, e o Bingbot em particular é conhecido por recusar tais respostas. O verificador testa o content type e assinala-o como aviso quando não corresponde.

Sitemaps comprimidos disponibilizados como .xml.gz poupam largura de banda dramaticamente — os sitemaps comprimem para 5-10% do seu tamanho original devido à grande repetição de prefixos de URL. Tanto o Google como o Bing aceitam sitemaps com gzip sem qualquer configuração extra, e o limite de tamanho de ficheiro é medido em relação ao tamanho não comprimido. A única ressalva é que algumas plataformas de alojamento disponibilizam ficheiros .gz com a codificação de conteúdo errada, fazendo com que o crawler receba bytes gzip brutos que falham ao ser analisados. Teste a versão comprimida num browser; se vir caracteres binários em vez de XML, a resposta está a falhar o cabeçalho Content-Encoding: gzip.