Le graphe de ton WordPress : @id, sameAs, auteur et organisation

Tu sais combien d'organisations ton WordPress présente à Google ? Une seule, j'espère. C'est en tout cas ce que tu crois avoir réglé le jour où tu as tapé le nom de ta boîte et choisi son logo dans ton extension SEO.

Début novembre 2026, j'ai donné la formation dont je te parle au chapitre 1, trois jours sur le SEO par les entités. Sous la diapo qui explique l'@id, mes notes d'orateur disaient ceci. « Erreur fréquente des plugins SEO : chaque page déclare une "nouvelle" organisation sans @id commun. Résultat : dix organisations au lieu d'une. »

Le genre de phrase que je répète de formation en formation. Encore fallait-il que je vérifie qu'elle tient debout sur les extensions d'aujourd'hui !

Alors on a ressorti le labo. WordPress 7.1.3, le thème Twenty Twenty-Five et les quatre grandes extensions SEO, activées une à une, aux mêmes versions que dans le chapitre 3 du dossier SEO WordPress. Ce chapitre-là mesurait leurs réglages d'origine, je n'y reviens pas. Ici, on a configuré chaque extension pour de vrai, avec une organisation, puis avec une personne, et on a suivi chaque identifiant sur quatre pages (l'accueil, un article, la page d'auteur et la page « À propos »). Le chapitre 2 t'a donné la langue, le JSON-LD de schema.org. Celui-ci regarde ce que ton WordPress raconte vraiment avec.

Je te préviens, c'est le chapitre le plus technique du dossier. Allez, on y va !

3.1Un graphe, ce sont des @id qui se répondent

Tu te souviens de l'identifiant unique, la première des quatre parties d'une entité au chapitre 1 ? Dans le JSON-LD, il s'appelle @id.

Je te propose une image. Pense au numéro de dossier que te donne ta mutuelle. Tu changes d'adresse, de téléphone, de banque, et le dossier reste le même. Toute personne qui cite ce numéro parle de toi, sans hésitation possible.

Un @id, c'est ça.

La norme JSON-LD 1.1 du W3C le définit comme ce qui identifie de façon unique un nœud du graphe, avec une adresse de type IRI (une URL, pour faire simple). Et un nœud qui ne contient qu'un @id n'est qu'un renvoi vers un nœud décrit ailleurs dans le document.

