Données structurées Drupal : guide JSON-LD

Les moteurs de recherche lisent vos pages, mais ils ne les comprennent pas aussi finement qu’un humain. Un titre, un prix, une date de publication, un fil d’Ariane : tout cela est visible à l’écran, mais reste ambigu pour une machine qui parcourt du HTML. Les données structurées comblent cet écart. Elles décrivent explicitement le sens de votre contenu dans un format que Google, Bing et les autres exploitent directement. Sur un site Drupal, cette description s’ajoute proprement, sans toucher au rendu visuel. Elle ouvre l’accès aux rich snippets qui font la différence dans les résultats de recherche.

Pour un décideur, l’enjeu est simple : à positionnement égal, une page qui affiche des étoiles d’avis, une FAQ déroulante ou un fil d’Ariane attire plus de clics qu’un résultat texte classique. Les données structurées ne remplacent pas une bonne stratégie de contenu, elles l’amplifient. Ce guide explique ce qu’est JSON-LD, pourquoi ce format s’est imposé, quels types schema.org apportent le plus de valeur sur un site Drupal, comment les implémenter proprement et comment valider le résultat avant la mise en production.

JSON-LD : qu’est-ce que c’est et pourquoi c’est important

Le principe. Les données structurées sont un vocabulaire standardisé, défini par schema.org, qui décrit le sens des entités présentes sur une page : une organisation, un article, une question fréquente, un produit, un événement. JSON-LD (JavaScript Object Notation for Linked Data) est le format recommandé par Google pour exprimer ce vocabulaire. Concrètement, c’est un bloc de code JSON injecté dans le <head> ou le <body> de la page, totalement invisible pour le visiteur.

Pourquoi ce format plutôt qu’un autre. Il existe plusieurs syntaxes pour exposer des données structurées (microdata, RDFa, JSON-LD). JSON-LD a un avantage décisif : il est découplé du HTML visible. Vous n’avez pas à parsemer vos balises de attributs itemprop, le bloc de données vit à part. C’est plus simple à maintenir, plus lisible et moins fragile lors d’une refonte du thème. Google recommande explicitement JSON-LD depuis plusieurs années.

Ce que ça change concrètement. Deux bénéfices principaux. D’abord les rich snippets : les résultats enrichis qui affichent des étoiles, des prix, des FAQ déroulantes, des fils d’Ariane ou des images directement dans la page de résultats. Ensuite la compréhension sémantique : en déclarant explicitement votre organisation, vos auteurs, vos contenus, vous aidez les moteurs à construire une représentation fiable de votre site. Cela alimente le Knowledge Graph et renforce votre présence dans les réponses générées par les moteurs modernes.

Les données structurées sont un pilier du SEO technique Drupal, au même titre que la performance, le maillage interne ou la gestion des URLs canoniques. Elles ne se substituent à aucun de ces fondamentaux, elles s’ajoutent au socle pour en tirer le meilleur.

Les types les plus utiles pour un site Drupal

Schema.org définit des centaines de types. En pratique, quelques-uns couvrent l’essentiel des besoins d’un site éditorial ou institutionnel sous Drupal.

Organization. Décrit votre entité : nom, logo, URL, profils sociaux, coordonnées. À déclarer une fois, généralement sur toutes les pages ou au moins la page d’accueil. C’est la base de votre identité aux yeux des moteurs et l’un des signaux du Knowledge Graph.

Article (et BlogPosting). Pour vos contenus éditoriaux : titre, auteur, dates de publication et de modification, image principale, éditeur. Indispensable pour un blog ou une section actualités et facteur de visibilité dans Google Discover et Actualités.

FAQPage. Pour les pages qui présentent une liste de questions et réponses. Bien implémentée, elle peut afficher les questions directement dans les résultats de recherche, ce qui augmente la surface occupée par votre lien et la probabilité de clic.

BreadcrumbList. Décrit le fil d’Ariane de la page. Google l’utilise pour remplacer l’URL brute par un chemin de navigation lisible dans les résultats. Simple à mettre en place et applicable à pratiquement tout le site.

D’autres types méritent attention selon votre contexte : Product et Offer pour le e-commerce, Event pour un agenda, LocalBusiness pour un établissement physique, Person pour les pages auteurs. Le bon réflexe est de cartographier vos types de contenu Drupal et d’associer à chacun le type schema.org pertinent, plutôt que de tout baliser sans discernement.

Exemples de code JSON-LD

Voici à quoi ressemblent les types les plus courants. Ces blocs s’insèrent dans une balise <script type="application/ld+json">.

Organization, à placer sur la page d’accueil ou en global :

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Votre Organisation",
  "url": "https://www.exemple.com",
  "logo": "https://www.exemple.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/votre-organisation",
    "https://twitter.com/votreorganisation"
  ]
}

