Published or Updated Date? When a Post Earns a New Date

A post earns a new date when a reader would get a different answer from it than they did before. That is the whole rule, and this guide spends its length on the edge cases: a corrected figure, a new section bolted onto an old argument, a merged pair of posts, a rewrite that keeps the URL. It is built on four Google Search Central documents and the schema.org Article type, read for this post, because the question "will Google punish me for changing the date" has a documented answer that is both less dramatic and more useful than the folklore.

The short version of what Google says: a byline date is Google's estimate, made from several signals, so no single field you set decides it. You may show a published date, an updated date, or both, as long as the visible and structured values agree. And in its guidance on helpful content, Google asks publishers directly whether they are changing the date of pages to make them seem fresh when the content has not substantially changed. Nothing in those documents says a date change is penalised. Everything in them says an inconsistent or inflated date is a signal Google will weigh against your other signals, and that it does not work anyway.

This matters for any archive that grows by refreshing old posts as much as by publishing new ones. If you are deciding which posts to refresh at all, our refresh prioritisation matrix covers that. This post is about what to do with the date once you have refreshed one.

Google's Search Central document on byline dates opens with a definition worth reading slowly: "A byline date is the date that Google estimates that the web page was updated or published." The operative word is estimates. The same document explains why: Google "doesn't depend on a single date factor because all factors can be prone to issues," so its systems "look at several factors to determine our best estimate of when a page was published or significantly updated." Google also says it does not guarantee a byline date, visible or structured, will be shown in results at all.

That reframes the whole decision. You are not setting the date Google shows. You are supplying one of several inputs to an estimate, and the estimate is about when the page was published or significantly updated, in Google's words, not when it was last touched. A visible "Updated" line that says today, a structured field that says last year and a sitemap that says every page changed this morning are three inputs that disagree, and the document's advice on consistency exists because disagreement makes the estimate worse, not because any one of the three is forbidden.

An example of the estimate working for you: a guide published in 2024, substantially rewritten in 2026 with its visible updated date, its dateModified and its sitemap entry all moved to the rewrite day. Three consistent signals, one plausible story. A failure case: the same guide with only the visible date changed, so the page says 2026 while the markup and sitemap still say 2024. Google now has a reason to trust its other factors over your visible date, which is the opposite of what the edit intended.

Google's byline-dates guidance names two of the places and its sitemap guidance names the third. The first is the visible page: "Add a user-visible date to the page and feature it prominently," and label it "with text like 'Publish' or 'Last updated'." Google's own examples include a plain "Published February 4, 2019", a "Last updated: Feb 14, 2018" and an "Updated Feb 14, 2019 8pm ET" with a time and timezone. The document states plainly that you "can provide a publication date and/or a last updated date."

The second is structured data. Google recommends a subtype of CreativeWork such as Article or BlogPosting with datePublished and/or dateModified. Its Article structured-data page defines them as the date and time the article was first published and most recently modified, both in ISO 8601 format, and recommends a timezone because otherwise Google defaults to the one Googlebot uses. Neither property is required; both are listed as recommended. The schema.org definitions match: datePublished is the date of first publication, dateModified the date the work was most recently modified.

The third is the sitemap's lastmod value, covered in section 07. The rule binding all three is consistency. Google asks that the date, and the optional time and timezone, "match between the equivalent user-visible and structured values," that dates are not in the future and do not describe the events in the story, and that you "minimize the presence of other dates on the page." The failure case that last line targets is familiar: a post with a published date in the byline, a different date in the sidebar's "recent posts" widget, a copyright year in the footer and a comment timestamp, all competing to be the estimate.

Google's guidance on creating helpful, reliable, people-first content is written as a self-assessment, and one of its questions is about exactly this decision: "Are you changing the date of pages to make them seem fresh when the content has not substantially changed?" The question sits beside a second one, about adding or removing a lot of content "primarily because you believe it will help your search rankings overall by somehow making your site seem 'fresh?'", to which Google appends its own answer in brackets: "(No, it won't)".

Read the two together and the position is clear without any penalty language. Google is not threatening the editor who moves a date. It is telling the editor that freshness-by-date is not a lever, and listing the practice among the things that mark content as made for search engines first. The practical consequence is reputational as much as algorithmic: a reader who notices that a post labelled "Updated October 2026" still cites 2023 prices has learned something about the site, and so has anyone deciding whether to cite it.

One example of the line being crossed in good faith: a CMS plugin that advances the modified date whenever a post is saved, so a batch of category-tag edits re-dates two hundred posts in an afternoon. Nobody intended to make anything seem fresh, and the self-assessment question still applies, because the content has not substantially changed. One example of the line not being crossed: a 2024 statistics post whose every figure is replaced with the 2026 release, with the old figures struck through in a change note. The date moves because the answer moved.

Google does not define "substantially changed" in the helpful content guidance, but its sitemap document comes close to a working definition for a related field. The lastmod value "should reflect the date and time of the last significant update to the page," and the document gives both sides of the line: an update to the main content, the structured data or the links on the page "is generally considered significant," while an update to the copyright date is not. That is a standard an editor can apply, and it is the one this guide adopts for the visible updated date as well.

