Frontmatter de Conținut: Câmpuri și Metadate SEO

Frontmatter-ul este elementul de pagină pe care cititorii nu îl văd niciodată ca un bloc și de care depinde fiecare sistem de publicare. Acesta oferă unui document o identitate, un contract de redare, o previzualizare de căutare, o evidență a responsabilității, date și intrări pentru schemă. Un frontmatter defect poate selecta șablonul greșit, poate crea conflicte canonice, poate pierde autorul sau poate emite markup care contrazice pagina.

Specimenul live este o înregistrare la nivel de document, afișată ca și cod, deoarece frontmatter-ul nu trebuie să devină o cutie decorativă în corpul paginii.

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

De ce există frontmatter-ul

Pentru un cititor, metadatele reduc incertitudinea. Un titlu precis stabilește domeniul, o descriere utilă câștigă clicul, identitățile fac afirmațiile responsabile, iar datele dezvăluie dacă informațiile s-ar putea fi învechit. Aceste semnale nu pot compensa un conținut slab, dar absența lor îl obligă pe cititor să ghicească.

Pentru mașini, frontmatter-ul înlocuiește inferența cu valori denumite. Șabloanele mapează câmpurile către titluri de browser, linkuri canonice, înregistrări de persoane, date, feeduri, indici și JSON-LD fără a extrage din proză. Aceasta este extractibilitatea automată: faptele importante au o locație și un tip consistente.

Urmați regulile de scriere a elementelor: metadatele aparțin nivelului de document; elementele vizibile pentru cititor aparțin corpului paginii. O linie de autor poate fi redată din frontmatter, dar identificatorul său autoritar rămâne acolo.

Când să îl utilizați — și când nu

Fiecare pagină indexabilă are nevoie de o înregistrare de frontmatter pentru identitate, redare și rutare. Schițele au nevoie de el atunci când intră în producție, astfel încât validarea să poată eșua devreme.

Nu ascundeți fapte ale articolului în frontmatter. Limitările produsului, avertismentele de siguranță, dezvăluirile de afiliere, metodele și sursele trebuie să rămână vizibile acolo unde cititorii le pot evalua. O valoare structurată nu înlocuiește niciodată o dezvăluire.

Aproape-omisiunile provoacă cele mai mari daune:

• Etichetele de navigare, textul campaniilor și subtitrările sociale care variază independent sunt setări de canal; nu supraîncărcați title.
• Faptele organizației partajate pe întreg site-ul aparțin înregistrării organizației, nu copiate în fiecare pagină unde se vor deplasa.
• O secțiune de întrebări și răspunsuri aparține în [[faq]] doar atunci când același conținut este redat vizibil. FAQ-ul ascuns, doar pentru schemă, este invalid.
• O etichetă de subiect aparține în taxonomy; nu trebuie să înlocuiască entity-ul care identifică tipul de postare al documentului.
• O redirecționare aparține în configurația de rutare sau într-un câmp de aliasuri aprobat. canonical identifică versiunea preferată; nu redirecționează vizitatorii.

Unde să îl plasați

Frontmatter-ul începe la primul octet cu +++ și se termină la delimitatorul corespunzător înaintea corpului. Niciun titlu, comentariu, notă, shortcode sau bloc de metadate nu poate preceda. Câmpurile și array-urile TOML aparțin în acea singură înregistrare.

Corpul începe după delimitatorul de închidere. Frontmatter-ul nu poate sta între H1 și introducere, lângă o captură de ecran, în interiorul unei componente sau la sfârșit. Un marcaj de ordine a octeților sau un comentariu rătăcit poate împiedica recunoașterea. Cheile duplicate, delimitatorii YAML și blocurile secundare sunt invalide.

Anatomie

Legenda redată rămâne în pagină pentru a rămâne lizibilă și traductibilă independent de imagine:

1. Granță: delimitatorii de deschidere și închidere +++ definesc singura regiune de metadate.
2. Identitate: entity, id, type și url spun sistemelor ce este documentul și unde se află.
3. Descoperire: title, seoTitle, description, image, imageAlt și keywords sprijină previzualizările și regăsirea.
4. Proveniență: date, updated, author și reviewedBy indică cine este responsabil și când a fost modificată valid lucrarea.
5. Clasificare: taxonomy conectează pagina la colecții de subiecte controlate fără a redefini identitatea sa.
6. Controlul duplicării: canonical denumește URL-ul public preferat atunci când versiuni echivalente pot fi accesate din altă parte.
7. Colecții structurate: fiecare [[faq]] creează o înregistrare tipizată de întrebare și răspuns pentru redare vizibilă și schemă.

Exemple de design

Frontmatter-ul are variante de contract de date, nu stiluri vizuale. Capturile de ecran asociază înregistrările sursă cu previzualizarea sau linia de autor rezultată.

Parametri

Acestea sunt limite editoriale chiar și atunci când un analizor acceptă mai mult. „Condiționat” înseamnă obligatoriu atunci când condiția specificată este adevărată.

Referință per câmp

Această referință definește contractul de publicare pentru fiecare câmp. „Obligatoriu” înseamnă că validarea ar trebui să oprească publicarea atunci când câmpul sau derivarea sa validă este absentă. „Condiționat” înseamnă că cerința este activată de un fapt declarat, cum ar fi redarea unei imagini sau o revizuire independentă care a avut loc. O valoare implicită este sigură doar atunci când produce același sens pe care un editor l-ar fi ales în mod deliberat.

Identitate și rutare

title, h1 și seoTitle

• Scop — title oferă documentului numele său editorial durabil. h1 controlează titlul principal din pagină atunci când contextul layout-ului necesită o formulare diferită. seoTitle controlează titlul de browser/căutare atunci când valoarea implicită are nevoie de un calificativ concis sau de un tratament de marcă. Separarea lor împiedică o etichetă de navigare, un titlu de pagină și o previzualizare de căutare să fie forțate într-un singur șir stângaci.
• Tip și format — Fiecare este un șir de text simplu. title este valoarea sursă; suprascrierile absente trebuie să revină la acesta. HTML, Markdown, decorațiuni cu emoji și marcaje de trunchiere manuală nu sunt valori valide.
• Obligatoriu? — title este obligatoriu pe fiecare pagină publică. h1 și seoTitle sunt opționale și ar trebui omise atunci când title funcționează în toate cele trei contexte.
• Limite — Utilizați 30–70 caractere pentru title, 20–80 pentru h1 și 30–60 pentru seoTitle ca benzi editoriale, nu ca promisiuni că o interfață de căutare va afișa fiecare caracter. Trebuie să existe un H1 redat.
• Cine sau ce îl consumă — Șabloane de pagină, titluri de browser, adaptoare de căutare și rețele sociale, carduri de navigare, feeduri, headline schema, structuri de accesibilitate și listări editoriale.
• Reguli — Toate versiunile trebuie să identifice același subiect, intenție și scop. O diferență legitimă rezolvă o constrângere de canal: de exemplu, H1 poate spune „Cum să rotești o cheie API fără timp de nefuncționare”, în timp ce titlul SEO mai scurt spune „Rotație Cheie API: Ghid Sigur Pas cu Pas”. Secțiunea ulterioară Titlu, H1 și titlu SEO explică testul editorial.
• Greșeli comune — Repetarea unui cuvânt cheie în toate cele trei variante, adăugarea unui sufix de marcă în H1, schimbarea promisiunii pentru a urmări clicuri, încorporarea anului curent când pagina nu este întreținută anual sau crearea a trei valori doar pentru că există trei câmpuri.

