Indhold Frontmatter: Felter og SEO-metadata

Frontmatter er det sideelement, læsere aldrig ser som én blok, og som ethvert publiceringssystem er afhængigt af. Det giver et dokument en identitet, gengivelseskontrakt, søgepreview, ejerskabsregistrering, datoer og skemainput. Ødelagt frontmatter kan vælge den forkerte skabelon, skabe kanoniske konflikter, miste forfatteren eller udsende markup, der modsiger siden.

Det levende eksemplar er en dokument-niveau registrering, vist som kode, fordi frontmatter ikke må blive en dekorativ boks i brødteksten.

+++
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 læser reducerer metadata usikkerhed. En præcis titel sætter rammen, en nyttig beskrivelse fortjener klikket, identiteter gør krav ansvarlige, og datoer afslører, om information kan være forældet. Disse signaler kan ikke kompensere for svagt indhold, men deres fravær tvinger læseren til at gætte.

For maskiner erstatter frontmatter inferens med navngivne værdier. Skabeloner kortlægger felter til browsertitler, kanoniske links, personregistreringer, datoer, feeds, indekser og JSON-LD uden at skulle skrabe brødtekst. Dette er maskinel udtrækbarhed: vigtige fakta har en konsistent placering og type.

Følg element-skrivereglerne: metadata hører til på dokumentniveau; læservendte elementer hører til i brødteksten. En byline kan gengives fra frontmatter, men dens autoritative identifikator forbliver der.

Hvornår det skal bruges — og hvornår ikke

Hver indekserbar side har brug for én frontmatter-registrering til identitet, gengivelse og routing. Kladder har brug for den, når de går i produktion, så validering kan fejle tidligt.

Gem ikke artikel-fakta i frontmatter. Produktbegrænsninger, sikkerhedsadvarsler, tilknytningsoplysninger, metoder og kilder skal forblive synlige, hvor læsere kan vurdere dem. En struktureret værdi erstatter aldrig en oplysning.

Næsten-miss’er forårsager mest skade:

• Uafhængigt varierende navigationsetiketter, kampagnekopi og sociale billedtekster er kanalindstillinger; overbelast ikke title.
• Organisationsfakta, der deles på tværs af hele webstedet, hører til i webstedets organisationsregistrering, ikke kopieret ind på hver side, hvor de vil afvige.
• Et spørgsmål-og-svar-afsnit hører kun til i [[faq]], når det samme indhold gengives synligt. Skjult schema-only FAQ er ugyldigt.
• En emneetiket hører til i taxonomy; den må ikke erstatte den entity, der identificerer dokumentets post-type.
• En omdirigering hører til i routing-konfiguration eller et godkendt aliases-felt. canonical identificerer den foretrukne version; den omdirigerer ikke besøgende.

Hvor det placeres

Frontmatter begynder ved den første byte med +++ og slutter ved det matchende skel før brødteksten. Ingen overskrift, kommentar, note, shortcode eller metadatablok må komme før den. TOML-felter og -arrays hører til i den ene registrering.

Brødteksten begynder efter det afsluttende skel. Frontmatter kan ikke sidde mellem H1 og introduktion, ved siden af et skærmbillede, inde i en komponent eller til sidst. Et byte-order-mærke eller en løs kommentar kan forhindre genkendelse. Duplikerede nøgler, YAML-skel og anden blokke er ugyldige.

Anatomi

Den gengivne legende forbliver på siden, så den forbliver læsbar og oversættelig uafhængigt af billedet:

1. Afgrænsning: de åbnende og afsluttende +++-skel definerer den eneste metadataregion.
2. Identitet: entity, id, type og url fortæller systemer, hvad dokumentet er, og hvor det findes.
3. Opdagelse: title, seoTitle, description, image, imageAlt og keywords understøtter forhåndsvisninger og søgning.
4. Oprindelse: date, updated, author og reviewedBy angiver, hvem der er ansvarlig, og hvornår værket blev ændret gyldigt.
5. Klassifikation: taxonomy forbinder siden til kontrollerede emnesamlinger uden at omdefinere dens identitet.
6. Duplikeringskontrol: canonical navngiver den foretrukne offentlige URL, når ækvivalente versioner kan nås andre steder.
7. Strukturerede samlinger: hver [[faq]] opretter én typet spørgsmål-og-svar-registrering til synlig gengivelse og skema.

Designeksempler

Frontmatter har datakontrakt-varianter, ikke visuelle stilarter. Skærmbilleder parrer kilderegistreringer med deres resulterende forhåndsvisning eller byline.

Parametre

Dette er redaktionelle grænser, selv når en parser accepterer mere. “Betinget” betyder påkrævet, når den angivne betingelse er sand.

Reference pr. felt

Denne reference definerer publiceringskontrakten for hvert felt. “Påkrævet” betyder, at validering bør stoppe publicering, når feltet eller dets gyldige afledning mangler. “Betinget” betyder, at kravet aktiveres af en angivet kendsgerning, såsom at et billede gengives, eller at en uafhængig gennemgang har fundet sted. En standard er kun sikker, når den producerer samme betydning, som en redaktør ville have valgt bevidst.

Identitet og routing

title, h1 og seoTitle

• Formål — title giver dokumentet dets holdbare redaktionelle navn. h1 styrer den primære sideoverskrift, når layoutkonteksten kræver anden ordlyd. seoTitle styrer browser-/søgetitlen, når standarden har brug for et kort kvalifikationsord eller brandbehandling. Adskillelse forhindrer, at en navigationsetiket, sideoverskrift og søgepreview bliver tvunget ind i én akavet streng.
• Type og format — Hver er en ren tekst-streng. title er kildeværdien; fraværende overskrivelser skal falde tilbage til den. HTML, Markdown, emoji-dekoration og manuelle afkortningsmarkeringer er ikke gyldige værdier.
• Påkrævet? — title er påkrævet på alle offentlige sider. h1 og seoTitle er valgfrie og bør udelades, når title fungerer i alle tre kontekster.
• Grænser — Brug 30–70 tegn til title, 20–80 til h1 og 30–60 til seoTitle som redaktionelle bånd, ikke løfter om, at en søgegrænseflade viser hvert tegn. Der skal være én gengivet H1.
• Hvem eller hvad bruger det — Sideskabeloner, browsertitler, søge- og sociale adaptere, navigationskort, feeds, schema headline, tilgængelighedsoversigter og redaktionelle lister.
• Regler — Alle versioner skal identificere samme emne, hensigt og omfang. En legitim forskel løser en kanalbegrænsning: for eksempel kan H1 sige “How to Rotate an API Key Without Downtime”, mens den kortere SEO-titel siger “API Key Rotation: Safe Step-by-Step Guide”. Afsnittet Titel, H1 og SEO-titel forklarer den redaktionelle test.
• Almindelige fejl — Gentage et søgeord i alle tre varianter, sætte et brand-suffiks i H1, ændre løftet for at jage klik, indsætte indeværende år når siden ikke vedligeholdes årligt, eller skrive tre værdier blot fordi der er tre felter.

