Chaque page de votre site peut contenir du schema sans que le moteur d’IA comprenne pour autant à quel site cette WebPage appartient, ni qui exploite ce site. Le problème ne vient pas du nombre de balises, mais du fait qu’elles ne se connaissent pas. Décrire Organization, WebSite et WebPage dans trois blocs JSON-LD isolés revient à remettre à la machine trois cartes de visite sans aucun lien entre elles. @graph sert à tracer ce lien clairement, pour que l’IA puisse comprendre d’un seul coup la structure des entités de l’ensemble du site.
Pourquoi des blocs schema dispersés empêchent l’IA de reconstituer votre site
Sur la plupart des sites, les blocs schema sont générés automatiquement par des extensions ou des modèles de CMS : Organization sur la page d’accueil, Article sur les pages éditoriales et Product sur la page tarifaire. Pris séparément, chacun de ces blocs est valide et peut réussir le test des résultats enrichis. La difficulté apparaît lorsque la machine cherche à répondre à la question : « Qui publie cet article, et cette source est-elle digne de confiance ? » Elle ne voit alors qu’une série d’objets sans lien, sans aucun champ lui indiquant que l’éditeur de l’Article est bien l’Organization déclarée sur la page d’accueil. Pour les moteurs de synthèse et de réponse par IA, la possibilité de rattacher un contenu à une organisation réelle et vérifiable pèse largement dans la décision de le citer. Sans cette relation, votre contenu n’est plus identifié comme une information officielle de l’entreprise, mais comme un texte d’origine inconnue.
À quoi sert exactement @graph ?
@graph est une propriété de premier niveau de JSON-LD. Sa valeur est un tableau pouvant contenir plusieurs objets représentant des entités. Il permet de réunir dans un même fichier et un même espace de nommage des entités qui auraient autrement été réparties entre plusieurs balises script. L’essentiel n’est toutefois pas de les « mettre ensemble », mais de leur permettre de se référencer mutuellement à l’aide de @id. Vous déclarez un @id pour Organization, puis vous renseignez exactement le même @id dans la propriété publisher de WebSite : la machine comprend ainsi qu’il s’agit de la même entité, sans qu’il soit nécessaire de recopier tout l’objet Organization. Ce principe — définir une fois, référencer partout — est au fondement des graphes de connaissances. schema.org prend en charge @graph afin qu’une page puisse exprimer les relations entre ses entités, au lieu d’aligner une simple liste d’attributs.
Une seule balise script suffit pour accueillir tout le @graph d’une page. Cela résout au passage un problème ancien : trois extensions qui déclarent chacune la même Organization, avec des attributs contradictoires. Avec @graph, l’entreprise n’apparaît qu’une fois. Elle devient la source de vérité unique pour tout le site, et la maintenance ne nécessite plus de modifier qu’un seul emplacement.
@id : attribuer une adresse stable à chaque entité
@id est la pierre angulaire de toute cette méthode. Il s’agit d’une chaîne d’identification unique à l’échelle du domaine, généralement composée d’une URL suivie d’un fragment, par exemple https://example.com/#organization. Cette valeur n’a pas nécessairement besoin de s’ouvrir dans un navigateur : elle sert d’identifiant, pas de lien. Dès lors qu’une même entité conserve le même @id partout sur le site, l’IA peut regrouper sous un sujet unique les informations dispersées entre différentes pages. Si le même @id apparaît sur la page d’accueil, une page d’article et la page tarifaire, la machine peut rapprocher les descriptions de l’entreprise qui s’y trouvent pour constituer un dossier d’entité plus complet et plus difficile à falsifier.
- Pour Organization, utilisez la racine du domaine suivie d’un fragment, par exemple https://example.com/#organization. Cet identifiant est unique sur tout le site et désigne toujours la même entreprise.
- Pour WebSite, utilisez la racine du domaine suivie de #website afin de représenter le site dans son ensemble.
- Pour la WebPage de chaque page, utilisez « l’URL de la page + #webpage » ; la valeur change donc d’une page à l’autre.
- Fixez la convention de nommage des fragments avec toute l’équipe (#organization, #website, #webpage) : n’écrivez pas #org aujourd’hui puis #company demain.
- Une fois un @id mis en production, ne le modifiez pas sans raison. Le changer revient à créer une nouvelle entité et rompt toutes les associations accumulées jusque-là.
Comment les trois entités se référencent-elles ?
Le sens des relations suit une logique simple : on part de l’élément le plus précis pour remonter vers l’entité principale. WebSite utilise publisher pour pointer vers Organization et indiquer que le site est exploité par cette entreprise. Chaque WebPage utilise isPartOf pour pointer vers WebSite et déclarer qu’elle appartient à ce site. Si une page traite directement de l’entreprise — une page « À propos » ou une page tarifaire, par exemple —, utilisez about ou mainEntity pour la relier à Organization. Sur une page d’article, faites également pointer la propriété publisher de l’Article vers le @id de cette Organization : la relation avec l’éditeur est alors complète.
Un exemple complet directement réutilisable
Placez le @graph suivant dans le <head> de la page. Une seule balise script peut contenir les trois entités : chacune déclare son @id une seule fois, puis utilise @id pour référencer les autres, sans recopier Organization. En pratique, les parties Organization et WebSite sont intégrées à un modèle commun à tout le site et ne sont rédigées qu’une fois. La partie WebPage peut être alimentée dynamiquement avec les propriétés url, name et @id propres à chaque page. { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example company", "url": "https://example.com/", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }, "sameAs": [ "https://www.linkedin.com/company/example", "https://x.com/example" ] }, { "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com/", "name": "Example", "publisher": { "@id": "https://example.com/#organization" } }, { "@type": "WebPage", "@id": "https://example.com/pricing#webpage", "url": "https://example.com/pricing", "name": "Pricing plan", "isPartOf": { "@id": "https://example.com/#website" }, "about": { "@id": "https://example.com/#organization" } } ] }
Les quatre erreurs les plus fréquentes
- Des @id incohérents : la page d’accueil utilise #organization, tandis que la propriété publisher d’une page d’article contient l’URL complète ou omet le fragment après le signe #. La machine les interprète alors comme deux entreprises distinctes.
- Un objet complet à la place d’une référence : tout l’objet Organization est recopié dans publisher. La même entité existe alors en deux exemplaires, dont les attributs risquent de se contredire.
- Des entités isolées : WebPage ne contient pas isPartOf et Article ne contient pas publisher. L’objet est valide sur le plan syntaxique, mais il reste déconnecté de l’entité principale.
- Une URL variable utilisée comme @id : dès qu’une URL comportant des paramètres de suivi ou de session change, une nouvelle entité est créée et toutes les associations repartent de zéro.
Pour inspirer confiance à l’IA, ne multipliez pas les balises : rendez les relations entre les entités suffisamment explicites.
Trois vérifications indispensables avant la mise en ligne
Publier le balisage ne garantit pas qu’il soit correctement mis en œuvre. Commencez par coller tout le @graph dans Rich Results Test ou Schema Markup Validator afin de vérifier qu’aucune erreur de syntaxe n’apparaît. Effectuez ensuite le contrôle que la plupart des équipes oublient : relevez chaque @id référencé et vérifiez, un par un, qu’il est bien défini dans le même graphe. Ne créez aucune référence vers un identifiant inexistant. Enfin, chargez la page dans le navigateur, inspectez le HTML rendu et assurez-vous que le script est réellement présent dans la sortie. De nombreux systèmes SSR ou CMS peuvent le supprimer silencieusement à cette étape. La liaison des entités fait partie des optimisations de GEO technique à fort rendement : elle demande peu d’heures de travail, mais influe directement sur la propension de l’IA à considérer votre site comme une source fiable. Si vous ignorez si vos entités Organization, WebSite et WebPage sont réellement reliées, ou si la relation publisher est rompue, vous pouvez prendre rendez-vous pour un diagnostic GEO de 30 minutes. Nous analyserons concrètement votre HTML rendu et vous indiquerons, relation par relation, ce qui manque.
