Content Frontmatter: Velden en SEO-metadata

Frontmatter is het paginaelement dat lezers nooit als één blok zien en waar elk publicatiesysteem van afhankelijk is. Het geeft een document een identiteit, weergavecontract, zoekpreview, eigenaarsrecord, datums en schema-ingangen. Kapotte frontmatter kan het verkeerde sjabloon selecteren, canonical-conflicten veroorzaken, de auteur verliezen of opmaak genereren die de pagina tegenspreekt.

Het levende voorbeeld is een record op documentniveau, weergegeven als code omdat frontmatter geen decoratief bodyvak mag worden.

+++
entity = "guide-how-to"
id = "reset-api-key"
title = "How to Reset an API Key"
seoTitle = "How to Reset an API Key Safely"
description = "Reset an API key safely, replace it in every dependent service, verify the new credential, and revoke the exposed key without avoidable downtime."
url = "/academy/reset-an-api-key/"
image = "/images/academy/reset-api-key.png"
imageAlt = "API key settings with the Rotate key action highlighted"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "reset API key", "rotate API key", "revoke API key" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/reset-an-api-key/"

[[faq]]
question = "Does rotating an API key revoke the old key immediately?"
answer = "Not necessarily. Confirm the provider's rotation behavior before changing dependent services."
+++

Waarom frontmatter bestaat

Voor een lezer vermindert metadata onzekerheid. Een precieze titel bepaalt de reikwijdte, een bruikbare beschrijving verdient de klik, identiteiten maken beweringen controleerbaar en datums onthullen of informatie mogelijk verouderd is. Deze signalen kunnen zwakke content niet compenseren, maar hun afwezigheid dwingt de lezer om te raden.

Voor machines vervangt frontmatter inferentie door benoemde waarden. Sjablonen wijzen velden toe aan browsertitels, canonical-links, persoonsrecords, datums, feeds, indexen en JSON-LD zonder proza te hoeven scannen. Dit is machine-uittrekselbaarheid: belangrijke feiten hebben een consistente locatie en type.

Volg de schrijfregels voor elementen: metadata hoort op documentniveau; lezersgerichte elementen horen in de body. Een byline kan worden weergegeven vanuit frontmatter, maar de gezaghebbende identificatie blijft daar.

Wanneer te gebruiken — en wanneer niet

Elke indexeerbare pagina heeft één frontmatter-record nodig voor identiteit, weergave en routering. Concepten hebben het nodig wanneer ze in productie gaan, zodat validatie vroeg kan falen.

Verberg artikelfeiten niet in frontmatter. Productbeperkingen, veiligheidswaarschuwingen, affiliate-disclosures, methoden en bronnen moeten zichtbaar blijven waar lezers ze kunnen beoordelen. Een gestructureerde waarde vervangt nooit een openbaarmaking.

Bijna-goed veroorzaakt de meeste schade:

• Onafhankelijk variërende navigatielabels, campagneteKsten en sociale bijschriften zijn kanaalinstellingen; overbelast title niet.
• Organisatiefeiten die voor de hele site gelden, horen in het organisatierecord van de site, niet gekopieerd naar elke pagina waar ze zullen afwijken.
• Een vraag-en-antwoordsectie hoort alleen in [[faq]] wanneer dezelfde content zichtbaar wordt weergegeven. Verborgen schema-only FAQ is ongeldig.
• Een onderwerplabel hoort in taxonomy; het mag de entity die het berichttype van het document identificeert niet vervangen.
• Een redirect hoort in de routeringsconfiguratie of een goedgekeurd aliases-veld. canonical identificeert de voorkeursversie; het verwijst geen bezoekers door.

Waar te plaatsen

Frontmatter begint bij de eerste byte met +++ en eindigt bij de overeenkomende afsluiting vóór de body. Geen kop, opmerking, notitie, shortcode of metadatablok mag eraan voorafgaan. TOML-velden en -arrays horen binnen dat ene record.

De body begint na de afsluitende begrenzing. Frontmatter kan niet tussen de H1 en inleiding zitten, naast een screenshot, binnen een component of aan het einde. Een byte-order mark of verdwaalde opmerking kan herkenning voorkomen. Dubbele sleutels, YAML-begrenzingen en tweede blokken zijn ongeldig.

Anatomie

De weergegeven legenda blijft op de pagina zodat deze onafhankelijk van de afbeelding leesbaar en vertaalbaar blijft:

1. Begrenzing: de openings- en sluitings-+++-begrenzingen definiëren de enige metadataregio.
2. Identiteit: entity, id, type en url vertellen systemen wat het document is en waar het zich bevindt.
3. Ontdekking: title, seoTitle, description, image, imageAlt en keywords ondersteunen previews en vindbaarheid.
4. Herkomst: date, updated, author en reviewedBy geven aan wie verantwoordelijk is en wanneer het werk geldig is gewijzigd.
5. Classificatie: taxonomy koppelt de pagina aan beheerde onderwerpcollecties zonder de identiteit opnieuw te definiëren.
6. Duplicatiebeheer: canonical benoemt de voorkeurs openbare URL wanneer elders gelijkwaardige versies bereikbaar zijn.
7. Gestructureerde collecties: elke [[faq]] creëert één getypeerd vraag-en-antwoordrecord voor zichtbare weergave en schema.

Ontwerpvoorbeelden

Frontmatter heeft datacontractvarianten, geen visuele stijlen. Screenshots koppelen bronrecords aan hun resulterende preview of byline.

Parameters

Dit zijn redactionele grenzen, zelfs als een parser meer accepteert. “Voorwaardelijk” betekent vereist wanneer de genoemde voorwaarde waar is.

Per-veldreferentie

Deze referentie definieert het publicatiecontract voor elk veld. “Vereist” betekent dat validatie de publicatie moet stoppen wanneer het veld of de geldige afleiding ervan ontbreekt. “Voorwaardelijk” betekent dat de vereiste wordt geactiveerd door een vastgesteld feit, zoals een afbeelding die wordt weergegeven of een onafhankelijke beoordeling die heeft plaatsgevonden. Een standaardwaarde is alleen veilig wanneer deze dezelfde betekenis produceert die een redacteur bewust zou hebben gekozen.

Identiteit en routering

title, h1 en seoTitle

• Doel — title geeft het document zijn duurzame redactionele naam. h1 bepaalt de belangrijkste kop op de pagina wanneer de lay-outcontext een andere formulering nodig heeft. seoTitle bepaalt de browser-/zoekmachine-titel wanneer de standaard een beknopte kwalificatie of merkvermelding nodig heeft. Door ze te scheiden wordt voorkomen dat een navigatielabel, paginakop en zoekpreview in één onhandige string worden gedwongen.
• Type en formaat — Elk is een platte-tekststring. title is de bronwaarde; afwezige overschrijvingen moeten hierop terugvallen. HTML, Markdown, emoji-decoratie en handmatige afkappingstekens zijn geen geldige waarden.
• Vereist? — title is vereist op elke openbare pagina. h1 en seoTitle zijn optioneel en moeten worden weggelaten wanneer title in alle drie de contexten werkt.
• Limieten — Gebruik 30–70 tekens voor title, 20–80 voor h1 en 30–60 voor seoTitle als redactionele richtlijnen, niet als belofte dat een zoekinterface elk teken zal weergeven. Er moet één weergegeven H1 zijn.
• Wie of wat het verbruikt — Paginasjablonen, browsertitels, zoek- en social-adapters, navigatiekaarten, feeds, schema headline, toegankelijkheidsstructuren en redactionele overzichten.
• Regels — Alle versies moeten hetzelfde onderwerp, dezelfde intentie en dezelfde reikwijdte identificeren. Een legitiem verschil lost een kanaalbeperking op: bijvoorbeeld de H1 kan zeggen “Hoe roteer ik een API-sleutel zonder downtime”, terwijl de kortere SEO-titel zegt “API-sleutelrotatie: veilige stapsgewijze handleiding”. De latere sectie Titel, H1 en SEO-titel legt de redactionele test uit.
• Veelgemaakte fouten — Een trefwoord in alle drie de varianten herhalen, een merksuffix in de H1 plaatsen, de belofte wijzigen om klikken te jagen, het huidige jaar invoegen wanneer de pagina niet jaarlijks wordt onderhouden, of drie waarden schrijven alleen omdat er drie velden bestaan.

