FAQ-secties: opmaak, schema en voorbeelden

Een FAQ is een afsluitend inhoudselement dat een kleine, op bewijs gebaseerde set vragen beantwoordt die de hoofdsecties van de pagina niet al oplossen. De vragen gebruiken de taal van de lezer en elk antwoord van 30–60 woorden staat op zichzelf. Het live element hieronder wordt gegenereerd uit de [[faq]]-frontmatter van deze pagina in plaats van gedupliceerd in de Markdown-tekst.

De zichtbare vragen hierboven en hun FAQPage-gestructureerde gegevens delen één bron. Het bewerken van een frontmatter-item wijzigt beide weergaven, wat voorkomt dat een gepolijst antwoord op de pagina wegdrijft van de machineleesbare versie.

Waarom dit element belangrijk is

Lezers bereiken vaak het einde van een pagina met een specifieke onzekerheid in plaats van een behoefte aan een nieuwe volledige uitleg. Een koper begrijpt misschien wat een product doet maar vraagt zich nog af of het instellen een creditcard vereist. Iemand die een procedure volgt, kent misschien de stappen maar moet bevestigen wat er gebeurt wanneer een vereiste invoer ontbreekt. Een FAQ geeft die veelvoorkomende, laat-stadium vragen een voorspelbare plek zonder elke lezer door een nieuwe lange sectie te dwingen.

Het element werkt omdat vraagformulering een herkenningssignaal is. Een lezer die ‘Kan ik de gegevens exporteren?’ scant, kan hun eigen zorg sneller identificeren dan ze een vage kop zoals ‘Aanvullende informatie’ kunnen interpreteren. Het antwoord lost die zorg vervolgens onmiddellijk op. Dit is lezerspsychologie, geen decoratie: het onderdeel verkleint de afstand tussen een specifieke twijfel en de oplossing ervan.

Een FAQ creëert ook begrensde vraag-en-antwoordparen voor machine-extractie. Machine-extracteerbaarheid betekent dat software een eenheid kan isoleren en de betekenis ervan buiten de volledige pagina kan behouden. Een echte vraag gevolgd door een zelfstandig antwoord is gemakkelijker te identificeren voor zoeksystemen, interne zoekopdrachten, ondersteuningstools en AI-agents dan een antwoord verborgen in een algemene afsluitende alinea. De grens helpt alleen wanneer de taal expliciet blijft; ‘Ja, zoals hierboven beschreven’ staat visueel in een FAQ maar wordt nutteloos bij extractie.

Frontmatter is de publicatiebron omdat dezelfde records drie toepassingen moeten voeden: het zichtbare blok, FAQPage-gestructureerde gegevens en analyse op corpusniveau. Analyse op corpusniveau betekent het doorzoeken van alle pagina’s als een verzameling — bijvoorbeeld het vinden van elk antwoord over annulering of het controleren welke paginatypes routinematig meer dan zes vragen hebben. Het bewaren van items in getypte [[faq]]-records maakt die controles mogelijk. Het kopiëren van de vragen in de tekst creëert twee bewerkbare versies en nodigt uit tot afwijking.

Wanneer te gebruiken

Gebruik een FAQ wanneer onderzoek verschillende terugkerende vragen aan het licht brengt die relevant zijn voor de pagina maar te specifiek zijn om volledige secties te rechtvaardigen. Goede kandidaten verduidelijken randgevallen, geschiktheid, compatibiliteit, timing, definities die lezers routinematig verwarren, aankoopbezwaren of een veilige vervolgactie. Elke vraag moet dezelfde doelgroep helpen de primaire beslissing of taak van de pagina te voltooien.

Vragenonderzoek komt vóór het schrijven. Verzamel exacte taal uit zoeksuggesties, interne sitezoekopdrachten, ondersteuningstickets, aantekeningen van verkoopgesprekken, communitydiscussies en bijgehouden AI-prompts. Prompt Tracking is nuttig omdat het de vragen registreert die een bedrijf kiest om te volgen in AI-engines; herhaalde prompts kunnen onthullen hoe prospects vragen stellen over een categorie, functie of vergelijking. De registratie is bewijs van formulering en vraag, geen toestemming om een niet-gerelateerde prompt aan een pagina op te dringen.

