Données structurées auteur et article : construire un graphe cohérent

Un balisage valide peut rester trompeur. Il suffit qu’un titre, une date, un auteur ou un profil déclaré dans le JSON-LD ne corresponde pas à ce que la personne voit dans la page. Le premier travail n’est donc pas de remplir toutes les propriétés disponibles : il consiste à définir une source de vérité, puis à faire converger contenu visible, métadonnées et données structurées.

Réponse en bref

Utilisez Article pour décrire l’article visible, ProfilePage pour une page réellement consacrée à un auteur et Person pour l’entité auteur. Donnez à cette personne un identifiant @id stable et réutilisez-le dans les articles. Ne déclarez que les informations visibles, exactes et autorisées. Testez la syntaxe, puis contrôlez manuellement la cohérence éditoriale. Un balisage correct rend une page éligible à certains traitements ; il ne garantit ni résultat enrichi, ni indexation, ni position.

Trois couches à ne pas confondre

Couche	Question	Autorité utile
vocabulaire	quels types et propriétés existent ?	Schema.org
prise en charge	quels champs un moteur recommande-t-il pour une fonctionnalité ?	documentation du moteur
vérité éditoriale	cette information est-elle visible, prouvée et publiable ?	contenu de la page et registre interne

Schema.org définit un vocabulaire partagé. La documentation Google précise les usages reconnus par Google Search. Aucune de ces deux sources ne prouve qu’une personne possède un titre, un diplôme, un client ou un profil social. Cette preuve doit exister avant le balisage.

Les règles générales de Google sur les données structurées demandent notamment que le balisage représente le contenu principal et ne décrive pas un contenu caché ou trompeur. La règle opérationnelle la plus sûre est simple : si un lecteur ne peut pas retrouver l’affirmation dans la page, ne l’ajoutez pas au JSON-LD.

La matrice visible-source-balisage

Avant d’écrire le code, remplissez une ligne par information. La colonne « source » désigne ici la source de vérité du site, pas une URL ajoutée pour donner une apparence d’autorité.

Information	Visible où ?	Source de vérité	Balisage possible	Décision si non validée
nom de l’auteur	signature et page auteur	registre d’identité validé	author.name, Person.name	ne pas publier l’article sous ce nom
URL auteur	lien de la signature	route canonique du site	author.url, @id	retirer le lien et l’identifiant
date de publication	en-tête de l’article	CMS éditorial	datePublished	omettre tant que le contenu reste à l’état de brouillon
date de modification	historique visible ou métadonnée fiable	événement éditorial	dateModified	ne pas utiliser l’heure du build
image	image réellement affichée	médiathèque et droits	image	omettre si absente ou non autorisée
fonction	biographie visible	preuve et validation du propriétaire	jobTitle	ne pas l’inférer depuis un sujet traité
profils externes	liens visibles sur la page auteur	validation de propriété	sameAs	conserver hors balisage
éditeur	mention éditoriale visible	identité juridique ou éditoriale validée	publisher	ne pas inventer une organisation

Cette matrice empêche deux dérives courantes : transformer une hypothèse en fait parce qu’une propriété existe, et laisser le template publier une ancienne valeur après correction de la page.

Concevoir le graphe avant le template

Une personne ne devrait pas devenir une nouvelle entité à chaque page. Un identifiant stable relie la page de profil et les articles sans dupliquer l’identité.

Pour un site fictif, le graphe peut suivre ce modèle :

https://example.com/a-propos/#personne
       ↑ mainEntity                    ↑ author
ProfilePage                       Article A, B, C

L’identifiant avec fragment est une convention de modélisation, pas une page supplémentaire. Il doit rester stable tant qu’il désigne la même entité. L’URL publique de la page auteur peut être utilisée dans url, tandis que @id sert à relier les nœuds.

Exemple pour la page auteur

L’exemple suivant est fictif. Chaque valeur textuelle devrait aussi être visible dans la page correspondante.

{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "@id": "https://example.com/a-propos/#page",
  "url": "https://example.com/a-propos/",
  "name": "À propos de Camille Martin",
  "dateModified": "2026-07-12",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://example.com/a-propos/#personne",
    "name": "Camille Martin",
    "url": "https://example.com/a-propos/",
    "description": "Description courte visible sur la page."
  }
}

ProfilePage convient lorsque la page est principalement consacrée à une personne ou à une organisation affiliée au site. Une page d’accueil qui mélange services, articles et appels à l’action ne doit pas être déclarée page de profil par commodité.

Exemple pour une page article

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/articles/guide/#article",
  "url": "https://example.com/articles/guide/",
  "mainEntityOfPage": "https://example.com/articles/guide/",
  "headline": "Titre visible de l'article",
  "description": "Description visible ou fidèlement dérivée de l'article.",
  "datePublished": "2026-07-12",
  "dateModified": "2026-07-12",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/a-propos/#personne",
    "name": "Camille Martin",
    "url": "https://example.com/a-propos/"
  }
}

Le nom, la date et le titre ne sont pas répétés dans plusieurs fichiers si le CMS peut les fournir. Le composant visible et le JSON-LD doivent lire la même donnée. Cette architecture réduit les écarts, mais ne remplace pas le contrôle des valeurs saisies.

Les décisions importantes propriété par propriété

headline et description

Le titre structuré doit désigner le même article que le h1. Une reformulation courte peut rester fidèle, mais une promesse absente du contenu crée une incohérence. La description ne doit pas annoncer une étude, un comparatif ou des résultats qui ne figurent pas dans la page.

datePublished et dateModified

