Freshness is a property of the query, and an update is a change in the page, not in its date. Google does run systems that favour recent pages for some searches, and its own engineers describe a built-in bias toward old ones. The usual SEO reflex, bumping the date on a schedule, tells Google nothing it can verify. We know because our own sitemap did exactly that for months.
What query deserves freshness means
In his testimony in the US v. Google antitrust trial, Pandu Nayak gave three examples, quoted in a Hobo analysis of the transcripts from 5 October 2026. A sports fan wants pages from this morning. A laptop buyer wants reviews from the right model year, not today’s. Someone planning a turkey dinner may be better served by a recipe that is ten years old.
That third case is the one WordPress owners skip. Freshness is not a ranking bonus every page can collect. For a large share of queries the older, settled page is the correct answer, and “updating” it can only make it worse. Before touching a post, ask whether its query is one where recency is expected.
Why old pages get more clicks in Google
The reason is mechanical. Google ranks partly on what users clicked before, and Nayak described the side effect:
The challenge with freshness and clicks is that clicks accrete over time, which means older pages, potentially stale pages, tend to have more clicks than fresh pages
Pandu Nayak, Google, Hobo Web
A new page starts with no clicks and an old page has years of them. For queries where recency matters, Google has to compensate. For every other query the accumulated clicks do what they were built to do.
Two consequences for a site owner. A freshness system exists to lift pages that are genuinely recent, so it is built to resist cheap signals. And a fresh page without clicks is competing against a handicap that a date change will not remove.
Changing the post date without changing the content
Hobo cites a 5 February 2022 tweet by John Mueller, since deleted, that reads:
When you write something new, or significantly change something existing, then change the date. Changing the date without doing anything else is just noise & useless.
John Mueller, Google, Hobo Web
The tweet is gone, so treat it as reported speech, not documentation. The same article quotes a question from Google’s helpful content guidance:
Are you changing the date of pages to make them seem fresh when the content has not substantially changed?
Google, helpful content guidance, Hobo Web
Read the first sentence of Mueller’s advice again. It does not say never change the date. It says change it when something new was written or something was significantly changed. A date is a claim, and the rule is that the claim has to be true.
Content Warehouse API leak and freshness dates
Hobo goes further and maps the testimony onto field names from the leaked Content Warehouse API documentation: separate dates for the byline, for the URL pattern, and a timestamp for the last significant update. The picture is tidy, and it is the author’s inference. Nobody at Google confirmed that those fields drive freshness ranking the way the article lays them out. The trial testimony and the public guidance support the principle, and the field-level story is a reading of a leak.
The practical advice survives without it. A page whose date moved while the text barely did looks, to any system that compares versions, like a page that made a claim it did not keep. Whether that is a named field or a general comparison, the tactic does not need a leak to be a bad bet.
Same lastmod date for every URL in the sitemap
On 24 August 2026 we measured five of our sitemaps on production. Each had exactly one lastmod value for every entry, the date of the build. The sitemap integration computed the current date once and stamped it on all URLs. Google schedules revisits from lastmod only while the value stays verifiably true, so a site where every URL declares a change on every build teaches the crawler to ignore the field. The last crawl dates we sampled for individual pages ranged from three weeks to three months back.
That is the date-without-change pattern, built by us, at scale, with no human involved. The fix took the date from updatedDate, falling back to pubDate, and from 29 September a URL with no known content date gets no lastmod at all, because an absent date is better than a false one.
Measured today, the English blog sitemap lists 329 URLs with 100 distinct lastmod dates. That is the shape of a site that changes at different times. It is not a clean result. 130 of those URLs share one day, 22 September, and we have not audited whether those edits added content. If they did not, we have rebuilt the problem on a smaller scale, one editor at a time.
How long Google takes to recrawl an updated page
At a Search Central Live event, Gary Illyes presented internal timings that Barry Schwartz reported at Search Engine Roundtable. A refresh of a known URL typically takes about 30 days, with the slowest cases at weeks or never. Sitemap processing takes about 24 hours, up to 14 days or never. Illyes added a caveat:
mind that this was an exercise to see if the audience can relate to the numbers we pulled internally and put in those slides.
Gary Illyes, Google, Search Engine Roundtable
So these are orders of magnitude, not guarantees. They still change how to judge an update. If you edit a post on Monday and look at the result on Wednesday, you have measured nothing. And if a typical refresh takes a month, an honest lastmod is the one way to tell Google that this page is worth visiting earlier than its schedule says.
What counts as an update in WordPress
WordPress records post_modified on every save. A typo fix, a bulk category change and a plugin that re-saves posts all move it, and many SEO plugins pass that value to lastmod and to the visible “last updated” line. So the platform’s default is to publish claims nobody checked.
Treat these as updates, worth a new date:
- a figure, price or version number that changed, and the sentence around it
- a section added because the topic grew
- a recommendation reversed after new evidence
- a deadline that passed, with the tense rewritten
These are not updates:
- re-saving to trigger a plugin
- reordering paragraphs or swapping an image
- a bulk edit of metadata across many posts
- re-reading the page and finding nothing to change
For the last case keep a separate field. We store lastVerified apart from updatedDate for this reason: verification is a fact worth recording, but it is not a content change. Deadline content needs the strictest handling, because a post written as advice before a date turns false on that date. A fresh lastVerified does not catch the future tense still standing in the text.
When to change the updated date on a post
- Open the previous version next to the current one. If the diff is only whitespace, markup or order, stop.
- Ask whether the query expects recency. If not, an unchanged date is the honest and safe choice.
- If the change is real, say what changed in the text, near the top or bottom, so a human sees the reason as well as the date.
- Let
lastmodfollow the content date and nothing else. Check the sitemap itself, not the plugin settings, and count the distinct values.
Freshness is earned by a change a reader or a crawler can see. A date can only record that change, and a date that records nothing is the cheapest signal a site can send and the first one Google learns to ignore.
QDF is useless without a publish habit that GEO and LLMO can trust: update the facts, keep the URL, show the date.
