Schema.org pour la recherche générative : Organization, Person, Article, FAQPage.

À quoi servent les données structurées dans un moteur génératif

Les données structurées servent à une chose précise : rendre lisible, sans ambiguïté, l'entité qui publie. Un moteur génératif choisit ses sources parmi des passages, puis vérifie qui les signe. Le balisage schema.org, inséré en JSON-LD dans le HTML, lui fournit cette identité sous une forme qu'un programme lit sans interprétation : un nom, une forme juridique, un auteur, une date, des profils reliés. C'est la troisième des quatre conditions d'une citation décrites dans notre méthode complète : après accessible et citable, identifiée.

Il faut être honnête sur ce que l'on sait. Google documente l'usage des données structurées pour comprendre une page et déclencher des résultats enrichis ; AI Overviews et AI Mode reposent sur le même index que la recherche classique, et la documentation de Google sur ses fonctionnalités d'IA renvoie aux mêmes fondamentaux, en insistant sur la correspondance entre le balisage et le contenu visible. Bing exploite le balisage schema.org, et Copilot s'appuie sur l'index Bing. En revanche, ni OpenAI, ni Anthropic, ni Perplexity n'ont publié de documentation décrivant l'usage du JSON-LD dans la sélection des sources. À notre connaissance, leurs robots de recherche IA lisent le HTML complet, balisage compris ; ce qu'ils en font ensuite n'est pas public.

Cette incertitude ne change pas la décision. Le balisage coûte quelques heures sur un gabarit, il est lu de façon certaine par Google et Bing, et il impose une discipline qui profite à tous les moteurs : un nom unique, un auteur nommé, une date sincère, des profils cohérents. Dans nos audits, les sites cités régulièrement par les quatre moteurs ont presque tous une entité balisée et cohérente ; l'inverse n'est pas vrai, mais l'absence de balisage accompagne presque toujours une entité floue.

D'autres types existent et servent selon le métier : LocalBusiness pour un établissement, Product et Offer pour un catalogue, Event, Course, SoftwareApplication. Ils s'ajoutent aux quatre types de base, ils ne les remplacent pas. Un site qui balise ses produits sans décrire l'organisation qui les vend laisse le moteur deviner la moitié de l'information.

Organization : la fiche d'identité de l'éditeur

Le bloc Organization décrit l'entreprise qui édite le site. Il doit apparaître une seule fois, sur chaque page, avec le même contenu et le même identifiant @id, de façon que tous les autres blocs puissent s'y référer. Le nom déclaré ici devient le nom canonique de l'entité : c'est celui qu'il faudra retrouver, à la lettre, sur LinkedIn, dans les registres et dans les annuaires.

Google documente pour ce type une liste de propriétés élargie depuis 2024, qui couvre les identifiants administratifs : legalName, vatID, taxID, leiCode, duns, iso6523Code, numberOfEmployees, foundingDate. Ces propriétés n'ont aucun effet visible dans les résultats ; elles servent à relier l'entité du site à l'entité des registres, ce qui est exactement ce qu'un moteur cherche à faire avant d'accorder sa confiance à une source.

Tableau : faites défiler horizontalement.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://seo360.tech/#organization",
  "name": "SEO360",
  "legalName": "SEO 360 ALICANTE S.L.",
  "url": "https://seo360.tech",
  "logo": "https://seo360.tech/img/logo.png",
  "description": "Agence de référencement et de recherche générative (GEO), présente à Alicante, Valence, Madrid et Paris.",
  "email": "hola@seo360.tech",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Elche",
    "addressRegion": "Alicante",
    "addressCountry": "ES"
  },
  "vatID": "ES…",
  "founder": { "@id": "https://seo360.tech/#kamel-malek" },
  "knowsAbout": ["Référencement naturel", "Recherche générative", "Données structurées"],
  "sameAs": [
    "https://www.linkedin.com/company/…",
    "https://www.wikidata.org/wiki/Q…"
  ]
}

Deux règles pour sameAs. N'y mettez que des pages qui existent réellement et qui parlent de vous : un profil vide ou une adresse morte affaiblit la fiche au lieu de la renforcer. Et gardez la liste courte : cinq à huit profils tenus à jour valent mieux que vingt liens dont la moitié pointe vers des comptes abandonnés. La construction de cette liste, avec les registres et Wikidata, fait l'objet d'un article dédié sur l'entité de marque.