slug și url

• Scop — Slug-ul este segmentul final al căii; url este ruta publică relativă la site care îl conține. Împreună oferă paginii o adresă stabilă pentru cititori, crawler-e, linkuri, raportări și migrări. Stabilitatea contează deoarece fiecare link câștigat și fiecare marcaj salvat devine dependent de acea adresă.
• Tip și format — Utilizați un șir de cale cu litere mici, separate prin cratimă, cum ar fi /academy/rotate-an-api-key/. Acest depozit înregistrează ruta completă în url; un CMS care are un câmp slug separat trebuie să derive același segment final.
• Obligatoriu? — O rută unică este obligatorie pentru fiecare pagină publică. Poate fi generată doar acolo unde o secțiune are o regulă deterministă aprobată și verificări de coliziuni; paginile playbook utilizează valorile lor url înregistrate.
• Limite — Preferați un slug scurt și lizibil care păstrează subiectul distinctiv, de obicei trei până la opt cuvinte utile. Eliminați punctuația și modificatorii goi. Eliminați cuvinte de oprire precum „the” sau „a” doar atunci când rezultatul rămâne natural și neambiguu; nu există o limită arbitrară de caractere care să justifice deteriorarea sensului.
• Cine sau ce îl consumă — Rutare Hugo, linkuri interne, breadcrumb-uri, generare canonică, sitemapuri, feeduri, analitică, redirecționări și referințe externe.
• Reguli — Tratați un slug publicat ca un angajament permanent. Decideți-l din subiectul durabil, nu dintr-un titlu de campanie sau un an tranzitoriu. Când titlul se schimbă, dar subiectul și intenția nu, păstrați slug-ul vechi. Dacă pagina se mută cu adevărat, creați noua rută, păstrați ruta veche în aliases, actualizați linkurile interne și testați destinația redirecționării.
• Greșeli comune — Regenerarea slug-ului de fiecare dată când titlul se schimbă, înghesuirea sinonimelor în cale, păstrarea datelor care fac conținutul peren să pară învechit, utilizarea literelor mari și mici amestecate sau a underscore-urilor, crearea a două URL-uri care diferă doar printr-un slash final și schimbarea unei rute fără a o păstra pe cea veche.

canonical

• Scop — O adresă canonică identifică URL-ul preferat dintre versiunile echivalente sau aproape echivalente accesibile. Consolidează identitatea; nu mută un vizitator și nu scuză duplicarea necontrolată.
• Tip și format — Un URL HTTPS absolut, incluzând host-ul intenționat și calea normalizată: https://amicited.com/academy/rotate-an-api-key/. Șablonul poate deriva o auto-referință din permalink-ul paginii atunci când site-ul are un singur host și o politică de rutare de încredere.
• Obligatoriu? — Fiecare pagină indexabilă trebuie să emită un canonical. Câmpul în sine este condiționat atunci când o valoare corectă de auto-referință este derivată automat; setați-l explicit pentru un canonical cross-domain aprobat sau excepțional.
• Limite — Exact o țintă canonică. Ținta trebuie să returneze un document indexabil de succes, să utilizeze protocolul și host-ul preferate și să reprezinte substanțial același conținut.
• Cine sau ce îl consumă — HTML <link rel="canonical">, motoare de căutare, verificări sitemap și linkuri interne, rapoarte de deduplicare și identificatori URL de schemă.
• Reguli — Auto-referință implicit. Utilizați un canonical cross-domain doar atunci când un alt editor deține echivalentul preferat și ambele părți intenționează consolidarea. Utilizați o redirecționare, nu un canonical, atunci când URL-ul vechi a fost înlocuit și utilizatorii ar trebui să ajungă întotdeauna pe cel nou. Mențineți canonical, URL sitemap, hreflang, linkuri interne și identitatea schemei aliniate.
• Greșeli comune — Directionarea fiecărei pagini paginate sau localizate către un părinte generic, canonicalizarea conținutului distinct, targetarea unei redirecționări sau a unei pagini de eroare, amestecarea HTTP și HTTPS, utilizarea câmpului ca substitut pentru un alias și presupunerea că directivele canonice sunt garantate a fi respectate.

aliases

• Scop — aliases păstrează rutele care au identificat anterior aceeași pagină, astfel încât o mutare să nu transforme linkurile și marcajele existente în fundături. Înregistrează istoricul rutei, mai degrabă decât să creeze identități indexabile alternative.
• Tip și format — Un array TOML de căi relative la site, de exemplu aliases = [ "/blog/old-api-key-guide/" ]. Fiecare valoare include un slash la început și la sfârșit și trebuie să fie unică pe întreg site-ul.
• Obligatoriu? — Opțional pentru o pagină nouă; obligatoriu de fiecare dată când o pagină publicată se mută de pe o cale pe care site-ul o controla.
• Limite — Includeți fiecare rută cunoscută anterioară care încă primește linkuri sau trafic. Nu adăugați variante de ortografie speculative sau o listă nelimitată de URL-uri de cuvinte cheie.
• Cine sau ce îl consumă — Ieșirea de alias Hugo, procesarea redirecționărilor la implementare acolo unde este configurat, QA de migrare, monitorizare linkuri și utilizatori care urmăresc URL-uri vechi. Deoarece Hugo poate emite o pagină de alias în loc de o redirecționare HTTP la nivel de origine, comportamentul la implementare trebuie verificat, nu presupus.
• Reguli — O pagină mutată își menține calea veche funcțională. Fiecare alias trebuie să se rezolve într-un singur salt către ruta canonică curentă. Actualizați linkurile interne către noul URL chiar și atunci când aliasul funcționează și păstrați aliasul pe parcursul editărilor ulterioare, cu excepția cazului în care un sistem documentat de redirecționare îl înlocuiește.
• Greșeli comune — Ștergerea paginii vechi fără un alias, înlănțuirea căii vechi la calea intermediară la calea curentă, tratarea aliasurilor ca rute de publicare duplicate, directionarea mai multor pagini fără legătură către o destinație convenabilă sau presupunerea că ieșirea Hugo locală dovedește starea HTTP de producție.

type și layout