Concrètement, tu décris ton organisation une seule fois, avec son nom, son logo et ses profils. Partout ailleurs, son @id suffit.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Exemple",
      "sameAs": ["https://www.linkedin.com/company/1234/"]
    },
    {
      "@type": "Person",
      "@id": "https://example.com/#/schema/person/camille",
      "name": "Camille Exemple",
      "worksFor": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Article",
      "headline": "Mon article",
      "author": { "@id": "https://example.com/#/schema/person/camille" },
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

L'article ne recopie pas le nom de l'organisation ni celui de Camille, mais il pointe vers eux.

Et le moteur additionne au lieu de deviner.

L'@id ressemble à une adresse web, mais personne ne te demande d'y publier une page. Le plus souvent, il se termine par un dièse suivi d'un nom (#organization), ce qui le distingue de l'adresse de la page elle-même.

Attention, la comparaison est bête et méchante. La norme RDF du W3C l'écrit noir sur blanc, deux IRI sont égales si et seulement si leurs caractères sont identiques, et on ne doit rien normaliser avant de les comparer. https://example.com/#organization et https://example.com#organization, ce sont donc deux entités.

Un slash de différence !

Google est peut-être plus tolérant que la norme. Sa documentation ne le dit pas, et franchement, je ne parierais pas mon site là-dessus.

Dernière chose, et elle compte. Une même entité garde le même @id partout où elle apparaît, mais rien ne l'oblige à apparaître partout. Pour l'organisation, Google recommande de la décrire sur ta page d'accueil ou sur une page qui la présente, comme la page « À propos », et précise que tu n'as pas besoin de la mettre sur chaque page de ton site.

Ce que je cherche, ce n'est pas la répétition, mais la cohérence.

3.2Organisation ou personne ? Le réglage de chaque extension

Les quatre extensions commencent par la même question. Ton site représente-t-il une organisation ou une personne ? Ce choix décide de tout le reste, du type de l'entité jusqu'au champ d'où viendront tes profils.

Ma règle est simple. Un blog perso, un portfolio, un consultant qui signe de son nom, c'est une personne. Une boutique, une agence, une association, c'est une organisation. Et le freelance qui a monté sa marque ? Là, honnêtement, ça se discute. Je choisirais l'entité que les clients cherchent par son nom.

J'ai relevé dans la documentation de chaque extension où se cache ce réglage.

Chemins et libellés relevés au labo le 6 novembre 2026, dans l'administration en français. Champs de profils vérifiés dans le code de chaque extension.

Je vois déjà deux pièges. Chez Rank Math, tout passe par le module SEO local. Chez The SEO Framework, par deux interrupteurs, celui des données structurées et celui de la « présence autorisée ». Un module éteint, et ton réglage ne sort jamais dans le code !

Au labo, après l'assistant de Rank Math, le module SEO local était éteint. Rank Math déclarait quand même le site, sous le double type Person et Organization, avec le nom du site. Chez The SEO Framework, les deux interrupteurs étaient allumés d'origine.

Le second piège concerne SEOPress. Sa documentation décrit déjà la version 10.4 (l'image de la personne, l'adresse e-mail publique, un graphe unique en option), alors que le labo tourne en 10.3. Ce qu'on a mesuré vaut pour la 10.3, pas pour sa documentation du jour.

Et pour distinguer ton organisation de ses homonymes ? Au chapitre 1, je t'avais promis la réponse. Google la donne dans sa documentation sur les organisations. Certaines propriétés y servent « en coulisses » à distinguer ton organisation des autres, et il cite deux exemples, iso6523 et naics.

Le premier (iso6523Code dans sa liste de propriétés) est un identifiant à la norme ISO 6523, en deux morceaux. D'abord un code qui désigne le registre utilisé, 0060 pour le DUNS, 0088 pour le GLN ou 0199 pour le LEI dans les exemples de Google, puis le numéro lui-même. Le second, naics, c'est le code de la classification des industries d'Amérique du Nord. Pour une PME de Provence, avouons que ça parle moins !

Note bien que ce n'est pas sameAs que Google désigne pour ce rôle. sameAs relie ton entité à ses autres identités sur le web, c'est sa définition sur schema.org, et il a sa partie à lui dans ce chapitre.

Au labo, on a rempli ces champs avec des valeurs de test. Rank Math est le seul à sortir iso6523Code et naics dans le JSON-LD, depuis les détails de l'organisation de son SEO local. Yoast affiche bien « ISO 6523 » et « SCIAN » (le nom français du NAICS), mais réservés à sa version Premium, et rien n'est sorti. SEOPress et The SEO Framework n'ont aucun des deux.

3.3Le même @id sur l'accueil, l'article et la page d'auteur ?

Retour à ma phrase de formation. Pour la vérifier, on a relevé dans le code de chaque page tous les blocs JSON-LD, puis l'@id de l'organisation, celui du site (le nœud WebSite) et celui de l'auteur.

« Absente » quand la page ne décrit pas l'organisation. Chaque @id commence par l'adresse du site, et chaque page n'a qu'une organisation. Labo, 6 novembre 2026.

Bonne nouvelle, ma phrase de formation est fausse, du moins pour ces quatre-là, aux versions du labo. Aucune ne fabrique dix organisations, chacune garde un seul @id sur toutes les pages où elle décrit l'organisation (SEOPress, lui, ne la décrit que sur l'accueil). Le doublon, quand il existe, vient d'ailleurs, et on va le provoquer exprès dans la partie sur ce qui casse.