slug en url

• Doel — De slug is het laatste padsegment; url is de site-relatieve openbare route die het bevat. Samen geven ze de pagina een stabiel adres voor lezers, crawlers, links, rapportage en migraties. Stabiliteit is belangrijk omdat elke verdiende link en opgeslagen bladwijzer afhankelijk wordt van dat adres.
• Type en formaat — Gebruik een lowercase, met koppeltekens gescheiden padstring zoals /academy/rotate-an-api-key/. Deze repository registreert de volledige route in url; een CMS met een apart slug-veld moet hetzelfde eindsegment afleiden.
• Vereist? — Een unieke route is vereist voor elke openbare pagina. Deze mag alleen worden gegenereerd waar een sectie een goedgekeurde deterministische regel en botsingscontroles heeft; playbookpagina’s gebruiken hun geregistreerde url-waarden.
• Limieten — Geef de voorkeur aan een korte, leesbare slug die het onderscheidende onderwerp behoudt, meestal drie tot acht bruikbare woorden. Verwijder leestekens en lege modifiers. Verwijder stopwoorden zoals “de” of “een” alleen wanneer het resultaat natuurlijk en ondubbelzinnig blijft; er is geen willekeurige tekenlimiet die het beschadigen van de betekenis rechtvaardigt.
• Wie of wat het verbruikt — Hugo-routering, interne links, broodkruimels, canonical-generatie, sitemaps, feeds, analyses, redirects en externe verwijzingen.
• Regels — Behandel een gepubliceerde slug als een permanente verplichting. Bepaal deze op basis van het duurzame onderwerp, niet een campagnekop of tijdelijk jaar. Wanneer de titel verandert maar het onderwerp en de intentie niet, behoud dan de oude slug. Als de pagina echt verhuist, maak dan de nieuwe route aan, behoud de oude route in aliases, werk interne links bij en test de redirect-bestemming.
• Veelgemaakte fouten — De slug opnieuw genereren telkens wanneer de titel verandert, synoniemen in het pad stoppen, datums behouden die tijdloze content er verouderd uit laten zien, gemengd hoofd- en kleinletters of underscores gebruiken, twee URL’s creëren die alleen verschillen in een afsluitende slash, en een route wijzigen zonder de oude te behouden.

canonical

• Doel — Een canonical identificeert de voorkeurs-URL onder gelijkwaardige of bijna-gelijkwaardige toegankelijke versies. Het consolideert identiteit; het verplaatst geen bezoeker en rechtvaardigt geen ongecontroleerde duplicatie.
• Type en formaat — Eén absolute HTTPS-URL, inclusief de beoogde host en genormaliseerd pad: https://amicited.com/academy/rotate-an-api-key/. Het sjabloon kan een zelfverwijzing afleiden van de permalink van de pagina wanneer de site één betrouwbare host- en routepolicy heeft.
• Vereist? — Elke indexeerbare pagina moet één canonical uitstralen. Het veld zelf is voorwaardelijk wanneer een correcte zelfverwijzende waarde automatisch wordt afgeleid; stel deze expliciet in voor een goedgekeurde cross-domein of uitzonderlijke canonical.
• Limieten — Precies één canonical-doel. Het doel moet een succesvol indexeerbaar document retourneren, het voorkeursprotocol en host gebruiken en inhoudelijk hetzelfde vertegenwoordigen.
• Wie of wat het verbruikt — De HTML <link rel="canonical">, zoekmachines, sitemap- en interne-linkcontroles, deduplicatierapporten en schema-URL-identificaties.
• Regels — Standaard zelfverwijzend. Gebruik een cross-domein canonical alleen wanneer een andere uitgever de voorkeursgelijkwaardige versie bezit en beide partijen consolidatie beogen. Gebruik een redirect, geen canonical, wanneer de oude URL is vervangen en gebruikers altijd op de nieuwe moeten belanden. Houd canonical, sitemap-URL, hreflang, interne links en schema-identiteit op elkaar afgestemd.
• Veelgemaakte fouten — Elke gepagineerde of gelokaliseerde pagina naar een generieke ouder verwijzen, verschillende content canonicaliseren, naar een redirect- of foutpagina verwijzen, HTTP en HTTPS door elkaar gebruiken, het veld gebruiken als vervanging voor een alias en aannemen dat canonical-instructies gegarandeerd worden opgevolgd.

aliases

• Doel — aliases bewaart routes die eerder dezelfde pagina identificeerden, zodat een verhuizing bestaande links en bladwijzers niet in doodlopende wegen verandert. Het registreert routegeschiedenis in plaats van alternatieve indexeerbare identiteiten te creëren.
• Type en formaat — Een TOML-array van site-relatieve paden, bijvoorbeeld aliases = [ "/blog/old-api-key-guide/" ]. Elke waarde bevat een leidende en afsluitende slash en moet uniek zijn op de site.
• Vereist? — Optioneel voor een nieuwe pagina; vereist wanneer een gepubliceerde pagina verhuist van een pad dat de site beheerde.
• Limieten — Neem elk bekend voormalig first-party route op dat nog links of verkeer ontvangt. Voeg geen speculatieve spellingsvarianten of een ongelimiteerde lijst van zoekwoord-URL’s toe.
• Wie of wat het verbruikt — Hugo’s alias-uitvoer, redirectverwerking bij implementatie waar geconfigureerd, migratie-kwaliteitscontrole, linkmonitors en gebruikers die oude URL’s volgen. Omdat Hugo een alias-pagina kan uitstralen in plaats van een HTTP-redirect op oorsprongsniveau, moet het implementatiegedrag worden geverifieerd in plaats van aangenomen.
• Regels — Een verplaatste pagina houdt zijn oude pad werkend. Elke alias moet in één hop naar de huidige canonieke route oplossen. Werk interne links bij naar de nieuwe URL, zelfs wanneer de alias werkt, en behoud de alias bij latere bewerkingen, tenzij een gedocumenteerd redirectsysteem deze vervangt.
• Veelgemaakte fouten — De oude pagina verwijderen zonder alias, oud pad naar tussenpad naar huidig pad ketenen, aliassen behandelen als dubbele publicatieroutes, meerdere niet-gerelateerde pagina’s naar één handige bestemming verwijzen, of aannemen dat lokale Hugo-uitvoer de productie-HTTP-status bewijst.

type en layout

