Innhold Frontmatter: Felt og SEO-metadata

Frontmatter er sideelementet lesere aldri ser som én blokk, og som alle publiseringssystemer er avhengige av. Det gir et dokument en identitet, gjengivelseskontrakt, søkeforvisning, eierskapsregistrering, datoer og skjemainndata. Ødelagt frontmatter kan velge feil mal, skape kanoniske konflikter, miste forfatteren eller sende ut markup som motsier siden.

Det levende eksemplaret er en dokumentnivåpost, vist som kode fordi frontmatter ikke må bli en dekorativ innholdsboks.

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

Hvorfor frontmatter eksisterer

For en leser reduserer metadata usikkerhet. En presis tittel setter omfang, en nyttig beskrivelse fortjener klikket, identiteter gjør påstander ansvarlige, og datoer avslører om informasjon kan ha blitt foreldet. Disse signalene kan ikke kompensere for svakt innhold, men fraværet tvinger leseren til å gjette.

For maskiner erstatter frontmatter slutninger med navngitte verdier. Maler kartlegger felt til nettlesertitler, kanoniske lenker, personposter, datoer, strømmer, indekser og JSON-LD uten å skrape prosa. Dette er maskinuttrekkbarhet: viktige fakta har en konsekvent plassering og type.

Følg skrivereglene for elementer: metadata tilhører på dokumentnivå; leservendte elementer tilhører i brødteksten. En byline kan gjengis fra frontmatter, men dens autoritative identifikator forblir der.

Når du skal bruke det — og når ikke

Hver indekserbar side trenger én frontmatter-post for identitet, gjengivelse og ruting. Utkast trenger det når de går i produksjon, slik at validering kan feile tidlig.

Ikke skjul artikkelfakta i frontmatter. Produktbegrensninger, sikkerhetsadvarsler, tilknytningsavsløringer, metoder og kilder må forbli synlige der lesere kan vurdere dem. En strukturert verdi erstatter aldri en avsløring.

Nære bommerter forårsaker mest skade:

• Uavhengig varierende navigasjonsetiketter, kampanjetekst og sosiale bildetekster er kanalinnstillinger; ikke overbelast title.
• Organisasjonsfakta som deles på hele nettstedet, hører hjemme i nettstedets organisasjonspost, ikke kopiert inn på hver side der de vil drive fra hverandre.
• En spørsmål-og-svar-seksjon hører hjemme i [[faq]] bare når samme innhold gjengis synlig. Skjult skjemabasert FAQ uten synlig visning er ugyldig.
• En emneetikett hører hjemme i taxonomy; den må ikke erstatte entity som identifiserer dokumentets innleggstype.
• En omdirigering hører hjemme i rutingkonfigurasjon eller et godkjent alias-felt. canonical identifiserer den foretrukne versjonen; den omdirigerer ikke besøkende.

Hvor du plasserer det

Frontmatter begynner ved første byte med +++ og slutter ved den samsvarende markøren før brødteksten. Ingen overskrift, kommentar, notat, kortkode eller metadatablokk kan komme før den. TOML-felt og matriser hører hjemme inne i den ene posten.

Brødteksten begynner etter den avsluttende markøren. Frontmatter kan ikke sitte mellom H1 og introduksjonen, ved siden av et skjermbilde, inne i en komponent eller på slutten. Et byteordensmerke eller en løs kommentar kan hindre gjenkjennelse. Dupliserte nøkler, YAML-markører og andre blokker er ugyldige.

Anatomi

Den gjengitte forklaringen forblir på siden slik at den forblir lesbar og oversettbar uavhengig av bildet:

1. Grense: de åpne og lukkende +++-markørene definerer det eneste metadataområdet.
2. Identitet: entity, id, type og url forteller systemer hva dokumentet er og hvor det befinner seg.
3. Oppdagelse: title, seoTitle, description, image, imageAlt og keywords støtter forhåndsvisninger og gjenfinning.
4. Opprinnelse: date, updated, author og reviewedBy angir hvem som er ansvarlig og når arbeidet ble gyldig endret.
5. Klassifisering: taxonomy kobler siden til kontrollerte emnesamlinger uten å omdefinere identiteten.
6. Dupliseringskontroll: canonical navngir den foretrukne offentlige URL-en når ekvivalente versjoner kan nås andre steder.
7. Strukturerte samlinger: hver [[faq]] oppretter én typet spørsmål-og-svar-post for synlig gjengivelse og skjema.

Designeksempler

Frontmatter har datakontraktvarianter, ikke visuelle stiler. Skjermbilder parer kildeoppføringer med deres resulterende forhåndsvisning eller byline.

Parametere

Dette er redaksjonelle grenser selv når en parser godtar mer. «Betinget» betyr påkrevd når den angitte betingelsen er oppfylt.

Referanse per felt

Denne referansen definerer publiseringskontrakten for hvert felt. «Påkrevd» betyr at validering bør stoppe publisering når feltet eller dets gyldige utledning mangler. «Betinget» betyr at kravet aktiveres av et oppgitt faktum, for eksempel at et bilde gjengis eller en uavhengig gjennomgang har funnet sted. En standard er trygg bare når den produserer samme mening som en redaktør ville ha valgt bevisst.

Identitet og ruting

title, h1 og seoTitle

• Formål — title gir dokumentet sitt varige redaksjonelle navn. h1 styrer den viktigste overskriften på siden når layoutkonteksten trenger annen ordlyd. seoTitle styrer nettleser-/søketittelen når standarden trenger et konsistent kvalifiserende eller merkevareelement. Å skille dem forhindrer at en navigasjonsetikett, sideoverskrift og søkeforvisning blir tvunget inn i én klønete streng.
• Type og format — Hver er en ren tekststreng. title er kildeverdien; fraværende overstyringer må falle tilbake på den. HTML, Markdown, emoji-dekorasjon og manuelle trunkeringsmerker er ikke gyldige verdier.
• Påkrevd? — title er påkrevd på hver offentlige side. h1 og seoTitle er valgfrie og bør utelates når title fungerer i alle tre kontekster.
• Grenser — Bruk 30–70 tegn for title, 20–80 for h1 og 30–60 for seoTitle som redaksjonelle rammer, ikke løfter om at et søkegrensesnitt vil vise hvert tegn. Det må finnes én gjengitt H1.
• Hvem eller hva som forbruker det — Sidemaler, nettlesertitler, søke- og sosiale adaptere, navigasjonskort, strømmer, skjemaets headline, tilgjengelighetsdisposisjoner og redaksjonelle oppføringer.
• Regler — Alle versjoner må identifisere samme emne, hensikt og omfang. En legitim forskjell løser en kanalbegrensning: for eksempel kan H1 si «Hvordan rotere en API-nøkkel uten nedetid», mens den kortere SEO-tittelen sier «API-nøkkelrotasjon: Sikker steg-for-steg-guide.» Avsnittet Tittel, H1 og SEO-tittel forklarer den redaksjonelle testen.
• Vanlige feil — Å gjenta et nøkkelord i alle tre varianter, sette et merkevaresuffiks i H1, endre løftet for å jage klikk, legge inn inneværende år når siden ikke vedlikeholdes årlig, eller skrive tre verdier bare fordi tre felt finnes.

