Données structurées SEO : schema.org et JSON-LD en pratique

Il y a un malentendu tenace autour du balisage sémantique : beaucoup l’installent en espérant un gain de position, puis constatent que rien ne bouge. C’est logique — ce n’est pas à cela qu’il sert. En revanche, entre deux résultats de même niveau, celui qui affiche une note, un prix ou une date attire davantage de clics. Voyons comment le faire correctement, dans le prolongement des autres chantiers du SEO technique.

Ce que le balisage change réellement

Deux effets, très différents l’un de l’autre. Le premier est visible : l’affichage enrichi dans les pages de résultats. Une fiche recette qui montre son temps de préparation, un produit qui affiche sa disponibilité, un fil d’ariane qui remplace l’URL brute. Cela ne change pas votre position, mais cela change la surface que vous occupez et l’envie de cliquer.

Le second est invisible et probablement plus durable : la désambiguïsation. En déclarant explicitement qu’une page parle d’une organisation nommée ainsi, située à cette adresse, présente sur ces profils, vous aidez le moteur à relier votre site à une entité connue plutôt qu’à un simple paquet de mots. Pour une entreprise dont le nom est ambigu, c’est loin d’être anecdotique.

Vocabulaire, format, syntaxe : ne pas confondre

Trois notions se superposent souvent dans les discussions, alors qu’elles répondent à des questions distinctes :

• schema.org est le vocabulaire : la liste des types (Article, Product, LocalBusiness…) et de leurs propriétés. C’est un projet collaboratif soutenu par les principaux moteurs.
• JSON-LD, microdonnées et RDFa sont les formats permettant d’exprimer ce vocabulaire dans une page.
• Les résultats enrichis sont ce que chaque moteur décide d’en faire. Google ne prend en charge qu’un sous-ensemble des types existants.

Le JSON-LD est le format recommandé, et pour une bonne raison pratique : il est séparé du HTML d’affichage. Vous pouvez le modifier sans toucher à votre mise en page, et le relire sans le décortiquer au milieu des balises. Les microdonnées, qui s’entremêlent aux attributs HTML, restent valides mais deviennent vite pénibles à maintenir.

Un exemple commenté

Voici un balisage d’établissement local, avec les propriétés qui comptent réellement :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "name": "Atelier Deschamps",
  "url": "https://atelier-deschamps.fr/",
  "telephone": "+33240000000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 rue des Halles",
    "postalCode": "49100",
    "addressLocality": "Angers",
    "addressCountry": "FR"
  },
  "openingHours": "Mo-Fr 08:00-18:00",
  "sameAs": [
    "https://www.exemple-reseau.fr/atelierdeschamps"
  ]
}
</script>

Trois choses à remarquer. Le type choisi est le plus spécifique disponible dans l’arborescence — un plombier plutôt qu’un simple commerce local. La propriété sameAs relie l’entité à ses autres présences en ligne, ce qui renforce la cohérence de l’ensemble. Et toutes les informations déclarées figurent aussi, en clair, sur la page.

Les types qui servent vraiment

Le vocabulaire compte des centaines de types ; une poignée suffit à la plupart des sites :

1. Organization ou LocalBusiness et ses sous-types, sur la page d’accueil ou la page de contact.
2. BreadcrumbList, pour le fil d’ariane — simple à mettre en place et souvent repris à l’affichage.
3. Article, sur les contenus éditoriaux, avec auteur et dates de publication et de modification.
4. Product accompagné d’une offre, pour un catalogue marchand.
5. Event, Recipe, JobPosting ou VideoObject selon la nature du site.

Attention aux types dont le traitement a changé : en août 2023, Google a fortement restreint l’affichage enrichi des questions fréquentes, désormais réservé à un petit nombre de sites institutionnels et de santé, et a supprimé celui des tutoriels pas-à-pas. Le balisage correspondant reste valide et compréhensible par les machines, mais ne comptez plus dessus pour gagner de la place dans les résultats. C’est un bon rappel : un affichage enrichi n’est jamais un acquis.

