JSON-LD pour le SEO : le guide des données structurées

De nombreux sites ont une implémentation JSON-LD qui est progressivement devenue un patchwork. Le schéma Organization sur chaque page. Des @id incohérents. Des nœuds Service mélangés avec BlogPosting là où ce n’est pas approprié. Des FAQ qui référencent du contenu absent de la page.

Le résultat : des erreurs de validation dans Search Console, des données structurées qui envoient des signaux peu clairs, et un balisage difficile à maintenir.

Cet article explique comment implémenter JSON-LD d’une manière qui passe à l’échelle et reste cohérente. Les données structurées ne remplacent pas le SEO technique, mais sont un élément essentiel pour indiquer clairement aux moteurs de recherche l’intention de votre page.

Pourquoi presque toutes les implémentations JSON-LD deviennent désordonnées

Les implémentations JSON-LD démarrent généralement bien. Un développeur ajoute le schéma Organization sur la homepage. Puis arrive une page produit, et elle reçoit aussi le schéma Organization. Et un nœud Service. Puis arrivent des articles de blog, et ils reçoivent Organization + BlogPosting. Avant même de s’en rendre compte, la même définition Organization se retrouve sur des centaines de pages, mais avec de subtiles différences parce qu’elles ont été ajoutées à différents moments.

5 symptômes concrets de dérive :

• Schéma Organization avec des valeurs différentes. Sur la page A, le logo est à 200x200px, sur la page B à 400x400px, sur la page C il est absent.
• Fragments @id incohérents. Certaines pages utilisent #organization, d’autres #company, encore d’autres pas de @id du tout.
• Types mélangés sans logique. Une page de contact a à la fois le schéma Service, AboutPage et ContactPage.
• Contenu FAQ inexistant. Le schéma FAQPage contient des questions qui n’apparaissent pas sur la page, parce qu’elles ont été copiées d’un template.
• Boucles auto-référentielles. WebPage.mainEntityOfPage se référence lui-même au lieu de pointer vers le Service ou le BlogPosting.

Ces problèmes surviennent parce qu’il n’y a pas de séparation claire entre ce qui appartient au niveau site-wide (toujours identique) et ce qui appartient au niveau page-level (unique par page). Pour qui réalise un audit SEO technique approfondi : c’est souvent l’un des premiers points bloquants qui remonte.

“Les pages avec des données structurées obtiennent 30% de clics de plus que les résultats de recherche standard.”

— BrightEdge (plateforme SEO data & analytics)

Les principes fondamentaux qui résolvent tout

Google recommande JSON-LD parce qu’il est plus facile à implémenter et à maintenir que Microdata ou RDFa. Mais seulement si vous le faites correctement.

Cinq principes :

1. Un script JSON-LD page-level par page

Placez toutes les données structurées spécifiques à la page dans un seul bloc <script type="application/ld+json"> avec un tableau @graph. Pas quatre scripts séparés pour WebPage, Service, BreadcrumbList et FAQ. Un script, un graph, tous les nœuds dedans.

2. Stratégie @id stable

Chaque nœud reçoit un @id unique basé sur l’URL canonique de la page plus un fragment. Par exemple : https://example.com/seo#webpage, https://example.com/seo#service, https://example.com/blog/article#blogpost. Vous utilisez ce pattern de manière cohérente sur tout le site.

3. Séparation stricte : site-wide vs page-level

Les entités site-wide (WebSite, Organization, Person) sont définies une fois dans un script séparé chargé sur chaque page. Les entités page-level (WebPage, Service, BlogPosting, BreadcrumbList, FAQPage) se trouvent dans le script spécifique à la page et référencent les entités site-wide via leur @id.

4. Faites correspondre exactement les URLs avec le canonical

Utilisez exactement la même URL que votre URL canonique sur la page. Si votre balise canonical est <link rel="canonical" href="https://example.com/a-propos">, utilisez exactement https://example.com/a-propos dans vos propriétés @id et url. Faites correspondre exactement www/non-www et les slashes finales avec votre stratégie canonique.

5. Preserve unless invalid (lors du nettoyage d’implémentations existantes)

Si vous assainissez une implémentation JSON-LD existante : ne modifiez pas le contenu à moins qu’il ne soit factuellement incorrect. Votre BlogPosting.description a 180 caractères ? Laissez-le. Il y a une URL d’image fonctionnelle ? Laissez-la. Ne changez que ce qui est vraiment faux. Cela évite un impact involontaire sur le classement lors du nettoyage.