slug og url

• Formål — Slug er det sidste stisegment; url er den webstedsrelative offentlige rute, der indeholder det. Sammen giver de siden en stabil adresse for læsere, crawlers, links, rapportering og migrationer. Stabilitet betyder noget, fordi hvert optjent link og gemt bogmærke bliver afhængigt af den adresse.
• Type og format — Brug en lowercase, bindestregssepareret sti-streng som /academy/rotate-an-api-key/. Dette repository registrerer hele ruten i url; et CMS, der har et separat slug-felt, skal udlede det samme sidste segment.
• Påkrævet? — En unik rute er påkrævet for hver offentlig side. Den må kun genereres, hvor en sektion har en godkendt deterministisk regel og kollisionskontrol; playbook-sider bruger deres registrerede url-værdier.
• Grænser — Foretræk et kort, læsbart slug, der bevarer det adskillende emne, normalt tre til otte nyttige ord. Fjern tegnsætning og tomme modifikatorer. Fjern stopord som “den” eller “et” kun, når resultatet forbliver naturligt og entydigt; der er ingen vilkårlig tegnbegrænsning, der retfærdiggør at skade betydningen.
• Hvem eller hvad bruger det — Hugo routing, interne links, brødkrummer, kanonisk generering, sitemaps, feeds, analyse, omdirigeringer og eksterne referencer.
• Regler — Behandl et publiceret slug som en permanent forpligtelse. Beslut det ud fra det holdbare emne, ikke en kampagneoverskrift eller et forbigående år. Når titlen ændres, men emnet og hensigten ikke gør, behold det gamle slug. Hvis siden reelt flyttes, opret den nye rute, behold den gamle rute i aliases, opdater interne links, og test omdirigeringsdestinationen.
• Almindelige fejl — Regenerere slug når titlen ændres, proppe synonymer ind i stien, beholde datoer der får tidløst indhold til at se forældet ud, bruge blandet kasus eller understregninger, oprette to URL’er der kun adskiller sig ved en afsluttende skråstreg, og ændre en rute uden at bevare den gamle.

canonical

• Formål — En canonical identificerer den foretrukne URL blandt ækvivalente eller næsten-ækvivalente tilgængelige versioner. Den konsoliderer identitet; den flytter ikke en besøgende og undskylder ikke ukontrolleret duplikering.
• Type og format — Én absolut HTTPS-URL, inklusive den tilsigtede vært og normaliserede sti: https://amicited.com/academy/rotate-an-api-key/. Skabelonen kan udlede en selvreference fra sidens permalink, når webstedet har én pålidelig vært og rutepolitik.
• Påkrævet? — Hver indekserbar side skal udsende én canonical. Feltet i sig selv er betinget, når en korrekt selvrefererende værdi udledes automatisk; angiv det eksplicit for en godkendt cross-domæne eller ekstraordinær canonical.
• Grænser — Præcis ét canonical-mål. Målet skal returnere et succesfuldt indekserbart dokument, bruge den foretrukne protokol og vært og repræsentere væsentligt det samme indhold.
• Hvem eller hvad bruger det — HTML <link rel="canonical">, søgemaskiner, sitemap- og interne linkkontrol, deduplikeringsrapporter og schema URL-identifikatorer.
• Regler — Selvreference som standard. Brug en cross-domæne canonical kun, når en anden udgiver ejer den foretrukne ækvivalent, og begge parter agter konsolidering. Brug en omdirigering, ikke en canonical, når den gamle URL er blevet erstattet, og brugere altid bør lande på den nye. Hold canonical, sitemap-URL, hreflang, interne links og schema-identitet justeret.
• Almindelige fejl — Peke hver pagineret eller lokaliseret side til en generisk forælder, canonicalisere forskelligt indhold, målrette en omdirigering eller fejlside, blande HTTP og HTTPS, bruge feltet som erstatning for et alias og antage, at canonical-direktiver garanteret efterleves.

aliases

• Formål — aliases bevarer ruter, der tidligere identificerede samme side, så en flytning ikke gør eksisterende links og bogmærker til blindgyder. Den registrerer rutehistorie i stedet for at skabe alternative indekserbare identiteter.
• Type og format — Et TOML-array af webstedsrelative stier, for eksempel aliases = [ "/blog/old-api-key-guide/" ]. Hver værdi inkluderer en førende og afsluttende skråstreg og skal være unik på tværs af webstedet.
• Påkrævet? — Valgfrit for en ny side; påkrævet når en publiceret side flyttes fra en sti, webstedet kontrollerede.
• Grænser — Inkluder hver kendt tidligere første-part rute, der stadig modtager links eller trafik. Tilføj ikke spekulative stavevarianter eller en ubegrænset liste af søgeords-URL’er.
• Hvem eller hvad bruger det — Hugos alias-output, deployment-omdirigeringsbehandling hvor konfigureret, migrations-QA, linkovervågning og brugere der følger gamle URL’er. Fordi Hugo kan udsende en alias-side snarere end en HTTP-omdirigering på oprindelsesniveau, skal deployment-adfærd verificeres i stedet for antages.
• Regler — En flyttet side holder sin gamle sti fungerende. Hvert alias skal løses i ét hop til den aktuelle kanoniske rute. Opdater interne links til den nye URL, selv når aliaset virker, og bevar aliaset ved senere redigeringer, medmindre et dokumenteret omdirigeringssystem erstatter det.
• Almindelige fejl — Slette den gamle side uden et alias, kæde gammel sti til mellemliggende sti til nuværende sti, behandle aliases som duplikerede publiceringsruter, peke flere ikke-relaterede sider til én bekvem destination eller antage at lokalt Hugo-output beviser produktions HTTP-status.

type og layout