slug og url

• Formål — Slugen er det siste banesegmentet; url er den nettstedrelative offentlige ruten som inneholder den. Sammen gir de siden en stabil adresse for lesere, crawls, lenker, rapportering og migrasjoner. Stabilitet betyr noe fordi hver opptjente lenke og lagrede bokmerke blir avhengig av den adressen.
• Type og format — Bruk en lowercase, bindestrek-separert banestreng som /academy/rotate-an-api-key/. Dette repositoriet registrerer hele ruten i url; et CMS som har et separat slug-felt må utlede samme siste segment.
• Påkrevd? — En unik rute er påkrevd for hver offentlige side. Den kan bare genereres der en seksjon har en godkjent deterministisk regel og kollisjonskontroller; playbook-sider bruker sine registrerte url-verdier.
• Grenser — Foretrekk en kort, lesbar slug som bevarer det distinkte emnet, vanligvis tre til åtte nyttige ord. Fjern tegnsetting og tomme modifikatorer. Fjern stoppord som «the» eller «a» bare når resultatet forblir naturlig og utvetydig; det er ingen vilkårlig tegnbegrensning som rettferdiggjør å skade meningen.
• Hvem eller hva som forbruker det — Hugo-ruting, interne lenker, brødsmuler, kanonisk generering, sidekart, strømmer, analyse, omdirigeringer og eksterne referanser.
• Regler — Behandle en publisert slug som en permanent forpliktelse. Bestem den ut fra det varige emnet, ikke en kampanjeoverskrift eller et forbigående år. Når tittelen endres, men emnet og hensikten ikke gjør det, behold den gamle slugen. Hvis siden virkelig flytter, opprett den nye ruten, behold den gamle ruten i aliases, oppdater interne lenker og test omdirigeringsmålet.
• Vanlige feil — Å regenerere slugen når tittelen endres, stappe synonymer inn i banen, beholde datoer som får eviggrønt innhold til å se utdatert ut, bruke blandet store og små bokstaver eller understreker, opprette to URL-er som bare skiller seg med en avsluttende skråstrek, og endre en rute uten å bevare den gamle.

canonical

• Formål — En canonical identifiserer den foretrukne URL-en blant ekvivalente eller nær-ekvivalente tilgjengelige versjoner. Den konsoliderer identitet; den flytter ikke en besøkende eller unnskylder ukontrollert duplisering.
• Type og format — Én absolutt HTTPS-URL, inkludert tiltenkt vert og normalisert bane: https://amicited.com/academy/rotate-an-api-key/. Malen kan utlede en selvreferanse fra sidens permalink når nettstedet har én pålitelig vert- og rute-policy.
• Påkrevd? — Hver indekserbare side må sende ut én canonical. Selve feltet er betinget når en korrekt selvrefererende verdi utledes automatisk; sett det eksplisitt for en godkjent kryssdomene eller eksepsjonell canonical.
• Grenser — Nøyaktig ett canonical-mål. Målet må returnere et vellykket indekserbart dokument, bruke foretrukket protokoll og vert, og representere i hovedsak samme innhold.
• Hvem eller hva som forbruker det — HTML <link rel="canonical">, søkemotorer, sidekart- og interne lenkekontroller, dedupliseringsrapporter og skjema-URL-identifikatorer.
• Regler — Selvreferanse som standard. Bruk en kryssdomene-canonical bare når en annen utgiver eier det foretrukne ekvivalenten og begge parter har til hensikt å konsolidere. Bruk en omdirigering, ikke en canonical, når den gamle URL-en er erstattet og brukere alltid bør lande på den nye. Hold canonical, sidekart-URL, hreflang, interne lenker og skjemaidentitet på linje.
• Vanlige feil — Å peke hver paginerte eller lokaliserte side til en generisk overordnet, canonicalisere distinkt innhold, målrette en omdirigering eller feilside, blande HTTP og HTTPS, bruke feltet som en erstatning for et alias, og anta at canonical-direktiver garantert vil bli etterlevd.

aliases

• Formål — aliases bevarer ruter som tidligere identifiserte samme side, slik at en flytting ikke gjør eksisterende lenker og bokmerker til blindveier. Det registrerer rutehistorikk i stedet for å opprette alternative indekserbare identiteter.
• Type og format — En TOML-matrise med nettstedrelative stier, for eksempel aliases = [ "/blog/old-api-key-guide/" ]. Hver verdi inkluderer en ledende og avsluttende skråstrek og må være unik på tvers av nettstedet.
• Påkrevd? — Valgfri for en ny side; påkrevd når en publisert side flyttes fra en bane nettstedet kontrollerte.
• Grenser — Inkluder enhver kjent tidligere førstepartsrute som fortsatt mottar lenker eller trafikk. Ikke legg til spekulative stavevarianter eller en ubegrenset liste over nøkkelord-URL-er.
• Hvem eller hva som forbruker det — Hugos alias-utdata, distribusjonsomdirigeringsbehandling der konfigurert, migrasjonskvalitetssikring, lenkemonitorer og brukere som følger gamle URL-er. Fordi Hugo kan sende ut en alias-side i stedet for en HTTP-omdirigering på opprinnelsesnivå, må distribusjonsatferd verifiseres i stedet for antas.
• Regler — En flyttet side holder sin gamle sti fungerende. Hvert alias må løses i ett hopp til den gjeldende kanoniske ruten. Oppdater interne lenker til den nye URL-en selv når aliaset fungerer, og behold aliaset gjennom senere redigeringer med mindre et dokumentert omdirigeringssystem overstyrer det.
• Vanlige feil — Å slette den gamle siden uten et alias, lenke gammel sti til mellomliggende sti til gjeldende sti, behandle aliaser som dupliserte publiseringsruter, peke flere urelaterte sider til ett praktisk mål, eller anta at lokal Hugo-utdata beviser produksjons-HTTP-statusen.

type og layout

