Guide pratique des données structurées

Guide du balisage JSON-LD pour un SEO pratique

JSON-LD aide les moteurs à comprendre ce qu’est une page, qui l’a publiée, son rôle dans votre site et quelles données utiliser dans les fonctionnalités de recherche supportées.

L’objectif utile n’est pas d’ajouter tous les types de schéma possibles. C’est d’avoir des données structurées précises, correspondant à la page visible, validées proprement et synchronisées aux changements de contenu.

La version courte utile

Utilisez JSON-LD quand vous pouvez décrire la page avec des faits honnêtes et visibles : titre, description, auteur, date de publication, fil d’Ariane, détails produit, données vidéo ou contenu clair de questions-réponses. N’ajoutez pas de schéma pour promettre des fonctionnalités que Google n’affiche plus ou pour baliser du contenu invisible aux utilisateurs.

Meilleur schéma initial Article, WebPage et BreadcrumbList pour la plupart des pages guides.
Meilleur flux de travail Générez le schéma à partir des mêmes métadonnées qui alimentent le titre, la description, le canonique et Open Graph.
Meilleur contrôle de réalité Le balisage FAQPage et WebSite peut encore décrire du contenu, mais ne basez pas votre stratégie sur des affichages Google obsolètes.

Ce que fait réellement JSON-LD

JSON-LD est un bloc de données structurées lisible par machine. Il se place généralement dans un script dans le head ou le corps de la page et décrit des entités avec le vocabulaire schema.org. Les moteurs l’utilisent comme couche de clarté sur le contenu visible.

Clarté du parseur

Signification

Il transforme les faits de la page en entités nommées et propriétés, comme Article, auteur, datePublication, BreadcrumbList ou SoftwareApplication.

Fonctionnalité de recherche

Éligibilité

Il peut rendre une page éligible aux résultats enrichis supportés, mais Google décide ce qu’il affiche selon qualité, politique, requête et disponibilité des fonctionnalités.

Graphe du site

Cohérence

Il offre à votre CMS ou app Blazor un endroit structuré pour réutiliser la même URL canonique, langue, titre, dates, images et données éditeur.

Pas un raccourci

Limite

Il ne corrige pas un contenu faible, faux avis, FAQ cachées, dates obsolètes ou pages non conformes aux données structurées.

Important : Les données structurées doivent soutenir la page, pas remplacer un contenu utile. Si la page visible est maigre, confuse, obsolète ou trompeuse, le balisage ne la rendra pas performante en recherche.

Choisissez le schéma selon la fonction de la page

La façon la plus simple d’éviter un balisage spammy ou dupliqué est de se demander ce que la page cherche à faire. Ajoutez le plus petit ensemble de schéma qui décrit précisément cette fonction.

Contenu

Article / BlogPosting

Utilisez-le pour
Guides, tutoriels, avis, articles d’actualité et explications détaillées.
Ajouter quand
La page a un titre clair, un auteur ou éditeur, une date de publication, une date de modification, une URL canonique et une image.
À éviter quand
La page est principalement une interface d’outil, une liste de produits, une page catégorie ou une page d’atterrissage maigre.

Navigation

BreadcrumbList

Utilisez-le pour
Presque toutes les pages sous la page d’accueil.
Ajouter quand
Les utilisateurs peuvent comprendre la place de la page dans la hiérarchie du site.
À éviter quand
Le chemin du fil d’Ariane ne correspond pas aux liens internes, URLs canoniques ou navigation visible.

Identité du site

WebPage / WebSite / Organization

Utilisez-le pour
Page d’accueil, hubs, pages à propos et pages où l’identité de l’éditeur compte.
Ajouter quand
Vous souhaitez un graphe d’entités stable qui relie la page, le site, l’éditeur et la langue.
À éviter quand
Vous ajoutez un balisage WebSite uniquement pour viser l’ancien affichage de la boîte de recherche sitelinks.

Produit ou application

Product / SoftwareApplication

Utilisez-le pour
Outils, apps, pages SaaS, extensions, logiciels téléchargeables ou vraies pages produit.
Ajouter quand
Le contenu visible de la page inclut nom, description, OS ou catégorie, prix, offres et notes lorsque vous les balisez.
À éviter quand
Notes, prix, disponibilité ou avis ne sont pas visibles des utilisateurs sur la page.

Questions

FAQPage

Utilisez-le pour
Sections questions-réponses visibles qui aident vraiment les utilisateurs à comprendre le sujet.
Ajouter quand
Le contenu Q&R est utile sur la page même si Google n’affiche pas les résultats enrichis FAQ.
À éviter quand
Vous ajoutez des Q&R génériques uniquement pour occuper de l’espace dans la recherche ou répéter la même réponse sur plusieurs pages.

Média

VideoObject / ImageObject

Utilisez-le pour
Pages avec vidéo intégrée importante, tutoriel vidéo ou image crawlable.
Ajouter quand
Le média est central sur la page et possède un titre, une description, une miniature, une date de mise en ligne et une URL stable.
À éviter quand
Le média est décoratif, caché, bloqué ou non pertinent pour l’objectif principal de la page.

