Données structurées schema.org pour débutants : le guide simple

Un client m'appelle un jour, paniqué : ses produits n'apparaissent plus avec leurs petites étoiles dans Google. "J'ai rien touché", jure-t-il. J'ouvre son site. Le balisage est là, mais une accolade mal fermée a cassé tout le bloc. Un caractère. Une apostrophe typographique collée dans une valeur texte et c'est l'ensemble du schema.org qui tombe par terre.

C'est ça, les données structurées. Un langage invisible, un peu austère, mais qui décide si votre page raconte une histoire claire à Google ou si elle laisse la machine deviner. Et devinez quoi ? La machine devine mal.

Données structurées schema.org : ce que c'est vraiment, sans jargon

Imaginez que vous décriviez votre produit à quelqu'un au téléphone. Vous dites "chemise bleue, taille M, 39 euros, en stock". Vous ne dites pas "objet textile à manches, coloris 0042, disponible". Pourtant, c'est exactement ce que fait une page web sans balisage : elle livre le contenu brut et laisse Google interpréter.

Les données structurées, c'est le mode d'emploi que vous glissez dans le code. Vous dites explicitement : "ceci est un prix", "ceci est une note moyenne", "ceci est une question". Google n'a plus à supposer. Il lit.

Une définition qu'on peut retenir

Schema.org est un vocabulaire partagé, né d'un accord entre les grands moteurs de recherche, qui liste des types (Product, Article, Recipe, LocalBusiness…) et des propriétés pour chaque type (name, price, author, datePublished…). Vous écrivez votre contenu avec ces étiquettes. Google les reconnaît parce qu'elles sont standardisées, pas inventées par vous.

Le point que beaucoup ratent : schema.org ne change rien à ce que voit votre visiteur. Le balisage est invisible à l'écran. Il ne sert qu'aux machines. Si vous le supprimez, votre page reste identique pour un humain — mais Google perd son GPS.

Données structurées et non structurées : où est la frontière ?

Vous croisez souvent cette opposition. Elle est mal comprise parce qu'on mélange deux débats.

Type de données	Ce que c'est	Exemple concret
Structurées (au sens base de données)	Information rangée dans des colonnes, interrogeable	Un tableur de contacts avec nom, email, date
Structurées (au sens SEO)	Balisage schema.org ajouté au HTML	Un bloc JSON-LD qui décrit une recette
Non structurées	Du texte libre, sans étiquette	Un paragraphe d'article, un avis client rédigé

Ne confondez pas les deux premières lignes. Un site peut stocker ses fiches produits dans une base parfaitement structurée côté serveur et n'afficher aucune donnée structurée côté HTML. C'est d'ailleurs le cas le plus fréquent chez les débutants : la donnée existe, elle n'est juste pas déclarée à Google.

Comment ça marche concrètement : le JSON-LD en pratique

Trois formats existent pour écrire du balisage. Microdata, RDFa, et JSON-LD. En 2026, si vous débutez, vous utilisez JSON-LD. Pas de débat. Google le recommande, il vit dans un seul bloc isolé du reste du HTML, et vous pouvez le générer ou le modifier sans toucher à votre mise en page.

Un exemple copiable, tout de suite