Person : l'auteur, relié à l'organisation

Un moteur génératif évalue une source en partie par la personne qui la signe. Le bloc Person décrit cet auteur avec des propriétés vérifiables : fonction, employeur, domaines de compétence, profils publics, publications. Il porte lui aussi un @id stable, de sorte que chaque article, chaque page auteur et le bloc Organization désignent la même personne sans la redécrire.

Les propriétés qui pèsent sont celles qu'un tiers peut confirmer. jobTitle et worksFor situent la personne ; knowsAbout déclare ses sujets ; sameAs renvoie à des profils où le même nom, la même fonction et les mêmes sujets apparaissent ; alumniOf, hasCredential et award documentent la formation et les distinctions quand elles existent. À l'inverse, une biographie de trois lignes dans description, sans aucun lien externe, ne prouve rien.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://seo360.tech/#kamel-malek",
  "name": "Kamel Malek",
  "jobTitle": "Fondateur et directeur",
  "worksFor": { "@id": "https://seo360.tech/#organization" },
  "url": "https://seo360.tech/#equipe",
  "image": "https://seo360.tech/img/auteur-kamel-malek.jpg",
  "description": "Praticien du référencement depuis 2001, auteur de trois ouvrages sur la recherche générative.",
  "knowsAbout": ["Recherche générative", "Référencement naturel", "Entités et données structurées"],
  "knowsLanguage": ["fr", "es", "en"],
  "sameAs": [
    "https://www.linkedin.com/in/…",
    "https://www.amazon.fr/…"
  ]
}

Le lien entre Person et Organization se fait dans les deux sens : worksFor d'un côté, founder ou employee de l'autre. Cette réciprocité est ce qui permet à un moteur de conclure que l'auteur et l'éditeur forment une seule entité cohérente, et non deux noms posés côte à côte. Ce qu'une page auteur doit contenir, au-delà du balisage, est détaillé dans l'article sur les pages auteur.

Article et BlogPosting : ce qui est dit, par qui, quand

Le bloc Article, ou son sous-type BlogPosting pour un blog, rattache un contenu à son auteur, à son éditeur et à ses dates. Google documente pour ce type un petit nombre de propriétés recommandées : headline, image, datePublished, dateModified, author avec name et url. C'est le minimum. Pour la recherche générative, trois propriétés supplémentaires ont une valeur pratique : mainEntityOfPage, qui désigne l'adresse canonique ; inLanguage, qui évite les confusions sur un site multilingue ; about ou mentions, qui relient l'article aux entités qu'il traite.

La règle absolue est la correspondance avec le visible. La date déclarée doit être celle affichée dans la page ; l'auteur déclaré doit être celui de la signature ; le titre déclaré doit être le titre principal. Un écart entre le balisage et le texte est le type d'incohérence qu'un moteur détecte facilement et qui décrédibilise toute la fiche. La question des dates, et ce qu'une mise à jour sincère signifie, est traitée dans l'article sur les signaux de fraîcheur.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://seo360.tech/blog/schema-org-pour-la-recherche-generative.html#article",
  "mainEntityOfPage": "https://seo360.tech/blog/schema-org-pour-la-recherche-generative.html",
  "headline": "Schema.org pour la recherche générative : Organization, Person, Article, FAQPage",
  "description": "Quatre types schema.org suffisent pour qu'un moteur génératif identifie qui publie, qui écrit, quoi et quand.",
  "image": "https://seo360.tech/blog/img/027-schema-org-pour-la-recherche-generative.jpg",
  "inLanguage": "fr",
  "datePublished": "2026-06-25",
  "dateModified": "2026-06-25",
  "articleSection": "Données structurées",
  "author": { "@id": "https://seo360.tech/#kamel-malek" },
  "publisher": { "@id": "https://seo360.tech/#organization" },
  "about": [
    { "@type": "Thing", "name": "Schema.org" },
    { "@type": "Thing", "name": "Recherche générative" }
  ]
}

Sur un site de plusieurs centaines de pages, ce bloc ne s'écrit pas à la main : il se génère à partir du gabarit, avec les champs du système de gestion de contenu. La seule discipline à imposer aux rédacteurs est de renseigner un auteur réel et une date de mise à jour honnête ; le reste est mécanique.

FAQPage : le format le plus proche d'une réponse générée

