There's a trick that's been around as long as blogs have had dates. Open an old post, change "Updated: March 2022" to today, maybe swap a sentence, hit publish. The page looks fresh. Nothing else happened.
We don't do it, and we'd rather you didn't either. Not because it's sneaky (though it is, a little). Because it doesn't do what people hope, and it spends something you'll want later: a date your readers and search engines can believe.
What Google says, in plain terms
Google's guidance on creating helpful content includes a self-assessment list. Two of its questions are aimed straight at this habit. Paraphrasing closely:
- Are you changing the date of pages to make them seem fresh when the content hasn't substantially changed?
- Are you adding or removing a lot of content mainly because you think it'll make your site seem "fresh" to search? Google answers that one itself: "No, it won't."
Its sitemap documentation makes a related point about the lastmod date in your XML sitemap. Google says it uses that date only when it's consistently and verifiably accurate, and that it should reflect the last significant update to the page: the main content, the structured data or the links. A new copyright year in the footer doesn't count.
That's our reading of those pages at the time of writing, October 2026. Google edits its documentation regularly, so read the current versions on Search Central before you set a policy for your team.
Substantial or cosmetic?
Most of the confusion sits here. "Substantially changed" isn't defined by a word count, so we use a plain test: would a returning reader learn something they couldn't have learned from the old version?
| Counts as a real update | Doesn't, on its own |
|---|---|
| Prices, rates or ranges brought up to date | Changing the date |
| Steps rewritten because the product, rule or process changed | Fixing typos |
| A new section answering a question readers actually ask | Swapping the header image |
| Wrong or outdated advice corrected or removed | Rewording sentences without changing what they say |
| Sources rechecked, dead links replaced with live ones that support the claim | Adding the current year to the title |
| Two overlapping posts merged into one stronger page | Adding 300 words of general padding |
| New examples or screenshots from your own work | Reordering the sections |
The right-hand column isn't useless. Typos should be fixed. It just isn't a reason to tell the reader the page is new.
Combinations take judgment. Three dead links replaced and a price updated on a 2,000-word guide? If the price is what people came for, we'd call that a real update. A new intro paragraph and nothing else? No.
Two dates, two jobs
People mix these up, so here they are separately.
The visible date on the page is for readers. It tells them how current the information is. If you show one, it should move only when the substance moves. Showing both "Published" and "Updated" is the most honest option for anything more than a year old.
The lastmod date in your sitemap is for crawlers. Most content systems set it automatically, and plenty set it badly: every URL stamped with today's date, or every URL sharing the date of a site migration. If those dates can't be trusted, Google is free to ignore them.
You can check yours in about a minute. Our free sitemap decay scanner flags three patterns that suggest the dates aren't reliable: every URL dated identically, every URL dated today, or no dates at all. It reads only your public sitemap.
What a change log looks like
If the date is going to mean something, there has to be a record of what changed. This is the format we fill in for every refresh. Sample, no client data.
| Field | Sample entry |
|---|---|
| URL | /blog/how-much-does-a-roof-inspection-cost/ |
| Date | 2026-10-07 |
| Type | Refresh (½ slot) |
| What changed | Price ranges updated against the current rate sheet. Section on drone inspections added. Two dead sources replaced. Outdated insurance paragraph removed. |
| What didn't | Structure, intro, FAQ answers 1–3 |
| Visible date | "Updated" date set; original "Published" date kept |
| Sitemap lastmod | Updated |
| Title and meta | Meta description rewritten; title unchanged |
| Internal links | One link added to the roof inspection service page; one link fixed that pointed through a redirect |
The "What didn't" row is the one people skip and later wish they hadn't. When someone asks a year from now why traffic moved, it's the most useful line in the log.
The log also keeps your own process honest. If you can't fill in "What changed" with something a reader would care about, the page probably shouldn't get a new date.
A short policy you can borrow
If your team needs a rule, this one fits on a sticky note:
- The visible "Updated" date moves only when something from the left column of the table above happened.
- Sitemap lastmod follows the same rule. If your system bumps it on every save, fix the setting or the plugin.
- Every date change gets a change-log line.
- Keep the original "Published" date. Never reset it.
- When in doubt, leave the date alone. Nothing bad happens to an accurate old date.
Why we're strict about this
Maintenance is most of what we do. In our pricing a refresh is half a slot, and clients pay for those refreshes, so the change log is how they see what they bought. If we bumped dates on pages we hadn't really changed, the log would be fiction and the work would be invisible.
That's why "fake date bumps" sits on our list of things we won't do, right next to guaranteed rankings.
If you'd like help
A refresh pack is $1,350 for five existing pages of up to 2,500 words each. Up to about half of each page gets rewritten, sources are checked, internal links added, title and meta updated, an FAQ added where it's useful, and you get a change log with before-and-after notes. It's delivered 10 business days after we get CMS access.
For ongoing upkeep, see our content refresh service. And if you're not sure which pages deserve the work in the first place, start with refresh, merge or delete?
A real update doesn't promise a ranking change. Results depend on far more than one page, and Google changes its systems often. What it does give the reader is a page that's actually current, which was the point of putting a date on it.
