Comment optimiser la structure de vos données structurées pour booster votre SEO

La première fois que j'ai mis du JSON-LD sur un site, j'étais fier de moi. Le validateur de Google me renvoyait un gros "Aucun élément détecté" et je ne comprenais pas pourquoi. J'avais pourtant copié le schéma Article depuis la documentation, changé les valeurs, collé dans le <head>. Zéro. Le problème ne venait pas du type de schéma. Il venait de la structure : mon entité Product n'était reliée à rien, mon Article flottait dans le vide, et Googlebot ne savait pas à quelle Organization le rattacher.

C'est là que j'ai compris un truc que la plupart des articles sur le sujet passent sous silence. Les données structurées ne sont pas une question de balises, c'est une question de graphe. Tu ne poses pas des bouts de JSON isolés sur chaque page. Tu construis un réseau d'entités qui se référencent entre elles.

Pourquoi vos données structurées ne produisent rien (et ce n'est pas le type de schéma)

Quand j'ai commencé à auditer des sites il y a quelques années, je posais toujours la même question au client : "Montre-moi ton JSON-LD." Neuf fois sur dix, je tombais sur un bloc Article correct techniquement, avec un headline, un author, une datePublished. Et rien d'autre. Pas de publisher relié à une Organization. Pas de mainEntityOfPage. Aucun lien vers le reste du site.

Résultat : Google validait le schéma, mais ne pouvait pas construire de contexte. Un Article orphelin, c'est un Article que le moteur traite comme une page parmi des millions d'autres.

Le vrai problème : les entités ne se parlent pas

Pense à ton site comme à une base de données relationnelle. Une page d'article, ce n'est pas un objet seul : c'est un Article écrit par une Person qui travaille pour une Organization qui publie sur un WebSite dont la page est une WebPage.

Si tu ne déclares pas ces liens, tu livres à Google une table sans clés étrangères. Il devine. Et quand il devine, il se trompe.

• Une Organization déclarée uniquement sur la page d'accueil ne sera pas rattachée à tes articles.
• Un auteur sans sameAs vers un profil vérifiable (Wikidata, LinkedIn) reste une chaîne de caractères anonyme.
• Un Product sans brand reliée à une entité Organization nommée est un produit orphelin.
• Ton fil d'Ariane, s'il est balisé en BreadcrumbList mais sans item pointant vers des URL réelles, ne sert à rien.
• Le @id de ta WebPage n'existe nulle part ailleurs : aucun autre schéma ne peut l'appeler.

Franchement, la première fois qu'on m'a expliqué ça, j'ai eu un peu honte. J'avais passé des mois à empiler des schémas comme on colle des post-it sur un mur.

La méthode structurelle pour optimiser vos données structurées

Voici le process que j'applique désormais sur chaque site que je touche. Il tient en quatre étapes, dans cet ordre précis. Si tu inverses, tu vas perdre du temps.

Étape 1 : cartographier les entités avant d'écrire une ligne de JSON

Liste à la main, dans un fichier texte, toutes les entités de ton site. Pas les schémas : les choses qui existent. Ton entreprise. Ton site. Une page. Un article. Un produit. Une personne. Une catégorie. Une FAQ.

Pour chacune, note :

1. Le type Schema.org le plus précis possible (pas Thing si Product marche).
2. Un @id stable, sous forme d'URL absolue avec fragment (ex. https://exemple.fr/#organization).
3. Les relations sortantes : de quoi cette entité dépend-elle, et qui dépend d'elle ?

Cette carte mentale, c'est 80 % du boulot. Le JSON n'est que la transcription.

Étape 2 : déclarer les entités racines une fois, les référencer partout

Ton Organization et ton WebSite sont des entités racines. Elles ne changent pas d'une page à l'autre. Tu les déclares avec un @id fixe, et partout ailleurs tu ne fais que référencer cet identifiant.

Sur un site vitrine que j'ai repris l'an dernier, on est passés d'un schéma Organization dupliqué (avec des variations dans le nom, l'adresse, le logo sur chaque page) à un seul bloc @graph par page, avec la même entité Organization référencée par @id. Trois semaines après la mise en ligne, la fiche Knowledge Panel affichait enfin le bon logo et la bonne adresse. Avant, Google affichait une version obsolète qu'il avait pêchée sur une vieille page.

Étape 3 : utiliser @graph pour regrouper au lieu d'empiler

Un <script type="application/ld+json"> par entité, c'est tentant. Mais à partir de trois ou quatre blocs par page, tu perds la vue d'ensemble. Et surtout, tu risques les contradictions : deux blocs qui redéfinissent la même Organization avec des valeurs différentes.

Le conteneur @graph te permet de déclarer plusieurs entités dans un seul objet JSON, chacune avec son @id, et de les relier par référence. C'est le format que Google recommande implicitement depuis des années, et c'est celui que j'utilise par défaut.

Étape 4 : valider avec les bons outils, dans le bon ordre

Deux validateurs, deux usages distincts. Ne les confonds pas.

