Pourquoi ajouter des données structurées à une page web

Une page web est lisible par un humain, mais elle reste souvent ambiguë pour un moteur de recherche. Un titre peut désigner un article, une formation, un produit, une personne, une organisation ou un événement. Les données structurées servent à lever cette ambiguïté en décrivant explicitement le rôle des informations présentes dans la page.

Elles ne remplacent pas un bon contenu, une structure HTML correcte ou une stratégie de performance. Elles complètent le document avec une couche sémantique exploitable par les moteurs de recherche, les assistants, les indexeurs et certains outils d’analyse. Dans une stratégie SEO moderne, elles s’inscrivent donc aux côtés de l’optimisation des images, de l’accessibilité et de la qualité technique globale du site. Si vous travaillez déjà sur ces sujets, l’article Optimiser les images web sans sacrifier la qualité constitue un bon complément.

Le format le plus utilisé aujourd’hui est JSON-LD, recommandé par Google pour de nombreux types de données structurées. Il permet d’ajouter un bloc JSON dans la page sans modifier la structure visible du HTML.

Comprendre Schema.org et JSON-LD

Schema.org est un vocabulaire partagé qui définit des types d’objets : Article, Course, Product, Event, Organization, Person, FAQPage, etc. Chaque type possède des propriétés attendues, comme headline, author, datePublished ou image pour un article.

JSON-LD signifie JavaScript Object Notation for Linked Data. Dans une page HTML, il prend généralement la forme suivante :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Données structurées JSON-LD : aider Google à comprendre vos pages",
  "author": {
    "@type": "Person",
    "name": "Julien Dargelos"
  }
}
</script>

Ce bloc n’est pas destiné à être affiché. Il décrit la page pour les machines. L’avantage est important : votre HTML reste propre, votre CSS ne dépend pas de cette couche SEO, et vous pouvez générer ces données depuis votre application, votre CMS ou votre framework.

Exemple minimal pour un article technique

Prenons le cas d’un article de blog technique. Un schéma Article peut inclure le titre, la description, l’auteur, les dates, l’image principale et l’éditeur.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Web Workers en JavaScript : déplacer les calculs lourds hors du thread principal",
  "description": "Apprendre à utiliser les Web Workers pour améliorer la réactivité d’une interface web.",
  "image": "https://example.com/images/web-workers.jpg",
  "datePublished": "2026-06-03",
  "dateModified": "2026-06-03",
  "author": {
    "@type": "Person",
    "name": "Julien Dargelos",
    "url": "https://example.com/auteur/julien-dargelos"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Formation développeur web",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}

Ce type de balisage est particulièrement pertinent pour un site qui publie régulièrement des contenus pédagogiques. Il peut accompagner des articles sur JavaScript, TypeScript, CSS ou React, comme Typage des données API en TypeScript ou React Server Components.

Générer du JSON-LD avec TypeScript

Dans un projet moderne, il est préférable de générer les données structurées depuis une fonction plutôt que de copier-coller des blocs JSON à la main. Cela réduit les erreurs, centralise le format et facilite l’évolution du site.

type ArticleJsonLdInput = {
  title: string;
  description: string;
  url: string;
  imageUrl: string;
  publishedAt: string;
  updatedAt: string;
  authorName: string;
};

export function createArticleJsonLd(article: ArticleJsonLdInput) {
  return {
    "@context": "https://schema.org",
    "@type": "Article",
    headline: article.title,
    description: article.description,
    mainEntityOfPage: {
      "@type": "WebPage",
      "@id": article.url
    },
    image: [article.imageUrl],
    datePublished: article.publishedAt,
    dateModified: article.updatedAt,
    author: {
      "@type": "Person",
      name: article.authorName
    },
    publisher: {
      "@type": "Organization",
      name: "Formation développeur web"
    }
  };
}

Cette fonction peut ensuite être utilisée dans une page Next.js, Nuxt, Astro ou dans un générateur statique. L’idée reste la même : produire un objet fiable, puis l’injecter dans un script application/ld+json.

Intégration dans une page React ou Next.js

Dans React, il faut sérialiser l’objet JSON-LD. Comme React échappe le contenu par défaut, l’injection passe généralement par dangerouslySetInnerHTML. Le nom peut inquiéter, mais il est acceptable ici si les données sont contrôlées et correctement sérialisées.

import { createArticleJsonLd } from "./seo";

type ArticlePageProps = {
  article: {
    title: string;
    description: string;
    url: string;
    imageUrl: string;
    publishedAt: string;
    updatedAt: string;
  };
};

export function ArticleStructuredData({ article }: ArticlePageProps) {
  const jsonLd = createArticleJsonLd({
    ...article,
    authorName: "Julien Dargelos"
  });

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{
        __html: JSON.stringify(jsonLd)
      }}
    />
  );
}