The reader-facing version is the rule in the lede. Ask whether someone who read the old version would now get a different answer. A corrected price, a replaced statistic, a new recommendation, a removed section that was wrong, a new section that changes the conclusion: yes. A fixed typo, a tightened paragraph, a swapped image, a new internal link, a reformatted table: no, however long the edit took. Effort is not the test. The reader's answer is.

Two cases sit on the line and deserve a named decision. The first is the factual correction that changes a figure but not the argument: a 12% that should have read 21%. The answer changed, so the modified date moves, and the change is labelled as a correction rather than an update, because a reader who cited the old figure needs to know. The second is the new section that adds a related answer without touching the original one. The post now answers a question it did not before, so the modified date moves, and the published date stays, because the original answer is unchanged and still dated honestly.

The router below is the decision this post exists to make repeatable. Each row names an edit an editor actually performs, and the route says what happens to the published date, the modified date and the sitemap entry. The principle underneath is that datePublished answers "when did this page first exist" and dateModified answers "when did its content last significantly change", and the two questions have different answers for every row but the last.

The merge and republish rows are the only ones where the published date legitimately moves, and they move it for the same reason: the page at this URL is new. A post merged from three older posts is a new work with a new first-publication date, and the three old URLs redirect to it. A post republished at a new URL is likewise first published on the day the new URL went live. In both cases the honest signal is a fresh datePublished with a line in the text saying what the page replaces, not an old date carried over to borrow its age.

Google's examples use "Published" and "Last updated" as separate labelled lines, and that is the pattern to copy: both dates visible, each labelled, the updated line present only when the modified date differs from the published date. A single unlabelled date is the worst option, because the reader cannot tell which it is and neither can the estimate. A page that shows only an updated date is a close second, because it invites the suspicion that the published date was hidden to look newer.

The markup mirrors the page. datePublished carries the first publication; dateModified carries the last significant change; both in ISO 8601 with a timezone, per Google's Article guidance, and both equal to the visible values to the day. If you show a time on the page, show the same time in the markup, with a timezone that accounts for daylight saving, which Google's byline guidance calls out specifically. If you do not show a time, you may still provide one in the markup; Google says time and timezone are optional in the user-visible data even when provided in structured data.

One more place to check: the feed. An RSS or Atom feed carries its own published and updated timestamps, and many systems set the feed's updated value from the database row's save time, which is exactly the signal the self-assessment question is about. Treat the feed as a fourth copy of the date and bind it to the same rule. The table below is the checklist we use when a refresh ships.

Of the three places a date lives, the sitemap is the one most often set by a machine and least often looked at by a person, which is why it is where a good intention on the page turns into a bad signal in bulk. Google's sitemap document is specific about the standard: the lastmod value is used "if it's consistently and verifiably" accurate, with the example of Google comparing it to the last modification of the page. The same document says Google ignores the priority and changefreq values, so lastmod is the only per-URL signal in the file that carries weight at all.

The failure case is common on sites built with a static generator or a daily rebuild: the sitemap is regenerated on each build and every URL's lastmod becomes the build time. The page dates are honest and the sitemap says the whole site changed this morning. By Google's stated standard that value is neither consistent nor verifiable, and the sensible reading of the document is that Google stops using it. The site has thrown away a signal it could have had, and done so on every page at once.

The fix is mechanical. Derive lastmod from the same modified date the page shows and the markup carries, never from the build clock, and spot-check it after a refresh by opening the sitemap and confirming that only the refreshed URLs moved. If your platform cannot do that, a sitemap with no lastmod at all is more honest than one with a wrong lastmod on every line, and it costs you nothing Google has said it uses. When traffic falls after a refresh and you need to check whether a date signal is involved, the sitemap is the first file to open, as our traffic-drop diagnosis walks through.

A date without a reason is a claim; a date with a reason is a record. The simplest discipline that keeps an archive honest is a one-line entry for every refresh: the URL, the date, which of the six edit kinds it was, and what changed in a sentence. The visible "what changed" note on the page is the reader's copy of that line. The log is the editor's copy, and it answers the question a year later of why a post carries the date it does.

The log also makes the policy auditable in both directions. It shows the posts whose dates moved without a substantive reason, so they can be reverted. And it shows the posts whose content moved without the date following, which is the quieter failure: a corrected figure with no modified date and no note, so the reader who cited the old number is never told. The correction case is where this policy meets a second one, on how to label and word a correction, which deserves its own page. Both rest on the same fact-checking habits that Google's recent guidance on AI-assisted content describes, covered in our note on that guidance.

Finally, the log is what tells you when to stop refreshing a post and retire it instead. A post that has been re-dated four times in two years for small corrections is a post whose subject moves faster than its format, and the honest options are a maintained dataset or a redirect. Our keep, rewrite or retire decision covers that call, and building the editorial system that makes these decisions routine is part of what our content engine service does.