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.

El archivo de la habilidad

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

## Qué necesitas antes

- 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étodo

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.

## Qué produce esto

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.

## Dónde falla esto

- 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

---

De la biblioteca de habilidades de QuQi - https://www.quqi.io/es/skills/on-page-freshness-signals

Qué necesitas antes

• 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étodo

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.

Qué produce esto

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.

Dónde falla esto

• 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

Usa esta skill en tu propia IA

El archivo es markdown simple, con el nombre y el disparador en su frontmatter. Cuando un asistente sabe cargar skills por su cuenta, es ese frontmatter lo que lee para decidir que esta le aplica.

Más en SEO on-page