Configurer

Choisissez un type schema.org et remplissez les champs. Les champs obligatoires sont marqués d'un *.

Type de schéma

Article

Titre principal*

0/110

Le titre principal est obligatoire pour un schéma Article valide.

Description

URL de l'image

Date de publication*

Champ obligatoire.

Date de modification

Auteur

Nom de l'auteur*

Le nom de l'auteur est obligatoire.

URL de l'auteur

Éditeur

Nom de l'éditeur

URL du logo de l'éditeur

Page

Entité principale de la page (URL)

Résultat

À coller dans une balise script[type=application/ld+json] dans l'en-tête de votre page.

schema.jsonld

{
  "@context": "https://schema.org",
  "@type": "Article"
}

Tester dans Google Rich Results

Votre robots.txt est prêt — mais ce n'est qu'un des 99+ signaux SEO.

Lancer un audit gratuit →

Qu'est-ce que les données structurées et pourquoi sont-elles importantes ?

Les données structurées sont une couche de métadonnées que vous ajoutez à une page web pour décrire son contenu dans un format lisible par les machines. Le corps de la page est ce que voient les humains ; les données structurées sont ce que lisent les moteurs de recherche, les assistants vocaux et les agrégateurs de contenu pour comprendre de quoi parle la page. Un billet de blog devient un Article clairement identifié avec un auteur, une date de publication et un titre. Une fiche produit devient un Product avec un prix, une disponibilité et des avis. Une adresse commerciale devient une LocalBusiness avec une adresse, des horaires et un numéro de téléphone. Le vocabulaire qui définit tous ces types est Schema.org, un projet collaboratif lancé en 2011 par Google, Microsoft, Yahoo et Yandex.

La raison pour laquelle les données structurées sont importantes, ce sont les résultats enrichis. Lorsqu'une page dispose de données structurées valides et que Google estime que la requête et la qualité du contenu le justifient, le SERP affiche des fonctionnalités améliorées en complément ou à la place de l'extrait habituel. Des notes en étoiles apparaissent sous les résultats produits. Des accordéons FAQ apparaissent sous les articles. Des fils d'Ariane remplacent la ligne d'URL. Les fiches recettes affichent le temps de cuisson et le nombre de calories. Les listes d'événements affichent la date et le lieu. Chacun de ces enrichissements occupe plus d'espace vertical, distingue visuellement le résultat et augmente sensiblement le taux de clic. Un résultat en troisième position avec un extrait enrichi surpasse régulièrement un résultat en première position avec un simple lien bleu.

Au-delà du SERP, les données structurées alimentent le web sémantique au sens large. Les assistants vocaux comme Google Assistant et Alexa lisent le schema pour répondre aux questions. Le Knowledge Graph de Google utilise le schema pour construire des profils d'entités. Les agrégateurs comme Google Shopping, Google Travel et Google Jobs s'appuient sur les données structurées pour alimenter leurs verticaux. Sans schema, votre contenu est du texte qui doit être interprété ; avec le schema, ce sont des données qui peuvent être citées directement.

La hiérarchie de traitement de Google est importante lorsque vous avez le choix du format. L'équipe a indiqué depuis 2015 que JSON-LD est le format préféré, et une confirmation de 2020 a précisé que JSON-LD est analysé plus rapidement et plus fiablement que les alternatives en ligne. L'ordre de préférence est JSON-LD en premier, Microdata en deuxième, RDFa en troisième. Mélanger les formats sur la même page produit des résultats incohérents — Google peut en choisir un, les fusionner, ou signaler le conflit — donc engagez-vous sur JSON-LD et évitez les mélanges. JSON-LD présente également l'avantage pratique de se trouver dans une balise <script type="application/ld+json"> dans le head, séparé du HTML rendu, ce qui facilite la maintenance et le contrôle de version.

Comment utiliser ce générateur

Le formulaire est regroupé par type de schema, et vous ne remplissez que les champs qui s'appliquent à votre page.

Étape 1 — Choisissez le type de schema. Choisissez Article, Product, Organization, LocalBusiness, FAQPage ou BreadcrumbList selon ce que représente réellement la page. Le générateur n'émet des balises que pour les types correspondant à un contenu réel de la page ; il ne vous permet pas de fabriquer des entrées FAQ ou des avis produits pour manipuler les résultats enrichis.

Étape 2 — Remplissez les champs requis. Chaque type de schema possède un ensemble de champs requis défini par la documentation des données structurées de Google. Le générateur met en évidence les champs requis en rouge et signale les valeurs manquantes avant de générer la sortie. Les champs optionnels sont visibles mais réductibles pour garder le formulaire court.

