Innehåll Frontmatter: Fält och SEO-metadata

Frontmatter är sidelementet som läsare aldrig ser som ett block, men som varje publiceringssystem är beroende av. Det ger ett dokument en identitet, renderingskontrakt, sökförhandsvisning, ägarregister, datum och schemaindata. Felaktig frontmatter kan välja fel mall, skapa kanoniska konflikter, tappa bort författaren eller generera markering som motsäger sidan.

Det levande exemplaret är en post på dokumentnivå, visad som kod eftersom frontmatter inte får bli en dekorativ kroppsruta.

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

Varför frontmatter finns

För en läsare minskar metadata osäkerhet. En precis titel sätter omfattning, en användbar beskrivning förtjänar klicket, identiteter gör påståenden ansvarsfulla, och datum avslöjar om information kan ha åldrats. Dessa signaler kan inte kompensera för svagt innehåll, men deras frånvaro tvingar läsaren att gissa.

För maskiner ersätter frontmatter gissningar med namngivna värden. Mallar mappar fält till webbläsartitlar, kanoniska länkar, personposter, datum, flöden, index och JSON-LD utan att skrapa prosa. Detta är maskinellt extraherbarhet: viktiga fakta har en konsekvent plats och typ.

Följ skrivreglerna för element: metadata hör hemma på dokumentnivå; läsarriktade element hör hemma i brödtexten. En byline kan renderas från frontmatter, men dess auktoritativa identifierare förblir där.

När det ska användas – och när inte

Varje indexerbar sida behöver en frontmatter-post för identitet, rendering och routing. Utkast behöver det när de går i produktion så att validering kan misslyckas i förtid.

Göm inte artikelns fakta i frontmatter. Produktbegränsningar, säkerhetsvarningar, affiliate-avslöjanden, metoder och källor måste förbli synliga där läsare kan utvärdera dem. Ett strukturerat värde ersätter aldrig ett avslöjande.

Nästan-rätt fall orsakar mest skada:

• Oberoende varierande navigeringsetiketter, kampanjtexter och sociala bildtexter är kanalinställningar; överbelasta inte title.
• Organisationsfakta som delas över hela webbplatsen hör hemma i organisationens post, inte kopierade till varje sida där de kommer att skilja sig åt.
• En fråge-och-svar-sektion hör hemma i [[faq]] endast när samma innehåll renderas synligt. Dold schema-endast FAQ är ogiltig.
• En ämnesetikett hör hemma i taxonomy; den får inte ersätta entity som identifierar dokumentets inläggstyp.
• En omdirigering hör hemma i routingkonfiguration eller ett godkänt aliasfält. canonical identifierar den föredragna versionen; den omdirigerar inte besökare.

Var det ska placeras

Frontmatter börjar vid första byten med +++ och slutar vid matchande avgränsare före brödtexten. Ingen rubrik, kommentar, not, shortcode eller metadatablock får föregå det. TOML-fält och arrayer hör hemma i den posten.

Brödtexten börjar efter den avslutande avgränsaren. Frontmatter kan inte placeras mellan H1 och introduktion, bredvid en skärmbild, inuti en komponent eller i slutet. En byteordningsmarkering eller en felplacerad kommentar kan förhindra igenkänning. Dubbla nycklar, YAML-avgränsare och andra block är ogiltiga.

Anatomi

Den renderade förklaringen finns kvar på sidan så att den förblir läsbar och översättbar oberoende av bilden:

1. Avgränsning: de öppnande och avslutande +++-avgränsarna definierar den enda metadataregionen.
2. Identitet: entity, id, type och url berättar för system vad dokumentet är och var det finns.
3. Upptäckt: title, seoTitle, description, image, imageAlt och keywords stödjer förhandsvisningar och sökning.
4. Ursprung: date, updated, author och reviewedBy anger vem som är ansvarig och när arbetet ändrades på ett giltigt sätt.
5. Klassificering: taxonomy kopplar sidan till kontrollerade ämnessamlingar utan att omdefiniera dess identitet.
6. Dupliceringskontroll: canonical namnger den föredragna publika webbadressen när motsvarande versioner kan nås på annat håll.
7. Strukturerade samlingar: varje [[faq]] skapar en typad fråge-och-svar-post för synlig rendering och schema.

Designexempel

Frontmatter har datakontraktsvarianter, inte visuella stilar. Skärmbilder parar ihop källposter med deras resulterande förhandsvisning eller byline.

Parametrar

Dessa är redaktionella gränser även om en tolk accepterar mer. “Villkorlig” betyder obligatoriskt när dess angivna villkor är uppfyllt.

Referens per fält

Denna referens definierar publiceringsavtalet för varje fält. “Obligatoriskt” betyder att validering bör stoppa publicering när fältet eller dess giltiga härledning saknas. “Villkorlig” betyder att kravet aktiveras av ett angivet faktum, såsom att en bild renderas eller att en oberoende granskning har ägt rum. En standard är säker endast när den producerar samma innebörd som en redaktör skulle ha valt medvetet.

Identitet och routing

title, h1 och seoTitle

• Syfte — title ger dokumentet dess varaktiga redaktionella namn. h1 styr den synliga rubriken på sidan när layoutens sammanhang kräver annan formulering. seoTitle styr webbläsar-/söktiteln när standarden behöver en koncis kvalificerare eller varumärkesbehandling. Att separera dem förhindrar att en navigeringsetikett, sidrubrik och sökförhandsvisning tvingas in i en enda besvärlig sträng.
• Typ och format — Var och en är en vanlig textsträng. title är källvärdet; frånvarande åsidosättanden måste falla tillbaka på det. HTML, Markdown, emoji-dekoration och manuella trunkeringsmärken är inte giltiga värden.
• Obligatoriskt? — title är obligatoriskt på varje publik sida. h1 och seoTitle är valfria och bör utelämnas när title fungerar i alla tre sammanhang.
• Gränser — Använd 30–70 tecken för title, 20–80 för h1 och 30–60 för seoTitle som redaktionella band, inte löften om att ett sökgränssnitt kommer att visa varje tecken. Det måste finnas en renderad H1.
• Vem eller vad som konsumerar det — Sidmallar, webbläsartitlar, sök- och sociala adaptrar, navigeringskort, flöden, schema headline, tillgänglighetsöversikter och redaktionella listningar.
• Regler — Alla versioner måste identifiera samma ämne, avsikt och omfattning. En legitim skillnad löser en kanalbegränsning: till exempel kan H1 säga “How to Rotate an API Key Without Downtime”, medan den kortare SEO-titeln säger “API Key Rotation: Safe Step-by-Step Guide.” Avsnittet Titel, H1 och SEO-titel förklarar det redaktionella testet.
• Vanliga misstag — Upprepa ett nyckelord i alla tre varianter, sätta ett varumärkessuffix i H1, ändra löftet för att jaga klick, bädda in innevarande år när sidan inte underhålls årligen, eller skriva tre värden bara för att tre fält finns.

