Les données structurées :ce que les moteurs et l'IA en comprennent

Ce qu'est schema.org et ce qu'est le JSON-LD

schema.org est un vocabulaire commun pour décrire des choses sur le web. Il fixe des types comme Organization, Service et Question. À chaque type correspond une série de propriétés comme name, url et address. Ce n'est pas un produit de Google. Les grands moteurs de recherche ont mis ce vocabulaire en place ensemble et il est ouvert. C'est pourquoi le même balisage fonctionne aussi pour d'autres acteurs qui lisent votre page.

Le JSON-LD est la notation dans laquelle vous écrivez ce vocabulaire. Un bloc JSON dans un élément script avec type="application/ld+json", séparé de votre HTML visible. Cette séparation est l'avantage pratique : vous l'ajoutez, le modifiez ou le retirez sans toucher une seule ligne de votre design. Il existe deux notations plus anciennes, les microdonnées et RDFa, qui tissent des attributs dans votre HTML. Les deux fonctionnent encore. Pour du travail neuf vous prenez le JSON-LD, car c'est ce que Google recommande et c'est la seule forme que vous gérez à un seul endroit.

Une règle vaut toujours. Ce que vous balisez doit être visible sur la page. Google exige dans ses consignes pour les données structurées que le balisage corresponde à ce que le visiteur voit. Un bloc FAQ avec cinq questions qui n'existent que dans le JSON-LD est une infraction et pas une astuce.

Pourquoi cela pèse plus lourd en GEO qu'en SEO

Pour les résultats de recherche classiques le gain est limité et facile à délimiter. Google peut montrer un élément supplémentaire : un fil d'Ariane à la place d'une URL nue, une date pour un événement, une information de prix pour un produit. Les données structurées ne sont pas un facteur de positionnement. Google le dit publiquement. Une page sans une seule ligne de schéma peut occuper la première position sans le moindre souci.

Avec un moteur de réponse IA le calcul est différent. Ce système doit déterminer en peu de temps de quoi parle votre page, de quelle organisation elle vient, qui l'a écrite et s'il s'y trouve un passage qui répond à la question posée. Du texte courant il doit tout déduire. Dans le JSON-LD c'est simplement écrit. Le gain est exactement là : vous supprimez l'étape où cela dérape.

Dans notre propre formule de score GEO les données structurées pèsent 0,25. C'est le plus lourd de six composants. C'est notre opérationnalisation et pas une norme du secteur. Nous lui donnons ce poids parce que c'est le seul facteur qui se trouve entièrement à l'intérieur de vos propres murs et que vous réparez en une après-midi.

Soyons honnêtes sur ce que nous ne savons pas. Personne ne publie ce que le schéma rapporte exactement en citations. Ce qui est établi, c'est qu'une page sans schéma oblige le système à deviner. Une supposition tombe parfois à faux.

Les types qui comptent pour une PME

À côté de cela il y a SpeakableSpecification, un petit composant avec lequel vous indiquez quel morceau de la page se prête à être lu à voix haute ou repris. Placez-le sur votre bloc de réponse en haut. Cela coûte deux lignes.

Choisissez-vous Organization ou LocalBusiness ? Prenez LocalBusiness si des clients viennent à votre adresse ou si vous desservez une zone de travail délimitée. Prenez Organization dans tous les autres cas. LocalBusiness est un sous-type d'Organization, donc tout ce qui entre dans l'un entre aussi dans l'autre. Ne les posez jamais tous les deux comme nœuds distincts sur la même page, car alors deux entreprises figurent sur votre site.

Des exemples prêts à copier

Remplacez partout uwdomein.be et les données d'exemple. Le reste peut rester tel quel.

Votre organisation, mise en place une fois et répétée sur chaque page :

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://uwdomein.be/#organization",
  "name": "Voorbeeld bv",
  "url": "https://uwdomein.be/",
  "logo": "https://uwdomein.be/assets/logo.png",
  "email": "info@uwdomein.be",
  "telephone": "+32 3 123 45 67",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Voorbeeldstraat 1",
    "postalCode": "2000",
    "addressLocality": "Antwerpen",
    "addressCountry": "BE"
  },
  "sameAs": [
    "https://www.linkedin.com/company/voorbeeld-bv"
  ]
}