Article, pour une page de blog :

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Titre de l'article",
  "image": "https://www.exemple.com/images/article.jpg",
  "datePublished": "2026-11-03T08:00:00+01:00",
  "dateModified": "2026-11-03T08:00:00+01:00",
  "author": {
    "@type": "Person",
    "name": "Nom de l'auteur"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Votre Organisation",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.exemple.com/logo.png"
    }
  }
}

FAQPage, pour une page de questions fréquentes :

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Quels types de contenu Drupal peut-on baliser ?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Tous : articles, pages, produits, événements et types custom."
      }
    },
    {
      "@type": "Question",
      "name": "Faut-il un module pour générer le JSON-LD ?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Le module Schema.org Metatag automatise la génération, mais un template custom reste possible."
      }
    }
  ]
}

BreadcrumbList, pour le fil d’Ariane :

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Accueil",
      "item": "https://www.exemple.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blogue",
      "item": "https://www.exemple.com/blogue/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Données structurées Drupal"
    }
  ]
}

Comment les implémenter sur Drupal

Deux grandes approches existent et elles se combinent bien.

Le module Schema.org Metatag. C’est la voie la plus directe. Adossé au module Metatag (déjà présent sur la majorité des sites Drupal soignés), il génère automatiquement le JSON-LD à partir de vos champs. Vous mappez un type de contenu à un type schema.org (par exemple le type de contenu Article vers Article), puis vous associez chaque champ à la propriété correspondante (field_image vers image, field_auteur vers author). Le module produit ensuite le bloc JSON-LD sur chaque nœud, en intégrant les valeurs réelles de chaque page. L’avantage est la maintenabilité : la configuration est exportable, versionnée et cohérente sur tout le site.

Les templates custom. Pour les cas particuliers ou pour un contrôle fin, vous pouvez générer le JSON-LD directement, soit dans un preprocess via hook_page_attachments() ou hook_node_view(), soit dans une twig avec attach_library. Cette approche convient quand la structure des données ne correspond pas exactement au mapping standard ou quand vous devez agréger des données de plusieurs sources. Elle demande plus de rigueur : c’est à vous de garantir la validité du JSON et la cohérence avec le contenu affiché.

La stratégie recommandée. Couvrir le gros du site avec Schema.org Metatag (Organization, Article, BreadcrumbList) et réserver les templates custom aux types qui sortent du cadre. Pour le fil d’Ariane, le module sait s’appuyer sur le système de breadcrumb de Drupal, ce qui évite de dupliquer la logique de navigation. Quel que soit le chemin retenu, gardez une règle absolue : les données structurées doivent refléter exactement ce que voit le visiteur. Déclarer un contenu absent de la page est considéré comme du spam structuré et peut entraîner une pénalité manuelle.

Valider avant de publier

Un JSON-LD invalide ne produit aucun rich snippet et une erreur silencieuse peut passer inaperçue pendant des mois. La validation n’est pas optionnelle.

Rich Results Test de Google. L’outil officiel teste une URL en production ou un extrait de code et indique quels résultats enrichis sont éligibles, avec les erreurs et avertissements détaillés. C’est le test de référence pour savoir si une page peut réellement déclencher un rich snippet. À utiliser systématiquement avant chaque mise en ligne d’un nouveau type de balisage.

Schema Markup Validator. Hébergé par schema.org, il valide la conformité du balisage au vocabulaire, sans se limiter aux types qui génèrent des rich snippets chez Google. Utile pour vérifier la justesse sémantique complète, y compris les types que Google n’affiche pas en résultat enrichi.

La Search Console. Une fois en production, le rapport sur les résultats enrichis de la Google Search Console suit dans le temps les types détectés, les erreurs et les pages affectées. C’est votre tableau de bord de suivi continu : il signale les régressions après une mise à jour ou une refonte. Intégrer cette vérification à votre cycle de maintenance garantit que le balisage reste valide à mesure que le site évolue.

En résumé

Les données structurées sont un levier à fort rapport valeur/effort : invisibles pour le visiteur, elles enrichissent vos résultats de recherche et clarifient votre contenu aux yeux des moteurs. Sur Drupal, le module Schema.org Metatag couvre l’essentiel des besoins de façon maintenable et les templates custom prennent le relais sur les cas spécifiques. La discipline de validation, via le Rich Results Test, le Schema Markup Validator et la Search Console, garantit que le balisage reste fiable dans la durée.

Pour aller plus loin sur les fondamentaux qui entourent le balisage (performance, indexation, maillage), mon guide SEO technique Drupal replace les données structurées dans une stratégie d’ensemble. Une approche cohérente combine ces deux dimensions plutôt que de les traiter isolément.

Vous voulez implémenter ou auditer les données structurées de votre site Drupal ? Parlons de votre projet et définissons ensemble le plan adapté à vos types de contenu.