What Counts as a Real Content Update: Dates, Republishing and lastmod

A change is a real content update when it changes what a reader learns or can do on the page: new or corrected facts, new sections, examples or data, a rewrite for a different intent. Only then should the page show a new “Updated” date. Typos, template changes and a new copyright year are not updates. This guide gives you a change-type table to make that call consistently, explains how the visible date, the dateModified in structured data and the sitemap’s lastmod should move together, what republishing actually does, and how to set CMS rules so dates stay honest without anyone thinking about it.

It matters for two reasons. Google lists changing dates to make pages seem fresh, when the content has not substantially changed, as a sign of content made for search engines first. And Google only uses your sitemap’s lastmod if it is consistently accurate, so a CMS that bumps every date on every save teaches Google to ignore the signal for your whole site. For the bigger picture of why pages lose ground, start with what content decay is and how to detect it.

Three dates, one rule

A page can carry three dates, and each is read by someone different.

The details come from Google’s byline dates documentation and its sitemap documentation. The rule that ties them together: a date moves only when something it describes has changed. The visible date and dateModified describe the content a reader sees. lastmod describes anything a crawler should come back for, which is a slightly wider set, as the next section shows.

What counts as a real update: a change-type table

Google’s sitemap documentation defines a significant change for lastmod as a change to the main content, the structured data or the links on the page, and says an updated copyright date is not one. For the visible date, Google gives no list, only the warning against changing dates without substantial changes. The table below is our working policy built on those two statements. The visible-date column is a judgment call, so write your own version down and apply it the same way every time.

Two cases need care. A title-tag change is not in Google’s list of significant changes, and it is not something a reader of the page sees as new content, so it moves neither date. And a page where you checked every fact and changed nothing has not been updated, however much work the check took. If you want readers to see that, show a separate “Reviewed” date, as described further down, rather than a new “Updated” date.

Published, updated or both?

Google asks for one prominent, labelled date and lets you choose the label. In practice:

• Keep the original published date. datePublished should not move when you update; that is what dateModified is for.
• Show both when you have updated substantially. “Published 3 March 2025 · Updated 12 October 2026” tells a reader the page has history and has been maintained.
• Say what changed on important pages. One sentence, such as “Updated with the 2027 holiday pay rates”, turns a date into evidence. It is the most useful thing a regulated or fast-changing page can show.
• Reduce competing dates. Google says that if it picks the wrong date, other prominent dates on the page, such as dates in related-article lists, can be the cause.
• No future dates, and no dates that describe an event rather than the page.

Republishing: what it actually does

“Republishing” means different things in different teams. Google’s guidance treats the patterns very differently:

For pages that recur every year, decide once between an evergreen URL you update each year and a new URL per edition. The evergreen URL keeps its links and history and suits “holiday pay rates” style pages. A new URL per edition suits reports where people cite a specific year. Mixing the two creates pages that compete with each other; see keyword-to-page mapping.

What a new date does, and does not, do

A new date is not a ranking boost. Google’s ranking systems guide describes freshness systems that show fresher content for queries where it is expected, which is not every query. Where freshness matters, it is the content that has to be fresh. A changed date on unchanged content gives the reader nothing new, and Google’s helpful content guidance names it, along with adding or removing lots of content mainly to seem fresh, as a warning sign.

What a real update does need is for Google to see it. Three things help:

• An accurate lastmod. This is the scalable signal. It only works if your sitemap has earned trust by being right.
• URL Inspection for a few important pages. Requesting indexing has a quota, and Google says crawling can take from a few days to a few weeks and that asking again does not speed it up.
• Not the sitemap ping. Google retired the sitemaps ping endpoint in 2023; submit sitemaps in Search Console or list them in robots.txt.

Make your CMS follow the rules

Most dishonest dates are not dishonest at all. They come from a CMS that sets “modified” on every save, a plugin that copies that value into dateModified and lastmod, and a template change that touches every record at once. Fix the system, not the editors:

1. Separate the system timestamp from the editorial date. Keep the CMS “modified” field for audit trails, and add an editorial “last substantive update” field that drives the visible date and dateModified.
2. Make the editor decide. A “this is a substantive update” checkbox on save, with the change-type table as its help text, plus an optional one-line note of what changed.
3. Drive lastmod from what changed. Compare a hash of the main content, the structured data and the in-content links with the previous version, and move lastmod only when one of them differs. Navigation and footer changes then never move it.
4. Exclude bulk operations. Template releases, migrations and plugin updates should be able to run without touching any editorial date.

How we do it on this site

This site follows the same rules, which is why the dates above this guide look the way they do. Every guide has a published date that never moves. It gets an updated date only when its content changed meaningfully, with a one-sentence note to readers about what changed. When the facts were rechecked and nothing needed changing, it gets a separate reviewed date instead, which is shown to readers but does not change dateModified. The sitemap dates guides from those same fields. For other pages, the sitemap’s lastmod is the date the page’s own files last changed in our repository, with a list of commits that are skipped because they changed files without changing what the page says, such as moving the site to a new folder.

Audit your dates

A date audit takes an afternoon on most sites and usually finds one of a few patterns. Check, for a sample of pages and then for the whole site:

• Every lastmod is the same date, or today’s date. The sitemap generator is stamping, not tracking. Google is likely ignoring it.
• The visible date is newer than the last real change to the text. Usually a template release or migration that re-dated everything.
• Visible date and dateModified disagree. Two systems writing dates independently.
• Pages with no date at all on content where readers would want one, such as rates, rules, prices and comparisons.
• Dates in the future, usually from time-zone handling or scheduled posts.

Fixing a re-dated page means putting back the date of its last real update, in the byline, in dateModified and in lastmod. That can feel like making the page look older. It is making it accurate, which is the point.

Where Morrison fits

Morrison’s site index records when each page’s main text last changed, because it compares the main content on every crawl; the URL grid’s Updated column shows it, and you can sort a section by it. Template and navigation changes do not count, because Morrison reads main content only. For the dates a page claims, chat can read the byline date, dateModified and the sitemap’s lastmod of the pages you ask about, and point out where they disagree or were stamped on the same day. See outdated content finder and the content refresh playbook for how to run the updates themselves.

Key takeaways

• An update changes what the reader learns or can do. Only then does the visible date move.
• lastmod is a little wider: main content, structured data or links, per Google. Never template changes or a copyright year.
• Keep the three dates consistent, and keep datePublished fixed.
• Republish at the same URL. A lightly edited copy at a new URL with a redirect is a practice Google calls out.
• Fix the CMS, not the editors: an editorial date separate from the system timestamp, and lastmod driven by what actually changed.