Gebruik geen FAQ alleen omdat een sjabloon er een biedt. Verzonnen vragen zoals ‘Waarom is ons platform geweldig?’ zijn herkenbaar als marketingtekst met een vraagteken. Zoekwoordfragmenten zoals ‘FAQ-schema voordelen?’ klinken niet als een lezer. Beide verzwakken het vertrouwen en leren machines weinig over een daadwerkelijke informatiebehoefte.

Een FAQ is geen dumpplaats voor alinea’s die niet in de opzet pasten. Als een antwoord een kernargument introduceert, een vereiste stap uitlegt, het sterkste bewijs van de pagina draagt of meer dan 60 woorden nodig heeft, doet het echt werk en verdient het waarschijnlijk een benoemde sectie. Verplaats het naar de hoofdstructuur. De FAQ kan dan de kleinere vervolgvraag beantwoorden die overblijft.

Herhaal het artikel niet in vraagvorm. ‘Wat is X?’, ‘Waarom is X belangrijk?’ en ‘Hoe werkt X?’ zijn slechte afsluitende vragen wanneer dat al de eerste drie secties van de pagina zijn. Herhaling maakt de pagina langer zonder de dekking te vergroten en riskeert licht verschillende antwoorden op dezelfde vraag te produceren.

De veelgemaakte fout is een relevante vraag waarvan het antwoord centraal staat. Op een symptoomstijl-pagina lijkt ‘Wanneer is dit ernstig?’ misschien een natuurlijke FAQ, maar waarschuwingssignalen beïnvloeden de veiligheid en moeten in de hoofdtekst verschijnen waar elke lezer ze tegenkomt. De FAQ kan noch de waarschuwingslijst, noch een zwakkere samenvatting herhalen. Gebruik in plaats daarvan een specifieke onbeantwoorde vraag, zoals of een bepaalde omstandigheid de aanbevolen vervolgactie verandert.

Waar te plaatsen

FAQ is een afsluitend element omdat het tot doel heeft resterende vragen op te lossen nadat de pagina het hoofdantwoord heeft gegeven. Plaats het na de inhoudelijke tekst, voorbeelden en ondersteunend bewijs. Plaats bronnen er direct voor wanneer de FAQ van die bronnen afhankelijk is; plaats de primaire call-to-action en gerelateerde-inhoudlinks erna. Deze volgorde laat de lezer de laatste onzekerheid oplossen voordat hij beslist wat te doen.

Plaats de productie-FAQ niet direct onder de hero, in de inleiding, tussen stappen of tussen een bewering en het bewijs ervan. Het live blok bovenaan deze specificatie is een demonstratie vereist door de elementbibliotheek, niet de voorgeschreven plaatsing voor normale pagina’s.

Gebruik één FAQ-blok per pagina. Het mag niet naast een tweede accordeon, een ‘veelgestelde vragen’-sectie met hetzelfde materiaal of een als vragen herschreven samenvatting staan. Vermijd plaatsing naast een grote woordenlijst: twee dichte sets korte items concurreren om hetzelfde scan-gedrag. Als beide nodig zijn, houd definities dan in de relevante lichaamssecties en reserveer het afsluitende blok voor onbeantwoorde vragen.

Anatomie

Het gelabelde schermbeeld scheidt de semantische regio’s van de visuele behandeling. De legenda blijft op deze pagina zodat de labels leesbaar blijven wanneer de afbeelding wordt vergroot of vervangen.

1. Sectiekop: Benoemt de verzameling als veelgestelde vragen; het is een echte kop in de documenthiërarchie.
2. Vraag: Gebruikt de woorden van de lezer als een complete vragende zin en eindigt met een vraagteken.
3. Open/dicht-regelaar: Bij inklapbare varianten geeft de bedienbare knop aan of het antwoord is uitgevouwen en identificeert het geregelde antwoordgebied.
4. Antwoord: Geeft eerst het directe antwoord, daarna een nuttige kwalificatie, onderscheid of vervolgactie.
5. Itemgrens: Houdt visueel en programmatisch elke vraag aan precies één antwoord gekoppeld.
6. Frontmatter-record: De niet-visuele bron die question en answer koppelt; het voedt zowel de presentatie als de FAQPage-uitvoer.

Ontwerpvoorbeelden

