Il y a une question qu'on me pose à chaque audit, sans exception, et toujours sur le même ton mi-sérieux mi-résigné : « Le schema markup, ça sert vraiment à quelque chose ou c'est encore un truc de geeks ? » La dernière fois, c'était un client qui vend des pièces auto en ligne. Il avait collé du JSON-LD partout sur son site six mois plus tôt, sans rien comprendre, et son trafic n'avait pas bougé d'un iota. Forcément, il était sceptique.
Et il avait raison de l'être, en partie. Parce que le schema markup, mal compris, mal posé, ne sert strictement à rien. Mais bien utilisé, c'est l'une des rares choses en SEO où l'on contrôle encore quelque chose que Google ne peut pas deviner tout seul. Je vais vous expliquer pourquoi, et surtout comment, sans vous vendre la lune.
Points clés à retenir
- Le schema markup est un vocabulaire (schema.org) qui décrit le sens de votre contenu à Google et aux IA, pas son apparence.
- Le format JSON-LD est celui que Google recommande et de loin le plus simple à maintenir.
- Baliser ne fait pas monter dans les résultats. Ça peut améliorer l'affichage enrichi, et donc le taux de clic.
- Ne déclarez que ce qui existe réellement sur la page. Les données inventées se retournent contre vous.
- Un schema markup n'a rien à voir avec un schéma de base de données, malgré la confusion fréquente.
Le schema markup, c'est quoi exactement (et pourquoi Google en a besoin)
Quand Google lit votre page, il voit du texte. Il ne « sait » pas que le mot « Bordeaux » désigne ici une ville, là un vin, ailleurs un prénom. Le schema markup comble ce trou : c'est un code standardisé, basé sur le vocabulaire de schema.org, qui indique la nature de chaque élément. Ceci est un article, ceci est son auteur, ceci est une note de 4,5 sur 5, ceci est une fourchette de prix.
Vous pouvez le poser de plusieurs façons. La plus courante aujourd'hui, et celle que je recommande sans hésiter, c'est le JSON-LD : un bloc de code que vous collez dans le <head> ou le <body> de votre page, complètement séparé du HTML visible.
Les formats d'implémentation, et celui qu'il faut choisir
Trois formats existent réellement :
- JSON-LD — un script JSON autonome. Google le recommande explicitement. Il ne touche pas à votre affichage, donc si vous le cassez, la page reste lisible.
- Microdata — des attributs glissés dans les balises HTML existantes. Plus ancien, plus intrusif.
- RDFa — le même principe que microdata, avec une syntaxe différente. On le croise encore sur de vieux sites.
J'ai fait l'erreur, sur mon premier site, de tout baliser en microdata. Résultat : le jour où j'ai voulu refondre mon template, j'ai dû repasser sur 60 pages à la main. Six heures perdues. Avec du JSON-LD, j'aurais modifié un fichier.
À quoi ressemble du JSON-LD concret
Un exemple d'article, volontairement simple :
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Comprendre le schema markup",
"author": {
"@type": "Person",
"name": "Prénom Nom"
},
"datePublished": "2026-02-14"
}Vous voyez les trois propriétés qui reviennent partout : @context (le vocabulaire utilisé), @type (la nature de l'objet décrit), et les propriétés qui le décrivent. La propriété @id sert à donner un identifiant unique à un élément pour pouvoir le référencer ailleurs, par exemple relier un article à son auteur via mainEntity sur une page de type Question/Réponse.
Ce n'est pas de la magie. C'est de la description.
Schéma de base de données ou schema markup : ne confondez pas
C'est une confusion que je vois revenir sans arrêt, et elle mérite qu'on s'y arrête, parce qu'un lecteur qui cherche « schéma de base de données » tombe régulièrement sur des articles de SEO et repart plus perdu qu'avant.
Qu'est-ce qu'un schéma de base de données et comment est-il structuré ?
Un schéma de base de données, c'est la structure d'une base de données décrite dans un langage formel, généralement pris en charge par un système de gestion de base de données relationnelle (SGBDR). Le terme « schéma » renvoie à l'organisation des données comme plan directeur : il indique comment la base est construite, découpée en tables dans le cas d'une base relationnelle.
Sa définition formelle est un ensemble de formules, appelées contraintes d'intégrité, imposées à la base. Ces contraintes assurent la compatibilité entre les différentes parties du schéma, et toutes s'expriment dans le même langage. Le schéma décrit ainsi comment les entités du monde réel sont modélisées dans la base.
Autrement dit : d'un côté, on organise des tables, des colonnes et des relations internes à une base de données. De l'autre, on décrit le contenu d'une page web à un moteur de recherche.
Les deux n'ont rigoureusement rien à voir. Le seul point commun est le mot « schéma ». Si vous cherchiez des informations sur les bases relationnelles, vous êtes au mauvais endroit, et inversement.
Les données structurées qui changent vraiment quelque chose
Sur les dizaines de types disponibles, une poignée mérite votre attention immédiate. Voici ce que je pose en priorité quand j'audite un site, et pourquoi.
| Type | À quoi ça sert | Effet visible typique |
|---|---|---|
| Article | Décrire un contenu éditorial, son auteur, sa date | Meilleure compréhension par les fils d'actualité |
| Organization | Identifier l'entreprise, son logo, ses contacts | Logo et infos de marque dans les résultats |
| Product | Décrire un produit, son prix, sa disponibilité | Prix et stock visibles dans la fiche |
| FAQPage | Marquer une série de questions/réponses | Questions dépliables dans la page de résultats |
| LocalBusiness | Signaler une adresse, des horaires, un téléphone | Encadré local enrichi |
Le Product est celui qui rapporte le plus quand on vend en ligne, parce qu'il touche directement à la décision d'achat. Le FAQPage est le plus facile à mettre en place et le plus rentable en volume de clics, à condition de ne pas tricher.
Attention, un point que personne ne répète assez : Google n'est jamais obligé d'afficher ces enrichissements. Il décide requête par requête, algorithme par algorithme. Vous n'achetez pas un affichage, vous augmentez vos chances d'en obtenir un.
Vérifier et déboguer : la partie que tout le monde saute
Poser du JSON-LD sans le vérifier, c'est comme envoyer un colis sans adresse en espérant que le facteur devine. Deux outils font le job, et ils sont gratuits.
- Le Rich Results Test de Google, pour savoir si votre balisage donne droit à un résultat enrichi.
- Le validateur de balisage schema.org, plus large, qui vérifie la conformité au vocabulaire même quand Google ne propose rien.
- La Search Console, onglet « Améliorations », qui remonte les erreurs sur l'ensemble du site, pas page par page.
La première fois que j'ai lancé un site entier dans la Search Console, j'ai découvert que 40 % de mes pages produit avaient un balisage incomplet. Une propriété obligatoire manquait, systématiquement, à cause d'un copier-coller malheureux. Je ne l'aurais jamais vu autrement.
Franchement, si vous ne retenez qu'une seule habitude de cet article, prenez celle-là : validez après chaque déploiement.
Trois erreurs que je vois systématiquement (et que j'ai commises)
La plus fréquente, et de loin : déclarer ce qui n'existe pas. Une note de 5 étoiles sur une page qui n'affiche aucun avis. Un prix qui ne correspond pas au produit. Google le détecte, et ce n'est pas un avertissement gentil.
La deuxième, c'est de croire que le balisage compense un mauvais contenu. Il ne le fera jamais. Si la page ne répond pas à l'intention de recherche, aucune donnée structurée ne la sauvera.
Et la troisième, plus discrète : baliser la même information à plusieurs endroits avec des valeurs différentes. Deux prix contradictoires pour un même produit, l'un dans le JSON-LD, l'autre dans le HTML visible. C'est le genre d'incohérence qui fait perdre tous les enrichissements d'une page, sans message d'erreur clair.
Le schema markup est-il indispensable quand on débute en SEO ?
Non. Si vous commencez, il vaut mieux passer du temps sur votre contenu et vos titres que sur du JSON-LD. Le schema markup est une optimisation de second niveau : elle amplifie un résultat déjà bon, elle ne rattrape pas un site mal structuré. Gardez-le pour quand les bases sont solides.
Ce qui me ramène à mon client du début. On a nettoyé son balisage, supprimé les fausses données, ajouté les propriétés manquantes sur ses fiches produit. Son trafic n'a pas explosé du jour au lendemain. Mais ses fiches ont commencé à afficher le prix et la disponibilité, et son taux de clic a progressé. Lentement, puis franchement.
Le schema markup ne crie pas. Il chuchote à l'oreille des machines. Encore faut-il avoir quelque chose qui vaut la peine d'être chuchoté.