Outil	Ce qu'il vérifie	Quand l'utiliser
Schema Markup Validator (validator.schema.org)	La syntaxe Schema.org et la cohérence du vocabulaire	En premier, à chaque modification de structure
Test des résultats enrichis (Google)	L'éligibilité aux fonctionnalités Google (rich snippets, etc.)	En second, une fois le schéma stable
Inspection d'URL dans Search Console	L'état réel côté Googlebot après déploiement	Après mise en production, jamais avant
Validateur JSON standard	La validité brute du JSON (virgules, guillemets)	Toujours en premier, avant tout autre contrôle

Le JSON invalide est la cause n°1 des schémas silencieusement ignorés. Une virgule en trop et tout le bloc est jeté sans avertissement dans les résultats enrichis.

Les questions qu'on me pose le plus souvent

Quel outil utiliser pour valider mes données structurées ?

Le Schema Markup Validator de Schema.org pour la conformité au vocabulaire, et le test des résultats enrichis de Google pour l'éligibilité aux affichages enrichis. Ce sont deux choses différentes : un schéma parfaitement valide peut ne rien donner côté Google s'il ne correspond à aucun format pris en charge. Utilise les deux, dans cet ordre.

Comment structurer le schéma Article correctement ?

Un Article utile n'est pas un Article seul. Il doit contenir au minimum : headline, author (référencé par @id si l'auteur existe ailleurs sur le site), datePublished, dateModified, publisher (référence vers ton Organization racine), et mainEntityOfPage (référence vers ta WebPage). Sans ces liens, l'Article reste une île.

Comment baliser un Product sans tomber dans le spam ?

Trois règles. Un : ne déclare que ce qui est visible sur la page (prix, disponibilité, avis). Deux : relie le Product à une brand elle-même typée Brand ou Organization, avec un @id cohérent. Trois : n'utilise pas AggregateRating si tu n'as pas de vrais avis vérifiables. J'ai vu des sites se faire retirer tous leurs rich snippets produits pour ça.

Et le fil d'Ariane, on le balise comment ?

Avec un BreadcrumbList où chaque ListItem contient une position (entier, dans l'ordre), un name (le libellé visible) et un item (l'URL absolue). L'erreur classique : mettre des URL relatives, ou oublier le item sur le dernier élément parce qu'on est déjà dessus. Mets-le quand même. Google s'en sert pour reconstituer la hiérarchie.

Comment relier Organization, WebSite et WebPage entre elles ?

Via @id. Ton Organization a un @id du type https://exemple.fr/#organization. Ton WebSite pointe vers elle avec publisher. Ta WebPage pointe vers le WebSite avec isPartOf. Ton Article pointe vers la WebPage avec mainEntityOfPage et vers l'Organization avec publisher. C'est un arbre, pas une collection.

Ce que les IA génératives changent à la donne

Un truc qu'on ne voyait pas il y a deux ans : les modèles qui alimentent les réponses génératives s'appuient de plus en plus sur le balisage pour identifier qui parle, de quoi, et à quel titre. Un Article correctement relié à une Organization identifiable et à un auteur vérifiable a une meilleure chance d'être cité qu'un Article anonyme.

Ce n'est pas magique, et personne aujourd'hui ne peut prétendre à un lien de causalité prouvé. Mais l'idée derrière est solide : plus ton graphe d'entités est clair, plus une machine — Google ou un LLM — peut t'attribuer une information sans ambiguïté.

Concrètement, ça se traduit par trois priorités :

• Un sameAs propre vers tes profils officiels sur chaque entité Person ou Organization. Un lien mort ou un compte abandonné plombe la confiance.
• Une cohérence NAP (nom, adresse, téléphone) entre le balisage et le contenu visible. Google ne pardonne pas les écarts.
• Des dates dateModified à jour. Une page modifiée depuis six mois mais dont le balisage affiche encore 2023, c'est un signal de négligence.

Et le pire dans tout ça ? Beaucoup de sites balisent à moitié, valident vite, puis n'y touchent plus jamais. Le balisage est un organe vivant. Il se met à jour quand ton site évolue.

Le piège que j'ai mis deux ans à comprendre

Pendant longtemps, j'ai cru qu'optimiser les données structurées consistait à choisir le bon type. Article pour un article. Product pour un produit. Évident, non ?

Sauf que ce n'est jamais ça le problème. Le type, tu le trouves en trois clics dans la doc. La difficulté, c'est la structure relationnelle entre ces types. Un Article qui ne pointe vers rien, un Product sans brand identifiable, une Organization dupliquée sur quinze pages avec des micro-variations : voilà ce qui tue ton balisage en silence.

Si tu ne devais retenir qu'une chose de cet article, c'est celle-là : pense en graphe avant de penser en balises. Le JSON ne fait que transcrire une carte que tu dois avoir en tête. Et si cette carte est floue, aucun validateur ne te sauvera.

La prochaine fois que tu ouvres le Schema Markup Validator et que tout est vert, pose-toi une question différente : est-ce que chaque entité de cette page sait à qui elle appartient ? Si la réponse est non, tu n'as pas fini.