Data de publicação no Google: por que erra e quando mudar

O Google não copia a data que está escrita na sua página; ele tenta adivinhar qual é a data mais confiável de publicação cruzando vários sinais diferentes — e quando esses sinais não coincidem entre si, o resultado é a data “errada”, atrasada demais ou até futura, que aparece embaixo do título no resultado de busca.

Este artigo explica de onde vem essa data, por que ela costuma divergir do que está escrito na página, e onde fica a linha entre corrigi-la de forma legítima — porque o conteúdo realmente mudou — e simplesmente trocar o valor para simular uma atualização recente, prática que o Google trata como manipulação de sinal de frescor.

De onde vem a data que aparece no resultado do Google

O primeiro sinal que o Google procura é a data visível: um texto simples, escrito na própria página, geralmente perto do título ou da assinatura do autor, como “Publicado em 12 de março de 2024”. Esse texto costuma pesar mais do que a marcação estruturada, porque é o que uma pessoa real veria ao abrir a página, e o Google tenta manter coerência entre o que promete no resultado e o que o usuário encontra ao clicar.

Além da data visível, o Google também lê a marcação schema.org (os campos datePublished e dateModified de um Article ou BlogPosting), o cabeçalho HTTP Last-Modified enviado pelo servidor, o valor lastmod do sitemap.xml e até evidências indiretas, como a data que outro site usou ao citar ou republicar o mesmo conteúdo, ou um padrão de data embutido na própria URL. Quando todos esses sinais apontam para o mesmo dia, o Google exibe essa data com confiança; quando divergem, ele escolhe segundo sua própria hierarquia de confiabilidade, e é exatamente essa escolha que costuma parecer errada para quem escreveu a página.

Se nenhum sinal for confiável — por exemplo, a página não tem nenhuma data visível nem marcação estruturada —, o Google pode simplesmente não mostrar data alguma no resultado, em vez de arriscar exibir algo impreciso. Em casos raros, ele recorre à primeira vez que o Googlebot rastreou aquela URL como aproximação, o que pode ser bem posterior à publicação real se a página ficou bloqueada por robots.txt ou noindex no início.

Data visível, datePublished, dateModified e lastmod: quatro sinais diferentes

É comum tratar “a data da página” como uma coisa só, mas o Google na verdade lida com quatro sinais distintos, que nem sempre concordam entre si e estão resumidos na lista mais abaixo.

Uma causa recorrente de confusão é técnica: muitos temas e frameworks front-end imprimem a data com JavaScript no momento do carregamento, em vez de gravar uma data fixa no banco de dados. Isso faz a data visível mudar a cada visita — inclusive durante o próprio rastreamento do Googlebot, que pode capturar o timestamp do momento do crawl como se fosse a data de publicação. É uma das explicações mais comuns para o Google mostrar “hoje” ou uma data que avança sozinha semana após semana, sem que ninguém tenha editado nada de fato.

• Data visível: o texto que qualquer visitante lê na página, geralmente um “Publicado em” ou “Atualizado em”.
• datePublished (schema.org): deveria representar a data original de publicação e, por definição, não deveria mudar depois.
• dateModified (schema.org): a data da última alteração relevante no conteúdo, não de qualquer deploy técnico do site.
• lastmod (sitemap.xml): um sinal para os crawlers sobre quando a URL mudou, usado mais para priorizar o recrawl do que para decidir qual data mostrar.

As causas mais comuns de o Google mostrar a data errada

Descartada a explicação acima, as causas mais frequentes de uma data errada no resultado são:

• O template imprime a data de carregamento no lado do cliente em vez de uma data fixa, então cada rastreamento vê um valor diferente.
• O conteúdo foi republicado ou sindicado em outro domínio, e o Google prefere a cópia que rastreou primeiro, atribuindo a data errada tanto ao original quanto à réplica.
• A página tem mais de uma data visível — “publicado em”, “atualizado em”, a data de um comentário, a data no rodapé —, e o algoritmo de extração escolhe a que não era a pretendida.
• O schema.org grava datePublished e dateModified com o mesmo valor mesmo depois de uma reescrita grande, então o Google não recebe nenhum sinal explícito de que algo mudou.
• Uma migração de CMS ou de domínio resetou o campo interno de criação do post, e o campo passou a refletir a data da migração, não a da publicação original.
• O Google ainda está mostrando uma versão em cache de antes da última edição, porque a URL não foi recrawleada com prioridade desde então.

Quando mudar a data é legítimo

Trocar a data — o dateModified e, se o design da página mostrar isso, também a data visível — é honesto quando o conteúdo de fato mudou de um jeito que afeta quem está lendo: um dado desatualizado foi corrigido, uma recomendação técnica mudou, uma seção inteira foi reescrita, um exemplo ou uma captura de tela foi substituída porque a interface real mudou. A régua prática é simples: se alguém que leu a versão anterior aprenderia algo novo e relevante lendo a versão atual, a atualização é real.