Je simplifiais, je l'avoue.

Avant même la mesure, j'étais sûr d'une chose, chaque extension écrit son @id à sa façon. La spécification de Yoast décrit l'organisation principale en #/schema/Organization/1, alors que son propre exemple de code pour une personne renvoie à une constante nommée ORGANIZATION_HASH. The SEO Framework annonce #/schema/Organization dans sa documentation. Au labo, c'est la constante qui gagne. Yoast écrit #organization, sa valeur dans le code, comme Rank Math et SEOPress. The SEO Framework, lui, tient parole, #/schema/Organization. Et pour l'auteur, Yoast écrit #/schema/person/ en minuscules, suivi d'une empreinte, là où sa spécification annonce #/schema/Person/.

Conséquence pratique, change d'extension, et ton organisation change de numéro de dossier. Ce que Google fait de l'ancien, sa documentation ne le dit pas. Je n'en ferais pas une maladie, mais c'est une raison de plus de ne pas changer d'extension SEO parce qu'un tuto te l'a conseillé ;)

3.4L'auteur, relié à sa personne

Place à l'auteur. Pour Google, un auteur bien balisé, c'est d'abord un nom, et rien d'autre, dans author.name. Pas de fonction, pas de formule. Ensuite, sa documentation sur les articles recommande vivement un type et une propriété url (ou sameAs), avec un lien vers une page qui identifie l'auteur de façon unique. Son profil sur un réseau social, sa page « À propos », une page de biographie. Et si cette page est sur ton site, Google conseille de la baliser comme une page de profil.

Dans WordPress, cette page existe déjà, c'est l'archive de l'auteur, /author/ton-identifiant/. Au chapitre 3 du dossier SEO, je te conseillais d'en faire une vraie page, avec ton parcours et tes articles. On va plus loin. Elle doit aussi dire aux machines « cette page parle de cette personne-là ».

Et là, j'ai découvert que les documentations ne racontent pas la même histoire.

Celle de Yoast prévoit sur une archive d'auteur une page de profil (ProfilePage, ou CollectionPage et ProfilePage à la fois), et une propriété mainEntityOfPage qui relie la personne à sa page. Celle de The SEO Framework annonce une CollectionPage, comme pour toutes les archives. Rank Math range bien un ProfilePage dans ses données, ses propres exemples de filtres le montrent. Quant à SEOPress, au labo, réglages d'origine, il ne décrivait même pas l'article !

Labo, 6 novembre 2026. Le site web du profil WordPress était l'adresse de ma page d'auteur d'Inside da WeB.

Un détail qui me fâche, mesuré au chapitre 3 du dossier SEO. Réglages d'origine, Rank Math et SEOPress mettent l'archive d'auteur en noindex. Or la documentation de Google sur les pages de profil demande justement de vérifier que la page n'est bloquée ni par le robots.txt, ni par une balise noindex. Si ta page d'auteur doit servir de référence, je te conseille de la rendre indexable.

Maintenant, le cas qui m'intéresse le plus, parce que c'est le mien. Sur un blog perso, la personne derrière le site et l'auteur des articles, c'est la même. Une seule entité, donc un seul @id, non ?

On a refait le tour avec le site déclaré comme une personne, l'auteur de l'article. Yoast n'en fait qu'une, la personne du site et l'auteur portent le même @id, sous le double type Person et Organization. SEOPress décrit la personne sur l'accueil seulement, et toujours pas d'auteur.

Rank Math et The SEO Framework, eux, en fabriquent deux. Rank Math déclare la personne du site en #person et l'auteur en /author/labo/, deux @id pour le même humain, sur l'article, la page d'auteur et la page « À propos ». The SEO Framework fait pareil sur l'article, #/schema/Person d'un côté, #/schema/Person/ suivi d'une empreinte de l'autre. Et sur l'accueil, il ajoute même une Organization… à mon nom.

