Faut-il afficher la date de publication ET de mise à jour sur vos articles ?

Pourquoi Google insiste-t-il sur ces deux dates distinctes ?

La recommandation de John Mueller cible un problème récurrent : de nombreux sites masquent complètement leurs dates ou n'affichent que la dernière modification pour faire croire à du contenu frais. Google cherche à comprendre l'âge réel du contenu et sa trajectoire de mise à jour. Un article publié il y a trois ans mais actualisé la semaine dernière n'a pas la même valeur informationnelle qu'un contenu totalement neuf.

Les deux timestamps distincts permettent aux algorithmes de contextualiser la fraîcheur. Un guide technique de 2018 régulièrement mis à jour peut rester pertinent. Un article d'actualité jamais rafraîchi depuis sa publication perd rapidement de sa valeur. Google veut cette nuance temporelle pour affiner ses classements selon les requêtes sensibles au temps.

Quelles données structurées concrètement ?

On parle ici de Schema.org type Article avec les propriétés datePublished et dateModified. Le premier fixe l'origine du contenu, le second trace sa dernière révision substantielle. Ces métadonnées doivent être cohérentes avec l'affichage visible sur la page, sinon vous créez un signal contradictoire.

Google utilise ces timestamps structurés pour alimenter les snippets enrichis dans les résultats de recherche. Si vos données structurées indiquent une mise à jour récente mais que le texte visible montre une date figée de 2019, vous générez de la confusion. L'alignement parfait entre affichage HTML et Schema.org devient critique.

Cette règle s'applique-t-elle à tous les types de contenus ?

La recommandation vise principalement les contenus informationnels et éditoriaux : articles de blog, guides, tutoriels, actualités. Pour des pages produits e-commerce ou des fiches techniques, la logique diffère. Un produit a une date de disponibilité, pas vraiment une date de « publication » au sens éditorial.

Les pages institutionnelles type « À propos » ou « Contact » n'ont généralement pas besoin de timestamps visibles. Par contre, un article pilier mis à jour régulièrement bénéficie clairement de cette double datation. Soyons honnetes : appliquer ça à toutes vos pages sans réflexion éditoriale n'a aucun sens.

• Afficher les deux dates (publication + dernière mise à jour) améliore la transparence et la confiance utilisateur
• Schema.org Article avec datePublished et dateModified doit refléter exactement l'affichage visible
• Priorité aux contenus éditoriaux régulièrement actualisés, pas aux pages statiques
• Masquer les dates ou n'en montrer qu'une seule peut limiter votre contexte temporel dans les algorithmes
• L'alignement HTML / Schema.org est critique pour éviter les signaux contradictoires

Cette déclaration colle-t-elle aux observations terrain ?

Oui, mais avec des nuances importantes. Les sites qui affichent clairement leurs dates de mise à jour et maintiennent des contenus actualisés performent mieux sur les requêtes sensibles au temps. Toutefois, [A verifier] : Google n'a jamais publié de données chiffrées sur l'impact direct de cette pratique dans son algorithme de ranking. On travaille sur des corrélations, pas des causalités prouvées.

Certains secteurs testent depuis des années le masquage complet des dates pour éviter que les contenus anciens paraissent obsolètes. Les résultats sont mixtes selon la typologie de requête. Sur des topics evergreen, masquer les dates ne pénalise pas forcément. Sur des sujets d'actualité ou techniques évolutifs, ça devient problématique. La recommandation de Mueller a le mérite de clarifier la position officielle, mais elle ne règle pas tous les arbitrages éditoriaux.

Quelle différence entre mise à jour cosmétique et substantielle ?

C'est là que ça coince. Google parle de dateModified, mais ne définit jamais le seuil de modification qui justifie de changer cette date. Corriger trois fautes de frappe mérite-t-il de bumper la dateModified ? Probablement pas. Ajouter trois paragraphes de nouvelles données et retirer une section obsolète ? Certainement.