• Doel — Deze velden selecteren het weergavecontract. type plaatst een pagina in een contentklasse met gedeelde sjablonen en gedrag; layout vraagt een specifiek sjabloon binnen die klasse. Correcte selectie zorgt ervoor dat de pagina de beoogde navigatie, contentpositie, assets en schemagedrag ontvangt.
• Type en formaat — Lowercase geregistreerde strings. Deze pagina gebruikt type = "academy". Een layout-waarde is een sjabloonbasisnaam zoals single, zonder bestandsextensie of padmanipulatie.
• Vereist? — type is vereist wanneer de contentlocatie niet veilig het beoogde type impliceert of wanneer het playbookcontract dit vereist. layout is optioneel en moet worden weggelaten wanneer het standaardsjabloon van het type correct is.
• Limieten — Eén waarde voor elk veld, alleen gekozen uit sjablonen die door de site worden onderhouden. Een nieuwe waarde is een technische wijziging, geen redactionele improvisatie.
• Wie of wat het verbruikt — Hugo’s opzoekvolgorde, sjablonen, partiële selectie, CSS- en JavaScript-inclusie, schema-adapters en validatieregels.
• Regels — Kies het berichttype en weergavecontract voordat je gaat schrijven. Gebruik layout alleen voor een daadwerkelijk ondersteunde variant; gebruik het niet om te compenseren voor content die bij een ander type hoort. Verifieer dat een overschrijving bestaat en de frontmatter-vorm van de pagina accepteert.
• Veelgemaakte fouten — De redactionele entity verwarren met Hugo type, een sjabloonbestand benoemen dat niet bestaat, een landingspagina-type kopiëren naar een academiedocument, vertrouwen op mapinferentie tijdens een migratie en eenmalige layoutnamen introduceren die gedeelde verbeteringen omzeilen.

Ontdekking

description

• Doel — De beschrijving helpt een gekwalificeerde zoeker of deelontvanger te beslissen of deze pagina de behoefte beantwoordt. Het is preview-tekst, geen samengeperste inleiding en geen plek om relevantie te bewijzen door herhaling.
• Type en formaat — Eén platte-tekstzin. Het moet de primaire term natuurlijk noemen, de concrete waarde vermelden en een nuttige reikwijdte, doelgroep, methode of uitkomst toevoegen.
• Vereist? — Vereist voor elke indexeerbare pagina in dit playbook.
• Limieten — 150–160 tekens, inclusief spaties. Dit is een redactionele consistentierichtlijn, geen weergavegarantie: zoekmachines kunnen de tekst afkappen of het fragment herschrijven op basis van bodycontent wanneer een andere passage beter bij de zoekopdracht past.
• Wie of wat het verbruikt — Metabeschrijvingstags, Open Graph- en Twitter-beschrijvingsstandaarden, overzichtskaarten, feeds, CMS-previews, zoekkwaliteitscontroles en soms schema description.
• Regels — Schrijf voor een klik van de juiste lezer. Maak de zin specifiek genoeg om de pagina te onderscheiden van een ander resultaat met een vergelijkbare titel. De sectie Beschrijvingsregels hieronder geeft de rationale en afwijzingstests.
• Veelgemaakte fouten — De titel dupliceren, trefwoorden opsommen, beginnen met “Leer alles over”, een niet-ondersteunde beste-of-snelste claim maken, een vage oproep tot actie gebruiken, de band overschrijden door een onzichtbare merksuffix, of aannemen dat de geschreven tekst letterlijk in zoekresultaten moet verschijnen.

keywords

• Doel — In deze repository registreert keywords de compacte zoekopdracht- en terminologieset die wordt gebruikt voor redactionele kwaliteitscontrole, corpuszoekopdracht, dekkingsanalyse en interne tooling. Het helpt redacteuren de taal te herkennen die een pagina nauwkeurig moet gebruiken; het is geen belofte om elke zin mechanisch op te nemen.
• Type en formaat — Een array van natuurlijke-taalstrings, geordend van de primaire term via betekenisvolle varianten en nauw gerelateerde terminologie.
• Vereist? — Vereist onder dit playbook, inclusief voor pagina’s waarvan de openbare sjablonen de waarden niet weergeven.
• Limieten — Zes tot acht afzonderlijke items. Elk item moet een echte zoekzin of noodzakelijke term vertegenwoordigen, geen variantie op token-niveau.
• Wie of wat het verbruikt — Redactionele validatoren, contentinventarissen, zoek- en kansanalyse, intern ophalen en migratietools. Openbare zoekmachines gebruiken dit veld niet als rankingsignaal alleen omdat het bestaat.
• Regels — Houd de set gefocust op de reikwijdte van één pagina. Voeg hoofdlettergebruik, interpunctie, enkelvoud/meervoud en triviale woordvolgorde-duplicaten samen. Gebruik de zinnen om dekking en terminologie te controleren, nooit om onnatuurlijke dichtheid op te leggen.
• Veelgemaakte fouten — Het veld behandelen als het verouderde meta-keywords-rankingsmechanisme, tientallen varianten toevoegen, de titel als acht bijna-duplicaten herhalen, concurrentennamen invoegen die de body niet bespreekt, en de array laten dienen als vervanging voor een goede taxonomie of promptdoelen.

targetPrompts

• Doel — targetPrompts registreert de volledige vragen of verzoeken die een persoon aan een AI-antwoordsysteem kan geven en waarvoor deze pagina een nuttige bron moet zijn. Promptdoelen behouden conversationele context die korte trefwoordzinnen weglaten.
• Type en formaat — Een array van volledige, natuurlijke-taalstrings, bijvoorbeeld targetPrompts = [ "How do I rotate an API key without downtime?", "What should I check before revoking an old API key?" ]. Houd de formulering zoals een gebruiker het zou vragen, inclusief doelgroep, beperkingen of gewenste vergelijking.
• Vereist? — Voorwaardelijk voor pagina’s die zijn opgenomen in prompt-tracking of een AI-zichtbaarheidscontentprogramma; optioneel wanneer er geen getrackte promptset bestaat.
• Limieten — Gebruik een kleine, doelbewuste set, normaal één primaire prompt en maximaal vier betekenisvolle varianten. Een prompt kan langer zijn dan een trefwoord omdat de kwalificaties intentie dragen.
• Wie of wat het verbruikt — Contentbriefs, prompt-trackingworkflows, zoek- en dekkingsaudits, AI-antwoordmonitoring en redactionele evaluatie. Het wordt niet weergegeven als verborgen zoektekst.
• Regels — Scheid prompts op basis van daadwerkelijke informatiebehoefte, niet interpunctie. Een trefwoord zoals “API-sleutelrotatie” noemt een onderwerp; “Hoe kan een SaaS-team een API-sleutel roteren zonder integraties te onderbreken?” noemt een doelgroep, taak en beperking. De pagina moet elke opgeslagen prompt eerlijk beantwoorden.
• Veelgemaakte fouten — De keywords-array in dit veld kopiëren, tientallen syntactische varianten verzinnen, prompts registreren die breder zijn dan de pagina, prompts gebruiken als bodykoppen ongeacht de leesstroom, en promptdekking claimen wanneer het antwoord afhangt van informatie die de pagina niet biedt.

Vertrouwen en herkomst

date en updated