• Formål — Disse feltene velger gjengivelseskontrakten. type plasserer en side i en innholdsklasse med delte maler og atferd; layout ber om en spesifikk mal innenfor den klassen. Korrekt valg sikrer at siden mottar tiltenkt navigasjon, innholdsplass, ressurser og skjemaatferd.
• Type og format — Lowercase registrerte strenger. Denne siden bruker type = "academy". En layout-verdi er et mal-basenavn som single, uten filendelse eller banegjennomgang.
• Påkrevd? — type er påkrevd når innholdsplasseringen ikke trygt impliserer tiltenkt type eller når playbook-kontrakten krever det. layout er valgfri og bør utelates når typens standardmal er korrekt.
• Grenser — Én verdi for hvert felt, valgt kun fra maler som vedlikeholdes av nettstedet. En ny verdi er en teknisk endring, ikke en redaksjonell improvisasjon.
• Hvem eller hva som forbruker det — Hugos oppslagsrekkefølge, maler, delvis valg, CSS- og JavaScript-inkludering, skjematilpassere og valideringsregler.
• Regler — Velg innleggstype og gjengivelseskontrakt før du utformer. Bruk layout bare for en ekte støttet variant; ikke bruk det for å kompensere for innhold som tilhører en annen type. Verifiser at en overstyring eksisterer og godtar sidens frontmatter-form.
• Vanlige feil — Å forveksle den redaksjonelle entity med Hugo type, navngi en malfil som ikke finnes, kopiere en landingssidetype på et akademidokument, stole på mappe-inferens under en migrasjon, og introdusere engangslayoutnavn som omgår delte forbedringer.

Oppdagelse

description

• Formål — Beskrivelsen hjelper en kvalifisert søker eller delingsmottaker å avgjøre om denne siden svarer på behovet. Det er forhåndsvisningstekst, ikke en komprimert introduksjon og ikke et sted å bevise relevans gjennom repetisjon.
• Type og format — Én ren tekstsetning. Den bør nevne hovedtermen naturlig, angi den konkrete verdien og legge til nyttig omfang, målgruppe, metode eller resultat.
• Påkrevd? — Påkrevd for hver indekserbare side i denne playbooken.
• Grenser — 150–160 tegn, inkludert mellomrom. Dette er en redaksjonell konsistensramme, ikke en visningsgaranti: søkemotorer kan forkorte den eller skrive om utdraget fra brødtekst når en annen passasje passer bedre til søket.
• Hvem eller hva som forbruker det — Metabeskrivelsestagger, Open Graph- og Twitter-beskrivelsesstandarder, oppføringskort, strømmer, CMS-forhåndsvisninger, søkekvalitetskontroller og noen ganger skjemaets description.
• Regler — Skriv for et klikk fra rett leser. Gjør setningen spesifikk nok til å skille siden fra et annet resultat med en lignende tittel. Avsnittet Beskrivelsesregler nedenfor gir begrunnelse og avvisningstester.
• Vanlige feil — Å duplisere tittelen, liste opp nøkkelord, åpne med «Lær alt om», komme med en ubegrunnet best-eller-raskest-påstand, bruke en vag handlingsoppfordring, overskride rammen gjennom et usynlig merkevaresuffiks, eller anta at den skrevne teksten må vises ordrett i søkeresultater.

keywords

• Formål — I dette repositoriet registrerer keywords det kompakte søkeord- og termsettet som brukes til redaksjonell kvalitetssikring, korpussøk, dekningsanalyse og interne verktøy. Det hjelper redaktører å gjenkjenne språket en side må bruke nøyaktig; det er ikke et løfte om å inkludere hver frase mekanisk.
• Type og format — En matrise med naturlige språkstrenger, ordnet fra hovedtermen gjennom meningsfulle varianter og nært beslektet terminologi.
• Påkrevd? — Påkrevd under denne playbooken, inkludert for sider hvis offentlige maler ikke gjengir verdiene.
• Grenser — Seks til åtte distinkte oppføringer. Hver oppføring må representere en ekte søkefrase eller nødvendig term, ikke en token-nivå-variasjon.
• Hvem eller hva som forbruker det — Redaksjonelle validatorer, innholdsinventar, søke- og mulighetsanalyse, intern gjenfinning og migrasjonsverktøy. Offentlige søkemotorer bruker ikke dette feltet som et rangeringssignal bare fordi det finnes.
• Regler — Hold settet fokusert på én sides omfang. Slå sammen store/små bokstaver, tegnsetting, entall/flertall og trivielle ordstillingsduplikater. Bruk frasene til å kontrollere dekning og terminologi, aldri for å diktere unaturlig tetthet.
• Vanlige feil — Å behandle feltet som den foreldede meta-keywords-rangeringsmekanismen, legge til dusinvis av varianter, gjenta tittelen som åtte nær-duplikater, sette inn konkurrentnavn brødteksten ikke diskuterer, og la matrisen erstatte riktig taksonomi eller målspørsmål.

targetPrompts

• Formål — targetPrompts registrerer de fullstendige spørsmålene eller forespørslene en person kan gi et AI-svarssystem, og som denne siden bør være en nyttig kilde for. Målspørsmål bevarer samtalekontekst som korte nøkkelordfraser utelater.
• Type og format — En matrise med fullstendige, naturlige språkstrenger, for eksempel targetPrompts = [ "How do I rotate an API key without downtime?", "What should I check before revoking an old API key?" ]. Hold ordlyden som en bruker ville spurt, inkludert målgruppe, begrensninger eller ønsket sammenligning.
• Påkrevd? — Betinget for sider som inngår i malspørsmålsoppfølging eller et AI-synlighetsinnholdsprogram; valgfritt når intet sporesett for malspørsmål finnes.
• Grenser — Bruk et lite, bevisst sett, normalt ett primært malspørsmål og opptil fire meningsfulle varianter. Et malspørsmål kan være lengre enn et nøkkelord fordi dets kvalifikatorer bærer hensikt.
• Hvem eller hva som forbruker det — Innholdsbeskrivelser, malspørsmålsoppfølgingsarbeidsflyter, gjenfinnings- og dekningsrevisjoner, AI-svarovervåking og redaksjonell evaluering. Det gjengis ikke som skjult søketekst.
• Regler — Skill malspørsmål etter faktisk informasjonsbehov, ikke tegnsetting. Et nøkkelord som «API-nøkkelrotasjon» navngir et emne; «Hvordan kan et SaaS-team rotere en API-nøkkel uten å avbryte integrasjoner?» navngir en målgruppe, oppgave og begrensning. Siden må svare på hvert lagrede malspørsmål ærlig.
• Vanlige feil — Å kopiere nøkkelordsmatrisen inn i dette feltet, fabrikkere dusinvis av syntaktiske varianter, registrere malspørsmål bredere enn siden, bruke malspørsmål som brødtekstoverskrifter uavhengig av leseflyt, og hevde malspørsmålsdekning når svaret avhenger av informasjon siden ikke gir.

Tillit og opprinnelse

date og updated

