Technical SEO · September 17, 2026 · 8 min read
Does Changing the Publish Date Help? What Google Actually Uses for Freshness
Restamping a post is not a freshness signal — learn which queries actually reward recency, and the three places a date genuinely earns its keep.
By FluxWriter Team
Changing the publish date is the most common freshness tactic in SEO, and on its own it does almost nothing. The belief behind it is that Google reads a timestamp and rewards recency — what gets assessed is whether the content changed and whether the query wants something new. This covers what registers as a real change, the three places a date does real work, and whether recency is priced into your query at all.
Why the Date Stamp Is Not the Signal
Google indexes what a page says, not what its byline claims about when it was said. Those are two different objects.
The date you display is metadata. Freshness, as the ranking systems treat it, is a property of the content — whether the claims, the figures and the advice have moved since the last crawl. Edit a timestamp and you have changed zero words of main content. Nothing in the index moves.
There is a second-order effect worth naming, because it is why the tactic keeps getting reported as working. Saving a post in your CMS usually updates its lastmod value in sitemap.xml, and that can pull a crawler back in days rather than weeks. Change real content in the same save and the earlier recrawl finds it sooner. The date got the credit. The edit did the work.
You can settle this on your own site. Restamp 10 pages, change nothing else, and hold them for 6 weeks against a matched set you leave alone. Whatever you find applies to your queries and nothing else — the honest ceiling on every claim in this argument, including the ones here.
What Registers as a Change
Not every edit registers. The system compares your page against what it last stored, and cosmetic differences do not clear the bar.
Main content changes count. Rewriting the opening, replacing a section that was wrong, adding an answer the page never had — that reads as a different page. Boilerplate changes mostly do not. A new footer link, a swapped stock photo, a year bumped in the sidebar: none of it makes the page a better answer to anything.
There is no published threshold for how much has to change, and anyone quoting you an exact percentage is guessing at it. Use a reader test instead. If someone who knew the old version would notice the difference inside the first two scrolls, the edit is material. Twelve scattered word swaps across a 1,400-word post is not.
Crawl frequency is the other half of this, and it is where refresh programmes get misread. A page crawled every 2 to 3 days typically registers an edit inside a week. One on a newer site crawled every 4 to 6 weeks shows nothing until the crawler returns — the refresh has not failed, it has not been seen. Open URL Inspection in Search Console and read the last crawl date before you conclude anything.
Where Recency Changes Rankings
Only some queries carry a recency demand, and the gap between them is wide. Recency is applied per query rather than awarded per site. SEOs call it Query Deserves Freshness, and the label matters far less than knowing which side your query sits on.
Score each target query on how much recency it carries:
| Query type | Recency demand | What that means for the page |
|---|---|---|
| Breaking or event-driven | Decisive, measured in hours | Publish new, never restamp |
| Year-stamped comparisons | High, on an annual cycle | Rewrite and restamp yearly |
| Version- or price-dependent | Moderate, tied to releases | Refresh when the product changes |
| Stable definitions and how-tos | Low to none | Refresh only when the facts move |
| Seasonal or regulatory | Spikes 6–8 weeks ahead | Refresh before the window opens |
The row your page sits in decides whether a date edit is even a coherent idea. On the bottom two rows restamping is theatre — a 2018 explainer of a stable concept does not rank worse because it says 2018.
Reading the results page tells you which row you are in faster than any tool will. Search the query and look at the dates on the top 10. If eight of them fall inside the last 90 days, recency is being priced in. If the ages scatter across 6 years, your refresh budget belongs elsewhere. Count only the dates Google displays — never infer age from a URL carrying a year.
The Three Places a Date Does Real Work
Dates earn their keep in three places, and none of them is a ranking factor on its own.
The result snippet. Google displays a date on many results, drawing it from the visible date on the page, from structured data and from the URL. A result showing 2023 beside four competitors showing 2026 tends to lose clicks at identical position. By how much, nobody can tell you without your own click-through data.
Structured data. datePublished and dateModified should agree with the date a reader sees. Google's guidance on article dates asks for one consistent date across the page and its markup, and when the two disagree it infers a date itself. Your markup stops deciding anything. Show one date, mark it up once.
Sitemap lastmod. The value works as a crawl hint only while it stays honest, and most sites break it without noticing. Check yours before trusting it. Find two posts you have not edited in a year and read their lastmod in the live sitemap — if it matches your last deploy date, the file is reporting your build schedule rather than your edits.
What a Refresh Has to Change to Count
A restamped date is a promise to the reader, and the page has to be able to keep it. Read your own post the way a stranger would and mark every element that carries an age.
Four things go stale on a clock rather than on a ranking chart. Figures and prices are wrong the moment a vendor changes a plan. Screenshots age worst. Named tools and product versions drift too, and some of them have gone out of existence entirely since the page was written. Then the soft time words — "currently", "recently", "this year" — turn false with nobody editing them.
One element deserves its own rule. A year in the title is a commitment to rewrite annually, and an abandoned "2024 guide" does more damage than never having dated it. Maintain it or strip the year.
Fix: replace every figure, price and screenshot older than 18 months, cut the paragraphs describing a version nobody runs, and rewrite the sections your search data says are being asked differently now. Leave the rest alone. A refresh that touches everything is a rewrite, and it deserves to be measured as one.
Then restamp, once, on the day the rewrite ships. Give it 28 days before you judge it, and 6 to 8 weeks on a slowly crawled site. If position moved for an unrelated reason, the read is void.
When Restamping Backfires
Restamping a page you did not meaningfully change carries three costs, and a rank tracker shows none of them.
Reader trust goes first. Someone lands on a post dated last week, hits a 2019 screenshot in the second scroll, and leaves. That behaviour turns up in your own engagement data long before it turns up anywhere else. Broken expectations are expensive at exactly the moment you were trying to look current.
Measurement is the quieter cost. Every date change erodes your ability to say what a page's history actually looks like. Refresh 60 URLs in a batch, restamp all of them, and no clean before-and-after survives for a single one.
Then there is habit. Blanket restamping trains you to ignore your own signal — once every URL claims it was updated this month, your audit sheet stops telling you which pages are maintained. Keep the real review date in an internal field. Let the public date follow real edits only.
FAQ
Should I remove dates from my blog posts entirely?
No, and it rarely helps. Google infers a date from the URL, the markup and the page body whether you display one or not, so hiding it costs you the click-through benefit on genuinely current content while changing nothing at all about how the page gets assessed.
Does updating the year in the title work on its own?
Only when the content behind it changed too. A "best X in 2026" title over a 2024 comparison earns the click and loses the visit, and repeated mismatches show up as weak engagement on exactly the query you were chasing. Rewrite the comparison, then change the title.
How often should evergreen posts be refreshed?
Once every 12 to 18 months for most stable topics, and only where something has visibly moved — a price, a product version, or the ages of the pages now outranking you. Refreshing on a fixed quarterly schedule spends publishing slots on pages that were already fine.
The Practical Takeaway
Stop treating the date as a lever and treat it as a claim you have to back. Take your 10 highest-click posts untouched in 18 months and count how many of the top 10 results for their main query show a date inside the last 90 days. Fewer than 3 and recency is not priced in — leave the date alone. More than 6 and the page needs a rewrite: replace the stale figures and screenshots, cut the dead versions, restamp once on the day it ships, and keep the visible date and dateModified identical. Then wait 28 days. Start with the one post you would least want a prospect to open today.
If you are running that kind of cycle across a large library, tools like FluxWriter can help produce the replacement sections to a consistent spec — but deciding which queries reward recency, and whether a page has earned the new date on it, stays a judgement you make from your own data.