“Les données structurées ne font pas mieux classer votre site. Elles sont utilisées pour afficher des fonctionnalités de recherche. Utilisez-les si vos pages sont adaptées à ces fonctionnalités.”

— John Mueller, Search Relations Team chez Google

Ce qui appartient au site-wide (et pourquoi)

Les entités site-wide sont des données identiques pour l’ensemble du site. Vous les définissez une fois dans un script chargé sur chaque page, généralement via le template de votre CMS ou un include d’en-tête.

Quelles entités appartiennent au site-wide :

WebSite (un site web, une entité WebSite) Contient : name, url, publisher (référence le @id d’Organization), inLanguage, potentialAction optionnel pour la recherche du site

Organization (une entreprise, une Organization) Contient : name, url, logo, sameAs (profils sociaux), contactPoint optionnel, address, areaServed

Person (auteur ou fondateur cohérent, optionnel) Contient : name, url, sameAs (LinkedIn, Twitter), worksFor (référence le @id d’Organization)

Ce qui N’appartient PAS au site-wide :

• Nœuds Service (uniques par page de service)
• BlogPosting (unique par article)
• BreadcrumbList (unique par page)
• FAQPage (unique par page où FAQ est présente)
• Product (unique par produit)

Guidance minimal vs étendu :

Commencez minimal. WebSite avec name, url, publisher. Organization avec name, url, logo. C’est suffisant. Ajoutez davantage uniquement quand vous pouvez valider que c’est correct et pertinent.

Tableau d’aperçu : ce qui va où

Template JSON-LD site-wide (copier-coller)

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "name": "[NOM_SITE]",
      "inLanguage": "fr-BE",
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "[NOM_ORGANISATION]",
      "url": "https://example.com",
      "logo": {
        "@type": "ImageObject",
        "url": "[URL_LOGO]"
      },
      "sameAs": [
        "[URL_SOCIAL_1]",
        "[URL_SOCIAL_2]",
        "[URL_SOCIAL_3]"
      ]
    },
    {
      "@type": "Person",
      "@id": "https://example.com/#fondateur",
      "name": "[NOM_FONDATEUR]",
      "url": "https://example.com/a-propos",
      "sameAs": [
        "[URL_LINKEDIN]"
      ],
      "worksFor": {
        "@id": "https://example.com/#organization"
      }
    }
  ]
}

Placez ce script dans le <head> de chaque page, ou via un template global include dans votre CMS.

Remplacez les placeholders :

• [NOM_SITE] : “ClickForest” ou votre nom d’entreprise
• [NOM_ORGANISATION] : Nom formel de l’entreprise
• [URL_LOGO] : URL complète vers votre logo (min. 112x112px, de préférence carré)
• [URL_SOCIAL_1/2/3] : URLs LinkedIn, Facebook, Instagram
• [NOM_FONDATEUR] : Nom du fondateur/CEO si pertinent
• [URL_LINKEDIN] : LinkedIn personnel du fondateur

Note sur Person : Ajoutez ce bloc uniquement si vous avez une composante personal brand dans votre entreprise (founder-led, thought leadership). Sinon, supprimez entièrement ce bloc.

“Cela aide leur contenu à être compris. Que ce soit les détails sur leur entreprise, les services qu’ils offrent, ou le contenu dans lequel ils investissent tant de temps.”

— Martha van Berkel, CEO de Schema App

JSON-LD page-level pour les pages ordinaires (services, localisations, etc.)

Pour les pages ordinaires (services, à propos, contact, pages de localisation), vous utilisez un ensemble de nœuds limité.

Checklist de base minimale :

• WebPage (toujours obligatoire)
• Service (uniquement si c’est vraiment une page de service)
• BreadcrumbList (optionnel, uniquement si vous implémentez les breadcrumbs de manière cohérente)
• FAQPage (optionnel, uniquement si la FAQ est effectivement sur la page)

Règles de liaison :

• WebPage.isPartOf référence le @id WebSite site-wide
• WebPage.mainEntity référence le @id Service
• Service.provider référence le @id Organization site-wide
• Service.mainEntityOfPage référence le @id WebPage

Cheatsheet de liaison par type de page