slug och url

• Syfte — Slugen är det sista sökvägssegmentet; url är den sajtrelativa publika rutten som innehåller den. Tillsammans ger de sidan en stabil adress för läsare, crawlers, länkar, rapportering och migreringar. Stabilitet är viktigt eftersom varje förtjänad länk och sparad bokmark blir beroende av den adressen.
• Typ och format — Använd en gemener, bindestreckseparerad sökvägssträng som /academy/rotate-an-api-key/. Detta arkiv registrerar hela rutten i url; ett CMS som har ett separat slug-fält måste härleda samma slutsegment.
• Obligatoriskt? — En unik rutt krävs för varje publik sida. Den får endast genereras där en sektion har en godkänd deterministisk regel och kollisionskontroller; spelbokssidor använder sina registrerade url-värden.
• Gränser — Föredra en kort, läsbar slug som bevarar det särskiljande ämnet, vanligtvis tre till åtta användbara ord. Ta bort skiljetecken och tomma modifierare. Ta bort stoppord som “the” eller “a” endast när resultatet förblir naturligt och otvetydigt; det finns ingen godtycklig teckengräns som motiverar att skada innebörden.
• Vem eller vad som konsumerar det — Hugo-routing, interna länkar, brödsmulor, kanonisk generering, sajtkartor, flöden, analys, omdirigeringar och externa referenser.
• Regler — Behandla en publicerad slug som ett permanent åtagande. Bestäm den utifrån det varaktiga ämnet, inte en kampanjrubrik eller ett tillfälligt år. När titeln ändras men ämne och avsikt inte gör det, behåll den gamla slugen. Om sidan verkligen flyttas, skapa den nya rutten, behåll den gamla rutten i aliases, uppdatera interna länkar och testa omdirigeringsmålet.
• Vanliga misstag — Återskapa slugen närhelst titeln ändras, stoppa in synonymer i sökvägen, behålla datum som får evigt innehåll att se föråldrat ut, använda blandad versal eller understreck, skapa två webbadresser som endast skiljer sig åt i ett avslutande snedstreck, och ändra en rutt utan att bevara den gamla.

canonical

• Syfte — En kanonisk identifierar den föredragna webbadressen bland motsvarande eller nästan motsvarande tillgängliga versioner. Den konsoliderar identitet; den flyttar inte en besökare eller ursäktar okontrollerad duplicering.
• Typ och format — En absolut HTTPS-URL, inklusive den avsedda värden och normaliserad sökväg: https://amicited.com/academy/rotate-an-api-key/. Mallen kan härleda en självreferens från sidans permalänk när webbplatsen har en pålitlig värd- och rutpolicy.
• Obligatoriskt? — Varje indexerbar sida måste skicka ut en kanonisk. Fältet i sig är villkorligt när ett korrekt självrefererande värde härleds automatiskt; ställ in det explicit för en godkänd korsdomän eller exceptionell kanonisk.
• Gränser — Exakt ett kanoniskt mål. Målet måste returnera ett framgångsrikt indexerbart dokument, använda det föredragna protokollet och värden, och representera väsentligen samma innehåll.
• Vem eller vad som konsumerar det — HTML <link rel="canonical">, sökmotorer, sajtkarta- och internlänkskontroller, dedupliceringsrapporter och schema-URL-identifierare.
• Regler — Självreferens som standard. Använd en korsdomänkanonisk endast när en annan utgivare äger den föredragna motsvarigheten och båda parter avser konsolidering. Använd en omdirigering, inte en kanonisk, när den gamla webbadressen har ersatts och användare alltid ska landa på den nya. Håll kanonisk, sajtmap-URL, hreflang, interna länkar och schemaidentitet i linje.
• Vanliga misstag — Peka varje paginerad eller lokaliserad sida till en generisk förälder, kanonisera distinkt innehåll, rikta in en omdirigering eller felsida, blanda HTTP och HTTPS, använda fältet som ersättning för ett alias, och anta att kanoniska direktiv garanterat efterlevs.

aliases

• Syfte — aliases bevarar rutter som tidigare identifierade samma sida, så att en flytt inte gör befintliga länkar och bokmärken till återvändsgränder. Den registrerar rutthistoria snarare än att skapa alternativa indexerbara identiteter.
• Typ och format — En TOML-array med sajtrelativa sökvägar, till exempel aliases = [ "/blog/old-api-key-guide/" ]. Varje värde inkluderar ett inledande och avslutande snedstreck och måste vara unikt på webbplatsen.
• Obligatoriskt? — Valfritt för en ny sida; obligatoriskt när en publicerad sida flyttas från en sökväg som webbplatsen kontrollerade.
• Gränser — Inkludera varje känd tidigare förstapartsrutt som fortfarande får länkar eller trafik. Lägg inte till spekulativa stavningsvarianter eller en obegränsad lista med nyckelords-URL:er.
• Vem eller vad som konsumerar det — Hugos aliasutdata, omdirigeringsbearbetning vid driftsättning där det är konfigurerat, migrationskontroll, länkbevakare och användare som följer gamla webbadresser. Eftersom Hugo kan skicka ut en alias-sida snarare än en HTTP-omdirigering på ursprungsnivå, måste driftsättningsbeteendet verifieras istället för att antas.
• Regler — En flyttad sida håller sin gamla sökväg fungerande. Varje alias måste lösas i ett hopp till den aktuella kanoniska rutten. Uppdatera interna länkar till den nya webbadressen även när aliaset fungerar, och bevara aliaset över senare redigeringar om inte ett dokumenterat omdirigeringssystem ersätter det.
• Vanliga misstag — Ta bort den gamla sidan utan alias, kedja gammal sökväg till mellanliggande sökväg till aktuell sökväg, behandla alias som dubbla publiceringsrutter, peka flera orelaterade sidor till ett bekvämt mål, eller anta att lokal Hugo-utdata bevisar produktions-HTTP-status.

type och layout