De varianten wijzigen de presentatie, niet het eigendom van de inhoud. Elke versie leest dezelfde [[faq]]-records en behoudt dezelfde vraag-antwoordparen.

Standaard responsieve variant

Desktop toont vragen en antwoorden in uitgelijnde kolommen; kleinere schermen gebruiken open/dicht-regelaars om verticale ruimte te besparen. Dit is de standaard wanneer het ontwerpsysteem responsief gedrag levert.

Ingeklapte mobiele variant

Vragen blijven zichtbaar als knoppen en antwoorden openen op dezelfde plek. De regelaar moet de uitgevouwen status communiceren, toetsenbordtoegang behouden en het antwoord aangrenzend in leesvolgorde houden.

Lange-vraag stressvariant

Een natuurlijke vraag kan over twee regels lopen. De lay-out moet het vraagteken, het regelaardoel en de uitlijning van het antwoord behouden zonder afkapping.

Geen-FAQ-status

Wanneer er geen onderzochte vragen zijn, geef dan niets weer. Toon geen lege kop, placeholderrij of gegenereerde algemene inhoud.

Parameters

Parameters zijn het inhoudscontract. Limieten bestaan om elk paar extraheerbaar te houden en te voorkomen dat het afsluitende element een tweede artikel wordt.

De bewijsreferentie hoeft niet openbaar te verschijnen, maar moet redactionele toetsing doorstaan. Een ondersteuningsticket-ID, verkoopgesprek-link, query-export of bijgehouden prompt-record is voldoende. “De schrijver bedacht het” is dat niet.

Syntax en codevoorbeelden

Alle drie de vormen behandelen FAQ-items als gestructureerde paginametadata. De renderinstructie bevat geen gedupliceerde vragen of antwoorden.

Draagbare Markdown-richtlijn

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

Het draagbare documentmodel slaat de records op als paginametadata:

