Données structurées : quels schémas installer sur son site

Quels schémas JSON-LD installer selon votre site (vitrine, e-commerce, blog) : Organization, Product, BreadcrumbList, FAQPage, avec exemples de code et méthode de test.

Un site qui n’a pas de données structurées n’affiche pas d’étoiles, pas de prix, pas de FAQ dépliée dans les résultats Google. Le concurrent juste en dessous, lui, capte le clic. Installer les bons schémas ne fait pas remonter une page dans le classement à lui seul, mais il améliore le taux de clic et donne à Google (et aux moteurs génératifs qui pillent le JSON-LD pour leurs réponses) une lecture fiable du contenu. La question n’est pas « faut-il en mettre » mais « lesquels, où, et avec quel format ». Voici la liste concrète selon le type de site, avec le code à poser.

Le format à utiliser : JSON-LD, jamais microdata

Google recommande JSON-LD depuis des années et c’est le seul format qui a du sens en 2026. Le microdata (attributs itemprop collés dans le HTML visible) oblige à modifier chaque template au risque de casser l’affichage. Le JSON-LD est un bloc <script type="application/ld+json"> injecté dans le <head>, totalement découplé du rendu visuel. On peut le générer côté serveur en fonction du contenu de la page sans toucher au CSS ni au HTML du corps. Sur un site en wordpress sur mesure, ça se fait dans le thème via une fonction qui hook sur wp_head — pas besoin d’un plugin de balisage qui duplique des schémas déjà générés ailleurs, ce qui est l’erreur la plus fréquente que je corrige en audit.

Organization ou LocalBusiness : le socle pour tout site

Ce schéma va sur la page d’accueil, une seule fois. Il déclare l’identité de l’entité derrière le site : nom, logo, adresse si pertinent, réseaux sociaux, moyens de contact. C’est ce qui alimente le knowledge panel et les résultats avec logo dans les snippets. Pour un commerce local (artisan, cabinet, boutique physique), on utilise LocalBusiness (ou une sous-classe comme Restaurant, Dentist) plutôt que Organization générique, car il porte des propriétés en plus : horaires d’ouverture, zone de service, géolocalisation.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Nom de l'entreprise",
  "image": "https://exemple.fr/logo.png",
  "telephone": "+33...",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "...",
    "addressLocality": "Paris",
    "postalCode": "75000",
    "addressCountry": "FR"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00",
    "closes": "18:00"
  }]
}

Product, Offer et AggregateRating pour l’e-commerce

C’est le schéma qui rapporte le plus visuellement : prix, disponibilité et étoiles directement dans les résultats de recherche pour chaque fiche produit. Trois blocs imbriqués sont attendus : Product pour le nom et l’image, offers (type Offer) pour le prix et la disponibilité (InStock, OutOfStock), et aggregateRating pour la note moyenne — mais attention, Google interdit d’afficher une note qui n’existe pas réellement sur la page. Un aggregateRating fictif ou copié d’un autre produit est une violation directe des consignes qualité et peut déclencher une action manuelle sur tout le catalogue.

Sur WooCommerce comme sur PrestaShop, les extensions génériques de SEO génèrent souvent ce balisage de façon approximative : prix HT au lieu de TTC, devise absente, variations de produit non gérées. Sur un catalogue de plusieurs centaines de références, ça vaut le coup de générer ce JSON-LD dynamiquement depuis les données produit réelles plutôt que de laisser un plugin tiers deviner. C’est typiquement le genre de correctif qu’on traite pendant une refonte de site web, en même temps que l’optimisation des Core Web Vitals du catalogue.

Article ou BlogPosting pour le contenu éditorial

Sur un blog ou une page d’actualité, le schéma Article (ou BlogPosting, sa sous-classe) déclare l’auteur, la date de publication, la date de mise à jour et l’image principale. C’est un signal de fraîcheur exploité par Google pour l’affichage de la date dans les SERP et par les agrégateurs. Les champs datePublished et dateModified doivent correspondre à la réalité — les mettre à jour artificiellement à chaque republication sans changement de fond est détecté et pénalisé sur le long terme.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Titre de l'article",
  "datePublished": "2026-08-21",
  "dateModified": "2026-08-21",
  "author": { "@type": "Organization", "name": "WebEngine" },
  "image": "https://exemple.fr/image-article.jpg"
}