• Doel — date bewaart wanneer de pagina voor het eerst werd gepubliceerd; updated rapporteert de laatste substantiële wijziging of voltooide beoordeling. Twee velden bewaren de geschiedenis terwijl ze laten zien of informatie waar lezers op vertrouwen, is veranderd.
• Type en formaat — Tijdstempelstrings in de siteconventie, YYYY-MM-DD HH:MM:SS. Houd één tijdzonebeleid aan in het hele corpus, zodat feeds en vergelijkingen deterministisch blijven.
• Vereist? — date is vereist voor gepubliceerde redactionele pagina’s. updated is optioneel tot een in aanmerking komende wijziging plaatsvindt, dan vereist als de pagina een gewijzigde datum presenteert.
• Limieten — Één waarde elk. updated kan niet voor date komen of in de toekomst liggen. Een correctie die minuten na publicatie wordt gemaakt, kan nog steeds worden gedocumenteerd, maar routinematige conceptherzieningen vóór publicatie creëren geen bijgewerkte datum.
• Wie of wat het verbruikt — Zichtbare bylines en versheidsstempels, feeds, sitemaps, schema datePublished en dateModified, recentheidsaudits, sortering en redactionele wachtrijen.
• Regels — Stel updated opnieuw in voor een feitelijke correctie, gewijzigde instructie, nieuw of verwijderd bewijs, herziene reikwijdte, materieel gewijzigde aanbeveling, of een gedocumenteerde beoordeling van tijdsgevoelige beweringen. Stel het nooit opnieuw in voor interpunctie, opmaak, sjabloonwerk of een alleen-tijdstempelbewerking. Zie Datums, auteurs en recensenten voor de beleidsrationale.
• Veelgemaakte fouten — De originele datum overschrijven tijdens een vernieuwing, een pagina in de toekomst datuma om vers te lijken, datums verhogen zonder een contentverschil, een geautomatiseerde implementatie als redactionele update behandelen, en niet vastleggen wat er is gewijzigd in de onderhouden updategeschiedenis.

author

• Doel — author verbindt het document met de verantwoordelijke persoonsentiteit die verantwoordelijk is voor het werk. De link geeft een lezer en een machine een pad van een pagina met beweringen naar een onderhouden identiteit, expertise en ander werk.
• Type en formaat — Een stabiele auteursidentificatie die via het auteurregister van de site oplost naar een profiel-URL en Person-record. Bijvoorbeeld, author = "maya-chen" is alleen geldig als die identificatie oplost; een weergavenaam zoals "Maya Chen, SEO-expert" is geen vervanging voor de entiteitslink.
• Vereist? — Vereist voor substantiële redactionele pagina’s. Transactionele pagina’s mogen een beheerde organisatorische eigenaar gebruiken alleen wanneer het sjabloon en beleid dat entiteitstype ondersteunen.
• Limieten — Standaard één verantwoordelijke leider; gebruik een gedocumenteerde identificatie-array alleen wanneer het schema en byline-sjablonen daadwerkelijk co-auteurschap ondersteunen.
• Wie of wat het verbruikt — Zichtbare bylines, auteurprofiel-links, Article-schema, feeds, redactionele eigendomsrapporten, beoordelingsworkflows en entiteitsgrafieken.
• Regels — Los de identificatie op vóór publicatie. Het profiel moet dezelfde persoon identificeren die in de byline wordt getoond en onderhouden blijven. Geef credit aan de persoon die verantwoordelijk is voor de content, niet de persoon die deze alleen heeft geüpload.
• Veelgemaakte fouten — Een niet-gelinkte naamstring invoeren, “Admin” of een verzonnen redactieteam gebruiken, een prominente leidinggevende toewijzen die het werk niet heeft geschreven, toestaan dat een identificatie naar geen profiel oplost, en auteurschap wijzigen om expertise te impliceren die niet betrokken was.

reviewedBy, reviewedAt en reviewScope

• Doel — Deze velden registreren een onafhankelijke beoordeling die verschilt van het auteurschap. reviewedBy identificeert de recensent-entiteit; reviewedAt geeft aan wanneer de beoordeling is voltooid; reviewScope zegt wat de recensent heeft gecontroleerd, zodat de badge geen goedkeuring impliceert buiten het bewijs.
• Type en formaat — reviewedBy is een stabiele identificatie die oplost naar een onderhouden persoonlijk profiel. reviewedAt gebruikt het site-timestampformaat. reviewScope is een beknopte platte-tekstverklaring zoals “Stappen voor het roteren van inloggegevens en veiligheidsmaatregelen.”
• Vereist? — Voorwaardelijk wanneer wet, risicobeleid, onderwerpgevoeligheid of de berichttypespecificatie onafhankelijke beoordeling vereist. Wanneer reviewedBy aanwezig is, zijn beoordelingsdatum en -reikwijdte vereist als beoordelingsrecordgegevens, zelfs als een bepaald sjabloon ze opslaat in een verbonden redactioneel record in plaats van openbare frontmatter.
• Limieten — Noem alleen daadwerkelijke recensenten. Reikwijdte moet specifiek genoeg zijn om uitsluitingen te onthullen zonder een beoordelingsrapport te worden. Een recensent moet relevante competentie hebben en mag niet simpelweg de auteursrol dupliceren.
• Wie of wat het verbruikt — Beoordeeld-door-componenten, persoonsentiteitskoppelingen, governanceaudits, publicatiepoorten met hoog risico, gestructureerde herkomst en updatelogs.
• Regels — Voltooi de beoordeling nadat de content stabiel is, leg bevindingen en resolutie vast in de redactionele geschiedenis, en beoordeel opnieuw wanneer latere wijzigingen de beoordeelde reikwijdte beïnvloeden. Onafhankelijk betekent dat de recensent het werk test in plaats van zijn eigen concept goed te keuren.
• Veelgemaakte fouten — Redactie behandelen als expertbeoordeling, een recensent tonen zonder datum of reikwijdte, iemand noemen die nooit de definitieve versie heeft gezien, de badge laten staan na een materiële onbeoordeelde herschrijving, en juridische, medische of technische goedkeuring impliceren buiten de vermelde reikwijdte.

Media en sociaal

image en imageAlt

• Doel — image selecteert de representatieve hero en social asset; imageAlt levert het functionele tekstalternatief wanneer die asset wordt weergegeven als betekenisvolle pagina-inhoud. Het paar bij elkaar houden voorkomt dat ontdekkingsafbeeldingen een toegankelijkheidsweglating worden.
• Type en formaat — image is een oplosbaar site-pad of goedgekeurde absolute URL. imageAlt is platte tekst die de nuttige informatie van de afbeelding beschrijft in zijn paginacontext, niet de bestandsnaam of doeltrefwoord.
• Vereist? — Voorwaardelijk per berichttype en sjabloon. Als de pagina een hero of speciale social afbeelding vereist, is image vereist. imageAlt is vereist wanneer die afbeelding informatief wordt weergegeven; een puur decoratieve weergave moet een leeg alt-attribuut in het sjabloon gebruiken, geen verzonnen beschrijvende tekst.
• Limieten — Gebruik één representatieve asset. Voor sociale compatibiliteit, lever een 1200 × 630 pixel bron in de verwachte uitsnijverhouding, houd belangrijke content uit de buurt van randen en houd imageAlt beknopt — normaal 5–160 tekens. Het bestand moet bestaan voordat ernaar wordt verwezen.
• Wie of wat het verbruikt — Hero-componenten, overzichtskaarten, Open Graph- en Twitter-tags, schema-afbeeldingsvelden, feeds, afbeeldingspijplijnen, schermlezers wanneer zichtbaar en asset-kwaliteitscontrole.
• Regels — Kies een afbeelding die nog steeds communiceert na een middenuitsnede en op miniaturegrootte. Beschrijf de functie in context: “API-sleutelinstellingen met Roterende sleutel gemarkeerd” is nuttig; “API-sleutel” is dat niet. Plaats geen essentiële beweringen alleen in pixels.
• Veelgemaakte fouten — Verwijzen naar een gepland asset dat niet bestaat, een logo gebruiken als elke artikelafbeelding, kleine tekst insluiten die onleesbaar wordt in gedeelde content, “afbeelding van” schrijven, trefwoorden in alt-tekst stoppen, en aannemen dat sociale alt-tekst en zichtbare-afbeelding-alt-gedrag identiek zijn op verschillende platforms.

