Sections FAQ : format, schéma et exemples

Une FAQ est un élément de contenu de clôture qui répond à un petit ensemble de questions fondées sur des preuves que les sections principales de la page ne résolvent pas déjà. Ses questions utilisent le langage du lecteur, et chaque réponse de 30 à 60 mots se tient d’elle-même. L’élément live ci-dessous est rendu à partir du frontmatter [[faq]] de cette page plutôt que dupliqué dans le corps Markdown.

Les questions visibles ci-dessus et leurs données structurées FAQPage partagent une source unique. Modifier une entrée du frontmatter change les deux représentations, ce qui évite qu’une réponse soignée de la page ne s’éloigne de la version lisible par machine.

Pourquoi cet élément est important

Les lecteurs arrivent souvent à la fin d’une page avec une incertitude précise plutôt qu’un besoin d’explication complète supplémentaire. Un acheteur peut comprendre ce qu’un produit fait mais se demander encore si la configuration nécessite une carte bancaire. Une personne suivant une procédure peut connaître les étapes mais avoir besoin de confirmer ce qui se passe lorsqu’une entrée obligatoire est manquante. Une FAQ offre à ces questions fréquentes de dernière minute un emplacement prévisible sans forcer chaque lecteur à parcourir une autre longue section.

L’élément fonctionne parce que le wording des questions est un indice de reconnaissance. Un lecteur qui parcourt « Puis-je exporter les données ? » peut identifier sa propre préoccupation plus rapidement qu’il ne peut interpréter un titre vague tel que « Informations complémentaires ». La réponse résout ensuite cette préoccupation immédiatement. C’est de la psychologie du lecteur, pas de la décoration : le composant réduit la distance entre un doute spécifique et sa résolution.

Une FAQ crée également des paires question-réponse délimitées pour l’extraction automatique. L’extractibilité par machine signifie qu’un logiciel peut isoler une unité et préserver son sens en dehors de la page complète. Une question réelle suivie d’une réponse autonome est plus facile à identifier pour les systèmes de recherche, la recherche interne, les outils d’assistance et les agents d’IA qu’une réponse cachée dans un paragraphe de clôture divers. La délimitation n’est utile que lorsque le langage reste explicite ; « Oui, comme décrit ci-dessus » est visuellement dans une FAQ mais devient inutile une fois extrait.

Le frontmatter est la source de publication parce que les mêmes enregistrements doivent alimenter trois usages : le bloc visible, les données structurées FAQPage et l’analyse au niveau du corpus. L’analyse au niveau du corpus signifie interroger toutes les pages en tant qu’ensemble — par exemple, trouver chaque réponse concernant l’annulation ou vérifier quels types de pages dépassent systématiquement six questions. Conserver les entrées dans des enregistrements typés [[faq]] rend ces vérifications possibles. Copier les questions dans le corps crée deux versions modifiables et invite à la dérive.

Quand l’utiliser

Utilisez une FAQ lorsque la recherche révèle plusieurs questions récurrentes qui sont pertinentes pour la page mais trop spécifiques pour justifier des sections entières. Les bons candidats clarifient les cas limites, l’éligibilité, la compatibilité, le timing, les définitions que les lecteurs confondent couramment, les objections d’achat ou une prochaine action sûre. Chaque question doit aider le même public à accomplir la décision ou la tâche principale de la page.

La recherche de questions précède la rédaction. Recueillez le langage exact à partir des suggestions de recherche, de la recherche interne du site, des tickets d’assistance, des notes d’appels commerciaux, des discussions communautaires et des prompts IA suivis. Le suivi des prompts est utile car il enregistre les questions qu’une entreprise choisit de surveiller sur les moteurs d’IA ; les prompts répétés peuvent révéler comment les prospects s’informent sur une catégorie, une fonctionnalité ou une comparaison. L’enregistrement est une preuve de wording et de demande, pas une permission d’imposer un prompt non pertinent sur une page.