Template canonique pour page de service :

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://example.com/seo#webpage",
      "url": "https://example.com/seo",
      "name": "Services SEO",
      "description": "Optimisation SEO pour les entreprises en Belgique.",
      "isPartOf": {
        "@id": "https://example.com/#website"
      },
      "mainEntity": {
        "@id": "https://example.com/seo#service"
      }
    },
    {
      "@type": "Service",
      "@id": "https://example.com/seo#service",
      "serviceType": "Optimisation SEO",
      "name": "Services SEO",
      "description": "SEO technique, optimisation de contenu et linkbuilding.",
      "provider": {
        "@id": "https://example.com/#organization"
      },
      "areaServed": {
        "@type": "Country",
        "name": "Belgique"
      },
      "mainEntityOfPage": {
        "@id": "https://example.com/seo#webpage"
      }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://example.com/seo#breadcrumbs",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Accueil",
          "item": "https://example.com"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "SEO",
          "item": "https://example.com/seo"
        }
      ]
    }
  ]
}

Note sur BreadcrumbList : Ajoutez des breadcrumbs uniquement si vous les affichez effectivement sur la page, ou si votre site a une hiérarchie claire que vous pouvez maintenir de manière cohérente. Pas de manière ad hoc sur certaines pages et pas sur d’autres.

Note sur les pages Product : Les pages produit nécessitent le schéma Product avec des propriétés supplémentaires (offers, availability, reviews, aggregateRating, etc.). Cela sort du cadre de cet article.

JSON-LD page-level pour les articles de blog

Pour les articles de blog, vous utilisez un ensemble de nœuds légèrement différent.

• WebPage (obligatoire)
• BlogPosting (obligatoire)
• BreadcrumbList (fortement recommandé)
• FAQPage (optionnel, uniquement si FAQ est sur la page)
• BlogPosting.mainEntityOfPage référence le @id WebPage
• BlogPosting.author référence le @id Person site-wide (si défini)
• BlogPosting.publisher référence le @id Organization site-wide

Template canonique pour article de blog :

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://example.com/blog/seo-tips#webpage",
      "url": "https://example.com/blog/seo-tips",
      "name": "Conseils SEO pour 2026",
      "description": "Aperçu de conseils SEO pratiques.",
      "isPartOf": {
        "@id": "https://example.com/#website"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/seo-tips#blogpost",
      "headline": "Conseils SEO pour 2026",
      "description": "Aperçu de conseils SEO pratiques.",
      "image": "https://example.com/images/seo-tips-header.jpg",
      "datePublished": "2026-01-15T10:00:00+01:00",
      "dateModified": "2026-01-20T14:30:00+01:00",
      "author": {
        "@id": "https://example.com/#fondateur"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      },
      "mainEntityOfPage": {
        "@id": "https://example.com/blog/seo-tips#webpage"
      }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://example.com/blog/seo-tips#breadcrumbs",
      "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": "Conseils SEO pour 2026",
          "item": "https://example.com/blog/seo-tips"
        }
      ]
    }
  ]
}

Important pour dateModified : Ajoutez toujours dateModified quand vous mettez à jour un article. Cela aide les moteurs de recherche à mieux interpréter les modifications et peut contribuer à des signaux de fraîcheur plus clairs, ce qui est également pertinent pour l’optimisation GEO (Generative Engine Optimization).

“Le balisage Schema structure votre contenu pour que les machines ET les humains trouvent exactement ce dont ils ont besoin. Et quand les LLM vous comprennent mieux, ils vous citent plus souvent”

— Hamzah Khadim, expert SEO chez Logik Digital

Stratégie d’ID et d’URL robuste à grande échelle

Une stratégie @id cohérente est essentielle pour garder vos données structurées évolutives. Cela devient particulièrement crucial pour les sites avec des centaines de pages produit ou d’articles de blog.

Pattern strict pour les fragments @id :

• WebPage : [URL_CANONIQUE]#webpage
• Service : [URL_CANONIQUE]#service
• BlogPosting : [URL_CANONIQUE]#blogpost
• BreadcrumbList : [URL_CANONIQUE]#breadcrumbs
• FAQPage : [URL_CANONIQUE]#faq
• ImageObject (primary) : [URL_CANONIQUE]#primaryimage

Règles importantes :