Open Graph- en Twitter-kaartvelden

• Doel — Sociale metadata bepaalt hoe een URL wordt samengevat wanneer deze wordt gedeeld. Een consistente titel, beschrijving, URL, type en afbeelding helpen ontvangers de pagina te herkennen voordat ze klikken en verminderen de kans dat een platform een irrelevant asset selecteert.
• Type en formaat — In deze repository leiden sjablonen og:title en twitter:title af van title, beschrijvingen van description, URL’s van de permalink, og:type van de lay-outcontext, en beide afbeeldingstags van image met een site-terugval. twitter:card wordt uitgezonden als summary_large_image. Dit zijn gegenereerde tags, geen dubbele frontmatter-velden standaard.
• Vereist? — De uitvoertags zijn vereist op openbare pagina’s. Aparte overschrijvingen zijn optioneel en mogen alleen worden geïntroduceerd via een gedocumenteerd sjablooncontract; niet-ondersteunde ad-hocvelden zoals ogTitle doen niets.
• Limieten — Eén coherente preview per pagina en één 1200 × 630 representatieve afbeelding. Houd de afgeleide formulering binnen de titel- en beschrijvingsbanden, test dan de daadwerkelijke uitsnede- en overlay-gedrag op belangrijke deeloppervlakken.
• Wie of wat het verbruikt — Sociale netwerken, berichtenclients, link-unfurlers, browserextensies, samenwerkingstools en deelpreview-debuggers.
• Regels — Geef de voorkeur aan afleiding, zodat zoek- en sociale beweringen op elkaar blijven afgestemd. Overschrijf alleen wanneer de sociale context echt een andere framering nodig heeft en het sjabloon dit ondersteunt. Een verkeerde afbeelding kost herkenning en vertrouwen: de ontvanger kan een verouderde interface, een ander product, een misleidende bewering of een uitsnede zien die het onderwerp verbergt.
• Veelgemaakte fouten — Velden schrijven die geen enkel sjabloon leest, een globale terugval een ontbrekende vereiste hero laten maskeren, een portret of kleine afbeelding gebruiken voor een brede kaart, sociale tekst wijzigen om een sterkere belofte te doen dan de pagina, en alleen de HTML-bron valideren in plaats van een opgehaalde preview.

Classificatie

taxonomy, categories en tags

• Doel — Classificatie verbindt een pagina met beheerde onderwerp-, formaat-, publieks- of productcollecties. Het ondersteunt bruikbare archieven en filters alleen wanneer elke vocabulaire een verklaarde betekenis heeft; anders worden labels een ongecontroleerde synoniemenbrij.
• Type en formaat — Arrays van geregistreerde lowercase slugs. Gebruik taxonomy voor de beheerde onderwerpvocabulaire van de repository. Gebruik categories alleen voor een kleine onderling begrijpelijke redactionele hiërarchie en tags alleen voor een beheerde dwarsdoorsnijdende vocabulaire wanneer die taxonomieën zijn geconfigureerd.
• Vereist? — Voorwaardelijk op basis van het berichttype en archiefontwerp. Onderwerpdragende redactionele pagina’s hebben normaal een of meer beheerde termen nodig; utiliteitspagina’s hebben mogelijk geen nodig. Een veld mag niet worden ingevuld alleen omdat een CMS het blootstelt.
• Limieten — Voor algemene taxonomie, één tot vijf waarden per beheerde vocabulaire. Elke term heeft een definitie, eigenaar en samenvoegregel nodig. Creëer een indexeerbaar archief alleen wanneer de term duurzame lezersvraag vertegenwoordigt en het archief een unieke inleiding, coherente inventaris, interne links en doorlopend onderhoud kan bieden.
• Wie of wat het verbruikt — Archiefpagina’s, broodkruimels, filters, gerelateerde-inhoudssystemen, gefacetteerde navigatie, contentaudits en analysesegmentatie.
• Regels — Kies de smalste geregistreerde term die de pagina nauwkeurig groepeert. Houd enkelvoud/meervoud, afkortingen en spellingsvarianten gemapt op één canonieke waarde. Beslis of archieven indexeerbaar zijn op vocabulaire-niveau, niet tag voor tag na accidentele creatie.
• Veelgemaakte fouten — seo, SEO, search-optimization en search engine optimization gebruiken als aparte waarden, eenmalige tags toevoegen om elk zelfstandig naamwoord te beschrijven, een bedrijfstype verwarren met een onderwerp, dunne indexeerbare archieven genereren en termen verwijderen zonder hun leden te migreren.

Playbook-joinsleutels

• Doel — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage en amicitedFeatures zijn getypeerde joinsleutels. Ze laten één bronpagina verschijnen in gegenereerde bibliotheken en matrices zonder dat redacteuren handmatig kaarten kopiëren. Deze pagina is het uitgewerkte voorbeeld: zijn pijler identificeert een element, zijn familie groepeert metadatabegeleiding en zijn postTypes-array verklaart de specificaties die het verbruiken.
• Type en formaat — Enkelvoudige sleutels gebruiken geregistreerde lowercase slugs: playbookPillar en playbookFamily zijn strings, playbookWave is een geheel getal en journeyStage is een beheerde string. Relatiesleutels — postTypes, elements, businessTypes en amicitedFeatures — zijn arrays van geregistreerde slugs uit hun respectievelijke registers.
• Vereist? — playbookPillar en playbookWave zijn vereist op playbookrecords. playbookFamily is vereist waar de pijler beheerde families heeft. De array-joins en journeyStage zijn voorwaardelijk: vul alleen relaties in die het paginacontract daadwerkelijk ondersteunt.
• Limieten — Eén pijler, één familie binnen die pijler, één wave en één journeyfase, tenzij het model expliciet meerdere fasen toestaat. Arrays bevatten unieke geregistreerde sleutels, geen weergavelabels, proza of URL’s.
• Wie of wat het verbruikt — Playbook-huboverzichten, cross-pijlermatrices, filters, relatiekaarten, volledigheidsrapporten, release-wave-weergaven en interne tools die relevante AmICited-mogelijkheden vinden.
• Regels — Valideer elke waarde tegen het canonieke register. Richting is belangrijk: een berichttype-pagina vermeldt zijn vereiste elements; een elementpagina vermeldt toepasselijke postTypes; een bedrijfstype-pagina vermeldt nuttige berichttypen. Behandel labels als presentatie en sleutels als duurzame data. Hernoem een sleutel alleen via een migratie die elke kant van de join bijwerkt.
• Veelgemaakte fouten — Bijna-synoniemen verzinnen, titels opslaan in plaats van slugs, gehele getallen en strings door elkaar gebruiken voor waves, een relatie toevoegen omdat twee pagina’s elkaar noemen, wederzijdse arrays elkaar laten tegenspreken en handmatig onderhouden overzichtsopmaak creëren die afwijkt van metadata.

