Date d’article et date de mise à jour : arrêter de simuler la fraîcheur éditoriale

Déclarez la date de première publication et la date de dernière modification réelle dans le balisage Article, et ne modifiez la seconde que lorsqu’un changement substantiel a eu lieu. Une date de mise à jour avancée sans contenu nouveau est une simulation de fraîcheur : elle ne crée pas de valeur et expose le site aux logiques de contenu utile. La méthode fiable consiste à historiser les révisions et à aligner dateModified sur la dernière révision vérifiable.

Que signifient exactement datePublished et dateModified ?

Dans le vocabulaire schema.org utilisé par Google, datePublished correspond à la date et l’heure de première publication de l’article, et dateModified à la date et l’heure de sa dernière modification. Les deux sont exprimées au format ISO 8601, avec un fuseau horaire recommandé ; à défaut, Googlebot applique son propre fuseau (Official source).

Le balisage Article, NewsArticle ou BlogPosting aide Google à mieux comprendre une page et à afficher des informations de date plus pertinentes dans les résultats, y compris dans Google News et l’Assistant. Aucun balisage n’est exigé pour être éligible aux fonctionnalités comme Top stories, mais il rend explicite ce que la page est et quand elle a évolué (Official source).

La distinction essentielle est donc technique : une date n’est pas un signal de qualité en soi, c’est une métadonnée. Elle décrit un fait éditorial vérifiable, pas une intention marketing.

Pourquoi avancer une date sans modification réelle est un mauvais calcul

Les systèmes de classement automatisés de Google visent à privilégier les informations utiles et fiables, pas les contenus conçus pour manipuler le classement. La documentation sur les contenus utiles invite à s’interroger sur les contenus conçus pour manipuler le classement plutôt que pour bénéficier aux personnes (Official source).

Cette pratique ne produit aucun gain durable : elle ne modifie ni la réponse apportée au lecteur, ni la profondeur de l’analyse. Elle crée en revanche une incohérence entre la date affichée et l’état réel du document, ce qui complique les audits internes et peut tromper les visiteurs.

Exemple hypothétique. Un site affiche « Mis à jour le 30 septembre 2026 » sur une fiche produit dont seule la couleur d’un bouton a changé. La date est techniquement modifiée, mais l’information utile pour l’acheteur n’a pas évolué. Un lecteur qui revient constater la mise à jour ne trouve rien de neuf.

Comment historiser les révisions sans dépendre d’une date affichée ?

La méthode robuste consiste à séparer trois choses : la date de publication, la date de dernière révision substantielle, et l’historique des changements. Voici une procédure de contrôle applicable à un site français, belge ou suisse.

1. Définir ce qu’est une révision substantielle. Un ajout d’information, une correction factuelle, une mise à jour de prix ou de disponibilité, une reformulation qui change le sens. Une correction de faute, un changement de maquette ou une modification de lien interne n’en sont pas.
2. Consigner chaque révision dans un journal. Un fichier de suivi ou un champ de gestion de contenu daté suffit. L’objectif est de pouvoir prouver, en interne, ce qui a changé et quand.
3. Aligner dateModified sur la dernière révision substantielle. Si aucune révision substantielle n’a eu lieu, la date ne bouge pas.
4. Vérifier la cohérence entre le balisage et l’affichage. La date visible et la date structurée doivent raconter la même histoire.
5. Contrôler le fuseau horaire. Une date sans fuseau est interprétée selon le fuseau de Googlebot ; mieux vaut l’expliciter pour éviter les décalages (Official source).

Cette procédure ne garantit aucun classement. Elle garantit seulement que la métadonnée décrit un fait.

Quel diagnostic appliquer à un lot de pages ?

Pour auditer un site existant, constituez un échantillon de pages représentatives : articles de blog, fiches produits, pages catégories, pages d’aide. Pour chaque page, relevez quatre éléments : la date affichée, datePublished, dateModified, et la dernière révision réellement documentée.

Ce tableau est un outil de décision, pas une grille de notation. Il sert à prioriser les corrections là où l’écart entre la date et le contenu est le plus net.

Faut-il mettre à jour la date quand on corrige une coquille ?

Non, si la correction ne change pas le sens ni l’information utile. En revanche, si la correction porte sur un fait, un chiffre, une règle ou une recommandation, elle constitue une révision substantielle et peut justifier une nouvelle dateModified. La question à se poser est simple : un lecteur qui a déjà lu la page apprendrait-il quelque chose de nouveau ? Si la réponse est non, la date ne devrait pas bouger.

Cette règle vaut aussi pour les pages commerciales. Une boutique qui modifie un prix, une disponibilité ou une condition de livraison apporte une information utile ; une boutique qui change une bannière n’en apporte pas. Pour les fondations techniques d’une boutique, voir SEO e-commerce : les fondations d’une boutique visible.

Comment relier ce sujet au suivi des mises à jour Google ?

Les dates d’article ne sont pas un levier de classement isolé. Elles s’inscrivent dans un contexte plus large de qualité et de suivi. Lorsqu’une mise à jour de Google est déployée, la tentation d’avancer les dates pour « profiter » de l’événement est forte. Elle est pourtant contre-productive : la mise à jour antispam de septembre 2026 illustre qu’une baisse de clics exige une comparaison par page et par requête, pas une retouche de dates (Mise à jour antispam Google de septembre 2026 : suivre les effets sans conclusion hâtive).

Un audit de dates s’intègre naturellement à un audit plus large. Pour savoir par où commencer sur un catalogue, voir Audit SEO e-commerce : les contrôles à faire en premier.

Quelles incertitudes subsistent ?

Google ne publie pas de règle indiquant qu’une date avancée entraîne une pénalité automatique. La documentation ne cite pas explicitement la modification de date dans les questions d’auto-évaluation fournies (Official source). L’effet exact dépend du contexte, du type de page et de la concurrence. Il n’existe pas de seuil public, ni de garantie qu’une date correcte améliore le classement. La seule certitude documentée est que datePublished et dateModified ont une définition précise et que les systèmes de classement privilégient les contenus utiles.

Questions fréquentes

Faut-il afficher la date de mise à jour sur toutes les pages ?

Pas nécessairement. Elle est surtout pertinente pour les contenus dont la valeur dépend de l’actualité : articles, guides, fiches produits évolutives. Google recommande de ne pas modifier la date d’une page pour la faire paraître plus récente lorsque le contenu n’a pas substantiellement changé. Sur une page intemporelle, une date de mise à jour artificielle apporte peu et peut nuire à la cohérence.

Peut-on utiliser une date de mise à jour pour un contenu traduit ?

Une traduction n’est pas une mise à jour de l’article source. Si la version traduite est publiée pour la première fois, elle a sa propre datePublished. Si elle est ensuite corrigée substantiellement, sa dateModified peut évoluer. Les deux versions doivent rester cohérentes avec leur propre historique.