Une section de questions-réponses balisée en FAQPage est le contenu dont la forme ressemble le plus à ce qu'un moteur génératif produit : une question en langage naturel, une réponse autonome de cinquante à quatre-vingt-dix mots. Le balisage énumère ces paires dans mainEntity, chacune sous la forme d'un objet Question dont la réponse acceptée est un objet Answer.

Il faut connaître la limite de ce type chez Google. Depuis août 2023, Google n'affiche plus de résultat enrichi FAQ que pour des sites gouvernementaux et de santé reconnus ; pour tous les autres, le balisage reste valide et lu, mais il ne produit aucun affichage particulier. Ce n'est pas une raison de l'abandonner : il conserve une valeur descriptive, il oblige à écrire des réponses autonomes, et il ne coûte rien de plus qu'une section bien structurée. Simplement, ne l'attendez pas comme un levier d'affichage.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Faut-il un bloc JSON-LD par type ou un seul graphe ?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Un seul script JSON-LD avec un tableau @graph est préférable : les nœuds Organization, Person, BlogPosting et FAQPage y sont déclarés une fois et se référencent par @id, ce qui évite les doublons contradictoires."
      }
    },
    {
      "@type": "Question",
      "name": "Le balisage FAQPage produit-il encore un résultat enrichi ?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Chez Google, seulement pour des sites gouvernementaux ou de santé reconnus, depuis août 2023. Pour les autres, le balisage reste valide mais n'a pas d'affichage dédié."
      }
    }
  ]
}

Trois règles de contenu conditionnent la validité de ce bloc : chaque question balisée doit être visible dans la page, avec sa réponse, dans les mêmes termes ; le balisage ne doit pas servir à insérer des réponses promotionnelles absentes du texte ; et une page ne doit porter qu'un seul bloc FAQPage. Une section de quatre à six questions, chacune répondant à une formulation réellement posée par vos acheteurs, vaut mieux qu'une liste de vingt questions rhétoriques.

Les erreurs de balisage qui décrédibilisent une source

Un balisage faux est pire qu'une absence de balisage, parce qu'il donne au moteur une raison précise de douter. Les erreurs ci-dessous reviennent dans presque tous nos audits ; chacune se corrige en moins d'une journée.

• Deux blocs Organization contradictoires sur la même page, l'un injecté par le thème, l'autre par une extension, avec deux noms différents.
• Un auteur générique (« admin », « équipe éditoriale », le nom du site) là où un nom de personne est attendu.
• Une dateModified renouvelée à chaque génération de page, sans changement de contenu.
• Des liens sameAs vers des profils vides, des comptes abandonnés ou des pages qui ne mentionnent pas l'entreprise.
• Un bloc AggregateRating sur l'organisation elle-même, alimenté par des avis collectés sur le site : Google exclut ces notes auto-attribuées de ses résultats enrichis, et un moteur génératif n'a aucune raison de les croire.
• Une FAQPage dont les questions ne figurent pas dans le texte visible.
• Un balisage Article sur des pages qui ne sont pas des articles : accueil, catégories, fiches produit.
• Un bloc valide syntaxiquement mais vide de sens : name renseigné, tout le reste absent.

Valider, déployer, surveiller

Un balisage se valide à trois niveaux, et chaque niveau attrape des erreurs que les autres laissent passer. Le validateur de schema.org (validator.schema.org) vérifie la syntaxe et l'existence des types et propriétés. L'outil de test des résultats enrichis de Google vérifie l'éligibilité aux affichages que Google prend en charge, et signale les propriétés manquantes pour ces affichages. La lecture humaine, enfin, vérifie ce qu'aucun outil ne contrôle : que le nom, l'auteur et la date déclarés sont bien ceux que la page affiche.

Le déploiement suit l'ordre des types. L'organisation d'abord, parce que tout le reste s'y réfère ; les auteurs ensuite ; puis les gabarits d'article et, en dernier, les sections de questions. Sur un site existant, ce déroulé tient en un trimestre, à condition de commencer par supprimer les balisages parasites plutôt que d'en ajouter.

Le suivi ne s'arrête pas au déploiement. Une mise à jour du thème, une nouvelle extension ou un changement de gabarit peuvent réintroduire un bloc parasite sans que personne ne le remarque. Une relecture mensuelle d'un échantillon de pages, croisée avec les rapports de la Search Console, suffit à détecter ces régressions avant qu'elles ne coûtent des citations.

Ce qu'il faut retenir