• Scop — Aceste câmpuri selectează contractul de redare. type plasează o pagină într-o clasă de conținut cu șabloane și comportament partajate; layout solicită un șablon specific în cadrul acelei clase. Selectarea corectă asigură că pagina primește navigarea, slotul de conținut, activele și comportamentul de schemă intenționate.
• Tip și format — Șiruri de litere mici înregistrate. Această pagină folosește type = "academy". O valoare layout este un nume de bază de șablon, cum ar fi single, fără extensie de fișier sau traversare de cale.
• Obligatoriu? — type este obligatoriu atunci când locația conținutului nu implică în siguranță tipul intenționat sau când contractul playbook-ului îl impune. layout este opțional și ar trebui omis atunci când șablonul implicit al tipului este corect.
• Limite — O valoare pentru fiecare câmp, aleasă doar din șabloanele întreținute de site. O valoare nouă este o modificare de inginerie, nu o improvizație editorială.
• Cine sau ce îl consumă — Ordinea de căutare Hugo, șabloane, selecția de parțiale, includerea CSS și JavaScript, adaptoare de schemă și reguli de validare.
• Reguli — Alegeți tipul de postare și contractul de redare înainte de redactare. Utilizați layout doar pentru o variantă suportată reală; nu îl utilizați pentru a compensa conținutul care aparține unui alt type. Verificați că o suprascriere există și acceptă forma frontmatter-ului paginii.
• Greșeli comune — Confundarea entity-ului editorial cu type-ul Hugo, denumirea unui fișier șablon care nu există, copierea unui tip de pagină de destinație pe un document academia, bazarea pe inferența folderelor în timpul unei migrări și introducerea de nume de layout unice care ocolesc îmbunătățirile partajate.

Descoperire

description

• Scop — Descrierea ajută un căutător calificat sau un destinatar al unei partajări să decidă dacă această pagină răspunde nevoii. Este un text de previzualizare, nu o introducere comprimată și nu un loc pentru a dovedi relevanța prin repetiție.
• Tip și format — O frază de text simplu. Ar trebui să numească termenul principal în mod natural, să afirme valoarea concretă și să adauge un scop, public, metodă sau rezultat util.
• Obligatoriu? — Obligatoriu pentru fiecare pagină indexabilă din acest playbook.
• Limite — 150–160 caractere, inclusiv spații. Aceasta este o bandă de consistență editorială, nu o garanție de afișare: motoarele de căutare o pot trunchia sau rescrie fragmentul din conținutul corpului atunci când un alt pasaj se potrivește mai bine cu interogarea.
• Cine sau ce îl consumă — Etichete meta description, valori implicite Open Graph și Twitter description, carduri de listare, feeduri, previzualizări CMS, verificări de calitate a căutării și uneori description schema.
• Reguli — Scrieți pentru un clic din partea cititorului potrivit. Faceți fraza suficient de specifică pentru a distinge pagina de un alt rezultat cu un titlu similar. Secțiunea Reguli pentru descriere de mai jos oferă rațiunea și testele de respingere.
• Greșeli comune — Duplicarea titlului, listarea cuvintelor cheie, începerea cu „Află totul despre”, formularea unei afirmații nesuportate de cel-mai-bun-sau-cel-mai-rapid, utilizarea unui îndemn vag la acțiune, depășirea benzii printr-un sufix de marcă nevăzut sau presupunerea că textul scris trebuie să apară textual în rezultatele căutării.

keywords

• Scop — În acest depozit, keywords înregistrează setul compact de interogări și terminologie utilizat pentru QA editorial, căutare în corpus, analiză de acoperire și instrumente interne. Ajută editorii să recunoască limbajul pe care o pagină trebuie să îl utilizeze cu acuratețe; nu este o promisiune de a include fiecare frază în mod mecanic.
• Tip și format — Un array de șiruri de limbaj natural, ordonate de la termenul principal prin variante semnificative și terminologie strâns legată.
• Obligatoriu? — Obligatoriu conform acestui playbook, inclusiv pentru paginile ai căror șabloane publice nu redau valorile.
• Limite — Șase până la opt intrări distincte. Fiecare intrare trebuie să reprezinte o frază de interogare reală sau un termen necesar, nu o variație la nivel de token.
• Cine sau ce îl consumă — Validatori editoriali, inventare de conținut, analiză de căutare și oportunități, regăsire internă și instrumente de migrare. Motoarele de căutare publice nu utilizează acest câmp ca semnal de clasare doar pentru că există.
• Reguli — Mențineți setul concentrat pe domeniul unei singure pagini. Uniți duplicatele de majuscule, punctuație, singular/plural și ordine trivială a cuvintelor. Utilizați frazele pentru a verifica acoperirea și terminologia, niciodată pentru a dicta o densitate nenaturală.
• Greșeli comune — Tratarea câmpului ca mecanism învechit de clasare meta-keywords, adăugarea a zeci de variante, repetarea titlului ca opt intrări aproape identice, inserarea numelor competitorilor pe care corpul nu le discută și permiterea array-ului să înlocuiască o taxonomie adecvată sau ținte de prompt.

targetPrompts

• Scop — targetPrompts înregistrează întrebările sau solicitările complete pe care o persoană le poate da unui sistem AI de răspuns și pentru care această pagină ar trebui să fie o sursă utilă. Țintele de prompt păstrează contextul conversațional pe care frazele scurte de cuvinte cheie îl omit.
• Tip și format — Un array de șiruri complete de limbaj natural, de exemplu targetPrompts = [ "How do I rotate an API key without downtime?", "What should I check before revoking an old API key?" ]. Păstrați formularea așa cum ar întreba un utilizator, incluzând public, constrângeri sau comparația dorită.
• Obligatoriu? — Condiționat pentru paginile incluse în urmărirea prompturilor sau într-un program de conținut pentru vizibilitate AI; opțional atunci când nu există un set de prompturi urmărit.
• Limite — Utilizați un set mic, intenționat, în mod normal un prompt principal și până la patru variante semnificative. Un prompt poate fi mai lung decât un cuvânt cheie, deoarece calificatorii săi poartă intenția.
• Cine sau ce îl consumă — Briefuri de conținut, fluxuri de lucru de urmărire a prompturilor, audituri de regăsire și acoperire, monitorizare a răspunsurilor AI și evaluare editorială. Nu este redat ca text de căutare ascuns.
• Reguli — Separați prompturile după nevoia reală de informație, nu după punctuație. Un cuvânt cheie precum „rotație cheie API” numește un subiect; „Cum poate o echipă SaaS să rotească o cheie API fără a întrerupe integrările?” numește un public, o sarcină și o constrângere. Pagina trebuie să răspundă onest la fiecare prompt stocat.
• Greșeli comune — Copierea array-ului de cuvinte cheie în acest câmp, fabricarea a zeci de variante sintactice, înregistrarea de prompturi mai largi decât pagina, utilizarea prompturilor ca titluri de corp indiferent de fluxul de lectură și pretinderea acoperirii prompturilor atunci când răspunsul depinde de informații pe care pagina nu le oferă.

Încredere și proveniență

date și updated

