A frescura é uma propriedade da pesquisa, e uma atualização é uma mudança na página, não na sua data. O Google tem sistemas que favorecem páginas recentes em parte das pesquisas, e os seus próprios engenheiros descrevem uma tendência embutida a favor das antigas. O reflexo habitual em SEO, subir a data segundo um calendário, não diz ao Google nada que ele consiga verificar. Sabemo-lo porque o nosso próprio sitemap fez exatamente isso durante meses.
O que significa frescura nas pesquisas do Google (QDF)
No depoimento no processo antitrust US v. Google, Pandu Nayak deu três exemplos, citados numa análise da Hobo de 5 de outubro de 2026. Um fã de desporto quer páginas desta manhã. Quem compra um portátil quer análises do ano de modelo certo, não de hoje. Quem planeia um jantar com peru pode ficar melhor servido com uma receita de há dez anos.
O terceiro caso é o que os donos de WordPress saltam. A frescura não é um bónus que toda a página recolhe. Para muitas pesquisas a resposta certa é a página mais antiga e assente, e “atualizá-la” só a pode piorar. Antes de mexer num artigo, pergunte se a pesquisa dele espera novidade.
Porque é que o Google precisa de um sistema de frescura
A razão é mecânica. O Google ordena em parte pelo que os utilizadores clicaram antes, e Nayak descreveu o efeito secundário (a citação fica no original em inglês, como no depoimento):
O desafio da frescura e dos cliques é que os cliques se acumulam ao longo do tempo, o que significa que as páginas mais antigas, potencialmente desatualizadas, tendem a ter mais cliques do que as páginas recentes
Pandu Nayak, Google, Hobo Web, tradução própria
Uma página nova começa sem cliques, uma antiga tem anos deles. Nas pesquisas em que a frescura conta, o Google tem de compensar. Em todas as outras, os cliques acumulados fazem aquilo para que foram construídos.
Para quem gere um site seguem-se duas coisas. Um sistema de frescura serve para elevar páginas realmente recentes, por isso é construído para resistir a sinais baratos. E uma página fresca sem cliques parte com uma desvantagem que uma data nova não remove.
Mudar a data sem alterar o conteúdo
A Hobo cita um tweet de John Mueller de 5 de fevereiro de 2022, entretanto apagado:
Quando escreve algo novo, ou altera significativamente algo que já existe, então altere a data. Alterar a data sem fazer mais nada é apenas ruído e inútil.
John Mueller, Google, Hobo Web, tradução própria
O tweet desapareceu, por isso é discurso indireto e não documentação. O mesmo artigo cita uma pergunta das diretrizes do Google sobre conteúdo útil:
Está a alterar a data das páginas para as fazer parecer recentes quando o conteúdo não mudou substancialmente?
Google, orientações sobre conteúdo útil, Hobo Web, tradução própria
Leia outra vez a primeira frase do conselho de Mueller. Não diz para nunca mudar a data. Diz para a mudar quando se escreveu algo novo ou se alterou algo de forma significativa. Uma data é uma afirmação, e a regra é que a afirmação seja verdadeira.
O conteúdo evergreen precisa de ser atualizado
A Hobo lista outros tweets de Mueller, também apagados, e um deles é útil a quem tem guias que não precisam de mudar. Segundo a Hobo, dizia:
Se é intemporal, então, por definição, não precisa de o alterar. Não é preciso fazer nada de especial. Mantenha as datas, torne-o excelente.
John Mueller, Google, Hobo Web, tradução própria
Como o anterior, é reportado e não confirmável. Mas é coerente com o que Nayak disse sobre a receita de peru. Um guia estável tem a sua data original e não precisa de a perder. A tentação de o “refrescar” todos os trimestres vem de uma ideia errada de que o Google premeia o movimento. Premeia a resposta certa para a pesquisa, e para muitas pesquisas essa resposta já está escrita.
Fuga da Content Warehouse API e datas de frescura
A Hobo vai mais longe e sobrepõe os depoimentos a nomes de campos da documentação divulgada da Content Warehouse API: datas separadas para a assinatura, para o padrão do URL e um carimbo da última atualização significativa. O quadro é arrumado, e é inferência do autor. Ninguém no Google confirmou que esses campos movem o ranking de frescura como é descrito. Os depoimentos e as diretrizes públicas sustentam o princípio, e a história ao nível dos campos é uma leitura de uma fuga.
O conselho prático sobrevive sem ela. Uma página cuja data se mexeu enquanto o texto mal mudou parece, a qualquer sistema que compare versões, uma página com uma promessa que não cumpriu. Seja um campo com nome ou uma comparação geral, a tática não precisa de uma fuga para ser má aposta.
Mesma data lastmod em todos os URLs do sitemap
A 24 de agosto de 2026 medimos cinco dos nossos sitemaps em produção. Em cada um, todas as entradas tinham exatamente um valor de lastmod, a data do build. A integração do sitemap calculava a data atual uma vez e carimbava todos os URL com ela. O Google agenda novas visitas por lastmod só enquanto o valor se mantém verificavelmente verdadeiro. Um site em que cada URL declara uma mudança em cada build ensina o crawler a ignorar o campo. As datas do último crawl em páginas da amostra iam de três semanas a três meses atrás.
É o padrão data sem mudança, construído por nós, à escala do site inteiro, sem intervenção humana. A correção passou a usar updatedDate, ou pubDate na falta dela, e desde 29 de setembro um URL sem data de conteúdo conhecida não recebe lastmod nenhum, porque a ausência de data é melhor do que uma data falsa.
Medido hoje, o sitemap do blogue em inglês lista 329 URL com 100 datas de lastmod diferentes. É a forma de um site que muda em momentos diferentes. Não é um resultado limpo. 130 desses URL partilham um dia, 22 de setembro, e não auditámos se essas edições acrescentaram conteúdo. Se não, reconstruímos o problema em escala menor, um editor de cada vez.
Quanto tempo o Google demora a rastrear de novo uma página
Num evento Search Central Live, Gary Illyes mostrou tempos internos que Barry Schwartz relatou no Search Engine Roundtable. O refresh de um URL conhecido demora tipicamente cerca de 30 dias, no pior caso semanas ou nunca. O processamento do sitemap demora cerca de 24 horas, até 14 dias ou nunca. Illyes acrescentou uma ressalva:
tenham em conta que isto foi um exercício para ver se o público se identifica com os números que obtivemos internamente e colocámos nesses diapositivos.
Gary Illyes, Google, Search Engine Roundtable, tradução própria
São ordens de grandeza, não garantias. Mesmo assim mudam a forma de avaliar uma atualização. Quem edita um artigo à segunda e olha para o resultado à quarta não mediu nada. E se o refresh típico demora um mês, um lastmod honesto é a única maneira de dizer ao Google que esta página merece uma visita mais cedo.
O que conta como atualização no WordPress
O WordPress grava post_modified em cada gravação. Uma gralha, uma alteração em massa de categorias e um plugin que volta a gravar artigos movem o valor, e muitos plugins de SEO passam-no ao lastmod e à linha visível “atualizado em”. O comportamento por omissão da plataforma é publicar afirmações que ninguém verificou.
Uma atualização que merece data nova é:
- um número, preço ou versão que mudou, com a frase à volta
- uma secção acrescentada porque o tema cresceu
- uma recomendação invertida perante novas provas
- um prazo que passou, com o tempo verbal reescrito
Não é atualização:
- voltar a gravar para disparar um plugin
- reordenar parágrafos ou trocar uma imagem
- uma edição em massa de metadados em muitos artigos
- reler a página e não encontrar nada a mudar
Para o último caso usamos um campo à parte, lastVerified, separado de updatedDate: uma verificação é um facto que vale a pena registar, mas não é uma mudança de conteúdo.
Quando mudar a data de atualização de um artigo
- Abrir a versão anterior ao lado da atual. Se a diferença for só espaço, markup ou ordem, parar.
- Perguntar se a pesquisa espera novidade. Se não, uma data inalterada é honesta e segura.
- Se a mudança é real, escrever no texto o que mudou, perto do início ou do fim, para que uma pessoa veja o motivo e não só a data.
- Deixar o
lastmodseguir a data do conteúdo e mais nada. Verificar o próprio sitemap, não as definições do plugin, e contar os valores distintos.
A frescura ganha-se com uma mudança que um leitor ou um crawler consegue ver. Uma data só a pode registar, e uma data que não regista nada é o sinal mais barato que um site pode enviar e o primeiro que o Google aprende a ignorar.
QDF não serve sem um hábito de publicação em que GEO e LLMO possam confiar: atualiza factos, mantém o URL, mostra a data.
