Le schema markup est souvent installé à la va-vite, un plugin coché sans vérification, et la moitié des sites qui pensent en profiter n’en tirent rien. Résultat : des rich results absents, des erreurs invisibles dans la Search Console, et un balisage que les moteurs IA ignorent au moment de citer une source. Voici la méthode pour l’implémenter proprement, du choix du type de schéma jusqu’à la validation après publication.
En bref
Le schema markup est un code structuré, ajouté au HTML d’une page, qui décrit son contenu dans un vocabulaire standardisé compris par Google, Bing et les moteurs IA. Bien implémenté, il ne garantit pas un rich result mais augmente les chances qu’une page soit correctement interprétée et citée.
La méthode fiable tient en cinq étapes : identifier le bon type de schéma, l’écrire en JSON-LD, le placer proprement dans le HTML, le valider avant publication, puis surveiller son état dans le temps face aux plugins de cache et aux mises à jour de thème qui cassent le script.
Qu’est-ce que le schema markup, concrètement
Le schema markup s’appuie sur le vocabulaire schema.org, un standard commun aux moteurs de recherche pour décrire des entités : un article, un produit, un événement, une FAQ, une organisation. Sans ce balisage, un moteur doit deviner le sens d’un bloc de texte à partir de sa position et de sa mise en forme. Avec, il lit une déclaration explicite : ceci est une question, ceci est un prix, ceci est l’auteur d’un contenu.
Trois formats sont admis par Google : JSON-LD, Microdata et RDFa. Google recommande JSON-LD dans sa documentation officielle, car ce format se place dans une balise <script> indépendante du HTML visible, plus simple à maintenir sans toucher au template. C’est le format que nous utilisons systématiquement chez Lead4you, y compris sur cet article.
Le rôle de ce type de balisage a changé avec l’arrivée des moteurs IA génératifs. ChatGPT, Perplexity ou les AI Overviews de Google s’appuient en partie sur des données structurées pour extraire rapidement une réponse fiable plutôt que sur une interprétation du texte brut. Un schema markup propre facilite ce travail d’extraction, sans le garantir.
Choisir le bon type de schéma selon la page
L’erreur la plus fréquente n’est pas technique mais stratégique : appliquer le même schéma partout. Une page article n’a pas les mêmes besoins qu’une page service ou qu’une fiche produit. Le type doit correspondre à la nature réelle du contenu, sous peine d’être jugé trompeur par Google.
Pour un article de blog, BlogPosting ou Article couvrent l’essentiel. Pour une page de questions-réponses, FAQPage s’impose, à condition que les questions soient visibles et lisibles sur la page, pas seulement présentes dans le code. Pour une page service, Service ou Organization selon l’angle. Pour un guide en étapes, HowTo. Notre page SEO & GEO détaille comment ces choix s’articulent avec une stratégie de visibilité plus large.
Combiner plusieurs types sur une même page est possible, à condition que chacun décrive un élément réellement présent. Un BreadcrumbList peut cohabiter avec un Article sans problème : ce sont deux entités différentes de la même page.
La méthode en 5 étapes pour l’implémenter sans erreur
Un déploiement fiable suit toujours le même ordre. Sauter une étape, en particulier la validation, est la cause la plus fréquente de balisage cassé.
- Identifier le type de schéma adapté à chaque gabarit de page (article, service, FAQ, organisation) plutôt qu’un choix unique appliqué partout.
- Écrire le code en JSON-LD, en ne renseignant que les propriétés correspondant à un contenu réellement visible sur la page.
- Insérer ce script en fin de contenu, sans le fragmenter ni le dupliquer entre le thème et un plugin SEO qui génère le même schéma en parallèle.
- Tester avant publication avec le validateur de schema.org et le Rich Results Test de Google, qui ne détectent pas exactement les mêmes erreurs.
- Vérifier après mise en ligne que le script survit à la mise en cache, à la minification et aux filtres de sécurité de WordPress, qui suppriment parfois les balises
<script>jugées à risque.
Les erreurs techniques qui invalident un balisage
La majorité des schémas défaillants ne le sont pas à cause d’une syntaxe fausse, mais d’un décalage entre ce que le code déclare et ce que la page affiche réellement.
| Erreur constatée | Conséquence | Correction |
|---|---|---|
| Propriétés requises manquantes | Le schéma est ignoré pour l’affichage enrichi | Compléter selon la liste des propriétés obligatoires du type choisi |
| Contenu marqué mais invisible sur la page | Risque de non-conformité aux règles de Google | Ne baliser que ce que le visiteur peut lire |
| JSON-LD mal formé (virgule, guillemet) | Le script entier est rejeté, pas seulement la ligne fautive | Valider le code avant toute mise en ligne |
| Script supprimé par un plugin de cache | Le schéma disparaît en production malgré un code correct | Vérifier le code source de la page publiée, pas seulement le brouillon |
| Deux schémas concurrents pour la même entité | Ambiguïté pour le moteur, données parfois contradictoires | Centraliser la génération dans une seule source (thème ou plugin, pas les deux) |
Note terrain Lead4you
Sur les sites que nous avons audités récemment, l’erreur qui revient le plus souvent n’est pas le choix du type de schéma mais sa survie après publication. Un balisage juste au moment de l’écriture peut disparaître de trois façons : le filtre kses de WordPress qui échappe le JSON-LD à l’enregistrement d’un article, un plugin de minification qui coupe des balises <script> jugées superflues, ou un thème qui régénère son propre schéma par-dessus celui déjà présent. Dans les trois cas, l’erreur ne se voit ni dans l’éditeur ni dans un premier test rapide : elle n’apparaît qu’en inspectant le code source réellement servi au visiteur, après cache. C’est cette vérification post-publication, plus que la rédaction du code lui-même, qui fait la différence entre un balisage qui fonctionne et un balisage qui existe seulement dans le brouillon.
Valider et surveiller le balisage dans la durée
Une validation unique au moment du lancement ne suffit pas. Une mise à jour de thème, un nouveau plugin de cache ou une migration peuvent casser un schema markup qui fonctionnait depuis des mois, sans qu’aucune alerte visible ne soit déclenchée côté site.
Deux outils suffisent pour un contrôle régulier : le Rich Results Test de Google pour vérifier l’éligibilité aux résultats enrichis, et le rapport de résultats enrichis dans Search Console pour surveiller les erreurs détectées sur l’ensemble du site, page par page. Un contrôle trimestriel, ou après chaque changement de thème, évite qu’une régression passe inaperçue pendant des mois.
Checklist rapide
- Le type de schéma correspond au contenu réel de la page, pas à un modèle générique copié partout
- Le code est en JSON-LD, dans un seul script, sans doublon avec un plugin
- Seules les propriétés visibles sur la page sont renseignées
- Le validateur schema.org et le Rich Results Test ont été passés avant publication
- Le code source de la page en ligne, après cache, contient bien le script attendu
- Un contrôle Search Console est prévu au moins une fois par trimestre
Demander un audit SEO/GEO gratuit
À lire ensuite
Sources et repères utiles
FAQ
Qu’est-ce que le schema markup exactement ?
C’est un code structuré, généralement écrit en JSON-LD, qui décrit le contenu d’une page dans un vocabulaire standardisé issu de schema.org. Il permet aux moteurs de recherche et aux moteurs IA d’identifier précisément la nature d’un contenu : article, question, produit, organisation, plutôt que de le déduire du texte brut.
JSON-LD, Microdata ou RDFa : quel format choisir ?
Google accepte les trois mais recommande officiellement JSON-LD, car il se maintient dans un script séparé du HTML visible, sans risque de casser la mise en page. C’est le format le plus simple à faire évoluer sans toucher au template du site.
Un schema markup garantit-il l’apparition d’un rich result ?
Non. Google le précise explicitement dans sa documentation : un balisage correct rend une page éligible, mais l’affichage enrichi reste soumis à l’algorithme et à la pertinence jugée du contenu. Aucun outil ne peut promettre un résultat garanti.
Comment vérifier qu’un schema markup fonctionne après publication ?
En inspectant le code source réellement servi au visiteur, après passage par le cache, puis en le testant avec le Rich Results Test de Google. Le brouillon dans l’éditeur peut être correct alors que la version mise en cache a perdu le script.
Le schema markup aide-t-il à être cité par ChatGPT ou Perplexity ?
Il facilite l’extraction d’une réponse fiable en structurant explicitement l’information, ce qui sert les moteurs IA autant que Google. Il ne remplace toutefois pas un contenu clair, sourcé et déjà bien organisé sur la page.
Faut-il un schema markup différent sur chaque page ?
Oui, le type doit correspondre au gabarit réel de la page : BlogPosting pour un article, FAQPage pour une page de questions, Service pour une page prestation. Appliquer un schéma générique partout est une des causes les plus fréquentes d’erreurs de validation.