Faut-il vraiment dupliquer votre balisage JSON-LD sur toutes vos pages ?

Pourquoi Google fait-il cette distinction entre types de balisage ?

La logique de Google repose sur la nature même de l'information encodée. Les données organisationnelles (Organization schema) décrivent une entité unique : votre entreprise, son logo, son nom officiel, ses coordonnées. Ces informations ne changent pas d'une page à l'autre.

À l'inverse, un balisage Recipe ou Product décrit un contenu spécifique à une URL précise. Chaque recette a ses propres ingrédients, temps de cuisson, note utilisateur. Google doit pouvoir associer ces métadonnées structurées à la page exacte qui les contient pour générer un résultat enrichi pertinent.

Quelles données entrent dans la catégorie "organisationnelle" ?

Concrètement, on parle des schémas qui identifient votre entité juridique ou éditoriale : Organization, LocalBusiness, Corporation, Brand. Ces balises définissent qui vous êtes, pas ce que vous publiez.

Elles incluent typiquement : nom légal, logo, slogan, réseaux sociaux, adresse du siège, numéro de contact principal. Tout ce qui figure sur votre page "À propos" ou votre fiche Google Business Profile. Une seule occurrence suffit, généralement sur la homepage ou une page dédiée.

Qu'est-ce qui relève du balisage contextuel obligatoire sur chaque page ?

Tout ce qui décrit le contenu unique d'une page spécifique : Recipe, Product, Article, Event, JobPosting, FAQPage, HowTo, VideoObject, Review. Google ne peut pas deviner qu'une recette page 47 hérite des métadonnées de votre homepage.

Sans ce balisage local, vous perdez l'éligibilité aux rich snippets pour cette URL précise. Un ProductSchema absent sur une fiche produit = pas d'étoiles ni de prix dans les SERP, même si votre site a un balisage Organization parfait ailleurs.

• Organization/LocalBusiness : une fois sur le site, généralement homepage
• Recipe, Product, Article, Event : obligatoire sur chaque page concernée
• BreadcrumbList : sur chaque page pour indiquer la position hiérarchique
• WebSite/SearchAction : une fois, typiquement sur la homepage
• FAQPage, HowTo : uniquement sur les pages contenant effectivement ce type de contenu

Cette règle s'applique-t-elle strictement à tous les types de sites ?

La distinction de Mueller est solide pour les sites éditoriaux classiques et les e-commerces. Un blog culinaire avec 500 recettes n'a aucun intérêt à dupliquer son Organization schema 500 fois. Un shop Shopify avec 10 000 produits doit en revanche injecter un ProductSchema sur chaque fiche.

Là où ça devient flou : les sites multi-entités. Un annuaire de restaurants avec une fiche LocalBusiness par établissement. Un portail immobilier avec un balisage RealEstateAgent par agence. Dans ces cas, le balisage "organisationnel" devient contextuel. [À vérifier] : Google n'a jamais clarifié si un site agrégeant 1000 LocalBusiness doit toutes les baliser ou peut se contenter d'un Organization général.

Quels sont les risques d'une duplication excessive du balisage Organisation ?

Dupliquer inutilement l'Organization schema sur 10 000 pages ne casse rien techniquement. Google ignore simplement les occurrences redondantes. Mais vous polluez votre code pour rien, vous alourdissez vos templates, et vous compliquez la maintenance.

Plus embêtant : si vous avez des variations (un logo différent sur certaines pages, une adresse légèrement différente), vous créez des signaux contradictoires. Google ne sait plus quelle version est la source de vérité. J'ai vu des sites perdre leur Knowledge Panel à cause d'incohérences entre 3 versions d'un Organization schema éparpillées sur le domaine.

Dans quels cas cette logique peut-elle être contournée ?

Certains types hybrides posent question. Un Article avec un embedded VideoObject ou Recipe. Techniquement, le VideoObject devrait être imbriqué dans l'Article schema de la page, pas déclaré deux fois. La règle de Mueller reste valable : le balisage principal (Article) doit être sur la page qui héberge le contenu.

Autre zone grise : les pages hub ou landing catégories e-commerce. Une page /cuisine/robots-patissiers liste 40 produits. Faut-il 40 ProductSchema ou un seul ItemList ? Les deux approches fonctionnent, mais ItemList est plus cohérent avec la logique de Mueller : un balisage qui décrit la page, pas chaque élément individuel.

Comment auditer rapidement votre déploiement de balisage actuel ?

Première étape : crawlez votre site avec Screaming Frog ou Oncrawl en activant l'extraction des JSON-LD. Exportez la liste des types de schema détectés par URL. Filtrez sur "Organization" : si vous avez 5000 occurrences pour 5000 pages, vous avez un problème de duplication inutile.

Deuxième vérification : utilisez le Rich Results Test de Google sur un échantillon de pages (homepage, fiche produit, article de blog, page catégorie). Notez quels types de rich snippets sont éligibles. Si votre Organization apparaît partout mais que vos Recipe ne sont pas détectées, vous avez inversé les priorités.

Quelle architecture de déploiement adopter pour respecter cette logique ?

Centralisez votre Organization schema sur une seule page de référence, idéalement la homepage ou une page /a-propos dédiée. Injectez-le via un script JSON-LD dans le de cette URL uniquement, pas dans un template global.

Pour les balises contextuelles (Product, Recipe, Article), créez des templates conditionnels par type de page. Votre CMS doit injecter automatiquement le bon schema en fonction du content type : WooCommerce génère ProductSchema sur les single-product.php, Yoast injecte Article sur les posts WordPress, etc. Validez que chaque template inclut tous les champs obligatoires (image, name, description minimum).

Faut-il maintenir un balisage Organisation minimal sur toutes les pages malgré tout ?

Non, mais vous devez maintenir un lien sémantique via la propriété publisher. Un Article schema doit pointer vers votre Organization via son champ "publisher". Un Product peut référencer le "brand" ou "manufacturer" avec un nested Organization.

Cette approche satisfait Google sans dupliquer le gros du balisage. Vous déclarez une fois l'entité complète (logo, sameAs, contactPoint) sur une URL canonique, puis vous la référencez par @id dans vos balises contextuelles. C'est plus propre, plus maintenable, et conforme à la spec Schema.org.

• Auditez votre site pour identifier les duplications inutiles d'Organization schema
• Centralisez ce balisage sur une seule page de référence (homepage ou /about)
• Créez des templates conditionnels pour injecter Recipe/Product/Article uniquement sur les pages concernées
• Utilisez les propriétés "publisher" ou "brand" pour référencer votre Organisation depuis les balises contextuelles
• Testez chaque type de page avec Rich Results Test pour valider l'éligibilité aux snippets enrichis
• Documentez votre architecture de balisage pour faciliter la maintenance future