Schema Article : baliser vos articles pour Google

Le schema Article est un balisage de données structurées qui décrit une page éditoriale à Google : son titre, son auteur, ses dates de publication et de mise à jour, son image principale. Il existe trois types courants, Article, NewsArticle et BlogPosting, et le choix entre eux compte moins qu'on ne le croit. Ce qui compte, c'est la qualité des propriétés que vous renseignez et leur cohérence avec ce que le lecteur voit sur la page.

Une précision d'emblée, pour éviter les déceptions : ajouter ce balisage ne produit pas, à lui seul, un rich result spectaculaire ni une meilleure position. Son rôle est plus discret. Il lève des ambiguïtés, notamment sur les dates et les auteurs, et il alimente certaines surfaces comme Google Actualités ou Discover. Voyons comment le mettre en place proprement et à quoi s'attendre.

Article, NewsArticle ou BlogPosting : lequel choisir ?

Dans le vocabulaire de schema.org, ces trois types s'emboîtent comme des poupées russes. Article est le type générique. NewsArticle et BlogPosting en sont des spécialisations : un NewsArticle est un article d'actualité, un BlogPosting est un billet de blog. Tout ce qui vaut pour Article vaut donc pour les deux autres, qui héritent de ses propriétés.

Côté Google, la documentation sur les données structurées d'article regroupe les trois types sous le même ensemble de recommandations. Vous ne gagnez pas un avantage technique en choisissant l'un plutôt que l'autre. Le type sert surtout à dire honnêtement quelle nature a votre contenu, et à faciliter la lecture du balisage par vos équipes et par les outils tiers.

La règle pratique est simple et tient en trois cas de figure.

Un cas limite fréquent : un site d'entreprise dont la rubrique « actualités » publie surtout des communiqués et des nouveautés produit. Ces pages relèvent souvent davantage de l'Article ou du BlogPosting que du NewsArticle au sens journalistique. Posez-vous la question du lecteur : est-ce une information datée et traitée comme telle, ou un contenu de marque ? Cette honnêteté évite des incohérences et rend l'audit ultérieur beaucoup plus simple.

• BlogPosting pour les billets de blog, les articles de conseil, les tutoriels publiés dans une rubrique de type blog, même quand le ton est professionnel.
• NewsArticle pour un contenu d'actualité daté, typiquement sur un site de presse ou une rubrique d'informations : un événement, une annonce, un fait récent traité comme une information.
• Article quand aucun des deux ne convient franchement : dossier de fond, analyse, contenu éditorial intemporel, page de type magazine.

Les pièges de NewsArticle

Le type NewsArticle attire les mauvais usages. Certains sites l'appliquent à tous leurs contenus dans l'espoir d'apparaître dans les blocs d'actualité. Ça ne fonctionne pas ainsi. Être éligible à Google Actualités ou au carrousel des sujets d'actualité dépend de la nature réelle du site, de ses pratiques éditoriales et de ses propres règles, pas d'un mot dans le JSON-LD.

Étiqueter un guide pratique évergreen comme un NewsArticle est au mieux inutile, au pire trompeur : cela introduit une incohérence entre le balisage et la page, et cela rend la lecture des dates moins crédible. Si votre contenu ne porte pas sur un fait d'actualité, restez sur BlogPosting ou Article. Le gain d'un type plus flatteur est nul, le risque d'incohérence, lui, est réel.

Les propriétés qui comptent vraiment

Bonne nouvelle pour les équipes pressées : pour le balisage d'article, Google ne déclare aucune propriété strictement obligatoire. Il recommande en revanche un petit groupe de propriétés, et c'est là que se joue la valeur du balisage. Les voici, avec ce qu'elles apportent concrètement.

• headline : le titre de l'article, court. Google demande un titre concis ; un titre interminable n'apporte rien. Il doit correspondre au titre visible sur la page, pas à une version réécrite pour le balisage.
• author : une entité Person ou Organization, avec au minimum un champ name, et idéalement une url qui renvoie vers une page dédiée à l'auteur. Le champ name contient uniquement le nom, sans « Par », sans fonction, sans mention d'entreprise.
• datePublished et dateModified : les dates au format ISO 8601, de préférence avec le fuseau horaire, par exemple 2026-03-14T09:30:00+01:00. Elles aident Google à comprendre la fraîcheur du contenu.
• image : une ou plusieurs URL d'images explorables et indexables, représentatives de l'article. Fournir plusieurs formats (16:9, 4:3 et 1:1) donne à Google le choix selon la surface d'affichage.
• mainEntityOfPage et publisher : utiles pour relier le balisage à l'URL canonique de la page et à l'organisation éditrice. Ils ne sont pas exigés, mais ils clarifient le contexte.

Auteur, dates, image : les détails qui font la différence

L'auteur. C'est la propriété la plus souvent mal renseignée. Erreurs fréquentes : mettre le nom du site à la place de la personne, concaténer plusieurs noms dans un seul champ, ou insérer un titre comme « Dr » ou « Rédactrice en chef » dans name. Quand un article a plusieurs auteurs, déclarez un objet Person par auteur, dans un tableau. Si vous ajoutez une url, pointez vers une page qui présente réellement la personne ; Google s'en sert pour désambiguïser les homonymes. Un lien sameAs vers un profil public fiable peut renforcer cette identification, à condition qu'il soit exact.

Les dates. Deux pièges dominent. Le premier : afficher des dates dans le balisage qui ne correspondent pas à celles de la page. Si l'article indique « Mis à jour le 3 mars » à l'écran, le dateModified du JSON-LD doit dire la même chose. Le second : modifier dateModified à chaque déploiement ou à chaque correction de virgule pour simuler de la fraîcheur. Une date de mise à jour n'a de sens que si le contenu a changé de façon significative. Les systèmes de Google comparent plusieurs signaux de date, et une manipulation grossière n'apporte rien de durable.