BreadcrumbList : petit schéma, gain systématique

C’est le plus simple à mettre en place et celui qui a le taux d’adoption le plus faible par rapport à son coût d’implémentation. Il remplace l’URL brute par le fil d’ariane dans les résultats de recherche (Accueil > Catégorie > Produit au lieu de exemple.fr/cat/prod-123). Sur un site avec une arborescence profonde — un catalogue e-commerce ou une documentation — l’effet sur la lisibilité du résultat est immédiat. Comme il ne dépend que de la structure de navigation, il se génère automatiquement dès que le fil d’ariane HTML existe, sans logique métier supplémentaire.

FAQPage et HowTo : à poser avec prudence

Depuis 2023, Google a restreint l’affichage enrichi de FAQPage aux sites gouvernementaux et institutionnels jugés fiables sur le sujet, et celui de HowTo a quasiment disparu des résultats desktop. Concrètement : le balisage reste valide et ne nuit pas, mais il ne garantit plus le rich snippet qu’il produisait avant. Ça reste pertinent à installer si la page contient réellement des questions-réponses ou des étapes (ça sert aussi les moteurs conversationnels qui citent des sources), mais ce n’est plus une priorité si le temps de développement est compté. Mieux vaut concentrer l’effort sur Product et BreadcrumbList, qui ont un effet SERP mesurable et stable.

Vérifier que le balisage est valide avant de le laisser en prod

Deux outils suffisent. Le Rich Results Test de Google (search.google.com/test/rich-results) simule le rendu et signale les propriétés manquantes ou mal typées. La Search Console, dans la section Améliorations, remonte les erreurs détectées à l’échelle du site après indexation — c’est là qu’on voit apparaître les faux positifs de note produit ou les dates incohérentes sur des centaines de pages en même temps. Un schéma mal formé (JSON invalide, virgule en trop) n’est pas juste ignoré : il peut faire échouer le parsing de tout le bloc <script>, donc aucune des propriétés qu’il contient n’est prise en compte.

Où l’implémenter : dans le thème, pas dans un plugin générique

La tentation est d’installer un plugin « Schema Pro » ou équivalent qui coche toutes les cases. Le problème : ces plugins génèrent souvent des doublons avec ce que le thème ou un plugin SEO (Yoast, Rank Math) produit déjà, et Google ne sait plus lequel prioriser en cas de conflit de valeurs. La solution durable est d’intégrer le JSON-LD directement dans le code du thème, généré à partir des données réelles de chaque page (prix WooCommerce, date de publication WordPress, adresse enregistrée). C’est plus de travail au départ, mais ça élimine la dette technique qui s’accumule quand trois extensions balisent la même page différemment — un problème classique qu’on retrouve sur les sites bâtis à coups de page builders et de plugins empilés, et qui justifie souvent une remise à plat complète du thème.

FAQ

Les données structurées améliorent-elles le classement Google ?

Pas directement. Google l’indique explicitement : le JSON-LD n’est pas un facteur de ranking. Son effet est indirect, via le taux de clic (un résultat avec étoiles ou prix est plus cliqué qu’un résultat nu) et via une meilleure compréhension du contenu par les systèmes d’indexation, ce qui peut influencer la pertinence perçue sur des requêtes ambiguës.

Faut-il baliser toutes les pages du site ?

Non. Organization ou LocalBusiness se pose une fois sur l’accueil. BreadcrumbList et Article/Product se posent sur les pages où ils ont un sens (fiches produit, articles). Baliser une page de contact avec un schéma Product ou coller un FAQPage sur une page qui ne contient pas de questions est inutile et peut être vu comme une tentative de manipulation des résultats.

Un plugin SEO suffit-il ou faut-il du code sur mesure ?

Pour un petit site vitrine avec peu de pages, un plugin SEO correctement configuré suffit largement. Pour un catalogue e-commerce ou un site à fort volume de contenu, générer le JSON-LD depuis les données réelles (prix, stock, dates) dans le thème évite les incohérences que les plugins génériques produisent à l’échelle, et c’est un chantier qui s’intègre naturellement dans une refonte de site ou un développement en WordPress sur mesure.