Données structurées Person, Organization et Article sur WordPress : guide JSON-LD

Quel type Schema.org décrit quelle chose

Le document, la personne, l’organisation et l’article sont quatre objets distincts.

Person représente un individu. Organization représente une structure. ProfilePage représente une page dont le sujet principal est cette personne ou organisation. Article ou BlogPosting représente un contenu éditorial. WebPage décrit la page qui porte ce contenu et BreadcrumbList son chemin de navigation.

Choisir le type le plus précis aide à éviter les raccourcis. La page auteur n’est pas elle-même une Person : c’est une ProfilePage dont mainEntity pointe vers Person. L’article n’est pas l’organisation : il possède un auteur et un publisher. La page À propos peut décrire l’organisation sans devenir un profil personnel.

Schema.org propose de nombreuses propriétés, mais leur existence dans le vocabulaire ne signifie pas qu’elles sont pertinentes, visibles ou exploitées par un moteur. Commence par les relations nécessaires. Le guide de page auteur détaille la couche éditoriale qui doit exister avant le code.

Pourquoi les @id stables sont le centre du graphe

Un @id agit comme une référence interne ; il permet à plusieurs pages de parler de la même entité.

Sans @id stable, chaque bloc JSON-LD peut être interprété comme une description indépendante. Deux plugins peuvent ainsi générer deux organisations avec des noms proches, des logos différents et des URL divergentes. Le problème n’est pas nécessairement une erreur de syntaxe, mais une identité incohérente.

Choisis des identifiants HTTPS sous le domaine contrôlé. Une ancre sur la page d’accueil convient pour les entités globales, par exemple #organization et #person-ayoub-kahouadji. Les pages et articles utilisent leur URL canonique suivie d’une ancre descriptive. Il n’est pas nécessaire que l’ancre renvoie un fragment visuel ; elle sert d’identifiant dans le graphe.

Une fois choisis, ne changez pas les @id à chaque refonte graphique. Mettez à jour les propriétés du nœud existant. Si une URL canonique change, prévoyez la redirection de la page et contrôlez les références dans le graphe, le sitemap et les liens.

Relier author et publisher sans ambiguïté

Les relations doivent décrire des faits affichés, pas compléter artificiellement une fiche.

Organization sert ici de publisher et Person d’author. D’autres relations existent dans Schema.org, mais elles ne doivent être ajoutées que lorsqu’elles correspondent à des faits visibles et confirmés.

BlogPosting utilise author pour la personne qui signe réellement l’article et publisher pour l’organisation qui le publie. Si un article a plusieurs auteurs ou un éditeur différent, le graphe doit refléter ce cas réel. Ne désignez pas automatiquement le propriétaire du site comme auteur de tous les contenus.

Sur WeWorkWeb, la signature visible « Auteur : Ayoub Kahouadji » mène à la page auteur. Le @id de l’auteur reste identique dans BlogPosting et ProfilePage, tandis que le publisher pointe vers l’organisation. Cette structure évite de confondre la personne et la marque.

Aligner BlogPosting, WebPage, canonical et dates

Toutes les couches doivent désigner la même URL et les mêmes informations éditoriales.

Le canonical HTML indique l’URL de référence. Le nœud WebPage utilise cette URL, et BlogPosting peut pointer vers lui avec mainEntityOfPage. Le fil d’Ariane se termine sur la même URL. Une variante avec paramètres, une URL HTTP ou une ancienne route ne doit pas être injectée par un autre plugin.

headline, description, image, datePublished, dateModified et author doivent correspondre à ce que l’article affiche. datePublished conserve la publication initiale. dateModified change seulement après une modification substantielle, pas à chaque reconstruction du cache ou correction d’une espace.

Google recommande des images représentatives et explorables, idéalement dans plusieurs ratios lorsqu’elles existent. Ne fabriquez pas trois URL qui recadrent mal une image. Une seule image fidèle et accessible vaut mieux que des variantes déclarées mais absentes.

