Pourquoi Google affiche-t-il parfois la date de publication initiale au lieu de la date de mise à jour ?

Quelle date Google privilégie-t-il réellement dans les résultats de recherche ?

La réponse de John Mueller brise une idée reçue tenace : Google ne se contente pas de lire votre balisage datePublished ou dateModified et de l'afficher mécaniquement. Les algorithmes évaluent quel timestamp apporte le plus de valeur à l'utilisateur dans le contexte précis de sa requête.

Concrètement, si quelqu'un cherche un guide SEO fondamental, Google peut juger que la date de publication originale (2018) est plus pertinente que la dernière mise à jour mineure (correction de typos en 2023). À l'inverse, pour une requête sur les nouvelles règles fiscales, la date de modification récente sera privilégiée car la fraîcheur est critique.

Comment Google détermine-t-il quelle date afficher ?

Mueller reste volontairement vague sur les critères exacts. On sait que les algorithmes contextuels analysent plusieurs signaux : le type de contenu (evergreen vs actualité), l'intention de recherche détectée, l'ampleur des modifications apportées au contenu, et probablement la cohérence entre le balisage et le contenu réel de la page.

Ce qui complique la donne : Google peut ignorer votre balisage s'il détecte une manipulation. Si vous changez la date modified chaque semaine sans modification substantielle du contenu, l'algorithme peut revenir à la date de publication initiale. C'est un mécanisme anti-abus qui vise à préserver la pertinence des dates affichées.

Cette logique s'applique-t-elle de la même façon pour tous les types de contenu ?

Non, et c'est là que ça devient intéressant. Les contenus d'actualité (news) suivent des règles distinctes où la fraîcheur est quasi systématiquement favorisée. Pour le contenu informatif classique, Google dispose d'une plus grande latitude d'interprétation.

Un article de blog technique evergreen régulièrement enrichi peut voir Google alterner entre les deux dates selon les requêtes. Une page produit mise à jour pour refléter un nouveau prix affichera probablement la date de modification. La nature même du contenu influence le choix algorithmique.

• Google ne se fie pas aveuglément au balisage datePublished/dateModified
• Le contexte de la requête utilisateur joue un rôle décisif dans le choix de la date affichée
• Les modifications substantielles ont plus de poids que les ajustements cosmétiques
• La manipulation de dates sans vrai changement de contenu peut être détectée et ignorée
• Les contenus actualités vs evergreen ne sont pas traités avec la même logique

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et elle confirme ce que beaucoup d'entre nous constatent depuis des années. Des sites qui republient du contenu ancien légèrement retouché avec une nouvelle date modified ne voient pas systématiquement cette date s'afficher dans les SERP. Google a visiblement construit des filtres pour détecter les mises à jour superficielles.

Ce qui reste flou : le seuil exact qui définit une modification substantielle. Changer 10% du texte suffit-il ? Faut-il ajouter une section entière ? Mueller ne donne aucun chiffre, et c'est probablement intentionnel pour éviter que les SEO optimisent mécaniquement autour d'un pourcentage précis. [A vérifier] par des tests A/B sur différents volumes de modification.

Dans quels cas cette règle pose-t-elle problème pour les SEO ?

Le premier cas vicieux : les guides mis à jour annuellement. Vous enrichissez votre guide SEO chaque année avec les dernières tendances, mais Google continue d'afficher la date de 2019. Pour l'utilisateur, ça sent le contenu périmé, même si c'est faux. Résultat : un CTR en berne malgré un contenu à jour.

Second problème : les pages produits dont le contenu descriptif reste stable mais dont le prix, la disponibilité ou les specs évoluent. Google peut juger que ces changements ne justifient pas d'afficher la nouvelle date, alors que pour l'acheteur, c'est justement l'info qui compte. La logique algorithmique ne colle pas toujours à la valeur business.

Quelles nuances faut-il apporter à cette déclaration ?

Mueller parle de pertinence pour l'utilisateur, mais c'est Google qui décide ce qui est pertinent. Cette subjectivité algorithmique peut créer des situations absurdes où un contenu fraîchement mis à jour affiche une vieille date parce que l'algorithme a mal évalué l'ampleur des changements.

Autre angle mort : Mueller ne mentionne pas le rôle du sitemap XML. Si votre sitemap indique une lastmod récente mais que le contenu n'a pas vraiment changé, Google peut croiser ces signaux et conclure à une tentative de manipulation. La cohérence entre tous vos signaux de fraîcheur compte probablement plus que le balisage isolé.

Que faut-il faire concrètement pour maximiser ses chances d'afficher la bonne date ?

Première règle : ne changez la date modified que si vous modifiez substantiellement le contenu. Pas de mise à jour cosmétique juste pour paraître frais. Google a les moyens techniques de comparer les versions crawlées et de détecter si vous avez juste changé trois mots.

Deuxième approche : quand vous mettez à jour un contenu, ajoutez une section visible « Dernière mise à jour » avec un résumé des changements. Cela donne un signal humain en plus du balisage technique, et Google peut analyser ce texte pour évaluer la substantialité de la modification.

Comment structurer son balisage de dates pour éviter les pièges ?

Utilisez Schema.org Article avec datePublished ET dateModified distincts. Ne supprimez jamais datePublished, même si vous voulez pousser la date de modification. Google a besoin des deux pour faire son choix contextuel.

Pour les contenus evergreen régulièrement enrichis, envisagez d'ajouter une propriété version ou un changelog structuré. Même si Google ne l'exploite pas directement aujourd'hui, cela renforce la légitimité de votre date modified et peut influencer l'évaluation qualitative du contenu.

Quelles erreurs éviter absolument ?

Ne jouez pas avec les dates pour simuler de la fraîcheur artificielle. Changer la date modified chaque semaine sur un contenu statique finira par être détecté, et Google reviendra probablement à la date de publication initiale de façon permanente.

Évitez les incohérences entre vos signaux : si votre sitemap XML indique une lastmod mais que ni le contenu ni le balisage on-page ne reflètent ce changement, vous créez de la confusion. Google peut alors faire un choix arbitraire ou ignorer complètement vos dates.

• Vérifier que votre CMS ne met pas à jour dateModified pour des changements non-éditoriaux (connexions admin, modifs CSS/JS)
• Ajouter une mention visible « Mis à jour le [date] » avec un résumé des changements pour les mises à jour majeures
• Maintenir datePublished ET dateModified dans le balisage Schema.org, jamais l'un sans l'autre
• Auditer les pages clés pour vérifier quelle date Google affiche réellement dans les SERP vs ce que vous balises
• Synchroniser les dates entre sitemap XML, balisage Schema.org et affichage visible sur la page
• Documenter les mises à jour substantielles dans un changelog structuré