En pratique, beaucoup de CMS mettent à jour automatiquement dateModified à chaque sauvegarde, même mineure. Résultat : des signaux pollués. Un expert SEO doit donc contrôler manuellement ces timestamps ou paramétrer son CMS pour ne modifier la date que lors de révisions éditoriales significatives. Sinon, vous créez du bruit dans vos propres métadonnées.

Y a-t-il des cas où afficher les dates nuit au référencement ?

Oui, et c'est rarement évoqué. Un site avec un rythme de publication irrégulier peut se tirer une balle dans le pied en affichant des dates anciennes sur 80% de ses contenus. Si votre dernier article date de 18 mois et que tous vos concurrents publient chaque semaine, vos timestamps deviennent un signal de fraîcheur négatif.

Certains éditeurs dans des niches evergreen (droit fondamental, philosophie, histoire) constatent que retirer les dates améliore leur CTR dans les SERP, car les utilisateurs ne discriminent plus sur l'âge apparent. Cette pratique contredit la recommandation de Mueller, mais elle répond à une logique UX et business. L'arbitrage n'est pas binaire : il faut peser signal algorithmique vs perception utilisateur selon votre contexte concurrentiel.

Comment implémenter correctement ces deux dates ?

Première étape : audit de vos templates. Vérifiez si votre thème affiche déjà datePublished et dateModified, et si ces valeurs correspondent réellement à l'historique éditorial. Beaucoup de thèmes WordPress par défaut n'affichent qu'une seule date, souvent mal configurée. Vous devez forcer l'affichage des deux, avec un libellé clair : « Publié le » et « Mis à jour le ».

Ensuite, Schema.org via JSON-LD. Intégrez un bloc script type Article avec datePublished (ISO 8601) et dateModified. Testez avec le Rich Results Test de Google pour valider. Si vous utilisez un plugin SEO (Yoast, Rank Math), ces champs sont souvent auto-générés, mais vérifiez la cohérence : le plugin ne doit pas inventer des dates de modification fantaisistes.

Quelles erreurs éviter absolument ?

Erreur classique : bumper dateModified sans vraie mise à jour. Certains SEO changent cette date chaque mois pour simuler de la fraîcheur. Google détecte cette manipulation si le contenu reste identique (via diffing ou analyse sémantique). Vous risquez une perte de confiance algorithmique. Ne touchez à dateModified que lors de révisions éditoriales réelles.

Autre piège : incohérence entre affichage et Schema.org. Votre page HTML montre « Mis à jour le 12 mars » mais votre JSON-LD indique février. Google privilégiera probablement le Schema.org, mais cette divergence crée un signal de qualité négatif. Automatisez la génération pour garantir l'alignement parfait.

Comment vérifier la conformité de mon site ?

Utilisez un crawler SEO (Screaming Frog, Sitebulb) pour extraire les valeurs datePublished et dateModified de toutes vos pages Article. Exportez dans un tableau, comparez avec vos dates réelles d'édition (accessibles via votre CMS ou Git). Identifiez les incohérences. Les outils de crawl peuvent parser le JSON-LD et l'affichage HTML simultanément, vous repérez ainsi les désalignements.

Parallèlement, testez un échantillon de vos URLs dans Rich Results Test et Search Console pour vérifier que Google lit correctement vos timestamps. Si les propriétés datePublished/dateModified n'apparaissent pas dans le preview, c'est que votre implémentation a un problème structurel. Corrigez avant de scaler à l'ensemble du site.

• Afficher visiblement les deux dates (publication + mise à jour) sur chaque article
• Implémenter Schema.org Article avec datePublished et dateModified en ISO 8601
• Garantir la cohérence parfaite entre affichage HTML et données structurées
• Ne modifier dateModified que lors de révisions éditoriales substantielles, jamais pour manipuler la fraîcheur
• Auditer régulièrement avec un crawler pour détecter les incohérences de timestamps
• Valider l'implémentation via Rich Results Test et Search Console