C'est le doublon de ma formation, en version humaine !

3.5Les sameAs, tes autres identités

sameAs, c'est la propriété qui relie ton entité à ses autres identités sur le web. En clair, elle dit « c'est la même chose que ». Et là, schema.org et Google ne la décrivent pas tout à fait de la même façon.

Pour schema.org, c'est l'URL d'une page de référence qui indique sans ambiguïté l'identité de la chose, par exemple sa page Wikipédia, sa fiche Wikidata ou son site officiel. Pour Google, dans sa documentation sur les organisations, la porte est plus large. C'est une page d'un autre site qui contient des informations supplémentaires sur ton organisation, comme un profil sur un réseau social ou un site d'avis.

La règle que je te conseille, c'est la règle stricte. Un sameAs, c'est une page qui parle de la même entité, et d'elle seule. Pour une personne, ton profil LinkedIn à toi, ton profil WordPress.org, ta fiche Wikidata si elle existe. Pour une organisation, sa page entreprise sur LinkedIn, sa fiche Wikidata. En formation, c'était d'ailleurs l'une des erreurs que je guettais pendant les présentations, une personne dont le sameAs pointe vers la page de son entreprise. Ce lien-là existe en schema.org, il s'appelle worksFor.

Pas sameAs !

Et Wikidata ? Si ta fiche existe, mets-la, c'est à mon avis le meilleur sameAs qui soit, un identifiant que d'autres bases lisent déjà. Si elle n'existe pas (c'est mon cas, on l'a vu au chapitre 1), ne force pas la porte. Wikidata demande qu'une entité puisse être décrite par des sources sérieuses et publiques. Ce n'est pas un annuaire où l'on s'inscrit soi-même.

Reste à savoir où tes extensions acceptent ces adresses. Pour une organisation, Yoast et Rank Math ont un champ libre (« autres profils », « profils supplémentaires »). The SEO Framework propose une liste fixe, Facebook, X, Instagram, YouTube, LinkedIn, Pinterest, TikTok, SoundCloud et Tumblr d'après sa documentation de 2026. Pas de Wikidata, pas de WordPress.org. Pour ceux-là, il faudra passer par le filtre.

Au labo, on a glissé une adresse WordPress.org et une fiche Wikidata dans chaque champ libre. Côté organisation, Yoast, Rank Math et SEOPress les ont sorties toutes les deux dans sameAs. Côté auteur, seul Rank Math a un champ libre, et les deux adresses sont sorties sur l'article.

Yoast n'offre à l'auteur que sa liste de réseaux, mais il verse le champ « Site web » de son profil dans ses sameAs, Rank Math aussi. Quant à The SEO Framework 5.1.4, sa liste fixe compte huit réseaux, TikTok n'y est pas encore.

Et le profil mort ? Une page Facebook supprimée, un compte X abandonné depuis des années... Le lien reste dans ton balisage, lui. On a fait l'essai avec une adresse qui répond 404. validator.schema.org l'affiche comme n'importe quel sameAs, sans erreur ni avertissement. Le test des résultats enrichis de Google, lui, n'y trouve que le fil d'Ariane, sans aucune organisation, donc rien sur ce sameAs non plus. Le seul contrôle qui marche, à ma connaissance, c'est de les ouvrir, un par un.

3.6La page « À propos », ta page de référence

Pour moi, une entité a besoin d'une page qui la décrit, en clair, pour les humains. C'est là que tout se recoupe. Google la cite trois fois dans les documentations qu'on vient de croiser. Pour l'organisation, comme l'endroit où décrire ton entreprise. Pour l'auteur, comme une adresse valable dans author.url. Et pour les pages de profil, où « une page "À propos de moi" sur un blog » figure parmi les cas valides.

