Qu’est-ce que les données structurées (Schema.org)?

Name: Référence Numérique
Price range: $$

Vous voyez parfois des résultats Google enrichis d'étoiles, de prix, d'horaires, ou de photos. Votre concurrent en a, pas vous.

17 avril 2026 · 9 min de lecture

Vous voyez parfois des résultats Google enrichis d’étoiles, de prix, d’horaires, ou de photos. Votre concurrent en a, pas vous. Il y a de fortes chances que la différence s’appelle les données structurées.

La réponse courte : Les données structurées (structured data) sont un format standardisé qui permet de décrire le contenu d’une page web dans un langage que les moteurs de recherche interprètent sans ambiguïté. Schema.org est le vocabulaire commun utilisé pour cette description. Résultat : Google comprend mieux votre page, et peut l’afficher dans des formats enrichis (étoiles, prix, horaires, recettes, événements) qui augmentent le taux de clic.

Ce qu’il faut comprendre

Google est bon pour deviner le sujet d’une page, mais il n’est pas infaillible. Si votre page parle d’un restaurant, Google peut comprendre « c’est un restaurant ». Mais il ne saura pas avec certitude : le nom exact, l’adresse, les heures d’ouverture, la cuisine servie, la note moyenne, la fourchette de prix. Il devra deviner à partir du texte, et parfois il se trompe.

Les données structurées résolvent ce problème en fournissant ces informations directement dans le code de la page, dans un format machine : « Voici le type de contenu, voici ses propriétés, voici leurs valeurs. » Google n’a plus à deviner.

Schema.org est le standard créé en 2011 par Google, Microsoft, Yahoo et Yandex pour unifier ce vocabulaire. Il définit des centaines de types : LocalBusiness, Product, Article, Recipe, Event, FAQPage, Review, etc. Chaque type a une liste de propriétés définies : un LocalBusiness a une adresse, un téléphone, des heures d’ouverture, un secteur d’activité.

Le format technique le plus utilisé est JSON-LD, un bloc de code JavaScript inséré dans l’en-tête de la page. C’est celui que Google recommande officiellement depuis plusieurs années.

Notre position : le Schema est le levier SEO technique le plus sous-exploité de 2026. La majorité des CMS produisent un balisage minimal : Article et WebPage générés par le plugin SEO, point. Ajouter FAQPage sur les pages de service, HowTo sur les guides, BreadcrumbList partout, LocalBusiness propre sur la home, Product sur les fiches, et maintenant un balisage compatible avec les moteurs IA (llms.txt, schema enrichi pour les LLMs) : c’est un travail de quelques heures par section qui compose en visibilité sur plusieurs mois. La plupart des agences sautent cette étape parce que c’est du travail invisible : aucun client ne le voit dans son tableau de bord. C’est précisément pour ça qu’il livre un différentiel.

Sur les sites qu’on audite, il est courant de voir un site avec « Schema activé » dans Rank Math ou Yoast et rien d’autre : alors que le potentiel réel demande 6 à 10 types de schema différents implémentés à la main, par gabarit.

Concrètement, comment les utiliser

Identifiez le type Schema approprié. Pour un commerce local : LocalBusiness (ou une sous-catégorie plus précise comme Restaurant, AutoRepair, MedicalBusiness). Pour un produit : Product. Pour un article de blog : Article. Pour une page de questions fréquentes : FAQPage.
Générez le code JSON-LD. Des outils gratuits comme le Markup Helper de Google produisent le code à partir d’un formulaire simple. Aucune connaissance en programmation requise.
Insérez le bloc dans l’en-tête de votre page. Sur WordPress, un plugin SEO bien configuré gère ce travail automatiquement pour les types courants. Sur un site fait main, le code s’insère dans la section du HTML.
Validez avec le Rich Results Test. L’outil officiel de Google Rich Results Test vérifie que votre balisage est correct et indique à quels affichages enrichis votre page est admissible.

Code réel : trois schemas à implémenter en priorité

Voici le balisage qu’on déploie systématiquement sur les sites de PME au Québec. Ces blocs sont à insérer dans ou injectés via wp_head dans un plugin/child theme.

FAQPage : pour capturer des featured snippets en français

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "inLanguage": "fr-CA",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Combien coûte un audit SEO pour une PME?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Un audit SEO sérieux pour une PME démarre autour de quelques milliers de dollars selon la taille du site et la profondeur d'analyse demandée."
      }
    },
    {
      "@type": "Question",
      "name": "Combien de temps avant de voir des résultats SEO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Les corrections techniques (Core Web Vitals, indexation, redirections) bougent en quelques semaines. L'autorité de domaine se construit sur plusieurs mois."
      }
    }
  ]
}
</script>

La propriété inLanguage: "fr-CA" est sous-utilisée : elle aide Google à servir le bon résultat selon la locale du visiteur, et elle envoie un signal cohérent avec la Loi 25 et l’OQLF.

BreadcrumbList : fil d’Ariane lisible par Google

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Accueil",
      "item": "https://exemple.ca/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Services",
      "item": "https://exemple.ca/services/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Référencement naturel",
      "item": "https://exemple.ca/services/referencement-naturel/"
    }
  ]
}
</script>

