Published or Last Updated? Give Website Articles Dates That Describe the Content

An article's publication date, its latest substantive revision and the date of an event it discusses are different facts. Decide which dates your website shows and what each label means. Do not let a routine site rebuild silently turn every old article into newly published content.

For a business website, the useful outcome is a reader who can judge the age of the information and a content system that preserves the agreed meaning. Date markup may help a search engine interpret a page, but it is not a guarantee that a date will appear in search results or that the page will rank better.

Separate the article from the event it describes

Google's publication-date guidance says the relevant dates must describe when the page was published or updated, not the stories or events described on it. It also says not to specify future dates for those publication or update signals.

For a fictional workshop announcement, the workshop date can be in the future while the announcement itself was published earlier. The booking date belongs in the event information. It should not become the article's publication date simply because it is the largest date on the page.

Put these concepts into separate content fields. If you use event-specific structured data, scope that separately to the event rather than making article date fields perform both jobs. The cited guidance does not establish that every page qualifies for every structured-data type.

Choose visible labels that readers can understand

Google recommends a prominent user-visible date with an appropriate label, such as Published or Last updated. Its guidance allows a publication date, an update date or both.

For your editorial workflow, choose what readers need. An article with a material correction might retain its original publication date and show a clearly labelled update date. A page that has never been revised should not acquire an “Updated today” label merely because a deployment touched its output file.

That deployment rule is a practical recommendation about truthful content maintenance, not a claim that Google documents your particular build pipeline. Ask the developer where dates come from: editorial source records, database metadata or filesystem timestamps. Only the intended source should control the public labels.

Define what the editor's update action means

Do not make the developer guess whether fixing a typo, checking an unchanged source or rewriting a major section should change the public date. Establish an editorial policy and distinguish a review record from an actual content revision.

A sensible design keeps internal review history even when the visible article does not need a new publication claim. If a substantive correction changes what readers should do, consider a concise explanation of the change as well as the date. That is an editorial recommendation, not a search-result feature promised by the source.

Keep the original publication date available when it remains true. If content is migrated to a new system, decide how historical dates will be preserved instead of adopting the import date for every article. A migration is not automatically a new publication of the underlying advice.

Visible text and structured data should agree

The Google guide recommends suitable CreativeWork subtypes, such as Article or BlogPosting, with datePublished and/or dateModified fields. It asks that equivalent visible and structured dates match. Time and timezone are optional in the visible information even when they are included in structured data.

For acceptance, inspect the actual rendered page and its machine-readable values together. A visible old publication date paired with a newly generated structured publication date needs investigation. Do not assume the template is correct merely because its JSON parses.

Where timestamps include a timezone, the guidance says to use the correct timezone and account for daylight saving as appropriate. Retain the actual intended instant instead of silently reinterpreting a timestamp when the site changes hosting or locale.

Do not remove useful dates indiscriminately

Google says it considers several factors when estimating a byline date rather than relying on one signal. If it selects an incorrect date despite the recommended practices, the guide suggests considering removal of other dates from the page.

Treat that as troubleshooting advice, not an instruction to erase necessary event details or historical context. First identify which dates are present and whether their labels are clear. A meaningful deadline should not disappear merely to make an article's date simpler for a crawler.

The same documentation explicitly does not guarantee that a supplied byline date will be displayed in search results. Correct dates are a content-quality requirement; they are not evidence of indexing, increased traffic or a successful search presentation.

Test one old article and one real revision

Use a controlled copy of the site. Record an old article's visible and structured dates, then run an ordinary rebuild without changing its source. Confirm that those dates stay unchanged under your agreed policy.

Next make a test revision and exercise the actual editorial update action. Check which date changes and which remains original. Add an event date different from the publication date and verify the two roles stay separate. If your site has genuine language equivalents, check the agreed per-version dates rather than assuming all translations were published simultaneously.

Finally inspect the built and served versions, including listings that show dates. Record the actual result; a saved CMS form is not proof that a public template used the same value. No such production test is claimed in this article.

Should every deployment change Last updated?

Not under the recommended content-based policy. A deployment timestamp and a meaningful article revision serve different purposes. Agree the source and trigger explicitly.

Does dateModified replace the original publication date?

It represents a different concept. Where both dates are used, preserve their separate meaning and keep equivalent visible and structured values consistent.

Will Google display exactly the date I supply?

Not necessarily. Its guidance says dates are estimated from several signals and does not guarantee display of a supplied byline date.

Include the date policy in your website project brief and discuss the editing and migration requirements through website development.

Source and limits

Google Search Central: Influence your byline dates in Google Search. The source supports visible labels, structured date fields, consistency, correct timezone handling, event-date separation and the lack of a search-display guarantee. Revision triggers, migration preservation and the proposed rebuild tests are editorial and implementation recommendations, not measured search outcomes.