Schema Markup : guide pratique des données structurées pour le SEO

En bref : le schema markup est un code, le plus souvent un script JSON-LD, qui décrit une page avec le vocabulaire schema.org afin que les moteurs de recherche sachent exactement ce qu'elle contient : un produit et son prix, un article et son auteur, une entreprise et son adresse. Dans Google, il rend les pages éligibles aux résultats enrichis (prix, étoiles d'avis, fil d'Ariane), mais il ne les garantit pas et n'est pas un levier de classement. Plusieurs résultats enrichis ont été supprimés, dont la FAQ en mai 2026 : balisez donc ce que Google prend encore en charge, gardez un balisage identique à ce que voient les visiteurs et testez-le avant et après chaque modification de template.

La plupart des sites qui "ont du schema" souffrent de l'un de ces deux problèmes : un balisage ajouté il y a des années pour un résultat enrichi que Google n'affiche plus, ou un thème, un plugin et une application qui ajoutent chacun leur propre bloc, avec des données contradictoires. Ce guide présente ce que font aujourd'hui les données structurées, les types qui méritent votre temps en octobre 2026, du JSON-LD prêt à copier et une routine de test.

Qu'est-ce que le schema markup

Schema.org est un vocabulaire partagé pour décrire des éléments du web, fondé par Google, Microsoft, Yahoo et Yandex et maintenu comme projet communautaire. Il définit des types (Product, Article, LocalBusiness, Event) et les propriétés que chaque type peut avoir (price, author, address, startDate). Schema.org indique qu'en 2024, plus de 45 millions de domaines web l'utilisent.

"Données structurées" est le terme général pour désigner des informations dans un format fixe que les machines lisent sans avoir à deviner. Le "schema markup" désigne des données structurées écrites avec le vocabulaire schema.org. En pratique, les deux termes sont employés indifféremment.

Sans balisage, un moteur de recherche lit "32 $" près du mot "mug" et en déduit que c'est probablement un prix. Avec balisage, la page l'affirme : il s'agit d'un Product nommé "Speckled Stoneware Mug", proposé à 32,00 USD, en stock. L'introduction aux données structurées de Google décrit ainsi leur finalité : Google utilise les données structurées pour comprendre le contenu d'une page, et elles peuvent permettre des résultats de recherche plus attrayants pour les utilisateurs.

JSON-LD, Microdata et RDFa

Google Search prend en charge trois formats. Tous expriment le même vocabulaire ; ils diffèrent par l'endroit où se trouve l'information.

Google indique qu'en général, il recommande JSON-LD si la configuration de votre site le permet. Utilisez JSON-LD pour tout nouveau balisage. Si votre plateforme produit déjà du Microdata correct, il n'y a aucune raison de le réécrire, mais n'ajoutez pas par-dessus un bloc JSON-LD qui décrit le même élément différemment.

Ce que font les données structurées, et ce qu'elles ne font pas

Elles rendent les pages éligibles aux résultats enrichis. Les résultats enrichis sont les affichages de recherche améliorés : prix et disponibilité d'un produit, étoiles d'avis, fil d'Ariane à la place d'une URL brute, miniatures de vidéos, dates d'événements. La documentation de Google comprend des études de cas où les résultats enrichis ont amélioré le taux de clics, par exemple Rotten Tomatoes, qui a mesuré un taux de clics supérieur de 25 % sur les pages avec données structurées.

Elles ne garantissent rien. Les consignes générales sur les données structurées de Google précisent que Google ne garantit pas que vos données structurées apparaîtront dans les résultats de recherche. Un balisage valide rend une page éligible ; Google décide ensuite, requête par requête, si le résultat enrichi est utile.

Ce n'est pas un raccourci pour le classement. Google présente les données structurées comme un moyen de comprendre le contenu et de se qualifier pour des fonctionnalités de recherche. Le signal le plus clair est la façon dont il traite les abus : une action manuelle liée aux données structurées fait perdre à une page son éligibilité aux résultats enrichis, et Google affirme qu'elle n'affecte pas le classement de la page dans la recherche web.

Elles aident à lever les ambiguïtés. Selon la documentation Organization de Google, le balisage Organization aide Google à comprendre vos informations administratives, à distinguer votre organisation des autres, et peut influencer le logo affiché dans les résultats de recherche et les panneaux de connaissances.

Quels résultats enrichis Google prend encore en charge (octobre 2026)

Google réduit la liste depuis trois ans. Un balisage écrit pour une fonctionnalité supprimée n'est pas nuisible, mais c'est de la maintenance inutile, et certains plugins en génèrent encore par défaut.