• Formål — Disse felter vælger gengivelseskontrakten. type placerer en side i en indholdsklasse med delte skabeloner og adfærd; layout anmoder om en specifik skabelon inden for den klasse. Korrekt valg sikrer, at siden modtager den tilsigtede navigation, indholdsplads, aktiver og skema-adfærd.
• Type og format — Lowercase registrerede strenge. Denne side bruger type = "academy". En layout-værdi er et skabelon-basenavn som single, uden filtypenavn eller sti-gennemløb.
• Påkrævet? — type er påkrævet, når indholdsplaceringen ikke sikkert antyder den tilsigtede type, eller når playbook-kontrakten kræver det. layout er valgfri og bør udelades, når typens standardskabelon er korrekt.
• Grænser — Én værdi for hvert felt, kun valgt blandt skabeloner vedligeholdt af webstedet. En ny værdi er en teknisk ændring, ikke en redaktionel improvisation.
• Hvem eller hvad bruger det — Hugos opslagsrækkefølge, skabeloner, delvise valg, CSS- og JavaScript-inkludering, skemaadaptere og valideringsregler.
• Regler — Vælg post-type og gengivelseskontrakt før udkast. Brug layout kun til en ægte understøttet variant; brug det ikke til at kompensere for indhold, der tilhører en anden type. Bekræft, at en overskrivelse eksisterer og accepterer sidens frontmatter-form.
• Almindelige fejl — Forveksle den redaktionelle entity med Hugo type, navngive en skabelonfil der ikke eksisterer, kopiere en landingssidetype på et akademidokument, stole på mappeinferens under en migration og introducere engangs-layoutnavne der omgår fælles forbedringer.

Opdagelse

description

• Formål — Beskrivelsen hjælper en kvalificeret søger eller delingsmodtager med at beslutte, om denne side opfylder behovet. Det er forhåndsvisningskopi, ikke en komprimeret introduktion og ikke et sted at bevise relevans gennem gentagelse.
• Type og format — Én ren tekst-sætning. Den bør nævne det primære udtryk naturligt, angive den konkrete værdi og tilføje nyttig afgrænsning, målgruppe, metode eller resultat.
• Påkrævet? — Påkrævet for hver indekserbar side i denne playbook.
• Grænser — 150–160 tegn, inklusive mellemrum. Dette er et redaktionelt konsistensbånd, ikke en visningsgaranti: søgemaskiner kan afkorte det eller omskrive uddraget fra brødteksten, når et andet afsnit passer bedre til forespørgslen.
• Hvem eller hvad bruger det — Meta description-tags, Open Graph- og Twitter-beskrivelsesstandarder, listekort, feeds, CMS-forhåndsvisninger, søgekvalitetskontrol og nogle gange schema description.
• Regler — Skriv for et klik fra den rigtige læser. Gør sætningen specifik nok til at adskille siden fra et andet resultat med en lignende titel. Afsnittet Beskrivelsesregler nedenfor giver begrundelsen og afvisningstest.
• Almindelige fejl — Duplikere titlen, liste søgeord, åbne med “Lær alt om,” komme med en ubegrundet bedste-eller-hurtigste påstand, bruge en vag call-to-action, overskride båndet gennem et usynligt brand-suffiks eller antage at den forfattede tekst skal optræde ordret i søgeresultater.

keywords

• Formål — I dette repository registrerer keywords det kompakte søge- og terminologisæt, der bruges til redaktionel QA, korpussøgning, dækningsanalyse og interne værktøjer. Det hjælper redaktører med at genkende det sprog, en side skal bruge præcist; det er ikke et løfte om at inkludere hver sætning mekanisk.
• Type og format — Et array af naturligt-sprog-strenge, ordnet fra det primære udtryk gennem meningsfulde varianter og tæt beslægtet terminologi.
• Påkrævet? — Påkrævet under denne playbook, inklusive for sider hvis offentlige skabeloner ikke gengiver værdierne.
• Grænser — Seks til otte distinkte indgange. Hver indgang skal repræsentere en reel søgesætning eller nødvendigt udtryk, ikke en token-niveau variation.
• Hvem eller hvad bruger det — Redaktionelle validatorer, indholdsinventarer, søge- og mulighedsanalyse, intern hentning og migrationsværktøjer. Offentlige søgemaskiner bruger ikke dette felt som et rangsignal blot fordi det eksisterer.
• Regler — Hold sættet fokuseret på én sides omfang. Flet kasus, tegnsætning, ental/flertal og trivielle ordstillingsdubletter. Brug sætningerne til at kontrollere dækning og terminologi, aldrig til at diktere unaturlig tæthed.
• Almindelige fejl — Behandle feltet som den forældede meta-keywords-rangmekanisme, tilføje dusinvis af varianter, gentage titlen som otte næsten-dubletter, indsætte konkurrentnavne brødteksten ikke diskuterer og lade arrayet erstatte ordentlig taksonomi eller prompt-mål.

targetPrompts

• Formål — targetPrompts registrerer de komplette spørgsmål eller anmodninger, en person kan give et AI-svarssystem, og som denne side bør være en nyttig kilde til. Prompt-mål bevarer samtalekontekst, som korte søgeordssætninger udelader.
• Type og format — Et array af komplette, naturligt-sprog-strenge, 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 bruger ville spørge, inklusive målgruppe, begrænsninger eller ønsket sammenligning.
• Påkrævet? — Betinget for sider inkluderet i prompt-sporing eller et AI-synlighedsindholdsprogram; valgfrit når intet sporet promptsæt eksisterer.
• Grænser — Brug et lille, intentionelt sæt, normalt én primær prompt og op til fire meningsfulde varianter. En prompt kan være længere end et søgeord, fordi dens kvalifikationer bærer hensigten.
• Hvem eller hvad bruger det — Indholdsoversigter, prompt-sporingsarbejdsgange, hentnings- og dækningsrevisioner, AI-svarovervågning og redaktionel evaluering. Det gengives ikke som skjult søgekopi.
• Regler — Adskil prompter efter faktisk informationsbehov, ikke tegnsætning. Et søgeord som “API key rotation” navngiver et emne; “How can a SaaS team rotate an API key without interrupting integrations?” navngiver en målgruppe, opgave og begrænsning. Siden må besvare hver gemt prompt ærligt.
• Almindelige fejl — Kopiere keywords-arrayet ind i dette felt, fabrikere dusinvis af syntaktiske variationer, registrere prompter bredere end siden, bruge prompter som brødtekst-overskrifter uanset læseflow og påstå prompt-dækning når svaret afhænger af information siden ikke giver.

Tillid og oprindelse

date og updated

