Visible Dates And Freshness Signals

Dates change behaviour on both sides: readers skip a guide dated three years ago, and results show dates on some queries. That tempts teams into restamping pages that did not change, which is visible to anyone comparing two versions and destroys the signal for pages that genuinely were updated. Whether a date moves rankings is argued; that it moves clicks is not. The harder question is which page types should carry a date at all, and that is a policy per type rather than a site-wide switch.

The skill file

---
name: on-page-freshness-signals
description: Use when deciding what date a page should show, or when someone proposes bumping updated dates across the site.
---

# Visible Dates And Freshness Signals

Dates change behaviour on both sides: readers skip a guide dated three years ago, and results show dates on some queries. That tempts teams into restamping pages that did not change, which is visible to anyone comparing two versions and destroys the signal for pages that genuinely were updated. Whether a date moves rankings is argued; that it moves clicks is not. The harder question is which page types should carry a date at all, and that is a policy per type rather than a site-wide switch.

## What you need first

- The list of page types on the site and what each is for
- Current dating behaviour per type: published, updated, both or none, and where each value is stored
- What the CMS writes to dateModified in structured data, which is often the last save of any field

## Method

1. Decide per page type whether a date helps the reader. A tutorial against a versioned product needs one; a definition or an about page usually does not.
2. Where a date helps, show the updated date with the original publication date still available. Replacing the publication date reads as concealment to anyone who checks an archive.
3. Define in writing what counts as an update before allowing the date to move: a factual correction, a version change, a rewritten section. A typo fix is not one.
4. Inspect what the CMS writes to dateModified. Many write it on any save, including a tag edit, which puts a fresh date in the markup while the visible date stays correct, and the two then contradict each other.
5. When you do refresh, state in one line what changed and when. It is the cheapest way to make a new date credible and it survives a sceptical reader.
6. Refuse bulk date updates. The pattern is visible in archives and in the markup, and it removes any ability to tell which refreshes actually worked.
7. Schedule reviews against whatever makes each type go stale, such as a product release cycle or a regulatory change, rather than a fixed calendar interval unrelated to the content.

## What this produces

A dating policy per page type, the rule for what counts as a restampable update, and the CMS setting that keeps markup and visible date in agreement.

## Where this goes wrong

- Restamping without editing, which is easy to detect and costs credibility with readers before it costs anything in search
- Letting dateModified drift away from the visible date, so the page contradicts itself
- Stripping dates from everything to avoid looking stale, which also removes the reason to trust a page that is genuinely current

---

From the QuQi skill library - https://www.quqi.io/skills/on-page-freshness-signals

What you need first

• The list of page types on the site and what each is for
• Current dating behaviour per type: published, updated, both or none, and where each value is stored
• What the CMS writes to dateModified in structured data, which is often the last save of any field

Method

1. 01 Decide per page type whether a date helps the reader. A tutorial against a versioned product needs one; a definition or an about page usually does not.
2. 02 Where a date helps, show the updated date with the original publication date still available. Replacing the publication date reads as concealment to anyone who checks an archive.
3. 03 Define in writing what counts as an update before allowing the date to move: a factual correction, a version change, a rewritten section. A typo fix is not one.
4. 04 Inspect what the CMS writes to dateModified. Many write it on any save, including a tag edit, which puts a fresh date in the markup while the visible date stays correct, and the two then contradict each other.
5. 05 When you do refresh, state in one line what changed and when. It is the cheapest way to make a new date credible and it survives a sceptical reader.
6. 06 Refuse bulk date updates. The pattern is visible in archives and in the markup, and it removes any ability to tell which refreshes actually worked.
7. 07 Schedule reviews against whatever makes each type go stale, such as a product release cycle or a regulatory change, rather than a fixed calendar interval unrelated to the content.

What this produces

A dating policy per page type, the rule for what counts as a restampable update, and the CMS setting that keeps markup and visible date in agreement.

Where this goes wrong

• Restamping without editing, which is easy to detect and costs credibility with readers before it costs anything in search
• Letting dateModified drift away from the visible date, so the page contradicts itself
• Stripping dates from everything to avoid looking stale, which also removes the reason to trust a page that is genuinely current

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Questions about this skill

More in On-page SEO