Fonctionnalités supprimées ou restreintes

Lorsque Google a supprimé le champ de recherche des sitelinks, il a indiqué qu'il n'était pas nécessaire de retirer le balisage, car des données structurées non prises en charge ne posent pas de problème dans la recherche. La même logique vaut pour les autres : nettoyez-les à la prochaine intervention sur le template, sans paniquer.

Types utiles pour la plupart des sites

La galerie de résultats de recherche, mise à jour en octobre 2026, répertorie les fonctionnalités que Google prend actuellement en charge. Voici celles que la plupart des entreprises peuvent utiliser :

La galerie couvre aussi les offres d'emploi, les jeux de données, les forums de discussion, les pages de questions-réponses, les pages de profil, les films, les locations de vacances, les contenus payants et quelques autres. Deux règles de la documentation valent la peine d'être connues avant de commencer : les événements uniquement en ligne ne sont pas éligibles aux résultats enrichis Event, qui exigent un lieu physique, et l'affichage des avantages et inconvénients est réservé aux avis produits éditoriaux, pas aux pages marchandes.

Exemples JSON-LD prêts à copier

Chaque bloc se place dans <script type="application/ld+json"> dans le HTML de la page, généralement dans le head. Remplacez chaque valeur par vos vraies données, et ne balisez que ce que la page affiche réellement.

Organization (page d'accueil)

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Copperleaf Ceramics",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo-512.png",
  "description": "Handmade stoneware mugs, plates and bowls, shipped across the United States.",
  "email": "[email protected]",
  "sameAs": [
    "https://www.instagram.com/example",
    "https://www.linkedin.com/company/example"
  ]
}

Google recommande de placer le balisage Organization sur la page d'accueil ou sur une seule page décrivant l'organisation, et non sur chaque page. Ses consignes sur le logo demandent une image d'au moins 112×112 pixels, explorable, indexable et lisible sur fond blanc. sameAs accepte les URL d'autres sites qui vous décrivent, comme des profils sociaux ou d'avis. Google mentionne aussi des identifiants tels que vatID et iso6523Code pour les organisations qui en disposent.

LocalBusiness (page d'établissement)

{
  "@context": "https://schema.org",
  "@type": "Bakery",
  "name": "North Street Bakery",
  "url": "https://www.example.com/locations/north-street",
  "telephone": "+1-555-010-0199",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "120 North Street",
    "addressLocality": "Springfield",
    "addressRegion": "IL",
    "postalCode": "62701",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.80172,
    "longitude": -89.64371
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "07:00",
      "closes": "18:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "08:00",
      "closes": "14:00"
    }
  ]
}

Le guide Google sur les entreprises locales demande le sous-type le plus précis disponible (Bakery, Dentist, HealthClub) plutôt que LocalBusiness tout court, une latitude et une longitude avec au moins cinq décimales, un numéro de téléphone avec indicatif pays et régional, et un priceRange de moins de 100 caractères. Gardez des informations identiques à celles de votre fiche Google Business Profile ; notre guide d'optimisation de la fiche Google Business Profile traite de cet aspect.

Product avec une offre (merchant listing)

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Speckled Stoneware Mug, 12 oz",
  "image": [
    "https://www.example.com/images/mug-1x1.jpg",
    "https://www.example.com/images/mug-4x3.jpg",
    "https://www.example.com/images/mug-16x9.jpg"
  ],
  "description": "Wheel-thrown stoneware mug with a speckled glaze. Dishwasher safe.",
  "sku": "MUG-SPK-12",
  "brand": {
    "@type": "Brand",
    "name": "Copperleaf Ceramics"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.com/shop/speckled-mug",
    "price": "32.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "14"
  }
}

Le guide des merchant listings exige name, image et un objet offers avec price et priceCurrency (un code ISO 4217 à trois lettres). Il recommande la disponibilité, l'état, la marque, un GTIN lorsqu'il existe, les informations de livraison et une politique de retour. La définition de price sur schema.org demande un nombre simple avec un point comme séparateur décimal, et la devise dans priceCurrency plutôt qu'un "$" dans la valeur. Pour une promotion, Google documente désormais validFrom avec validThrough ou priceValidUntil pour définir la période de promotion. Google indique aussi que l'envoi à la fois d'un balisage sur la page et d'un flux Merchant Center maximise l'éligibilité aux expériences Shopping.

