Schema markup pour Shopify en 2026 : les propriétés JSON-LD que les agents IA lisent réellement

La plupart des guides schema markup pour l'ecommerce sont encore écrits pour Google. Ils listent les huit propriétés Product qui vous donnent les étoiles dans la SERP et s'arrêtent là. Cela a fonctionné pendant dix ans.

Cela ne fonctionne plus en 2026.

Quand un agent IA sur ChatGPT, Copilot ou Google AI Mode évalue s'il doit recommander votre produit, il score sur un jeu de propriétés bien plus large. L'analyse interne de Shopify suggère que les boutiques avec un Product schema complet voient un taux d'inclusion AI shopping significativement plus élevé. Les audits de boutiques inscrites aux Agentic Storefronts mais invisibles dans les surfaces IA trouvent systématiquement le même écart : schema présent, schema maigre.

Ce post est la liste de propriétés que nous utilisons, les règles de validation que nous lançons et le pattern d'implémentation que nous déployons sur Shopify (Liquid et Hydrogen) chez les clients qui livrent du schema AI-aware en 2026. Si vous n'avez pas encore lancé notre audit de visibilité en 10 minutes, faites-le d'abord. Ce post corrige ce que cet audit révèle.

Pourquoi le schema compte plus en 2026 qu'en 2024

Deux hypothèses étaient sûres. Elles ne le sont plus.

La première était que le schema était un nice to have, pas un essentiel. Une page produit bien écrite avec une bonne copy et un H1 propre pouvait se classer sans JSON-LD élaboré. C'est encore partiellement vrai pour la SERP classique de Google, mais ce n'est plus vrai pour les surfaces IA. Les agents IA ne parcourent pas votre page. Ils consomment votre flux et votre schema, scorent le résultat et décident de vous faire remonter ou non. Si les données structurées sont absentes ou maigres, l'agent doit se rabattre sur l'extraction de prose, ce qui est plus lent, moins fiable, et biaisé contre votre produit quand un concurrent a des données plus propres.

La deuxième était que le jeu de propriétés était petit. Schema.org existe depuis plus de dix ans et les mêmes six ou sept propriétés Product (name, description, image, offers, aggregateRating, brand, sku) ont été traitées comme suffisantes. Les agents IA veulent un signal plus riche : matières, dimensions, certifications, pays d'origine, listes d'ingrédients, tranche d'âge, genre cible, notes de coupe, détails de fabrication, allégations de durabilité. L'agent utilise ces données pour décider si votre produit correspond à l'intention de l'acheteur et pour rédiger l'explication qu'il montrera.

La barre pratique en 2026 est d'environ 20 propriétés par produit, avec des extensions spécifiques à la catégorie en plus. En dessous, vous êtes en désavantage structurel face à tout concurrent qui a fait le travail.

Ce que Google exige encore (le socle)

Avant d'aller plus loin, posez le socle correctement. Ces propriétés sont requises (ou fortement recommandées) par Google pour les rich results produit, et elles sont le minimum absolu pour les agents IA aussi.

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "T-shirt en coton bio col rond",
  "image": [
    "https://cdn.yourstore.com/products/tshirt-front.jpg",
    "https://cdn.yourstore.com/products/tshirt-back.jpg"
  ],
  "description": "T-shirt col rond en coton bio, maille épaisse 240 g/m², fabriqué au Portugal. Certifié GOTS. Pré-rétréci. Coupe unisexe.",
  "sku": "TS-ORG-CRW-BLK-M",
  "gtin13": "5012345678900",
  "brand": {
    "@type": "Brand",
    "name": "Votre marque"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://www.yourstore.com/products/tshirt-bio?variant=42",
    "priceCurrency": "EUR",
    "price": "39.00",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "5.00",
        "currency": "EUR"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "FR"
      },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "businessDays": {
          "@type": "OpeningHoursSpecification",
          "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"]
        },
        "transitTime": {
          "@type": "QuantitativeValue",
          "minValue": 2,
          "maxValue": 4,
          "unitCode": "DAY"
        }
      }
    }
  }
}

Trois points sur le socle qui sont régulièrement faux sur les boutiques Shopify que nous auditons.

gtin13 (ou gtin12, gtin14, mpn) est manquant sur environ 60% des boutiques. Le GTIN est la manière dont les agents IA regroupent le même produit chez plusieurs marchands. Sans lui, votre produit apparaît comme un SKU unique pour l'agent, comparé contre tout au lieu d'être comparé contre le même produit chez des concurrents où vous pourriez offrir un meilleur prix ou une livraison plus rapide.