• Scop — date păstrează momentul în care pagina a fost publicată pentru prima dată; updated raportează cea mai recentă modificare substanțială sau revizuire finalizată. Două câmpuri păstrează istoricul, arătând în același timp dacă informațiile pe care se bazează cititorii s-au schimbat.
• Tip și format — Șiruri de timestamp în convenția site-ului, YYYY-MM-DD HH:MM:SS. Mențineți o politică de fus orar pe întreg corpusul, astfel încât feedurile și comparațiile să rămână deterministe.
• Obligatoriu? — date este obligatoriu pentru paginile editoriale publicate. updated este opțional până la o modificare calificativă, apoi obligatoriu dacă pagina prezintă o dată modificată.
• Limite — O valoare fiecare. updated nu poate preceda date sau fi în viitor. O corectură făcută la câteva minute după publicare poate fi încă documentată, dar reviziile obișnuite ale schițelor înainte de publicare nu creează o dată actualizată.
• Cine sau ce îl consumă — Linii de autor vizibile și ștampile de prospețime, feeduri, sitemapuri, schema datePublished și dateModified, audituri de actualitate, sortare și cozi editoriale.
• Reguli — Resetați updated pentru o corectură factuală, o instrucțiune schimbată, dovezi noi sau eliminate, un domeniu revizuit, o recomandare modificată material sau o revizuire documentată a afirmațiilor sensibile la timp. Nu îl resetați niciodată pentru punctuație, formatare, lucrări de șablon sau o editare doar de timestamp. Consultați Date, autori și recenzenți pentru rațiunea politicii.
• Greșeli comune — Suprascrierea datei originale în timpul unei reîmprospătări, datarea viitoare a unei pagini pentru a părea proaspătă, actualizarea datelor fără o diferență de conținut, tratarea unei implementări automate ca o actualizare editorială și neînregistrarea a ceea ce s-a schimbat în istoricul de actualizare întreținut.

author

• Scop — author conectează documentul la entitatea persoană responsabilă pentru munca sa. Legătura oferă unui cititor și unei mașini o cale de la o pagină cu afirmații la o identitate întreținută, expertiză și alte lucrări.
• Tip și format — Un identificator stabil de autor care se rezolvă prin registrul de autori al site-ului către un URL de profil și o înregistrare Person. De exemplu, author = "maya-chen" este valid doar dacă acel identificator se rezolvă; un nume afișat precum "Maya Chen, Expert SEO" nu este un substitut pentru legătura entității.
• Obligatoriu? — Obligatoriu pentru paginile editoriale substanțiale. Paginile tranzacționale pot folosi un proprietar organizațional guvernat doar atunci când șablonul și politica suportă acel tip de entitate.
• Limite — Un responsabil principal în mod implicit; utilizați un array documentat de identificatori doar atunci când schema și șabloanele de linie de autor suportă coautoratul real.
• Cine sau ce îl consumă — Linii de autor vizibile, linkuri către profilul autorului, schema Article, feeduri, rapoarte de proprietate editorială, fluxuri de lucru de revizuire și grafuri de entități.
• Reguli — Rezolvați identificatorul înainte de publicare. Profilul trebuie să identifice aceeași persoană afișată în linia de autor și să rămână întreținut. Creditați persoana responsabilă pentru conținut, nu persoana care doar l-a încărcat.
• Greșeli comune — Introducerea unui șir de nume nelegat, utilizarea „Admin” sau a unei echipe editoriale inventate, atribuirea unui executiv proeminent care nu a scris lucrarea, permiterea unui identificator să se rezolve la niciun profil și schimbarea autorului pentru a implica o expertiză care nu a fost implicată.

reviewedBy, reviewedAt și reviewScope

• Scop — Aceste câmpuri înregistrează o revizuire independentă distinctă de calitatea de autor. reviewedBy identifică entitatea recenzent; reviewedAt indică momentul finalizării revizuirii; reviewScope spune ce a verificat recenzentul, astfel încât insigna să nu implice aprobarea dincolo de dovezi.
• Tip și format — reviewedBy este un identificator stabil care se rezolvă la un profil de persoană întreținut. reviewedAt utilizează formatul de timestamp al site-ului. reviewScope este o declarație concisă de text simplu, cum ar fi „Pași de rotație a creditențialelor și avertismente de securitate.”
• Obligatoriu? — Condiționat atunci când legea, politica de risc, sensibilitatea subiectului sau specificația tipului de postare impune o revizuire independentă. Când reviewedBy este prezent, data și domeniul revizuirii sunt obligatorii ca date ale înregistrării de revizuire, chiar dacă un anumit șablon le stochează într-o înregistrare editorială conectată, mai degrabă decât în frontmatter-ul public.
• Limite — Numiți doar recenzenți reali. Domeniul ar trebui să fie suficient de specific pentru a dezvălui excluderile fără a deveni un raport de revizuire. Un recenzent trebuie să aibă competență relevantă și nu trebuie să dubleze pur și simplu rolul de autor.
• Cine sau ce îl consumă — Componente de tip „revizuit de”, jonțiuni de entitate persoană, audituri de guvernanță, porți de publicare cu risc ridicat, proveniență structurată și jurnale de actualizare.
• Reguli — Finalizați revizuirea după ce conținutul este stabil, capturați constatările și rezolvarea în istoricul editorial și reexaminați atunci când modificările ulterioare afectează domeniul revizuit. Independent înseamnă că recenzentul testează munca, nu că își susține propriul draft.
• Greșeli comune — Tratarea corecturii editoriale ca revizuire de expert, afișarea unui recenzent fără dată sau domeniu, numirea cuiva care nu a văzut niciodată versiunea finală, lăsarea insignei după o rescriere materială nerevizuită și implicarea aprobării legale, medicale sau tehnice în afara domeniului declarat.

Media și social

image și imageAlt

• Scop — image selectează activul reprezentativ principal și social; imageAlt furnizează alternativa text funcțională atunci când acel activ este redat ca conținut semnificativ al paginii. Păstrarea perechii împreună împiedică imaginile de descoperire să devină o omisiune de accesibilitate.
• Tip și format — image este o cale de site rezolvabilă sau un URL absolut aprobat. imageAlt este text simplu care descrie informațiile utile ale imaginii în contextul paginii sale, nu numele fișierului sau cuvântul cheie țintă.
• Obligatoriu? — Condiționat de tipul de postare și șablon. Dacă pagina necesită o imagine principală sau o imagine socială dedicată, image este obligatoriu. imageAlt este obligatoriu de fiecare dată când acea imagine se redă informativ; o redare pur decorativă trebuie să utilizeze un atribut alt gol în șablon, nu un text descriptiv inventat.
• Limite — Utilizați un activ reprezentativ. Pentru compatibilitate socială, furnizați o sursă de 1200 × 630 pixeli în raportul de decupare așteptat, păstrați conținutul important departe de margini și mențineți imageAlt concis — în mod normal 5–160 caractere. Fișierul trebuie să existe înainte de a fi referit.
• Cine sau ce îl consumă — Componente principale, carduri de listare, etichete Open Graph și Twitter, câmpuri de imagine schemă, feeduri, pipeline-uri de imagine, cititoare de ecran când este vizibil și QA de active.
• Reguli — Alegeți o imagine care comunică în continuare după un decupaj central și la dimensiunea de miniatură. Descrieți funcția sa în context: „Setări cheie API cu opțiunea Rotire cheie evidențiată” este util; „cheie API” nu este. Nu puneți afirmații esențiale doar în pixeli.
• Greșeli comune — Referirea la un activ planificat care nu există, utilizarea unui logo ca imagine a fiecărui articol, încorporarea de text mic care devine ilizibil în partajări, scrierea „imagine cu”, înghesuirea cuvintelor cheie în textul alternativ și presupunerea că textul alternativ social și comportamentul textului alternativ al imaginii vizibile sunt identice pe toate platformele.

