Guide de Schema.org et JSON-LD pour les données structurées

Sélectionnez l'objet réellement décrit sur la page, remplissez ses propriétés et obtenez le code JSON-LD à insérer dans le HTML. Le générateur aide à construire la syntaxe, mais avant la publication, il est nécessaire de vérifier la conformité avec le contenu visible, les exigences du consommateur de données choisi et l'actualité des valeurs.

Schema.org, JSON-LD et le résultat enrichi sont des choses différentes

Schema.org

Il s'agit d'un vocabulaire commun de types et de propriétés : Article, Product, Organization, Event, name, image, offers et bien d'autres. Il décrit quelles entités et relations peuvent être représentées de manière structurée.

JSON-LD

C'est l'un des formats d'écriture des données structurées. Le code est placé à l'intérieur de :

Google recommande JSON-LD lorsqu'il est adapté à l'implémentation, mais Schema.org peut également être écrit avec Microdata ou RDFa.

Résultat enrichi de Google

Il s'agit d'une présentation spéciale dans les résultats de recherche qui ne prend en charge qu'un ensemble limité de types et nécessite le respect de règles spécifiques de Google. Un balisage Schema.org valide ne garantit pas un résultat enrichi, un bon classement ou même l'utilisation de toutes les propriétés transmises. Par conséquent, il ne faut pas évaluer le balisage uniquement en se demandant "va-t-il afficher un bel extrait ?". Il doit avant tout décrire correctement l'entité réelle de la page.

Comment choisir le type de balisage

Choisissez le type en fonction de l'objet principal de la page, et non de l'apparence souhaitée dans les résultats de recherche.

Sur une page, plusieurs objets liés sont autorisés. Par exemple, un article peut avoir un auteur Person, un éditeur Organization, un fil d'Ariane BreadcrumbList et une vidéo intégrée VideoObject. Il est préférable de les lier via @id plutôt que de créer des copies contradictoires.

Restrictions importantes et actuelles de Google

FAQPage

Google a considérablement limité l'affichage des résultats enrichis de FAQ : ils ne sont généralement disponibles que pour les sites gouvernementaux et médicaux de haute autorité. Pour un site commercial ou informatif ordinaire, un balisage FAQPage correct peut ne pas apporter d'extension notable dans les résultats. Cela ne rend pas le type FAQPage invalide dans Schema.org, mais on ne peut pas promettre à l'utilisateur que "les questions apparaîtront sur Google".

HowTo

Google a cessé d'afficher les résultats enrichis HowTo. Le type HowTo reste dans le vocabulaire Schema.org et peut être utilisé par d'autres consommateurs, mais l'ajouter uniquement pour l'ancien résultat enrichi de Google n'a plus de sens.

Autres types

Organization, Person et WebSite aident à décrire des entités, mais tous ne créent pas un résultat enrichi visuel distinct. Le support et l'apparence des fonctionnalités de recherche changent, donc avant de mettre en œuvre, vérifiez la galerie actuelle de Google Search Central.

Règle principale : le balisage doit correspondre au contenu visible

N'ajoutez pas dans JSON-LD des informations absentes de la page ou qui la contredisent. Cela concerne particulièrement :

• le prix et la disponibilité du produit ;
• la note et le nombre d'avis ;
• les questions et réponses ;
• la date et le lieu de l'événement ;
• l'auteur du contenu ;
• l'adresse et les horaires de l'entreprise ;
• les conditions de l'offre d'emploi ;
• les ingrédients et les étapes de la recette.

Le balisage n'est pas un endroit pour du texte publicitaire caché ou des mots-clés supplémentaires. L'utilisateur et le moteur de recherche doivent recevoir des informations cohérentes.

Les champs obligatoires dépendent de qui lit le balisage

Schema.org définit un vocabulaire, mais pas une liste universelle unique de "champs obligatoires" pour tous les systèmes. Un consommateur spécifique, comme Google Search, établit ses propres propriétés obligatoires et recommandées pour une fonction de recherche donnée. Par conséquent, trois résultats de validation différents sont possibles :

1. Le JSON est syntaxiquement correct.
2. Les types et propriétés existent dans Schema.org.
3. Le balisage répond aux exigences du résultat enrichi spécifique de Google.