priceValidUntil est souvent omis ou réglé sur une date passée. Google ignore les offres expirées, les agents IA aussi. Réglez-le dynamiquement sur une date à 6 à 12 mois.

shippingDetails est la propriété la plus souvent manquante. Les agents IA pondèrent fortement le coût et le délai de livraison parce que les acheteurs en parlent en conversation. Sans shippingDetails, votre produit est invisible aux requêtes du type "livré en France sous 3 jours" même si c'est exactement ce que vous faites.

Ce que les agents IA lisent en plus (les 12+ nouvelles)

Les propriétés ci-dessous ne sont pas toutes exigées par Google. Plusieurs sont des extensions, certaines sont recommandées seulement, et quelques-unes sont spécifiques à la catégorie. Les agents IA les lisent toutes quand elles sont présentes.

Matière et composition. Utilisez material pour le textile, recipeIngredient pour l'alimentaire, activeIngredient pour les cosmétiques, chemicalComposition pour l'industriel. C'est la propriété la plus souvent manquante et la plus facile à ajouter.

"material": "100% coton bio (certifié GOTS)"

Poids, dimensions et taille. Utilisez weight, height, width, depth et size. Critique pour le mobilier, les catégories sensibles au packaging, et tout ce où l'acheteur demande "est-ce que ça rentre sur une étagère de 60 cm ?"

"weight": {
  "@type": "QuantitativeValue",
  "value": 240,
  "unitCode": "GRM"
},
"size": "Medium (M)"

Couleur et code hex. Utilisez color pour le nom et additionalProperty avec le nom colorHex pour le code. Les noms de couleur sont incohérents d'un marchand à l'autre et le code hex permet aux agents de regrouper de manière fiable.

Pays d'origine. Utilisez countryOfOrigin. De plus en plus important pour les acheteurs qui filtrent par "Made in UE" ou "Made in France".

Manufacturer (quand différent de la marque). Utilisez manufacturer avec name et country. Les boutiques de marque blanche et de revente confondent régulièrement avec la marque ; les agents IA pénalisent l'incohérence.

Audience et cible. Utilisez audience avec audienceType, suggestedAge, suggestedGender. Critique pour le textile et les jouets.

Certifications. Utilisez hasCertification. C'est un ajout schema.org de 2023 et la plupart des boutiques ne l'ont pas encore implémenté. GOTS, B Corp, OEKO-TEX, bio, fair trade, vegan : tout devrait être explicite, pas enterré dans la prose.

"hasCertification": [
  {
    "@type": "Certification",
    "name": "GOTS Organic",
    "issuedBy": { "@type": "Organization", "name": "Global Organic Textile Standard" }
  }
]

Note agrégée et nombre d'avis. Utilisez aggregateRating avec ratingValue, reviewCount, bestRating. Requis si des avis existent. Ne les inventez pas. Les agents IA recoupent les notes contre les grandes plateformes d'avis et un aggregateRating fabriqué endommage le score de confiance sur tout votre catalogue.

Les avis eux-mêmes. Incluez 3 à 5 entrées Review réelles avec author, datePublished, reviewBody, reviewRating. Les agents utilisent la prose pour rédiger l'explication de pourquoi un produit est recommandé.

Scénarios d'usage via additionalProperty. C'est la propriété sous-utilisée qui vous donne le plus gros levier. Chaque additionalProperty est un PropertyValue avec name et value, et vous pouvez en lister autant que vous voulez. Servez-vous-en pour les cas d'usage, les notes de coupe, l'occasion, la saison, l'entretien, les spécifications techniques : tout ce qui est spécifique à la catégorie sans propriété first-class.

"additionalProperty": [
  {
    "@type": "PropertyValue",
    "name": "Cas d'usage",
    "value": "Layering, sport, casual"
  },
  {
    "@type": "PropertyValue",
    "name": "Grammage",
    "value": "240 g/m²"
  },
  {
    "@type": "PropertyValue",
    "name": "Entretien",
    "value": "Lavage à froid, séchage doux, pas de javel"
  },
  {
    "@type": "PropertyValue",
    "name": "Coupe",
    "value": "Taille normale, unisexe"
  }
]

Politique de retour. Utilisez hasMerchantReturnPolicy avec applicableCountry, returnPolicyCategory, merchantReturnDays, returnMethod, returnFees. C'est l'une des trois questions les plus posées aux agents IA. Affichez-la explicitement.

"hasMerchantReturnPolicy": {
  "@type": "MerchantReturnPolicy",
  "applicableCountry": ["FR", "BE", "DE"],
  "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
  "merchantReturnDays": 30,
  "returnMethod": "https://schema.org/ReturnByMail",
  "returnFees": "https://schema.org/FreeReturn"
}