L'image. L'URL doit pointer vers un fichier que Googlebot peut explorer, sans blocage par le robots.txt ni mur de connexion, dans un format d'image pris en charge. Pour Discover, Google recommande des images larges, d'au moins 1 200 pixels de largeur, et l'activation de la directive max-image-preview:large dans la balise meta robots. Un logo minuscule utilisé comme image d'article est l'erreur classique : préférez l'image principale réelle de l'article.

Un exemple de JSON-LD prêt à adapter

Le format recommandé par Google est le JSON-LD, placé dans une balise script de type application/ld+json dans le head ou le body de la page. Voici la structure d'un billet de blog, décrite en texte pour éviter toute ambiguïté : le contexte est https://schema.org, le type est BlogPosting, le mainEntityOfPage pointe vers l'URL canonique de l'article, le headline reprend le titre affiché, image liste deux ou trois URL, datePublished et dateModified portent les dates ISO 8601.

Vient ensuite author, un objet de type Person avec name et url, puis publisher, un objet de type Organization avec name et logo. Le tout tient en une vingtaine de lignes. Dans un CMS, ce bloc se génère à partir des champs déjà présents : titre, auteur, date de publication, date de modification, image mise en avant. C'est la meilleure garantie de cohérence, car personne n'a à recopier quoi que ce soit à la main.

Un point de méthode : générez le balisage à partir des mêmes données que celles qui alimentent l'affichage. Les écarts viennent presque toujours d'un balisage saisi à la main dans un champ séparé, qui n'est plus mis à jour quand l'article évolue.

Ce que le balisage Article change vraiment dans les résultats

Soyons précis, car c'est là que circulent le plus d'idées fausses. Contrairement aux données structurées de recette ou de produit, le balisage Article ne déclenche pas un affichage enrichi distinctif dans les résultats classiques, comme des étoiles ou une vignette de recette. Vous ne verrez pas votre résultat se transformer après l'ajout d'un BlogPosting.

Ce qu'il fait, c'est fournir à Google des informations propres et non ambiguës. Dans la pratique, cela peut influencer plusieurs choses : la façon dont le titre, la date et l'image sont compris, la présentation dans certaines surfaces comme Discover, Google Actualités ou les résultats d'actualité, et l'association de l'article à son auteur. Google reste libre de déterminer lui-même ces éléments à partir de la page, et il le fait souvent correctement même sans balisage.

Le balisage Article n'est pas, non plus, un facteur de classement direct. Il ne remplace ni la qualité du contenu, ni les liens, ni la pertinence pour la requête. Présenter ce balisage comme un levier de position serait une erreur. Il sert à réduire le risque de mauvaise interprétation, ce qui a une valeur, mais une valeur modérée.

Le vrai bénéfice est donc plutôt en termes de fiabilité : des dates lisibles, un auteur identifié, une image correcte. Pour un site qui publie beaucoup et veut être comparable aux autres sources éditoriales, c'est une base saine. Pour un site de trois pages, l'effort est plus discutable, sans être inutile.

Valider, déployer, surveiller

Avant de déployer, testez une URL réelle avec le test des résultats enrichis de Google, qui indique si le balisage est lisible et signale les avertissements. L'outil de validation Schema Markup Validator, indépendant de Google, vérifie la conformité au vocabulaire schema.org, ce qui est utile pour les propriétés que Google n'exploite pas. Les deux sont complémentaires : l'un répond à « est-ce bien formé ? », l'autre à « Google en fait-il quelque chose ? ».

Une fois en ligne, Search Console reste votre filet de sécurité. Les rapports d'améliorations ne couvrent que certains types de données structurées, et il n'existe pas de rapport dédié à chaque type d'article, donc ne vous attendez pas à un tableau de bord complet pour ce balisage. Surveillez en revanche les erreurs d'analyse du JSON-LD et inspectez de temps en temps quelques URL pour vérifier que le balisage rendu correspond à celui que vous avez prévu, en particulier si le site repose sur du JavaScript.

Dernier réflexe : relisez régulièrement un échantillon d'articles après chaque refonte de thème ou migration de CMS. Les balisages disparaissent discrètement lors de ces opérations, ou se dupliquent quand un plugin et un thème injectent chacun leur version. Deux blocs Article contradictoires sur la même page sont à éviter ; gardez une seule source de vérité.

Enfin, n'oubliez pas l'entretien. Un balisage correct le jour de la mise en ligne peut dériver : un auteur quitte la rédaction et sa page disparaît, une image est supprimée de la médiathèque, un article est republié avec une nouvelle URL sans que le mainEntityOfPage suive. Un contrôle trimestriel sur un échantillon d'articles suffit en général à détecter ces dérives avant qu'elles ne s'accumulent.

Les erreurs qui reviennent le plus souvent

Quelques défauts reviennent sur la plupart des sites audités. Ils ont en commun d'être faciles à corriger dès qu'on les a repérés.

• Balisage qui décrit du contenu absent de la page : auteur inventé, date fictive, image que le lecteur ne voit jamais. Google attend que le balisage reflète le contenu visible.
• Même image et même auteur générique sur tous les articles, par exemple le nom de la marque à la place de la rédaction réelle, ce qui prive le balisage de toute valeur d'identification.
• Dates sans fuseau horaire ou dans un format non conforme, qui provoquent des lectures erronées ou des avertissements.
• Type NewsArticle appliqué à des guides intemporels, sans lien avec l'actualité.
• Plugins qui empilent plusieurs blocs JSON-LD concurrents pour la même page.
• Balisage appliqué à des pages qui ne sont pas des articles : pages de catégorie, pages de listing, pages de service.