Blog · 2026-08-30

O lastmod do seu sitemap mente todo dia, e o Google para de ouvir: a máquina de estados por hash de conteúdo

Site estático que carimba o lastmod com a hora do build a cada reconstrução mente para o Google todo santo dia. O certo é remover o ruído, calcular o hash do conteúdo e rodar uma máquina de estados, para que a data só se mova quando o conteúdo mudou de verdade.

Abra o seu próprio sitemap.xml: centenas de URLs e todos os lastmod no mesmo minuto da madrugada de hoje, porque o agendamento de deploy acabou de rodar. Nenhuma palavra do conteúdo mudou. A única coisa que mudou foi a hora do build. Um sitemap assim grita "o site inteiro foi atualizado" para o Google todo dia, e depois de um tempo nem a única página que você atualizou de verdade vale o tempo dele. Isso não é desastre exótico, é o comportamento padrão da maioria dos geradores de site estático.

O sintoma: um único timestamp em todos os lastmod do site

O diagnóstico leva um olhar. Abra o sitemap: se todo <lastmod> carrega o mesmo horário e esse horário bate exatamente com o último deploy, seu gerador quase certamente usa "agora" como data de modificação, seja um date.today() enfiado no dateModified, seja um script de build sobrescrevendo o lastmod com o instante da compilação. A segunda prova está no Google Search Console: o sitemap aparece como lido, mas as páginas que você realmente editou nunca são rastreadas de novo.

O estrago é pior em sites que reconstroem por agendamento. Mantemos um site de conteúdo esportivo de 402 páginas que reconstrói 4 vezes por dia (classificação e tabela mudam diariamente, então as reconstruções são necessárias). Usar a hora do build como lastmod significaria declarar todo dia que cada página "foi atualizada 4 vezes", quando o corpo do texto na maioria delas não mexeu um único byte. Pior: a mesma mentira costuma ser contada duas vezes, uma no sitemap e outra no dateModified dos dados estruturados da página.

A posição do Google: um lastmod impreciso é tratado como ausente

A documentação oficial de sitemaps do Google é direta: o lastmod só é usado quando é "consistently and verifiably accurate", verificado por exemplo comparando com as modificações reais da página. O mesmo documento define o que conta como atualização digna de sinalização: mudanças no conteúdo principal, nos dados estruturados ou nos links da página. Trocar o ano do aviso de copyright não conta.

A função do lastmod é ajudar os rastreadores a priorizar, dizendo "rastreie estas páginas primeiro, pule o resto". Grite "atualizado" no site inteiro todo dia e esse sinal cai a zero. O Google fica sem como saber qual página mudou de fato, e você jogou fora com as próprias mãos a dica de rastreamento mais valiosa que tinha. Para um site que reconstrói várias vezes ao dia e quer suas atualizações indexadas rápido, isso é um tiro no pé.

A correção: máquina de estados por hash de conteúdo, datas que seguem o conteúdo

O princípio em uma linha: o lastmod não deve vir de "quando foi construído", deve vir de "quando o conteúdo mudou". O método é manter para cada página um arquivo de estado que sobrevive entre builds:

{ "/match/group-a/": {
    "hash": "3f2a…",
    "publishedAt": "2026-06-10",
    "updatedAt": "2026-08-12" } }

Todo build roda o mesmo procedimento em cada página:

1. Depois de gerar o HTML, extraia o conteúdo principal, normalize e calcule um SHA256.
2. Página ausente do arquivo de estado, ou seja, página nova: escreva a data de hoje em publishedAt e em updatedAt.
3. Hash igual ao da rodada anterior: não mexa em nada, mantenha as datas antigas.
4. Hash diferente: coloque hoje em updatedAt e grave de volta no arquivo de estado.

O lastmod do sitemap, o dateModified dos dados estruturados e a linha de "última atualização" exibida na página leem todos do arquivo de estado, então três lugares compartilham uma única fonte de verdade. O arquivo de estado viaja com o repositório ou com o artefato de deploy, e nenhuma quantidade de reconstruções lhe dá amnésia. Pense também no momento de gravar: só persista depois que o deploy for confirmado com sucesso. Um build que falhou não pode poluir o estado, senão uma compilação explodida arrasta junto todas as datas do site.

Limpe antes de calcular o hash: script e código de rastreamento não são conteúdo

Onde esse mecanismo costuma morrer é num hash calculado de forma grosseira demais. Calcule o hash do documento HTML inteiro e você vai descobrir que toda página "mudou" em todo build: um snippet de rastreamento ganha versão nova, nomes de arquivos de asset carregam impressão digital de cache (app.a1b2c3.js), nonces são aleatórios, o rodapé imprime o ano corrente sozinho. Mexeu em qualquer um desses e todos os hashes do site viram, deixando a máquina de estados inútil. Pela mesma lógica, um bloco de "artigos relacionados" que sorteia entradas a cada build precisa ficar fora do escopo do hash.

Então limpe antes de calcular. Use um parser de HTML de verdade (não uma expressão regular) para remover <script>, <style> e comentários por inteiro, tire parâmetros de rastreamento e impressões digitais de versão, mantenha só o texto e a estrutura da área de conteúdo principal, e normalize espaços em branco antes de calcular. O que você remove é exatamente aquilo que a definição do Google não considera atualização significativa. Corte a fronteira do hash pela mesma fronteira oficial de significant.

Data de publicação e data de atualização são dois campos, não misture

Outro erro comum é ter um único campo de data para o site inteiro. A data de publicação (publishedAt) nunca mais deve se mover depois de escrita. A data de atualização (updatedAt) só se move quando o hash muda. A regra de saída cabe em uma linha:

lastmod = updatedAt ?? publishedAt

Para uma página que nunca foi editada, o lastmod fica honestamente parado na data de publicação, e não há nada de vergonhoso nisso. Para uma página que foi realmente editada, o lastmod aponta com precisão para aquele dia, e é aí que está o valor.

O aceite exige teste negativo, e as duas condições têm que passar: rode dois builds seguidos, e o segundo precisa reportar zero páginas alteradas. Depois edite um parágrafo de uma página, e só o lastmod daquela página pode se mover. Falhou em qualquer uma das duas, o ruído não foi totalmente removido, o que significa que o seu sitemap continua mentindo.

Fechamento

O lastmod é o seu limite de crédito com os rastreadores, e crédito se constrói não mexendo nas coisas à toa. Amarre a data a um hash de conteúdo e a mentira sai do processo, por mecanismo e não por autodisciplina. Se o seu site também tem algumas centenas de páginas reconstruindo por agendamento diário enquanto o sitemap nunca fez o Google olhar direito, essa máquina de estados roda no site de conteúdo que operamos. Fale com a gente.

Esse tipo de detalhe, transformamos em serviço

Honestidade de lastmod é aquele tipo de métrica que ninguém confere, mas no momento em que alguém confere dá para ver se o trabalho foi feito direito. O sitemap do nosso próprio site é produzido por uma máquina de estados por hash de conteúdo, e a data só se move quando algo mudou.

• Arquitetura de site e SEO técnico: sitemap, canonical, robots e dados estruturados alinhados de uma vez
• Monitoramento de indexação: status de indexação página a página, com IndexNow enviado aos cinco endpoints
• Produção de conteúdo: lastmod só significa alguma coisa quando existe atualização real

As especificações estão em Serviço de criação de site iGaming SEO.