• Formål — date bevarer når siden først ble publisert; updated rapporterer den siste vesentlige endringen eller fullførte gjennomgangen. To felt bevarer historikk samtidig som de viser om informasjon lesere stoler på har endret seg.
• Type og format — Tidsstempelstrenger i nettstedkonvensjonen, YYYY-MM-DD HH:MM:SS. Hold én tidssone-policy på tvers av korpuset slik at strømmer og sammenligninger forblir deterministiske.
• Påkrevd? — date er påkrevd for publiserte redaksjonelle sider. updated er valgfri inntil en kvalifiserende endring oppstår, deretter påkrevd hvis siden viser en endret dato.
• Grenser — Én verdi hver. updated kan ikke være før date eller ligge i fremtiden. En rettelse gjort minutter etter publisering kan fortsatt dokumenteres, men rutinemessige utkastrevisjoner før publisering oppretter ikke en oppdatert dato.
• Hvem eller hva som forbruker det — Synlige bylines og ferskhetsmerker, strømmer, sidekart, skjemaets datePublished og dateModified, aktualitetsrevisjoner, sortering og redaksjonelle køer.
• Regler — Nullstill updated for en faktakorrektur, endret instruksjon, nytt eller fjernet bevis, revidert omfang, vesentlig endret anbefaling, eller en dokumentert gjennomgang av tidssensitive påstander. Nullstill det aldri for tegnsetting, formatering, malfunksjoner eller en tidsstempel-bare redigering. Se Datoer, forfattere og anmeldere for policybegrunnelsen.
• Vanlige feil — Å overskrive den opprinnelige datoen under en oppdatering, datere en side frem i tid for å virke fersk, øke datoer uten en innholdsendring, behandle en automatisk distribusjon som en redaksjonell oppdatering, og unnlate å registrere hva som endret seg i den vedlikeholdte oppdateringshistorikken.

author

• Formål — author kobler dokumentet til den ansvarlige personenheten som er ansvarlig for arbeidet. Koblingen gir en leser og en maskin en vei fra en påstandsbærende side til vedlikeholdt identitet, ekspertise og annet arbeid.
• Type og format — En stabil forfatteridentifikator som løses gjennom nettstedets forfatterregister til en profil-URL og Person-post. For eksempel er author = "maya-chen" gyldig bare hvis den identifikatoren løses; et visningsnavn som "Maya Chen, SEO-ekspert" er ikke en erstatning for entitetskoblingen.
• Påkrevd? — Påkrevd for vesentlige redaksjonelle sider. Transaksjonssider kan bruke en styrt organisasjonseier bare når malen og policyen støtter den entitetstypen.
• Grenser — Én ansvarlig leder som standard; bruk en dokumentert identifikatormatrise bare når skjemaet og byline-malene støtter ekte medforfatterskap.
• Hvem eller hva som forbruker det — Synlige bylines, forfatterprofillenker, Article-skjema, strømmer, redaksjonelle eierskapsrapporter, gjennomgangsarbeidsflyter og entitetsgrafer.
• Regler — Løs identifikatoren før publisering. Profilen må identifisere samme person som vises i bylinjen og holdes vedlike. Krediter personen som er ansvarlig for innholdet, ikke personen som bare lastet det opp.
• Vanlige feil — Å legge inn et ukoblet navn som streng, bruke «Admin» eller et oppdiktet redaksjonelt team, tildele en fremtredende leder som ikke forfattet arbeidet, la en identifikator løses til ingen profil, og endre forfatterskap for å antyde ekspertise som ikke var involvert.

reviewedBy, reviewedAt og reviewScope

• Formål — Disse feltene registrerer en uavhengig gjennomgang som er distinkt fra forfatterskap. reviewedBy identifiserer anmelderentiteten; reviewedAt angir når gjennomgangen ble fullført; reviewScope sier hva anmelderen sjekket, slik at merket ikke impliserer godkjenning utover bevisene.
• Type og format — reviewedBy er en stabil identifikator som løses til en vedlikeholdt personprofil. reviewedAt bruker nettstedets tidsstempelformat. reviewScope er en konsis ren tekst-erklæring som «Rotasjonstrinn for legitimasjon og sikkerhetsadvarsler.»
• Påkrevd? — Betinget når lov, risikopolitikk, emnefølsomhet eller innleggstypespesifikasjonen krever uavhengig gjennomgang. Når reviewedBy er til stede, er gjennomgangsdato og omfang påkrevd som gjennomgangspostdata, selv om en bestemt mal lagrer dem i en tilkoblet redaksjonell post i stedet for offentlig frontmatter.
• Grenser — Navngi bare faktiske anmeldere. Omfanget bør være spesifikt nok til å avsløre ekskluderinger uten å bli en gjennomgangsrapport. En anmelder må ha relevant kompetanse og må ikke bare duplisere forfatterrollen.
• Hvem eller hva som forbruker det — Vurdert-av-komponenter, personentitetskoblinger, styringrevisjoner, høysikkerhetspublikasjonsporter, strukturert opprinnelse og oppdateringslogger.
• Regler — Fullfør gjennomgang etter at innholdet er stabilt, fang opp funn og løsning i redaksjonell historikk, og vurder på nytt når senere endringer påvirker det gjennomgåtte omfanget. Uavhengig betyr at anmelderen tester arbeidet i stedet for å godkjenne eget utkast.
• Vanlige feil — Å behandle kopiredigering som ekspertvurdering, vise en anmelder uten dato eller omfang, navngi noen som aldri så den endelige versjonen, la merket stå igjen etter en vesentlig urevidert omskriving, og antyde juridisk, medisinsk eller teknisk godkjenning utenfor det oppgitte omfanget.

Media og sosiale medier

image og imageAlt