Checklist d’implémentation pour éviter la plupart des erreurs

Un bon JSON-LD est ennuyeux dans le meilleur sens : cohérent, généré à partir de champs fiables, facile à valider et difficile à oublier lors d’un changement de page.

01

Choisissez une entité principale de page

Déterminez si la page est principalement un article, produit, application, vidéo, FAQ, collection ou page web générique. Le schéma secondaire doit soutenir l’entité principale.

02

Correspond au contenu visible

Chaque donnée balisée doit être visible ou clairement déductible sur la page : titre, auteur, dates, prix, note, Q&R, fil d’Ariane et images.

03

Utilisez des valeurs @id stables

Attribuez aux entités importantes des ID stables comme l’URL canonique suivie de #article, #webpage, #organization ou #faq. Cela aide les parseurs à relier les éléments du graphe.

04

Générer à partir des métadonnées partagées

Réutilisez les mêmes champs source qui créent titres, méta descriptions, URLs canoniques, images Open Graph, balises de langue et dates de dernière modification.

05

Gardez les dates honnêtes

Modifiez dateModified uniquement lors de changements significatifs du contenu. Ne rafraîchissez pas les dates automatiquement pour paraître plus récent dans les résultats.

06

Rendez les images crawlables

Utilisez des URLs d’images absolues, dimensions adaptées et fichiers non bloqués par robots, authentification ou rendu lazy-loading uniquement.

07

Rendre tôt

Dans Blazor et autres apps JavaScript, préférez un JSON-LD prerendered ou rendu serveur pour que les crawlers le voient dans le HTML initial.

08

Valider et surveiller

Exécutez le test des résultats enrichis avant publication, vérifiez la syntaxe avec le validateur, et surveillez Search Console après indexation.

Un modèle JSON-LD propre pour les pages Blazor

Pour Blazor, le modèle le plus sûr est de générer le schéma à partir des métadonnées lors de l’initialisation ou du prerendering, de le sérialiser une fois, puis d’afficher le script application/ld+json visible dans le HTML initial.

HTMLExemple JSON-LD d’article
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/en/json-ld-schema-guide/#article",
  "headline": "JSON-LD Schema Markup Guide for Practical SEO",
  "description": "A practical guide to choosing, generating, and validating structured data.",
  "image": "https://example.com/images/json-ld-guide.png",
  "datePublished": "2026-03-28T10:00:00+00:00",
  "dateModified": "2026-05-31T10:00:00+00:00",
  "author": {
    "@type": "Organization",
    "name": "Example Publisher"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Publisher",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/en/json-ld-schema-guide/"
  }
}
</script>
C#Modèle d’aide C#
private MarkupString BuildJsonLd(PageMetaData meta)
{
    var pageUrl = BuildPageUrl(meta);

    var schema = new Dictionary<string, object?>
    {
        ["@context"] = "https://schema.org",
        ["@type"] = "Article",
        ["@id"] = $"{pageUrl}#article",
        ["headline"] = meta.Title,
        ["description"] = meta.Description,
        ["url"] = pageUrl,
        ["datePublished"] = meta.Published?.ToString("O"),
        ["dateModified"] = meta.Modified?.ToString("O"),
        ["inLanguage"] = CS.Culture
    };

    var json = JsonSerializer.Serialize(schema, new JsonSerializerOptions
    {
        DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
    });

    return new MarkupString($"<script type=\"application/ld+json\">{json}</script>");
}
Règle pratique : Utilisez des URLs stables pour url et @id. Employez la même URL canonique partout. Si la même page existe sous plusieurs URLs linguistiques, générez des métadonnées spécifiques à chaque langue et maintenez une configuration hreflang/canonique cohérente.

Validez le JSON-LD avant de vous y fier

La validation a deux fonctions : le validateur de balisage vérifie la compréhension du vocabulaire et de la syntaxe JSON-LD. Le test des résultats enrichis Google vérifie si la page est reconnue comme éligible aux types de résultats enrichis supportés.

Éligibilité Google

Test des résultats enrichis

Vérifie si Google peut lire la page et si les données structurées détectées sont éligibles aux types de résultats enrichis supportés.

Ouvrir le test des résultats enrichis

Vocabulaire

Validateur de balisage Schema

Vérifie la structure générale schema.org et la syntaxe JSON-LD, incluant types, propriétés, entités imbriquées et JSON mal formé.

Ouvrir le validateur de balisage

Erreurs JSON-LD courantes qui nuisent à la confiance

La plupart des problèmes de schéma ne sont pas des bugs techniques complexes, mais des incohérences entre le balisage et ce que l’utilisateur ou crawler peut vérifier sur la page.

Balisage de contenu caché ou manquant