La réussite de la première ou de la deuxième étape ne garantit pas la troisième.

Comment remplir les URL, les dates et les identifiants

Utilisez des URL absolues

De préférence :

Au lieu de :

Les liens doivent être accessibles au robot de recherche, ne pas nécessiter d'authentification et pointer vers une ressource stable.

Indiquez les dates au format ISO 8601

Date :

Date et heure avec fuseau horaire :

Pour les événements, il est particulièrement important de ne pas perdre le fuseau horaire. Sinon, l'heure pourrait être interprétée incorrectement.

Créez un @id stable

@id est l'identifiant de l'entité, souvent sous forme d'URL avec fragment :

La même organisation sur différentes pages doit faire référence à un identifiant stable, et non ressembler à de multiples entreprises indépendantes.

Comment décrire plusieurs entités avec @graph

Pour les objets liés, il est pratique d'utiliser un seul bloc :

Ainsi, les objets sont explicitement liés et il n'est pas nécessaire de répéter toutes les informations sur l'organisation dans chaque article.

Où insérer JSON-LD

Le bloc <script type="application/ld+json"> peut être placé dans <head> ou <body> de la page HTML. Il est plus important que :

• le code soit présent dans le HTML final ou accessible après un rendu correct ;
• il se rapporte spécifiquement à la page actuelle ;
• le CMS l'échappe sans endommager les guillemets et les caractères ;
• un même modèle n'insère pas les mêmes données sur différentes pages ;
• le prix dynamique, la disponibilité et les dates soient mis à jour en même temps que le contenu visible.

Après la mise en œuvre, vérifiez non seulement le code du générateur, mais aussi l'URL publiée : le modèle, un plugin ou JavaScript peuvent modifier le balisage final.

Deux niveaux de validation différents

Schema Markup Validator

Vérifie la syntaxe et l'utilisation du vocabulaire Schema.org. Il est adapté pour voir les types trouvés, les propriétés et les problèmes généraux du balisage.

Google Rich Results Test

Indique si Google reconnaît sur la page un type de résultat enrichi pris en charge et si ses exigences spéciales sont remplies. L'outil ne confirme pas que le résultat enrichi apparaîtra dans la recherche. Après la publication, il est également utile de vérifier l'URL via l'inspection d'URL dans Google Search Console pour voir la version traitée par Google et les éléments détectés.

Erreur et avertissement ne sont pas des catégories universelles

Un validateur peut considérer l'absence d'une propriété comme un avertissement, alors qu'elle s'avère obligatoire pour un consommateur spécifique. Inversement, Schema.org autorise une propriété que Google n'utilise pas pour la fonction souhaitée. Évaluez le message selon quatre questions :

1. La syntaxe JSON est-elle cassée ?
2. Le type et la propriété existent-ils dans Schema.org ?
3. La propriété est-elle correctement imbriquée et a-t-elle une valeur valide ?
4. Est-elle requise par la fonction de recherche choisie ou une autre intégration ?

Erreurs fréquentes

• Type inapproprié : la page de catégorie de produits est balisée comme un seul Product, bien qu'il n'y ait pas de produit individuel ni d'offre unique. Ou un article ordinaire reçoit FAQPage uniquement parce qu'il y a un petit bloc de questions en bas.
• Le balisage ne correspond pas à la page : le code indique un ancien prix, une note inexistante, des questions cachées ou un autre auteur.
• Entités en conflit : plusieurs plugins créent différents blocs Organization avec des noms, logos et URL divergents. Les objets ne sont pas liés via un @id commun.
• Imbrication incorrecte : par exemple, price est écrit directement dans Product, alors que l'offre est généralement décrite via un objet Offer dans la propriété offers.
• Type de valeur incorrect : la date est écrite comme un texte arbitraire, le prix contient la devise dans la même chaîne, la valeur booléenne est transmise comme une phrase et le champ attendu comme URL contient un chemin relatif.
• Images et pages inaccessibles : l'URL renvoie une erreur, est bloquée par une authentification ou robots.txt, pointe vers un lien temporaire instable ou vers une image que le moteur de recherche ne peut pas récupérer.
• Données dynamiques obsolètes : l'événement est déjà terminé, le poste est pourvu, le produit n'est pas disponible, mais le balisage continue de transmettre l'ancien statut.
• Erreurs JSON : guillemets simples ou typographiques ; virgule superflue après la dernière propriété ; crochet non fermé ; commentaires dans le JSON ; saut de ligne non traité dans une valeur de chaîne ; clé en double dans un même objet.