Propriétés énergie et durabilité. Utilisez energyEfficiencyEnumeration pour l'électroménager. Pour les allégations de durabilité plus larges, utilisez additionalProperty en attendant que schema.org rattrape.

Les règles de validation qui comptent vraiment

Un schema qui ment est pire que pas de schema du tout. Les erreurs ci-dessous sont celles que nous voyons le plus souvent en auditant des boutiques Shopify, dans l'ordre approximatif des dégâts.

Devise incohérente. priceCurrency: "USD" alors que le prix proposé est en EUR sur un storefront français. L'agent affiche le mauvais prix ou filtre le produit comme incohérent.

Availability qui ne correspond pas à la réalité. availability: "InStock" alors que la variante a zéro stock. Nous le voyons sur un tiers des boutiques multi-variantes parce que le schema est généré pour le produit maître et pas mis à jour par variante.

priceValidUntil périmé. Date passée. Traité comme expiré.

aggregateRating gonflé ou fabriqué. Le plus courant sur les boutiques qui ont récemment migré d'app d'avis. La nouvelle app a 12 avis mais le schema en annonce 348. Les agents IA recoupent et déclassent.

Erreurs de format GTIN. Mauvaise longueur, caractères alphanumériques dans un GTIN numérique, zéros initiaux supprimés par la sérialisation JSON. Validez en string avec gtin13 etc., pas en nombre.

@id manquant. Chaque Product, Offer et Brand devrait avoir un @id URL stable pour que les agents dédupliquent dans le graph. La plupart des boutiques Shopify l'omettent ; cela coûte en matchabilité.

Blocs JSON-LD dupliqués. Courant sur Shopify quand un thème injecte du schema et qu'une app en injecte aussi. Les deux blocs se contredisent et l'agent choisit le mauvais. Auditez en regardant la source et en comptant les blocs application/ld+json par page.

Passez chaque changement dans le Rich Results Test de Google et le Schema Markup Validator de schema.org. Les deux sont gratuits et attrapent l'essentiel des erreurs avant la mise en prod.

Implémentation sur Shopify (Liquid)

Pour les boutiques sur Shopify classique (thèmes Liquid), l'approche la plus propre est un seul bloc JSON-LD dans theme.liquid qui référence les metafields et metaobjects pour les données que le thème ne possède pas nativement.