La date de publication correspond à une mise à disposition publique réelle. La date de modification correspond à un changement éditorial significatif selon la politique du site. Utiliser automatiquement l’heure de chaque compilation rend la date inutilisable et donne l’impression d’une mise à jour qui n’a pas eu lieu.

author

Google recommande d’inclure tous les auteurs visibles, chacun dans un objet distinct, et d’indiquer son type ainsi qu’une URL utile. Ne fusionnez pas deux personnes dans une seule chaîne. Ne placez pas la fonction ou le nom de l’éditeur dans author.name.

sameAs

sameAs relie une entité à une autre URL qui représente cette même entité. Ce n’est pas une liste de sources, de partenaires, de clients ou de liens appréciés. Une homonymie ou un compte supposé ne suffit pas. Avant d’ajouter un profil externe, vérifiez qu’il appartient bien à la personne ou à l’organisation décrite.

image

Une image déclarée doit représenter le contenu balisé, être réellement utilisée et pouvoir être explorée. Vérifiez aussi les droits de publication. Un fichier techniquement accessible n’est pas automatiquement réutilisable.

publisher

Sur un site personnel, ne créez pas une organisation fictive uniquement pour remplir ce champ. Si une organisation éditrice existe, sa dénomination et son identité doivent être cohérentes avec les mentions visibles. Sinon, suivez les propriétés adaptées au type de page sans ajouter de faux intermédiaire.

La checklist de cohérence en douze points

Cette checklist est conçue pour une revue avant passage au statut public.

1. le type choisi décrit le sujet principal de la page ;
2. chaque affirmation structurée est visible ou directement vérifiable dans la page ;
3. le headline correspond au titre éditorial ;
4. tous les auteurs visibles sont présents et aucun auteur caché n’est ajouté ;
5. chaque auteur pointe vers le bon identifiant stable ;
6. les dates proviennent d’événements éditoriaux, pas du build ;
7. les URL sont absolues, canoniques et en HTTPS ;
8. les images déclarées sont affichées, accessibles et autorisées ;
9. les sameAs ont fait l’objet d’une validation de propriété ;
10. aucun titre, client, avis, note ou résultat n’est inféré ;
11. la syntaxe passe un validateur et le HTML rendu contient le bloc attendu ;
12. une lecture humaine compare le JSON-LD au contenu visible.

Un validateur syntaxique peut confirmer un type, une URL ou un format de date. Il ne sait pas si la personne a réellement exercé la fonction déclarée. Les points 2, 8, 9 et 10 restent donc des contrôles éditoriaux ou juridiques.

Tester à quatre niveaux

Niveau	Test	Échec détecté
schéma interne	validation des champs du CMS	auteur vide, date impossible, statut inconnu
rendu	inspection du HTML généré	JSON invalide, URL relative, bloc absent
outil externe	test de résultats enrichis ou validateur Schema.org	propriété ou type mal formé
revue éditoriale	comparaison page/registre/JSON-LD	fait invisible, profil non confirmé, date trompeuse

Après publication, l’inspection d’URL et les rapports de la plateforme peuvent révéler des problèmes que le test local n’observe pas. Cela ne justifie pas de publier un brouillon uniquement pour tester : utilisez d’abord un environnement de revue protégé des index, puis appliquez la procédure de mise en ligne prévue.

Éviter la génération incontrôlée

Un template global devient dangereux lorsqu’il assemble des propriétés à partir de valeurs par défaut. Quelques règles réduisent le risque :

• aucune datePublished sans statut publié ;
• aucun sameAs sans drapeau de validation explicite ;
• aucune image de remplacement déclarée comme portrait ;
• aucun auteur par défaut si l’attribution manque ;
• aucun dateModified calculé depuis l’heure du déploiement ;
• aucun nœud Person enrichi depuis une page tierce non vérifiée.

Le bon comportement est de ne pas générer le bloc incomplet, ou de bloquer la publication, selon l’importance du champ. Un balisage minimal et exact vaut mieux qu’un graphe riche mais spéculatif.

Ce que les données structurées ne promettent pas

Google précise qu’un balisage conforme ne garantit pas l’affichage d’un résultat enrichi. Schema.org ne promet pas non plus qu’un service utilisera chaque propriété. Les données structurées servent à expliciter une page ; elles ne compensent pas un contenu faible, une identité incertaine, un accès bloqué ou une information contradictoire.

La même exigence de provenance s’applique aux vidéos. Pour attribuer correctement creator et ne publier que des interactions réellement mesurées, consultez le guide VideoObject et SEO vidéo.

Pour mesurer les effets sans confondre éligibilité et visibilité, utilisez un protocole comme celui du guide Mesurer sa visibilité dans les moteurs de réponse. Les règles de sources et de correction sont détaillées dans la politique éditoriale.

Limites

Les propriétés et fonctionnalités prises en charge peuvent évoluer. Vérifiez la documentation au moment de l’implémentation et après une modification importante du template. Les exemples utilisent un domaine et une personne fictifs ; ils ne constituent pas un balisage prêt à publier pour une personne réelle. Ce guide ne remplace ni une validation juridique des mentions, ni la confirmation des droits sur les images, ni une revue de la politique de publication.

Articles liés

• Mesurer sa visibilité dans les moteurs de réponse
• Comment apparaître dans ChatGPT : méthode et contrôles
• À propos : informations vérifiables

Prochaine étape

Construisez d’abord la matrice pour une page auteur et un article. Ensuite seulement, reliez les deux nœuds, validez le rendu et comparez chaque propriété au contenu visible.