Fraîcheur éditoriale et GEO : dates, preuves de révision et sitemap lastmod

Un contenu récent n’est pas nécessairement juste, et un contenu ancien n’est pas nécessairement périmé. La fraîcheur éditoriale utile décrit une action : un fait a été revérifié, une procédure a été retestée, une limite a été ajoutée ou une erreur a été corrigée. Les dates ne doivent que représenter cette action.

Réponse en bref

Affichez une date de publication et, lorsqu’une révision significative a eu lieu, une date de mise à jour clairement libellée. Alignez ces dates avec datePublished et dateModified dans les données structurées. Dans le sitemap, utilisez lastmod uniquement pour la dernière modification réelle de la page, pas pour la date de génération du fichier. Conservez un historique qui explique la révision. Changer une date sans améliorer le contenu ne crée pas de fraîcheur et peut induire le lecteur en erreur.

Pourquoi la fraîcheur compte dans un contenu GEO

Les pages consacrées aux moteurs de réponse dépendent de faits volatils :

• noms et finalités des robots ;
• plages IP publiées ;
• fonctionnalités et pays couverts ;
• rapports de mesure ;
• politiques d’extrait ;
• versions de schémas ou d’API.

Une recommandation juste en janvier peut être fausse en juillet. La date aide seulement si elle indique ce qui a été contrôlé et par qui.

Le protocole DATE

DATE signifie déclencheur, action, trace, exposition.

Étape	Question	Résultat attendu
D : Déclencheur	pourquoi rouvrir la page ?	événement ou échéance documentée
A : Action	qu’a-t-on réellement revu ?	source, test ou correction
T : Trace	comment prouver le changement ?	historique et diff éditorial
E : Exposition	quelles dates afficher aux personnes et machines ?	valeurs cohérentes

Le protocole évite de commencer par modifier dateModified avant même d’avoir relu la page.

D : Définir les déclencheurs

Une revue peut être déclenchée par :

• une modification de la documentation citée ;
• la sortie d’une fonctionnalité ou version ;
• une erreur signalée ;
• un lien cassé ;
• un changement réglementaire ;
• une échéance fixe adaptée au risque.

Toutes les pages n’ont pas besoin du même rythme. Un guide de protocole stable peut être revu annuellement. Une liste de crawlers ou une documentation produit peut nécessiter une veille plus fréquente.

Attribuez un niveau de volatilité : faible, moyen ou élevé. Ce niveau détermine la prochaine condition de revue, pas une promesse de mise à jour automatique.

A : Décrire l’action de révision

Une révision significative peut :

• corriger une affirmation ;
• remplacer une source devenue obsolète ;
• retester un exemple ;
• ajouter une limite qui change l’interprétation ;
• réorganiser le guide pour une nouvelle décision ;
• retirer une recommandation qui n’est plus soutenue.

Corriger une faute peut être utile sans justifier une nouvelle date mise en avant. Définissez une règle éditoriale : dateModified change lorsque la modification affecte le sens, la méthode, les recommandations ou une portion substantielle du contenu.

T : Conserver une trace lisible

Un historique minimal répond à trois questions :

1. quand la modification a-t-elle été faite ?
2. qu’est-ce qui a changé ?
3. pourquoi ce changement était-il nécessaire ?

Exemple :

Date	Changement	Motif
3 juin 2026	ajout des rapports dédiés Search et Discover	annonce officielle du déploiement progressif
13 juillet 2026	ajout du rapport IA générative Search Console	nouvelle mesure officielle déployée progressivement

Évitez « article mis à jour » sans détail. Cette formulation ne permet aucune vérification.

E : Aligner les dates visibles et techniques

Google recommande une date visible et clairement libellée, par exemple « Publié le » ou « Mis à jour le ». Les données structurées d’un Article ou BlogPosting peuvent fournir datePublished et dateModified. Les valeurs doivent correspondre aux dates visibles.

Exemple JSON-LD

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Titre de l’article",
  "datePublished": "2026-07-13T09:00:00+02:00",
  "dateModified": "2026-07-13T09:00:00+02:00"
}

N’utilisez pas une date future et ne confondez pas la date de l’événement décrit avec celle de la page. Limitez les autres dates ambiguës dans le haut du contenu.

Utiliser lastmod correctement

Dans un sitemap XML, lastmod est facultatif. Le protocole Sitemaps précise qu’il doit représenter la dernière modification de la page liée, pas le moment où le sitemap est généré.

<url>
  <loc>https://www.exemple.fr/guide/</loc>
  <lastmod>2026-07-13</lastmod>
</url>

Une erreur fréquente consiste à mettre la date du jour sur toutes les URL à chaque build. Le sitemap affirme alors que tout le site change continuellement. Générez lastmod à partir de la donnée éditoriale de chaque page ou omettez-le si vous ne pouvez pas le maintenir correctement.

lastmod reste un signal fourni aux moteurs, pas une instruction de recrawl immédiat. Sa présence ne remplace ni les liens internes, ni la qualité de la page.

Construire une file de révision

Pour chaque contenu, stockez :

Champ	Exemple
niveau de volatilité	élevé
dernière revue	2026-07-13
prochain déclencheur	changement de la documentation des robots
propriétaire	responsable éditorial
sources à contrôler	URL officielles listées
statut	à jour, à revoir, archivé

Triez d’abord par risque : santé, finance, sécurité, obligations et décisions coûteuses demandent une vigilance supérieure à une définition stable.

Signaux de fausse fraîcheur

• toutes les pages portent la date du build ;
• l’historique ne décrit aucun changement ;
• la date visible diffère du JSON-LD ;
• dateModified précède datePublished ;
• un article cite une version plus récente que sa prétendue revue ;
• le sitemap annonce une modification quotidienne sans diff ;
• l’auteur ou le responsable de revue n’est pas identifiable.

Corrigez la source de données plutôt que d’ajouter une nouvelle date à la main.

Limites

Google utilise plusieurs indices pour estimer les dates et ne garantit pas l’affichage de celle fournie. Une date exacte n’assure ni recrawl, ni indexation, ni citation. Le protocole DATE ne mesure pas la qualité intrinsèque du contenu ; il prouve seulement qu’un processus de révision existe et que les métadonnées le représentent fidèlement.

Articles liés

• Guide GEO : rendre un contenu utile aux moteurs de réponse
• Données structurées auteur et article
• Entité numérique : rendre une identité cohérente
• Étude de cas SEO anonymisée d’un site saisonnier

Prochaine étape

Choisissez cinq contenus volatils, attribuez un déclencheur de revue et corrigez la génération de lastmod si elle utilise la date du build. Pour examiner le processus, décrire le CMS et les métadonnées disponibles.