{% if template contains 'product' %}
<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "@id": "{{ shop.url }}{{ product.url }}",
  "name": {{ product.title | json }},
  "description": {{ product.description | strip_html | truncatewords: 120 | json }},
  "image": {{ product.images | map: 'src' | json }},
  "sku": {{ product.selected_or_first_available_variant.sku | json }},
  {% if product.metafields.custom.gtin %}
  "gtin13": {{ product.metafields.custom.gtin | json }},
  {% endif %}
  "brand": {
    "@type": "Brand",
    "name": {{ product.vendor | json }}
  },
  {% if product.metafields.custom.material %}
  "material": {{ product.metafields.custom.material | json }},
  {% endif %}
  {% if product.metafields.custom.country_of_origin %}
  "countryOfOrigin": {{ product.metafields.custom.country_of_origin | json }},
  {% endif %}
  "offers": {
    "@type": "Offer",
    "url": "{{ shop.url }}{{ product.url }}?variant={{ product.selected_or_first_available_variant.id }}",
    "priceCurrency": {{ cart.currency.iso_code | json }},
    "price": "{{ product.selected_or_first_available_variant.price | money_without_currency | remove: ',' }}",
    "availability": "https://schema.org/{% if product.selected_or_first_available_variant.available %}InStock{% else %}OutOfStock{% endif %}",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>
{% endif %}

C'est volontairement minimal. Étendez en lisant des metafields supplémentaires pour additionalProperty, les certifications, les avis et la politique de retour. Gardez une seule source de vérité : si votre thème injecte le schema, supprimez tout schema injecté par les apps pour éviter les doublons.

Implémentation sur Hydrogen

Sur Hydrogen et les autres storefronts React headless, le schema est généré dans le loader de route et injecté comme un <script> classique dans la réponse. L'avantage sur Liquid est que vous avez le contrôle programmatique complet sur quelles propriétés rentrent, conditionnelles à la qualité des données.

// app/routes/products.$handle.tsx
export async function loader({ params, context }) {
  const { product } = await context.storefront.query(PRODUCT_QUERY, {
    variables: { handle: params.handle }
  });

  const schema = buildProductSchema(product);
  return { product, schema };
}

function buildProductSchema(product) {
  const schema = {
    '@context': 'https://schema.org/',
    '@type': 'Product',
    '@id': `https://www.yourstore.com/products/${product.handle}`,
    name: product.title,
    description: product.description,
    image: product.images.nodes.map((i) => i.url),
    sku: product.variants.nodes[0]?.sku,
    brand: { '@type': 'Brand', name: product.vendor },
    offers: {
      '@type': 'Offer',
      priceCurrency: product.priceRange.minVariantPrice.currencyCode,
      price: product.priceRange.minVariantPrice.amount,
      availability: product.availableForSale
        ? 'https://schema.org/InStock'
        : 'https://schema.org/OutOfStock'
    }
  };

  const additionalProperty = [];
  for (const field of product.metafields ?? []) {
    if (field?.namespace === 'custom' && field?.value) {
      additionalProperty.push({
        '@type': 'PropertyValue',
        name: field.key,
        value: field.value
      });
    }
  }
  if (additionalProperty.length > 0) {
    schema.additionalProperty = additionalProperty;
  }

  return schema;
}

Rendez le schema dans le composant de route avec dangerouslySetInnerHTML dans une balise <script type="application/ld+json">, ou utilisez un petit helper qui gère la sérialisation proprement.

Que faire cette semaine

Si vous avez une heure : ouvrez trois de vos top produits en view-source, comptez les propriétés JSON-LD, et écrivez la liste de ce qui manque. La plupart des boutiques découvrent qu'elles sont à 6 à 9 propriétés alors qu'elles devraient être à 20+.

Si vous avez une journée : définissez cinq metafields qui couvrent les attributs structurés dont votre catégorie a besoin (typiquement : matière, pays d'origine, poids, certifications, cas d'usage). Remplissez-les pour vos 50 meilleurs SKU. Mettez à jour votre template Liquid ou Hydrogen pour les exposer dans additionalProperty.

Si vous avez une semaine : déployez le schema sur tout le catalogue, corrigez les erreurs de validation les plus courantes ci-dessus, et mettez en place un check automatisé (un script quotidien qui fetch un échantillon de pages produit, parse le JSON-LD, valide contre le jeu de propriétés attendu) pour attraper les régressions quand votre équipe édite les produits.

Nous avons couvert l'architecture metafield qui rend cela scalable dans le Metaobjects et metafields Shopify. Sans cette couche de données, le schema est quelque chose que vous maintenez à la main par produit, sans jamais finir. Avec elle, le schema est une fonction des données structurées et reste correct automatiquement.

FAQ

Faut-il un schema différent pour les agents IA et pour Google ?

Non. Les propriétés que les agents IA lisent sont un sur-ensemble de ce que Google utilise. Un schema complet fonctionne pour les deux. La seule chose à surveiller, c'est que certaines propriétés AI-spécifiques (hasCertification, certains patterns additionalProperty) ne sont pas encore affichées dans les rich results Google, mais elles sont lues par les agents.

Google va-t-il me pénaliser pour des propriétés schema qu'il n'utilise pas ?

Non, tant que les valeurs sont exactes. Schema.org est le standard que Google et les agents IA référencent. Les propriétés que Google ne fait pas remonter actuellement sont ignorées, pas pénalisées.

Comment générer du schema pour les données au niveau variante ?

Le pattern le plus propre est un Product pour le maître avec des références hasVariant, plus un Offer par variante dans le tableau offers. Sur Shopify cela demande d'itérer product.variants dans votre template. La plupart des thèmes livrent un schema maître seulement et ont besoin d'une mise à jour.

Et ProductGroup et isVariantOf ?

ProductGroup est utile pour les boutiques avec de fortes relations de famille entre produits (vêtements en plusieurs couleurs et tailles). Utilisez-le quand chaque variante est vraiment son propre produit, avec une URL unique. Pour la plupart des boutiques Shopify où les variantes partagent une URL, Product avec plusieurs entrées Offer est plus simple et tout aussi efficace.

Faut-il ajouter Organization ou LocalBusiness schema en plus ?

Oui. Un Organization schema sur votre homepage avec name, url, logo, sameAs (vos profils sociaux), et contactPoint donne aux agents IA une entité de marque stable à laquelle rattacher les informations produit. LocalBusiness seulement si vous avez une présence retail physique.

La suite

Le prochain post de cette série, Metaobjects et metafields Shopify, entre dans l'architecture de données qui permet de remplir ce schema à grande échelle sur des milliers de SKU sans édition manuelle par produit.

Si vous voulez que nous auditions votre schema et que nous écrivions le plan d'implémentation, contactez-nous. Pour les catalogues complexes nous lançons généralement un atelier d'une demi-journée avec votre équipe dev, livrons une carte des propriétés par catégorie et livrons l'implémentation Liquid ou Hydrogen en deux semaines.