Afgeleide en structurele velden

schemaType

• Doel — schemaType selecteert de meest specifieke ondersteunde gestructureerde-data-mapping die de zichtbare pagina nauwkeurig beschrijft. Het vertelt de schema-adapter welk vocabulairecontract hij moet toepassen; het verandert de pagina niet in dat ding door alleen verklaring.
• Type en formaat — Één geregistreerde Schema.org-type-naam zoals Article, geselecteerd uit de typen die de site-adapter ondersteunt. Hoofdlettergebruik en spelling moeten overeenkomen met het register.
• Vereist? — Voorwaardelijk. Stel het in waar meerdere schema-mapping geldig zijn voor hetzelfde Hugo-type of waar het berichttypecontract een expliciet type vereist. Laat het sjabloon anders zijn veilige standaard afleiden.
• Limieten — Eén primair paginatype, met geneste entiteiten gemaakt door de adapter uit daadwerkelijke content. Het geselecteerde type moet aan alle vereiste eigenschappen voldoen en overeenkomen met wat een lezer kan zien.
• Wie of wat het verbruikt — JSON-LD-adapters, rich-resultaatvalidatie, content-kwaliteitscontrole en schema-inventarisrapporten.
• Regels — Kies op basis van paginafunctie en zichtbaar bewijs, niet op de zoekfunctie die een redacteur wenst. Een handleiding zonder een volledige zichtbare procedure kan geen nauwkeurigheid verdienen door een handleiding-type in te stellen. Houd schema-URL’s, datums, personen en afbeeldingen gesynchroniseerd met hun bronvelden.
• Veelgemaakte fouten — Een specifieker type selecteren zonder de vereiste content, meerdere conflicterende primaire typen uitzenden, een schema-waarde kopiëren van een niet-gerelateerd sjabloon, aannemen dat geldige syntaxis geschiktheid garandeert en beweringen in JSON-LD plaatsen die lezers niet kunnen inspecteren.

Leestijd

• Doel — Leestijd geeft een lezer een ruwe inspanningsschatting. Het wordt afgeleid van de uiteindelijk weer te geven body, zodat de schatting verandert wanneer de daadwerkelijke leeslast verandert.
• Type en formaat — Een berekend geheel aantal minuten geproduceerd uit het woordtelbeleid van de contentpijplijn. Codeblokken, tabellen, bijschriften en ingesloten media moeten één gedocumenteerde telregel volgen.
• Vereist? — De weergave is optioneel per sjabloon. Een geschreven frontmatter-veld is niet toegestaan als bron van waarheid.
• Limieten — Rond consistent af en pas een redelijke minimumweergave toe zoals één minuut. De precieze woorden-per-minuut-aanname is minder belangrijk dan het gebruik van dezelfde methode op de hele site en het resultaat labelen als een schatting.
• Wie of wat het verbruikt — Paginakoppen, kaarten, feeds, analysesegmentatie en lezers die beslissen of ze een lange gids willen beginnen.
• Regels — Bereken nadat shortcodes en uitgesloten regio’s zijn behandeld volgens het sitebeleid. Herbereken bij elke build. Als video of een interactieve taak de voltooiingstijd materieel verandert, label dat dan apart in plaats van de leestijd te corrumperen.
• Veelgemaakte fouten — readingTime = 8 schrijven, vergeten het bij te werken na een herschrijving, valse precisie presenteren, navigatie en boilerplate meetellen en een uitvoeringsintensieve handleiding behandelen als acht minuten leestijd plus geen taaktijd.

[[faq]]

• Doel — [[faq]] slaat zichtbare vraag-en-antwoordparen één keer op, zodat de pagina en eventuele in aanmerking komende FAQ-gestructureerde data niet uit elkaar kunnen lopen.
• Type en formaat — Een TOML-array van tabellen; elk item bevat één platte-tekst question en één zelfstandige answer-string.
• Vereist? — Voorwaardelijk wanneer er echte vervolgvragen overblijven na de hoofdpagina. Het is nooit vereist alleen om een sjabloon te vullen of een zoekfunctie na te streven.
• Limieten — Normaal vier tot acht nuttige items op playbookpagina’s. Elke vraag verschijnt één keer en elk antwoord moet volledig zijn zonder te vertrouwen op accordeonvolgorde.
• Wie of wat het verbruikt — Zichtbare FAQ-weergave, FAQPage-schema waar in aanmerking komend, paginanavigatie, content-kwaliteitscontrole en antwoordextractie.
• Regels — Dit is een kruisverwijzingscontract: volg Waarom FAQ in frontmatter leeft en de latere FAQ-richtlijnen in plaats van aparte zichtbare en schema-kopieën te onderhouden. Sla alleen vragen op die elke lezer op de pagina kan raadplegen.
• Veelgemaakte fouten — Verborgen schema-only antwoorden, dubbele koppen vermomd als vragen, promotionele antwoorden, niet-ondersteunde beweringen, verouderde JSON-LD en het behandelen van zoekresultaatgeschiktheid als gegarandeerd.

[[lnks]]

• Doel — [[lnks]] registreert elke beheerde interne link die in de body wordt gebruikt, en koppelt het zichtbare anker aan een bestemming en onderhouden beschrijving. Het record maakt links inspecteerbaar zonder weergegeven HTML te hoeven scrapen en ondersteunt migratie en kwaliteitscontrole.
• Type en formaat — Een TOML-array van tabellen met text, path en title. text is het exacte zichtbare anker, path is een site-relatieve URL met leidende en afsluitende slash, en title is de beschrijving van de bestemmingspagina.
• Vereist? — Vereist voor elke interne bodylink die door deze contentconventie wordt beheerd. App-diepe links en externe bronnen volgen hun eigen records en worden niet vermomd als [[lnks]]-items.
• Limieten — Eén record per body-linkvoorkomen wanneer hetzelfde anker naar verschillende bestemmingen kan wijzen; anders moeten exacte duplicaten worden verwijderd. De bestemming moet bestaan of in het goedgekeurde canonieke slugregister staan voor de gecoördineerde release.
• Wie of wat het verbruikt — Interne-linkvalidatie, contentmigratie, relatieanalyse, linktitelgeneratie waar ondersteund en redactionele beoordeling.
• Regels — Laat text exact overeenkomen met het body-anker, inclusief hoofdlettergebruik en interpunctie binnen de link. Gebruik het canonieke site-relatieve pad. Schrijf title als een nauwkeurige bestemmingsbeschrijving, niet als instructies voor de huidige pagina. Werk het record en de body samen bij.
• Veelgemaakte fouten — Een langere text-waarde gebruiken dan het daadwerkelijke anker, een niet-geregistreerde slug verzinnen, een afsluitende slash weglaten, een verwijzend oud pad registreren, de bron beschrijven in plaats van de bestemming en een record achterlaten nadat de body-link is verwijderd.