Article (billet de blog)

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Care for Handmade Stoneware",
  "image": ["https://www.example.com/images/stoneware-care-16x9.jpg"],
  "datePublished": "2026-09-14T08:00:00+00:00",
  "dateModified": "2026-10-02T09:30:00+00:00",
  "author": [
    {
      "@type": "Person",
      "name": "Maya Lindqvist",
      "url": "https://www.example.com/about/maya"
    }
  ],
  "publisher": {
    "@id": "https://www.example.com/#organization"
  }
}

Le guide Article n'a aucune propriété requise et recommande author, les dates, headline et image. Ne mettez que le nom de la personne dans author.name, sans titre ni "publié par", et donnez à chaque auteur une entrée distincte. Ici, publisher pointe vers le bloc Organization via son @id, de sorte que les deux décrivent une seule entité reliée plutôt que deux entités sans lien.

BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Shop",
      "item": "https://www.example.com/shop"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Mugs",
      "item": "https://www.example.com/shop/mugs"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Speckled Stoneware Mug"
    }
  ]
}

Selon le guide du fil d'Ariane, un fil doit comporter au moins deux éléments, le dernier peut omettre item (Google utilise alors l'URL de la page elle-même), et le fil doit suivre le chemin qu'emprunte un utilisateur typique pour arriver à la page, et non refléter les dossiers de vos URL.

Relier les blocs dans un seul graphe

Une page décrit souvent plusieurs éléments : la page, l'organisation qui la publie, un produit, le fil d'Ariane. Les consignes de Google indiquent qu'il comprend plusieurs éléments sur une page, qu'ils soient imbriqués ou spécifiés séparément, et que vous pouvez relier des blocs distincts avec @id. De nombreuses installations WordPress le font déjà : Yoast SEO, par exemple, produit un seul @graph dans lequel WebPage, WebSite, Organization ou Person, Article et BreadcrumbList sont des nœuds distincts qui se référencent par @id.

Deux règles pratiques en découlent. Donnez à votre Organization un @id stable et référencez-le partout au lieu de répéter les informations. Et balisez l'élément principal de la page, un Product ou une Recipe, en plus des éléments secondaires comme un VideoObject, comme le demandent les consignes de Google.

Schema markup et recherche IA

Beaucoup de conseils prétendent que le schema est la clé des réponses de l'IA. Les recommandations de Google sur les fonctionnalités d'IA et votre site web sont claires : il n'existe aucune donnée structurée schema.org spéciale à ajouter pour apparaître dans les AI Overviews ou en AI Mode, et vous n'avez pas besoin non plus de nouveaux fichiers lisibles par machine. Parmi les bonnes pratiques qu'il énumère figure celle de s'assurer que vos données structurées correspondent au texte visible sur la page.

Les autres assistants n'ont pas non plus publié d'exigences de balisage. Ce que les données structurées font de façon fiable, c'est lever l'ambiguïté : un balisage Organization avec un nom, un logo et des profils sameAs cohérents indique à quelle entité appartient un site, et un balisage Product ou SoftwareApplication indique ce que vous vendez et à quel prix. C'est utile à tout système qui lit la page, ce qui explique pourquoi la vérification du balisage d'identité fait partie de notre AI search readiness checker. Considérez-le comme de l'hygiène, pas comme un levier. Les leviers des réponses IA, comme l'accès des robots d'exploration et les mentions par des tiers, sont traités dans notre guide sur le generative engine optimization, et la mesure des résultats dans AI visibility tracking.

Comment tester les données structurées

Utilisez trois outils, pour trois questions différentes.

1. Rich Results Test : "Est-ce éligible à un résultat enrichi Google ?" Il indique quels types de résultats enrichis il a trouvés, avec erreurs et avertissements, et teste par défaut en mode smartphone. Utilisez la saisie par URL plutôt que du code collé lorsque votre balisage est généré en JavaScript ; le guide JavaScript de Google indique que Google traite les données structurées présentes dans le DOM rendu, mais que la saisie de code a des limites.
2. Schema Markup Validator : "Est-ce du schema.org valide ?" Google a déplacé en 2021 son ancien Structured Data Testing Tool vers schema.org, sous forme de validateur général sans contrôles propres à Google. Utilisez-le pour les types que Google n'affiche pas en résultats enrichis, comme les détails d'Organization au-delà du logo.
3. Rapports sur les résultats enrichis de la Search Console : "Est-ce que ça fonctionne sur l'ensemble du site ?" Des rapports apparaissent pour les types pris en charge dès que Google trouve du balisage. Les éléments valides peuvent s'afficher en résultats enrichis ; ceux qui présentent des problèmes critiques ne le peuvent pas tant qu'ils ne sont pas corrigés. Après une correction, utilisez Validate fix pour que Google réexamine les pages concernées.