Sans BreadcrumbList, le fil d’Ariane visuel sur la page n’est pas lu comme une hiérarchie par Google : c’est juste du texte.

LocalBusiness avec @id pour relier les entités

L’astuce qui change tout : utiliser @id pour lier LocalBusiness, Organization, et WebSite entre eux. Google et les LLMs comprennent alors que les schémas parlent de la même entité.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "LocalBusiness",
      "@id": "https://exemple.ca/#localbusiness",
      "name": "Nom de l'entreprise",
      "url": "https://exemple.ca/",
      "telephone": "+1-(XXX)-XXX-XXXX",
      "inLanguage": "fr-CA",
      "address": {
        "@type": "PostalAddress",
        "addressRegion": "QC",
        "addressCountry": "CA"
      },
      "areaServed": {
        "@type": "AdministrativeArea",
        "name": "Québec"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://exemple.ca/#website",
      "url": "https://exemple.ca/",
      "inLanguage": "fr-CA",
      "publisher": { "@id": "https://exemple.ca/#localbusiness" }
    }
  ]
}
</script>

Le @graph avec @id croisés est ce qui transforme un schema « valide mais isolé » en knowledge graph local utile.

Cas limites : quand le Schema valide ne suffit pas

Cas 1 : Schema valide pour Google, invisible pour les LLMs

Le Rich Results Test peut afficher « tout est en ordre » alors que les moteurs IA (Perplexity, ChatGPT search, Google AI Overviews) ne lisent pas le balisage. Raison fréquente : le contenu de la page est mal structuré (pas de

clairs, pas de réponses directes), ou le schema ne reflète pas ce qui est visible. Les LLMs croisent le schema avec le DOM rendu : si l’un contredit l’autre, ils ignorent les deux.

Cas 2 : Schemas en conflit sur la même page

On voit régulièrement deux schemas du même type sur une seule URL : un Article injecté par le thème, un autre Article injecté par le plugin SEO, parfois avec des valeurs différentes (auteur, date, image). Google choisit le plus complet et ignore le reste : mais la version qu’il choisit n’est pas toujours celle qu’on veut. Auditer le code source rendu (pas juste l’admin WordPress) est obligatoire après chaque ajout de plugin qui touche au schema.

Cas 3 : Schema injecté en JavaScript après rendu

Les solutions « no-code Schema » qui injectent le JSON-LD via JavaScript après le DOMContentLoaded posent un problème silencieux : la majorité des crawlers de LLMs (et certains crawlers SEO) ne rendent pas le JS. Le schema est invisible pour eux, même s’il s’affiche correctement dans le navigateur. Règle : Schema en JSON-LD inline dans le HTML servi côté serveur : toujours.

Spécificité Québec : le vide francophone du Schema

Sur les sites de PME au Québec, le balisage inLanguage: "fr-CA" est rare. Les outils générateurs (plugins SEO en mode automatique, builders) produisent par défaut en ou rien du tout. Résultat : un site francophone québécois envoie à Google des signaux linguistiques inconsistants entre le , le contenu, et le schema.

Trois éléments qui découlent du contexte légal et linguistique québécois :

Loi 25 et tracking analytics. Le schema LocalBusiness ne contient pas de tracking, mais sa présence change ce que Google peut afficher. Une fiche LocalBusiness propre + Consent Mode v2 propre = rich results servis même quand l’utilisateur refuse les cookies analytics.
OQLF et noms d’entreprise. Le champ name du schema doit refléter la dénomination officielle déposée : pas une traduction marketing. C’est un détail qu’aucun générateur automatique ne respecte.
Différentiation francophone. Comme la majorité des sites concurrents au Québec n’ont pas de inLanguage: "fr-CA" propre, l’effort de quelques heures pour ajouter cette propriété sur tous les schemas livre un avantage immédiat dans les SERP francophones : c’est une ligne facile à cocher dans un audit.

À éviter

Marquer du contenu qui n’apparaît pas visiblement sur la page. Google considère ça comme une tentative de manipulation et peut appliquer une action manuelle contre votre site.
Utiliser le mauvais type. Un article de blog n’est pas un produit. Un service n’est pas un lieu physique. Choisir le bon schéma est plus important que d’en ajouter partout.
Copier-coller un schéma sans le personnaliser. Les propriétés doivent refléter votre vraie entreprise. Un schéma générique avec les mêmes valeurs que tout le monde n’apporte aucun bénéfice.
Oublier les propriétés obligatoires. Chaque type Schema a des propriétés requises pour que Google le valide. Le Rich Results Test indique celles qui manquent.

Sources

Google Search Central : Introduction aux données structurées (consulté le 2026-04-11)
Google Search Central : Galerie des types de résultats enrichis (consulté le 2026-04-11)

Voir aussi

Nos services de référencement naturel : implémentation complète de Schema.org pour PME québécoises
Guide Google Business Profile 2026 : complément naturel des données structurées LocalBusiness

Vous voulez améliorer votre visibilité en ligne ?

Un audit gratuit de votre site — sans engagement, sous 48 h.

Obtenir mon audit gratuit →