Dates visibles et signaux de fraîcheur

Les dates modifient les comportements des deux côtés : les lecteurs passent leur chemin devant un guide daté d'il y a trois ans, et les résultats affichent des dates sur certaines requêtes. La tentation est alors de redater des pages qui n'ont pas changé, ce qui se voit dès que quelqu'un compare deux versions et détruit le signal pour les pages réellement mises à jour. Qu'une date fasse bouger les positions se discute ; qu'elle fasse bouger les clics, non. La question difficile est de savoir quels types de pages doivent porter une date, et cela relève d'une politique par type plutôt que d'un réglage global.

Le fichier de compétence

---
name: on-page-freshness-signals
description: À utiliser au moment de décider quelle date une page doit afficher, ou lorsque quelqu'un propose de rajeunir les dates de mise à jour sur tout le site.
---

# Dates visibles et signaux de fraîcheur

Les dates modifient les comportements des deux côtés : les lecteurs passent leur chemin devant un guide daté d'il y a trois ans, et les résultats affichent des dates sur certaines requêtes. La tentation est alors de redater des pages qui n'ont pas changé, ce qui se voit dès que quelqu'un compare deux versions et détruit le signal pour les pages réellement mises à jour. Qu'une date fasse bouger les positions se discute ; qu'elle fasse bouger les clics, non. La question difficile est de savoir quels types de pages doivent porter une date, et cela relève d'une politique par type plutôt que d'un réglage global.

## Ce qu’il vous faut d’abord

- La liste des types de pages du site et la fonction de chacun
- Le traitement actuel des dates par type : publication, mise à jour, les deux ou aucune, et l'endroit où chaque valeur est stockée
- Ce que le CMS écrit dans dateModified des données structurées, qui correspond souvent au dernier enregistrement d'un champ quelconque

## Méthode

1. Décidez, type de page par type de page, si une date aide le lecteur. Un tutoriel portant sur un produit versionné en a besoin ; une définition ou une page à propos, en général non.
2. Là où une date aide, affichez la date de mise à jour en laissant la date de publication d'origine consultable. Remplacer la date de publication passe pour de la dissimulation aux yeux de quiconque consulte une archive.
3. Définissez par écrit ce qui constitue une mise à jour avant d'autoriser la date à bouger : une correction factuelle, un changement de version, une section réécrite. Une coquille corrigée n'en est pas une.
4. Examinez ce que le CMS écrit dans dateModified. Beaucoup l'écrivent à chaque enregistrement, y compris la modification d'une étiquette, ce qui place une date récente dans le balisage alors que la date visible reste juste, et les deux se contredisent.
5. Quand vous mettez réellement à jour, indiquez en une ligne ce qui a changé et quand. C'est le moyen le moins coûteux de rendre une nouvelle date crédible, et il résiste à un lecteur sceptique.
6. Refusez les mises à jour de dates en masse. Le procédé se voit dans les archives comme dans le balisage, et il vous prive de toute capacité à savoir quelles mises à jour ont réellement fonctionné.
7. Planifiez les revues selon ce qui périme chaque type de page, par exemple un cycle de sortie produit ou une évolution réglementaire, plutôt que selon un intervalle de calendrier fixe sans rapport avec le contenu.

## Ce que ça produit

Une politique de datation par type de page, la règle définissant ce qui justifie une nouvelle date, et le réglage du CMS qui maintient l'accord entre le balisage et la date visible.

## Là où ça dérape

- Redater sans rien modifier, ce qui se détecte facilement et coûte en crédibilité auprès des lecteurs avant de coûter quoi que ce soit dans les résultats
- Laisser dateModified s'écarter de la date visible, si bien que la page se contredit elle-même
- Retirer les dates de partout pour éviter de paraître dépassé, ce qui supprime aussi la raison de faire confiance à une page réellement à jour

---

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

• La liste des types de pages du site et la fonction de chacun
• Le traitement actuel des dates par type : publication, mise à jour, les deux ou aucune, et l'endroit où chaque valeur est stockée
• Ce que le CMS écrit dans dateModified des données structurées, qui correspond souvent au dernier enregistrement d'un champ quelconque

Méthode

1. 01 Décidez, type de page par type de page, si une date aide le lecteur. Un tutoriel portant sur un produit versionné en a besoin ; une définition ou une page à propos, en général non.
2. 02 Là où une date aide, affichez la date de mise à jour en laissant la date de publication d'origine consultable. Remplacer la date de publication passe pour de la dissimulation aux yeux de quiconque consulte une archive.
3. 03 Définissez par écrit ce qui constitue une mise à jour avant d'autoriser la date à bouger : une correction factuelle, un changement de version, une section réécrite. Une coquille corrigée n'en est pas une.
4. 04 Examinez ce que le CMS écrit dans dateModified. Beaucoup l'écrivent à chaque enregistrement, y compris la modification d'une étiquette, ce qui place une date récente dans le balisage alors que la date visible reste juste, et les deux se contredisent.
5. 05 Quand vous mettez réellement à jour, indiquez en une ligne ce qui a changé et quand. C'est le moyen le moins coûteux de rendre une nouvelle date crédible, et il résiste à un lecteur sceptique.
6. 06 Refusez les mises à jour de dates en masse. Le procédé se voit dans les archives comme dans le balisage, et il vous prive de toute capacité à savoir quelles mises à jour ont réellement fonctionné.
7. 07 Planifiez les revues selon ce qui périme chaque type de page, par exemple un cycle de sortie produit ou une évolution réglementaire, plutôt que selon un intervalle de calendrier fixe sans rapport avec le contenu.

Ce que ça produit

Une politique de datation par type de page, la règle définissant ce qui justifie une nouvelle date, et le réglage du CMS qui maintient l'accord entre le balisage et la date visible.

Là où ça dérape

• Redater sans rien modifier, ce qui se détecte facilement et coûte en crédibilité auprès des lecteurs avant de coûter quoi que ce soit dans les résultats
• Laisser dateModified s'écarter de la date visible, si bien que la page se contredit elle-même
• Retirer les dates de partout pour éviter de paraître dépassé, ce qui supprime aussi la raison de faire confiance à une page réellement à jour

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