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.

Le fichier de compétence

---
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.

## Ce qu’il vous faut d’abord

- 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

## Méthode

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.

## Ce que ça produit

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.

## Là où ça dérape

- 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

---

Extrait de la bibliothèque de compétences QuQi - https://www.quqi.io/fr/skills/on-page-freshness-signals

Ce qu’il vous faut d’abord

• 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

Méthode

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.

Ce que ça produit

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.

Là où ça dérape

• 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

Utiliser cette compétence dans votre propre IA

Le fichier téléchargé est un simple markdown dont l'en-tête porte le nom et le déclencheur. Quand un assistant sait charger des compétences tout seul, c'est cet en-tête qu'il lit pour décider que celle-ci s'applique.

Plus dans SEO on-page