Que doit-elle contenir ? Ce que ton balisage affirme, ni plus, ni moins. Google le répète dans ses consignes générales, on ne balise pas un contenu que le lecteur ne voit pas. En formation, la règle de réussite du TP tenait en une ligne. « Chaque ligne du JSON-LD a sa phrase justificative sur la page. » Ton nom, ton activité, ta ville, et des liens visibles vers tes profils, ceux-là mêmes que tu as mis en sameAs.

Côté extensions, Yoast te laisse choisir le type de chaque page dans son onglet Schema, dont « About Page » et « Profile Page ». Rank Math te fait désigner ta page « À propos » dans ses réglages de SEO local, et promet de la baliser en conséquence.

Au labo, sans réglage, la page « À propos » est un simple WebPage chez Yoast et The SEO Framework, sans lien vers l'organisation. Rank Math y ajoute un Article et son auteur, comme sur n'importe quelle page, et SEOPress n'y met rien.

Avec le réglage, Yoast en fait une AboutPage ou une ProfilePage selon ton choix, et seule la seconde crée un lien, l'organisation reçoit un mainEntityOfPage vers la page. Rank Math, page désignée dans son SEO local, la passe en AboutPage, sans la relier à l'organisation. SEOPress et The SEO Framework n'ont pas de réglage pour ça.

Et sur un site de personne, faut-il une page « À propos » et une page d'auteur ? Deux pages de profil pour un seul humain, ça en fait une de trop à mon goût. Je garderais celle qui a le plus de contenu, et je ferais pointer l'autre vers elle. Pour ce qui me concerne, la page de référence n'est même pas sur ce blog ! Dans le fichier qui décrit mon entité pour tous mes sites, c'est la page « À propos » de mon site perso, et ma page d'auteur d'Inside da WeB figure parmi mes sameAs. Les deux pages portent d'ailleurs le même @id de personne dans leur balisage, et chacune affiche un lien vers l'autre.

3.7Ce qui casse

Maintenant, ma partie préférée. On a cassé exprès !

L'organisation en double

Le scénario classique. Ton extension déclare ton organisation, et ton thème, ton constructeur de pages ou un bout de code copié depuis un générateur en ajoute une seconde, avec son propre @id. Ou deux extensions SEO restent actives le temps d'une migration. On l'a fait au labo, une seconde Organization au même nom et à un autre @id, à côté de celle de Yoast. validator.schema.org compte alors deux organisations, sans erreur ni avertissement. Le test des résultats enrichis de Google, lui, ne trouve que le fil d'Ariane, et aucune organisation, ni une ni deux.

The SEO Framework écrit dans sa documentation que, si deux sources se contredisent sur une même propriété, les moteurs retiennent la première. C'est sa lecture, Google ne documente rien de tel. La mienne est plus simple.

Une entité, une seule source.

Un slash de différence

La règle du W3C, deux IRI égales au caractère près, je voulais la voir à l'œuvre. On l'a mise à l'épreuve. Le 6 novembre 2026, on a passé chaque bloc dans le JSON-LD Playground (json-ld.org/playground, onglet N-Quads), chaque bloc collé à part, puis on a comparé les sujets des triplets. Avec http://127.0.0.1:8090#organization, sans le slash, on obtient deux organisations distinctes. Celle de Yoast garde son nom, son url, son logo, son image et ses sameAs, l'autre n'a que son nom, et le publisher du WebSite ne pointe que vers la première.

La seconde reste orpheline.

Avec l'@id exact, il n'en reste qu'une, qui porte tout, plus la description venue du second bloc.

L'auteur « admin »

La spécification de Yoast contient une règle que j'adore. Si le nom d'une personne est « admin », ou son équivalent dans une autre langue, l'entité doit être écartée, parce qu'on ne présente jamais un contenu comme écrit par « admin ». Or WordPress prend l'identifiant de connexion comme nom affiché tant que tu n'as rien changé. Tu vois le problème si ton identifiant, c'est « admin » ? On l'a vérifié. Un utilisateur créé sans prénom ni nom s'affiche bien sous son identifiant. Avec un utilisateur « admin », Yoast, Rank Math et The SEO Framework ont tous publié une Person nommée « admin », auteur de l'article. SEOPress, qui ne décrit pas l'article, n'en dit rien.