• Syfte — Dessa fält väljer renderingskontraktet. type placerar en sida i en innehållsklass med delade mallar och beteenden; layout begär en specifik mall inom den klassen. Korrekt val säkerställer att sidan får den avsedda navigeringen, innehållsplatsen, tillgångarna och schemabeteendet.
• Typ och format — Gemener registrerade strängar. Denna sida använder type = "academy". Ett layout-värde är ett mallbasnamn som single, utan filtillägg eller sökvägstraversering.
• Obligatoriskt? — type är obligatoriskt när innehållsplatsen inte säkert antyder den avsedda typen eller när spelbokskontraktet kräver det. layout är valfritt och bör utelämnas när typens standardmall är korrekt.
• Gränser — Ett värde för varje fält, valt endast från mallar som underhålls av webbplatsen. Ett nytt värde är en teknisk ändring, inte en redaktionell improvisation.
• Vem eller vad som konsumerar det — Hugos uppslagsordning, mallar, partiell selektion, CSS- och JavaScript-inkludering, schemaadaptrar och valideringsregler.
• Regler — Välj inläggstyp och renderingskontrakt före utkast. Använd layout endast för en genuin, understödd variant; använd det inte för att kompensera för innehåll som tillhör en annan type. Verifiera att en åsidosättning finns och accepterar sidans frontmatter-form.
• Vanliga misstag — Förväxla redaktionell entity med Hugo type, namnge en mallfil som inte finns, kopiera en landningssidstyp på ett akademidokument, förlita sig på mappinferens under en migrering, och införa engångs-layoutnamn som kringgår delade förbättringar.

Upptäckt

description

• Syfte — Beskrivningen hjälper en kvalificerad sökare eller delningsmottagare att avgöra om denna sida uppfyller behovet. Det är förhandsvisningstext, inte en komprimerad introduktion och inte en plats att bevisa relevans genom upprepning.
• Typ och format — En vanlig textmening. Den bör nämna den primära termen naturligt, ange det konkreta värdet och lägga till användbar omfattning, målgrupp, metod eller resultat.
• Obligatoriskt? — Obligatoriskt för varje indexerbar sida i denna spelbok.
• Gränser — 150–160 tecken, inklusive mellanslag. Detta är ett redaktionellt konsistensband, inte en visningsgaranti: sökmotorer kan trunkera det eller skriva om utdraget från brödtext när en annan passage passar frågan bättre.
• Vem eller vad som konsumerar det — Metabeskrivningstaggar, Open Graph- och Twitter-beskrivningsstandarder, listkort, flöden, CMS-förhandsvisningar, sökvalskontroller och ibland schema description.
• Regler — Skriv för ett klick från rätt läsare. Gör meningen tillräckligt specifik för att skilja sidan från ett annat resultat med en liknande titel. Avsnittet Beskrivningsregler nedan ger motivering och avvisningstest.
• Vanliga misstag — Duplicera titeln, lista nyckelord, börja med “Lär dig allt om,” göra ett icke-underbyggt bäst-eller-snabbast-påstående, använda en vag uppmaning till handling, överskrida bandet genom ett osynligt varumärkessuffix, eller anta att den skrivna texten måste visas ordagrant i sökresultaten.

keywords

• Syfte — I detta arkiv registrerar keywords den kompakta sökords- och terminologimängd som används för redaktionell kvalitetssäkring, korpussökning, täckningsanalys och interna verktyg. Det hjälper redaktörer att känna igen språket en sida måste använda korrekt; det är inte ett löfte om att mekaniskt inkludera varje fras.
• Typ och format — En array med naturliga språksträngar, ordnade från den primära termen genom meningsfulla varianter och nära relaterad terminologi.
• Obligatoriskt? — Obligatoriskt enligt denna spelbok, även för sidor vars publika mallar inte renderar värdena.
• Gränser — Sex till åtta distinkta poster. Varje post måste representera en verklig sökordsfras eller nödvändig term, inte en variant på token-nivå.
• Vem eller vad som konsumerar det — Redaktionella validerare, innehållsinventarier, sök- och möjlighetsanalys, intern sökning och migreringsverktyg. Offentliga sökmotorer använder inte detta fält som en rankningssignal bara för att det finns.
• Regler — Håll mängden fokuserad på en sidas omfattning. Slå samman versaler, skiljetecken, singular/plural och triviala ordföljdsdubbletter. Använd fraserna för att kontrollera täckning och terminologi, för att aldrig diktera onaturlig densitet.
• Vanliga misstag — Behandla fältet som den föråldrade meta-keywords-rankningsmekanismen, lägga till dussintals varianter, upprepa titeln som åtta nästan-duplikat, infoga konkurrentnamn som brödtexten inte diskuterar, och låta arrayen ersätta korrekt taxonomi eller promptmål.

targetPrompts

• Syfte — targetPrompts registrerar de fullständiga frågor eller förfrågningar som en person kan ge ett AI-svarssystem och för vilka denna sida bör vara en användbar källa. Promptmål bevarar konversationssammanhang som korta nyckelordsfraser utelämnar.
• Typ och format — En array med fullständiga, naturliga språksträngar, till exempel targetPrompts = [ "How do I rotate an API key without downtime?", "What should I check before revoking an old API key?" ]. Håll formuleringen som en användare skulle fråga, inklusive målgrupp, begränsningar eller önskad jämförelse.
• Obligatoriskt? — Villkorlig för sidor som ingår i promptspårning eller ett AI-synlighetsinnehållsprogram; valfritt när ingen spårad promptuppsättning finns.
• Gränser — Använd en liten, avsiktlig uppsättning, normalt en primär prompt och upp till fyra meningsfulla varianter. En prompt kan vara längre än ett nyckelord eftersom dess kvalificerare bär avsikt.
• Vem eller vad som konsumerar det — Innehållsbeskrivningar, promptspårningsarbetsflöden, sök- och täckningsrevisioner, AI-svarsövervakning och redaktionell utvärdering. Det renderas inte som dold sökkopia.
• Regler — Separera prompts efter faktiskt informationsbehov, inte skiljetecken. Ett nyckelord som “API key rotation” namnger ett ämne; “How can a SaaS team rotate an API key without interrupting integrations?” namnger en målgrupp, uppgift och begränsning. Sidan måste besvara varje lagrad prompt ärligt.
• Vanliga misstag — Kopiera keywords-arrayen till detta fält, fabricera dussintals syntaktiska variationer, registrera prompts bredare än sidan, använda prompts som kroppsrubriker oavsett läsflyt, och påstå prompttäckning när svaret beror på information som sidan inte tillhandahåller.