• Formål — date bevarer hvornår siden blev første gang publiceret; updated rapporterer den seneste substantielle ændring eller gennemførte gennemgang. To felter bevarer historik samtidig med at de viser, om information læsere stoler på er ændret.
• Type og format — Tidsstempelstrenge i webstedets konvention, YYYY-MM-DD HH:MM:SS. Hold én tidszonepolitik på tværs af korpuset, så feeds og sammenligninger forbliver deterministiske.
• Påkrævet? — date er påkrævet for publicerede redaktionelle sider. updated er valgfrit indtil en kvalificerende ændring opstår, derefter påkrævet hvis siden præsenterer en ændret dato.
• Grænser — Én værdi hver. updated kan ikke være før date eller ligge i fremtiden. En rettelse foretaget minutter efter publicering kan stadig dokumenteres, men rutinemæssige udkastsrevisioner før publicering skaber ikke en opdateret dato.
• Hvem eller hvad bruger det — Synlige bylines og friskhedsstempler, feeds, sitemaps, schema datePublished og dateModified, aktualitetsrevisioner, sortering og redaktionelle køer.
• Regler — Nulstil updated for en faktuel rettelse, ændret instruktion, ny eller fjernet evidens, revideret afgrænsning, væsentligt ændret anbefaling eller en dokumenteret gennemgang af tidsfølsomme påstande. Nulstil det aldrig for tegnsætning, formatering, skabelonarbejde eller en tidsstempel-only redigering. Se Datoer, forfattere og anmeldere for politikbegrundelsen.
• Almindelige fejl — Overskrive den oprindelige dato under en opdatering, fremtidsdatere en side for at fremstå frisk, opdatere datoer uden et indholdsdiff, behandle en automatiseret deployment som en redaktionel opdatering og undlade at registrere hvad der ændrede sig i den vedligeholdte opdateringshistorik.

author

• Formål — author forbinder dokumentet til den ansvarlige person-enhed, der står for arbejdet. Linket giver en læser og en maskine en sti fra en krav-bærende side til vedligeholdt identitet, ekspertise og andet arbejde.
• Type og format — En stabil forfatteridentifikator, der løses gennem webstedets forfatterregister til en profil-URL og Person-registrering. For eksempel er author = "maya-chen" kun gyldig, hvis den identifikator løses; et visningsnavn som "Maya Chen, SEO Expert" er ikke en erstatning for enhedslinket.
• Påkrævet? — Påkrævet for substantielle redaktionelle sider. Transaktionssider kan bruge en styret organisationsejer, kun når skabelonen og politikken understøtter den enhedstype.
• Grænser — Én ansvarlig leder som standard; brug et dokumenteret identifikator-array kun når skemaet og byline-skabelonerne understøtter ægte medforfatterskab.
• Hvem eller hvad bruger det — Synlige bylines, forfatterprofillinks, Article-skema, feeds, redaktionelle ejerskabsrapporter, gennemgangsarbejdsgange og enhedsgrafer.
• Regler — Løs identifikatoren før publicering. Profilen skal identificere samme person som vist i bylinen og forblive vedligeholdt. Krediter den person, der er ansvarlig for indholdet, ikke den person, der blot uploadede det.
• Almindelige fejl — Indtaste et ikke-linket navn, bruge “Admin” eller et opfundet redaktionelt team, tildele en fremtrædende leder der ikke skrev værket, lade en identifikator løse til ingen profil og ændre forfatterskab for at antyde ekspertise der ikke var involveret.

reviewedBy, reviewedAt og reviewScope

• Formål — Disse felter registrerer en uafhængig gennemgang adskilt fra forfatterskab. reviewedBy identificerer reviewer-enheden; reviewedAt angiver hvornår gennemgangen blev afsluttet; reviewScope siger hvad revieweren tjekkede, så mærket ikke antyder godkendelse ud over evidensen.
• Type og format — reviewedBy er en stabil identifikator, der løses til en vedligeholdt personprofil. reviewedAt bruger webstedets tidsstempelformat. reviewScope er en kortfattet ren tekst-erklæring som “Credential rotation steps and security cautions.”
• Påkrævet? — Betinget når lov, risikopolitik, emnefølsomhed eller post-type-specifikationen kræver uafhængig gennemgang. Når reviewedBy er til stede, er gennemgangsdato og -omfang påkrævet som gennemgangsregistreringsdata, selvom en bestemt skabelon gemmer dem i en tilknyttet redaktionel registrering frem for offentlig frontmatter.
• Grænser — Navngiv kun faktiske reviewere. Omfang bør være specifikt nok til at afsløre udeladelser uden at blive en gennemgangsrapport. En reviewer må have relevant kompetence og må ikke blot duplikere forfatterrollen.
• Hvem eller hvad bruger det — Reviewed-by-komponenter, person-enheds-joins, styringsrevisioner, højrisiko-publiceringsporte, struktureret oprindelse og opdateringslogs.
• Regler — Gennemfør gennemgang efter indholdet er stabilt, indfang resultater og løsning i redaktionel historik, og gennemgå igen når senere ændringer påvirker det gennemgåede omfang. Uafhængig betyder at reviewer tester arbejdet i stedet for at godkende deres eget udkast.
• Almindelige fejl — Behandle korrekturlæsning som ekspertgennemgang, vise en reviewer uden dato eller omfang, navngive nogen der aldrig så den endelige version, efterlade mærket efter en væsentlig ureviewet omskrivning og antyde juridisk, medicinsk eller teknisk godkendelse uden for det angivne omfang.

Medie og socialt

image og imageAlt