Yoast compris, malgré sa propre règle !

Les avis sans avis visibles

Dernier classique, les étoiles. Là-dessus, Google est très clair ! Si l'entité contrôle les avis qui la concernent, une page balisée en Organization ou en LocalBusiness n'a pas droit aux étoiles, même quand les avis viennent d'un widget intégré. Et on ne balise jamais des avis que le lecteur ne voit pas. The SEO Framework assume d'ailleurs de ne pas proposer ce balisage du tout, parce qu'il est trop souvent détourné, et je trouve ça plutôt sain. Au labo, aucune des quatre n'a posé de Review ni d'AggregateRating, dans aucun des relevés du labo.

3.8Ajouter une propriété qui manque, par le filtre de ton extension

Tôt ou tard, il te manquera une propriété. Mon principe est simple, le réglage d'abord, le filtre ensuite.

Si un champ existe dans ton extension, utilise-le. Je garde le code pour ce qu'elle ne sait pas faire, parce qu'un bout de PHP oublié dans un coin, c'est le genre de chose qu'on redécouvre trois mises à jour plus tard, en cherchant pourquoi une propriété apparaît deux fois.

J'ai pris un exemple tout bête, foundingDate, la date de création de ton organisation. Google la range parmi les propriétés qu'il reconnaît pour une organisation, au format de date ISO 8601. Au labo, Rank Math (dans son SEO local) et SEOPress (dans son Knowledge Graph) proposent déjà ce champ, et la date sort telle quelle. Yoast l'affiche, réservé à Premium.

Chaque extension a son filtre, et chacune le documente. Je n'ai rien inventé, le code ci-dessous vient de leur documentation officielle, réduit à l'essentiel. Il se colle dans un fichier PHP du dossier wp-content/mu-plugins/, comme les quatre lignes du chapitre 3 du dossier SEO. Un fichier, et seulement celui de l'extension que tu utilises. La date, bien sûr, c'est la tienne.

<?php
add_filter( 'wpseo_schema_organization', 'change_organization_schema', 11, 2 );

function change_organization_schema( $data, $context ) {
	$data['foundingDate'] = '2009-09-01';
	return $data;
}

<?php
add_filter( 'rank_math/json_ld', function( $data, $jsonld ) {
	if ( isset( $data['publisher'] ) ) {
		$data['publisher']['foundingDate'] = '2009-09-01';
	}
	return $data;
}, 99, 2 );

<?php
function sp_get_json_data_organization( $jsonld ) {
	$jsonld['foundingDate'] = '2009-09-01';
	return $jsonld;
}
add_filter( 'seopress_get_json_data_organization', 'sp_get_json_data_organization', 10 );

<?php
add_filter(
	'the_seo_framework_schema_graph_data',
	function ( $graph, $args ) {
		foreach ( $graph as &$entity ) {
			if ( in_array( 'Organization', (array) ( $entity['@type'] ?? [] ), true ) ) {
				$entity['foundingDate'] = '2009-09-01';
				break;
			}
		}
		return $graph;
	},
	10,
	2,
);

Deux précisions, pour être franc, parce que je ne veux pas te faire croire que tout sort tel quel de la documentation. La documentation de Rank Math donne le filtre, et sa base de connaissances montre que l'organisation vit sous la clé publisher. L'exemple les assemble, sur le modèle des réponses de son support. Et l'exemple officiel de The SEO Framework ajoute une vidéo à la page. J'ai gardé sa mécanique (parcourir le graphe, viser un type), en visant l'organisation.

