Quand utiliser le schema Article ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Article, BlogPosting et NewsArticle

Schema.org propose plusieurs types proches pour représenter des contenus éditoriaux. Article est général, BlogPosting décrit plus précisément un billet de blog et NewsArticle correspond à un contexte d’actualité. Le choix doit suivre la nature réelle du document publié.

Une documentation produit, une page de service ou un guide permanent peut rester une WebPage même si son contenu est long. Le bon schema ne dépend pas du nombre de mots mais de l’entité que représente réellement la page.

Décrire un auteur réel

Lorsque la page est un véritable article, l’auteur structuré doit correspondre à la personne ou à l’organisation réellement responsable du contenu. Si une attribution visible existe, le JSON-LD ne doit pas présenter un autre auteur ou inventer une expertise supplémentaire.

Une URL d’auteur doit elle aussi désigner une ressource permettant réellement d’identifier cet auteur. Créer artificiellement une page ou une entité Person uniquement pour compléter le markup n’améliore pas la véracité du document.

Utiliser datePublished et dateModified correctement

datePublished représente la vraie première publication. dateModified représente une modification éditoriale réelle. Elle ne doit pas changer simplement parce qu’une release technique, un rebuild ou une modification sans effet sur le fond vient d’avoir lieu.

Les dates structurées ne doivent pas contredire celles visibles par l’utilisateur. Une politique de maintenance doit également définir quelle source de données les alimente afin d’éviter qu’un CMS, un générateur statique et le JSON-LD publient trois dates différentes.

Ne pas confondre auteur et publisher

L’auteur désigne la responsabilité éditoriale du contenu ; le publisher désigne l’organisation qui le publie lorsque cette propriété est pertinente dans le modèle utilisé. Ces rôles peuvent être portés par la même organisation mais ils ne sont pas conceptuellement interchangeables.

Le nom, le logo, l’URL et les autres propriétés utilisées doivent être vrais et stables. Ajouter un publisher artificiel ou une marque différente de celle qui publie réellement la page crée une donnée structurée plus riche en apparence mais moins fiable.

Aligner contenu visible et JSON-LD

Le titre, l’auteur, les dates, la description et l’URL structurés doivent rester compatibles avec la page. Cette règle évite que le JSON-LD devienne une base parallèle contenant des informations différentes de ce que les visiteurs peuvent vérifier.

Canonical et indexabilité doivent aussi être prises en compte. Un objet Article qui décrit une URL alors que la page canonicalise vers une autre ressource introduit une incohérence structurelle qu’un simple test de syntaxe JSON ne peut pas détecter.

Valider le sens, pas seulement la syntaxe

Un outil peut confirmer qu’un JSON-LD est parfaitement formé sans savoir si le contenu décrit est vrai. Le contrôle doit donc distinguer la syntaxe Schema.org, les exigences éventuelles d’une fonctionnalité de recherche et la cohérence éditoriale.

Aucun balisage Article ne doit être présenté comme une garantie de résultat enrichi, de classement ou de visibilité. Les données structurées servent d’abord à fournir une description exploitable et cohérente de la ressource.

Gouverner Article à l’échelle du site

Lorsque plusieurs équipes publient des articles, une convention commune évite les divergences : choix du type, format des auteurs, source des dates, URL d’auteur et identité du publisher. Sans cette convention, deux contenus comparables peuvent recevoir des structures totalement différentes selon le template utilisé.

Une validation automatisée peut vérifier les propriétés attendues pour votre modèle interne, mais elle doit rester accompagnée d’un contrôle sémantique. L’automatisation sait repérer un champ absent ; elle ne sait pas toujours déterminer si la personne indiquée est réellement l’auteur du contenu.

Prévoir la maintenance avant d’ajouter Article

Un balisage éditorial n’est réellement utile que si l’équipe peut le maintenir. Une dateModified laissée figée après plusieurs révisions, un auteur disparu du contenu visible ou un publisher qui ne correspond plus à la structure éditoriale créent progressivement une divergence.

Avant d’ajouter des propriétés supplémentaires, il faut donc savoir quel système les met à jour, quelle donnée fait autorité et comment les changements seront contrôlés lors des prochaines publications.

Distinguer un article d’une page qui parle d’un article

Une page d’actualité publiée avec une date, un auteur et un corps éditorial peut correspondre à NewsArticle ou Article selon son contexte. Un billet de blog peut être décrit comme BlogPosting. En revanche, une page qui explique comment utiliser le schema Article reste elle-même une page de connaissance : son sujet n’est pas son type.

Cette distinction paraît simple mais elle évite de nombreux marquages artificiels. Le choix doit toujours partir de la fonction réelle du document pour l’utilisateur, puis seulement sélectionner le type structuré le plus précis qui reste vrai.

Contrôler les variantes de template

Si plusieurs templates publient des contenus éditoriaux, vérifiez qu’ils appliquent la même logique de type et de propriétés. Une différence historique entre mobile, blog, actualités ou pages syndiquées peut produire des objets Article incompatibles pour des contenus comparables. Un échantillon par famille de template permet de détecter ces divergences avant qu’elles ne deviennent massives.

Méthode de vérification

Cette séquence visible aide à appliquer la méthode. Elle ne crée pas de données structurées HowTo.

1. Confirmer que la page est réellement un contenu éditorial.
2. Choisir Article, BlogPosting ou NewsArticle selon la nature du document.
3. Renseigner uniquement des propriétés vraies et maintenables.
4. Aligner auteur, dates, publisher, URL et canonical.
5. Valider la syntaxe puis relire humainement le sens du balisage.
6. Prévoir qui mettra à jour ces données lors des futures modifications.

Questions fréquentes

Une longue page doit-elle forcément utiliser Article ?

Non. La longueur ne détermine pas le type Schema.org.

Faut-il toujours ajouter un auteur ?

Non. Il faut uniquement représenter une attribution réelle et pertinente.

dateModified doit-elle changer à chaque déploiement ?

Non. Elle doit correspondre à une vraie modification éditoriale.

Article garantit-il un résultat enrichi ?

Non. Le balisage n’est pas une garantie de fonctionnalité enrichie ni de classement.

Sources de référence : Google Search Central — Article · Google — galerie des données structurées