Le champ sameAs est votre lien lisible par la machine vers la même entreprise ailleurs. C'est le pont vers le chapitre 10.

Une page de service :

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Onderhoud van verwarmingsinstallaties",
  "serviceType": "Onderhoud en keuring",
  "url": "https://uwdomein.be/onderhoud.html",
  "provider": { "@id": "https://uwdomein.be/#organization" },
  "areaServed": [
    { "@type": "Country", "name": "Belgium" }
  ],
  "description": "Eén zin die letterlijk zegt wat de dienst is en voor wie."
}

Une question avec sa réponse :

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "inLanguage": "nl-BE",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Hoe vaak moet een gasketel onderhouden worden?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Schrijf hier hetzelfde antwoord dat zichtbaar op de pagina staat, in twee tot vier zinnen die los van de rest leesbaar zijn."
      }
    }
  ]
}

Attention avec FAQPage. Google a limité en 2023 les résultats FAQ visibles aux sites publics et de santé. Votre PME n'obtient donc plus de bloc déroulant dans les résultats de recherche grâce à cela. La mise à jour majeure de mars 2026 a encore réduit les résultats enrichis pour FAQPage, Review et HowTo sur les pages qui ne sont pas le contenu principal. Cela reste néanmoins la façon la plus claire de relier une question à une réponse pour tout système qui traite votre texte et Gemini utilise le schéma dans AI Mode précisément pour vérifier les affirmations et évaluer la fiabilité d'une source. Toute la valeur pour le GEO se trouve là.

Un article avec un auteur et un fil d'Ariane, ensemble dans un seul bloc :

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://uwdomein.be/blog/artikel.html#article",
      "headline": "De titel van het artikel, kort gehouden",
      "datePublished": "2026-08-03",
      "dateModified": "2026-08-03",
      "inLanguage": "nl-BE",
      "author": {
        "@type": "Person",
        "name": "Voornaam Achternaam",
        "url": "https://uwdomein.be/over-ons.html"
      },
      "publisher": { "@id": "https://uwdomein.be/#organization" },
      "speakable": {
        "@type": "SpeakableSpecification",
        "cssSelector": [".antwoordblok"]
      }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://uwdomein.be/" },
        { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://uwdomein.be/blog/" }
      ]
    }
  ]
}

Le piège du @graph sur lequel les scanners butent

Le dernier exemple utilise @graph. Vous mettez ainsi plusieurs entités dans un seul bloc sous un seul @context et vous donnez à chaque entité un @id pour qu'elles puissent se renvoyer l'une à l'autre. C'est la façon propre et Google la lit sans le moindre problème.

Pourtant beaucoup de choses ratent ici, pour trois raisons.

Votre scanner ne voit rien. Beaucoup de contrôleurs SEO ne lisent que la clé @type en haut du bloc. Dans un @graph cette clé ne s'y trouve pas, car les types sont un niveau plus bas. Le rapport annonce alors que vous n'avez pas de données structurées alors que tout est en place. Ce qui se passe ensuite est prévisible : quelqu'un s'effraie de la coche rouge et colle un deuxième bloc à côté. Il y a maintenant deux organisations sur votre page et Google peut choisir. Contrôlez donc toujours dans les validateurs officiels et pas dans le scanner. S'ils sont verts, c'est le scanner qui se trompe et vous ne changez rien.

Votre @id diffère selon la page. Le renvoi { "@id": "..." } ne fonctionne que si la chaîne de caractères est exactement la même partout. Une fois avec www devant et une fois sans donne deux entreprises au lieu d'une. Choisissez une écriture comme https://uwdomein.be/#organization et utilisez-la sur chaque page dans chaque langue.

Vous renvoyez à quelque chose qui n'est pas là. Un provider qui pointe vers #organization ne fonctionne que si ce nœud est présent sur cette même page. Mettez donc le nœud de l'organisation dans chaque @graph, y compris sur la page de service.