Petite surprise, enfin, dans l'exemple complet de Yoast. Il décrit le fondateur en ligne, avec un nom et un profil, mais sans @id. On l'a collé tel que publié. Sur l'article, le graphe compte alors deux Person, l'auteur avec son @id, et le fondateur, Joost de Valk, en ligne, sans @id. Au passage, l'exemple remplace l'url de ton organisation par celle de Yoast, et il écrit un avertissement PHP dans le journal d'erreurs à chaque page, sur un site qui n'a pas le type de contenu yoast_employees qu'il compte.

Mets ton nom à la place de Joost de Valk, et tu viens de fabriquer un doublon de toi-même avec le code de la documentation :D Le fondateur doit pointer vers l'@id de ta personne, celui que ton extension donne déjà à l'auteur, pas être redécrit en ligne.

3.9Vérifier, avec validator.schema.org et le test des résultats enrichis

Deux outils, deux rôles. Le test des résultats enrichis de Google te dit ce que Google retient pour ses propres fonctionnalités. Le Schema Markup Validator, à l'adresse validator.schema.org, vérifie ton balisage par rapport à schema.org, sans l'avis de Google. C'est l'héritier de l'ancien outil de test des données structurées, que Google a refocalisé puis confié à la communauté schema.org en 2021.

Pour ton graphe, c'est le second que je regarde en premier. Le premier montre surtout les types qui donnent droit à un affichage spécial. Au labo, avec les quatre extensions réglées en organisation, validator.schema.org n'a trouvé ni erreur ni avertissement, sur l'accueil comme sur l'article, et une seule organisation à chaque fois. Le test des résultats enrichis, lui, ne montre l'organisation sur aucune page. Il trouve le fil d'Ariane chez Yoast et The SEO Framework, l'article chez Yoast et Rank Math, et rien du tout sur l'accueil de Rank Math ni sur celui de SEOPress. C'est pour ça qu'il ne voit ni le profil mort, ni le doublon.

Voici le contrôle que je te propose, dix minutes chrono.

1. validator.schema.org, ta page d'accueil. Colle son adresse, puis note chaque entité, son type et son @id.
2. Un article, puis ta page d'auteur. Même chose, et compare les @id ligne à ligne. Une seule organisation, un seul toi.
3. Tes sameAs. Ouvre-les tous. Chacun doit répondre, et parler de la bonne entité.
4. Le test des résultats enrichis. Passe l'accueil et l'article, pour voir ce que Google en retient.
5. Une IA, pour dessiner le graphe. Colle tes blocs JSON-LD avec le prompt ci-dessous, puis vérifie sur schema.org chaque propriété qu'elle cite.

Voici les blocs JSON-LD de trois pages de mon site.
[BLOC 1]
[BLOC 2]
[BLOC 3]
1. Liste les entités et leurs @id.
2. Liste les relations (sujet, propriété, objet).
3. Les blocs se contredisent-ils ?
4. Une propriété schema.org existe-t-elle vraiment
   pour chaque relation ? Donne le lien schema.org de chacune.

La question 4 n'est pas là pour faire joli !

En préparant la formation, j'avais noté que Gemini invente parfois des propriétés qui n'existent pas dans schema.org. Je préfère le savoir avant de copier son graphe dans mon site.

Ton graphe tient debout ? Alors les machines savent enfin qui parle. Reste à leur donner envie de te citer, trouvé, extractible, attribuable, et c'est tout le chapitre 4.

Et toi, combien d'organisations le validateur a-t-il trouvées sur ton site ? Une, j'espère :)

Co-fondateur de Kōeki · Consultant SEO et IA

Sébastien Grillot

Consultant SEO depuis 2009 : c'est ici, sur Inside da WeB, qu'il a monté sa première agence, spécialisée dans l'e-commerce sous WordPress. Depuis 2021, il accompagne les e-commerçants avec Kōeki.

Son parcours completDiscuter de ton site avec KōekimIAou, ma newsletter IA