Schema.org et JSON-LD : ajouter des données structurées utiles sans surpromettre

Une page Web contient déjà beaucoup d’informations compréhensibles par un humain : un titre, un auteur, une date, un prix, une organisation ou une liste d’étapes.

Les données structurées cherchent à exprimer certaines de ces informations dans une forme plus explicite pour les machines.

Schema.org fournit le vocabulaire. JSON-LD fournit une manière courante de l’écrire.

Schema.org n’est pas un format de fichier

Schema.org définit des types et des propriétés.

Par exemple :

Article
Organization
Product
BreadcrumbList
Person
Event

Chaque type possède des propriétés adaptées.

Un Article peut par exemple avoir :

headline
author
datePublished
image

Le vocabulaire peut être utilisé avec plusieurs syntaxes. JSON-LD est aujourd’hui une approche pratique parce qu’il peut être placé dans un bloc séparé du HTML visible.

À quoi ressemble un JSON-LD ?

Exemple simplifié :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Comprendre le SEO technique",
  "datePublished": "2026-08-29"
}
</script>

Le Générateur Schema.org JSON-LD permet de préparer ce type de structure sans écrire chaque propriété à la main.

Le balisage doit décrire la page réelle

C’est la règle la plus importante.

Si une page n’affiche aucun prix, ajouter un Product avec un prix inventé pour essayer d’obtenir un résultat enrichi est une mauvaise stratégie.

Même logique pour :

• avis ;
• notes ;
• auteur ;
• date ;
• événement ;
• FAQ ;
• disponibilité.

Les données structurées ne doivent pas devenir une deuxième version fictive de la page.

JSON-LD ne remplace pas le contenu visible

Supposons que votre bloc déclare :

{
  "@type": "Article",
  "headline": "Guide complet du robots.txt"
}

mais que la page visible parle essentiellement de CSS.

Le schéma n’oblige pas le moteur à croire la donnée déclarée.

La description structurée doit renforcer une information déjà cohérente avec :

• le contenu ;
• le title ;
• le H1 ;
• l’URL ;
• le contexte général de la page.

Choisir le type le plus précis, sans forcer

Si une page est réellement un article, Article est plus descriptif qu’une entité générique.

Mais il ne faut pas chercher absolument le type « le plus SEO ».

Demandez-vous plutôt :

Quel type décrit honnêtement cette ressource ?

Une page peut aussi comporter plusieurs entités liées lorsque cela correspond à la réalité : une organisation qui publie un article, un fil d’Ariane qui décrit la navigation, etc.

Les propriétés obligatoires et recommandées dépendent du cas

Schema.org contient énormément de propriétés possibles. Les moteurs qui proposent des expériences enrichies peuvent cependant documenter un sous-ensemble précis de propriétés attendues.

Il faut donc distinguer :

vocabulaire Schema.org
≠
exigences d’une fonctionnalité particulière d’un moteur

Un JSON-LD peut être syntaxiquement valide sans être éligible à une présentation enrichie particulière.

Un résultat enrichi n’est jamais garanti

Même si votre balisage est :

• valide ;
• complet ;
• conforme aux recommandations ;
• correctement indexé ;

le moteur peut décider de ne pas afficher d’enrichissement.

Il faut éviter de présenter Schema.org comme un bouton « activer les étoiles dans Google ».

Le bénéfice principal est d’abord la clarté sémantique.

Faites attention aux URLs déclarées

Les propriétés comme url, image ou certains identifiants doivent pointer vers des ressources réellement accessibles et cohérentes.

Évitez par exemple :

canonical : https://example.com/article
JSON-LD url : https://example.com/article?source=test

sans raison précise.

Les métadonnées et les données structurées doivent parler de la même page. Le guide Title, meta description, canonical et Open Graph aide à vérifier cette cohérence.

Une image déclarée doit exister

Si votre schéma référence une image :

"image": "https://example.com/images/article.webp"

vérifiez :

• que l’URL est publique ;
• que le fichier existe ;
• que le format est utilisable ;
• que l’image correspond réellement à la page.

Pour optimiser les fichiers eux-mêmes, utilisez les principes du guide Optimiser les images pour les performances Web.

Éviter les données dupliquées incohérentes

Une page peut contenir la même information à plusieurs endroits :

H1
→ "Guide SEO technique"

title
→ "SEO technique : guide complet"

JSON-LD headline
→ "Guide SEO 2024"

La variation est acceptable si le sens reste cohérent. Le problème est l’information devenue obsolète ou contradictoire.

Les dates sont particulièrement sensibles : ne déclarez pas une date de mise à jour simplement parce que la page a été reconstruite techniquement si son contenu n’a pas réellement changé.

Générer, puis relire

Un générateur élimine une partie des erreurs de syntaxe, mais il ne sait pas si vos données sont vraies.

Avec le Générateur Schema.org JSON-LD, vérifiez après génération :

1. le type choisi ;
2. les noms et dates ;
3. les URLs ;
4. les images ;
5. les propriétés laissées vides ;
6. la correspondance avec le contenu visible.

Un petit schéma exact vaut mieux qu’un schéma impressionnant

Il est tentant d’ajouter des dizaines de propriétés parce qu’elles existent.

Cette complexité augmente pourtant les risques :

• données périmées ;
• URLs incohérentes ;
• informations impossibles à maintenir ;
• champs inventés ;
• erreurs lors des mises à jour.

Commencez par les informations que vous êtes certain de pouvoir maintenir.

Intégrer le contrôle dans la publication

Les données structurées ne devraient pas être un ajout oublié après la mise en ligne.

Elles peuvent faire partie d’une séquence de contrôle :

contenu finalisé
→ URL définitive
→ title / description / canonical
→ JSON-LD si pertinent
→ validation
→ publication
→ contrôle de la page réelle

La Checklist SEO technique avant publication rassemble ces vérifications avec robots.txt, maillage interne et performance.