Câmpuri Open Graph și Twitter card

• Scop — Metadatele sociale controlează modul în care un URL este rezumat atunci când este partajat. Un titlu, o descriere, un URL, un tip și o imagine consistente ajută destinatarii să recunoască pagina înainte de a da clic și reduc șansa ca o platformă să selecteze un activ irelevant.
• Tip și format — În acest depozit, șabloanele derivă og:title și twitter:title din title, descrierile din description, URL-urile din permalink, og:type din contextul layout-ului și ambele etichete de imagine din image cu un fallback al site-ului. twitter:card este emis ca summary_large_image. Acestea sunt etichete generate, nu câmpuri de frontmatter duplicate în mod implicit.
• Obligatoriu? — Etichetele de ieșire sunt obligatorii pe paginile publice. Suprascrierile separate sunt opționale și ar trebui introduse doar printr-un contract de șablon documentat; câmpurile ad-hoc nesuportate, cum ar fi ogTitle, nu fac nimic.
• Limite — O previzualizare coerentă per pagină și o imagine reprezentativă de 1200 × 630. Păstrați formularea derivată în benzile de titlu și descriere, apoi testați comportamentul real de decupare pe principalele suprafețe de partajare.
• Cine sau ce îl consumă — Rețele sociale, clienți de mesagerie, instrumente de despachetare a linkurilor, extensii de browser, instrumente de colaborare și depanatoare de previzualizare a partajării.
• Reguli — Preferați derivarea, astfel încât afirmațiile de căutare și sociale să rămână aliniate. Suprascrieți doar atunci când contextul social are nevoie reală de o încadrare diferită și șablonul o suportă. O imagine greșită costă recunoaștere și încredere: destinatarul poate vedea o interfață învechită, un alt produs, o afirmație înșelătoare sau un decupaj care ascunde subiectul.
• Greșeli comune — Scrierea unor câmpuri pe care niciun șablon nu le citește, permiterea unui fallback global să mascheze o imagine principală obligatorie lipsă, utilizarea unui portret sau a unei imagini mici pentru un card larg, modificarea textului social pentru a face o promisiune mai puternică decât pagina și validarea doar a sursei HTML, nu a unei previzualizări obținute.

Clasificare

taxonomy, categories și tags

• Scop — Clasificarea conectează o pagină la colecții guvernate de subiect, format, public sau produs. Alimentează arhive și filtre utile doar atunci când fiecare vocabular are un sens declarat; altfel etichetele devin o grămadă necontrolată de sinonime.
• Tip și format — Array-uri de slug-uri înregistrate cu litere mici. Utilizați taxonomy pentru vocabularul controlat de subiect al depozitului. Utilizați categories doar pentru o ierarhie editorială mică, inteligibilă reciproc, și tags doar pentru un vocabular guvernat transversal atunci când acele taxonomii sunt configurate.
• Obligatoriu? — Condiționat de tipul de postare și designul arhivei. Paginile editoriale cu subiect necesită în mod normal unul sau mai mulți termeni controlați; paginile utilitare pot să nu necesite niciunul. Un câmp nu trebuie populat doar pentru că un CMS îl expune.
• Limite — Pentru taxonomia generală, una până la cinci valori per vocabular controlat. Fiecare termen are nevoie de o definiție, un proprietar și o regulă de unire. Creați o arhivă indexabilă doar atunci când termenul reprezintă o cerere durabilă a cititorilor și arhiva poate oferi o introducere unică, un inventar coerent, linkuri interne și întreținere continuă.
• Cine sau ce îl consumă — Pagini de arhivă, breadcrumb-uri, filtre, sisteme de conținut conex, navigare fațetată, audituri de conținut și segmentare de analitică.
• Reguli — Alegeți cel mai restrâns termen înregistrat care grupează cu acuratețe pagina. Mențineți variantele de singular/plural, abrevieri și ortografie mapate la o valoare canonică. Decideți dacă arhivele sunt indexabile la nivel de vocabular, nu etichetă cu etichetă după crearea accidentală.
• Greșeli comune — Utilizarea seo, SEO, search-optimization și search engine optimization ca valori separate, adăugarea de etichete unice pentru a descrie fiecare substantiv, confundarea unui tip de afacere cu un subiect, generarea de arhive indexabile subțiri și ștergerea termenilor fără a migra membrii lor.

Chei de jonțiune ale playbook-ului

• Scop — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage și amicitedFeatures sunt chei de jonțiune tipizate. Acestea permit unei singure pagini sursă să apară în biblioteci și matrici generate fără ca editorii să copieze carduri manual. Această pagină este exemplul lucrat: pilonul său identifică un element, familia sa grupează îndrumări privind metadatele, iar array-ul său postTypes declară specificațiile care îl consumă.
• Tip și format — Cheile singulare utilizează slug-uri înregistrate cu litere mici: playbookPillar și playbookFamily sunt șiruri, playbookWave este un întreg, iar journeyStage este un șir controlat. Cheile de relație — postTypes, elements, businessTypes și amicitedFeatures — sunt array-uri de slug-uri înregistrate din registrele lor respective.
• Obligatoriu? — playbookPillar și playbookWave sunt obligatorii pe înregistrările playbook. playbookFamily este obligatoriu acolo unde pilonul are familii guvernate. Jonțiunile de array și journeyStage sunt condiționate: populați doar relațiile pe care contractul paginii le suportă efectiv.
• Limite — Un pilon, o familie în cadrul acelui pilon, un val și o etapă a călătoriei, cu excepția cazului în care modelul permite în mod explicit mai multe etape. Array-urile conțin chei înregistrate unice, nu etichete de afișare, proză sau URL-uri.
• Cine sau ce îl consumă — Listări hub playbook, matrici cross-pilon, filtre, carduri de relație, rapoarte de completitudine, vizualizări pe val de lansare și instrumente interne care găsesc capacități AmICited relevante.
• Reguli — Validați fiecare valoare în raport cu registrul canonic. Direcția contează: o pagină de tip de postare își listează elements-ele obligatorii; o pagină de element listează postTypes-urile aplicabile; o pagină de tip de afacere listează tipurile de postare utile. Tratați etichetele ca prezentare și cheile ca date durabile. Redenumiți o cheie doar printr-o migrare care actualizează fiecare parte a jonțiunii.
• Greșeli comune — Inventarea de aproape-sinonime, stocarea titlurilor în loc de slug-uri, amestecarea întregilor și șirurilor pentru valuri, adăugarea unei relații pentru că două pagini se menționează reciproc, permiterea array-urilor reciproce să se contrazică și crearea de markup de listare întreținut manual care se îndepărtează de metadate.