Voici une fiche produit minimale et valide. Vous la collez dans le <head> de votre page, vous remplacez les valeurs, point.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Chemise en lin bleue",
  "image": "https://exemple.fr/chemise.jpg",
  "description": "Chemise en lin, coupe droite, coloris bleu.",
  "sku": "CH-LIN-004",
  "offers": {
    "@type": "Offer",
    "price": "39.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Trois choses à voir dans ce bloc. Le @context pointe toujours vers schema.org. Le @type déclare ce que la page décrit. Et les propriétés à l'intérieur (offers, price, availability) suivent la grammaire du type choisi — vous ne pouvez pas inventer "prix" à la place de "price".

Quels types viser en premier

Ne cherchez pas à tout baliser d'un coup. C'est l'erreur que j'ai faite au début : j'ai voulu couvrir Product, FAQ, BreadcrumbList et Organization sur les mêmes pages, et j'ai produit un bloc de 200 lignes impossible à maintenir. Résultat, deux propriétés se contredisaient et tout était invalide.

Commencez par ce qui touche votre modèle économique :

• Article — pour tout contenu éditorial. author et datePublished sont vos amis.
• FAQPage — les questions/réponses. Grande visibilité quand c'est pertinent.
• Product — prix, disponibilité, avis. Le plus rentable en e-commerce.
• BreadcrumbList — le fil d'Ariane. Simple et rarement raté.
• LocalBusiness — pour les commerces physiques, avec adresse et horaires.

Et voilà, avec cinq types vous couvrez l'immense majorité des besoins éditoriaux.

Pourquoi Google s'en sert, et ce que vous y gagnez

La vraie raison n'est pas la bienveillance. Google veut des pages qu'il peut résumer sans se tromper, parce qu'il affiche de plus en plus de réponses directement dans la page de résultats. Un contenu balisé est un contenu qu'il peut découper proprement — prix, note, étapes, avis. Un contenu non balisé, il doit le lire en entier et espérer comprendre.

Le bénéfice que vous voyez

Des résultats enrichis. Étoiles de notation, encadré FAQ dépliable, fourchette de prix, temps de préparation d'une recette. Sur un site de location de matériel que j'ai accompagné, l'ajout du balisage Product et Review s'est traduit par un taux de clic qui est passé de 2,9% à 3,8% en six semaines sur les mêmes positions. Même place dans les résultats, plus de clics. Nuance importante : le balisage n'a pas amélioré le classement lui-même. Il a amélioré l'apparence, donc le clic. Ce sont deux leviers distincts.

Le bénéfice que vous ne voyez pas

Pensez aux assistants et aux moteurs qui répondent en langage naturel. Ils puisent dans du contenu structuré pour construire leurs réponses. Une question sur un produit obtient une citation fiable quand le prix et la disponibilité sont lisibles par la machine. Si votre concurrent a balisé sa fiche et pas vous, c'est lui qui est cité. Vous existez toujours, vous n'êtes simplement pas repris.

Les erreurs que je vois le plus souvent (et le vrai risque)

Le balisage a mauvaise réputation pour une raison précise : les gens copient des blocs trouvés en ligne sans comprendre, puis s'étonnent que ça ne fonctionne pas. Voyons les pièges réels.

Le balisage trompeur, le seul vrai danger

Il n'y a aucune pénalité à ne pas baliser. Zéro. Votre site se classe exactement pareil. En revanche, déclarer une note moyenne de 4,9 alors que vous avez trois avis, ou afficher un prix qui ne correspond pas à la page, c'est du contenu trompeur. Google le sanctionne — retrait des résultats enrichis sur le site, et dans les cas graves, action manuelle. Le balisage doit refléter ce que le visiteur voit. Pas ce que vous aimeriez montrer.

Quatre erreurs techniques qui m'ont coûté du temps

• Une virgule finale après la dernière propriété d'un objet JSON. JSON n'accepte pas les virgules en trop, contrairement à JavaScript.
• Des guillemets droits au lieu de guillemets typographiques — ou l'inverse — selon l'éditeur qui reformate votre code.
• Le bloc JSON-LD placé dans un template que le CMS échappe silencieusement en texte affiché.
• Plusieurs blocs qui décrivent la même entité avec des valeurs différentes.

Le troisième m'a fait perdre une après-midi entière. Le bloc apparaissait propre dans le code source, mais le CMS le transformait en texte littéral à l'affichage. Google voyait du charabia.

Comment tester avant de mettre en ligne

Ne déployez jamais à l'aveugle. Trois outils, dans cet ordre :

1. Le Rich Results Test de Google — il vous dit si votre type est éligible aux résultats enrichis, et il montre les erreurs et avertissements.
2. Le validateur schema.org — plus permissif, utile pour vérifier la grammaire du vocabulaire.
3. La Search Console, section Améliorations — elle remonte les problèmes détectés sur vos pages déjà indexées, y compris ceux qui apparaissent après une modification du modèle.

Si vous ne retenez qu'un réflexe de tout cet article : testez. Le temps gagné à sauter cette étape se paie toujours plus tard, en heures de débogage sur des pages dont vous ne savez plus quand elles ont changé.

Et dans un cours de SNT en seconde, on parle de la même chose ?

Oui, mais dans un sens légèrement différent. Le programme aborde les données structurées comme un concept informatique : une information rangée dans des champs identifiés, par opposition au texte libre. Le balisage schema.org est une application concrète de cette idée, appliquée au web. La logique est la même — nommer les champs pour que la machine les traite sans ambiguïté.

Par où commencer demain matin

Choisissez une page. Une seule. La plus stratégique pour vous : votre fiche produit phare, votre article le plus lu, votre page contact si vous êtes un commerce local. Écrivez son bloc JSON-LD à la main, collez-le, testez-le. Vous aurez compris en une heure ce que des articles entiers n'expliquent pas.

Ensuite, et seulement ensuite, industrialisez via votre CMS ou un plugin. Parce qu'un balisage que vous ne comprenez pas est un balisage que vous ne saurez pas réparer le jour où il casse. Et il cassera. C'est toujours une accolade.

Ce qui me frappe, après des années à manipuler ces blocs, c'est qu'on les présente souvent comme une astuce SEO. Je crois que c'est l'inverse. C'est une clarification. Vous passez d'une page qui marmonne à une page qui parle distinctement à une machine. Que Google vous récompense ou non, cette clarté vous appartient — et elle servira à chaque nouvel outil qui lira votre site, y compris ceux qui n'existent pas encore aujourd'hui.