[[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."

Hugo shortcode

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

De Hugo shortcode leest .Page.Params.faq; het ontvangt geen JSON-tekst. Het toevoegen van inline-items zou een tweede bron creëren en is verboden voor dit element.

WordPress-blok of shortcode

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

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

In WordPress hoort elke vraag en antwoord in herbruikbare postmetadata die wordt gebruikt door zowel de blokrenderer als de JSON-LD-emitter. Het plakken van dezelfde paren in blok-HTML of shortcode-tekst schendt de gelijkheid, zelfs wanneer de pagina er correct uitziet.

Voorbeelden

Goed voorbeeld

Kan ik de rapportageperiode wijzigen na het exporteren van het rapport?
Ja. Wijzig de rapportageperiode in het rapport en maak vervolgens een nieuwe export zodat het bestand de herziene periode weergeeft. Een bestaande CSV is een statische momentopname en wordt niet automatisch bijgewerkt wanneer dashboardfilters later veranderen.

Dit werkt omdat de vraag klinkt als iets dat een gebruiker zou vragen na het tegenkomen van de exportworkflow. De eerste zin antwoordt ‘ja’ en vermeldt de actie. De tweede legt de consequente grens uit: het eerdere bestand werkt zichzelf niet bij. Met 30 woorden is het antwoord compleet zonder een verborgen handleiding te worden.

Slecht voorbeeld

Rapport export CSV-download?
Zoals hierboven vermeld, maakt ons krachtige platform exporteren gemakkelijk. Zie de rapportagesectie voor meer informatie over alle geweldige opties die beschikbaar zijn.

De vraag is een zoekwoordfragment in plaats van gesproken taal. Het antwoord vermeldt niet of exporteren mogelijk is, is afhankelijk van afwezige context, voegt een niet-ondersteunde promotionele bewering toe en stuurt de lezer elders. Alleen herformuleren is niet voldoende; de schrijver moet een echte vraag verifiëren en het daadwerkelijke gedrag geven.

Een tweede slecht patroon is een antwoord van 180 woorden met vereisten, vijf stappen en een waarschuwing. Zelfs als elke zin accuraat is, hoort dat materiaal thuis in een proceduresectie. De FAQ moet de smallere resterende vraag beantwoorden of worden verwijderd.

Schema-opmaak en toegankelijkheid

Schema-opmaak is gestandaardiseerde machineleesbare code die de betekenis en relaties van paginainhoud identificeert. FAQ-items worden toegewezen aan een Schema.org FAQPage. Elke zichtbare vraag wordt een Question in mainEntity; het antwoord wordt de acceptedAnswer met type Answer en een text-waarde. De site zendt deze structuur uit als JSON-LD , een JSON-gebaseerd formaat voor gekoppelde gestructureerde gegevens.

Opmaak moet exact overeenkomen met zichtbare inhoud in betekenis en formulering. Voeg geen schema-only-vraag toe, verkort het zichtbare antwoord niet alleen in de opmaak en laat geen oud antwoord in JSON-LD achter na het bewerken van de pagina. De frontmatter-only-regel voorkomt deze fouten door beide uitvoeren uit hetzelfde record af te leiden. Gestructureerde gegevens beschrijven inhoud; ze compenseren niet voor dunne, verzonnen of verborgen inhoud en garanderen geen rijk zoekresultaat.

Toegankelijkheid hangt af van het open/dicht-gedrag. Een open/dicht-mechanisme is een regelaar die bijbehorende inhoud toont of verbergt. De vraag moet een native button zijn wanneer deze een antwoord in- of uitklapt, met aria-expanded die de huidige status weergeeft en aria-controls die naar het unieke ID van het antwoord verwijst. ARIA, Accessible Rich Internet Applications, levert statussen en relaties wanneer native HTML alleen deze niet uitdrukt.

Toetsenbordgebruikers moeten elke vraag kunnen bereiken, deze openen met Enter of Spatie en in logische volgorde door de pagina kunnen gaan. Focus moet zichtbaar blijven. Het antwoord moet na de vraag in de documentvolgorde komen en koppen mogen geen niveaus overslaan. Vertrouw niet op een draaiend pijltje, kleur of animatie als enige uitgevouwen-statussignaal. Als antwoorden altijd zichtbaar zijn op desktop, moeten ze nog steeds aan hun vragen zijn gekoppeld via dt en dd of een gelijkwaardige semantische relatie.

Schrijfregels

Gebruik vier tot zes vragen in een typische FAQ. Vier is de praktische ondergrens omdat minder vragen zelden een aparte afsluitende interface rechtvaardigen; een tot drie antwoorden kunnen meestal naast de relevante lichaamssecties worden geplaatst. Zes is de praktische bovengrens omdat een langere set moeilijk te scannen wordt en vaak aangeeft dat belangrijke onderwerpen uit het artikel zijn weggelaten. Uitzonderingen vereisen bewijs: een gereguleerd product kan meer specifieke geschiktheidsvragen nodig hebben, terwijl een beknopte productpagina het blok volledig kan weglaten.

Formuleer elk item als een echte vraag in de woorden van de lezer. Behoud nuttige woordenschat uit de bron, maar verwijder persoonlijke gegevens, accountspecifieke details en conversationele ruis. Combineer alleen echte duplicaten wanneer hun antwoorden ook hetzelfde zijn. ‘Kan ik maandelijks opzeggen?’ en ‘Krijg ik een terugbetaling?’ kunnen in hetzelfde verkoopgesprek voorkomen, maar vertegenwoordigen verschillende beslissingen en mogen niet worden samengevoegd.

Schrijf 30–60 woorden per antwoord. De eerste zin beantwoordt de vraag; de tweede werkt die uit met de meest nuttige voorwaarde, onderscheid, reden of vervolgactie. Noem het onderwerp zodat het antwoord extractie overleeft. Schrijf nooit ‘ja, dat doet het’, ‘zie hierboven’, ‘zoals eerder besproken’ of ’neem contact met ons op voor meer informatie’ als het complete antwoord.

Gebruik een rustige, feitelijke toon. Definieer een noodzakelijke technische term in het antwoord, maar stapel geen jargon. Voeg alleen een link toe wanneer de bestemming de vervolgactie mogelijk maakt of essentiële details levert; het zichtbare antwoord moet nog steeds compleet zijn zonder deze te volgen. Gebruik geen getuigenissen, verkoopslogans, niet-gerelateerde zoekwoorden, geneste tabellen, meerstapsprocedures of beweringen zonder onderbouwing.

Elk berichttype declareert intentiecategorieën die de FAQ moet dekken. Een intentiecategorie is het soort beslissing achter een vraag, geen zoekwoordthema. Een symptoomstijl-pagina kan categorieën declareren zoals oorzaak, zelfbehandeling, ernst en aankoop, met ten minste één vraag over waarschuwingssignalen. Omdat waarschuwingssignalen de veiligheid beïnvloeden, moet de hoofdtekst ze nog steeds presenteren; de FAQ-categoriecontrole zorgt ervoor dat de afsluitende vragen niet alleen gemakkelijke commerciële onderwerpen bespreken.

Generaliseer die methode in plaats van die vier categorieën overal te kopiëren. Een vergelijking heeft mogelijk categorieën nodig zoals overstapkosten, compatibiliteit, contract en beste geschiktheid. Een handleiding heeft mogelijk categorieën nodig zoals vereisten, herstel bij fouten, voltooiingscontrole en onderhoud. Dekking is succesvol wanneer de gedeclareerde categorieën de zoekintentie van de pagina en echt bewijs weerspiegelen, niet wanneer elke pagina een universele vraagsets herhaalt.

Berichttypes die het gebruiken

De postTypes-frontmatter registreert de geregistreerde koppelingen. De tabel zet elke koppeling om in een dekking- en plaatsingsregel; het maakt FAQ niet verplicht waar onderzoek geen nuttige resterende vragen vindt.

‘Meestal’ betekent dat het berichttype vaak resterende vragen creëert, niet dat redacteuren ze moeten verzinnen. De bewijsdrempel blijft van toepassing.

QA-checklist

Een beoordelaar controleert de bronrecords voordat hij de visuele stijl beoordeelt.

• Enkele bron: Elk zichtbaar paar komt uit [[faq]]-frontmatter; geen vraag of antwoord wordt gedupliceerd in de Markdown-tekst.
• Echte vraag: Elke vraag heeft een traceerbare bron in zoeksuggesties, sitezoekopdrachten, ondersteuning, verkoop, onderzoek of bijgehouden AI-prompts.
• Natuurlijke formulering: Elke vraag is een grammaticale vraag in de taal van de lezer, geen zoekwoordfragment of productclaim.
• Direct antwoord: De eerste zin beantwoordt de vraag; de tweede voegt de meest nuttige kwalificatie of actie toe.
• Zelfstandige betekenis: Geen antwoord is afhankelijk van ‘boven’, ’eerder’, ‘dit’ of een andere ontbrekende verwijzing.
• Lengte: Elk antwoord bevat 30–60 woorden; elke vraag blijft onder 120 tekens tenzij natuurlijke formulering echt meer vereist.
• Aantal: Het blok bevat normaal vier tot zes items, met een geregistreerde reden voor elke uitzondering.
• Geen verplaatste secties: Geen antwoord bevat een kernargument, vereiste procedure, belangrijke waarschuwing of bewijsset die in de hoofdtekst thuishoort.
• Geen herhaling: Vragen herhalen geen koppen die al volledig zijn beantwoord en antwoorden vatten het artikel niet opnieuw samen.
• Gedeclareerde dekking: De set dekt de vereiste intentiecategorieën van het berichttype, inclusief een risico- of waarschuwingscategorie waar het onderwerp er een vereist.
• Correcte plaatsing: Het productieblok volgt inhoudelijke tekst en bronnen, en gaat vooraf aan de primaire CTA en gerelateerde inhoud.
• Zichtbaar-schema-pariteit: FAQPage.mainEntity bevat dezelfde vragen en antwoorden als het weergegeven blok, zonder verborgen of verouderde items.
• Toegankelijke regelaars: Schakelknoppen geven de uitgevouwen status weer, antwoord-ID’s zijn uniek, toetsenbordbediening werkt, focus is zichtbaar en de documentvolgorde blijft logisch.
• Lege status: Een pagina zonder gekwalificeerde vragen toont geen FAQ-kop of placeholder-inhoud.
• Screenshotstatus: Bijschriften blijven opmerkingen totdat hun genoemde assets bestaan; geen niet-bestaand pad wordt als afbeelding weergegeven.

FAQ

Het live voorbeeld bovenaan en de FAQPage-gegevens worden gegenereerd uit de vijf beoordeelde [[faq]]-records in de frontmatter van deze pagina. Ze dekken noodzaak, bronvermelding, antwoordlengte, zelfstandige formulering en zichtbaar-schema-pariteit zonder een tweede kopie hier te onderhouden.