FAQ, glossaires et pages « vs » : les formats à fort rendement en recherche générative.

Trois formats, un point commun : ils sont déjà découpés comme une réponse

Un moteur génératif extrait des passages qui répondent seuls à une sous-requête. Trois formats produisent ces passages par construction, sans effort de réécriture : la FAQ, dont chaque entrée est un couple question-réponse ; le glossaire, dont chaque entrée est une définition ; la page « vs », dont chaque bloc compare deux options sur un critère. Dans nos audits, ces trois formats concentrent une part de citation très supérieure à leur part du site, à une condition : qu'ils aient été écrits pour répondre, et non pour remplir.

Chacun correspond à un type de sous-requête que les moteurs formulent en permanence. La FAQ sert les questions pratiques : comment, combien, quand, puis-je. Le glossaire sert les questions de définition : qu'est-ce que, que signifie. La page « vs » sert les questions de choix : X ou Y, lequel convient. Un cluster bien construit contient les trois, et chacun est balisé pour que le moteur sache ce qu'il lit.

La suite détaille chaque format avec un exemple sectoriel fictif, son balisage, ses erreurs classiques, puis la façon de les combiner. Les quatre conditions d'une citation décrites dans la méthode complète restent le cadre ; ces trois formats servent d'abord la deuxième, être citable.

La FAQ : répondre aux questions réellement posées, pas à celles qu'on aimerait

Une FAQ est citable quand ses questions sont celles que les acheteurs posent aux moteurs, formulées comme ils les formulent, et quand chaque réponse tient seule. Prenons un cabinet de gestion locative fictif. Ses clients demandent « quels sont les frais de gestion locative », « qui paie les réparations », « en combien de temps un logement est-il reloué ». La FAQ utile reprend ces formulations, pas « nos prestations » ni « pourquoi nous choisir ».

• Une FAQ par page thématique, avec quatre à huit questions liées au sujet de la page, plutôt qu'une page FAQ unique de soixante questions sans lien entre elles.
• Une réponse de cinquante à quatre-vingt-dix mots, qui commence par la réponse, donne une condition ou une preuve, et reste vraie sortie de la page.
• Des questions collectées, pas inventées : messages du service client, questions posées aux commerciaux, sous-questions affichées par les moteurs.
• Aucune question dont la réponse est « contactez-nous » : elle ne sera jamais extraite et elle affaiblit les autres.

Le balisage FAQPage déclare au moteur que la page contient des couples question-réponse, et il doit reprendre exactement le texte visible. D'après la documentation de Google, l'affichage enrichi des FAQ dans ses résultats est désormais limité à certains types de sites ; le balisage garde néanmoins son intérêt de structuration pour les moteurs génératifs, et il ne coûte rien dès lors qu'il correspond au contenu.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Qui paie les réparations dans un logement en gestion locative ?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Le propriétaire paie les réparations qui relèvent de la vétusté ou de la structure ; le locataire paie l'entretien courant et les petites réparations. …"
    }
  }, {
    "@type": "Question",
    "name": "En combien de temps un logement est-il reloué ?",
    "acceptedAnswer": { "@type": "Answer", "text": "…" }
  }]
}

Le glossaire : une entité par terme, une définition citable par entrée

Un glossaire bien conçu est une série de passages citables : chaque entrée commence par une définition en une ou deux phrases, puis développe, puis relie. Prenons un éditeur fictif de logiciel de signature électronique. Ses termes : signature simple, avancée et qualifiée, horodatage, cachet électronique, piste d'audit. Un acheteur qui demande à un moteur « quelle différence entre signature avancée et signature qualifiée » reçoit une réponse construite sur des définitions. Si le glossaire de l'éditeur les fournit clairement, il est cité ; sinon, ce sont celles d'un concurrent ou d'un site institutionnel qui le sont.

• Un terme, une URL ou une ancre stable, pour que le moteur puisse citer l'entrée et non la page entière.
• La définition en tête, au présent, sans « chez nous » : elle doit être vraie en dehors de votre produit.
• Puis la précision : ce que le terme n'est pas, les termes voisins, un exemple d'usage.
• Un lien vers les entrées liées et vers la page de service ou de produit concernée, avec le terme pour ancre.
• Un balisage DefinedTerm dans un DefinedTermSet, et la mention de la source quand la définition repose sur une norme ou un texte réglementaire.

{
  "@context": "https://schema.org",
  "@type": "DefinedTermSet",
  "name": "Glossaire de la signature électronique",
  "hasDefinedTerm": [{
    "@type": "DefinedTerm",
    "@id": "https://www.exemple.fr/glossaire/signature-qualifiee",
    "name": "Signature électronique qualifiée",
    "description": "Une signature électronique qualifiée est une signature avancée créée à l'aide d'un dispositif qualifié …",
    "inDefinedTermSet": "https://www.exemple.fr/glossaire/"
  }]
}