Les règles à ne pas transgresser

Les données structurées sont l’un des rares domaines du SEO où l’abus expose à une action manuelle explicite. Les interdits sont clairs :

• Baliser ce qui n’est pas visible par l’utilisateur sur la page. Déclarer une note moyenne qui n’apparaît nulle part est une infraction, pas une astuce.
• Décrire un contenu différent de celui de la page : mauvais prix, fausse disponibilité, dates fantaisistes.
• Publier des avis sur soi-même. Les avis rédigés ou commandés par l’entité décrite ne sont pas éligibles aux extraits d’avis pour une organisation ou un commerce.
• Baliser des pages sans rapport, par exemple déclarer chaque page d’un site comme une recette pour tenter d’obtenir un affichage particulier.

La logique sous-jacente est simple et cohérente avec l’ensemble des consignes : le balisage doit décrire la réalité de la page, jamais l’embellir.

Propriétés obligatoires, propriétés recommandées

Chaque type de résultat enrichi distingue des propriétés requises et des propriétés conseillées. L’absence d’une propriété requise rend la page inéligible : l’outil de test parle alors d’erreur. L’absence d’une propriété conseillée génère un simple avertissement, qui n’empêche rien mais réduit la richesse de l’affichage possible.

Deux outils permettent de vérifier. Le test des résultats enrichis de Google se concentre sur l’éligibilité aux affichages qu’il prend en charge. Le validateur de schema.org, lui, contrôle la conformité au vocabulaire en général, sans préjuger de ce que tel moteur en fera. Le second est plus permissif : ne concluez pas à une éligibilité parce qu’il n’a rien signalé.

Une fois en production, les rapports d’améliorations de l’interface de suivi remontent les erreurs constatées à l’échelle du site, ce qui est bien plus utile qu’un test page par page.

Où le placer, et sur quelle version de la page

Le script peut se trouver dans l’en-tête ou dans le corps du document, cela n’a pas d’importance. Ce qui compte, c’est qu’il soit présent dans la page que le robot obtient. Deux précautions concrètes :

D’abord, le balisage doit exister sur la version consultée par un appareil mobile, puisque c’est celle qui alimente l’index. Un JSON-LD injecté uniquement dans le gabarit bureau ne sera jamais lu : c’est l’un des points de contrôle listés dans notre article sur l’indexation mobile-first et le SEO mobile.

Ensuite, les URL déclarées dans le balisage — adresse du site, images, profils associés — doivent pointer vers des ressources servies de manière cohérente avec le reste du site. Déclarer une version non chiffrée alors que tout le site a basculé introduit une contradiction inutile ; notre article sur HTTPS et la sécurité du site détaille les points à harmoniser après une migration.

Ce que ça n’apportera pas

Disons-le nettement pour éviter les déceptions : ajouter du JSON-LD sur un site qui ne se positionne pas ne le fera pas se positionner. Les données structurées n’améliorent pas la pertinence, ne renforcent pas l’autorité, et ne remplacent pas un contenu. Elles agissent sur la présentation et la compréhension, en aval du classement.

Leur meilleur usage est donc opportuniste : les mettre en place quand vous avez déjà des pages qui remontent, pour améliorer leur taux de clic, et sur les types réellement pertinents pour votre activité. Une demi-journée de travail bien ciblée vaut mieux qu’un balisage exhaustif de tout le site.

Questions fréquentes

Sources

• schema.org — Vocabulaire et hiérarchie des types.
• Google Search Central — Introduction aux données structurées et galerie des résultats enrichis.
• Google Search Central — Consignes générales relatives aux données structurées et actions manuelles associées.
• Google Search Central — Annonce de la réduction des résultats enrichis FAQ et HowTo (août 2023).

Article informatif. Le SEO évolue et aucun résultat n’est garanti : privilégiez toujours des pratiques conformes aux consignes de Google.