Förtroende och ursprung

date och updated

• Syfte — date bevarar när sidan först publicerades; updated rapporterar den senaste substantiella ändringen eller slutförda granskningen. Två fält bevarar historik samtidigt som de visar om information som läsare förlitar sig på har ändrats.
• Typ och format — Datumtidssträngar enligt sajtkonventionen, YYYY-MM-DD HH:MM:SS. Håll en tidszonspolicy över hela korpusen så att flöden och jämförelser förblir deterministiska.
• Obligatoriskt? — date är obligatoriskt för publicerade redaktionella sidor. updated är valfritt tills en kvalificerande ändring inträffar, då krävs det om sidan presenterar ett ändrat datum.
• Gränser — Ett värde vardera. updated kan inte föregå date eller ligga i framtiden. En korrigering som görs minuter efter publicering kan fortfarande dokumenteras, men rutinmässiga utkastsrevideringar före publicering skapar inte ett uppdateringsdatum.
• Vem eller vad som konsumerar det — Synliga bylines och färskhetsstämplar, flöden, sajtkartor, schema datePublished och dateModified, färskhetskontroller, sortering och redaktionella köer.
• Regler — Återställ updated för en faktakorrigering, ändrad instruktion, nytt eller borttaget bevis, reviderad omfattning, materiellt ändrad rekommendation eller en dokumenterad granskning av tidskänsliga påståenden. Återställ det aldrig för skiljetecken, formatering, mallarbete eller en tidsstämpel-redigering. Se Datum, författare och granskare för policyrationalen.
• Vanliga misstag — Skriva över originaldatumet under en uppdatering, framtidsdatera en sida för att verka ny, höja datum utan innehållsdifferens, behandla en automatisk driftsättning som en redaktionell uppdatering, och misslyckas med att registrera vad som ändrades i den underhållna uppdateringshistoriken.

author

• Syfte — author kopplar dokumentet till den ansvariga personentiteten som är ansvarig för dess arbete. Länken ger en läsare och en maskin en väg från en påståendebärande sida till underhållen identitet, expertis och annat arbete.
• Typ och format — En stabil författaridentifierare som löses via webbplatsens författarregister till en profil-URL och Person-post. Till exempel är author = "maya-chen" giltigt endast om den identifieraren löses; ett visningsnamn som "Maya Chen, SEO Expert" är inte en ersättning för entitetslänken.
• Obligatoriskt? — Obligatoriskt för substantiella redaktionella sidor. Transaktionssidor kan använda en styrd organisatorisk ägare endast när mallen och policyn stödjer den entitetstypen.
• Gränser — En ansvarig ledare som standard; använd en dokumenterad identifierararray endast när schemat och byline-mallarna stödjer genuint medförfattarskap.
• Vem eller vad som konsumerar det — Synliga bylines, författarprofillänkar, Artikel-schema, flöden, redaktionella ägarskapsrapporter, granskningsarbetsflöden och entitetsgrafer.
• Regler — Lös identifieraren före publicering. Profilen måste identifiera samma person som visas i bylinen och förbli underhållen. Kreditera personen som är ansvarig för innehållet, inte personen som bara laddade upp det.
• Vanliga misstag — Ange en olänkad namnsträng, använda “Admin” eller ett påhittat redaktionellt team, tilldela en framstående chef som inte skrev arbetet, låta en identifierare lösa till ingen profil, och ändra författarskap för att antyda expertis som inte var inblandad.

reviewedBy, reviewedAt och reviewScope

• Syfte — Dessa fält registrerar en oberoende granskning skild från författarskap. reviewedBy identifierar granskarenheten; reviewedAt anger när granskningen slutfördes; reviewScope säger vad granskaren kontrollerade, så att märket inte innebär godkännande bortom bevisen.
• Typ och format — reviewedBy är en stabil identifierare som löses till en underhållen personprofil. reviewedAt använder webbplatsens tidsstämpelformat. reviewScope är ett koncist vanlig textuttalande som “Credential rotation steps and security cautions.”
• Obligatoriskt? — Villkorligt när lag, riskpolicy, ämneskänslighet eller inläggstypspecifikationen kräver oberoende granskning. När reviewedBy är närvarande krävs granskningsdatum och omfattning som granskningspostsdata, även om en viss mall lagrar dem i en ansluten redaktionell post snarare än offentlig frontmatter.
• Gränser — Namnge endast faktiska granskare. Omfattning bör vara specifik nog för att avslöja undantag utan att bli en granskningsrapport. En granskare måste ha relevant kompetens och får inte bara duplicera författarrollen.
• Vem eller vad som konsumerar det — Granskad-av-komponenter, personentitetssammanfogningar, styrningsrevisioner, högriskpubliceringsgrindar, strukturerat ursprung och uppdateringsloggar.
• Regler — Slutför granskning efter att innehållet är stabilt, fånga upp resultat och lösning i redaktionell historik, och granska om när senare ändringar påverkar den granskade omfattningen. Oberoende innebär att granskaren testar arbetet snarare än att godkänna sitt eget utkast.
• Vanliga misstag — Behandla kopieringsredigering som expertgranskning, visa en granskare utan datum eller omfattning, namnge någon som aldrig såg slutversionen, lämna märket efter en materiell ogranskad omskrivning, och antyda juridiskt, medicinskt eller tekniskt godkännande utanför den angivna omfattningen.

Media och socialt

image och imageAlt

• Syfte — image väljer den representativa hjälte- och sociala tillgången; imageAlt tillhandahåller det funktionella textalternativet när den tillgången renderas som meningsfullt sidinnehåll. Att hålla paret tillsammans förhindrar att upptäcktsbilder blir en tillgänglighetsförsummelse.
• Typ och format — image är en lösbar sajtsökväg eller godkänd absolut URL. imageAlt är vanlig text som beskriver bildens användbara information i sitt sidkontext, inte dess filnamn eller målnyckelord.
• Obligatoriskt? — Villkorligt efter inläggstyp och mall. Om sidan kräver en hjältebild eller dedikerad social bild är image obligatoriskt. imageAlt är obligatoriskt när den bilden renderas informativt; en rent dekorativ rendering måste använda ett tomt alt-attribut i mallen, inte påhittad beskrivande text.
• Gränser — Använd en representativ tillgång. För social kompatibilitet, tillhandahåll en 1200 × 630 pixel källa i det förväntade beskärningsförhållandet, håll viktigt innehåll borta från kanterna och håll imageAlt koncis—normalt 5–160 tecken. Filen måste finnas innan den refereras.
• Vem eller vad som konsumerar det — Hjältekomponenter, listkort, Open Graph- och Twitter-taggar, schemabildfält, flöden, bildpipelines, skärmläsare när synliga och tillgångskontroll.
• Regler — Välj en bild som fortfarande kommunicerar efter en centerbeskärning och i miniatyrstorlek. Beskriv dess funktion i kontext: “API key settings with Rotate key highlighted” är användbart; “API key” är det inte. Lägg inte väsentliga påståenden endast inuti pixlar.
• Vanliga misstag — Referera en planerad tillgång som inte finns, använda en logotyp som varje artikelbild, bädda in liten text som blir oläslig i delningar, skriva “image of,” stoppa in nyckelord i alt-text, och anta att social alt-text och synlig bild-alt-beteende är identiska över plattformar.