Une précaution sur JavaScript : Google note que le balisage Product généré dynamiquement peut rendre les explorations Shopping moins fréquentes et moins fiables, ce qui compte pour des prix et des stocks qui changent vite. Placez le balisage produit dans le HTML rendu côté serveur lorsque c'est possible.

Erreurs courantes

Exemple concret : corriger la fiche produit d'une boutique (hypothétique)

L'exemple suivant est hypothétique, il ne s'agit pas de données réelles. Copperleaf Ceramics, une boutique en ligne fictive sur une plateforme e-commerce populaire, constate que ses pages produits affichent de simples liens bleus alors que ses concurrents montrent prix et stock dans les résultats. Un audit de la page du mug révèle :

Les corrections ont pris un après-midi :

1. Désactivation du balisage produit du thème et configuration de l'application d'avis pour qu'elle ajoute sa note dans un seul bloc Product, à partir des données d'avis en direct.
2. Réécriture de l'offre : "price": "32.00", "priceCurrency": "USD", ajout de availability et itemCondition, et définition de la période de promotion avec validFrom et priceValidUntil pendant les promotions.
3. Ajout de trois formats d'image.
4. Ajout du balisage Organization sur la page d'accueil avec logo et sameAs, référencé depuis les pages produits par @id.
5. La section FAQ est restée visible, car les clients la lisent, et son balisage n'est plus considéré comme une fonctionnalité de recherche.
6. Exécution du Rich Results Test sur cinq URL de produits, puis suivi du rapport merchant listing de la Search Console pendant les semaines suivantes : les éléments invalides sont tombés à zéro à mesure que Google réexplorait les pages.

La boutique ne peut pas forcer l'affichage du résultat enrichi, mais chaque page est désormais éligible, et rien n'y contredit ce que voient les acheteurs.

Mettre en place le schema sur les plateformes courantes

• WordPress. Yoast SEO et Rank Math produisent Organization ou Person, WebSite, WebPage, Article et BreadcrumbList une fois les réglages de représentation du site renseignés. WooCommerce ajoute le balisage Product. Vérifiez l'absence de doublons lorsqu'un thème ou un autre plugin ajoute le sien.
• Shopify. Les thèmes produisent généralement le balisage produit, souvent via le filtre Liquid structured_data, qui transforme un produit en Product schema.org, ou en ProductGroup lorsqu'il a des variantes, et un article en Article. Les applications d'avis peuvent ajouter un second bloc ; vérifiez le code source de la page.
• Sites sur mesure et frameworks. Générez le JSON-LD côté serveur à partir des mêmes données que celles qui servent à afficher la page, pour que prix et stock ne puissent jamais diverger.
• Générateurs de schema markup. Pratiques pour des blocs ponctuels comme Organization. Pour les prix, notes ou dates, une sortie statique devient obsolète ; générez-la depuis vos données.

Une checklist schema de 30 minutes

1. Lancez le schema markup checker gratuit sur votre page d'accueil et vos pages clés pour voir quels types JSON-LD chacune déclare et si elle comporte un balisage d'identité Organization ou LocalBusiness avec sameAs.
2. Lancez le Rich Results Test sur une page par template : accueil, produit ou service, article, établissement.
3. Classez chaque type trouvé comme pris en charge, supprimé ou non éligible aux résultats enrichis, et supprimez les doublons.
4. Renseignez les propriétés requises des types que vous conservez.
5. Comparez chaque valeur balisée avec la page visible : prix, note, horaires, dates.
6. Vérifiez aussi les balises de partage social ; les mêmes modifications de template les cassent souvent.
7. Revérifiez dans la Search Console deux à quatre semaines plus tard.

Comment Searvia vérifie vos données structurées

Le schema markup checker gratuit utilise le même moteur que notre website SEO checker : il lit le JSON-LD dans le HTML de la page que vous saisissez (votre page d'accueil si vous ne saisissez qu'un domaine), liste les types qu'il trouve, vérifie la présence d'un balisage d'identité Organization, LocalBusiness ou Person et de liens sameAs, et recherche du contenu de type question-réponse, parmi les 38 contrôles au total. Dans l'application, l'audit de site explore vos pages chaque semaine, enregistre les types de schema de chacune et signale une page d'accueil sans données structurées, ainsi que les titres, les pages cassées et les problèmes de sitemap. Pour une vision d'ensemble de ce qu'il faut vérifier et dans quel ordre, consultez notre guide d'audit SEO technique.