• Utilisez exactement votre URL canonique. Copiez le href de votre balise <link rel="canonical">.
• Faites correspondre exactement www/non-www. Si le canonical est https://www.example.com, utilisez-le aussi dans JSON-LD.
• Faites correspondre exactement le slash final. Si le canonical se termine par /, utilisez-le aussi dans @id.
• Utilisez des fragments en minuscules. #webpage pas #WebPage ou #WEBPAGE.
• Cohérent sur tout le site. Pas #service sur la page A et #service-fr sur la page B.

Exemple d’implémentation en masse :

Si vous avez 200 pages produit, vous générez les @id de manière programmatique avec exactement la même logique que votre génération d’URL canonique. Pour les sites Shopify : vous pouvez automatiser cela via les templates liquid de votre thème.

Erreurs fréquentes (avec corrections)

Référence rapide : aperçu de 10 erreurs

Explication détaillée par erreur

{
  "name": "Service \"Premium\" Test"
}

{
  "name": "Service "Premium" Test"
}

{
  "name": "Service's Test"
}

{
  "name": "Test",
  "url": "https://example.com",
}

{
  "@type": "WebPage",
  "@id": "https://example.com/seo#webpage",
  "mainEntityOfPage": {
    "@id": "https://example.com/seo#webpage"
  }
}

1. Dupliquer le schéma Organization sur chaque page

Ce que vous voyez : Chaque page a sa propre définition Organization dans le JSON-LD page-level.

Pourquoi c’est problématique : Les incohérences entre pages peuvent envoyer des signaux peu clairs.

Correction : Déplacez Organization vers votre script site-wide. Laissez les scripts page-level référencer via {"@id": "https://example.com/#organization"}.

2. Mélanger BlogPosting et Service sur la même URL

Ce que vous voyez : Une page a à la fois @type: “BlogPosting” et @type: “Service”.

Pourquoi c’est problématique : Une page ne peut pas être à la fois un article de blog et un service. Cela peut mener à de l’ambiguïté.

Correction : Choisissez un type primaire. C’est un article décrivant un service ? BlogPosting. C’est une landing page pour un service ? Service + WebPage.

3. WebPage.mainEntityOfPage se référence lui-même

Ce que vous voyez : L’exemple d’erreur ci-dessus.

Pourquoi c’est faux : mainEntityOfPage est destiné à référencer d’une entité (Service, BlogPosting) vers la WebPage sur laquelle elle se trouve. Pas l’inverse.

Correction : Supprimez mainEntityOfPage du nœud WebPage. Utilisez mainEntityOfPage uniquement DANS le nœud Service/BlogPosting pour référencer en retour la WebPage.

4. Contenu FAQ absent de la page

Ce que vous voyez : Schéma FAQPage avec des questions qui ne figurent pas littéralement dans le HTML visible.

Pourquoi c’est faux : Les directives de Google exigent que les données structurées correspondent au contenu visible. Cela peut mener à une action manuelle.

Correction : Ajoutez le schéma FAQ uniquement si les questions ET les réponses sont effectivement présentes sur la page. Ne copiez pas des FAQ d’un template.

5. Descriptions avec des affirmations non prouvables

Ce que vous voyez : “description”: “Nous sommes la meilleure agence SEO de Belgique avec 500+ clients satisfaits”

Pourquoi c’est problématique : Si vous n’avez pas 500+ clients, c’est un balisage trompeur.

Correction : Utilisez uniquement des faits que vous pouvez prouver. Vous avez 50 clients ? Dites-le. Pas de données clients ? Omettez-les ou restez général.

6. Changer les formats d’URL à mi-chemin du site

Ce que vous voyez : La homepage utilise https://example.com, les sous-pages utilisent https://example.com/, d’autres encore https://www.example.com.

Pourquoi c’est problématique : Des @id incohérents brisent la liaison entre entités.

Correction : Choisissez un format d’URL canonique et utilisez-le partout.

7. sameAs surchargé de sources aléatoires

Ce que vous voyez : "sameAs": ["https://facebook.com/entreprise", "https://linkedin.com/company/entreprise", "https://annuaire-aleatoire.com/entreprise123"]

Pourquoi c’est problématique : sameAs est destiné aux sources officielles et faisant autorité. Pas à chaque endroit où votre entreprise est mentionnée.