Open Graph- och Twitter-kortfält

• Syfte — Social metadata styr hur en URL sammanfattas när den delas. En konsekvent titel, beskrivning, URL, typ och bild hjälper mottagare att känna igen sidan innan de klickar och minskar risken att en plattform väljer en irrelevant tillgång.
• Typ och format — I detta arkiv härleder mallar og:title och twitter:title från title, beskrivningar från description, URL:er från permalänken, og:type från layoutkontextet och båda bildtaggarna från image med en sajtsreserv. twitter:card skickas som summary_large_image. Dessa är genererade taggar, inte duplicerade frontmatter-fält som standard.
• Obligatoriskt? — Utmataggetagarna är obligatoriska på publika sidor. Separata åsidosättanden är valfria och bör införas endast genom ett dokumenterat mallkontrakt; icke-understödda ad hoc-fält som ogTitle gör ingenting.
• Gränser — En sammanhängande förhandsvisning per sida och en 1200 × 630 representativ bild. Håll härledd formulering inom titel- och beskrivningsbanden, testa sedan den faktiska beskärningen och överlagringsbeteendet på större delningsytor.
• Vem eller vad som konsumerar det — Sociala nätverk, meddelandeklienter, länkexpandrar, webbläsartillägg, samarbetsverktyg och förhandsvisningsfelsökare.
• Regler — Föredra härledning så att sök- och sociala påståenden förblir i linje. Åsidosätt endast när det sociala sammanhanget verkligen behöver en annan inramning och mallen stödjer det. En felaktig bild kostar igenkänning och förtroende: mottagaren kan se ett föråldrat gränssnitt, en annan produkt, ett missvisande påstående eller en beskärning som döljer ämnet.
• Vanliga misstag — Skriva fält som ingen mall läser, tillåta en global reserv att maskera en saknad obligatorisk hjältebild, använda ett porträtt eller en pytteliten bild för ett brett kort, ändra social kopia för att göra ett starkare löfte än sidan, och validera endast HTML-källan snarare än en hämtad förhandsvisning.

Klassificering

taxonomy, categories och tags

• Syfte — Klassificering kopplar en sida till styrda ämnes-, format-, målgrupps- eller produktsamlingar. Det driver användbara arkiv och filter endast när varje vokabulär har en deklarerad betydelse; annars blir etiketter en okontrollerad synonymhög.
• Typ och format — Arrayer med registrerade gemener slugs. Använd taxonomy för arkivets kontrollerade ämnesvokabulär. Använd categories endast för en liten ömsesidigt begriplig redaktionell hierarki och tags endast för en styrd genomgående vokabulär när dessa taxonomier är konfigurerade.
• Obligatoriskt? — Villkorligt baserat på inläggstyp och arkivdesign. Ämnesbärande redaktionella sidor kräver normalt en eller flera kontrollerade termer; verktygssidor kan kräva inga. Ett fält får inte fyllas i bara för att ett CMS exponerar det.
• Gränser — För allmän taxonomi, ett till fem värden per kontrollerad vokabulär. Varje term behöver en definition, ägare och sammanslagningsregel. Skapa ett indexerbart arkiv endast när termen representerar varaktig läsarefterfrågan och arkivet kan erbjuda en unik introduktion, sammanhängande inventering, interna länkar och löpande underhåll.
• Vem eller vad som konsumerar det — Arkivsidor, brödsmulor, filter, relaterat-innehåll-system, facetterad navigering, innehållsrevisioner och analyssegmentering.
• Regler — Välj den smalaste registrerade termen som korrekt grupperar sidan. Håll singular/plural, förkortningar och stavningsvarianter mappade till ett kanoniskt värde. Bestäm om arkiv är indexerbara på vokabulärnivå, inte tagg för tagg efter oavsiktlig skapelse.
• Vanliga misstag — Använda seo, SEO, search-optimization, och search engine optimization som separata värden, lägga till engångstaggar för att beskriva varje substantiv, förväxla en företagstyp med ett ämne, generera tunna indexerbara arkiv, och ta bort termer utan att migrera deras medlemmar.

Spelbokssammanfogningsnycklar

• Syfte — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage och amicitedFeatures är typade sammanfogningsnycklar. De låter en källsida visas i genererade bibliotek och matriser utan att redaktörer kopierar kort för hand. Denna sida är det arbetade exemplet: dess pelare identifierar ett element, dess familj grupperar metadatavägledning, och dess postTypes-array deklarerar specifikationerna som konsumerar det.
• Typ och format — Singularnycklar använder registrerade gemener slugs: playbookPillar och playbookFamily är strängar, playbookWave är ett heltal, och journeyStage är en kontrollerad sträng. Relationsnycklar—postTypes, elements, businessTypes och amicitedFeatures—är arrayer med registrerade slugs från sina respektive register.
• Obligatoriskt? — playbookPillar och playbookWave är obligatoriska på spelboksposter. playbookFamily är obligatoriskt där pelaren har styrda familjer. Array-sammanfogningarna och journeyStage är villkorliga: fyll endast i relationer som sidkontraktet faktiskt stödjer.
• Gränser — En pelare, en familj inom den pelaren, en våg och ett resesteg om inte modellen uttryckligen tillåter flera steg. Arrayer innehåller unika registrerade nycklar, inte visningsetiketter, prosa eller URL:er.
• Vem eller vad som konsumerar det — Spelbokens navlistningar, tvärpelarmatriser, filter, relationskort, fullständighetsrapporter, release-vy-vyer och interna verktyg som hittar relevanta AmICited-funktioner.
• Regler — Validera varje värde mot det kanoniska registret. Riktning spelar roll: en inläggstypsida listar sina obligatoriska elements; en elementsida listar tillämpliga postTypes; en företagstypsida listar användbara inläggstyper. Behandla etiketter som presentation och nycklar som varaktig data. Byt namn på en nyckel endast genom en migrering som uppdaterar varje sida av sammanfogningen.
• Vanliga misstag — Hitta på nära-synonymer, lagra titlar istället för slugs, blanda heltal och strängar för vågor, lägga till en relation för att två sidor nämner varandra, tillåta ömsesidiga arrayer att motsäga varandra, och skapa handunderhållen listningsmarkering som avviker från metadata.