• Formål — image velger den representative helte- og sosiale ressursen; imageAlt gir det funksjonelle tekstalternativet når den ressursen gjengis som meningsfullt sideinnhold. Å holde paret sammen forhindrer at oppdagelsesbilder blir en tilgjengelighetsutelatelse.
• Type og format — image er en løsbar nettstedsti eller godkjent absolutt URL. imageAlt er ren tekst som beskriver bildets nyttige informasjon i sidekonteksten, ikke filnavnet eller mål-nøkkelordet.
• Påkrevd? — Betinget etter innleggstype og mal. Hvis siden krever et heltebilde eller dedikert sosialt bilde, er image påkrevd. imageAlt er påkrevd når det bildet gjengis informativt; en rent dekorativ gjengivelse må bruke et tomt alt-attributt i malen, ikke oppdiktet beskrivende tekst.
• Grenser — Bruk én representativ ressurs. For sosial kompatibilitet, oppgi en 1200 × 625 piksel-kilde i forventet beskjæringsforhold, hold viktig innhold unna kantene, og hold imageAlt konsist — normalt 5–160 tegn. Filen må eksistere før den refereres.
• Hvem eller hva som forbruker det — Heltekomponenter, oppføringskort, Open Graph- og Twitter-tagger, skjemabilde-felt, strømmer, bildepipelines, skjermlesere når synlig, og ressurskvalitetssikring.
• Regler — Velg et bilde som fortsatt kommuniserer etter en senterbeskjæring og i miniatyrstørrelse. Beskriv dets funksjon i kontekst: «API-nøkkelinnstillinger med Roter-nøkkel uthevet» er nyttig; «API-nøkkel» er det ikke. Ikke legg vesentlige påstander bare inne i piksler.
• Vanlige feil — Å referere til en planlagt ressurs som ikke finnes, bruke en logo som hvert artikkelbilde, innebygge liten tekst som blir uleselig i delinger, skrive «bilde av», stappe nøkkelord inn i alt-tekst, og anta at sosial alt-tekst og synlig bilde-alt-atferd er identisk på tvers av plattformer.

Open Graph- og Twitter-kortfelt

• Formål — Sosiale metadata styrer hvordan en URL oppsummeres når den deles. En konsistent tittel, beskrivelse, URL, type og bilde hjelper mottakere å gjenkjenne siden før de klikker og reduserer sjansen for at en plattform velger en irrelevant ressurs.
• Type og format — I dette repositoriet utleder malene og:title og twitter:title fra title, beskrivelser fra description, URL-er fra permalinken, og:type fra layoutkonteksten, og begge bildetaggene fra image med en nettstedreserve. twitter:card sendes ut som summary_large_image. Dette er genererte tagger, ikke dupliserte frontmatter-felt som standard.
• Påkrevd? — Utdata-taggene er påkrevd på offentlige sider. Separate overstyringer er valgfrie og bør bare introduseres gjennom en dokumentert malkontrakt; ustøttede ad hoc-felt som ogTitle gjør ingenting.
• Grenser — Én sammenhengende forhåndsvisning per side og ett 1200 × 625 representativt bilde. Hold utledet ordlyd innenfor tittel- og beskrivelsesrammene, test deretter den faktiske beskjæringen og overleggsatferden på større delingsflater.
• Hvem eller hva som forbruker det — Sosiale nettverk, meldingsklienter, lenkeutfoldeapparater, nettleserutvidelser, samarbeidsverktøy og forhåndsvisningsfeilsøkere for deling.
• Regler — Foretrekk utledning slik at søke- og sosiale påstander holder seg på linje. Overstyr bare når den sosiale konteksten virkelig trenger en annen innramming og malen støtter det. Et feil bilde koster gjenkjennelse og tillit: mottakeren kan se et utdatert grensesnitt, et annet produkt, en misvisende påstand eller en beskjæring som skjuler emnet.
• Vanlige feil — Å skrive felt som ingen mal leser, la en global reserve skjule en manglende påkrevd helte, bruke et portrett- eller lite bilde for et bredt kort, endre sosial tekst for å gi et sterkere løfte enn siden, og validere bare HTML-kilden i stedet for en hentet forhåndsvisning.

Klassifisering

taxonomy, categories og tags

• Formål — Klassifisering kobler en side til styrte emne-, format-, målgruppe- eller produktsamlinger. Det driver nyttige arkiver og filtre bare når hvert vokabular har en erklært betydning; ellers blir etiketter en ukontrollert haug med synonymer.
• Type og format — Matriser av registrerte lowercase slug-er. Bruk taxonomy for repositoriets styrte emnevokabular. Bruk categories bare for et lite gjensidig forståelig redaksjonelt hierarki og tags bare for et styrt kryssskjærende vokabular når disse taksonomiene er konfigurert.
• Påkrevd? — Betinget etter innleggstype og arkivdesign. Emnebærende redaksjonelle sider krever normalt ett eller flere styrte begreper; nytte-sider kan kreve ingen. Et felt må ikke fylles ut bare fordi et CMS viser det.
• Grenser — For generell taksonomi, én til fem verdier per styrt vokabular. Hvert begrep trenger en definisjon, eier og sammenslåingsregel. Opprett et indekserbart arkiv bare når begrepet representerer varig leseretterspørsel og arkivet kan tilby en unik introduksjon, sammenhengende inventar, interne lenker og løpende vedlikehold.
• Hvem eller hva som forbruker det — Arkivsider, brødsmuler, filtre, relatert-innholdssystemer, fasettert navigasjon, innholdsrevisjoner og analysesegmentering.
• Regler — Velg det smaleste registrerte begrepet som nøyaktig grupperer siden. Hold entall/flertall, forkortelser og stavevarianter kartlagt til én kanonisk verdi. Bestem om arkiver er indekserbare på vokabularnivå, ikke tag for tag etter utilsiktet opprettelse.
• Vanlige feil — Å bruke seo, SEO, search-optimization og search engine optimization som separate verdier, legge til engangstagger for å beskrive hvert substantiv, forveksle en forretningstype med et emne, generere tynne indekserbare arkiver og slette begreper uten å migrere medlemmene.

Playbook-koblingsnøkler

• Formål — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage og amicitedFeatures er typede koblingsnøkler. De lar én kildeside vises i genererte biblioteker og matriser uten at redaktører kopierer kort for hånd. Denne siden er det bearbeidede eksemplet: pillaren identifiserer et element, familien grupperer metadataveiledning, og postTypes-matrisen erklærer spesifikasjonene som forbruker den.
• Type og format — Entallsnøkler bruker registrerte lowercase slug-er: playbookPillar og playbookFamily er strenger, playbookWave er et heltall, og journeyStage er en styrt streng. Relasjonsnøkler—postTypes, elements, businessTypes og amicitedFeatures—er matriser av registrerte slug-er fra deres respektive registre.
• Påkrevd? — playbookPillar og playbookWave er påkrevd på playbook-poster. playbookFamily er påkrevd der pillaren har styrte familier. Matrisekoblingene og journeyStage er betingede: fyll bare ut relasjoner sidekontrakten faktisk støtter.
• Grenser — Én pillar, én familie innenfor den pillaren, én wave og ett reisetrinn med mindre modellen eksplisitt tillater flere trinn. Matriser inneholder unike registrerte nøkler, ikke visningsetiketter, prosa eller URL-er.
• Hvem eller hva som forbruker det — Playbook-hub-oppføringer, tverrpillaermatriser, filtre, relasjonskort, fullstendighetsrapporter, utgivelseswavevisninger og interne verktøy som finner relevante AmICited-funksjoner.
• Regler — Valider hver verdi mot det kanoniske registeret. Retning betyr noe: en innleggstypeside lister sine påkrevde elements; en elementside lister gjeldende postTypes; en forretningstypside lister nyttige innleggstyper. Behandle etiketter som presentasjon og nøkler som varige data. Gi nytt navn til en nøkkel bare gjennom en migrasjon som oppdaterer hver side av koblingen.
• Vanlige feil — Å finne opp nærsynonymer, lagre titler i stedet for slug-er, blande heltall og strenger for waves, legge til en relasjon fordi to sider nevner hverandre, la gjensidige matriser motsi hverandre, og opprette håndvedlikeholdt oppføringsmarkering som driver fra metadata.

