Schema.org for generative search: Organization, Person, Article, FAQPage.

What structured data is for in a generative engine

Structured data serves one precise purpose: making the publishing entity readable, without ambiguity. A generative engine chooses its sources among passages, then checks who signs them. Schema.org markup, inserted as JSON-LD in the HTML, gives it that identity in a form a program reads without interpretation: a name, a legal form, an author, a date, linked profiles. It is the third of the four conditions for a citation described in our complete method: after accessible and citable, identified.

We must be honest about what is known. Google documents the use of structured data to understand a page and trigger rich results; AI Overviews and AI Mode rely on the same index as classic search, and Google's documentation on its AI features refers to the same fundamentals, insisting on the match between the markup and the visible content. Bing uses schema.org markup, and Copilot relies on the Bing index. By contrast, neither OpenAI, nor Anthropic, nor Perplexity has published documentation describing the use of JSON-LD in source selection. To our knowledge, their AI search crawlers read the full HTML, markup included; what they then do with it is not public.

This uncertainty does not change the decision. Markup costs a few hours on a template, it is read with certainty by Google and Bing, and it imposes a discipline that benefits all engines: a single name, a named author, a truthful date, consistent profiles. In our audits, the sites cited regularly by all four engines almost all have a marked-up, consistent entity; the reverse is not true, but the absence of markup almost always goes with a blurry entity.

Other types exist and serve depending on the business: LocalBusiness for an establishment, Product and Offer for a catalogue, Event, Course, SoftwareApplication. They are added to the four base types; they do not replace them. A site that marks up its products without describing the organisation that sells them leaves the engine to guess half the information.

Organization: the publisher's identity record

The Organization block describes the company that publishes the site. It must appear once, on every page, with the same content and the same @id identifier, so that all the other blocks can refer to it. The name declared here becomes the canonical name of the entity: it is the one that must be found, to the letter, on LinkedIn, in the registers and in the directories.

For this type, Google documents a list of properties extended since 2024, covering administrative identifiers: legalName, vatID, taxID, leiCode, duns, iso6523Code, numberOfEmployees, foundingDate. These properties have no visible effect in the results; they serve to link the site's entity to the entity in the registers, which is exactly what an engine tries to do before granting its trust to a source.

Table: scroll horizontally.

{
  "@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": "Search and generative search (GEO) agency, with offices in Alicante, Valencia, Madrid and Paris.",
  "email": "hola@seo360.tech",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Elche",
    "addressRegion": "Alicante",
    "addressCountry": "ES"
  },
  "vatID": "ES…",
  "founder": { "@id": "https://seo360.tech/#kamel-malek" },
  "knowsAbout": ["Organic search", "Generative search", "Structured data"],
  "sameAs": [
    "https://www.linkedin.com/company/…",
    "https://www.wikidata.org/wiki/Q…"
  ]
}

Two rules for sameAs. Only include pages that really exist and that are about you: an empty profile or a dead address weakens the record instead of strengthening it. And keep the list short: five to eight profiles kept up to date are worth more than twenty links, half of which point to abandoned accounts. Building this list, with the registers and Wikidata, is the subject of a dedicated article on the brand entity.

Person: the author, linked to the organisation

A generative engine evaluates a source partly by the person who signs it. The Person block describes that author with verifiable properties: job title, employer, areas of expertise, public profiles, publications. It too carries a stable @id, so that each article, each author page and the Organization block designate the same person without describing them again.

The properties that carry weight are those a third party can confirm. jobTitle and worksFor situate the person; knowsAbout declares their topics; sameAs points to profiles where the same name, the same job title and the same topics appear; alumniOf, hasCredential and award document training and distinctions when they exist. Conversely, a three-line biography in description, with no external link, proves nothing.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://seo360.tech/#kamel-malek",
  "name": "Kamel Malek",
  "jobTitle": "Founder and director",
  "worksFor": { "@id": "https://seo360.tech/#organization" },
  "url": "https://seo360.tech/#equipe",
  "image": "https://seo360.tech/img/auteur-kamel-malek.jpg",
  "description": "SEO practitioner since 2001, author of three books on generative search.",
  "knowsAbout": ["Generative search", "Organic search", "Entities and structured data"],
  "knowsLanguage": ["fr", "es", "en"],
  "sameAs": [
    "https://www.linkedin.com/in/…",
    "https://www.amazon.fr/…"
  ]
}

The link between Person and Organization works both ways: worksFor on one side, founder or employee on the other. This reciprocity is what lets an engine conclude that the author and the publisher form a single consistent entity, and not two names placed side by side. What an author page must contain, beyond the markup, is detailed in the article on author pages.