Si les utilisateurs ne voient pas la réponse, l’avis, l’offre, l’image ou l’auteur, ne les incluez pas dans les données structurées. C’est la façon la plus rapide de perdre la confiance.

Ajouter FAQPage partout

Le schéma FAQ peut décrire des Q&R visibles, mais ne doit pas être un copier-coller sur chaque article. Utilisez-le seulement si les Q&R améliorent la page.

Scripts en double conflictuels

Plusieurs blocs Article avec titres, dates ou URLs différentes compliquent l’interprétation. Un graphe clair vaut mieux que trois partiels.

Canonique ou @id incorrect

Les URLs du schéma doivent correspondre à la page canonique, à l’URL culturelle et à la configuration hreflang. Les URLs multilingues mélangées créent du contenu dupliqué et de la confusion d’entités.

Fausse actualité

Ne modifiez pas dateModified pour des changements de modèle, suivi ou mises à jour de schéma uniquement. Utilisez la date pour de vrais changements de contenu.

Rendu tardif côté client uniquement

Si le JSON-LD n’apparaît qu’après un rendu client différé, les crawlers peuvent le manquer. Privilégiez le rendu serveur ou prerendering pour les pages importantes.

Recettes pratiques de schéma par type de page

Vous avez rarement besoin d’un grand graphe. Ces combinaisons couvrent les pages que la plupart des petits sites, blogs, outils et projets d’avis publient réellement.

Article guide

Article + BreadcrumbList + WebPage

  • Utilisez Article pour titre, auteur, éditeur, image, dates et noms de section.
  • Utilisez BreadcrumbList pour le chemin visible du site.
  • Utilisez WebPage ou références @id pour relier la page et l’entité article.

Page outil

SoftwareApplication + WebPage + BreadcrumbList

  • Utilisez SoftwareApplication uniquement si la page concerne une vraie application ou un outil.
  • Incluez système d’exploitation, catégorie, prix ou détails d’offre uniquement s’ils sont visibles.
  • Évitez le balisage d’avis ou de notation sauf si la page affiche de vrais avis.

Page d’avis

Avis / Produit uniquement si la page le supporte

  • Balisage de l’élément évalué, auteur, date et note uniquement si clairement visibles sur la page.
  • Gardez les liens affiliés et le contexte commercial transparents.
  • Utilisez la même note dans le schéma et le contenu visible.

Page de questions

FAQPage uniquement pour Q&R visibles et utiles

  • Rendez chaque réponse utile en soi, pas seulement une variante de mot-clé.
  • Ne cachez pas les réponses derrière une interface bloquée inaccessible aux crawlers.
  • Ne comptez pas sur les résultats enrichis FAQ comme principal bénéfice SEO.

Sources vérifiées

Les conseils ci-dessus sont basés sur la documentation officielle de Google Search Central et schema.org, puis transformés en checklist JSON-LD pratique.

01 Introduction aux données structurées Google developers.google.com 02 Politiques des données structurées Google developers.google.com 03 Données structurées Article Google developers.google.com 04 Données structurées Fil d’Ariane Google developers.google.com 05 Données structurées FAQ Google developers.google.com 06 Mise à jour de la boîte de recherche sitelinks Google developers.google.com 07 Premiers pas avec Schema.org schema.org 08 Test des résultats enrichis Google search.google.com 09 Validateur de balisage Schema validator.schema.org

Questions fréquentes

Le balisage JSON-LD influence-t-il le classement ?

JSON-LD n’est pas un levier magique de classement. Il aide les moteurs à comprendre le contenu éligible et peut soutenir l’éligibilité aux résultats enrichis, mais le classement dépend toujours de la qualité, pertinence, crawlabilité, liens et autres signaux.

Où placer JSON-LD sur une page ?

Un script dans le head est généralement plus simple à gérer, mais Google peut aussi lire le JSON-LD dans le corps. L’essentiel est que le balisage soit présent dans la page rendue et corresponde au contenu visible.

Dois-je encore utiliser le schéma FAQPage ?

Utilisez FAQPage uniquement si la page contient des questions-réponses visibles et réellement utiles. Ne comptez pas dessus pour plus d’espace dans les résultats Google, car l’affichage FAQ est fortement réduit et déprécié pour la plupart des sites.

Une page peut-elle contenir plusieurs blocs JSON-LD ?

Oui. Une page article normale peut contenir Article, BreadcrumbList et WebPage. Gardez les blocs cohérents, évitez les entités dupliquées conflictuelles et utilisez des @id stables pour relier les éléments.

JSON-LD est-il meilleur que Microdata ?

Pour la plupart des sites modernes, oui. Google supporte JSON-LD, Microdata et RDFa, mais JSON-LD est plus facile à maintenir car il n’exige pas d’attributs schema dans le HTML visuel.

À quelle fréquence valider les données structurées ?

Validez à chaque modification de modèles, champs de métadonnées, helpers de schéma, URLs, routage linguistique, génération d’images, données d’avis ou sections FAQ. Vérifiez aussi Search Console après indexation des pages importantes.