Avledede og strukturelle felt

schemaType

• Formål — schemaType velger den mest spesifikke støttede strukturerte datakartleggingen som nøyaktig beskriver den synlige siden. Det forteller skjematilpasseren hvilken vokabular-kontrakt som skal brukes; det gjør ikke siden til den tingen bare ved erklæring.
• Type og format — Ett registrert Schema.org-typenavn som Article, valgt fra typene nettstedstilpasseren støtter. Store/små bokstaver og stavemåte må samsvare med registeret.
• Påkrevd? — Betinget. Angi det der flere skjemakartlegginger er gyldige for samme Hugo-type, eller der innleggstypekontrakten krever en eksplisitt type. Ellers la malen utlede sin trygge standard.
• Grenser — Én primær sidetype, med nestede entiteter opprettet av tilpasseren fra faktisk innhold. Den valgte typen må oppfylle alle påkrevde egenskaper og samsvare med hva en leser kan se.
• Hvem eller hva som forbruker det — JSON-LD-tilpassere, rik-resultatvalidering, innholdskvalitetssikring og skjemainventarrapporter.
• Regler — Velg ut fra sidefunksjon og synlige bevis, ikke fra søkefunksjonen en redaktør ønsker. En how-to-side uten en fullstendig synlig prosedyre kan ikke oppnå nøyaktighet ved å sette en how-to-type. Hold skjema-URL-er, datoer, personer og bilder synkronisert med kildefeltene.
• Vanlige feil — Å velge en mer spesifikk type uten dens påkrevde innhold, sende ut flere motstridende primærtyper, kopiere en skjemaverdi fra en urelatert mal, anta at gyldig syntaks garanterer kvalifikasjon, og sette påstander i JSON-LD som lesere ikke kan inspisere.

Lesetid

• Formål — Lesetid gir en leser et grovt innsatsanslag. Det er utledet fra den endelige gjengivbare brødteksten slik at anslaget endres når den faktiske lesebyrden endres.
• Type og format — Et beregnet heltall minutter produsert fra innholdspipelineens ordtellingspolicy. Kodeblokker, tabeller, bildetekster og innebygde medier bør følge én dokumentert telleregel.
• Påkrevd? — Visningen er valgfri etter mal. Et forfattet frontmatter-felt er ikke tillatt som sannhetskilde.
• Grenser — Rund av konsekvent og bruk en fornuftig minimumsvisning som ett minutt. Den nøyaktige ord-per-minutt-antakelsen betyr mindre enn å bruke samme metode gjennom hele nettstedet og merke resultatet som et anslag.
• Hvem eller hva som forbruker det — Sidehoder, kort, strømmer, analysesegmentering og lesere som bestemmer seg for om de skal starte en lang guide.
• Regler — Beregn etter at kortkoder og ekskluderte regioner er behandlet i henhold til nettstedets policy. Rekalkuler ved hver bygg. Hvis video eller en interaktiv oppgave vesentlig endrer fullføringstiden, merk det separat i stedet for å korrumpere lesetiden.
• Vanlige feil — Å skrive readingTime = 8, glemme å oppdatere det etter en omskriving, presentere falsk presisjon, telle navigasjon og sjablongtekst, og behandle en utførelse-tung how-to som åtte minutter lesing pluss ingen oppgavetid.

[[faq]]

• Formål — [[faq]] lagrer synlige spørsmål-og-svar-par én gang slik at siden og eventuelle kvalifiserte FAQ-strukturerte data ikke kan drive fra hverandre.
• Type og format — En TOML-matrise med tabeller; hvert element inneholder ett rentekst question og en selvstendig answer-streng.
• Påkrevd? — Betinget når genuine oppfølgingsspørsmål gjenstår etter hovedsiden. Det er aldri påkrevd bare for å fylle en mal eller forfølge en søkefunksjon.
• Grenser — Normalt fire til åtte nyttige elementer på playbook-sider. Hvert spørsmål vises én gang, og hvert svar må være fullstendig uten å være avhengig av harmonika-rekkefølge.
• Hvem eller hva som forbruker det — Synlig FAQ-gjengivelse, FAQPage-skjema der kvalifisert, sidenavigasjon, innholdskvalitetssikring og svarekstraksjon.
• Regler — Dette er en kryssreferansekontrakt: følg Hvorfor FAQ lever i frontmatter og FAQ-veiledningen senere i stedet for å vedlikeholde separate synlige og skjemakopier. Lagre bare spørsmål hver leser kan få tilgang til på siden.
• Vanlige feil — Skjulte skjema-bare svar, dupliserte overskrifter forkledd som spørsmål, salgsfremmende svar, ubegrunnede påstander, utdatert JSON-LD og å behandle søkeresultatkvalifikasjon som garantert.

[[lnks]]

• Formål — [[lnks]] registrerer hver styrt intern lenke som brukes i brødteksten, og parer dens synlige ankertekst med en destinasjon og vedlikeholdt beskrivelse. Posten gjør lenker kontrollerbare uten å skrape gjengitt HTML og støtter migrasjon og kvalitetssikring.
• Type og format — En TOML-matrise med tabeller med text, path og title. text er den nøyaktige synlige ankerteksten, path er en nettstedrelativ URL med ledende og avsluttende skråstrek, og title er destinasjonssidens beskrivelse.
• Påkrevd? — Påkrevd for hver intern brødtekstlenke styrt av denne innholdskonvensjonen. App-dyplenker og eksterne kilder følger sine egne poster og er ikke forkledd som [[lnks]]-oppføringer.
• Grenser — Én post per forekomst av brødtekstlenke når samme ankertekst kan peke til forskjellige destinasjoner; ellers bør nøyaktige duplikatposter fjernes. Destinasjonen må eksistere eller være i det godkjente kanoniske slug-registeret for den koordinerte utgivelsen.
• Hvem eller hva som forbruker det — Intern lenkevalidering, innholdsmigrering, relasjonsanalyse, lenketittelgenerering der støttet, og redaksjonell gjennomgang.
• Regler — Match text til brødtekstens ankertekst ordrett, inkludert store/små bokstaver og tegnsetting inne i lenken. Bruk den kanoniske nettstedrelative banen. Skriv title som en nøyaktig destinasjonsbeskrivelse, ikke som instruksjoner for gjeldende side. Oppdater posten og brødteksten sammen.
• Vanlige feil — Å bruke en lengre text-verdi enn selve ankerteksten, finne opp en uregistrert slug, utelate en avsluttende skråstrek, registrere en omdirigerende gammel bane, beskrive kilden i stedet for destinasjonen, og la en post stå igjen etter at brødtekstlenken er fjernet.

