Le balisage schema.org, c'est un peu comme ces meubles en kit qui promettent un montage en vingt minutes. Sur le papier, tout semble simple. En pratique, vous finissez par vous retrouver avec des vis en trop, une étagère de travers, et la vive impression d'avoir raté une étape.
J'ai passé des années à auditer des sites, et je peux vous dire une chose : les erreurs de balisage sont partout. Pas seulement sur les sites des autres, d'ailleurs. J'ai moi-même laissé partir en production des JSON-LD avec des URL absolument invalides. Ça arrive. Mais quand on connaît les pièges, on les évite.
Points clés à retenir
- Le JSON-LD reste le format le plus fiable, loin devant la Microdata et RDFa, plus complexes et donc plus sujettes aux erreurs.
- Une URL relative dans un champ url ou image casse silencieusement la plupart des types de schéma.
- Tester systématiquement avec le test des résultats enrichis avant la mise en production, et non après.
- Le balisage n'est pas une décoration SERP : c'est une couche de lisibilité machine, essentielle pour les moteurs de recherche et les systèmes d'IA.
- Un schéma qui décrit autre chose que le contenu visible de la page est pire qu'aucun schéma, pour la confiance des robots.
Les erreurs de balisage courantes qui plombent votre visibilité
Quand un balisage est mal implémenté, le résultat est toujours le même : pas de résultats enrichis, et un message d'erreur cryptique dans l'outil de test. Mais toutes les erreurs ne se valent pas. Certaines sont des avertissements que Google tolère. D'autres, des erreurs critiques qu'il vous faudra corriger sous peine de voir le schéma totalement ignoré.
Voici les plus fréquentes, celles que je croise dans presque chaque audit.
Les erreurs de validation et de syntaxe
Commençons par le plus basique, et pourtant le plus courant : la syntaxe invalide. Une virgule oubliée, un guillemet mal fermé, et votre JSON-LD ne se parse plus. Les outils de validation comme validator.schema.org le détectent immédiatement, mais ils ne sont pas toujours utilisés systématiquement.
J'ai vu un site e-commerce perdre ses étoiles de notation pendant trois semaines à cause d'une simple apostrophe mal échappée dans une description de produit. Trois semaines. Le pire, c'est que personne ne s'en est rendu compte tout de suite, parce que le code source semblait correct à l'œil nu.
Les trois formats d'encodage — RDFa, Microdata et JSON-LD — n'ont pas la même propension aux erreurs. RDFa et la Microdata sont des méthodes plus anciennes, dont la mise en œuvre est plus complexe. Elles sont donc nettement plus sujettes aux erreurs. Pour cette raison, je recommande presque toujours d'utiliser le JSON-LD. C'est plus propre, isolé dans une balise script, et ça ne pollue pas votre HTML avec des attributs itemscope, itemtype et autres joyeusetés.
Et une fois le code écrit ? Il faut le valider. Pas une fois, mais à chaque modification de la page. Le test des résultats enrichis de Google reste l'outil de référence. Un réflexe à avoir, comme sauvegarder son travail.
Le type de schéma incohérent avec le contenu
Voici une erreur que je qualifierais de "silencieuse", car elle ne produit pas toujours d'erreur dans les outils de test. Elle consiste à baliser une page avec un type de schéma qui ne correspond pas à son contenu. Un exemple classique : mettre un schéma Product avec un prix et une disponibilité sur une page qui est en réalité un article de blog présentant un produit.
Google s'en rend compte. Pas immédiatement, parfois. Mais quand l'algorithme compare le balisage au contenu visible et qu'il détecte une incohérence, il perd confiance. Et la confiance, une fois perdue, est difficile à regagner.
Autre exemple que je croise souvent : les pages catégories d'e-commerce balisées en ItemList alors qu'elles devraient être en CollectionPage. Ou les pages d'accueil qui cumulent cinq types de schéma différents dans un seul bloc, sans hiérarchie ni logique. Résultat : rien n'est compris, tout est ignoré.
Le bon réflexe ? Se poser une question simple avant d'écrire la moindre ligne de code : quelle est l'intention principale de cette page ? Une page produit vend. Une page article informe. Une page FAQ répond. Le balisage doit refléter cette intention, pas en cumuler trois.
Structures invalides et données manquantes
Une autre famille d'erreurs concerne la structure interne du schéma. Un type comme Article exige certaines propriétés. Si vous les omettez, le balisage devient incomplet, et les moteurs de recherche peinent à l'interpréter. Résultat : pas de résultats enrichis, et une occasion manquée de vous démarquer dans les résultats.
Le problème ? Beaucoup de propriétés ne sont pas marquées "obligatoires" par schema.org, mais elles le sont de facto pour obtenir un affichage enrichi. C'est le cas de datePublished pour un article, ou de price et availability pour un produit. Les omettre, c'est s'assurer que le balisage ne produira aucun effet visible.
Les URL relatives, l'erreur sournoise par excellence
Si je ne devais retenir qu'une seule erreur à traquer, ce serait celle-là. Une URL relative dans un champ url, image ou sameAs invalide le balisage, point. Les moteurs de recherche attendent des URL absolues, complètes, avec le protocole https:// et le nom de domaine.
Dans un CMS, quand on génère le JSON-LD dynamiquement avec une variable qui ne contient que le chemin relatif, l'erreur passe inaperçue en phase de test. Mais en production, le balisage est ignoré. Et le test des résultats enrichis vous sortira un message du type : "Le champ url doit être une URL absolue."
Prenez le réflexe de vérifier vos URLs générées dans le code source de la page publiée. Pas dans l'éditeur, pas dans l'aperçu : dans le code réellement servi au visiteur.
Les données manquantes pour les types structurés
Pour les types comme Product, Offer ou Review, chaque propriété manquante réduit les chances d'obtenir un affichage enrichi. J'ai audité un site qui affichait des centaines de produits sans la propriété brand. Résultat : aucune étoile dans les résultats, alors que les concurrents en affichaient.
Autre exemple : les pages de recettes sans cookTime ou recipeYield, ou les événements sans startDate. Dans chaque cas, le schéma existe, mais il est amputé de ce qui le rend utile pour les moteurs de recherche. Un balisage incomplet, c'est un peu comme une voiture sans roues : vous pouvez la regarder, mais elle ne vous mènera nulle part.
Mon conseil ? Faites une liste des propriétés recommandées pour chaque type de schéma que vous utilisez, et intégrez cette liste à votre checklist de publication. Ça semble bureaucratique, mais ça évite des allers-retours inutiles.
Le balisage à l'ère de l'IA générative
Depuis que les moteurs de réponse IA se sont généralisés, le rôle du balisage a changé. Vous avez peut-être vu passer la nouvelle : Google a déprécié les résultats enrichis FAQ. Eh bien, le type FAQPage reste valide et peut être conservé sur les pages. Google l'utilise toujours pour la compréhension du contenu, même s'il n'affiche plus de résultats enrichis visibles dans ses résultats de recherche.
C'est une distinction importante à comprendre. Le balisage schema.org n'est plus seulement une tactique pour obtenir des étoiles ou des encadrés dans les SERP. C'est devenu une couche de lisibilité machine. Les systèmes d'IA qui répondent aux questions des utilisateurs ont besoin de données structurées, claires, non ambiguës. Et c'est exactement ce que fournit un bon balisage.
Donc non, le schema n'est pas mort. Il a simplement changé de fonction. Et dans ce nouveau contexte, les erreurs de balisage ont un impact différent : elles ne coûtent plus seulement un affichage enrichi, elles dégradent la capacité des systèmes d'IA à comprendre et à extraire votre contenu.
Schema.org est-il toujours pertinent ?
Oui, sans ambiguïté. Le balisage schema.org reste pertinent, même si son rôle a évolué. Il ne s'agit plus de décorer les résultats de recherche, mais de fournir un contexte compréhensible par les machines. Les moteurs de recherche traditionnels l'utilisent toujours pour classifier les pages, et les moteurs de réponse IA en dépendent pour extraire des informations fiables.
Concrètement, si vous avez un balisage FAQPage en place, vous pouvez le laisser. Il ne génèrera plus de résultats enrichis visibles, mais il continue d'aider les moteurs de recherche à comprendre la structure de votre contenu. C'est un investissement qui continue de produire des bénéfices, même s'ils sont moins spectaculaires.
Ce qui a changé, c'est l'importance relative des différents types de schéma. Les types qui décrivent des entités claires — Product, Organization, Person, Event — deviennent plus précieux dans un monde où les IA doivent répondre à des questions factuelles. Les types plus décoratifs, comme FAQPage, perdent de leur intérêt visible sans perdre leur utilité fonctionnelle.
Comment utiliser le balisage comme un professionnel
Après des années à auditer des sites, j'ai fini par adopter une approche simple, presque minimaliste. Elle tient en trois règles.
Premièrement, validez avant de publier. Le test des résultats enrichis est gratuit, rapide, et il vous dit exactement ce qui cloche. L'utiliser à chaque publication, c'est le réflexe de base. Pas après coup, quand le mal est fait.
Deuxièmement, restez cohérent. Le schéma doit décrire exactement ce que la page contient, ni plus, ni moins. Une page produit qui parle d'un produit, une page article qui parle d'un article. Pas de mélange, pas d'exagération.
Troisièmement, pensez IA. Demandez-vous si le balisage aiderait un système d'IA à répondre à une question sur votre contenu. Si la réponse est non, vous avez probablement un problème de structure ou de données manquantes. Si la réponse est oui, vous êtes probablement sur la bonne voie.
Et une dernière chose : ne négligez pas les propriétés qui décrivent vos entités de manière exhaustive. Le sameAs pour les réseaux sociaux, le logo pour les organisations, la dateModified pour les articles. Ces détails font la différence entre un balisage qui fonctionne et un balisage qui est simplement présent.
Le schema.org n'est pas une science exacte, et il reste une marge d'interprétation. Mais les erreurs que j'ai décrites ici sont celles que je vois le plus souvent, et celles qui coûtent le plus cher en termes de visibilité manquée. Les éviter, ce n'est pas compliqué. C'est juste une question de méthode et de vigilance.
La prochaine fois que vous publierez une page, pensez à vérifier son code source. Pas pour le plaisir, mais parce que c'est là que tout se joue. En silence. Dans les coulisses du web.