A forma correta de registrar isso é manter o datePublished original intacto, atualizar o dateModified para a data real da edição e, na página, preferir um rótulo do tipo “Atualizado em [data]” mantendo visível a data de publicação original, em vez de sobrescrever “Publicado em” com a data nova — o que apaga o sinal original e pode parecer manipulação mesmo quando a edição foi genuína. O lastmod do sitemap normalmente é atualizado automaticamente pelo CMS ao salvar; vale confirmar que isso realmente acontece.

Não é necessário — nem recomendável — mudar a data a cada ajuste cosmético, correção de digitação ou mudança de formatação. Reserve a atualização de data para mudanças que alterem o que o leitor entende ou faz depois de ler o texto.

Quando é manipulação, e como o Google trata isso

O padrão problemático é trocar apenas a data — visível, dateModified ou ambas — sem nenhuma mudança real no conteúdo, feito especificamente para parecer recente em buscas sensíveis a tempo ou para tentar ganhar uma vantagem de frescor no ranqueamento. A orientação pública do Google, reforçada mais de uma vez por representantes da equipe de busca, trata mudar a data sem atualizar o conteúdo de forma significativa como uma prática enganosa: o usuário lê um resultado que promete informação atual e recebe um texto que não mudou.

O risco não é necessariamente uma penalização algorítmica automática amarrada só ao campo da data. É, antes, um problema de confiança que se propaga: se o usuário clica esperando informação atualizada e encontra conteúdo estagnado, o comportamento resultante — voltar rápido para a busca, não interagir com a página — alimenta os mesmos sinais de qualidade que os sistemas de conteúdo útil do Google já avaliam para a página e, com o tempo, para o domínio inteiro. A prática também pode ser enquadrada como comportamento enganoso pelas diretrizes de spam do Google, o que abre espaço para ação manual se for identificada em revisão humana.

O teste prático continua sendo o mesmo do item anterior: se você consegue apontar exatamente qual parágrafo, dado ou recomendação mudou, a atualização é legítima. Se a única coisa que mudou foi o número no campo de data, não mude.

Como verificar qual data o Google está exibindo e por quê

Antes de tentar corrigir qualquer coisa, vale confirmar o que está acontecendo de fato:

• Pesquise a URL exata no Google e observe a data mostrada no snippet hoje, para confirmar que o problema ainda existe e não foi só uma versão antiga no cache do navegador.
• Rode a URL no Rich Results Test do Google para ver exatamente quais valores de datePublished e dateModified ele está lendo no HTML já processado.
• Use a inspeção de URL no Search Console e compare o HTML testado com o HTML ao vivo da página — divergências entre os dois geralmente apontam para um problema de renderização de JavaScript.
• Rode curl -I na URL para conferir o cabeçalho HTTP Last-Modified enviado pelo servidor, que também é um sinal lido pelo Google.
• Abra o sitemap.xml e confirme se o lastmod daquela URL específica foi realmente atualizado depois da última edição de conteúdo.
• Revise o código-fonte, não só o que aparece na tela, procurando por mais de uma marcação de data conflitante — dois elementos de horário diferentes, ou dois blocos de schema.org na mesma página.

Erros comuns ao lidar com a data de publicação

Alguns hábitos comuns acabam causando exatamente o problema que tentam evitar:

• Gerar um novo dateModified automaticamente em todo deploy do site, mesmo quando o deploy não tocou em nenhum conteúdo, o que destrói o valor do campo como sinal.
• Remover a data visível da página imaginando que, sem ela, o problema desaparece — sem notar que o schema.org continua entregando uma data ao Google por outro caminho.
• Gravar uma data futura por erro de fuso horário no servidor, o que pode fazer o Google desconfiar da página até recrawleá-la e perceber o erro.
• Ter um valor de datePublished na página e um valor diferente no bloco JSON-LD, o que sinaliza inconsistência técnica em vez de frescor.
• Editar o texto de verdade mas esquecer de atualizar o lastmod do sitemap, perdendo a chance de priorizar o recrawl da mudança real.
• Pedir reindexação manual repetidamente no Search Console só para “forçar” o Google a pegar uma data nova, sem que o conteúdo tenha mudado — o efeito prático é o mesmo de trocar a data à mão.

O Google demorou para atualizar a data: o que fazer

O Google não recrawleia instantaneamente depois de uma edição; a prioridade de recrawl depende do orçamento de rastreamento do site como um todo e da importância que aquela URL específica parece ter para ele. Depois de uma edição genuinamente substancial, use a inspeção de URL no Search Console para solicitar indexação — mas reserve esse recurso para mudanças reais, não para forçar uma data nova em conteúdo que não mudou. Garantir que links internos relevantes apontem para a página atualizada também ajuda o Google a encontrar e priorizar a mudança mais rápido.

Na prática, uma divergência que se corrige sozinha em dias ou semanas é normal e não precisa de intervenção nenhuma. O que garante, no longo prazo, que a data exibida corresponda à realidade não é nenhum ajuste isolado, e sim a consistência entre os quatro sinais — data visível, datePublished, dateModified e lastmod — apontando sempre para a mesma informação verdadeira.