Câmpuri derivate și structurale

schemaType

• Scop — schemaType selectează cea mai specifică mapare de date structurate suportată care descrie cu acuratețe pagina vizibilă. Spune adaptorului de schemă ce contract de vocabular să aplice; nu transformă pagina în acel lucru doar prin declarație.
• Tip și format — Un nume de tip Schema.org înregistrat, cum ar fi Article, selectat dintre tipurile pe care adaptorul site-ului le suportă. Scrierea cu majuscule și ortografia trebuie să corespundă registrului.
• Obligatoriu? — Condiționat. Setați-l acolo unde mai multe mapări de schemă sunt valide pentru același tip Hugo sau unde contractul tipului de postare necesită un tip explicit. În caz contrar, lăsați șablonul să-și derive valoarea implicită sigură.
• Limite — Un tip de pagină principal, cu entități imbricate create de adaptor din conținutul real. Tipul selectat trebuie să satisfacă toate proprietățile obligatorii și să corespundă cu ceea ce poate vedea un cititor.
• Cine sau ce îl consumă — Adaptoare JSON-LD, validare rezultate îmbogățite, QA de conținut și rapoarte de inventar schemă.
• Reguli — Alegeți din funcția paginii și dovezile vizibile, nu din funcționalitatea de căutare pe care un editor o dorește. O pagină de tip ghid practic fără o procedură vizibilă completă nu poate câștiga acuratețe prin setarea unui tip de ghid practic. Mențineți URL-urile, datele, persoanele și imaginile schemei sincronizate cu câmpurile lor sursă.
• Greșeli comune — Selectarea unui tip mai specific fără conținutul său obligatoriu, emiterea mai multor tipuri principale conflictuale, copierea unei valori de schemă dintr-un șablon fără legătură, presupunerea că sintaxa validă garantează eligibilitatea și plasarea afirmațiilor în JSON-LD pe care cititorii nu le pot inspecta.

Timp de citire

• Scop — Timpul de citire oferă cititorului o estimare grosieră a efortului. Este derivat din corpul final redat, astfel încât estimarea se schimbă atunci când sarcina reală de citire se schimbă.
• Tip și format — Un număr întreg de minute calculat, produs din politica de numărare a cuvintelor a pipeline-ului de conținut. Blocurile de cod, tabelele, legendele și mediile încorporate ar trebui să urmeze o regulă de numărare documentată.
• Obligatoriu? — Afișarea este opțională în funcție de șablon. Un câmp de frontmatter scris de autor nu este permis ca sursă de adevăr.
• Limite — Rotunjiți consecvent și aplicați un minim rezonabil de afișare, cum ar fi un minut. Ipoteza precisă de cuvinte pe minut contează mai puțin decât utilizarea aceleiași metode pe întreg site-ul și etichetarea rezultatului ca estimare.
• Cine sau ce îl consumă — Antete de pagină, carduri, feeduri, segmentare de analitică și cititori care decid dacă să înceapă un ghid lung.
• Reguli — Calculați după ce shortcode-urile și regiunile excluse sunt gestionate conform politicii site-ului. Recalculați la fiecare construire. Dacă un videoclip sau o sarcină interactivă modifică material timpul de finalizare, etichetați-o separat, mai degrabă decât să corupeți timpul de citire.
• Greșeli comune — Scrierea readingTime = 8, uitarea de a-l actualiza după o rescriere, prezentarea unei precizii false, numărarea navigației și a conținutului boilerplate și tratarea unui ghid practic cu execuție grea ca opt minute de citire plus niciun timp de sarcină.

[[faq]]

• Scop — [[faq]] stochează perechi vizibile de întrebări și răspunsuri o singură dată, astfel încât pagina și orice date structurate FAQ eligibile să nu se poată separa.
• Tip și format — Un array TOML de tabele; fiecare element conține un question de text simplu și un șir answer autoconținut.
• Obligatoriu? — Condiționat atunci când întrebări reale de follow-up rămân după pagina principală. Nu este niciodată obligatoriu doar pentru a umple un șablon sau pentru a urmări o funcționalitate de căutare.
• Limite — În mod normal, patru până la opt elemente utile pe paginile playbook. Fiecare întrebare apare o singură dată, iar fiecare răspuns trebuie să fie complet fără a se baza pe ordinea acordeonului.
• Cine sau ce îl consumă — Redare FAQ vizibilă, schemă FAQPage acolo unde este eligibilă, navigare pe pagină, QA de conținut și extragere de răspunsuri.
• Reguli — Acesta este un contract de referință încrucișată: urmați De ce FAQ-ul trăiește în frontmatter și îndrumările ulterioare despre FAQ, mai degrabă decât să mențineți copii vizibile și de schemă separate. Stocați doar întrebări la care fiecare cititor poate accesa pe pagină.
• Greșeli comune — Răspunsuri doar pentru schemă ascunse, titluri duplicate deghizate ca întrebări, răspunsuri promoționale, afirmații nesuportate, JSON-LD învechit și tratarea eligibilității rezultatelor de căutare ca garantată.

[[lnks]]

• Scop — [[lnks]] înregistrează fiecare link intern guvernat utilizat în corp, asociind ancora sa vizibilă cu o destinație și o descriere întreținută. Înregistrarea face linkurile inspectabile fără a răzui HTML-ul redat și suportă migrarea și QA.
• Tip și format — Un array TOML de tabele cu text, path și title. text este ancora vizibilă exactă, path este un URL relativ la site cu slash la început și sfârșit, iar title este descrierea paginii de destinație.
• Obligatoriu? — Obligatoriu pentru fiecare link intern de corp guvernat de această convenție de conținut. Linkurile adânci de aplicație și sursele externe urmează propriile înregistrări și nu sunt deghizate ca intrări [[lnks]].
• Limite — O înregistrare per apariție a linkului în corp atunci când aceeași ancoră poate indica destinații diferite; în caz contrar, înregistrările duplicate exacte ar trebui eliminate. Destinația trebuie să existe sau să fie în registrul de slug-uri canonice aprobat pentru lansarea coordonată.
• Cine sau ce îl consumă — Validare linkuri interne, migrare conținut, analiză de relații, generare de titluri de link acolo unde este suportat și revizuire editorială.
• Reguli — Potriviți text cu ancora corpului textual, inclusiv majusculele și punctuația din interiorul linkului. Utilizați calea canonică relativă la site. Scrieți title ca o descriere exactă a destinației, nu ca instrucțiuni pentru pagina curentă. Actualizați înregistrarea și corpul împreună.
• Greșeli comune — Utilizarea unei valori text mai lungi decât ancora reală, inventarea unui slug neînregistrat, omiterea unui slash final, înregistrarea unei căi vechi de redirecționare, descrierea sursei în locul destinației și lăsarea unei înregistrări după ce linkul său de corp este eliminat.