Härledda och strukturella fält

schemaType

• Syfte — schemaType väljer den mest specifika understödda strukturerade datamappningen som korrekt beskriver den synliga sidan. Den talar om för schema-adaptern vilket vokabulärkontrakt som ska tillämpas; den förvandlar inte sidan till den saken genom deklaration enbart.
• Typ och format — Ett registrerat Schema.org-typenamn som Article, valt från de typer som sajtadaptern stödjer. Versaler och stavning måste matcha registret.
• Obligatoriskt? — Villkorligt. Ställ in det där flera schemamappningar är giltiga för samma Hugo-typ eller där inläggstypskontraktet kräver en explicit typ. Annars låt mallen härleda sin säkra standard.
• Gränser — En primär sidtyp, med kapslade entiteter skapade av adaptern från faktiskt innehåll. Den valda typen måste uppfylla alla obligatoriska egenskaper och matcha vad en läsare kan se.
• Vem eller vad som konsumerar det — JSON-LD-adaptrar, rich-resultat-validering, innehållskontroll och schemainventarierapporter.
• Regler — Välj utifrån sidfunktion och synliga bevis, inte från den sökfunktion en redaktör vill ha. En instruktionssida utan en komplett synlig procedur kan inte förtjäna noggrannhet genom att ställa in en instruktionstyp. Håll schema-URL:er, datum, personer och bilder synkroniserade med sina källfält.
• Vanliga misstag — Välja en mer specifik typ utan dess obligatoriska innehåll, skicka flera motstridiga primära typer, kopiera ett schemavärde från en orelaterad mall, anta att giltig syntax garanterar berättigande, och lägga påståenden i JSON-LD som läsare inte kan inspektera.

Läsningstid

• Syfte — Läsningstid ger en läsare en grov uppskattning av ansträngning. Den härleds från den slutliga renderbara kroppen så att uppskattningen ändras när den faktiska läsmängden ändras.
• Typ och format — Ett beräknat heltalsantal minuter producerat från innehållspipelinens ordräkningspolicy. Kodblock, tabeller, bildtexter och inbäddad media bör följa en dokumenterad räkningsregel.
• Obligatoriskt? — Visningen är valfri per mall. Ett författarskrivet frontmatter-fält är inte tillåtet som sanningskälla.
• Gränser — Avrunda konsekvent och tillämpa en förnuftig minimivisning som en minut. Det exakta antagandet om ord per minut spelar mindre roll än att använda samma metod på hela webbplatsen och märka resultatet som en uppskattning.
• Vem eller vad som konsumerar det — Sidhuvuden, kort, flöden, analyssegmentering och läsare som bestämmer om de ska påbörja en lång guide.
• Regler — Beräkna efter att shortcodes och exkluderade regioner har hanterats enligt sajtpolicy. Beräkna om vid varje bygge. Om video eller en interaktiv uppgift väsentligen ändrar slutförandetid, märk det separat istället för att korrumpera läsningstiden.
• Vanliga misstag — Skriva readingTime = 8, glömma att uppdatera det efter en omskrivning, presentera falsk precision, räkna navigering och standardtext, och behandla en utförandetung instruktion som åtta minuters läsning plus ingen uppgiftstid.

[[faq]]

• Syfte — [[faq]] lagrar synliga fråge-och-svar-par en gång så att sidan och eventuell berättigad FAQ-strukturerad data inte kan glida isär.
• Typ och format — En TOML-tabellarray; varje objekt innehåller en vanlig text question och en självständig answer-sträng.
• Obligatoriskt? — Villkorligt när genuina uppföljningsfrågor återstår efter huvudsidan. Det är aldrig obligatoriskt bara för att fylla en mall eller eftersträva en sökfunktion.
• Gränser — Normalt fyra till åtta användbara objekt på spelbokssidor. Varje fråga förekommer en gång, och varje svar måste vara komplett utan att förlita sig på accordion-ordning.
• Vem eller vad som konsumerar det — Synlig FAQ-rendering, FAQPage-schema där berättigat, sidnavigering, innehållskontroll och svarsextrahering.
• Regler — Detta är ett korsreferenskontrakt: följ Varför FAQ bor i frontmatter och den senare FAQ-vägledningen snarare än att underhålla separata synliga och schemakopior. Lagra endast frågor som varje läsare kan komma åt på sidan.
• Vanliga misstag — Dolda schema-endast svar, duplicera rubriker förklädda som frågor, reklamsvar, icke-underbyggda påståenden, inaktuell JSON-LD och behandla sökresultatberättigande som garanterat.

[[lnks]]

• Syfte — [[lnks]] registrerar varje styrd intern länk som används i brödtexten, och parar dess synliga ankare med ett mål och underhållen beskrivning. Posten gör länkar inspekterbara utan att skrapa renderad HTML och stödjer migrering och kvalitetssäkring.
• Typ och format — En TOML-tabellarray med text, path och title. text är det exakta synliga ankaret, path är en sajtrelativ URL med inledande och avslutande snedstreck, och title är mål-sidans beskrivning.
• Obligatoriskt? — Obligatoriskt för varje intern kroppslänk som styrs av denna innehållskonvention. Djupa applänkar och externa källor följer sina egna poster och är inte förklädda som [[lnks]]-poster.
• Gränser — En post per kroppslänk-förekomst när samma ankare kan peka på olika destinationer; annars bör exakta dubblettposter tas bort. Destinationen måste finnas eller vara i det godkända kanoniska slug-registret för den samordnade releasen.
• Vem eller vad som konsumerar det — Internlänksvalidering, innehållsmigrering, relationsanalys, länktitelgenerering där stödd och redaktionell granskning.
• Regler — Matcha text till kroppsankaret ordagrant, inklusive versaler och skiljetecken inuti länken. Använd den kanoniska sajtrelativa sökvägen. Skriv title som en korrekt destinationsbeskrivning, inte som instruktioner för den aktuella sidan. Uppdatera posten och kroppen tillsammans.
• Vanliga misstag — Använda ett längre text-värde än det faktiska ankaret, hitta på en oregistrerad slug, utelämna ett avslutande snedstreck, registrera en omdirigerande gammal sökväg, beskriva källan istället för destinationen, och lämna kvar en post efter att dess kroppslänk har tagits bort.