Correction : Utilisez uniquement les profils sociaux officiels (LinkedIn, Facebook, Twitter, Instagram) et des sources officielles comme Wikipedia (si pertinent). Max 3-5 URLs que vous contrôlez et maintenez réellement.

8. Plusieurs scripts JSON-LD sans raison

Ce que vous voyez : Quatre blocs <script type="application/ld+json"> séparés sur une page pour WebPage, Service, BreadcrumbList et Organization.

Pourquoi c’est problématique : Inutilement complexe, difficile à maintenir, augmente le risque de duplication et d’incohérence.

Correction : Consolidez en deux scripts : un site-wide (WebSite, Organization, Person) et un page-level (WebPage, Service/BlogPosting, BreadcrumbList, FAQ) avec @graph.

9. JSON cassé par des erreurs de syntaxe

Le JSON est strict dans ses exigences de syntaxe. Trois erreurs fréquentes :

A. Virgules finales : JSON n’autorise pas de virgule finale après la dernière propriété. Correction : Supprimez la virgule après la dernière propriété dans chaque objet.

B. Guillemets typographiques : JSON requiert des guillemets droits (”) pour les clés et valeurs de chaîne. Correction : Remplacez tous les guillemets typographiques par des guillemets droits.

C. Guillemets dans les chaînes : Les guillemets dans une chaîne doivent être échappés avec un backslash. Correction : Utilisez un validateur JSON comme JSONLint avant publication.

10. Modifier d’autres scripts lors d’une édition JSON-LD

Ce que vous voyez : Un développeur ajoute JSON-LD et modifie accidentellement un script Google Analytics existant ou d’autres fonctionnalités.

Pourquoi c’est problématique : Les scripts JSON-LD doivent être autonomes. Les modifications d’autres scripts peuvent casser le tracking, les ads ou d’autres fonctionnalités.

Correction : Traitez JSON-LD comme une zone en lecture seule. Ajoutez, mais ne touchez rien d’autre. Testez toujours après déploiement que les autres scripts fonctionnent encore.

“Auparavant, les moteurs de recherche étaient surtout des index de documents. Maintenant, Google devient de plus en plus un index de ‘choses’ et de faits qui y sont associés”

— Aaron Bradley, Consultant en données structurées

Checklist avant publication

Avant de mettre votre JSON-LD en ligne :

• Syntaxe JSON validée avec JSONLint
• Types de schéma correspondant à l’intention de la page (Service pour page de service, BlogPosting pour article)
• Toutes les références @id vérifiées (@id d’Organization correct, @id de WebSite correct)
• Testé avec Google Rich Results Test
• Testé avec Schema Markup Validator
• Aucune erreur ni avertissement critique dans les validateurs
• Le contenu dans les données structurées correspond au contenu visible de la page
• URLs exactement comme les URLs canoniques (correspondance www/non-www et slash final)
• DateModified ajouté si l’article a été mis à jour
• Changelog maintenu sur quelles pages ont quel schéma
• Processus en lots : d’abord 5 pages en production, surveiller 48h, puis déployer sur plus de pages

Les données structurées ne remplacent pas la recherche de mots-clés, mais aident les moteurs de recherche à comprendre plus rapidement l’intention de la page.

Les données structurées ne sont pas un travail ponctuel, mais un système que vous mettez en place et maintenez. Commencez par les entités site-wide, ajoutez ensuite le balisage page-level selon les templates ci-dessus, validez soigneusement et surveillez vos erreurs dans Search Console.

Les sites qui font cela correctement ont une chose en commun : une séparation claire entre ce qui appartient au site-wide et ce qui appartient au page-level, avec une stratégie @id cohérente qui passe à l’échelle.

Les données structurées fonctionnent mieux en combinaison avec le SEO technique, l’optimisation de la conversion et les stratégies GEO qui garantissent que votre contenu est trouvable aussi bien dans les moteurs de recherche traditionnels que dans les systèmes IA. Si vous avez besoin d’aide pour auditer ou implémenter vos données structurées, un audit de site web peut vous donner un aperçu de votre situation actuelle.

Articles connexes :

Pour ceux qui veulent approfondir l’aspect technique du SEO :

• Données structurées pour Google : guide complet
• Combiner SEO et IA : guide pratique
• Stratégies GEO : comment l’IA trouve votre contenu
• Conseils SEO e-commerce pour Shopify
• SEO local en Belgique : checklist complète