Vereist versus optioneel per berichttype

De matrix past de bovenstaande contracten toe op de twaalf berichttypen die momenteel door dit element worden gedeclareerd. R betekent vereist, V betekent voorwaardelijk onder de veldregels, A betekent vereiste uitvoer die veilig kan worden afgeleid en O betekent optioneel. “Identiteit” omvat entity, id, title, type en de stabiele route. “Ontdekking” omvat description en keywords; doelprompts blijven voorwaardelijk voor elke rij. aliases is altijd voorwaardelijk bij een verhuizing, terwijl geschreven leestijd nooit vereist is.

“Voorwaardelijke recensent” is geen toestemming om beoordeling over te slaan waar nauwkeurigheid of commercieel risico dit vereist. Beste-X- en alternatievenpagina’s vereisen onafhankelijke beoordeling omdat hun aanbevelingen een beslissing materieel kunnen beïnvloeden en vaak veranderen naarmate producten, prijzen en geschiktheid veranderen. Voor andere rijen activeert het risicobeleid, niet de beschikbare tijd van een redacteur, de vereiste. Evenzo is een canonical gemarkeerd met A nog steeds vereist in weergegeven HTML; alleen de frontmatter-invoer mag worden weggelaten wanneer het sjabloon de juiste zelfverwijzing kan genereren.

Frontmatter-validatie

Validatie moet deterministische defecten automatisch afwijzen en oordeel voorbehouden voor vragen die afhangen van betekenis, bewijs of professionele competentie. De splitsing voorkomt twee tegenovergestelde fouten: recensenten vragen om syntax te vangen die een parser perfect kan vangen, en doen alsof een tekenaantalregel kan beslissen of tekst eerlijk is.

Voer deterministische controles uit vóór de redactionele beoordeling, zodat de recensent een coherent record ziet. Beoordeel vervolgens de weergegeven HTML, niet alleen frontmatter: een geldige bronwaarde is nog steeds een productiedefect als het geselecteerde sjabloon deze negeert, naar de verkeerde tag verwijst, vereiste herkomst verbergt of een canonical genereert die niet overeenkomt met de openbare route. Publicatie is pas compleet wanneer bron, weergave en bestemmingsgedrag overeenkomen.

Het entity-veld

entity beantwoordt de vraag “van welk exact berichttype is dit document een exemplaar?” Het beantwoordt niet de vraag “welk onderwerp bespreekt deze pagina?” Dat onderscheid is belangrijk omdat twee documenten hetzelfde onderwerp kunnen behandelen terwijl ze verschillende functies vervullen. Een woordenlijstitem definieert “diagnose”; een blogartikel kan een wijziging in diagnostische richtlijnen rapporteren. Als beide entity = "diagnosis" gebruiken, kunnen stroomafwaartse systemen niet betrouwbaar het juiste sjabloon, de juiste validatieregels, de juiste analysagroep of migratie kiezen.

Gebruik het groepprefix plus de berichttype-slug voor varianten binnen een familie: guide-how-to, guide-ultimate, comparison-a-vs-b en comparison-alternatives-to-x. Gebruik de kale naam voor een zelfstandig type: product-page of case-study. Registreer de identificatie eenmaal, houd deze stabiel en verander deze nooit omdat het onderwerp of de doelzoekopdracht verandert. Plaats onderwerpconcepten in taxonomy en zoektaal in keywords.

Titel, H1 en SEO-titel

Deze waarden kunnen per context verschillen, maar moeten dezelfde pagina beschrijven. title is de duurzame standaard. h1 is de zichtbare kop en kan natuurlijker zijn in context. seoTitle dient voor browser- en zoekresultaten en kan een beknopte differentiator, legitiem jaar of merksuffix toevoegen.

Bijvoorbeeld, title = "API Key Rotation", h1 = "How to Rotate an API Key Without Downtime" en seoTitle = "API Key Rotation: Safe Step-by-Step Guide" komen overeen voor één taak. “Free Security Tool” als SEO-titel zou misleidend zijn omdat het de belofte verandert. Creëer geen verschillen alleen om meer trefwoorden in te voegen.

Beschrijvingsregels

De beschrijving bestaat om een gekwalificeerde lezer te helpen besluiten te klikken. Houd deze binnen 150–160 tekens, neem de primaire term natuurlijk op, vermeld het concrete voordeel van de pagina en voeg een betekenisvolle kwalificatie toe zoals publiek, reikwijdte of uitkomst. Schrijf één vloeiende zin, geen trefwoordlijst.

De term bevestigt relevantie; herhaling voegt geen waarde toe. Dupliceer de titel niet, gebruik geen “Leer alles over”, maak geen niet-ondersteunde superlatieven en eindig niet halverwege een gedachte. Zoeksystemen kunnen nog steeds andere zichtbare tekst voor een zoekopdracht selecteren.

Datums, auteurs en recensenten

date bewaart het eerste publicatietijdstip. updated registreert de laatste substantiële wijziging: een feitelijke correctie, nieuw bewijs, gewijzigde instructies, herziene reikwijdte, aangepaste aanbeveling of volledige beoordeling die tijdsgevoelige beweringen bevestigt. Leg vast wat er is gewijzigd in de redactionele geschiedenis wanneer het beleid dit vereist.

Het verbeteren van interpunctie, het wijzigen van een knopstijl, het herbouwen van een sjabloon of het alleen aanraken van de tijdstempel reset updated niet. Een datum vooruitzetten zonder werk erachter is een beleidsschending omdat het lezers en machines vertelt dat de content is ververst terwijl dat niet het geval is. Het is verkeerde voorstelling van zaken, geen groeitactiek.

Auteur- en recensentvelden dragen verantwoordelijke identiteiten over in bylines en gestructureerde data. De auteur is verantwoordelijk voor het werk. Gebruik reviewedBy alleen wanneer gekwalificeerde beoordeling heeft plaatsgevonden en koppel beide identificaties aan onderhouden profielen. De trust foundations-pagina legt uit hoe auteurschap, datums, bewijs en entiteitshelderheid vertrouwen ondersteunen zonder rangschikkingen te garanderen.

Waarom FAQ in frontmatter leeft

Een FAQ is zichtbare content en een gestructureerde collectie. Door het eenmalig op te slaan in [[faq]] kan het sjabloon de accordeon en identieke FAQPage JSON-LD weergeven, waardoor verouderde verborgen schema wordt voorkomen.

Neem echte vervolgvragen op die zichtbaar zijn voor elke lezer. Dupliceer geen koppen, verberg geen promoties in antwoorden en markeer niet-weergegeven vragen niet. Geldige opmaak garandeert geen zoekfunctie.

Syntax en codevoorbeelden

Het cross-platform contract wijst velden toe, geen zichtbaar component. De volgende draagbare envelop is alleen geldig in een uitwisselingsbestand waarvan de importeur metadata-instructies herkent:

:::frontmatter{entity="guide-how-to" id="reset-api-key" title="How to Reset an API Key"}
description: Reset an API key safely, replace it in dependent services, verify it, and revoke the exposed key without avoidable downtime.
author: maya-chen
:::

Het moet tijdens het importeren worden genormaliseerd naar native paginametadata. Het is niet geldig in de body van een productieartikel. In Hugo is de correcte mapping TOML tussen +++-begrenzingen bij byte één, zoals getoond in het levende voorbeeld. Er is bewust geen {{< frontmatter >}}-shortcode: een shortcode zou te laat en in de verkeerde documentregio worden uitgevoerd.

