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.
De onde vem o query deserves freshness
O nome é mais antigo do que qualquer fuga ou processo. A 3 de junho de 2007, Saul Hansell descreveu-o no The New York Times, num perfil de Amit Singhal, a quem o jornal chamou o mestre do algoritmo de ranking do Google. Segundo o artigo, o Google preferia até então páginas com idade suficiente para terem atraído ligações, e Singhal começou a desconfiar que o equilíbrio estava errado quando uma pesquisa por Google Finance não encontrava o novo serviço de cotações bolsistas do próprio Google.
A resposta da equipa, tal como Hansell a relata, foi um modelo matemático que tenta determinar quando os utilizadores querem informação nova e quando não querem. Chamava-se QDF, de query deserves freshness. Avaliava se um tema estava quente a partir de dois sinais: sites de notícias e blogues a escrever ativamente sobre ele, e o próprio fluxo de pesquisas do Google, que Singhal considerava o melhor indicador. O exemplo dele era um apagão em Nova Iorque, em que os primeiros artigos aparecem em 15 minutos e as pesquisas em dois segundos.
Dois pormenores de 2007 continuam a contar. Singhal explicou aos colegas que mudar simplesmente as fórmulas para mostrar mais páginas novas dava, na maior parte das vezes, resultados de pior qualidade, por isso a frescura nunca foi pensada como preferência geral por páginas novas. E o gatilho era a procura à volta de um tema, não a idade de uma página. Um artigo de WordPress não aquece a sua pesquisa mudando a própria data.
Que pesquisas os sistemas de frescura do Google visam
Hoje o Google documenta a ideia no seu guia dos sistemas de ranking, no plural: vários sistemas “query deserves freshness” concebidos para mostrar conteúdo mais recente nas pesquisas em que isso seria esperado. O guia dá dois exemplos. Quem pesquisa um filme acabado de estrear provavelmente quer críticas recentes e não artigos do início da produção. Uma pesquisa por “sismo” devolve normalmente material sobre preparação, mas depois de um sismo recente podem aparecer notícias e conteúdo mais fresco.
Os dois exemplos descrevem uma mudança no que a pessoa precisa, provocada por um acontecimento fora da página. Nenhum descreve uma página que melhorou por receber uma data nova. Bate com a receita de peru do depoimento de Nayak: um sistema feito para detetar procura de novidade não tem nada para premiar quando essa procura não existe. Para um site WordPress, a pergunta útil é quais das suas pesquisas alguma vez se comportam como “sismo”. Para a maioria das páginas de serviços e dos guias práticos a resposta é nenhuma, e nessas páginas a data é um registo, não uma alavanca.
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:
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.
O que diz o Google sobre mudar datas
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.
A pergunta não vem só de fontes indiretas. Continua no próprio guia do Google sobre criar conteúdo útil, fiável e pensado para pessoas, atualizado a 5 de outubro de 2026, seguida de uma segunda pergunta dirigida ao mesmo reflexo à escala do site inteiro:
Está a acrescentar muito conteúdo novo ou a remover muito conteúdo antigo sobretudo porque acredita que isso vai ajudar o ranking do site no seu conjunto, fazendo-o de alguma forma parecer “fresco”? (Não vai.)
Google Search Central, Criar conteúdo útil, tradução própria
A resposta entre parênteses é do Google, não nossa. Abrange a publicação em massa e a limpeza em massa feitas para parecer fresco, que é a versão de site inteiro de subir uma data.
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.
O que o Google considera uma alteração significativa para o lastmod
A documentação de sitemaps do Google fixa a fasquia em duas frases. O Google usa o valor de lastmod se for consistente e verificavelmente exato, por exemplo comparando-o com a última modificação da página, e o valor deve refletir a data e hora da última atualização significativa. Os exemplos dados: uma alteração ao conteúdo principal, aos dados estruturados ou às ligações da página é em geral significativa, a atualização da data de copyright não é. A mesma página diz que o Google ignora priority e changefreq, por isso esses dois campos também não transportam nenhum sinal de frescura.
Esta definição é mais estreita do que aquilo que o WordPress regista como modificação e mais larga do que muitos editores supõem. Uma nova ligação interna ou um dateModified corrigido no schema contam. O ano do rodapé mudado pelo tema, uma nova gravação ou um plugin que regrava artigos ao ser ativado não contam. “Verificavelmente” é a palavra que faz o trabalho: o Google pode comparar a data declarada com o que obteve da última vez, e o nosso carimbo com a data do build falhou essa comparação em todos os URL ao mesmo tempo.
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.
Como o Google escolhe a data mostrada nos resultados
A data por baixo de um resultado é uma questão à parte do lastmod. O guia do Google sobre datas diz que não depende de um único fator de data, porque todos podem ter problemas, e que olha para vários para estimar quando uma página foi publicada ou atualizada de forma significativa. Não garante que alguma data seja mostrada.
O guia pede uma data visível para o utilizador, em destaque e identificada com texto como “Publicado” ou “Última atualização”. Nos dados estruturados recomenda um subtipo de CreativeWork, como Article ou BlogPosting, com datePublished e/ou dateModified. A data visível e o valor estruturado devem coincidir, o fuso horário, se indicado, deve estar certo, e a data tem de descrever a publicação ou a atualização da página, não uma data futura nem a data de um acontecimento descrito na página. Se o Google continuar a escolher a data errada, o guia sugere remover algumas das outras datas da página.
No WordPress isto quer dizer que três sítios transportam a mesma afirmação: a linha visível “atualizado em”, o dateModified no schema impresso pelo plugin de SEO e o lastmod no sitemap. Se um deles se mexe em cada gravação e os outros não, a página contradiz-se. Se os três se mexem em cada gravação, a página é coerente e continua falsa. A correção é a que aplicámos ao sitemap: uma data de conteúdo, mudada só por um editor que mudou o conteúdo, e todas as saídas leem essa data.
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.