Étape 3 — Copiez le JSON-LD et collez-le dans votre <head>. La sortie est un bloc unique <script type="application/ld+json">. Collez-le dans le head de la page que le schema décrit. Validez immédiatement après dans le Rich Results Test — si l'outil de Google signale des erreurs, aucun résultat enrichi ne s'affichera jamais en production.

Types de schema et quand utiliser chacun

Le vocabulaire Schema.org contient des centaines de types, mais un petit ensemble couvre la majorité des pages réelles.

Article, NewsArticle, BlogPosting

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Comment rédiger une meta description",
  "datePublished": "2026-04-27T10:00:00+00:00",
  "dateModified": "2026-04-27T12:00:00+00:00",
  "author": { "@type": "Person", "name": "Jane Smith" },
  "publisher": {
    "@type": "Organization",
    "name": "Exemple",
    "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }
  },
  "mainEntityOfPage": "https://example.com/blog/meta-description"
}

Article est le type parent générique. NewsArticle est destiné au contenu journalistique et éditorial — reportages, enquêtes, tout ce qui a une date de publication et un processus éditorial. BlogPosting est pour le contenu au format blog — billets d'opinion, tutoriels, articles personnels. Utilisez le sous-type le plus spécifique qui s'applique réellement. Google récompense la spécificité dans le schema en affichant les bons résultats enrichis : NewsArticle est éligible au carrousel Top Stories, contrairement à Article simple. Les champs requis sont headline, datePublished, author et une image pour l'éligibilité aux résultats enrichis.

Product

Le schema Product vous donne des notes en étoiles, des affichages de prix et des badges de disponibilité dans la recherche. Les champs requis sont name, image, et soit offers (avec prix et devise) soit review et aggregateRating. La note agrégée est le champ qui produit les étoiles dorées sous le résultat, mais Google a resserré les règles depuis 2019 : la note doit être dérivée d'avis réels de première partie sur la page elle-même, et non extraite de sources tierces. Falsifier des notes ou réutiliser des notes tierces comme si elles vous appartenaient est une action manuelle en attente de se produire.

Organization

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Inc.",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://twitter.com/example",
    "https://linkedin.com/company/example",
    "https://en.wikipedia.org/wiki/Example_Inc"
  ]
}

Le schema Organization va sur la page d'accueil et la page À propos. Il indique aux moteurs de recherche qui publie le site, ce qui alimente le profil d'entité du Knowledge Graph qui apparaît dans le panneau latéral droit pour les recherches de marque. Le champ sameAs est le plus important et le plus souvent omis — il répertorie les profils externes faisant autorité qui confirment l'identité de l'organisation. Sans sameAs, Google doit déduire l'entité du contexte ; avec sameAs, le lien est explicite.

LocalBusiness

LocalBusiness étend Organization avec des champs spécifiques à la localisation : address, geo (latitude et longitude), openingHoursSpecification, telephone et priceRange. Il est requis pour le Knowledge Panel qui apparaît dans la recherche locale et Google Maps. Utilisez le sous-type le plus spécifique : Restaurant, Dentist, AutoRepair, LegalService, et ainsi de suite, chacun ayant son propre sous-type. La liste complète se trouve dans la section LocalBusiness de Schema.org. Inclure le mauvais sous-type — Restaurant pour un café, Store pour une entreprise de services — perturbe la recherche locale et réduit la visibilité pour les bonnes requêtes.

FAQPage

Le schema FAQPage balise des questions et réponses dans un format Q-et-R. Le format est simple — un tableau mainEntity d'objets Question, chacun avec un acceptedAnswer — mais l'éligibilité aux résultats enrichis s'est considérablement réduite depuis 2023. Google restreint désormais les résultats enrichis FAQ aux sites gouvernementaux et de santé faisant autorité, et la plupart des pages marketing ne voient plus l'accordéon dans la recherche même avec un balisage valide. Le schema vaut toujours la peine d'être inclus car il aide Google à comprendre la structure de la page, mais n'attendez pas de résultats enrichis en dehors des verticaux éligibles.

BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Accueil",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Article actuel"
    }
  ]
}

BreadcrumbList remplace la ligne d'URL dans le SERP par un fil d'Ariane cliquable, ce qui est l'un des résultats enrichis les plus fiablement affichés sur Google. La page actuelle (le dernier élément) n'a pas besoin d'une URL item — son absence indique à Google qu'il s'agit de la position finale. Incluez toujours BreadcrumbList sur chaque page plus profonde que la page d'accueil ; cela ne coûte rien et améliore systématiquement le CTR.

Lier des entités avec @id et sameAs

La plupart des pages réelles contiennent plusieurs entités — un Article avec un auteur, un éditeur et un fil d'Ariane. Sans coordination, vous finissez par déclarer la même Organization trois fois dans trois blocs de schema différents, sans moyen pour les moteurs de recherche de savoir qu'il s'agit de la même entité. Le modèle @id résout ce problème.