• URL canonique HTTPS auto-référente.
• mainEntityOfPage vers le @id WebPage.
• headline identique au H1 visible.
• description fidèle au chapeau.
• auteur et dates visibles dans la page.
• image accessible avec largeur et hauteur.
• articleSection limité à la catégorie réelle.

Ajouter BreadcrumbList seulement si le fil d’Ariane est réel

Le balisage du chemin doit refléter une navigation visible et stable.

Un article WeWorkWeb suit un chemin simple : Accueil, Articles, puis titre court de l’article. Chaque ListItem possède une position, un nom et une URL. Le dernier élément peut reprendre l’URL canonique de la page.

N’ajoutez pas une catégorie intermédiaire uniquement dans le JSON-LD si elle n’existe pas comme page utile. De même, une archive de catégorie noindex et vide n’a pas besoin d’être promue dans le fil. Le balisage doit suivre l’expérience, pas créer une architecture parallèle.

Lorsque WordPress ou un plugin SEO génère déjà le BreadcrumbList, modifiez sa configuration ou son filtre au lieu d’ajouter un second bloc manuel. Deux fils différents peuvent tous deux être valides mais contradictoires.

Intégrer le graphe dans WordPress sans empiler les plugins

Il faut d’abord inventorier qui produit déjà du JSON-LD, puis choisir un seul responsable par type.

Affichez le code source d’un article, recherchez application/ld+json et listez les nœuds. Répète sur l’accueil, la page auteur et une page de service. Un thème, un plugin SEO, une extension de schema et un constructeur peuvent tous injecter leur propre graphe via wp_head ou le rendu du document.

Choisis une source principale. Si le plugin SEO sait définir Organization, Person et Article avec des identifiants cohérents, utilisez ses filtres documentés. Si le besoin dépasse sa configuration, désactivez seulement le module concerné avant d’ajouter un graphe personnalisé. Ne masquez pas les doublons avec du CSS : le JSON-LD reste dans le code.

Pour un développement personnalisé, générez les valeurs depuis les données réelles de WordPress : URL canonique, auteur du post, date, image mise en avant et catégorie. Échappez correctement le JSON, ne concaténez pas des champs non validés et vérifiez les pages sans image ou sans auteur public.

1. 1. Inventaire sourceIdentifier thème, plugin SEO, extension schema et code personnalisé.
2. 2. Cartographie des @idLister Person, Organization, WebSite, WebPage et Article sur quatre pages types.
3. 3. ArbitrageDésigner un générateur responsable par nœud et désactiver les doublons.
4. 4. Test des cas limitesArticle sans image, auteur différent, brouillon, archive et ancienne URL.

Tester la syntaxe, les relations et le rendu réel

Un test riche ne suffit pas : il faut aussi vérifier le HTML, l’URL et l’indexabilité.

Commence par valider le JSON. Utilise ensuite le Schema Markup Validator pour la structure Schema.org et le Rich Results Test pour les fonctionnalités prises en charge par Google. Une absence d’erreur ne prouve pas que le contenu est vrai ni qu’un résultat enrichi sera affiché.

Inspectez l’URL dans Search Console après publication. Vérifie le canonical choisi, la page rendue, l’image, les directives robots et le code HTTP. Compare enfin le texte visible au graphe : nom, titre, dates, catégorie et auteur.

Conserve un contrôle automatisé local pour détecter un @id manquant, une date vide sur un article publié ou deux Organization différentes. La checklist SEO, GEO et moteurs IA complète ce test avec l’accès robots, les liens et la mesure.

• JSON valide et script application/ld+json unique ou coordonné.
• Aucun @id divergent pour la même entité.
• Aucune propriété importante absente du contenu visible.
• Canonical, WebPage, Article et breadcrumb alignés.
• Dates réelles et format ISO.
• Images accessibles et représentatives.
• URL publiée en HTTP 200 sans noindex involontaire.