Attention cependant : ne sérialisez jamais directement des champs non maîtrisés sans validation. Si les données viennent d’un CMS ou d’une API externe, vérifiez leur forme. Les principes expliqués dans Typage des données API en TypeScript s’appliquent très bien à ce cas.

Adapter le schéma au type de contenu

Le piège classique consiste à tout déclarer comme Article. Ce n’est pas toujours le bon choix. Une page de formation peut être décrite avec Course, une page d’entreprise avec Organization, une page de profil avec Person, une foire aux questions avec FAQPage, et une fiche produit avec Product.

Pour une formation en développement web, un schéma Course peut être plus précis :

{
  "@context": "https://schema.org",
  "@type": "Course",
  "name": "Formation JavaScript moderne",
  "description": "Cours pratique pour apprendre JavaScript, le DOM, les API web et les bases de l’architecture frontend.",
  "provider": {
    "@type": "Organization",
    "name": "Formation développeur web",
    "sameAs": "https://example.com"
  }
}

Le bon schéma dépend de l’intention réelle de la page. Un article qui présente une formation n’est pas forcément une page Course. Une page de vente de formation, en revanche, peut mériter un balisage plus spécifique.

Bonnes pratiques et erreurs fréquentes

Les données structurées doivent décrire le contenu visible ou réellement accessible de la page. Il ne faut pas ajouter des informations inventées uniquement pour attirer les moteurs de recherche. Si une page ne contient pas de FAQ visible, évitez de déclarer une FAQPage. Si une image n’est pas représentative, ne l’utilisez pas comme image principale.

Autre erreur fréquente : oublier les dates de modification. Pour un site pédagogique, les contenus techniques évoluent vite. Un article sur les APIs web, la performance ou l’architecture frontend peut devenir obsolète. Indiquer dateModified aide à signaler qu’un contenu a été maintenu.

Pensez aussi à la cohérence entre vos balises classiques et vos données structurées. Le title, la meta description, le h1 généré par votre système de publication, l’image Open Graph et le JSON-LD doivent raconter la même chose. Cette cohérence technique participe à la qualité SEO autant que la donnée structurée elle-même.

Tester vos données structurées

Avant de publier, utilisez l’outil Rich Results Test de Google. Il permet de vérifier si votre page est éligible à certains résultats enrichis et de détecter les propriétés manquantes ou invalides.

Vous pouvez aussi inspecter le JSON généré dans le navigateur. Une méthode simple consiste à ouvrir le code source de la page et à rechercher application/ld+json. Le JSON doit être valide, complet et correspondre à la version finale rendue côté serveur ou côté client.

Dans une architecture avec rendu serveur, React Server Components ou génération statique, privilégiez une génération côté serveur lorsque c’est possible. Cela évite que les robots aient à attendre une hydratation JavaScript complexe. Ce raisonnement rejoint les enjeux présentés dans React Server Components : écrire moins de JavaScript côté navigateur.

Conclusion

Les données structurées JSON-LD ne sont pas une astuce magique de référencement. Elles sont une couche de clarification. Elles indiquent aux moteurs de recherche ce qu’est votre contenu, qui l’a écrit, quand il a été publié, quelle image le représente et quel type d’objet il décrit.

Pour un site de formation en développement web, elles sont particulièrement utiles : articles techniques, pages de cours, profils d’intervenants, événements, ressources pédagogiques. Le plus important est de les générer proprement, de les valider et de les maintenir avec le même sérieux que le reste du code frontend.