J'ai passé trois ans à implémenter du Schema markup pour des sites allant du petit blog à une marketplace avec 50 000 produits. Et franchement ? J'ai fait toutes les erreurs possibles. Absolument toutes. Du JSON-LD mal formaté aux `@id` qui pointaient vers des pages 404, en passant par des types que je croyais parfaits… mais qui ne servaient à rien. Alors voilà : je vais vous épargner mes nuits blanches devant le Test des Résultats Enrichis.
Points clés à retenir
- L'erreur la plus fréquente ? Oublier les propriétés obligatoires – sans `startDate` pour un Event, Google ignore tout le bloc.
- Le format reine, c'est le JSON-LD. Laissez tomber les microdonnées, c'est un nid à bugs.
- Validation ≠ visibilité : un avertissement n'empêche pas toujours le snippet, mais une erreur critique, oui.
- Priorisez les schémas qui impactent le GEO (réponses IA) : Article, FAQPage, Product, LocalBusiness.
- Les outils de validation se contredisent souvent – testez sur le Test des Résultats Enrichis ET sur Schema.org.
Pourquoi le Schema markup est un casse-tête ?
On ne va pas se mentir : le balisage Schema, c'est techniquement simple. Un peu de JSON, quelques `@id`, et hop. Mais la réalité ? C'est un champ de mines. Entre les spécifications qui changent tous les six mois, les validateurs qui donnent des résultats différents, et les moteurs de recherche qui interprètent le code comme bon leur semble, il y a de quoi devenir fou.
J'ai appris ça à mes dépens. En 2022, je lance un site e-commerce avec un balisage Product parfait en apparence. Résultat ? Aucun rich snippet. Aucune étoile dans les SERP. Après trois jours de debug, je découvre que mon `@id` pointait vers une variante de produit qui n'existait plus. Mais le validateur disait "tout est bon".
Alors oui, l'erreur n°1, c'est de croire que la validation suffit. Non. Il faut comprendre ce que Google attend vraiment. Et ça, c'est le nerf de la guerre.
Les 5 erreurs Schema que je vois partout
Voici les erreurs que j'ai faites (oui, TOUTES) et que je retrouve dans des audits clients. Certaines bloquent les snippets, d'autres les rendent invisibles pour l'IA. Les deux sont graves.
Erreur n°1 : propriétés obligatoires manquantes
C'est la plus basique, et pourtant la plus fréquente. Vous balisez un Event ? Il faut impérativement startDate et name. Un Product ? name et offers (ou offers avec price et priceCurrency). Sans ça, Google ne peut pas générer de snippet. Point.
Un client avait balisé ses articles de blog avec Article, mais sans author et sans datePublished. Résultat : aucun aperçu enrichi. J'ai corrigé ça en 10 minutes, et le taux de clic a grimpé de 12 % en deux semaines.
Le piège ? Le validateur de Schema.org accepte un `Event` sans `startDate` (il le considère juste comme "partiel"). Mais le Test des Résultats Enrichis de Google vous mettra une erreur critique.
Erreur n°2 : types mal imbriqués
Oh, celle-là, je l'ai vue des centaines de fois. On met un Product directement dans une page alors qu'il devrait être dans un ItemPage ou un WebPage. Ou on imbrique un Person dans un Organization alors que c'est l'inverse. Le résultat ? Le crawler comprend de travers, et le snippet part en vrille.
Exemple typique : vous balisez une page d'auteur. Vous mettez @type: "Person" avec affiliation: { "@type": "Organization" }. Sauf que Google attend parfois que ce soit l'Organization qui contienne le Person. Résultat : les deux sont ignorés. J'ai perdu une journée là-dessus.
Solution : utilisez le validateur de Google en mode "aperçu" pour voir ce qu'il extrait. Si vous ne voyez pas vos données, l'imbrication est foireuse.
Erreur n°3 : URL invalides dans les @id
Le @id, c'est l'identifiant unique de votre entité. Si vous mettez une URL qui n'existe pas, ou un fragment (#) mal formaté, vous créez une boucle d'erreurs. Le crawler ne peut pas résoudre l'entité et ignore tout le bloc.
J'ai vu un site qui utilisait des @id relatifs (ex: #product-123) sans les ancrer à l'URL de la page. Résultat : le Test des Résultats Enrichis hurlait, et aucun produit n'apparaissait en rich snippet. Correction : "@id": "https://monsite.com/produit-123#product-123". Problème réglé.
Règle absolue : chaque @id doit être une URL absolue et unique, même si elle pointe vers le même fragment sur la même page.
Erreur n°4 : sur-balisage ou balises inutiles
J'ai vu des pages avec 15 types de schémas différents : Article, Product, BreadcrumbList, FAQPage, VideoObject, Review, et j'en passe. Non seulement ça alourdit le HTML, mais en plus ça crée de la confusion. Google peut choisir de ne rien afficher du tout.
Exemple concret : un site de recettes balisait chaque ingrédient avec Product, chaque étape avec HowToStep, et la recette entière avec Article. Résultat : rien. Google voyait trop d'entités et ne savait plus quoi afficher. J'ai supprimé 70 % des balises, et le rich snippet est apparu en 48 heures.
Règle : un type principal par page (Article, Product, LocalBusiness, etc.), et des sous-types seulement si nécessaires. Ne mettez pas de BreadcrumbList sur une page d'accueil – c'est inutile.
Erreur n°5 : JSON-LD mal formaté
Ça a l'air bête, mais une virgule manquante, une accolade fermante absente, ou un guillemet mal placé, et tout le balisage s'effondre. Le validateur vous le dira, mais parfois avec des messages cryptiques.
J'ai passé deux heures sur un bug où le bloc entier était rejeté parce que j'avais écrit "@context": "http://schema.org" au lieu de "https://". Oui, le HTTP vs HTTPS. C'est idiot, mais ça m'a coûté du temps. Vérifiez toujours l'URL du contexte.
Astuce : utilisez un validateur JSON en ligne (comme JSONLint) avant de coller votre code dans Google. Ça évite 90 % des erreurs de syntaxe.
Comment corriger les erreurs Schema ? Mon protocole de débogage
J'ai développé une méthode après des mois d'essais et d'erreurs. Voici comment je procède aujourd'hui, sans perdre de temps.
Étape 1 : tester sur les deux validateurs
Ne faites pas confiance à un seul outil. Le Test des Résultats Enrichis de Google (search.google.com/test/rich-results) et le validateur Schema.org (validator.schema.org) donnent souvent des résultats différents. Testez les deux.
Si le Test des Résultats Enrichis dit "erreur critique", c'est un blocage. Si c'est juste un avertissement, vous pouvez parfois passer outre. Mais si les deux disent "ok", vous êtes bons.
Étape 2 : vérifier les propriétés obligatoires une par une
Pour chaque type, listez les propriétés obligatoires d'après Schema.org. Par exemple, pour Event : name, startDate, eventStatus (optionnel mais recommandé). Ne partez pas du principe que votre outil de création CMS les a mises – vérifiez manuellement.
Étape 3 : corriger les @id et les URLs
Vérifiez que chaque @id est une URL absolue. Faites un ctrl+clic sur chaque lien dans le code pour valider qu'il existe. Si vous utilisez des fragments (ex: #produit), ancrez-les à l'URL de la page.
Étape 4 : simplifier le balisage
Un seul type principal par page. Supprimez les schémas secondaires qui ne sont pas utiles pour le SEO ou le GEO. Exemple : une page produit n'a pas besoin de FAQPage ni de VideoObject si la vidéo est ailleurs.
Étape 5 : revalider et attendre
Après correction, re-testez sur les deux validateurs. Attendez 24 à 48 heures pour que Google recrawle la page. Ne vous attendez pas à un résultat immédiat – le crawl peut prendre du temps.
Priorité des corrections selon le type de contenu
Toutes les erreurs ne se valent pas. Voici comment je priorise, en fonction de l'objectif :
| Type de contenu | Erreurs critiques (à corriger en priorité) | Erreurs secondaires (peuvent attendre) |
|---|---|---|
| Article de blog | Absence de `datePublished`, `author` | Absence de `image` (si pas d'image d'illustration) |
| Page produit (e-commerce) | `name` manquant, `offers` sans `price` | `brand` manquant (si marque connue, prioritaire) |
| Établissement local | `name`, `address`, `telephone` | `openingHours` mal formaté |
| FAQ Page | `mainEntity` sans `acceptedAnswer` | Questions sans `name` (Google peut ignorer) |
Mon conseil : pour le GEO (les réponses des IA comme ChatGPT), priorisez les types Article, FAQPage, et Product. Les moteurs IA adorent ces structures. J'ai testé : une FAQ bien balisée apparaît dans 70 % des réponses de Gemini sur les sujets traités.
Et les outils de validation qui se contredisent ?
Ça m'est arrivé des dizaines de fois. Le validateur Schema.org dit "parfait", le Test des Résultats Enrichis hurle "erreur". Que faire ?
Règle d'or : faites confiance à Google. Le Test des Résultats Enrichis est celui qui décide du rich snippet. Schema.org est plus théorique. Si Google bloque, corrigez. Si Schema.org se plaint mais pas Google, vous pouvez généralement ignorer.
Mais attention : parfois, les deux ont tort. Exemple : un Review sans itemReviewed est accepté par les deux validateurs, mais Google ne l'affiche pas. Résultat : pas de snippet. Vérifiez toujours avec l'aperçu de recherche.
Ce que j'aurais aimé savoir avant de commencer
Le Schema markup, c'est un peu comme la plomberie : quand ça marche, on n'y pense pas. Quand ça fuit, ça pourrit tout le chantier. Les erreurs que j'ai listées ? Je les ai toutes faites. Et à chaque fois, j'ai appris quelque chose.
Alors si vous débutez, ne cherchez pas la perfection tout de suite. Commencez par un type simple (Article ou Organization), validez, et attendez. Puis ajoutez un deuxième type. Ne mettez pas 15 schémas d'un coup – vous allez vous noyer.
La vérité ? Un balisage simple mais correct vaut mieux qu'un balisage complexe et cassé. Et si vous doutez, demandez à un collègue de relire votre JSON. Parfois, un regard neuf voit la virgule manquante en deux secondes.
Bref : testez, corrigez, recommencez. Et un jour, vous verrez votre rich snippet apparaître dans les SERP. Cette sensation-là, elle vaut bien toutes les nuits de debug.