Processus de mise en œuvre

1. Identifiez l'objet principal et l'objectif du balisage.
2. Vérifiez les exigences actuelles de Schema.org et du consommateur de données nécessaire.
3. Sélectionnez le type le plus précis.
4. Ne remplissez que les propriétés fiables présentes sur la page.
5. Générez le JSON-LD.
6. Validez le code dans Schema Markup Validator.
7. Si un résultat enrichi compatible avec Google est nécessaire, vérifiez avec Rich Results Test.
8. Insérez le code dans une version de test de la page.
9. Vérifiez à nouveau l'URL publiée, et non seulement le fragment isolé.
10. Configurez la mise à jour des valeurs dynamiques et de nouvelles vérifications après des modifications de modèle.

Liste de contrôle rapide avant la publication

• le type d'objet réel de la page a été sélectionné ;
• les données correspondent au contenu visible ;
• il n'y a pas de notes, avis ou propriétés inventés ;
• les URL sont absolues, accessibles et canoniquement cohérentes ;
• les dates sont dans un format clair et avec fuseau horaire si nécessaire ;
• le prix et la devise sont dans des champs séparés ;
• les mêmes entités sont liées via un @id stable ;
• il n'y a pas de balisage conflictuel d'un autre module ;
• le code a passé les validations appropriées ;
• l'URL publiée contient le même JSON-LD correct ;
• les données dynamiques seront mises à jour.

Foire aux questions

Schema.org garantit-il un extrait enrichi ?

Non. Un balisage correct rend la page traitable, mais le moteur de recherche décide de manière autonome s'il l'utilise et comment afficher le résultat.

Est-il nécessaire d'ajouter Schema.org sur chaque page ?

Seulement là où il y a une entité et des propriétés utiles et fiables pour la décrire. L'insertion massive du même bloc sans lien avec le contenu crée des erreurs et des contradictions.

Peut-on laisser des propriétés que l'utilisateur ne voit pas ?

Les relations techniques et les identifiants peuvent ne pas être affichés comme un texte séparé, mais les informations factuelles sur le produit, la note, les questions, l'événement et d'autres objets doivent correspondre au contenu accessible à l'utilisateur et aux règles du consommateur.

Où placer le code – dans head ou body ?

JSON-LD peut se trouver aux deux endroits. L'important est le HTML final correct, l'accessibilité du balisage pour le processeur et la cohérence avec la page actuelle.

Pourquoi Schema Markup Validator n'affiche-t-il pas d'erreur alors que Google en affiche une ?

Le premier outil vérifie le vocabulaire Schema.org et la structure du balisage, tandis que Google applique en plus les exigences spécifiques de la fonction de recherche.

Est-il judicieux de baliser FAQPage actuellement ?

On peut le faire lorsque la page est réellement une FAQ et que le type est utile pour d'autres consommateurs de données. Mais pour la plupart des sites, il ne faut pas compter sur le résultat enrichi FAQ de Google.

HowTo est-il nécessaire pour Google ?

Google n'affiche plus de résultats enrichis HowTo. Le type peut rester utile comme description sémantique pour d'autres systèmes, mais il ne faut pas s'attendre à l'effet précédent de Google.

Outils associés

Diffchecker ; Traitement de textes ; Base64.

Documents officiels

• Vocabulaire Schema.org
• Google Search Central — Introduction aux données structurées
• Google — Directives générales sur les données structurées
• Google — Galerie des fonctionnalités de données structurées
• Schema Markup Validator
• Google Rich Results Test

Recommandations éditoriales générales pour la section

1. Ne pas dupliquer le même bloc commercial dans chaque texte utile

Le bloc actuel sur "l'audit SEO complet, les outils pour la croissance de la visibilité dans l'IA et l'automatisation" peut être laissé comme un CTA visuel séparé après le matériel principal. Il ne doit pas être intégré dans la structure de l'article entre les sections utiles : cela interrompt le flux de lecture et semble identique sur les neuf pages. Il est préférable d'utiliser un court lien contextuel correspondant à l'outil. Par exemple :

