FAQPage-schema: een praktische gids
FAQPage-opmaak vertelt een machine welk deel van een pagina een vraag is en welk deel het antwoord. De rich results ervoor zijn beperkt, maar de waarde voor interpretatie is niet verdwenen, en het blijft een van de goedkoopste dingen om goed te doen.
Gestructureerde data had een paar verwarrende jaren. Of FAQ-opmaak een rich result opleverde, werd sterk ingeperkt, veel teams haalden de opmaak daarop weg, en veel advies online beschrijft nog de oude situatie. Het loont om twee dingen die de opmaak doet uit elkaar te houden.
Wat het nog doet, los van rich results
- Het zegt ondubbelzinnig welke tekst de vraag is en welke het antwoord, zodat een ophaalsysteem dat niet hoeft af te leiden uit kopniveaus.
- Het geeft elk antwoord een eigen, aanwijsbare identiteit, en dat telt als een pagina er meerdere heeft.
- Het wordt gelezen door systemen ver buiten één zoekmachine: andere zoekmachines, assistenten, interne zoekfuncties en alles wat op een crawl gebouwd is.
- Het overleeft een herontwerp. Opmaak die betekenis beschrijft, leeft langer dan opmaak die lay-out beschrijft.
FAQPage of QAPage?
| Type | Gebruik als | Gebruik niet als |
|---|---|---|
| FAQPage | Jij zowel de vraag als het antwoord schreef, en het antwoord vaststaat | De pagina een forumdraad is of concurrerende antwoorden heeft |
| QAPage | Eén vraag, mogelijk meerdere antwoorden, meestal ingestuurd door gebruikers | Je je eigen vaststaande helpcontent opmaakt |
Voor een kennisbank van een bedrijf is het antwoord bijna altijd FAQPage op de index en, waar elke vraag een eigen pagina heeft, een graaf met één vraag op die pagina. Een hubpagina met dertig vragen kan ze alle dertig dragen; de afzonderlijke pagina's dragen hun eigen.
Fouten waardoor opmaak genegeerd wordt
De meest voorkomende reden dat opmaak genegeerd wordt. Wat in de JSON staat, moet zichtbaar zijn op de weergegeven pagina.
"Klaar om te beginnen?" is geen vraag die de pagina beantwoordt. Systemen herkennen dit patroon en het kost meer dan het oplevert.
Het werkt vaak genoeg om veilig te voelen en faalt stil als een pagina opgehaald wordt zonder scripts uit te voeren, en dat is precies wanneer het ertoe deed.
Het antwoord wordt bewerkt, de JSON niet. Genereer de opmaak uit dezelfde bron als de tekst, zodat ze niet kunnen afwijken.
Een pagina die zichzelf beschrijft als artikel, FAQ, product en handleiding, beschrijft zichzelf als geen van alle.
Opmaak wint het nooit van de tekst. Hij verduidelijkt hem alleen.
Wat je ernaast zet
Drie grafen verdienen hun plek op bijna elke kennispagina: een Organization-graaf, één keer gedeclareerd en overal naar verwezen, zodat een machine de pagina's aan een bedrijf kan koppelen; een WebSite-graaf, zodat de site zelf een entiteit is; en een BreadcrumbList, zodat de plek van de pagina in de structuur benoemd wordt in plaats van geraden. Auteur- en datumvelden horen echte mensen en echte datums te zijn.
Vragen die dit beantwoordt
Dat is flink ingeperkt en de meeste sites zien de uitgeklapte FAQ-weergave niet meer. De opmaak blijft de interpretatie door zoek- en assistentsystemen dienen, en dat is een apart voordeel.
Nee. De opgemaakte tekst moet op de zichtbare pagina staan. Gedeeltelijke of geparafraseerde opmaak is de gebruikelijke reden dat gestructureerde data genegeerd wordt.
Ja, waar het antwoord dat verdient. De index laat een machine de hele bibliotheek in één keer zien; de afzonderlijke pagina is waar een citatie nuttig kan landen.