Sitemap XML: um lastmod igual em todos os URL torna o seu sitemap inútil
Um sitemap XML diz aos motores que URL existem e quais mudaram. A primeira função é cumprida por quase todos os CMS. A segunda falha numa boa parte deles, e de forma invisível: o ficheiro é válido, a Search Console lê-o sem erro e, ainda assim, deixou de trazer qualquer informação sobre o que se mexeu. A causa está num único campo, lastmod, e na maneira como é preenchido.
O que a Google faz mesmo com o lastmod
A posição da Google está escrita preto no branco na sua documentação sobre a construção de um sitemap: o valor de lastmod é utilizado «se for coerente e verificável», por exemplo comparando-o com a última modificação real da página. A Google acrescenta que os campos priority e changefreq são ignorados. Dos três campos opcionais do formato, só um conta, e apenas se disser a verdade.
Do ponto de vista do motor, o cálculo é o seguinte. Um robot dispõe de um orçamento de rastreio limitado por site. Quando relê um sitemap, compara as datas anunciadas com as que memorizou. Um URL cuja data avançou merece uma nova visita; um URL cuja data não se mexeu pode esperar. Se todas as datas avançam ao mesmo tempo a cada leitura, o motor deixa de poder distinguir uma página realmente atualizada de uma página inalterada. Acaba por deixar de confiar no campo e volta às suas próprias heurísticas, em regra mais lentas.
O defeito típico: a data do build
Muitos geradores de sites estáticos, e um certo número de CMS, escrevem no lastmod a data em que o site foi regenerado. Num site publicado todos os dias, todos os URL passam a ter a data do próprio dia, incluindo artigos com três anos em que ninguém tocou. O sitemap anuncia em permanência que tudo mudou.
Verificámos este defeito em vários sites em produção durante o verão de 2026, em mais de trezentos URL no total: em cada caso, um único valor de lastmod para todo o sitemap, igual à hora do último build. Nenhum destes sites enviava, de resto, cabeçalho HTTP Last-Modified nem ETag nas suas páginas, e nenhum respondia aos pedidos condicionais dos robots. O motor não tinha, portanto, forma alguma de saber o que recarregar.
Diagnóstico em três controlos
O controlo leva alguns minutos, com um simples terminal.
- Contar os valores distintos de lastmod. Recuperar o sitemap, extrair as etiquetas lastmod e contar os valores únicos. Um sitemap saudável, num site de várias centenas de páginas, conta dezenas deles. Um único valor, ou um punhado todos datados do mesmo dia, denuncia o defeito.
- Comparar o lastmod com a página. Pegar num URL antigo do sitemap, abrir a página e comparar a data de modificação exibida no artigo, ou nos seus dados estruturados, com o valor de lastmod. Um desvio de vários meses confirma que o lastmod não descreve a página.
- Testar os cabeçalhos HTTP. Pedir uma página com um pedido HEAD e ver se o servidor devolve Last-Modified ou ETag. Depois reenviar o mesmo pedido com If-Modified-Since na data recebida. Um servidor que responde 304 Not Modified sabe dizer que uma página não mudou; um servidor que devolve 200 de cada vez obriga o robot a voltar a descarregar tudo.
Estes três testes não exigem nenhuma ferramenta paga. Fazem parte dos controlos que recomendamos antes de qualquer discussão sobre a indexação de um meio de comunicação.
Por que razão é mais grave para um meio de comunicação do que para um site institucional
Um site institucional de vinte páginas é integralmente recrawlado aconteça o que acontecer. Um meio de comunicação que publica vários artigos por semana e corrige outros vive de um sinal de atualidade fiável: é ele que faz subir um artigo atualizado e é ele que evita ao robot gastar o seu orçamento em páginas paradas. Quando o sinal está partido, dois sintomas aparecem ao fim de algumas semanas:
- Os novos artigos demoram mais tempo a ser indexados, porque ficam diluídos num sitemap onde tudo parece novo.
- As correções de artigos antigos não são tidas em conta, porque nada distingue uma página corrigida de uma página que foi simplesmente reconstruída por um build.
Num meio de comunicação que visa também os motores generativos, o problema paga-se uma segunda vez: os robots das IA de pesquisa, que se apoiam nos mesmos sitemaps, herdam-no. Um conteúdo revisto para corrigir um número continua a ser servido na sua versão antiga durante semanas.
O critério de correção
Corrigir o defeito é fazer o lastmod carregar a data da última modificação editorial de cada página, e mais nada. Em concreto:
| Acontecimento | O lastmod deve mudar? |
|---|---|
| Correção do texto, adição de um parágrafo, atualização de um número | Sim |
| Mudança de título, de meta description ou de imagem de destaque | Sim |
| Regeneração do site sem modificação da página | Não |
| Mudança de tema ou de modelo aplicada a todas as páginas | Não, salvo se o conteúdo visível mudar |
| Novo comentário, novo bloco «artigos relacionados» calculado automaticamente | Não |
O critério de aceitação é o mesmo do diagnóstico: depois da correção, o número de valores distintos de lastmod tem de refletir a história real do meio de comunicação, e dois builds sucessivos sem modificação editorial têm de produzir dois sitemaps idênticos. Se o sitemap muda sem que nada tenha sido escrito, a correção não está feita.
O caso particular do meio de comunicação em subdiretório
Quando um meio de comunicação está alojado sob um caminho do site principal, por exemplo um blogue servido em /blog/ a partir de outra plataforma, junta-se uma segunda dificuldade: o ficheiro robots.txt que declara o sitemap só é lido na raiz do host. Um robots.txt colocado no subdiretório nunca é consultado, e as linhas Sitemap que contém não existem para os motores, como recorda a documentação da Google sobre o robots.txt. Há então que declarar o sitemap do meio de comunicação no robots.txt do site principal, ou submetê-lo diretamente na Search Console. A Google retirou em 2023 a possibilidade de «fazer ping» a um sitemap por simples pedido HTTP: sem declaração explícita, um meio de comunicação em subcaminho não tem canal de descoberta nenhum.
Estes dois defeitos, lastmod uniforme e sitemap por descobrir, corrigem-se de uma vez por todas ao nível da ferramenta de publicação. É o género de pormenor que um CMS pensado para um meio de comunicação tem de resolver por construção, porque nenhuma equipa editorial o irá verificar à mão a cada publicação. Sobre os outros sinais de atualidade, a data de revisão exibida e os dados estruturados, remetemos para o nosso artigo «Atualidade: datar, rever, provar».
Escrito por
Yann Léguillon
Presidente da Mazette, a editora da Joornal. Acompanha empresas que constroem o seu próprio meio de comunicação: estruturação editorial, visibilidade nos motores de busca e nas IA, produção à escala.