Données structurées (schema.org) : pourquoi l'IA cite certains sites et pas d'autres

Ce que sont les données structurées

Une machine qui lit ton site voit du texte, mais ne comprend pas toujours ce qu'est chaque chose. Les données structurées lui mettent des étiquettes : ceci est un produit, ceci est son prix, ceci est une question fréquente, voici l'auteur. Le vocabulaire standard s'appelle schema.org et il est utilisé aussi bien par les moteurs de recherche que par les modèles d'IA. Ce guide explique pourquoi elles aident à te faire citer, quels types mettre sur chaque page avec des exemples complets, les erreurs qui coûtent de la crédibilité et comment vérifier qu'elles sont correctes.

JSON-LD, la méthode facile

Il y a plusieurs façons d'écrire du schema, mais celle qui est recommandée est JSON-LD : un bloc de script au format JSON que tu places dans l'en-tête ou le corps de la page. Ça ne change rien à ce que voit l'utilisateur et ça reste séparé du HTML visible, donc c'est facile à générer et à relire. Si tu utilises Cursor, Bolt ou Lovable, demander à ton IA de générer le JSON-LD d'une page précise, c'est l'affaire d'un prompt. L'alternative, les microdonnées incrustées dans les balises HTML, marche aussi mais est plus difficile à maintenir.

Pourquoi ça aide à te faire citer

Quand un modèle doit résumer ta page, le schema réduit l'ambiguïté. Au lieu de déduire qu'un nombre est un prix, il le sait. Au lieu de deviner qui a écrit l'article, il le lit. Au lieu d'inférer que « Scanaris » est une entreprise et pas une personne, c'est déclaré. Moins deviner signifie plus de confiance, et plus de confiance signifie plus de chances d'être utilisé comme source. En plus, le schema relie ton site au reste d'internet : le champ sameAs pointe vers tes profils et le modèle comprend que tout parle de la même entité.

Quels types ajouter et avec quelles propriétés

Organization sur l'accueil : nom, logo, URL, description en une phrase et sameAs avec tes profils publics.
SoftwareApplication (ou Product) sur la page produit ou tarifs : nom, description, catégorie, système d'exploitation ou plateforme, et offers avec prix et devise.
FAQPage là où il y a de vraies questions-réponses visibles.
Article ou BlogPosting sur les articles, avec auteur, date de publication et de modification.
BreadcrumbList pour donner le contexte de l'endroit où chaque page s'insère.
WebSite sur l'accueil, avec le nom du site, ce qui l'aide à apparaître correctement dans les résultats.

N'ajoute pas tout pour le plaisir. Balise seulement ce qui est vraiment sur la page.

Un exemple complet pour une appli

Voici à quoi ressemble le bloc de l'accueil d'un produit logiciel, avec l'organisation et l'application dans un même graphe :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://tondomaine.com/#org",
      "name": "Ton Produit",
      "url": "https://tondomaine.com",
      "logo": "https://tondomaine.com/logo.png",
      "description": "Ton Produit est un [ce que c'est] pour [qui] qui [ce que ça permet].",
      "sameAs": [
        "https://github.com/tonproduit",
        "https://www.linkedin.com/company/tonproduit",
        "https://x.com/tonproduit"
      ]
    },
    {
      "@type": "SoftwareApplication",
      "name": "Ton Produit",
      "applicationCategory": "DeveloperApplication",
      "operatingSystem": "Web",
      "url": "https://tondomaine.com",
      "description": "Ton Produit est un [ce que c'est] pour [qui] qui [ce que ça permet].",
      "publisher": { "@id": "https://tondomaine.com/#org" },
      "offers": {
        "@type": "Offer",
        "price": "24",
        "priceCurrency": "EUR",
        "url": "https://tondomaine.com/pricing"
      }
    }
  ]
}
</script>

Remarque que la description est la même phrase dans les deux blocs, et qu'elle devrait être la même que celle qui apparaît sur l'accueil, dans la meta description et dans llms.txt. Cette répétition exacte, c'est ce que les modèles finissent par citer.

Et un pour les questions fréquentes

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Ton Produit modifie-t-il mon site ?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Non. Il fait des vérifications en lecture seule sur des informations publiques."
      }
    }
  ]
}
</script>

Chaque question du JSON doit exister, avec le même texte, dans la partie visible de la page.

Les erreurs les plus courantes

Baliser ce qui ne se voit pas. Des questions fréquentes qui n'apparaissent pas sur la page, des avis inventés, un prix dans le JSON différent de celui de la page. Ça coûte de la crédibilité et peut te valoir une action manuelle de Google.
Des données périmées. Tu changes le prix sur la page et tu oublies le schema. Génère le JSON-LD depuis la même source de données que la page, pas à la main.
Un nom incohérent. « Ton Produit » sur l'accueil, « TonProduit » dans le schema, « ton-produit » sur les profils. Choisis une graphie et utilise-la partout.
Le mauvais type. Un Product physique pour un service web, ou un Article sur une page de tarifs.
Un JSON invalide. Une virgule de trop et le bloc entier est ignoré en silence.

Où le mettre selon ton framework

En Next.js, un élément script avec type="application/ld+json" dans le layout ou la page, avec le JSON sérialisé depuis un objet. En Nuxt, avec useHead et un script du même type. Dans une SPA Vite, dans index.html si le bloc est statique, ou injecté au prerender s'il varie par page. L'important, c'est qu'il arrive dans le HTML initial : un JSON-LD qui n'existe qu'après l'exécution de JavaScript n'est pas lu par les bots qui ne rendent pas la page.

Comment vérifier que c'est correct

Demande ta page avec curl et cherche le bloc :

curl -s https://tondomaine.com/ | grep -o 'application/ld+json' | wc -l

Si ça donne zéro, il n'arrive pas dans le HTML. Ensuite, valide le contenu avec l'outil de résultats enrichis de Google ou avec le validateur de schema.org, qui te signalent les erreurs de syntaxe et les propriétés inconnues. Et relis-le toi-même : dit-il la même chose que la page ? Sinon, l'un des deux ment.

Scanaris vérifie ton schema

Le pilier de visibilité IA de Scanaris détecte si tu as des données structurées, de quel type, si elles arrivent dans le HTML sans JavaScript et si elles ont du sens pour la page, et te donne un fix prompt avec le JSON-LD suggéré à coller dans ton IA. C'est une vérification en lecture seule sur le HTML public de ton site. Ça fait partie du guide de l'AEO et de la revue de SEO et AEO sur la même page.

Questions fréquentes

Google pénalise-t-il le schema incorrect ?

Le schema avec des erreurs de syntaxe est simplement ignoré. Le schema trompeur (baliser des avis ou des questions qui n'existent pas) peut recevoir une action manuelle qui te retire les résultats enrichis. Balise seulement le visible.

JSON-LD ou microdonnées ?

JSON-LD. C'est ce que recommandent Google et schema.org, ça se génère depuis des données sans toucher au HTML visible et c'est beaucoup plus facile à maintenir.

Faut-il en mettre sur toutes les pages ?

Sur les pages publiques que tu veux faire comprendre : accueil, produit, tarifs, blog, FAQ. Le tableau de bord privé n'en a pas besoin parce que personne d'extérieur ne le lit.