Obligatoriu versus opțional în funcție de tipul de postare

Matricea aplică contractele de mai sus celor douăsprezece tipuri de postare declarate în prezent de acest element. R înseamnă obligatoriu, C înseamnă condiționat conform regulilor câmpurilor, D înseamnă ieșire obligatorie care poate fi derivată în siguranță, iar O înseamnă opțional. „Identitate” include entity, id, title, type și ruta stabilă. „Descoperire” include description și keywords; prompturile țintă rămân condiționate pentru fiecare rând. aliases este întotdeauna condiționat de o mutare, în timp ce timpul de citire scris de autor nu este niciodată obligatoriu.

„Recenzent condiționat” nu este permisiunea de a sări peste revizuire acolo unde acuratețea sau riscul comercial o impune. Paginile „cel mai bun X” și „alternative” necesită revizuire independentă deoarece recomandările lor pot influența material o decizie și se schimbă adesea pe măsură ce produsele, prețurile și eligibilitatea se modifică. Pentru alte rânduri, politica de risc, nu timpul disponibil al unui editor, activează cerința. De asemenea, un canonic marcat D este încă obligatoriu în HTML-ul redat; doar intrarea frontmatter poate fi omisă atunci când șablonul poate genera auto-referința corectă.

Validare frontmatter

Validarea ar trebui să respingă defectele deterministe automat și să rezerve judecata pentru întrebări care depind de sens, dovezi sau competență profesională. Separarea previne două eșecuri opuse: a cere recenzenților să prindă sintaxa pe care un analizor o poate prinde perfect și a pretinde că o regulă de numărare a caracterelor poate decide dacă textul este onest.

Rulați verificările deterministe înainte de revizuirea editorială, astfel încât recenzentul să vadă o înregistrare coerentă. Apoi revizuiți HTML-ul redat, nu doar frontmatter-ul: o valoare sursă validă este totuși un defect de producție dacă șablonul selectat o ignoră, o mapează la eticheta greșită, ascunde proveniența obligatorie sau generează un canonic care nu este de acord cu ruta publică. Publicarea este completă doar atunci când sursa, redarea și comportamentul destinației sunt de acord.

Câmpul entity

entity răspunde la întrebarea „ce tip exact de postare este o instanță acest document?” Nu răspunde la întrebarea „ce subiect discută această pagină?” Această distincție contează deoarece două documente pot aborda același subiect făcând sarcini diferite. O intrare de glosar definește „diagnostic”; un articol de blog poate raporta o schimbare în îndrumările de diagnostic. Dacă ambele folosesc entity = "diagnosis", sistemele din aval nu pot selecta în mod fiabil șablonul corect, regulile de validare, grupul de analitică sau migrarea.

Utilizați prefixul de grup plus slug-ul tipului de postare pentru variantele dintr-o familie: guide-how-to, guide-ultimate, comparison-a-vs-b și comparison-alternatives-to-x. Utilizați numele simplu pentru un tip autonom: product-page sau case-study. Înregistrați identificatorul o dată, păstrați-l stabil și nu îl schimbați niciodată pentru că subiectul sau interogarea țintă se schimbă. Puneți conceptele de subiect în taxonomy și limbajul de interogare în keywords.

Titlu, H1 și titlu SEO

Aceste valori pot diferi în funcție de context, dar trebuie să descrie aceeași pagină. title este valoarea implicită durabilă. h1 este titlul vizibil și poate fi mai natural în context. seoTitle servește browserului și rezultatelor de căutare și poate adăuga un diferențiator concis, un an legitim sau un sufix de marcă.

De exemplu, title = "API Key Rotation", h1 = "How to Rotate an API Key Without Downtime" și seoTitle = "API Key Rotation: Safe Step-by-Step Guide" se aliniază pe o singură sarcină. „Free Security Tool” ca titlu SEO ar fi înșelător deoarece schimbă promisiunea. Nu creați diferențe doar pentru a introduce mai multe cuvinte cheie.

Reguli pentru descriere

Descrierea există pentru a ajuta un cititor calificat să decidă să dea clic. Mențineți-o între 150–160 de caractere, includeți termenul principal în mod natural, afirmați beneficiul concret al paginii și adăugați un calificativ semnificativ, cum ar fi publicul, domeniul sau rezultatul. Scrieți o frază fluentă, nu o listă de cuvinte cheie.

Termenul confirmă relevanța; repetiția nu adaugă valoare. Nu duplicați titlul, nu folosiți „Află totul despre”, nu faceți superlative nesuportate și nu terminați pe la jumătatea gândului. Sistemele de căutare pot selecta în continuare un text vizibil diferit pentru o interogare.

Date, autori și recenzenți

date păstrează timestampul primei publicări. updated înregistrează cea mai recentă modificare substanțială: o corectură factuală, dovezi noi, instrucțiuni schimbate, domeniu revizuit, recomandare modificată sau revizuire completă care confirmă afirmațiile sensibile la timp. Înregistrați ce s-a schimbat în istoricul editorial atunci când politica o cere.

Corectarea punctuației, schimbarea unui stil de buton, reconstruirea unui șablon sau atingerea timestampului singur nu resetează updated. Avansarea unei date fără muncă în spate este o încălcare a politicii, deoarece spune cititorilor și mașinilor că conținutul a fost reîmprospătat când nu a fost. Este denaturare, nu o tactică de creștere.

Câmpurile de autor și recenzent poartă identități responsabile în liniile de autor și datele structurate. Autorul este responsabil pentru muncă. Utilizați reviewedBy doar atunci când a avut loc o revizuire calificată și conectați ambii identificatori la profiluri întreținute. Pagina fundațiilor de încredere explică modul în care calitatea de autor, datele, dovezile și claritatea entităților sprijină încrederea fără a garanta clasamentele.

De ce FAQ-ul trăiește în frontmatter

Un FAQ este conținut vizibil și o colecție structurată. Stocarea o dată în [[faq]] permite șablonului să redea acordeonul și JSON-LD-ul FAQPage identic, prevenind schema învechită ascunsă.

Includeți întrebări reale de follow-up vizibile pentru fiecare cititor. Nu duplicați titlurile, nu ascundeți promoții în răspunsuri și nu marcați întrebări neafișate. Markup-ul valid nu garantează o funcționalitate de căutare.

Sintaxă și exemple de cod

