'Last Updated' Dates on AI Buyer Guides: When Changing the Date Helps, When It's Deceptive, and What Google Checks
Every content-management system makes it a one-click job to stamp today's date on an old post, and every affiliate forum has someone reporting that it "worked". It didn't; what worked, when something did, was the update that went with it.
Google reads a page's date from more than the number on it, treats a date the content doesn't support as noise, and treats a site full of such dates as a pattern. On a buyer guide, where the content really does go stale, the date matters, which is exactly why faking it costs more here than elsewhere.
This post covers what Google actually reads to decide a page's date, why a date bump with no change gets ignored (or worse), what counts as an update worth dating, how to display published and modified dates, what the date does on freshness-sensitive queries, and how a refresh tool should set it.
It's the date half of the refresh post, which covers what to change; this is how to tell Google and the reader that you did.
The short answer
Keep the published date; move the modified date only when the content changed in a way a returning reader would notice. Show both. Put the modified date in the structured data (dateModified) and visibly on the page, and make them agree.
Add a one-line "what changed" when you update. Never bump a date on unchanged content: it does nothing for the page and counts against the site.
What Google reads
| Signal | Where | Weight |
|---|---|---|
| datePublished and dateModified | The Article structured data | High, when the visible date and the content agree with it |
| The visible date on the page | Byline or an "Updated" line near the title | High; Google says it looks for a clearly labelled visible date |
| Whether the content actually changed | Google's own comparison of the page against its last crawl | The corroboration; without it the dates above are discounted |
| Dates in the URL, sitemap lastmod, HTTP headers | Various | Weak on their own; sitemap lastmod is explicitly meant to reflect real changes |
Google's documentation on dates says it uses several factors and that the date should be the one the content supports. Read plainly: the markup and the visible date are what it shows; the content change is what makes it believe them. The schema post covers the Article markup where the two dates live.
Why a bump with no change fails
Three outcomes, none good. If the content didn't change, Google's comparison with the last crawl shows nothing moved, and the new date is discounted; the page stays where it was. If the site does it across many pages, the pattern of claimed freshness without real change is a quality signal in the wrong direction.
And a reader who arrives at a guide "updated this week" and finds products that were discontinued last year, or comments from three years ago, stops trusting the site, which costs the conversion the date was supposed to protect.
What counts as an update
- Counts: a pick replaced; prices and availability refreshed through the API; a section rewritten for a new model; a verdict changed; the comparison table re-ranked; a FAQ answer corrected; a dead link replaced.
- Doesn't count: a typo fixed; a stock image swapped; a sentence of padding added; the year changed in the title; a paragraph reordered.
The test is the "what changed" line. An update worth dating has one ("November 2026: the Metro Pro 800 is discontinued; the v2 replaces it as the commuter pick"). If there's nothing honest to put there, the date stays.
Displaying published and modified
Both, near the title: "Published 14 March 2025 · Updated 4 November 2026". The published date establishes the page's age, which Google and readers both treat as a trust signal for a guide that's been maintained. The modified date says it's current.
Showing only the modified date, or overwriting the published date, hides the history that makes the update credible and sets up the contradiction when a reader finds an old comment. The structured data carries the same two values, and they match what's displayed.
Freshness-sensitive queries
Some queries get a freshness boost: anything with a year in it, "best X" in categories where models change yearly, anything about a current sale. On those, a guide genuinely updated last month with the date to prove it has an edge over one last touched in 2024.
That edge is real and it's why the refresh cycle matters; it's also why the fake version is tempting. The titles post covers the year-in-the-title question, which is the same trade-off: a year helps when the content is current and hurts when it isn't.
How a refresh tool should set the date
- Update the post in place on the same URL; never create a new post for a refresh.
- Leave datePublished and the visible published date alone.
- Set dateModified and the visible "Updated" line to the refresh date, because the picks, prices and sections changed.
- Update the sitemap's lastmod for the URL at the same time.
- Surface a "what changed" line, or make it easy to add one.
- Do none of the above when the refresh found nothing to change.
Doing it with AffSERP
AffSERP's Refresh option regenerates a guide from current product data and updates the WordPress post in place: same URL, same published date, the modified date set to the refresh because the picks, prices and sections genuinely changed, and the sitemap's lastmod following from WordPress.
The "what changed" line is yours to add in the editor, and it's worth the minute; it's the sentence that turns a new date into something both Google and the reader can believe.
FAQ
Does updating the date on a blog post help SEO?
Only when the content changed in a way that matters. Google reads several signals for a page's date (the dateModified in the structured data, the visible date on the page, and whether the content itself moved) and is explicit that it doesn't trust a date that disagrees with the content. A real update (picks replaced, prices refreshed, a section rewritten) with the date moved to match can lift a guide on freshness-sensitive queries. A date moved on an unchanged page does nothing, and on a site that does it everywhere it reads as manipulation.
Should I change the published date or the modified date?
The modified date. The published date is when the page first went live and stays; dateModified (and a visible 'Updated' line) is what moves when you update. Changing the published date to today on an old post makes it look new to readers who then find a 2022 comment under it, and tells Google two different stories at once. Keep both, show both, move only the second.
What counts as an update worth changing the date for?
Something a returning reader would notice: a pick replaced, prices and availability refreshed through the API, a section rewritten for a new model, a verdict that changed, a FAQ answer corrected. Fixing a typo, swapping a stock image or adding a sentence of padding doesn't. The honest test is whether you'd put a 'what changed' line at the top; if there's nothing to write in it, leave the date.
Does Google penalise fake 'last updated' dates?
There's no named penalty, but Google says it uses multiple signals to decide a page's date and won't rely on one it can't corroborate, so a bumped date on unchanged content is simply ignored. Site-wide, a pattern of dates moving without content moving is the kind of signal the helpful-content systems weigh against a site. The downside is real; the upside of the trick is zero.
AffSERP's Refresh updates the post on the same URL, keeps the published date, and moves the modified date because the picks, prices and sections changed.
Start with free wordsKeep reading