• Formål — image vælger det repræsentative hero- og sociale aktiv; imageAlt leverer det funktionelle tekstalternativ når det aktiv gengives som meningsfuldt sideindhold. At holde parret sammen forhindrer opdagelsesbilleder i at blive en tilgængelighedsudeladelse.
• Type og format — image er en løsbar webstedssti eller godkendt absolut URL. imageAlt er ren tekst, der beskriver billedets nyttige information i dets sidekontekst, ikke dets filnavn eller målsøgeord.
• Påkrævet? — Betinget efter post-type og skabelon. Hvis siden kræver et hero- eller dedikeret socialt billede, er image påkrævet. imageAlt er påkrævet når billedet gengives informativt; en rent dekorativ gengivelse må bruge et tomt alt-attribut i skabelonen, ikke opfundet beskrivende tekst.
• Grænser — Brug ét repræsentativt aktiv. For social kompatibilitet, lever en 1200 × 630 pixel kilde i det forventede beskæringsforhold, hold vigtigt indhold væk fra kanterne, og hold imageAlt kortfattet—normalt 5–160 tegn. Filen skal eksistere før den refereres.
• Hvem eller hvad bruger det — Hero-komponenter, listekort, Open Graph- og Twitter-tags, schema-billedfelter, feeds, billedpipelines, skærmlæsere når synligt, og aktiv-QA.
• Regler — Vælg et billede der stadig kommunikerer efter en centerbeskæring og i miniaturestørrelse. Beskriv dets funktion i kontekst: “API key settings with Rotate key highlighted” er nyttigt; “API key” er ikke. Læg ikke væsentlige påstande kun inde i pixels.
• Almindelige fejl — Referere et planlagt aktiv der ikke eksisterer, bruge et logo som hvert artikelbillede, indlejre lille tekst der bliver ulæselig i delinger, skrive “billede af,” proppe søgeord ind i alt-tekst og antage at social alt-tekst og synlig billed-alt-adfærd er identisk på tværs af platforme.

Open Graph- og Twitter-kortfelter

• Formål — Social metadata styrer hvordan en URL opsummeres når den deles. En konsistent titel, beskrivelse, URL, type og billede hjælper modtagere med at genkende siden før klik og reducerer chancen for at en platform vælger et irrelevant aktiv.
• Type og format — I dette repository udleder skabeloner og:title og twitter:title fra title, beskrivelser fra description, URL’er fra permalink, og:type fra layoutkonteksten og begge billed-tags fra image med et websteds-fallback. twitter:card udsendes som summary_large_image. Disse er genererede tags, ikke duplikerede frontmatter-felter som standard.
• Påkrævet? — Output-tags er påkrævet på offentlige sider. Separate overskrivelser er valgfrie og bør kun introduceres gennem en dokumenteret skabelonkontrakt; ikke-understøttede ad hoc-felter som ogTitle gør ingenting.
• Grænser — Ét sammenhængende preview pr. side og ét 1200 × 630 repræsentativt billede. Hold afledt ordlyd inden for titel- og beskrivelsesbåndene, test derefter den faktiske beskæring og overlay-adfærd på større delingsflader.
• Hvem eller hvad bruger det — Sociale netværk, messaging-klienter, link-udfoldere, browserudvidelser, samarbejdsværktøjer og delingspreview-debuggere.
• Regler — Foretræk afledning så søge- og sociale påstande forbliver justeret. Overskriv kun når den sociale kontekst reelt har brug for anderledes indramning og skabelonen understøtter det. Et forkert billede koster genkendelse og tillid: modtageren kan se et forældet interface, et andet produkt, en vildledende påstand eller en beskæring der skjuler emnet.
• Almindelige fejl — Forfatte felter som ingen skabelon læser, tillade et globalt fallback at maskere et manglende påkrævet hero-billede, bruge et portræt eller lille billede til et bredt kort, ændre social kopi for at give et stærkere løfte end siden og validere kun HTML-kilden i stedet for et hentet preview.

Klassifikation

taxonomy, categories og tags

• Formål — Klassifikation forbinder en side til styrede emne-, format-, målgruppe- eller produktsamlinger. Det driver nyttige arkiver og filtre kun når hvert vokabular har en erklæret betydning; ellers bliver etiketter en ukontrolleret synonymbunke.
• Type og format — Arrays af registrerede lowercase slugs. Brug taxonomy til repository’ets kontrollerede emnevokabular. Brug categories kun til et lille gensidigt forståeligt redaktionelt hierarki og tags kun til et styret tværgående vokabular når disse taksonomier er konfigureret.
• Påkrævet? — Betinget af post-type og arkivdesign. Emnebærende redaktionelle sider kræver normalt én eller flere kontrollerede termer; hjælpesider kan kræve ingen. Et felt må ikke udfyldes blot fordi et CMS eksponerer det.
• Grænser — For generel taksonomi, én til fem værdier pr. kontrolleret vokabular. Hver term har brug for en definition, ejer og flettregel. Opret et indekserbart arkiv kun når termen repræsenterer holdbar læserefterspørgsel og arkivet kan tilbyde en unik introduktion, sammenhængende inventar, interne links og løbende vedligeholdelse.
• Hvem eller hvad bruger det — Arkivsider, brødkrummer, filtre, relateret-indhold-systemer, facetteret navigation, indholdsrevisioner og analysesegmentering.
• Regler — Vælg den snævreste registrerede term der præcist grupperer siden. Hold ental/flertal, forkortelser og stavevarianter kart til én kanonisk værdi. Beslut om arkiver er indekserbare på vokabularniveau, ikke tag for tag efter utilsigtet oprettelse.
• Almindelige fejl — Bruge seo, SEO, search-optimization og search engine optimization som separate værdier, tilføje engangs-tags for at beskrive hvert navneord, forveksle en forretningstype med et emne, generere tynde indekserbare arkiver og slette termer uden at migrere deres medlemmer.

Playbook-join-nøgler

• Formål — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage og amicitedFeatures er typedefinerede join-nøgler. De lader én kildeside optræde i genererede biblioteker og matricer uden at redaktører kopierer kort i hånden. Denne side er det bearbejdede eksempel: dens pillar identificerer et element, dens familie grupperer metadatavejledning, og dens postTypes-array erklærer de specifikationer, der forbruger det.
• Type og format — Entalsnøgler bruger registrerede lowercase slugs: playbookPillar og playbookFamily er strenge, playbookWave er et heltal, og journeyStage er en kontrolleret streng. Relationsnøgler—postTypes, elements, businessTypes og amicitedFeatures—er arrays af registrerede slugs fra deres respektive registre.
• Påkrævet? — playbookPillar og playbookWave er påkrævet på playbook-registreringer. playbookFamily er påkrævet hvor pillar’en har styrede familier. Array-joins og journeyStage er betingede: udfyld kun relationer sidekontrakten faktisk understøtter.
• Grænser — Én pillar, én familie inden for den pillar, én wave og ét journey-stage medmindre modellen eksplicit tillader flere stadier. Arrays indeholder unikke registrerede nøgler, ikke visningsetiketter, prosa eller URL’er.
• Hvem eller hvad bruger det — Playbook-hub-lister, tværpillar-matricer, filtre, relationskort, fuldstændighedsrapporter, release-wave-visninger og interne værktøjer der finder relevante AmICited-kapaciteter.
• Regler — Valider hver værdi mod det kanoniske register. Retning betyder noget: en post-typeside lister sine påkrævede elements; en elementside lister anvendelige postTypes; en forretningstypeside lister nyttige post-typer. Behandle etiketter som præsentation og nøgler som holdbare data. Omdøb en nøgle kun gennem en migration der opdaterer hver side af join’en.
• Almindelige fejl — Opfinde næsten-synonymer, gemme titler i stedet for slugs, blande heltal og strenge til waves, tilføje en relation fordi to sider nævner hinanden, lade gensidige arrays modsige hinanden og skabe håndvedligeholdt listemarkup der driver væk fra metadata.