N’utilisez pas une FAQ simplement parce qu’un modèle en fournit une. Les questions inventées comme « Pourquoi notre plateforme est-elle géniale ? » sont reconnaissables comme du contenu marketing déguisé en question. Les fragments de mots-clés comme « avantages du schéma FAQ ? » ne ressemblent pas à ce qu’un lecteur dirait. Les deux affaiblissent la confiance et n’apprennent que peu de choses aux machines sur un besoin réel d’information.

Une FAQ n’est pas un fourre-tout pour les paragraphes qui n’ont pas trouvé leur place dans le plan. Si une réponse introduit un argument central, explique une étape obligatoire, porte la preuve la plus solide de la page ou nécessite plus de 60 mots, elle fait un vrai travail et mérite probablement une section nommée. Déplacez-la dans la structure principale. La FAQ peut alors répondre à la question de suivi plus restreinte qui subsiste.

Ne répétez pas l’article sous forme de questions. « Qu’est-ce que X ? », « Pourquoi X est-il important ? » et « Comment fonctionne X ? » sont de mauvaises questions de clôture lorsque ce sont déjà les trois premières sections de la page. La répétition allonge la page sans augmenter la couverture, et elle risque de produire des réponses légèrement différentes à la même question.

L’erreur fréquente est une question pertinente dont la réponse est centrale. Sur une page de type symptôme, « Quand est-ce grave ? » peut sembler une question FAQ naturelle, mais les signes d’alerte concernent la sécurité et doivent apparaître dans le corps principal où chaque lecteur les rencontre. La FAQ ne peut répéter ni la liste d’alerte ni un résumé plus faible. Utilisez plutôt une question étroite non résolue, par exemple si une circonstance particulière change la prochaine action recommandée.

Où le placer

La FAQ est un élément de clôture car son rôle est de résoudre les questions résiduelles après que la page a fourni sa réponse principale. Placez-la après le corps substantiel, les exemples et les preuves à l’appui. Placez les sources immédiatement avant lorsqu’elles sont nécessaires à la FAQ ; placez l’appel à l’action principal et les liens vers du contenu connexe après elle. Cette séquence permet au lecteur de lever l’incertitude finale avant de décider quoi faire ensuite.

Ne placez pas la FAQ de production directement sous le hero, à l’intérieur de l’introduction, entre les étapes, ou entre une affirmation et sa preuve. Le bloc live en haut de cette spécification est une démonstration requise par la bibliothèque d’éléments, pas le placement prescrit pour les pages normales.

Utilisez un bloc FAQ par page. Il ne peut pas se trouver à côté d’un second accordéon, d’une section « questions fréquentes » contenant le même contenu, ou d’un récapitulatif reformulé en questions. Évitez de le placer à côté d’une longue liste de glossaire : deux ensembles denses de courtes entrées entrent en compétition pour le même comportement de balayage. Si les deux sont nécessaires, gardez les définitions dans les sections de corps pertinentes et réservez le bloc de clôture pour les questions non résolues.

Anatomie

La capture d’écran légendée sépare les régions sémantiques du traitement visuel. La légende reste dans cette page pour que ses étiquettes restent lisibles lorsque l’image est redimensionnée ou remplacée.

1. Titre de section : Désigne l’ensemble comme des questions fréquemment posées ; c’est un véritable titre dans la hiérarchie du document.
2. Question : Utilise les mots du lecteur sous forme de phrase interrogative complète et se termine par un point d’interrogation.
3. Contrôle de divulgation : Sur les variantes repliables, le bouton opérable expose si sa réponse est développée et identifie la zone de réponse contrôlée.
4. Réponse : Donne d’abord la réponse directe, puis une qualification, distinction ou prochaine action utile.
5. Limite d’élément : Maintient visuellement et programmatiquement chaque question associée à exactement une réponse.
6. Enregistrement du frontmatter : La paire source non visuelle associant question et answer ; elle alimente à la fois la présentation et la sortie FAQPage.

Exemples de conception

Les variantes changent la présentation, pas la propriété du contenu. Chaque version lit les mêmes enregistrements [[faq]] et préserve les mêmes paires question-réponse.

Variante responsive standard

