When should you change the published or updated date on a blog post?

A date on an article looks like metadata, but readers interpret it as a claim. “Updated July 2026” suggests that someone revisited the substance and that the page reflects what they found. Changing the date after fixing a typo may create a fresh-looking result, but it weakens the meaning of the signal.

The right question is not whether changing a date might improve clicks. It is whether the revision materially changes what a reader can trust, decide, or do.

Separate published date from modified date

The original publication date records when the article first became available. A modified date records a later substantive revision. They answer different questions and should not be casually substituted for each other.

Google’s Article structured-data documentation supports both datePublished and dateModified and recommends accurate ISO 8601 values with timezone information. Markup can help a system interpret the page, but it cannot make a cosmetic edit substantial.

Keep the original publication date stable unless your CMS and editorial model intentionally treat the new version as a new work. For normal evergreen maintenance, preserve publication history and update the modified date when the work justifies it.

Use a materiality ladder

Classify the change before touching the date.

Level 1: correction

Examples:

• Fixing spelling or punctuation

• Repairing a broken link without changing the source

• Adjusting formatting

• Replacing a low-resolution image with the same information

These changes improve the page but usually do not justify a new visible modified date.

Level 2: maintenance

Examples:

• Updating a product name

• Replacing one outdated screenshot

• Correcting a small factual detail

• Adding a short clarification

Maintenance keeps the article usable. Whether to update the date depends on how central the change is. A corrected price in a pricing guide matters more than a renamed menu item in a long tutorial.

Level 3: substantive revision

Examples:

• Rechecking all major claims and sources

• Rewriting the decision framework

• Updating a process after a platform changed

• Adding an important missing scenario

• Revising examples, recommendations, and conclusions

This normally supports a new modified date. The article now offers meaningfully different guidance.

Level 4: replacement

The old article’s job, audience, or central argument no longer fits. The team creates a fundamentally new work at the same URL.

This may warrant a prominent change note and careful editorial judgment about how the page is presented. A preserved URL does not mean the content has a continuous identity.

Test the change with three questions

Before changing a visible date, ask:

1. Would a returning reader learn something materially different?

2. Did someone verify the sections most likely to become outdated?

3. Can the editor describe the revision in one concrete sentence?

If the answers are no, the new date probably overstates the work.

“Updated for freshness” is not a concrete sentence. “Rechecked the platform requirements, replaced the obsolete setup path, and added a migration example” is.

Do not confuse age with inaccuracy

Some articles remain useful for years because the underlying question is stable. Others become risky within months because laws, prices, interfaces, or product capabilities change.

Set review frequency by volatility:

• High volatility: legal guidance, product features, pricing, platform instructions

• Medium volatility: tactical playbooks, tool comparisons, market examples

• Low volatility: durable principles, original research with a fixed study period, historical analysis

A review can conclude that no substantive update is needed. Record the review internally without manufacturing a new public date.

Show readers what changed

A short change note makes the date meaningful:

Updated July 2026: revised the consolidation decision matrix, verified Google’s current canonical guidance, and added migration checks for redirect chains.

The note does three things. It defines scope, helps returning readers find the new value, and creates accountability for the editor.

Avoid vague notices such as “updated for 2026” when the change is merely a year in the title. If the article depends on a year, explain what was actually reverified.

Work through four examples

A typo and one broken outbound link

Fix both. Keep the existing modified date. Log the maintenance if your team tracks edits.

A tutorial after the interface changed

Walk through the process again. Replace screenshots and instructions. Verify that the outcome still works. Update dateModified and add a change note.

An opinion article with a new paragraph

If the paragraph clarifies but does not alter the thesis, a new date may not help. If the author revises the position in response to new evidence, disclose that substantive evolution.

A comparison with changed pricing and features

Recheck every compared option, not just the winner. Record the check date and sources. Update the modified date because the decision support has materially changed.

Align the visible page and technical fields

Your CMS, page copy, structured data, sitemap, and social metadata should not tell conflicting stories.

• Keep datePublished accurate.

• Set dateModified to the substantive revision time.

• Display dates consistently where readers can interpret them.

• Avoid a visible “updated” label with stale structured data.

• Do not automatically change modified dates whenever a build runs.

Automatic timestamps are a common implementation mistake. A theme change or deployment can make every article appear newly modified even though no editor reviewed the content.

Create a compact editorial policy

Write five rules the team can apply without a meeting:

1. Typographical and formatting corrections do not change the public date.

2. Material factual, procedural, or recommendation changes do.

3. The original publication date is preserved.

4. Every substantive revision receives a concrete change note.

5. High-volatility pages have named owners and review intervals.

Add examples from your own content. Policies become usable when editors can compare a real change with a prior decision.

Let usefulness, not freshness theater, drive the update

Google’s people-first guidance emphasizes original value, reliable sourcing, clear expertise, and a satisfying reader outcome. Those are better reasons to revisit a page than the desire to make an old date disappear.

An honest modified date is a small trust mechanism. Protect it. Review content according to risk, make substantial changes when they are needed, and tell readers exactly what improved.

Make review evidence easy to inspect

For high-volatility pages, keep a private review note containing the reviewer, sections checked, sources revisited, changes made, and next trigger. The public change note can remain short; the internal record proves what “updated” meant.

This also helps when a review finds no required revision. Record that the price, instructions, or rule was checked and remained accurate. The page keeps its existing public modified date, while the team still knows maintenance occurred.

If several pages depend on the same changing source, connect them to one evidence record. A source update can then trigger a bounded review across affected articles instead of waiting for readers to discover inconsistencies.

The policy should survive staff changes. A future editor ought to understand why one page received a new date and another did not without reconstructing personal judgment from the CMS history.

That consistency also helps readers interpret the dates across the whole site instead of guessing whether each article follows a different freshness rule.