Påkrevd versus valgfri etter innleggstype

Matrisen bruker kontraktene ovenfor på de tolv innleggstypene som for tiden er erklært av dette elementet. R betyr påkrevd, C betyr betinget under feltreglene, D betyr påkrevd utdata som kan utledes trygt, og O betyr valgfri. «Identitet» inkluderer entity, id, title, type og den stabile ruten. «Oppdagelse» inkluderer description og keywords; målspørsmål forblir betinget for hver rad. aliases er alltid betinget ved en flytting, mens forfattet lesetid er aldri påkrevd.

«Betinget anmelder» er ikke tillatelse til å hoppe over gjennomgang der nøyaktighet eller kommersiell risiko krever det. Best-X- og alternatives-sider krever uavhengig gjennomgang fordi deres anbefalinger kan vesentlig påvirke en beslutning og ofte endres når produkter, priser og kvalifikasjoner endres. For andre rader aktiverer risikopolitikken, ikke en redaktørs tilgjengelige tid, kravet. Likeledes er en canonical merket D fortsatt påkrevd i gjengitt HTML; bare frontmatter-inndataet kan utelates når malen kan generere den korrekte selvreferansen.

Frontmatter-validering

Validering bør avvise deterministiske feil automatisk og forbeholde dømmekraft for spørsmål som avhenger av mening, bevis eller profesjonell kompetanse. Splittingen forhindrer to motsatte feil: å be anmeldere fange syntaks en parser kan fange perfekt, og å late som en tegnantallsregel kan avgjøre om kopi er ærlig.

Kjør deterministiske kontroller før redaksjonell gjennomgang slik at anmelderen ser en sammenhengende post. Gå deretter gjennom gjengitt HTML, ikke bare frontmatter: en gyldig kildeverdi er fortsatt en produksjonsfeil hvis den valgte malen ignorerer den, kartlegger den til feil tag, skjuler påkrevd opprinnelse, eller genererer en canonical som er uenig med den offentlige ruten. Publisering er fullført bare når kilde, gjengivelse og destinasjonsatferd stemmer overens.

entity-feltet

entity svarer på «hvilken nøyaktig innleggstype er dette dokumentet et eksempel på?» Det svarer ikke på «hvilket emne diskuterer denne siden?» Det skillet betyr noe fordi to dokumenter kan adressere samme emne mens de gjør forskjellige jobber. En glossoppføring definerer «diagnose»; en bloggartikkel kan rapportere en endring i diagnostisk veiledning. Hvis begge bruker entity = "diagnosis", kan ikke systemer nedstrøms pålitelig velge riktig mal, valideringsregler, analysegruppe eller migrasjon.

Bruk gruppeprefikset pluss innleggstypens slug for varianter innenfor en familie: guide-how-to, guide-ultimate, comparison-a-vs-b og comparison-alternatives-to-x. Bruk det rene navnet for en frittstående type: product-page eller case-study. Registrer identifikatoren én gang, hold den stabil, og endre den aldri fordi emnet eller målspørringen endres. Sett emnekonsepter i taxonomy og søkespråk i keywords.

Tittel, H1 og SEO-tittel

Disse verdiene kan variere etter kontekst, men må beskrive samme side. title er den varige standarden. h1 er den synlige overskriften og kan være mer naturlig i kontekst. seoTitle tjener nettleser og søkeresultater og kan legge til et konsist skilleelement, legitimt år eller merkevaresuffiks.

For eksempel samsvarer title = "API Key Rotation", h1 = "How to Rotate an API Key Without Downtime" og seoTitle = "API Key Rotation: Safe Step-by-Step Guide" om én oppgave. «Free Security Tool» som SEO-tittel ville være villedende fordi det endrer løftet. Ikke skap forskjeller bare for å sette inn flere nøkkelord.

Beskrivelsesregler

Beskrivelsen finnes for å hjelpe en kvalifisert leser å bestemme seg for å klikke. Hold den innenfor 150–160 tegn, inkluder hovedtermen naturlig, oppgi sidens konkrete fordel, og legg til en meningsfull kvalifikator som målgruppe, omfang eller resultat. Skriv én flytende setning, ikke en nøkkelordliste.

Termen bekrefter relevans; repetisjon tilfører ingen verdi. Ikke dupliser tittelen, bruk «Lær alt om», kom med ubegrunnede superlativer, eller avslutt midt i en tanke. Søkesystemer kan fortsatt velge annen synlig tekst for et søk.

Datoer, forfattere og anmeldere

date bevarer det første publiseringstidsstempelet. updated registrerer den siste vesentlige endringen: en faktakorrektur, nye bevis, endrede instruksjoner, revidert omfang, endret anbefaling, eller fullstendig gjennomgang som bekrefter tidssensitive påstander. Registrer hva som endret seg i den redaksjonelle historikken når policyen krever det.

Å rette tegnsetting, endre en knappestil, bygge om en mal eller bare berøre tidsstempelet nullstiller ikke updated. Å fremme en dato uten arbeid bak er et policybrudd fordi det forteller lesere og maskiner at innholdet ble oppdatert når det ikke ble det. Det er feilrepresentasjon, ikke en veksttaktikk.

Forfatter- og anmelderfelt bærer ansvarlige identiteter inn i bylines og strukturerte data. Forfatteren er ansvarlig for arbeidet. Bruk reviewedBy bare når kvalifisert gjennomgang fant sted, og koble begge identifikatorene til vedlikeholdte profiler. Tillitsgrunnlagssiden forklarer hvordan forfatterskap, datoer, bevis og entitetstyper støtter tillit uten å garantere rangeringer.

Hvorfor FAQ lever i frontmatter

En FAQ er synlig innhold og en strukturert samling. Å lagre den én gang i [[faq]] lar malen gjengi harmonikaen og identisk FAQPage JSON-LD, og forhindrer utdatert skjult skjema.

Inkluder genuine oppfølgingsspørsmål synlige for hver leser. Ikke dupliser overskrifter, skjul reklame i svar, eller merk opp ikke-viste spørsmål. Gyldig markup garanterer ikke en søkefunksjon.

Syntaks og kodeeksempler

Den kryssplattformkontrakten kartlegger felt, ikke en synlig komponent. Følgende bærbare konvolutt er bare gyldig i en utvekslingsfil hvis importør gjenkjenner metadatadirektiver:

:::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
:::

Den må normaliseres til opprinnelig sidemetadata under import. Den er ikke gyldig i brødteksten til en produksjonsartikkel. I Hugo er den korrekte kartleggingen TOML mellom +++-markører ved første byte, som vist i det levende eksemplaret. Det er bevisst ingen {{< frontmatter >}}-kortkode: en kortkode ville kjøre for sent og i feil dokumentområde.

I WordPress, kartlegg de samme kanoniske feltene til registrerte postfelt og postmeta, for eksempel post_title, post_excerpt, post_name, _amicited_entity, _amicited_author og _amicited_reviewed_by. En kommentar som <!-- wp:amicited/frontmatter --> eller en [frontmatter]-kortkode er ugyldig fordi den oppretter en innholdsblokk i stedet for dokumentmetadata. Importører og redaktører kan presentere et metadatapanel, men de lagrede verdiene må forbli knyttet til posten.

Eksempler

Bra: én sammenhengende, ansvarlig post

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/"

Dette identifiserer en how-to-variant, bevarer historikk, navngir ansvarlige personer, og skiller emne fra sideidentitet. Det oppdaterte tidsstempelet støttes av en dokumentert instruksjonsendring og gjennomgang.

Dårlig: tittelen gjentatt som beskrivelse

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

Beskrivelsen tilfører ingen fordel, omfang eller grunn til å klikke. Den kaster også bort forhåndsvisningsplassen som kunne skilt denne siden fra hvert annet resultat med samme tittel.

Dårlig: én entity gjenbrukt på tvers av to innleggstyper

# glossoppføring
entity = "diagnosis"

# redaksjonell guide
entity = "diagnosis"

Det delte emnet har erstattet innleggstypeidentiteten. Bruk registrerte verdier som glossary-term og guide-ultimate, tilordne deretter «diagnosis» gjennom taksonomi eller nøkkelord.

Dårlig: en oppdatert dato uten innholdsendring

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

Ingen vesentlig redigering eller gjennomgang støtter ferskhetspåstanden. Hold updated uendret eller utelatt inntil en reell endring finnes og kan inspiseres i redaksjonell historikk.

Skjemamarkering og tilgjengelighet

Metadata leverer verdier; malen forblir ansvarlig for semantisk HTML, fokus, kontrast, lenkeformål og alternativ tekst.

Skriveregler

• Hold identifikatorer stabile, lowercase og maskinsikre. Gjenbruk aldri en id eller endre entity stille etter publisering.
• Bruk ren tekst i tittellignende felt. HTML, Markdown-lenker, emoji-dekorasjon og tvungne linjeskift hører ikke hjemme i metadata-strenger.
• Hold beskrivelsen på 150–160 tegn og nøkkelordmatriser på seks til åtte distinkte fraser for denne playbooken.
• Bruk ekte registrerte personer for forfatter- og anmelderfelt. Lag aldri en seremoniell anmelder eller generisk «Redaksjonelt team»-identitet med mindre det er en vedlikeholdt ansvarlig enhet.
• Bruk en styrt taksonomi. Stavevarianter og entall/flertall-duplikater skaper fragmenterte arkiver.
• Referer bare til bilder som finnes og har publiseringsrettigheter. imageAlt beskriver bildets informative innhold, ikke dets SEO-mål.
• Hold FAQ-svar direkte og selvstendige. Påstander krever fortsatt samme bevis og avsløring som prosa andre steder på siden.
• Plasser aldri hemmeligheter, private notater, tilgangstokener, embargo-instruksjoner, personopplysninger eller ureviderte juridiske påstander i publiserbar frontmatter.

Hvilke innleggstyper bruker frontmatter, og hvor

Hver innleggstype bruker frontmatter ved første byte. Påkrevd dybde endres med risiko, hensikt og skjema snarere enn med visuelt design.

QA-sjekkliste

• Starter filen med +++, inneholder den gyldig TOML, og lukker posten før brødtekstinnhold?
• Er entity en registrert nøyaktig innleggstypeidentifikator snarere enn emnet, kampanjen eller nettstedsnavnet?
• Er id unik og stabil, og samsvarer url med det kanoniske slug-registeret?
• Beskriver title, valgfri h1 og valgfri seoTitle samme side uten villedende omfangsendringer?
• Er beskrivelsen 150–160 tegn, inneholder den hovedtermen naturlig, og gir den en konkret grunn til å klikke?
• Eksisterer hvert refererte bilde, og er imageAlt nøyaktig for bildet som gjengis?
• Er publiseringsdatoen bevart, og er hver updated-verdi støttet av en vesentlig endring eller dokumentert gjennomgang?
• Løses forfatter- og anmelderidentifikatorer til ekte vedlikeholdte profiler, og gjennomgikk den navngitte anmelderen faktisk arbeidet?
• Er nøkkelord begrenset til seks til åtte nyttige fraser, og taksonomiverdier hentet fra styrte vokabularer?
• Bruker canonical HTTPS, løses den til den foretrukne siden, og samsvarer den med sidekartet og interne lenker?
• Inneholder hvert [[faq]]-element ett nyttig spørsmål og et selvstendig svar som gjengis synlig med identisk ordlyd?
• Samsvarer generert JSON-LD med synlig innhold, bruker stabile identifikatorer, og består syntaksvalidering uten å hevde ustøttede typer?
• Er hemmeligheter, private redaksjonelle notater, ubegrunnede påstander og brødtekst-only avsløringer fraværende fra posten?

FAQ

Er frontmatter synlig på den publiserte siden?

Kildeposten er skjult, men maler kan gjengi tittelen, personer, datoer og FAQ. Andre felt mater forhåndsvisninger, kanoniske tagger, strømmer, sidekart, skjema og interne systemer.

Bør entitetsfeltet inneholde emnet eller innleggstypen?

Det identifiserer den nøyaktige innleggstypen. Delte emner hører hjemme i taksonomi og nøkkelord, ikke i stedet for dokumentidentitet.

Kan tittelen, H1 og SEO-tittelen være forskjellige?

Ja. H1 kan leses mer naturlig og SEO-tittelen kan legge til et skilleelement, men alle versjoner må gi samme løfte.

Når bør oppdateringsdatoen endres?

Endre den etter en vesentlig faktisk gjennomgang eller redigering. Ikke endre den for tegnsetting, styling, malfunksjoner eller en dato-bare oppdatering.

Hvorfor lagres FAQ-spørsmål i frontmatter?

Den strukturerte matrisen lar én kilde gjengi både synlig FAQ og samsvarende FAQPage JSON-LD. Det forhindrer at skjema driver bort fra hva lesere kan inspisere.