Le bureau affiche les questions et réponses dans des colonnes alignées ; les écrans plus petits utilisent des contrôles de divulgation pour économiser l’espace vertical. C’est le comportement par défaut lorsque le système de conception fournit un comportement responsive.

Variante mobile repliée

Les questions restent visibles comme des boutons et les réponses s’ouvrent sur place. Le contrôle doit communiquer l’état développé, conserver l’accès clavier et garder la réponse adjacente dans l’ordre de lecture.

Variante de stress avec question longue

Une question naturelle peut s’étendre sur deux lignes. La disposition doit préserver le point d’interrogation, la cible du contrôle et l’alignement de la réponse sans troncature.

État sans FAQ

Lorsqu’il n’y a pas de questions recherchées, n’affichez rien. Ne montrez pas de titre vide, de ligne d’espace réservé ou de contenu générique généré automatiquement.

Paramètres

Les paramètres sont le contrat de contenu. Les limites existent pour que chaque paire reste extractible et pour empêcher l’élément de clôture de devenir un second article.

La référence de preuve n’a pas besoin d’apparaître publiquement, mais elle doit survivre à la révision éditoriale. Un identifiant de ticket d’assistance, un lien de note d’appel, une exportation de requête ou un enregistrement de prompt suivi suffisent. « Le rédacteur y a pensé » ne suffit pas.

Syntaxe et exemples de code

Les trois formes traitent les entrées FAQ comme des métadonnées structurées de page. L’instruction de rendu ne contient aucune question ou réponse dupliquée.

Directive Markdown portable

:::faq{source="frontmatter" heading="Frequently asked questions"}
:::

Le modèle de document portable stocke les enregistrements comme métadonnées de page :

[[faq]]
question = "Can I export the report as a CSV?"
answer = "Yes. Export creates a CSV containing the report's current dataset. Check the export scope before sharing it, because screen filters and account permissions can affect which records are included."

Shortcode Hugo

{{< faq-side-by-side title="Frequently asked questions" >}}{{< /faq-side-by-side >}}

Le shortcode Hugo lit .Page.Params.faq ; il ne reçoit pas de corps JSON. Ajouter des éléments en ligne créerait une seconde source et est interdit pour cet élément.

Bloc ou shortcode WordPress

<!-- wp:amicited/faq {"source":"post-meta","heading":"Frequently asked questions"} /-->

[amicited_faq source="post-meta" heading="Frequently asked questions"]

Dans WordPress, chaque question et réponse appartient à des métadonnées de publication répétables utilisées à la fois par le moteur de rendu du bloc et l’émetteur JSON-LD. Coller les mêmes paires dans le HTML du bloc ou le corps du shortcode échoue à la parité même lorsque la page semble correcte.

Exemples

Bon exemple

Puis-je modifier la période de déclaration après avoir exporté le rapport ?
Oui. Modifiez la période de déclaration dans le rapport, puis créez un nouvel export pour que le fichier reflète la plage révisée. Un CSV existant est un instantané statique et ne se mettra pas à jour automatiquement lorsque les filtres du tableau de bord changeront ultérieurement.

Cela fonctionne parce que la question ressemble à quelque chose qu’un utilisateur demanderait après avoir rencontré le flux d’exportation. La première phrase répond « oui » et énonce l’action. La deuxième explique la limite conséquentielle : le fichier précédent ne se met pas à jour tout seul. Avec 30 mots, la réponse est complète sans devenir un tutoriel caché.

Mauvais exemple

Export CSV rapport téléchargement ?
Comme mentionné ci-dessus, notre plateforme puissante rend les exportations faciles. Consultez la section reporting pour plus d’informations sur toutes les excellentes options qui s’offrent à vous.

La question est un fragment de mot-clé plutôt qu’un langage parlé. La réponse ne dit pas si l’export est possible, dépend d’un contexte absent, ajoute une affirmation promotionnelle non étayée et renvoie le lecteur ailleurs. Reformuler seul ne suffit pas ; le rédacteur doit vérifier une question réelle et fournir le comportement réel.