Article and BlogPosting: what is said, by whom, when

The Article block, or its BlogPosting subtype for a blog, attaches a piece of content to its author, its publisher and its dates. For this type, Google documents a small number of recommended properties: headline, image, datePublished, dateModified, author with name and url. That is the minimum. For generative search, three additional properties have practical value: mainEntityOfPage, which designates the canonical address; inLanguage, which avoids confusion on a multilingual site; about or mentions, which link the article to the entities it deals with.

The absolute rule is the match with what is visible. The declared date must be the one displayed on the page; the declared author must be the one in the byline; the declared headline must be the main title. A gap between the markup and the text is the kind of inconsistency an engine detects easily and which discredits the whole record. The question of dates, and what a truthful update means, is covered in the article on freshness signals.

{
  "@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 for generative search: Organization, Person, Article, FAQPage",
  "description": "Four schema.org types are enough for a generative engine to identify who publishes, who writes, what and when.",
  "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": "Structured data",
  "author": { "@id": "https://seo360.tech/#kamel-malek" },
  "publisher": { "@id": "https://seo360.tech/#organization" },
  "about": [
    { "@type": "Thing", "name": "Schema.org" },
    { "@type": "Thing", "name": "Generative search" }
  ]
}

On a site of several hundred pages, this block is not written by hand: it is generated from the template, with the fields of the content management system. The only discipline to impose on writers is to fill in a real author and an honest update date; the rest is mechanical.

FAQPage: the format closest to a generated answer

A question-and-answer section marked up as FAQPage is the content whose form most resembles what a generative engine produces: a question in natural language, a self-contained answer of fifty to ninety words. The markup lists these pairs in mainEntity, each as a Question object whose accepted answer is an Answer object.

You need to know this type's limitation at Google. Since August 2023, Google only shows FAQ rich results for recognised government and health websites; for everyone else, the markup remains valid and read, but it produces no particular display. That is no reason to abandon it: it keeps a descriptive value, it forces you to write self-contained answers, and it costs nothing more than a well-structured section. Simply, do not expect it to be a display lever.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do you need one JSON-LD block per type or a single graph?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A single JSON-LD script with an @graph array is preferable: the Organization, Person, BlogPosting and FAQPage nodes are declared there once and reference each other by @id, which avoids contradictory duplicates."
      }
    },
    {
      "@type": "Question",
      "name": "Does FAQPage markup still produce a rich result?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "At Google, only for recognised government or health websites, since August 2023. For the others, the markup remains valid but has no dedicated display."
      }
    }
  ]
}

Three content rules condition the validity of this block: each marked-up question must be visible on the page, with its answer, in the same terms; the markup must not be used to insert promotional answers absent from the text; and a page must carry only one FAQPage block. A section of four to six questions, each answering a phrasing actually used by your buyers, is worth more than a list of twenty rhetorical questions.

The markup mistakes that discredit a source

False markup is worse than no markup, because it gives the engine a precise reason to doubt. The mistakes below come up in almost all our audits; each can be corrected in less than a day.

• Two contradictory Organization blocks on the same page, one injected by the theme, the other by a plugin, with two different names.
• A generic author (“admin”, “editorial team”, the site's name) where a person's name is expected.
• A dateModified refreshed at each page generation, without any change in content.
• sameAs links to empty profiles, abandoned accounts or pages that do not mention the company.
• An AggregateRating block on the organisation itself, fed by reviews collected on the site: Google excludes these self-serving ratings from its rich results, and a generative engine has no reason to believe them.
• A FAQPage whose questions do not appear in the visible text.
• Article markup on pages that are not articles: home page, categories, product pages.
• A block that is syntactically valid but empty of meaning: name filled in, everything else missing.

Validate, deploy, monitor

Markup is validated at three levels, and each level catches errors the others let through. The schema.org validator (validator.schema.org) checks the syntax and the existence of types and properties. Google's Rich Results Test checks eligibility for the displays Google supports, and flags the properties missing for those displays. Human reading, finally, checks what no tool controls: that the declared name, author and date are indeed those the page displays.

Deployment follows the order of the types. The organisation first, because everything else refers to it; the authors next; then the article templates and, last, the question sections. On an existing site, this sequence fits within a quarter, provided you start by removing stray markup rather than adding more.

Monitoring does not stop at deployment. A theme update, a new plugin or a template change can reintroduce a stray block without anyone noticing. A monthly review of a sample of pages, cross-checked with the Search Console reports, is enough to detect these regressions before they cost citations.

What to remember