Pourquoi Google ignore-t-il vos structured data de date si elles ne sont pas visibles ?

Google fait-il vraiment confiance aux structured data pour les dates ?

Non, et c'est une clarification importante. Google ne se contente pas de lire vos balises datePublished ou dateModified dans le schema.org pour déterminer la date d'un article. Les algorithmes adoptent une approche de validation croisée : ils extraient toutes les dates disponibles sur la page — celles visibles par l'utilisateur, celles dans les balises meta, celles dans les structured data — puis choisissent celle qui bénéficie du plus de support contextuel.

Concrètement, si votre date n'apparaît que dans le JSON-LD mais nulle part dans le corps visible de l'article, Google peut décider de l'ignorer ou de privilégier une autre date trouvée ailleurs sur la page. Le moteur cherche une cohérence entre ce que voit l'utilisateur et ce que disent les metadata techniques. C'est une approche défensive contre la manipulation : rien n'empêche un site de mentir dans ses structured data tout en affichant autre chose aux lecteurs.

Qu'entend-on par « support dans l'article » exactement ?

Le « support » désigne la convergence des signaux : date visible en haut de page, date dans les balises schema, éventuelle mention textuelle dans l'intro ou le footer, cohérence avec la date de publication des commentaires, fraîcheur des contenus liés. Plus ces éléments s'alignent, plus Google gagne en confiance. Si une date apparaît simultanément dans trois emplacements différents — en-tête visible, JSON-LD, balise meta — elle devient la candidate naturelle.

À l'inverse, un site qui affiche « 15 janvier » en haut mais encode « 2023-03-22 » dans ses structured data crée un conflit. Google doit alors arbitrer, et rien ne garantit que l'algorithme choisira la date que vous vouliez mettre en avant. L'ambiguïté coûte cher en contexte éditorial, surtout pour les contenus d'actualité où la fraîcheur influe sur le ranking dans Google News ou les featured snippets temporels.

Pourquoi cette exigence de visibilité maintenant ?

Cette clarification s'inscrit dans une tendance plus large : Google cherche à réduire l'écart entre l'expérience utilisateur réelle et les signaux techniques envoyés au moteur. C'est cohérent avec l'approche « mobile-first », où seul ce qui est visible compte, ou avec les Core Web Vitals, où la performance perçue prime sur les metrics serveur. Les structured data restent importantes, mais elles ne peuvent plus servir de couche invisible déconnectée du contenu réel.

Du point de vue de la lutte contre la manipulation, c'est aussi logique : il est beaucoup plus coûteux pour un spammeur de modifier une date visible (car les utilisateurs la voient et peuvent signaler l'incohérence) que de simplement tweaker un JSON-LD caché. En exigeant la confirmation visuelle, Google force l'alignement entre SEO technique et expérience lecteur.

• Google croise systématiquement les dates visibles, les metadata et les structured data avant de choisir celle qu'il retiendra
• Une date absente du contenu visible peut être ignorée même si elle figure dans le schema.org
• Afficher la date complète en clair (jour, mois, année) facilite la détection algorithmique et réduit les ambiguïtés
• Cette approche défensive vise à empêcher les manipulations où le code technique dit une chose et l'utilisateur en voit une autre
• La cohérence entre tous les signaux est désormais le critère déterminant pour la reconnaissance de date

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Globalement, oui. On observe depuis plusieurs mois que des sites avec des dates uniquement en JSON-LD voient Google afficher des dates erronées dans les SERPs, ou carrément ignorer la date dans les rich results. Certains éditeurs de presse ont constaté que leurs articles récents n'apparaissaient pas dans les filtres temporels de Google News tant qu'ils n'avaient pas ajouté une date visible en haut de page. C'est un signal clair que l'algorithme privilégie la confirmation visuelle.

Par contre, il reste une zone grise : quelle « visibilité » suffit exactement ? Une date en footer est-elle valable ? Une date dans une metadata OpenGraph invisible mais scrapable par Facebook compte-t-elle comme « support » ? [À vérifier] La déclaration de Mueller reste volontairement floue sur le poids relatif de chaque signal. On sait que « visible » est préféré, mais on ne sait pas si « semi-visible » (présent en DOM mais caché en CSS) est acceptable.

Quelles nuances faut-il apporter à cette règle ?

Premièrement, cette logique s'applique surtout aux contenus éditoriaux : articles de blog, actualités, études de cas. Pour une page produit ou une landing commerciale, la notion de date de publication est moins critique, et Google ne va pas pénaliser l'absence d'affichage de date. Il faut contextualiser : Mueller parle ici de « date d'article », pas de toute page web.