Un second mauvais motif est une réponse de 180 mots contenant des prérequis, cinq étapes et un avertissement. Même si chaque phrase est exacte, ce contenu appartient à une section de procédure. La FAQ devrait répondre à la question résiduelle plus étroite ou être supprimée.

Balisage de schéma et accessibilité

Le balisage de schéma est un code standardisé lisible par machine qui identifie le sens et les relations du contenu de la page. Les entrées FAQ correspondent à un FAQPage de Schema.org. Chaque question visible devient un Question dans mainEntity ; sa réponse devient le acceptedAnswer avec le type Answer et une valeur text. Le site émet cette structure sous forme de JSON-LD , un format basé sur JSON pour les données structurées liées.

Le balisage doit correspondre exactement au contenu visible en termes de sens et de wording. N’ajoutez pas de question uniquement dans le schéma, ne raccourcissez pas la réponse visible uniquement dans le balisage, et ne laissez pas une ancienne réponse dans JSON-LD après avoir modifié la page. La règle du seul frontmatter empêche ces échecs en dérivant les deux sorties du même enregistrement. Les données structurées décrivent le contenu ; elles ne compensent pas un contenu maigre, inventé ou caché, et elles ne garantissent pas un résultat de recherche enrichi.

L’accessibilité dépend du comportement de divulgation. Une divulgation est un contrôle qui affiche ou masque le contenu associé. La question doit être un button natif lorsqu’elle active une réponse, avec aria-expanded reflétant l’état actuel et aria-controls pointant vers l’identifiant unique de la réponse. ARIA, Accessible Rich Internet Applications, fournit des états et des relations lorsque le HTML seul ne les exprime pas.

Les utilisateurs clavier doivent pouvoir atteindre chaque question, l’ouvrir avec Entrée ou Espace, et continuer dans la page dans un ordre logique. Le focus doit rester visible. La réponse doit suivre sa question dans l’ordre du document, et les titres ne doivent pas sauter de niveaux. Ne vous fiez pas uniquement à une rotation de chevron, une couleur ou une animation comme seul signal d’état développé. Si les réponses sont toujours visibles sur le bureau, elles doivent néanmoins rester associées à leurs questions via dt et dd ou une relation sémantique équivalente.

Règles de rédaction

Utilisez quatre à six questions dans une FAQ typique. Quatre est le minimum pratique car moins de questions justifient rarement une interface de clôture séparée ; une à trois réponses peuvent généralement être placées à côté des sections de corps pertinentes. Six est le plafond pratique car un ensemble plus long devient difficile à parcourir et signale souvent que des sujets majeurs ont été retenus de l’article. Les exceptions nécessitent des preuves : un produit réglementé peut nécessiter plus de questions d’éligibilité spécifiques, tandis qu’une page produit concise peut omettre complètement le bloc.

Formulez chaque entrée comme une véritable question dans les mots du lecteur. Préservez le vocabulaire utile de la source, mais supprimez les données personnelles, les détails spécifiques au compte et le bruit conversationnel. Ne combinez les vrais doublons que lorsque leurs réponses sont également identiques. « Puis-je annuler mensuellement ? » et « Vais-je recevoir un remboursement ? » peuvent survenir dans le même appel commercial, mais ils représentent des décisions différentes et ne doivent pas être fusionnés.

Écrivez 30 à 60 mots par réponse. La première phrase répond à la question ; la seconde développe la condition, distinction, raison ou prochaine action la plus utile. Nommez le sujet pour que la réponse survive à l’extraction. N’écrivez jamais « oui, c’est le cas », « voir ci-dessus », « comme discuté précédemment » ou « contactez-nous pour en savoir plus » comme réponse complète.

Utilisez un ton calme et factuel. Définissez un terme technique nécessaire dans la réponse, mais n’accumulez pas de jargon. Incluez un lien uniquement lorsque la destination permet la prochaine action ou fournit des détails essentiels ; la réponse visible doit néanmoins être complète sans le suivre. N’incluez pas de témoignages, slogans commerciaux, mots-clés non pertinents, tableaux imbriqués, procédures en plusieurs étapes ou affirmations sans fondement.

