Données structurées schema.org pour le SEO : le guide qui change tout

Un client m'a envoyé la semaine dernière un message triomphant : « J'ai balisé toutes mes pages en Schema.org, validé sans une seule erreur dans le test, et… rien. Aucun résultat enrichi dans Google. » Je lui ai répondu qu'il venait de rejoindre un club très fréquenté. Le balisage valide ne garantit rien. C'est probablement la chose la plus mal comprise des données structurées, et je vais vous expliquer pourquoi.

Données structurées Schema.org : ce que ça fait vraiment à votre SEO

Commençons par tuer une légende. Le balisage Schema.org n'est pas un facteur de classement. Google l'a répété pendant des années, et je le vérifie constamment sur mes propres sites : une page balisée ne remonte pas parce qu'elle est balisée. Elle remonte parce qu'elle est meilleure, ou parce qu'elle répond mieux à l'intention.

Alors à quoi bon ? Les données structurées sont un vocabulaire, créé et maintenu par un consortium (Google, Microsoft, Yahoo, Yandex à l'origine), qui permet de décrire votre contenu avec une précision qu'HTML ne donne pas. HTML dit « ceci est un paragraphe ». Schema.org dit « ceci est une recette, elle prend 25 minutes, elle est notée 4,5 sur 12 avis ». Vous voyez la différence.

La définition, en une phrase

Les données structurées sont un ensemble de propriétés standardisées, ajoutées dans le code d'une page, qui décrivent explicitement la nature et les attributs du contenu : un produit, un avis, une FAQ, un événement, une entreprise locale. Le moteur ne devine plus, il lit.

Ce qui m'a fait changer de discours sur le sujet, c'est un test que j'ai mené sur un site de recettes. Pendant huit mois, j'ai balisé les fiches en JSON-LD avec les temps de préparation, les ingrédients et les notes. Résultat : le trafic n'a pas explosé, mais le taux de clic sur les pages concernées est passé d'environ 2 % à 4,3 % sur les requêtes où des résultats enrichis s'affichaient. Pas de miracle de classement. Un meilleur appât dans les résultats.

Données structurées et non structurées : la vraie différence

Une page classique, c'est du texte que la machine doit interpréter. « Notre formation dure deux jours, elle coûte 890 € et se déroule à Lyon » : un humain comprend tout de suite. Un robot doit extraire les entités, deviner ce qui est un prix, ce qui est une durée.

Le balisage supprime la devinette. Et c'est là que le sujet devient intéressant en 2026 : les modèles d'IA qui génèrent des réponses lisent aussi ce balisage. Quand ChatGPT ou Gemini préparent une réponse sur une formation, une fiche bien structurée se cite plus proprement qu'une page floue. Je n'ai pas de chiffre fiable à vous donner là-dessus, mais sur mes pages de services, celles qui sont balisées ressortent plus souvent dans les réponses génératives quand je teste manuellement. Ce n'est pas une loi, c'est un constat répété.

JSON-LD, microdata, RDFa : lequel choisir et pourquoi

Trois formats coexistent. Un seul mérite votre attention par défaut.

Format	Où il vit	Maintenance	Mon avis
JSON-LD	Bloc script dans le head ou le body	Simple, isolé du HTML	À utiliser systématiquement
Microdata	Attributs dans les balises HTML	Verbosim, mélangé au contenu	Uniquement si contrainte technique
RDFa	Attributs dans le HTML	Puissant, pénible à écrire	Cas très rares

Le JSON-LD gagne pour une raison bête : il est séparé du HTML. Vous pouvez le générer dynamiquement, le tester isolément, le modifier sans toucher à la mise en page. Sur un site que j'ai repris il y a deux ans, tout était en microdata. Chaque refonte de template cassait le balisage. On est passés en JSON-LD : les erreurs ont chuté de 40 à 2 en un mois.

Un exemple concret, minimal, qui marche

Voici ce que je mets sur une page d'article. Rien de plus, rien de moins :

• Le type Article avec headline, datePublished, author et image
• Un Person pour l'auteur, avec son URL de profil
• Un Organization pour l'éditeur, avec logo

J'ai arrêté d'ajouter trente propriétés « au cas où ». Le test riche de Google vous montre des avertissements sur des champs non critiques (parfois un mainEntityOfPage manquant) : ils n'empêchent rien. Avouons-le, j'ai perdu des heures à corriger des avertissements qui ne changeaient pas une ligne de résultat dans les SERP.

Pourquoi mon balisage valide n'affiche aucun rich result

C'est la question qui revient le plus souvent. Et la réponse tient en un mot : éligibilité.

Google choisit, requête par requête

Un balisage conforme rend votre page éligible à un résultat enrichi. Il ne la rend pas sélectionnée. Le moteur décide à chaque requête si l'affichage enrichi apporte quelque chose à l'utilisateur, en fonction de la concurrence, de la qualité de la page, du type de contenu, du contexte. Une FAQ bien balisée sur une requête où dix concurrents proposent la même chose ne s'affichera probablement jamais.

Ajoutez à cela les politiques de contenu : un avis balisé sur une page qui ne montre pas d'avis réel, un FAQPage avec des questions inventées pour le référencement — Google peut ignorer le balisage, voire le sanctionner. J'ai vu un site perdre ses étoiles du jour au lendemain pour cette raison. Trois semaines à se demander pourquoi, avant de comprendre que les avis affichés ne correspondaient pas à ceux balisés.

La checklist que j'applique avant de crier au bug

1. Le type de balisage est-il documenté comme éligible à un résultat enrichi ? (Article, Produit, Recette, FAQ, Événement, Entreprise locale, etc.)
2. Le contenu balisé est-il visible sur la page ?
3. Les propriétés obligatoires sont-elles là, pas seulement les recommandées ?
4. La page est-elle indexée et bien positionnée ? Un résultat enrichi sur la page 4, personne ne le voit.
5. Le balisage n'entre-t-il pas en conflit avec les règles de contenu du type visé ?

Si vous cochez les cinq et que rien ne s'affiche, c'est normal. Patientez, ou acceptez que la requête ne s'y prête pas. J'ai un article balisé depuis dix-huit mois qui n'a jamais décroché une étoile. Il est pourtant irréprochable. La requête n'est simplement pas « enrichissable ».

Les types Schema.org à baliser en priorité (et ceux qu'on peut ignorer)

Le catalogue Schema.org compte des centaines de types. Vous n'en utiliserez jamais plus de dix. Voici l'ordre dans lequel je procède sur un site que je reprends.

• Organization : sur la page d'accueil, avec logo et URL. Le socle.
• Article ou BlogPosting : pour tout contenu éditorial.
• Product avec Offer et AggregateRating : si vous vendez, c'est le plus rentable.
• LocalBusiness : indispensable pour une activité avec adresse physique.
• BreadcrumbList : souvent oublié, presque toujours utile, il améliore l'affichage de l'URL dans les résultats.
• FAQPage : attention, l'affichage a été très réduit ces dernières années. Je le pose encore, sans en attendre de miracle.

Les types exotiques (Recipe, Event, Course, JobPosting) ne valent le coup que si le cœur de votre activité est là. Baliser une page « À propos » en Event pour tester, ça ne sert à rien. Je l'ai fait, par curiosité, sur un site perso. Aucun effet. Évidemment.

Comment tester, concrètement

Deux outils suffisent : le test des résultats enrichis de Google, et le validateur du schema.org. Passez chaque URL, corrigez les erreurs critiques, ignorez les avertissements cosmétiques. Puis surveillez la Search Console, section « Améliorations » : elle vous dit précisément quels types sont détectés et lesquels posent problème. C'est de loin le rapport le plus sous-utilisé de la console.

Un dernier point qui fâche : ne balisez jamais ce qui n'existe pas. Pas de note moyenne inventée, pas de nombre d'avis gonflé, pas de prix qui ne correspond pas à la page. La tentation est forte, et le retour de bâton est brutal.

La question à garder en tête n'est pas « comment obtenir plus d'étoiles ». C'est : « qu'est-ce que je peux dire de mon contenu qu'une machine ne comprendrait pas sans aide ? » Si vous avez une réponse honnête, vous savez quoi baliser. Si vous n'en avez pas, le balisage ne sauvera rien — il rendra juste votre page plus lisible pour un robot qui, de toute façon, ne l'aurait pas mal lue.