Données structurées et JSON-LD : guide pratique d'implémentation SEO

Les données structurées aident les moteurs de recherche à comprendre le sujet d'une page. JSON-LD est la méthode la plus courante pour les ajouter, car elle garde les données lisibles par machine séparées du HTML visible.

Les données structurées peuvent rendre une page éligible à des fonctionnalités de recherche enrichies, mais elles ne garantissent pas de rich results. Google et d'autres moteurs décident quoi afficher selon la qualité de la page, l'intention de recherche, les règles d'éligibilité et de nombreux autres signaux.

Références utiles :

Ce que font les données structurées

Les données structurées donnent un sens explicite au contenu d'une page. Au lieu de voir seulement du texte, un moteur de recherche peut comprendre qu'une page est un article, un produit, une application logicielle, un fil d'Ariane, une section FAQ ou un autre type d'entité reconnu.

De bonnes données structurées doivent :

Correspondre au contenu visible de la page.
Utiliser le type Schema.org pertinent le plus spécifique.
Inclure les propriétés requises et recommandées.
Rester exactes lorsque le contenu change.
Être validées avant déploiement.

N'utilisez pas les données structurées pour décrire du contenu que les utilisateurs ne peuvent pas voir. C'est un problème qualité courant et cela peut rendre le markup inéligible.

Pourquoi JSON-LD est généralement le meilleur format

Il existe plusieurs formats de données structurées, mais JSON-LD est généralement le plus facile à maintenir.

Format	Ajout	Maintenance
JSON-LD	Bloc `<script type="application/ld+json">`	Propre et séparé du HTML
Microdata	Attributs dans les éléments HTML	Facile à casser lors de changements de template
RDFa	Attributs dans les éléments HTML	Puissant mais plus complexe

Avec JSON-LD, le markup frontend peut changer sans réécrire chaque attribut de données structurées.

Pattern JSON-LD de base

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Structured Data and JSON-LD: Practical SEO Implementation Guide",
  "description": "Learn how to add JSON-LD structured data safely.",
  "author": {
    "@type": "Person",
    "name": "Sarah Miller"
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16"
}
</script>

Les champs de base sont :

@context : normalement https://schema.org.
@type : le type Schema.org, par exemple Article.
Propriétés : champs décrivant l'entité, comme headline, author ou datePublished.

Markup Article

Utilisez Article, BlogPosting ou NewsArticle pour le contenu éditorial. Choisissez le type qui correspond le mieux à la page. Pour un article de blog classique, BlogPosting est souvent approprié.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Split a PDF Safely",
  "description": "A practical guide to extracting and splitting PDF pages.",
  "image": "https://example.com/images/pdf-split-guide.png",
  "author": {
    "@type": "Person",
    "name": "Rachel Kim"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Tools",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/pdf-split-guide"
  }
}
</script>

Soyez honnête avec les dates. Ne mettez pas à jour dateModified seulement pour donner une impression de fraîcheur si la page n'a pas réellement changé.

Markup BreadcrumbList

Les données structurées de fil d'Ariane aident les moteurs de recherche à comprendre la hiérarchie de la page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "PDF Split Guide",
      "item": "https://example.com/blog/pdf-split-guide"
    }
  ]
}
</script>

Le fil d'Ariane dans JSON-LD doit correspondre à la navigation compréhensible par les utilisateurs sur la page.

Markup FAQPage

Ajoutez FAQPage uniquement lorsque la page contient réellement des questions et réponses visibles. N'ajoutez pas de fausses FAQs seulement pour cibler des rich results.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does structured data guarantee rich results?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Structured data can make a page eligible, but search engines decide whether to show enhanced results."
      }
    },
    {
      "@type": "Question",
      "name": "Should JSON-LD match visible page content?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Markup should describe content that users can also see on the page."
      }
    }
  ]
}
</script>

Le markup FAQ n'est pas un raccourci vers plus d'espace dans la recherche. Utilisez-le seulement s'il améliore la clarté pour les utilisateurs.