• après le générateur d'UTM — vers les rapports par canal et conversions ;
• après le combinateur — vers la vérification de la fréquence, le clustering et l'attribution des requêtes aux pages ;
• après Schema — vers l'audit des données structurées ;
• après Diffchecker — vers le suivi des modifications de pages ;
• après la suppression des doublons — vers l'importation de sémantique ou d'URL dans le projet.

2. Ne pas créer de sections identiques "Avantages" et "À qui convient" par modèle

Leur contenu se transforme presque toujours en répétitions : "rapide", "pratique", "gratuit", "pour les spécialistes du marketing et les professionnels". Il est plus utile de laisser des scénarios concrets, des limites, des exemples et des FAQ. Les caractéristiques brèves comme "gratuit", "dans le navigateur", "sans inscription" sont déjà affichées à côté de l'outil.

3. Aligner les promesses avec l'implémentation réelle

Avant la publication, les développeurs doivent confirmer :

• le traitement est-il entièrement effectué dans le navigateur ou les données sont-elles envoyées au serveur ;
• quelles sont les limites de volume de texte et de nombre de lignes ;
• les données originales ou les résultats sont-ils conservés ;
• quel algorithme et quelle bibliothèque sont utilisés pour la détection de la langue ;
• comment exactement Diffchecker compare les mots et les lignes ;
• la suppression des doublons est-elle sensible à la casse et aux espaces, et dans quel ordre les actions sont-elles appliquées ;
• le générateur de mots de passe utilise-t-il une source de caractère aléatoire cryptographiquement solide ;
• quel encodage le convertisseur Base64 utilise-t-il ;
• prend-il en charge Base64url ou uniquement Base64 standard.

Après confirmation, ces détails peuvent être inclus dans un bref bloc "Traitement et confidentialité" sur chaque page. On ne peut pas promettre un traitement local et l'absence de stockage uniquement parce que l'outil fonctionne visuellement dans le navigateur.

4. Afficher les limites à côté de la fonction, ne pas les cacher en bas

Avertissements particulièrement importants :

• les paramètres UTM ne sont pas placés sur les liens internes ;
• Diffchecker ne vérifie pas le sens ni l'exactitude factuelle ;
• le combinateur ne confirme pas la demande et ne crée pas automatiquement la structure du site ;
• Base64 ne chiffre pas les données ;
• une URL entière ne doit pas être mise en minuscules sans vérification ;
• un mot de passe ne peut pas être considéré comme cryptographiquement solide sans vérifier le générateur ;
• un Schema.org valide ne garantit pas un résultat enrichi.

5. Ajouter des liens internes en fonction de la prochaine action de l'utilisateur

Au lieu d'une liste générale de tous les utilitaires à la fin de la page, placez deux ou trois liens vraiment pertinents. Le nom du lien doit expliquer la suite du scénario : "Nettoyer la liste obtenue", "Comparer deux versions", "Supprimer les combinaisons en double", "Vérifier la langue du texte".

6. Ne pas baliser les FAQ uniquement pour promettre un extrait enrichi

Les FAQ dans ces textes sont utiles pour l'utilisateur et peuvent rester sur la page. Mais la décision d'ajouter FAQPage doit être prise séparément, en tenant compte des règles de Schema.org et des limitations actuelles des moteurs de recherche. Pour les sites ordinaires, Google n'affiche généralement pas de résultats enrichis de FAQ.

7. Ordre recommandé pour la mise en œuvre

1. Diffchecker, détection de la langue et UTM — actuellement, ils ont le moins de matériel utile.
2. Suppression des doublons — corriger d'urgence le conseil de convertir toutes les URL en minuscules.
3. Base64 — remplacer "déchiffrer" par "décoder" et ajouter Base64url.
4. Générateur de mots de passe — mettre à jour les recommandations de longueur et vérifier l'implémentation de la génération aléatoire.
5. Schema.org — remplacer le texte actuel excessivement long et répétitif par un guide plus compact mais techniquement précis.
6. Combinateur et traitement de textes — conserver les parties solides, ajouter des limites et un ordre pratique des actions.