Afledte og strukturelle felter

schemaType

• Formål — schemaType vælger den mest specifikke understøttede strukturerede-data-kortlægning, der præcist beskriver den synlige side. Den fortæller skemaadapteren hvilken vokabular-kontrakt der skal anvendes; den gør ikke siden til den ting ved erklæring alene.
• Type og format — Ét registreret Schema.org-typenavn såsom Article, valgt blandt de typer webstedets adapter understøtter. Kasus og stavning skal matche registreret.
• Påkrævet? — Betinget. Angiv det hvor flere skema-kortlægninger er gyldige for samme Hugo-type, eller hvor post-type-kontrakten kræver en eksplicit type. Ellers lad skabelonen udlede sin sikre standard.
• Grænser — Én primær sidetype, med indlejrede enheder skabt af adapteren fra faktisk indhold. Den valgte type skal opfylde alle påkrævede egenskaber og matche hvad en læser kan se.
• Hvem eller hvad bruger det — JSON-LD-adaptere, rich-resultat-validering, indholds-QA og skema-inventarrapporter.
• Regler — Vælg ud fra sidefunktion og synlig evidens, ikke ud fra den søgefunktion en redaktør ønsker. En how-to-side uden en komplet synlig procedure kan ikke opnå nøjagtighed ved at sætte en how-to-type. Hold skema-URL’er, datoer, personer og billeder synkroniseret med deres kildefelter.
• Almindelige fejl — Vælge en mere specifik type uden dens påkrævede indhold, udsende flere modstridende primære typer, kopiere en skemaværdi fra en ikke-relateret skabelon, antage at gyldig syntaks garanterer berettigelse og lægge påstande i JSON-LD som læsere ikke kan inspicere.

Læsetid

• Formål — Læsetid giver en læser et groft skøn over indsats. Det afledes fra den endelige gengivelige brødtekst, så skønnet ændres når den faktiske læsebyrde ændres.
• Type og format — Et beregnet heltal antal minutter produceret fra indholdspipeline’ens ordtællingspolitik. Kodeblokke, tabeller, billedtekster og indlejrede medier bør følge én dokumenteret tælleregel.
• Påkrævet? — Visningen er valgfri efter skabelon. Et forfattet frontmatter-felt er ikke tilladt som sandhedskilde.
• Grænser — Afrund konsekvent og anvend en fornuftig minimumsvisning såsom ét minut. Den præcise ord-pr.-minut-antagelse betyder mindre end at bruge samme metode på hele webstedet og mærke resultatet som et skøn.
• Hvem eller hvad bruger det — Sidehoveder, kort, feeds, analysesegmentering og læsere der beslutter om de vil starte en lang guide.
• Regler — Beregn efter shortcodes og ekskluderede regioner er håndteret i henhold til webstedspolitikken. Genberegn ved hver build. Hvis video eller en interaktiv opgave væsentligt ændrer færdiggørelsestid, mærk det separat i stedet for at forvride læsetiden.
• Almindelige fejl — Forfatte readingTime = 8, glemme at opdatere det efter en omskrivning, præsentere falsk præcision, tælle navigation og boilerplate og behandle en eksekverings-tung how-to som otte minutters læsning plus ingen opgavetid.

[[faq]]

• Formål — [[faq]] gemmer synlige spørgsmål-og-svar-par én gang, så siden og eventuelle berettigede FAQ-strukturerede data ikke kan drive fra hinanden.
• Type og format — Et TOML-array af tabeller; hvert element indeholder én ren tekst question og én selvstændig answer-streng.
• Påkrævet? — Betinget når ægte opfølgningsspørgsmål forbliver efter hovedsiden. Det er aldrig påkrævet blot for at udfylde en skabelon eller forfølge en søgefunktion.
• Grænser — Normalt fire til otte nyttige elementer på playbook-sider. Hvert spørgsmål optræder én gang, og hvert svar skal være komplet uden at stole på accordion-rækkefølge.
• Hvem eller hvad bruger det — Synlig FAQ-gengivelse, FAQPage-skema hvor berettiget, sidenavigation, indholds-QA og svarekstraktion.
• Regler — Dette er en krydsreferencekontrakt: følg Hvorfor FAQ lever i frontmatter og den senere FAQ-vejledning i stedet for at vedligeholde separate synlige og skema-kopier. Gem kun spørgsmål hver læser har adgang til på siden.
• Almindelige fejl — Skjulte schema-only svar, duplikerede overskrifter forklædt som spørgsmål, salgsfremmende svar, ubegrundede påstande, forældet JSON-LD og behandle søgeresultat-berettigelse som garanteret.

[[lnks]]

• Formål — [[lnks]] registrerer hvert styret internt link brugt i brødteksten, og parrer dets synlige anker med en destination og vedligeholdt beskrivelse. Registreringen gør links inspicerbare uden at skulle skrabe gengivet HTML og understøtter migration og QA.
• Type og format — Et TOML-array af tabeller med text, path og title. text er det præcise synlige anker, path er en webstedsrelativ URL med førende og afsluttende skråstreg, og title er destinationssidens beskrivelse.
• Påkrævet? — Påkrævet for hvert internt brødtekstlink styret af denne indholdskonvention. App-dybe links og eksterne kilder følger deres egne registreringer og forkædes ikke som [[lnks]]-indgange.
• Grænser — Én registrering pr. brødtekstlink-forekomst når samme anker kan pege på forskellige destinationer; ellers bør præcise duplikerede registreringer fjernes. Destinationen må eksistere eller være i det godkendte kanoniske slug-register for den koordinerede udgivelse.
• Hvem eller hvad bruger det — Intern link-validering, indholdsmigration, relationsanalyse, link-titel-generering hvor understøttet og redaktionel gennemgang.
• Regler — Match text til brødtekstankeret ordret, inklusive store/små bogstaver og tegnsætning inde i linket. Brug den kanoniske webstedsrelative sti. Skriv title som en præcis destinationsbeskrivelse, ikke som instruktioner til den nuværende side. Opdater registreringen og brødteksten sammen.
• Almindelige fejl — Bruge en længere text-værdi end det faktiske anker, opfinde et uregistreret slug, udelade en afsluttende skråstreg, registrere en omdirigerende gammel sti, beskrive kilden i stedet for destinationen og efterlade en registrering efter dens brødtekstlink er fjernet.

