Quels exemples de JSON-LD copier pour décrire une marque, un article et un glossaire ?

Comment décrire une organisation en JSON-LD ?

En une fiche courte, exacte et identique à ce qui est affiché sur le site. Google n’impose aucune propriété pour une organisation et conseille d’en fournir autant qu’il est pertinent. Le modèle suivant décrit une marque fictive, dont toutes les adresses sont inventées.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Marque Alpha",
  "alternateName": "Alpha",
  "url": "https://marque-alpha.example/",
  "description": "Logiciel de facturation pour les indépendants.",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rue de l’Exemple",
    "addressLocality": "Ville-Exemple",
    "addressCountry": "FR"
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q0000000",
    "https://marque-alpha.example/a-propos/"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "email": "contact@marque-alpha.example"
  }
}

1. Le contexte désigne le vocabulaire schema.org, et le type décide des propriétés qui s’appliquent. Les trois autres modèles de la page ouvrent de la même façon.
2. Le nom est celui du site et des autres profils ; Google décrit aussi, parmi les propriétés recommandées, un autre nom courant, l’adresse, le point de contact et la description.
3. L’adresse du site est celle de la page d’accueil, sous une seule forme canonique.
4. Le champ sameAs liste des pages de référence qui identifient l’organisation sans ambiguïté, d’après schema.org. Seuls des profils réels, avec leur adresse exacte, y ont leur place ; l’identifiant Wikidata ci-dessus est inventé.
5. Le point de contact ne se renseigne que s’il existe, et son courriel doit être celui affiché sur le site.

Comment relier un article à son auteur et à ses dates ?

En le balisant comme un article, avec un titre, deux dates et un auteur identifiable. Google accepte les types Article, NewsArticle et BlogPosting, et recommande l’auteur, les dates de publication et de modification, le titre et une image. Le modèle suivant reprend ces champs pour un article fictif.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Comment lire un relevé de facturation",
  "image": "https://marque-alpha.example/images/releve.png",
  "datePublished": "2026-03-12T09:00:00+01:00",
  "dateModified": "2026-05-02T14:30:00+02:00",
  "author": {
    "@type": "Person",
    "name": "Camille Exemple",
    "url": "https://marque-alpha.example/equipe/camille-exemple/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Marque Alpha",
    "url": "https://marque-alpha.example/"
  }
}

1. Le type BlogPosting est l’un des trois que Google reconnaît pour un article.
2. Le titre est celui affiché sur la page, sans variante réservée aux machines.
3. Les deux dates suivent le format ISO 8601, d’après Google. Elles doivent correspondre aux dates visibles sur la page, d’après Google.
4. L’auteur est une personne ou une organisation ; Google recommande une adresse ou des pages de référence pour l’identifier. Pour schema.org, une personne peut même être fictive, ce que le nom de l’exemple est.
5. L’éditeur reprend l’organisation du premier modèle, pour que les deux fiches désignent la même entité.

Comment baliser un fil d’Ariane ?

En listant les pages de la chaîne qui mène à la page courante, chacune avec sa position, son nom et son adresse. schema.org définit un fil d’Ariane comme une chaîne de pages liées, qui se termine en général par la page courante. Le modèle suivant décrit une page d’aide fictive, à trois niveaux.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Accueil",
      "item": "https://marque-alpha.example/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Aide",
      "item": "https://marque-alpha.example/aide/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Premiers pas",
      "item": "https://marque-alpha.example/aide/premiers-pas/"
    }
  ]
}

1. Les éléments de la liste sont des objets de type ListItem, comme le prévoit schema.org.
2. Les positions sont des entiers qui commencent à un, d’après schema.org : le vocabulaire ne leur donne pas d’autre sens.
3. Chaque élément porte un nom et l’entité qu’il représente dans la liste, que schema.org décrit comme une entrée de la liste.
4. Le dernier élément est la page courante. Les noms doivent être ceux du fil d’Ariane visible sur la page.

Les exigences d’un moteur de recherche pour ce balisage figurent sur une page que nous n’avons pas ouverte : elles ne sont pas documentées ici, et ce modèle ne vaut que pour le vocabulaire de schema.org.

Comment décrire un glossaire en JSON-LD ?

En déclarant un ensemble de termes et, pour chacun, son nom et sa définition. D’après schema.org, un DefinedTermSet est un ensemble de termes définis, dont chacun est un objet à part. Le modèle suivant balise un glossaire fictif de deux termes, avec les définitions affichées sur la page.

{
  "@context": "https://schema.org",
  "@type": "DefinedTermSet",
  "name": "Glossaire de Marque Alpha",
  "url": "https://marque-alpha.example/glossaire/",
  "hasDefinedTerm": [
    {
      "@type": "DefinedTerm",
      "name": "Facture récurrente",
      "description": "Facture émise automatiquement à intervalle régulier.",
      "inDefinedTermSet": "https://marque-alpha.example/glossaire/"
    },
    {
      "@type": "DefinedTerm",
      "name": "Relance",
      "description": "Message qui rappelle à un client une facture impayée.",
      "inDefinedTermSet": "https://marque-alpha.example/glossaire/"
    }
  ]
}

1. L’ensemble porte un nom et une adresse ; la propriété qui lui rattache ses termes est hasDefinedTerm, d’après schema.org.
2. Chaque terme est un objet de type DefinedTerm, avec son nom et sa description, d’après schema.org.
3. La propriété inDefinedTermSet indique l’ensemble auquel le terme appartient. Ici, l’adresse de la page du glossaire joue ce rôle.
4. Les descriptions reprennent mot pour mot les définitions affichées : Google demande de ne pas baliser un contenu que les lecteurs ne voient pas.

Où placer le code, et comment le vérifier ?

Dans une balise script de type application/ld+json sur la page décrite, puis dans un outil de test avant la mise en ligne. Google recommande le JSON-LD, accepte aussi Microdata et RDFa, et propose son test des résultats enrichis. La liste suivante résume les contrôles.

• Chaque bloc décrit la page où il se trouve, et chaque champ a son équivalent visible sur cette page (Google).
• Les dates du balisage sont celles qui s’affichent sur la page (Google).
• Les adresses de sameAs sont celles de profils réels et à jour (schema.org).
• Le JSON est valide : une virgule en trop ou un guillemet droit mal fermé suffit à invalider le bloc entier.
• Le code est passé dans l’outil de test de Google avant la publication.
• Convention d’Abysia : aucun avis, aucune note ni aucune offre dans ses propres balisages, faute de donnée publique à y mettre.

Ces modèles décrivent des pages, ils ne font pas citer une marque : le guide de Google écrit que les données structurées ne sont pas requises pour ses fonctions d’IA, et aucune source consultée ne montre qu’un autre service s’en serve pour choisir ses réponses.