Notre règle de travail est simple : par page et par langue exactement un bloc JSON-LD avec un @graph dedans, dans lequel le nœud de l'organisation est toujours présent. Pour un site multilingue cela veut dire quatre blocs dont seuls les champs de texte diffèrent. Les URL et les valeurs @id restent identiques.

La règle qui peut sauver votre entreprise

N'inventez jamais de balisage Review ou AggregateRating pour des avis qui n'existent pas. C'est le seul sujet de tout ce guide sur lequel Google peut vous sanctionner activement.

Ce qui se passe : quelqu'un met 4,8 étoiles sur 137 avis dans le JSON-LD parce que cela fait joli dans le résultat de recherche. Il n'y a pas 137 avis. Google appelle cela du spam dans les données structurées et les conséquences sont une action manuelle, la perte de tous les résultats enrichis et du travail pour s'en défaire. De plus vous ne pouvez pas montrer des étoiles que vous écrivez sur vous-même. Les avis que le propriétaire dépose lui-même ne sont de toute façon pas éligibles à l'affichage.

Il existe un autre malentendu, plus fréquent encore que l'invention elle-même. Même avec de vrais avis, votre propre balisage ne vous rapporte aucune étoile. Depuis 2019, Google n'affiche plus d'extrait avec étoiles lorsque la partie évaluée gère elle-même les avis, et cela vaut pour LocalBusiness et pour tout autre type Organization. Peu importe que vous saisissiez les textes vous-même ou que vous utilisiez un widget qui les récupère sur un site d'avis. Pour Product, c'est différent : les avis d'un produit que vous vendez peuvent être balisés.

Il y a une deuxième raison, indépendante de Google. Les avis inventés relèvent des règles sur les pratiques commerciales déloyales. Ce n'est plus un problème de SEO.

Ce qui est permis et ce qui fonctionne : récolter de vrais avis sur votre fiche d'établissement Google. Google les montre lui-même, sans que vous ayez besoin d'une seule ligne de schéma. Voir le chapitre 10.

Comment vérifier que c'est correct

Quatre contrôles gratuits, dans cet ordre.

Les deux validateurs diffèrent et cela déroute les gens. Le Rich Results Test ne montre que ce que Google peut utiliser visuellement. Votre bloc Service ou Organization n'y figure donc pas alors qu'il est parfaitement en ordre. Le Schema Markup Validator montre tout. Utilisez le Schema Markup Validator pour la question de savoir si votre balisage est correct et le Rich Results Test pour la question de savoir si Google en fait quelque chose de visible.

Ce que vous pouvez faire vous-même et ce que vous ne pouvez pas

À faire vous-même, sans développeur :

• Reprendre le bloc de l'organisation ci-dessus, le remplir et le placer dans le <head> de chaque page. C'est une demi-heure de travail pour un site de vingt pages.
• Compléter sameAs avec vos profils ailleurs. Uniquement des profils que vous entretenez vraiment.
• Créer un bloc Service par page de service. Le modèle est chaque fois le même et seuls le nom, l'URL et la description changent.
• Ajouter FAQPage sur les pages où les questions figurent aussi visiblement.
• Faire tourner les deux validateurs et lire le résultat.

Ce pour quoi vous avez besoin d'aide :

• Une boutique en ligne avec des centaines de produits, où Product et Offer doivent être générés à partir de vos données de stock.
• Un plugin qui émet lui-même un @graph qui entre en conflit avec ce que vous ajoutez. Il faut alors démêler ce qui est déjà là avant d'ajouter quoi que ce soit.
• Les quatre variantes linguistiques du même bloc, où seul le texte peut différer et où les identifiants doivent rester identiques.
• Un site entièrement construit en JavaScript, où le bloc de schéma n'apparaît qu'après le chargement. Tous les systèmes qui vont chercher votre page n'exécutent pas JavaScript.

Notre ordre : d'abord Organization sur tout, puis Service sur les pages de service, puis FAQPage et Article là où cela s'applique. Le premier point apporte la plus grande partie du gain et il coûte le moins de temps.

Vous préférez ne pas le faire vous-même : SEMANU réalise l'audit SEO et GEO complet pour 1 450 euros, rapport et séance de travail compris. Le détail figure sur la page du guide.