L'erreur la plus fréquente est la définition copiée depuis un dictionnaire ou depuis un concurrent. Le moteur, qui compare, trouve la même phrase à dix endroits et n'a aucune raison de vous préférer. La définition doit être vôtre dans sa formulation, exacte dans son contenu, et sourcée quand elle repose sur un texte de référence.

La page « vs » : la comparaison honnête qui remplace le comparatif tiers

Les questions de choix sont celles où les marques sont le moins citées, parce que les moteurs préfèrent des sources tierces jugées neutres. Une page « vs » bien faite renverse partiellement ce rapport : si elle est honnête, structurée par critère, et cohérente avec ce que disent les comparatifs, elle devient une source acceptable pour le moteur, qui la croise avec les autres. Si elle est partiale, elle est écartée, et elle peut décrédibiliser le reste du site.

Prenons un fabricant fictif de menuiseries qui vend les deux matériaux et publie « Fenêtres aluminium ou PVC : lequel choisir ». La page ouvre sur un verdict conditionnel, compare critère par critère, puis donne les cas où chaque option l'emporte. Le tableau ci-dessous illustre la structure, pas une expertise en menuiserie : c'est au fabricant de le remplir avec ses propres mesures et de les dater.

Tableau : faites défiler horizontalement.

La structure gagnante est celle du schéma : verdict conditionnel en tête, un critère par bloc, cas d'usage à la fin. Le verdict conditionnel est la forme la plus reprise, parce qu'elle correspond à la manière dont le moteur lui-même répond. Une page « vs » entre votre produit et celui d'un concurrent nommé obéit aux mêmes règles, avec une contrainte de plus : la publicité comparative est encadrée par la loi en France comme en Espagne ; elle doit porter sur des caractéristiques essentielles et vérifiables, sans dénigrement. Le cas du SaaS B2B, où ces pages pèsent lourd, est détaillé dans l'article sur les prompts de comparaison.

Les erreurs classiques, format par format

Les erreurs ci-dessous sont celles qui reviennent dans nos audits. Chacune suffit à rendre un format inutile, quel que soit le soin apporté au reste.

FAQ

• Des questions inventées pour placer des mots-clés, jamais posées par personne.
• Des réponses promotionnelles qui renvoient à un formulaire au lieu de répondre.
• La même FAQ dupliquée sur toutes les pages du site.
• Un balisage FAQPage qui déclare des questions absentes du texte visible.

Glossaire

• Des définitions copiées, identiques à celles de dix autres sites.
• Un glossaire sur une seule page longue, sans ancre ni URL par terme.
• Des entrées qui définissent le terme par votre produit : « la signature qualifiée, c'est notre offre Premium ».
• Aucun lien entre les entrées, ni vers les pages qui emploient le terme.

Page « vs »

• Un verdict absent, ou un verdict qui désigne toujours votre offre.
• Des critères choisis parce qu'ils vous avantagent, en omettant ceux qui comptent pour l'acheteur.
• Des chiffres sur le concurrent sans source ni date.
• Une page « vs » par concurrent, générée en série, avec le même texte.

Balisage : ce que chaque format déclare, et la règle de correspondance

Le balisage ne crée pas la citation ; il confirme au moteur ce que la page contient déjà. La règle unique : tout ce qui est déclaré dans le JSON-LD doit être visible dans la page, mot pour mot ou presque. Un balisage qui déclare douze questions quand la page en montre quatre est une incohérence, et un moteur qui la détecte cesse de faire confiance au reste du balisage, y compris à l'entité.

Tableau : faites défiler horizontalement.

Les propriétés complètes et la validation sont traitées dans l'article sur Schema.org pour la recherche générative. La mise en œuvre HTML des tableaux, listes et définitions que ces formats mobilisent est décrite dans l'article sur les formats extraits.

Combiner les trois formats dans un même cluster

Les trois formats ne sont pas des pages isolées ; ce sont les pièces d'un cluster. La page pilier porte une FAQ courte sur l'intention. Les satellites portent chacun leur FAQ sur leur sous-requête. Le glossaire est un satellite à part entière, dont les entrées sont reliées depuis chaque page qui emploie le terme. Les pages « vs » servent les sous-requêtes de choix et renvoient vers les satellites pour le détail de chaque critère. Ce montage donne au moteur, pour chaque type de sous-requête, un passage de la forme attendue.

L'ordre de mise en œuvre que nous suivons : le glossaire d'abord, parce qu'il fixe le vocabulaire que toutes les autres pages reprendront ; les FAQ ensuite, satellite par satellite ; les pages « vs » en dernier, parce qu'elles exigent le plus de rigueur et bénéficient des définitions et des FAQ déjà en place.

Ce qu'il faut retenir