Obligatoriskt versus valfritt efter inläggstyp

Matrisen tillämpar kontrakten ovan på de tolv inläggstyper som för närvarande deklareras av detta element. R betyder obligatoriskt, C betyder villkorligt enligt fältreglerna, D betyder obligatorisk utdata som kan härledas säkert, och O betyder valfritt. “Identitet” inkluderar entity, id, title, type och den stabila rutten. “Upptäckt” inkluderar description och keywords; målpromptar förblir villkorliga för varje rad. aliases är alltid villkorligt vid en flytt, medan författarskriven läsningstid aldrig är obligatorisk.

“Villkorlig granskare” är inte tillstånd att hoppa över granskning där noggrannhet eller kommersiell risk kräver det. Bästa-X- och alternativsidor kräver oberoende granskning eftersom deras rekommendationer väsentligen kan påverka ett beslut och ofta ändras när produkter, priser och berättigande ändras. För andra rader aktiverar riskpolicyn, inte en redaktörs tillgängliga tid, kravet. På samma sätt är en kanonisk märkt D fortfarande obligatorisk i renderad HTML; endast frontmatter-indata får utelämnas när mallen kan generera korrekt självreferens.

Frontmatter-validering

Validering bör avvisa deterministiska defekter automatiskt och reservera bedömning för frågor som beror på innebörd, bevis eller professionell kompetens. Uppdelningen förhindrar två motsatta misslyckanden: att be granskare fånga syntax som en parser kan fånga perfekt, och att låtsas att en teckenräkningsregel kan avgöra om kopian är ärlig.

Kör deterministiska kontroller före redaktionell granskning så att granskaren ser en sammanhängande post. Granska sedan den renderade HTML-koden, inte bara frontmatter: ett giltigt källvärde är fortfarande en produktionsdefekt om den valda mallen ignorerar det, mappar det till fel tagg, döljer obligatoriskt ursprung eller genererar en kanonisk som inte överensstämmer med den publika rutten. Publicering är komplett endast när källa, rendering och mål-beteende överensstämmer.

Fältet entity

entity svarar på “vilken exakt inläggstyp är detta dokument en instans av?” Den svarar inte på “vilket ämne diskuterar denna sida?” Den distinktionen spelar roll eftersom två dokument kan behandla samma ämne samtidigt som de gör olika jobb. En glossarpost definierar “diagnos”; en bloggartikel kan rapportera en förändring i diagnostisk vägledning. Om båda använder entity = "diagnosis" kan nedströmsystem inte pålitligt välja rätt mall, valideringsregler, analysgrupp eller migrering.

Använd gruppprefixet plus inläggstypens slug för varianter inom en familj: guide-how-to, guide-ultimate, comparison-a-vs-b och comparison-alternatives-to-x. Använd bara namnet för en fristående typ: product-page eller case-study. Registrera identifieraren en gång, håll den stabil och ändra den aldrig för att ämnet eller målsökfrågan ändras. Lägg ämneskoncept i taxonomy och sökordsspråk i keywords.

Titel, H1 och SEO-titel

Dessa värden kan skilja sig åt beroende på sammanhang men måste beskriva samma sida. title är den varaktiga standarden. h1 är den synliga rubriken och kan vara mer naturlig i sammanhanget. seoTitle tjänar webbläsare och sökresultat och kan lägga till en koncis differentierare, legitimt år eller varumärkessuffix.

Till exempel, title = "API Key Rotation", h1 = "How to Rotate an API Key Without Downtime" och seoTitle = "API Key Rotation: Safe Step-by-Step Guide" är i linje med en uppgift. “Free Security Tool” som SEO-titel skulle vara bedrägligt eftersom det ändrar löftet. Skapa inte skillnader bara för att infoga fler nyckelord.

Beskrivningsregler

Beskrivningen finns för att hjälpa en kvalificerad läsare att bestämma sig för att klicka. Håll den inom 150–160 tecken, inkludera den primära termen naturligt, ange sidans konkreta fördel och lägg till en meningsfull kvalificerare som målgrupp, omfattning eller resultat. Skriv en flytande mening, inte en nyckelordslista.

Termen bekräftar relevans; upprepning tillför inget värde. Duplicera inte titeln, använd “Lär dig allt om,” gör inte icke-underbyggda superlativ, eller avsluta mitt i en tanke. Söksystem kan fortfarande välja en annan synlig text för en fråga.

Datum, författare och granskare

date bevarar första publiceringstidsstämpeln. updated registrerar den senaste substantiella ändringen: en faktakorrigering, nya bevis, ändrade instruktioner, reviderad omfattning, ändrad rekommendation eller fullständig granskning som bekräftar tidskänsliga påståenden. Registrera vad som ändrades i den redaktionella historiken när policyn kräver det.

Att fixa skiljetecken, ändra en knappstil, bygga om en mall eller bara röra tidsstämpeln återställer inte updated. Att flytta fram ett datum utan arbete bakom det är en policyöverträdelse eftersom det säger till läsare och maskiner att innehållet uppdaterades när det inte var det. Det är felaktig framställning, inte en tillväxttaktik.

Författar- och granskarfält bär ansvariga identiteter in i bylines och strukturerad data. Författaren är ansvarig för arbetet. Använd reviewedBy endast när kvalificerad granskning har ägt rum, och länka båda identifierarna till underhållna profiler. Sidan om förtroendegrunder förklarar hur författarskap, datum, bevis och entitetstydlighet stödjer förtroende utan att garantera rankningar.

Varför FAQ bor i frontmatter

En FAQ är synligt innehåll och en strukturerad samling. Att lagra den en gång i [[faq]] låter mallen rendera accordionen och identisk FAQPage JSON-LD, vilket förhindrar inaktuellt dolt schema.

Inkludera genuina uppföljningsfrågor synliga för varje läsare. Duplicera inte rubriker, göm inte reklam i svar eller markera icke-visade frågor. Giltig markering garanterar inte en sökfunktion.

Syntax och kodexempel

Tvärplattformsavtalet mappar fält, inte en synlig komponent. Följande portabla envelopp är endast giltig i en utbytesfil vars importör känner igen metadatadirektiv:

:::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åste normaliseras till inbyggd sidmetadata under import. Den är inte giltig i brödtexten av en produktionsartikel. I Hugo är den korrekta mappningen TOML mellan +++-avgränsare vid byte ett, som visas i det levande exemplaret. Det finns medvetet ingen {{< frontmatter >}}-shortcode: en shortcode skulle köras för sent och i fel dokumentregion.

I WordPress, mappa samma kanoniska fält till registrerade inläggsfält och inläggsmeta, till exempel post_title, post_excerpt, post_name, _amicited_entity, _amicited_author och _amicited_reviewed_by. En kommentar som <!-- wp:amicited/frontmatter --> eller en [frontmatter]-shortcode är ogiltig eftersom den skapar ett kroppsblock snarare än dokumentmetadata. Importörer och redaktörer kan visa en metadatapanel, men de lagrade värdena måste förbli kopplade till inläggsposten.

Exempel

Bra: en sammanhängande, ansvarig 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/"

Detta identifierar en instruktionsvariant, bevarar historik, namnger ansvariga personer och separerar ämne från sididentitet. Den uppdaterade tidsstämpeln stöds av en dokumenterad instruktionsändring och granskning.

Dåligt: titeln upprepad som beskrivning

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

Beskrivningen tillför ingen nytta, omfattning eller anledning att klicka. Den slösar också bort förhandsvisningsutrymmet som skulle kunna skilja denna sida från varje annat resultat med samma titel.

Dåligt: samma entitet återanvänd över två inläggstyper

# glossarpost
entity = "diagnosis"

# redaktionell guide
entity = "diagnosis"

Det delade ämnet har ersatt inläggstypens identitet. Använd registrerade värden som glossary-term och guide-ultimate, tilldela sedan “diagnosis” genom taxonomi eller nyckelord.

Dåligt: ett uppdateringsdatum utan innehållsdifferens

date = "2026-01-15 09:00:00"
updated = "2026-08-27 10:00:00" # endast datumet ändrades

Ingen substantiell redigering eller granskning stödjer färskhetspåståendet. Håll updated oförändrad eller utelämnad tills en verklig ändring finns och kan inspekteras i redaktionell historik.

Schema-markering och tillgänglighet

Metadata levererar värden; mallen förblir ansvarig för semantisk HTML, fokus, kontrast, länksyfte och alternativtext.

Skrivregler

• Håll identifierare stabila, gemener och maskinsäkra. Återanvänd aldrig ett id eller ändra tyst entity efter publicering.
• Använd vanlig text i titelliknande fält. HTML, Markdown-länkar, emoji-dekoration och påtvingade radbrytningar hör inte hemma i metadatasträngar.
• Håll beskrivningen på 150–160 tecken och nyckelordsarrayer på sex till åtta distinkta fraser för denna spelbok.
• Använd verkliga registrerade personer för författar- och granskarfält. Skapa aldrig en ceremoniell granskare eller generisk “Redaktionellt team”-identitet om inte det är en underhållen ansvarig enhet.
• Använd en kontrollerad taxonomi. Stavningsvarianter och singular/plural-duplikat skapar fragmenterade arkiv.
• Referera endast bilder som finns och har publiceringsrättigheter. imageAlt beskriver bildens informativa innehåll, inte dess SEO-mål.
• Håll FAQ-svar direkta och självständiga. Påståenden kräver fortfarande samma bevis och avslöjande som prosa på andra ställen på sidan.
• Placera aldrig hemligheter, privata anteckningar, access-tokens, embargoinstruktioner, personuppgifter eller ogranskade juridiska påståenden i publicerbar frontmatter.

Vilka inläggstyper använder frontmatter och var

Varje inläggstyp använder frontmatter vid byte ett. Det erforderliga djupet ändras med risk, avsikt och schema snarare än med visuell design.

Checklista för kvalitetssäkring

• Börjar filen med +++, innehåller den giltig TOML och stänger posten före brödtexten?
• Är entity en registrerad exakt inläggstypidentifierare snarare än ämnet, kampanjen eller sajtnamnet?
• Är id unik och stabil, och matchar url det kanoniska slug-registret?
• Beskriver title, valfri h1 och valfri seoTitle samma sida utan bedrägliga omfångsändringar?
• Är beskrivningen 150–160 tecken, innehåller den den primära termen naturligt och erbjuder den en konkret anledning att klicka?
• Finns varje refererad bild, och är imageAlt korrekt för bilden som renderas?
• Är publiceringsdatumet bevarat, och stöds varje updated-värde av en substantiell differens eller dokumenterad granskning?
• Löser författar- och granskaridentifierare till verkliga underhållna profiler, och granskade den namngivna granskaren faktiskt arbetet?
• Är nyckelord begränsade till sex till åtta användbara fraser och taxonomivärden hämtade från kontrollerade vokabulärer?
• Använder den kanoniska HTTPS, löser den till den föredragna sidan och överensstämmer den med sajtkartan och interna länkar?
• Innehåller varje [[faq]]-objekt en användbar fråga och ett självständigt svar som renderas synligt med identisk formulering?
• Matchar genererad JSON-LD synligt innehåll, använder stabila identifierare och passerar syntaxvalidering utan att göra anspråk på icke-understödda typer?
• Är hemligheter, privata redaktionella anteckningar, icke-underbyggda påståenden och kropp-endast-avslöjanden frånvarande från posten?

FAQ

Är frontmatter synligt på den publicerade sidan?

Källposten är dold, men mallar kan rendera titeln, personer, datum och FAQ. Andra fält matar förhandsvisningar, kanoniska taggar, flöden, sajtkartor, schema och interna system.

Ska entitetsfältet innehålla ämnet eller inläggstypen?

Det identifierar den exakta inläggstypen. Delade ämnen hör hemma i taxonomi och nyckelord, inte i stället för dokumentidentitet.

Kan titeln, H1 och SEO-titeln vara olika?

Ja. H1 kan läsas mer naturligt och SEO-titeln kan lägga till en differentierare, men alla versioner måste göra samma löfte.

När ska det uppdaterade datumet ändras?

Ändra det efter en substantiell faktagranskning eller redigering. Ändra det inte för skiljetecken, stil, mallarbete eller en datum-endast-uppdatering.

Varför lagras FAQ-frågor i frontmatter?

Den strukturerade arrayen låter en källa rendera både den synliga FAQ:n och matchande FAQPage JSON-LD. Det förhindrar att schema glider iväg från vad läsare kan inspektera.