Attribuez à chaque entité un @id stable et unique qui ressemble à une URL — généralement l'URL canonique de la page avec un identifiant de fragment comme #organization, #article ou #author. Une fois qu'une entité est déclarée avec un @id, toute référence ultérieure peut être un objet { "@id": "..." } au lieu d'un doublon complet.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Exemple",
      "url": "https://example.com",
      "logo": "https://example.com/logo.png"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/article#article",
      "headline": "Titre",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

Le wrapper @graph vous permet de déclarer plusieurs entités de premier niveau dans un seul bloc JSON-LD, avec les liens @id établissant les relations. C'est la meilleure pratique moderne pour toute page avec plus d'une entité, et c'est ainsi que les plugins SEO comme Yoast et Rank Math structurent leur sortie.

sameAs est la propriété partenaire de @id. Là où @id lie des entités au sein du site, sameAs lie des entités à leurs représentations canoniques ailleurs — la page Wikipédia, l'entrée Wikidata, les profils officiels Twitter et LinkedIn. Les moteurs de recherche utilisent sameAs pour effectuer la réconciliation d'entités, confirmant que votre Organization est bien celle que les utilisateurs recherchent quand ils cherchent la marque. Incluez toujours sameAs sur le schema Organization, Person et les entités à forte valeur.

Erreurs courantes qui nuisent au SEO

Schema pour du contenu qui n'apparaît pas sur la page. Schema FAQ pour des questions qui ne sont pas réellement affichées, schema Product avec des avis qui n'existent pas, schema Recipe sur une page qui ne contient pas de recette — tout cela viole les directives de données structurées de Google et peut déclencher des actions manuelles. Le schema doit décrire un contenu visiblement présent sur la page.

Mauvais type de schema. Utiliser Article pour une fiche produit, Organization pour un blog personnel, LocalBusiness pour un service uniquement en ligne. Le mauvais type perturbe les moteurs de recherche et empêche les bons résultats enrichis de s'afficher. Choisissez le type le plus spécifique qui convient réellement, et consultez l'arborescence des types Schema.org en cas de doute.

Mélanger JSON-LD avec Microdata ou RDFa. Lorsque la même page déclare la même entité dans deux formats, le comportement de Google est indéfini — il peut fusionner, en choisir un, ou signaler le conflit dans Search Console. Engagez-vous sur JSON-LD et supprimez les données structurées en ligne du HTML rendu.

Ignorer les champs requis. Chaque type de résultat enrichi a des champs requis documentés sur developers.google.com/search. Article exige headline, datePublished, author et une image. Product exige name, image et soit offers soit des données de notation. L'absence d'un champ requis signifie qu'aucun résultat enrichi ne s'affichera, même si le reste du balisage est parfait. Le Rich Results Test met en évidence ce qui manque.

dateModified obsolète. Un schema Article avec une valeur dateModified qui ne change jamais signale à Google que la page est stagnante. Inversement, mettre à jour dateModified à chaque régénération de page sans changement de contenu réel est également un signal — Google détecte le schéma et dévalue le champ. Définissez dateModified à la vraie heure de dernière modification du contenu.

Valeurs @id dupliquées ou récursives. Deux entités partageant le même @id, ou une entité référençant son propre @id, brise le graphe. Chaque @id doit être unique dans le bloc JSON-LD. Le modèle consistant à utiliser des identifiants de fragment comme #organization, #author, #article maintient les ID prévisibles et uniques.

Valider une fois et ne plus jamais. Le balisage schema qui fonctionnait au lancement peut se casser de multiples façons : une mise à jour du CMS change le format des dates, une traduction supprime un champ requis, un refactoring de template supprime entièrement le JSON-LD. Exécutez le Rich Results Test sur au moins une page par type de schema après chaque déploiement significatif.

Cas limites que personne ne mentionne

Le JSON-LD n'est pas visible pour les humains, mais il l'est pour les attaquants et les concurrents qui consultent la source de votre page. Un schema qui liste des employés internes par nom, expose des adresses e-mail professionnelles ou détaille des prix non affichés sur la page peut divulguer des informations que vous préféreriez garder privées. La recommandation est de ne mettre dans le JSON-LD que des données déjà publiques ailleurs sur la page. L'autre cas limite est le rendu : le schema injecté côté client par JavaScript peut être manqué lors du premier passage d'exploration de Googlebot, car la file d'attente de rendu est séparée de la file d'indexation et s'exécute plus tard. Pour le schema qui affecte les résultats enrichis, le rendu côté serveur ou la génération statique est la voie sûre.

Générateur JSON-LD Schema.org gratuit