Contractul cross-platform mapează câmpuri, nu o componentă vizibilă. Următorul plic portabil este valid doar într-un fișier de schimb al cărui importator recunoaște directivele de metadate:

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

Trebuie normalizat în metadatele native ale paginii în timpul importului. Nu este valid în corpul unui articol de producție. În Hugo, maparea corectă este TOML între delimitatorii +++ la primul octet, așa cum se arată în specimenul live. Nu există în mod deliberat un shortcode {{< frontmatter >}}: un shortcode ar rula prea târziu și în regiunea greșită a documentului.

În WordPress, mapați aceleași câmpuri canonice la câmpurile de postare înregistrate și meta de postare, de exemplu post_title, post_excerpt, post_name, _amicited_entity, _amicited_author și _amicited_reviewed_by. Un comentariu precum <!-- wp:amicited/frontmatter --> sau un shortcode [frontmatter] este invalid deoarece creează un bloc de corp, nu metadate de document. Importatorii și editorii pot prezenta un panou de metadate, dar valorile stocate trebuie să rămână atașate înregistrării postării.

Exemple

Bun: o înregistrare coerentă, responsabilă

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

Acesta identifică o variantă de ghid practic, păstrează istoricul, numește persoane responsabile și separă subiectul de identitatea paginii. Timestampul actualizat este suportat de o modificare documentată a instrucțiunilor și o revizuire.

Rău: titlul repetat ca descriere

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

Descrierea nu adaugă niciun beneficiu, domeniu sau motiv de a da clic. De asemenea, irosește spațiul de previzualizare care ar putea distinge această pagină de orice alt rezultat care folosește același titlu.

Rău: o entitate reutilizată pentru două tipuri de postare

# intrare glosar
entity = "diagnosis"

# ghid editorial
entity = "diagnosis"

Subiectul partajat a înlocuit identitatea tipului de postare. Utilizați valori înregistrate precum glossary-term și guide-ultimate, apoi atribuiți „diagnosis” prin taxonomie sau cuvinte cheie.

Rău: o dată actualizată fără diferență de conținut

date = "2026-01-15 09:00:00"
updated = "2026-08-27 10:00:00" # doar data s-a schimbat

Nicio editare sau revizuire substanțială nu suportă afirmația de prospețime. Păstrați updated neschimbat sau omis până când există o modificare reală și poate fi inspectată în istoricul editorial.

Markup de schemă și accesibilitate

Metadatele furnizează valori; șablonul rămâne responsabil pentru HTML semantic, focus, contrast, scopul linkurilor și text alternativ.

Reguli de scriere

• Păstrați identificatorii stabili, cu litere mici și siguri pentru mașini. Nu reciclați niciodată un id și nu schimbați în tăcere entity după publicare.
• Utilizați text simplu în câmpurile asemănătoare titlurilor. HTML, linkuri Markdown, decorațiuni cu emoji și întreruperi forțate de linie nu aparțin șirurilor de metadate.
• Mențineți descrierea la 150–160 de caractere și array-urile de cuvinte cheie la șase până la opt fraze distincte pentru acest playbook.
• Utilizați persoane reale înregistrate pentru câmpurile de autor și recenzent. Nu creați niciodată un recenzent ceremonial sau o identitate generică „Echipa Editorială”, cu excepția cazului în care aceasta este o entitate responsabilă întreținută.
• Utilizați o taxonomie controlată. Variantele de ortografie și duplicatele singular/plural creează arhive fragmentate.
• Referiți doar imagini care există și pentru care aveți drepturi de publicare. imageAlt descrie conținutul informativ al imaginii, nu ținta SEO.
• Mențineți răspunsurile FAQ directe și autoconținute. Afirmațiile necesită în continuare aceleași dovezi și dezvăluiri ca și proza altundeva pe pagină.
• Nu plasați niciodată secrete, note private, token-uri de acces, instrucțiuni de embargo, date personale sau afirmații legale nerevizuite în frontmatter-ul publicabil.

Ce tipuri de postare utilizează frontmatter-ul și unde

Fiecare tip de postare utilizează frontmatter-ul la primul octet. Adâncimea necesară se schimbă odată cu riscul, intenția și schema, nu cu designul vizual.

Listă de verificare QA

• Începe fișierul cu +++, conține TOML valid și închide înregistrarea înaintea conținutului corpului?
• Este entity un identificator de tip de postare exact înregistrat, mai degrabă decât subiectul, campania sau numele site-ului?
• Este id unic și stabil, iar url corespunde registrului de slug-uri canonice?
• Descriu title, h1 opțional și seoTitle opțional aceeași pagină fără modificări înșelătoare ale scopului?
• Este descrierea de 150–160 de caractere, conține termenul principal în mod natural și oferă un motiv concret de a da clic?
• Există fiecare imagine referită, iar imageAlt este corect pentru imaginea care se redă?
• Este păstrată data publicării și fiecare valoare updated este suportată de o diferență substanțială sau o revizuire documentată?
• Se rezolvă identificatorii de autor și recenzent la profiluri reale întreținute, iar recenzentul numit a revizuit efectiv munca?
• Sunt cuvintele cheie limitate la șase până la opt fraze utile, iar valorile de taxonomie extrase din vocabulare controlate?
• Folosește canonical HTTPS, se rezolvă la pagina preferată și este de acord cu sitemapul și linkurile interne?
• Conține fiecare element [[faq]] o întrebare utilă și un răspuns autoconținut care se redă vizibil în formulare identică?
• Se potrivește JSON-LD-ul generat cu conținutul vizibil, folosește identificatori stabili și trece validarea sintaxei fără a pretinde tipuri nesuportate?
• Sunt secretele, notele editoriale private, afirmațiile nesuportate și dezvăluirile doar în corp absente din înregistrare?

FAQ

Frontmatter-ul este vizibil pe pagina publicată?

Înregistrarea sursă este ascunsă, dar șabloanele pot reda titlul, persoanele, datele și FAQ-ul. Alte câmpuri alimentează previzualizări, etichete canonice, feeduri, sitemapuri, schemă și sisteme interne.

Câmpul entity trebuie să conțină subiectul sau tipul de postare?

Identifică tipul exact de postare. Subiectele partajate aparțin în taxonomie și cuvinte cheie, nu în locul identității documentului.

Pot fi diferite titlul, H1 și titlul SEO?

Da. H1 poate suna mai natural, iar titlul SEO poate adăuga un diferențiator, dar toate versiunile trebuie să facă aceeași promisiune.

Când ar trebui să se modifice data actualizării?

Modificați-o după o revizuire sau editare factuală substanțială. Nu o modificați pentru punctuație, stilizare, lucrări de șablon sau o reîmprospătare doar de dată.

De ce sunt stocate întrebările FAQ în frontmatter?

Array-ul structurat permite unei singure surse să redea atât FAQ-ul vizibil, cât și JSON-LD-ul FAQPage corespunzător. Acest lucru împiedică schema să se îndepărteze de ceea ce cititorii pot inspecta.