Markup SoftwareApplication

Pour les outils en ligne, apps ou logiciels téléchargeables, SoftwareApplication peut décrire ce que la page propose.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "PDF Split Tool",
  "applicationCategory": "UtilitiesApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/pdf/split",
  "description": "Split a PDF into selected pages or smaller files in the browser.",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}
</script>

N'incluez que des champs vrais. Si vous ajoutez notes, avis, prix ou claims de plateforme, ils doivent être soutenus par du contenu visible et l'état réel du produit.

Plusieurs blocs JSON-LD

Vous pouvez inclure plusieurs entités de données structurées sur une page. Par exemple, un article de blog peut aussi avoir des breadcrumbs.

Soit avec des blocs script séparés :

<script type="application/ld+json">{ "...Article data..." }</script>
<script type="application/ld+json">{ "...Breadcrumb data..." }</script>

Soit avec un tableau :

<script type="application/ld+json">
[
  { "@context": "https://schema.org", "@type": "BlogPosting" },
  { "@context": "https://schema.org", "@type": "BreadcrumbList" }
]
</script>

Les blocs séparés sont souvent plus faciles à générer depuis des templates.

Workflow de validation

Utilisez un workflow simple avant publication :

Générer JSON-LD depuis les mêmes données source que la page.
Vérifier que le markup est du JSON valide.
Passer l'URL ou le code dans le Rich Results Test.
Après indexation, surveiller les rapports de données structurées dans Search Console.
Re-vérifier les templates après de grands changements de design, routage ou CMS.

Une validation réussie signifie que la syntaxe et certaines règles d'éligibilité sont satisfaites. Cela ne garantit toujours pas un rich result.

Erreurs courantes

Le markup ne correspond pas au contenu visible

Si JSON-LD dit que la page a des avis, FAQs, prix ou détails d'auteur, les utilisateurs doivent pouvoir vérifier ces détails sur la page.

Mauvais type

N'utilisez pas Product pour chaque page d'outil simplement parce que les rich results produit paraissent attractifs. Utilisez le type qui correspond à la page.

Notes fausses ou non soutenues

Le markup d'avis et notes nécessite de vrais avis visibles. N'inventez pas d'aggregate ratings.

Dates incohérentes

datePublished et dateModified doivent correspondre au cycle réel du contenu. Mettez à jour les dates modifiées seulement lors de changements significatifs.

URLs cassées

Les URLs d'image, logo, canonical et page doivent être absolues, crawlables et stables.

Incohérence de langue

Pour les sites multilingues, chaque page localisée doit avoir des données structurées dans la même langue que la page, avec les liens canonical et alternate corrects gérés ailleurs dans la page.

Conseils d'implémentation

Générez les données structurées depuis votre CMS ou métadonnées de page, pas à la main sur chaque page.
Échappez correctement le texte généré par les utilisateurs pour que le JSON reste valide.
Gardez un template réutilisable pour chaque type de page.
Testez des pages représentatives, pas seulement la page d'accueil.
Revalidez après changement de routes, slugs, profils d'auteur ou génération d'images.
Considérez les warnings comme des pistes d'amélioration, mais priorisez les erreurs.

Checklist finale

Avant de livrer JSON-LD, confirmez :

Le markup décrit le contenu visible de la page.
Le type Schema.org correspond à la page.
Les champs requis sont présents.
Les URLs sont absolues et crawlables.
Dates, auteurs, titres et descriptions correspondent à la page.
La page passe le Rich Results Test lorsque applicable.
Search Console est surveillé après déploiement.

Les données structurées ne sont pas une astuce pour forcer des résultats de recherche plus riches. C'est une façon propre de rendre explicite le sens d'une page. Lorsqu'elles sont exactes, maintenues et alignées avec le contenu visible, elles augmentent les chances que les moteurs de recherche comprennent correctement le contenu.