Deuxièmement, attention à la sur-interprétation. Afficher la date ne garantit pas qu'elle sera utilisée : si l'algorithme détecte une incohérence (par exemple, un article daté du 10 mars mais avec des commentaires datés du 8 mars), il peut encore choisir une autre date ou renoncer à en afficher une. La visibilité est une condition nécessaire, pas suffisante. Le « support » reste un critère flou et multi-factoriel.

Quels risques pratiques pour les sites qui ne se conforment pas ?

Le risque principal : perte de visibilité dans les filtres temporels et les carousels d'actualité. Si Google ne parvient pas à identifier la date fiablement, l'article peut être exclu des résultats « dernières 24h » ou « dernière semaine », même s'il est récent. Pour un média d'actu, c'est critique. Pour un blog corporate, l'impact est moindre mais peut se traduire par une date incorrecte affichée dans les SERPs, ce qui nuit à la crédibilité.

Autre conséquence moins visible : les algorithmes de freshness et de QDF (Query Deserves Freshness) s'appuient sur la date pour déterminer si un contenu est à jour. Si la date n'est pas reconnue, un article récent peut être traité comme « ancien » et perdre du ranking sur des requêtes sensibles à la fraîcheur. Inversement, un vieux contenu sans date visible peut être mieux classé qu'il ne devrait, mais c'est un pari risqué sur la durée.

Que faut-il faire concrètement sur vos pages éditoriales ?

Afficher la date de publication en haut de chaque article, de préférence dans un format clair et complet (ex: « 12 mars 2023 » plutôt que « 12/03 »). Placez-la dans un emplacement visible et conventionnel : sous le titre, à côté du nom de l'auteur, ou dans une byline. Évitez les formats ambigus (« il y a 3 jours ») qui ne permettent pas à l'algorithme de calculer une date absolue fiable.

Ensuite, assurez-vous que cette date visible est cohérente avec celle encodée dans vos structured data (datePublished dans le schema Article). Si vous affichez « 15 janvier » mais que votre JSON-LD dit « 2023-01-22 », vous créez une incohérence que Google devra arbitrer. Idéalement, votre CMS doit générer les deux automatiquement à partir d'une seule source de vérité.

Comment vérifier que Google reconnaît correctement vos dates ?

Utilisez l'outil de test des résultats enrichis de Google Search Console pour valider que vos structured data sont bien parsées. Mais ne vous arrêtez pas là : faites une recherche site: sur quelques-uns de vos articles récents et vérifiez la date affichée dans les snippets. Si elle ne correspond pas à celle que vous avez encodée, c'est un signal que Google privilégie une autre source.

Vous pouvez également inspecter l'URL via Search Console et regarder la section « Structured data » pour voir ce que Googlebot a effectivement extrait. Si la date n'apparaît pas ou diffère de celle attendue, c'est qu'il y a un problème de détection ou de cohérence. Surveillez aussi vos logs : si vos articles récents n'apparaissent pas dans les filtres temporels de Google News alors qu'ils devraient, c'est souvent lié à un problème de reconnaissance de date.

Quelles erreurs éviter absolument ?

Ne cachez jamais la date uniquement en CSS (display:none, visibility:hidden) tout en espérant que Google la lise dans le DOM. C'est techniquement du cloaking et même si ça fonctionne parfois, c'est fragile et contraire aux guidelines. Si vous ne voulez pas afficher de date pour des raisons UX, assumez que Google pourrait ne pas en reconnaître, et acceptez les conséquences.

Autre piège classique : afficher « Mis à jour le X » mais encoder « datePublished: Y » dans le schema. Si les deux dates diffèrent significativement, Google peut se tromper ou choisir la mauvaise. Utilisez les deux propriétés distinctement (datePublished + dateModified) et affichez les deux si pertinent. Enfin, évitez les formats de date exotiques ou localisés qui compliquent le parsing algorithmique : privilégiez les formats ISO 8601 dans le code et un affichage textuel clair pour l'utilisateur.

• Afficher la date complète (jour, mois, année) en haut de chaque article, dans un format textuel clair
• Assurer la cohérence entre date visible, structured data (datePublished), et balises meta éventuelles
• Utiliser les deux propriétés schema.org : datePublished pour la création, dateModified pour la mise à jour
• Tester la reconnaissance via Search Console (test des résultats enrichis + inspection d'URL)
• Vérifier l'affichage dans les SERPs en faisant des recherches site: sur vos articles récents
• Ne jamais cacher la date uniquement en CSS si elle doit être reconnue par Google