Retour à « Les bases SEO techniques »
Les bases SEO techniques4 min de lecture

Les données structurées Schema.org : les implémenter

Types prioritaires (Organization, Product, FAQPage, Article, BreadcrumbList), exemple JSON-LD commenté, et outils de validation.

Une fois le principe des données structurées compris, reste la question pratique : quels types de Schema.org implémenter en priorité, comment écrire le JSON-LD correspondant, et comment vérifier que le balisage est valide.

Les types prioritaires

Cinq types couvrent la grande majorité des besoins d'un site :

  • Organization : identité de l'entreprise (nom, logo, réseaux sociaux, coordonnées) — généralement posé une seule fois, sur la page d'accueil ou en global.
  • Product : fiche produit, avec prix, disponibilité, avis.
  • FAQPage : liste de questions-réponses, particulièrement utile pour être repris directement dans une réponse d'IA générative.
  • Article : contenu éditorial (blog, actualité, guide), avec auteur, date de publication et de mise à jour.
  • BreadcrumbList : fil d'Ariane, qui explicite la position d'une page dans l'arborescence du site.

D'autres types existent pour des besoins plus spécifiques : Event pour un événement avec date et lieu, LocalBusiness pour un commerce avec adresse physique et horaires, Review pour un avis individuel distinct d'une note agrégée, ou HowTo pour un contenu structuré en étapes. Mieux vaut implémenter correctement les cinq types prioritaires avant d'étendre le balisage à des types plus spécialisés dont le bénéfice dépend fortement du secteur d'activité.

Exemple JSON-LD commenté

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nom du produit",
  "description": "Description courte et factuelle du produit.",
  "brand": {
    "@type": "Brand",
    "name": "NomMarque"
  },
  "offers": {
    "@type": "Offer",
    "price": "99.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128"
  }
}
</script>

Chaque propriété doit refléter une information réellement présente et vérifiable sur la page : le prix affiché doit correspondre au prix balisé, la note moyenne doit correspondre à des avis réels et consultables.

Pour une page de questions fréquentes :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Combien de temps dure la mise en place ?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "La mise en place prend généralement entre 2 et 5 jours ouvrés selon la complexité du projet."
      }
    }
  ]
}
</script>

Où placer le code

Le JSON-LD s'insère généralement dans le <head> ou juste avant la fermeture du <body>, sans dépendance à la mise en forme visuelle de la page — contrairement à un balisage HTML5 sémantique, qui reste intimement lié à la structure visuelle du document. C'est un des avantages du JSON-LD par rapport aux syntaxes alternatives (microdata, RDFa) qui nécessitent d'annoter directement les balises HTML visibles. Cette indépendance vis-à-vis du rendu visuel permet également de le générer dynamiquement à partir d'une base de données (fiche produit, système de gestion de contenu) sans intervention manuelle sur chaque page, ce qui en fait une solution particulièrement adaptée aux sites comportant un grand nombre de pages similaires.

Outils de validation

Avant publication, deux vérifications s'imposent : la validation syntaxique (le JSON est-il bien formé, sans virgule superflue ni guillemet manquant) et la validation sémantique (les types et propriétés utilisés existent-ils dans le vocabulaire Schema.org, et sont-ils cohérents entre eux). Les outils de test de résultats enrichis de Google et les validateurs Schema.org communautaires permettent de repérer ces deux catégories d'erreurs avant mise en ligne, et de vérifier qu'aucune propriété obligatoire n'est manquante pour le type utilisé.

Ce contrôle mérite d'être répété après chaque modification du template qui génère le balisage, pas uniquement au moment de l'implémentation initiale : une évolution du CMS, un changement de structure de base de données ou une mise à jour de thème peuvent silencieusement casser un bloc JSON-LD généré dynamiquement, sans que rien ne le signale visuellement sur la page.

Combiner plusieurs types sur une même page

Une page peut légitimement porter plusieurs blocs Schema.org à la fois : une fiche produit peut combiner Product pour la fiche elle-même, BreadcrumbList pour le fil d'Ariane, et Organization pour l'identité de la marque qui la vend. Ces blocs peuvent être déclarés séparément dans plusieurs balises <script>, ou regroupés dans un même bloc via la propriété @graph, qui permet de relier explicitement plusieurs entités entre elles au sein d'un seul document JSON-LD. Cette seconde approche devient préférable dès que les entités doivent se référencer mutuellement (l'auteur d'un article, la marque d'un produit), car elle évite la duplication d'informations entre plusieurs blocs indépendants.

Erreurs fréquentes

  • Balisage dupliqué ou contradictoire entre plusieurs blocs JSON-LD sur la même page.
  • Données balisées qui ne correspondent plus au contenu visible après une mise à jour (prix changé sur la page mais pas dans le JSON-LD).
  • Utiliser un type Schema.org qui ne correspond pas réellement au contenu (marquer une page de blog comme Product).
  • JSON malformé qui invalide silencieusement tout le bloc.
  • Multiplier les types secondaires avant d'avoir correctement implémenté et validé les types prioritaires.

Cette leçon clôt la partie balisage technique du module. La checklist technique complète qui suit reprend l'ensemble des points couverts jusqu'ici sous forme de liste actionnable, avant de passer aux fondamentaux du GEO à proprement parler.