In WordPress, wijs dezelfde canonieke velden toe aan geregistreerde postvelden en postmeta, bijvoorbeeld post_title, post_excerpt, post_name, _amicited_entity, _amicited_author en _amicited_reviewed_by. Een opmerking zoals <!-- wp:amicited/frontmatter --> of een [frontmatter]-shortcode is ongeldig omdat het een bodyblok creëert in plaats van documentmetadata. Importeurs en redacteuren kunnen een metadatapaneel presenteren, maar de opgeslagen waarden moeten aan het postrecord blijven gekoppeld.

Voorbeelden

Goed: één coherent, verantwoord record

entity = "guide-how-to"
id = "rotate-api-key"
title = "How to Rotate an API Key"
description = "Rotate an API key safely, update every dependent service, verify the replacement, and revoke the old credential without avoidable downtime."
url = "/academy/rotate-an-api-key/"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "rotate API key", "API key rotation", "revoke API key", "credential security", "API security", "secret rotation" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/rotate-an-api-key/"

Dit identificeert een handleidingsvariant, bewaart geschiedenis, noemt verantwoordelijke personen en scheidt onderwerp van pagina-identiteit. De bijgewerkte tijdstempel wordt ondersteund door een gedocumenteerde instructiewijziging en beoordeling.

Slecht: de titel herhaald als beschrijving

title = "How to Rotate an API Key"
description = "How to Rotate an API Key"

De beschrijving voegt geen voordeel, reikwijdte of reden om te klikken toe. Het verspilt ook de previewruimte die deze pagina zou kunnen onderscheiden van elk ander resultaat met dezelfde titel.

Slecht: één entiteit hergebruikt voor twee berichttypen

# woordenlijstitem
entity = "diagnosis"

# redactionele gids
entity = "diagnosis"

Het gedeelde onderwerp heeft de berichttype-identiteit vervangen. Gebruik geregistreerde waarden zoals glossary-term en guide-ultimate, wijs vervolgens “diagnosis” toe via taxonomie of trefwoorden.

Slecht: een bijgewerkte datum zonder contentverschil

date = "2026-01-15 09:00:00"
updated = "2026-08-27 10:00:00" # only the date changed

Geen substantiële bewerking of beoordeling ondersteunt de versheidsclaim. Houd updated ongewijzigd of weggelaten totdat er een echte wijziging bestaat en kan worden geïnspecteerd in de redactionele geschiedenis.

Schema-opmaak en toegankelijkheid

Metadata levert waarden; het sjabloon blijft verantwoordelijk voor semantische HTML, focus, contrast, linkdoel en alternatieve tekst.

Schrijfregels

• Houd identificaties stabiel, lowercase en machineveilig. Recycle nooit een id of wijzig stilletjes entity na publicatie.
• Gebruik platte tekst in titelachtige velden. HTML, Markdown-links, emoji-decoratie en geforceerde regeleinden horen niet thuis in metadatastrings.
• Houd de beschrijving op 150–160 tekens en trefwoordarrays op zes tot acht verschillende zinnen voor dit playbook.
• Gebruik echte geregistreerde personen voor auteur- en recensentvelden. Creëer nooit een ceremoniële recensent of generieke “Redactieteam”-identiteit, tenzij dat een onderhouden verantwoordelijke entiteit is.
• Gebruik een beheerde taxonomie. Spellingsvarianten en enkelvoud/meervoud-duplicaten creëren gefragmenteerde archieven.
• Verwijs alleen naar afbeeldingen die bestaan en publicatierechten hebben. imageAlt beschrijft de informatieve inhoud van de afbeelding, niet het SEO-doel.
• Houd FAQ-antwoorden direct en zelfstandig. Beweringen vereisen nog steeds hetzelfde bewijs en dezelfde openbaarmaking als proza elders op de pagina.
• Plaats nooit geheimen, privénotities, toegangstokens, embargo-instructies, persoonlijke gegevens of niet-beoordeelde juridische claims in publiceerbare frontmatter.

Welke berichttypen gebruiken frontmatter, en waar

Elk berichttype gebruikt frontmatter bij byte één. De vereiste diepgang verandert met risico, intentie en schema, niet met visueel ontwerp.

Kwaliteitscontrolelijst

• Begint het bestand met +++, bevat het geldige TOML en sluit het het record af vóór bodycontent?
• Is entity een geregistreerde exacte berichttype-identificatie in plaats van het onderwerp, de campagne of de sitenaam?
• Is id uniek en stabiel, en komt url overeen met het canonieke slugregister?
• Beschrijven title, optionele h1 en optionele seoTitle dezelfde pagina zonder misleidende reikwijdtewijzigingen?
• Is de beschrijving 150–160 tekens, bevat deze de primaire term natuurlijk en biedt deze een concrete reden om te klikken?
• Bestaat elke gerefereerde afbeelding en is imageAlt accuraat voor de afbeelding die wordt weergegeven?
• Is de publicatiedatum bewaard en wordt elke updated-waarde ondersteund door een substantieel verschil of gedocumenteerde beoordeling?
• Lossen auteur- en recensentidentificaties op naar echte onderhouden profielen en heeft de genoemde recensent het werk daadwerkelijk beoordeeld?
• Zijn trefwoorden beperkt tot zes tot acht nuttige zinnen en taxonomiewaarden ontleend aan beheerde vocabularia?
• Gebruikt de canonical HTTPS, lost deze op naar de voorkeurspagina en komt deze overeen met de sitemap en interne links?
• Bevat elk [[faq]]-item één nuttige vraag en zelfstandig antwoord dat zichtbaar wordt weergegeven in identieke formulering?
• Komt gegenereerde JSON-LD overeen met zichtbare content, gebruikt het stabiele identificaties en doorstaat het syntaxvalidatie zonder niet-ondersteunde typen te claimen?
• Zijn geheimen, privé redactionele notities, niet-ondersteunde beweringen en alleen-body-disclosures afwezig in het record?

FAQ

Is frontmatter zichtbaar op de gepubliceerde pagina?

De bronrecord is verborgen, maar sjablonen kunnen de titel, personen, datums en FAQ weergeven. Andere velden voeden previews, canonical-tags, feeds, sitemaps, schema en interne systemen.

Moet het entiteitsveld het onderwerp of het berichttype bevatten?

Het identificeert het exacte berichttype. Gedeelde onderwerpen horen in taxonomie en trefwoorden, niet in plaats van documentidentiteit.

Kunnen de titel, H1 en SEO-titel verschillend zijn?

Ja. De H1 kan natuurlijker lezen en de SEO-titel kan een differentiator toevoegen, maar alle versies moeten dezelfde belofte doen.

Wanneer moet de bijgewerkte datum wijzigen?

Wijzig deze na een substantiële feitelijke beoordeling of bewerking. Wijzig deze niet voor interpunctie, opmaak, sjabloonwerk of een alleen-datumvernieuwing.

Waarom worden FAQ-vragen opgeslagen in frontmatter?

De gestructureerde array laat één bron zowel de zichtbare FAQ als overeenkomende FAQPage JSON-LD weergeven. Dat voorkomt dat schema wegdrijft van wat lezers kunnen inspecteren.