Chaque type de publication déclare des catégories d’intention que sa FAQ doit couvrir. Une catégorie d’intention est le type de décision derrière une question, pas un thème de mot-clé. Une page de type symptôme pourrait déclarer les catégories cause, auto-traitement, gravité et achat, avec au moins une question couvrant les signes d’alerte. Parce que les signes d’alerte concernent la sécurité, le corps principal doit encore les présenter ; la vérification de catégorie FAQ garantit que les questions de clôture ne traitent pas uniquement de sujets commerciaux faciles.

Généralisez cette méthode plutôt que de copier ces quatre catégories partout. Une comparaison peut nécessiter les catégories coût de changement, compatibilité, contrat et meilleure adéquation. Un guide pratique peut nécessiter les catégories prérequis, récupération après échec, vérification d’achèvement et maintenance. La couverture est réussie lorsque les catégories déclarées reflètent l’intention de recherche de la page et des preuves réelles, pas lorsque chaque page répète un ensemble universel de questions.

Types de publications qui l’utilisent

Le postTypes du frontmatter enregistre les jonctions enregistrées. Le tableau transforme chaque jonction en règle de couverture et de placement ; il ne rend pas la FAQ obligatoire lorsque la recherche ne trouve aucune question résiduelle utile.

« Généralement » signifie que le type de publication crée couramment des questions résiduelles, pas que les rédacteurs doivent les fabriquer. Le seuil de preuve s’applique toujours.

Liste de contrôle QA

Un relecteur vérifie les enregistrements sources avant de juger le style visuel.

• Source unique : Chaque paire visible provient du frontmatter [[faq]] ; aucune question ou réponse n’est dupliquée dans le corps Markdown.
• Demande réelle : Chaque question a une source traçable dans les suggestions de recherche, la recherche interne, l’assistance, les ventes, la recherche ou les prompts IA suivis.
• Formulation naturelle : Chaque question est une question grammaticale dans le langage du lecteur, pas un fragment de mot-clé ou une affirmation produit.
• Réponse directe : La première phrase résout la question ; la seconde ajoute la qualification ou l’action la plus utile.
• Sens autonome : Aucune réponse ne dépend de « ci-dessus », « précédemment », « ceci » ou d’un autre référent manquant.
• Longueur : Chaque réponse contient 30 à 60 mots ; chaque question reste sous 120 caractères sauf si le wording naturel en requiert réellement plus.
• Nombre : Le bloc contient normalement quatre à six entrées, avec une raison enregistrée pour toute exception.
• Pas de sections déplacées : Aucune réponse ne contient d’argument central, de procédure obligatoire, d’avertissement majeur ou d’ensemble de preuves appartenant au corps principal.
• Pas de répétition : Les questions ne reformulent pas des titres déjà complètement répondus, et les réponses ne résument pas à nouveau l’article.
• Couverture déclarée : L’ensemble couvre les catégories d’intention requises du type de publication, y compris une catégorie de risque ou d’avertissement lorsque le sujet l’exige.
• Placement correct : Le bloc de production suit le contenu substantiel et les sources, et précède l’appel à l’action principal et le contenu connexe.
• Parité visible-schéma : FAQPage.mainEntity contient les mêmes questions et réponses que le bloc rendu, sans entrées cachées ou obsolètes.
• Contrôles accessibles : Les boutons basculent exposent l’état développé, les identifiants de réponse sont uniques, le fonctionnement clavier est opérationnel, le focus est visible et l’ordre du document reste logique.
• État vide : Une page sans questions qualifiées n’affiche ni titre FAQ ni contenu d’espace réservé.
• État des captures d’écran : Les commentaires de capture restent des commentaires jusqu’à ce que leurs ressources nommées existent ; aucun chemin inexistant n’est rendu comme image.

FAQ

L’exemple live en haut et les données FAQPage sont générés à partir des cinq enregistrements [[faq]] révisés dans le frontmatter de cette page. Ils couvrent la nécessité, la source, la longueur des réponses, le wording autonome et la parité visible-schéma sans maintenir une seconde copie ici.