Påkrævet versus valgfrit efter post-type

Matricen anvender kontrakterne ovenfor på de tolv post-typer, der i øjeblikket er erklæret af dette element. R betyder påkrævet, C betyder betinget under feltreglerne, D betyder påkrævet output der sikkert kan afledes, og O betyder valgfrit. “Identitet” inkluderer entity, id, title, type og den stabile rute. “Opdagelse” inkluderer description og keywords; målprompter forbliver betingede for hver række. aliases er altid betinget af en flytning, mens forfattet læsetid aldrig er påkrævet.

“Betinget reviewer” er ikke tilladelse til at springe gennemgang over, hvor nøjagtighed eller kommerciel risiko kræver det. Bedste-X- og alternativsider kræver uafhængig gennemgang, fordi deres anbefalinger kan påvirke en beslutning væsentligt og ofte ændres når produkter, priser og berettigelse ændres. For andre rækker aktiverer risikopolitikken, ikke en redaktørs tilgængelige tid, kravet. Ligeledes er en canonical markeret D stadig påkrævet i gengivet HTML; kun frontmatter-input kan udelades når skabelonen kan generere den korrekte selvreference.

Frontmatter-validering

Validering bør afvise deterministiske fejl automatisk og reservere dom til spørgsmål der afhænger af betydning, evidens eller professionel kompetence. Opdelingen forhindrer to modsatte fejl: at bede reviewere om at fange syntaks en parser kan fange perfekt, og at lade som om en tegnantal-regel kan afgøre om kopi er ærlig.

Kør deterministiske kontroller før redaktionel gennemgang, så reviewer ser en sammenhængende registrering. Gennemgå derefter den gengivne HTML, ikke kun frontmatter: en gyldig kildeværdi er stadig en produktionsfejl hvis den valgte skabelon ignorerer den, kortlægger den til det forkerte tag, skjuler påkrævet oprindelse eller genererer en canonical der er uenig med den offentlige rute. Publicering er først fuldstændig når kilde, gengivelse og destinationsadfærd er enige.

Feltet entity

entity svarer på “hvilken præcis post-type er dette dokument en instans af?” Den svarer ikke på “hvilket emne diskuterer denne side?” Den sondring betyder noget, fordi to dokumenter kan adressere samme emne mens de udfører forskellige opgaver. Et ordbogsopslag definerer “diagnose”; en blogartikel kan rapportere en ændring i diagnostisk vejledning. Hvis begge bruger entity = "diagnosis", kan downstream-systemer ikke pålideligt vælge den rigtige skabelon, valideringsregler, analysegruppe eller migration.

Brug gruppepræfikset plus post-type-slug til varianter inden for en familie: guide-how-to, guide-ultimate, comparison-a-vs-b og comparison-alternatives-to-x. Brug det rene navn til en selvstændig type: product-page eller case-study. Registrer identifikatoren én gang, hold den stabil, og skift den aldrig fordi emnet eller målsøgningen ændres. Læg emnekoncepter i taxonomy og søgesprog i keywords.

Titel, H1 og SEO-titel

Disse værdier må afvige efter kontekst, men skal beskrive samme side. title er den holdbare standard. h1 er den synlige overskrift og kan være mere naturlig i kontekst. seoTitle tjener browser- og søgeresultater og kan tilføje en kort differentiator, legitimt år eller brand-suffiks.

For eksempel er title = "API Key Rotation", h1 = "How to Rotate an API Key Without Downtime" og seoTitle = "API Key Rotation: Safe Step-by-Step Guide" justeret om én opgave. “Free Security Tool” som SEO-titel ville være vildledende, fordi det ændrer løftet. Skab ikke forskelle blot for at indsætte flere søgeord.

Beskrivelsesregler

Beskrivelsen eksisterer for at hjælpe en kvalificeret læser med at beslutte at klikke. Hold den inden for 150–160 tegn, inkluder det primære udtryk naturligt, angiv sidens konkrete fordel, og tilføj en meningsfuld kvalifikation som målgruppe, afgrænsning eller resultat. Skriv én flydende sætning, ikke en søgeordsliste.

Udtrykket bekræfter relevans; gentagelse tilføjer ingen værdi. Dupliker ikke titlen, brug “Lær alt om,” kom med ubegrundede superlativ, eller slut midt i en tanke. Søgesystemer kan stadig vælge anden synlig tekst til en forespørgsel.

Datoer, forfattere og anmeldere

date bevarer det første publiceringstidspunkt. updated registrerer den seneste substantielle ændring: en faktuel rettelse, ny evidens, ændrede instruktioner, revideret afgrænsning, ændret anbefaling eller komplet gennemgang der bekræfter tidsfølsomme påstande. Registrer hvad der ændrede sig i den redaktionelle historik når politikken kræver det.

Rettelse af tegnsætning, ændring af en knapstil, genopbygning af en skabelon eller blot at røre ved tidsstemplet nulstiller ikke updated. At fremrykke en dato uden arbejde bagved er en politik-overtrædelse, fordi det fortæller læsere og maskiner at indholdet blev opfrisket når det ikke blev. Det er vildledning, ikke en væksttaktik.

Forfatter- og reviewer-felter bærer ansvarlige identiteter ind i bylines og strukturerede data. Forfatteren er ansvarlig for arbejdet. Brug reviewedBy kun når kvalificeret gennemgang fandt sted, og link begge identifikatorer til vedligeholdte profiler. Siden tillidsgrundlag forklarer hvordan forfatterskab, datoer, evidens og enhedsklarhed understøtter tillid uden at garantere rangeringer.

Hvorfor FAQ lever i frontmatter

En FAQ er synligt indhold og en struktureret samling. At gemme den én gang i [[faq]] lader skabelonen gengive accordionen og identisk FAQPage JSON-LD, hvilket forhindrer forældet skjult skema.

Inkluder ægte opfølgningsspørgsmål synlige for hver læser. Dupliker ikke overskrifter, skjul ikke salgsfremstød i svar, eller markup ikke-viste spørgsmål. Gyldig markup garanterer ikke en søgefunktion.

Syntaks og kodeeksempler

Den tværplatformskontrakt kortlægger felter, ikke en synlig komponent. Følgende bærbare konvolut er kun gyldig i en udvekslingsfil hvis importør genkender metadata-direktiver:

:::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 skal normaliseres til indbygget sidemetadata under import. Den er ikke gyldig i brødteksten af en produktionsartikel. I Hugo er den korrekte kortlægning TOML mellem +++-skel ved byte ét, som vist i det levende eksemplar. Der er bevidst ingen {{< frontmatter >}}-shortcode: en shortcode ville køre for sent og i den forkerte dokumentregion.

I WordPress, kortlæg de samme kanoniske felter til registrerede post-felter og post-meta, 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]-shortcode er ugyldig, fordi den skaber en brødtekstblok i stedet for dokumentmetadata. Importører og redaktører må præsentere et metadatapanel, men de gemte værdier må forblive knyttet til post-registreringen.

Eksempler

God: én sammenhængende, ansvarlig registrering

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 identificerer en how-to-variant, bevarer historik, navngiver ansvarlige personer og adskiller emne fra sideidentitet. Det opdaterede tidsstempel understøttes af en dokumenteret instruktionsændring og gennemgang.

Dårligt: titlen gentaget som beskrivelse

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

Beskrivelsen tilføjer ingen fordel, afgrænsning eller grund til at klikke. Den spilder også preview-pladsen, der kunne adskille denne side fra hvert andet resultat med samme titel.

Dårligt: én entity genbrugt på tværs af to post-typer

# ordbogsopslag
entity = "diagnosis"

# redaktionel guide
entity = "diagnosis"

Det delte emne har erstattet post-type-identiteten. Brug registrerede værdier som glossary-term og guide-ultimate, og tildel derefter “diagnosis” gennem taksonomi eller keywords.

Dårligt: en opdateret dato uden indholdsdiff

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

Ingen substantiel redigering eller gennemgang understøtter friskhedspåstanden. Hold updated uændret eller udeladt indtil en reel ændring eksisterer og kan inspiceres i redaktionel historik.

Skema-markup og tilgængelighed

Metadata leverer værdier; skabelonen forbliver ansvarlig for semantisk HTML, fokus, kontrast, linkformål og alternativtekst.

Skriveregler

• Hold identifikatorer stabile, lowercase og maskinsikre. Genbrug aldrig en id eller skift stille entity efter publicering.
• Brug ren tekst i titel-lignende felter. HTML, Markdown-links, emoji-dekoration og tvungne linjeskift hører ikke til i metadatastreng.
• Hold beskrivelsen på 150–160 tegn og søgeords-arrayer på seks til otte distinkte sætninger for denne playbook.
• Brug rigtige registrerede personer til forfatter- og reviewer-felter. Opret aldrig en ceremoniel reviewer eller generisk “Redaktionelt Team”-identitet medmindre det er en vedligeholdt ansvarlig enhed.
• Brug en kontrolleret taksonomi. Stavevarianter og ental/flertal-dubletter skaber fragmenterede arkiver.
• Referer kun billeder der eksisterer og har publiceringsrettigheder. imageAlt beskriver billedets informative indhold, ikke dets SEO-mål.
• Hold FAQ-svar direkte og selvstændige. Påstande kræver stadig samme evidens og oplysning som prosa andre steder på siden.
• Placer aldrig hemmeligheder, private noter, adgangstokens, embargo-instruktioner, personlige data eller ureviewede juridiske krav i publicerbar frontmatter.

Hvilke post-typer bruger frontmatter, og hvor

Hver post-type bruger frontmatter ved byte ét. Den påkrævede dybde ændres med risiko, hensigt og skema snarere end med visuelt design.

QA-tjekliste

• Starter filen med +++, indeholder den gyldig TOML, og lukker den registreringen før brødtekstindhold?
• Er entity en registreret præcis post-type-identifikator snarere end emnet, kampagnen eller webstedsnavnet?
• Er id unik og stabil, og matcher url det kanoniske slug-register?
• Beskriver title, valgfri h1 og valgfri seoTitle den samme side uden vildledende omfangsændringer?
• Er beskrivelsen 150–160 tegn, indeholder den det primære udtryk naturligt, og giver den en konkret grund til at klikke?
• Eksisterer hvert refereret billede, og er imageAlt præcis for det billede der gengives?
• Er publiceringsdatoen bevaret, og er hver updated-værdi understøttet af et substantielt diff eller dokumenteret gennemgang?
• Løses forfatter- og reviewer-identifikatorer til virkelige vedligeholdte profiler, og gennemgik den navngivne reviewer faktisk arbejdet?
• Er keywords begrænset til seks til otte nyttige sætninger, og er taksonomiværdier hentet fra kontrollerede vokabularer?
• Bruger canonical HTTPS, løser den til den foretrukne side, og er den enig med sitemap og interne links?
• Indeholder hvert [[faq]]-element ét nyttigt spørgsmål og et selvstændigt svar der gengives synligt i identisk ordlyd?
• Stemmer genereret JSON-LD overens med synligt indhold, bruger den stabile identifikatorer og består syntaksvalidering uden at kræve ikke-understøttede typer?
• Er hemmeligheder, private redaktionelle noter, ubegrundede påstande og body-only-oplysninger fraværende fra registreringen?

FAQ

Er frontmatter synligt på den publicerede side?

Kilderegistreringen er skjult, men skabeloner må gengive titel, personer, datoer og FAQ. Andre felter leverer til forhåndsvisninger, kanoniske tags, feeds, sitemaps, skema og interne systemer.

Skal enhedsfeltet indeholde emnet eller post-typen?

Det identificerer den præcise post-type. Delte emner hører til i taksonomi og keywords, ikke i stedet for dokumentidentitet.

Kan titel, H1 og SEO-titel være forskellige?

Ja. H1 må læses mere naturligt, og SEO-titlen må tilføje en differentiator, men alle versioner må give samme løfte.

Hvornår skal den opdaterede dato ændres?

Ændr den efter en substantiel faktuel gennemgang eller redigering. Ændr den ikke for tegnsætning, styling, skabelonarbejde eller en dato-only opdatering.

Hvorfor opbevares FAQ-spørgsmål i frontmatter?

Den strukturerede matrix lader én kilde gengive både den synlige FAQ og matchende FAQPage JSON-LD. Det forhindrer skema i at drive væk fra hvad læsere kan inspicere.