Frontmatter obsahu: Pole a SEO metadata

Frontmatter je prvek stránky, který čtenáři nikdy nevidí jako jeden blok, ale na kterém závisí každý publikační systém. Poskytuje dokumentu identitu, kontrakt pro renderování, náhled ve vyhledávání, záznam o vlastnictví, data a vstupy pro schémata. Poškozený frontmatter může vybrat nesprávnou šablonu, vytvořit kanonické konflikty, ztratit autora nebo generovat markup, který je v rozporu se stránkou.

Živý vzorek je záznam na úrovni dokumentu, zobrazený jako kód, protože frontmatter se nesmí stát dekorativním rámečkem v těle stránky.

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

Proč frontmatter existuje

Pro čtenáře metadata snižují nejistotu. Přesný název vymezuje rozsah, užitečný popis získává proklik, identity činí tvrzení zodpovědnými a data odhalují, zda informace mohly zestárnout. Tyto signály nemohou kompenzovat slabý obsah, ale jejich absence nutí čtenáře hádat.

Pro stroje frontmatter nahrazuje odvozování pojmenovanými hodnotami. Šablony mapují pole na názvy prohlížeče, kanonické odkazy, záznamy osob, data, feedy, indexy a JSON-LD bez parsování textu. To je strojová extrahovatelnost: důležité skutečnosti mají konzistentní umístění a typ.

Postupujte podle pravidel pro psaní prvků: metadata patří na úroveň dokumentu; prvky určené čtenářům patří do těla stránky. Popisek autora může být renderován z frontmatter, ale jeho autoritativní identifikátor zůstává tam.

Kdy ho použít — a kdy ne

Každá indexovatelná stránka potřebuje jeden záznam frontmatter pro identitu, renderování a směrování. Koncepty ho potřebují, když vstupují do produkce, aby validace mohla selhat včas.

Neschovávejte faktické informace o článku do frontmatter. Omezení produktu, bezpečnostní varování, affiliate prohlášení, metody a zdroje musí zůstat viditelné tam, kde je čtenáři mohou vyhodnotit. Strukturovaná hodnota nikdy nenahrazuje zveřejnění.

Nejvíce škody způsobí téměř správné případy:

• Samostatně se měnící navigační popisky, kampaně a sociální titulky jsou nastavení kanálů; nepřetěžujte pole title.
• Organizační fakta sdílená napříč celým webem patří do záznamu organizace, nikoli zkopírovaná do každé stránky, kde se postupně rozejdou.
• Sekce otázek a odpovědí patří do [[faq]] pouze tehdy, když se stejný obsah renderuje viditelně. Skryté FAQ pouze pro schema je neplatné.
• Popisek tématu patří do taxonomy; nesmí nahrazovat entity, která identifikuje typ příspěvku dokumentu.
• Přesměrování patří do konfigurace směrování nebo schváleného pole aliases. canonical identifikuje preferovanou verzi; nepřesměrovává návštěvníky.

Kam ho umístit

Frontmatter začíná na prvním bajtu značkou +++ a končí u odpovídající ukončovací značky před tělem stránky. Žádný nadpis, komentář, poznámka, shortcode nebo blok metadat jej nesmí předcházet. TOML pole a pole patří dovnitř tohoto jednoho záznamu.

Tělo začíná za ukončovací značkou. Frontmatter nesmí být umístěn mezi H1 a úvodem, vedle screenshotu, uvnitř komponenty nebo na konci. Bajtová značka pořadí nebo zbloudilý komentář mohou zabránit rozpoznání. Duplicitní klíče, YAML ohraničení a druhé bloky jsou neplatné.

Anatomie

Renderovaná legenda zůstává na stránce, aby zůstala čitelná a překládatelná nezávisle na obrázku:

1. Ohraničení: otevírací a uzavírací značky +++ definují jedinou oblast metadat.
2. Identita: entity, id, type a url říkají systémům, co dokument je a kde se nachází.
3. Objevování: title, seoTitle, description, image, imageAlt a keywords podporují náhledy a vyhledávání.
4. Původ: date, updated, author a reviewedBy uvádějí, kdo je odpovědný a kdy byla práce platně změněna.
5. Klasifikace: taxonomy připojuje stránku k řízeným tematickým kolekcím, aniž by znovu definovala její identitu.
6. Kontrola duplicit: canonical pojmenovává preferovanou veřejnou URL, když lze ekvivalentní verze dosáhnout jinde.
7. Strukturované kolekce: každý [[faq]] vytváří jeden typovaný záznam otázky a odpovědi pro viditelné renderování a schema.

Příklady návrhů

Frontmatter má varianty datových kontraktů, nikoli vizuální styly. Screenshoty párují zdrojové záznamy s výsledným náhledem nebo popiskem autora.

Parametry

Toto jsou redakční limity, i když parser přijme více. „Podmíněné" znamená povinné, když je splněna uvedená podmínka.

Referenční příručka jednotlivých polí

Tato referenční příručka definuje publikační kontrakt pro každé pole. „Povinné" znamená, že validace by měla zastavit publikaci, když pole nebo jeho platné odvození chybí. „Podmíněné" znamená, že požadavek je aktivován uvedenou skutečností, například že je obrázek renderován nebo že proběhla nezávislá recenze. Výchozí hodnota je bezpečná pouze tehdy, když produkuje stejný význam, který by editor zvolil záměrně.

Identita a směrování

title, h1 a seoTitle

• Účel — title dává dokumentu jeho trvalé redakční jméno. h1 řídí hlavní nadpis na stránce, když kontext rozvržení vyžaduje jiné znění. seoTitle řídí název prohlížeče/vyhledávání, když výchozí hodnota potřebuje stručný kvalifikátor nebo úpravu pro značku. Jejich oddělení zabraňuje tomu, aby navigační popisek, nadpis stránky a náhled vyhledávání byly vtištěny do jednoho neohrabaného řetězce.
• Typ a formát — Každý je prostý textový řetězec. title je zdrojová hodnota; chybějící přepisy se na ni musí odvolávat. HTML, Markdown, emoji dekorace a ruční truncation značky nejsou platné hodnoty.
• Povinné? — title je povinný na každé veřejné stránce. h1 a seoTitle jsou volitelné a měly by být vynechány, když title funguje ve všech třech kontextech.
• Limity — Používejte 30–70 znaků pro title, 20–80 pro h1 a 30–60 pro seoTitle jako redakční pásma, nikoli jako příslib, že vyhledávací rozhraní zobrazí každý znak. Musí existovat jeden renderovaný H1.
• Kdo nebo co ho spotřebovává — Šablony stránek, názvy prohlížečů, adaptéry pro vyhledávání a sociální sítě, navigační karty, feedy, schema headline, osnovy pro přístupnost a redakční výpisy.
• Pravidla — Všechny verze musí identifikovat stejný předmět, záměr a rozsah. Legitimní rozdíl řeší omezení kanálu: například H1 může říkat „Jak otočit API klíč bez výpadku", zatímco kratší SEO název říká „Rotace API klíče: Bezpečný návod krok za krokem". Pozdější sekce Název, H1 a SEO název vysvětluje redakční test.
• Časté chyby — Opakování klíčového slova ve všech třech variantách, vložení přípony značky do H1, změna příslibu za účelem získání kliknutí, vložení aktuálního roku, když stránka není udržována každoročně, nebo vytvoření tří hodnot jen proto, že existují tři pole.

slug a url

• Účel — Slug je poslední segment cesty; url je veřejná cesta relativní k webu, která jej obsahuje. Dohromady dávají stránce stabilní adresu pro čtenáře, crawlerové, odkazy, reportování a migrace. Stabilita je důležitá, protože každý získaný odkaz a uložená záložka se stává závislou na této adrese.
• Typ a formát — Používejte malá písmena, cesta oddělená pomlčkami, např. /academy/rotate-an-api-key/. Tento repozitář zaznamenává celou cestu v url; CMS, který má samostatné pole slug, musí odvodit stejný finální segment.
• Povinné? — Jedinečná cesta je vyžadována pro každou veřejnou stránku. Může být generována pouze tam, kde má sekce schválené deterministické pravidlo a kontroly kolizí; stránky playbooku používají své registrované hodnoty url.
• Limity — Preferujte krátký, čitelný slug, který zachovává rozlišující předmět, obvykle tři až osm užitečných slov. Odstraňte interpunkci a prázdné modifikátory. Odstraňte stop slova jako „the" nebo „a" pouze tehdy, když výsledek zůstává přirozený a jednoznačný; neexistuje žádný arbitrární limit znaků, který by ospravedlňoval poškození významu.
• Kdo nebo co ho spotřebovává — Směrování Hugo, interní odkazy, breadcrumbs, generování canonical, sitemapy, feedy, analytika, přesměrování a externí reference.
• Pravidla — S publikovaným slugem zacházejte jako s trvalým závazkem. Rozhodujte o něm podle trvalého tématu, nikoli podle kampaně nebo přechodného roku. Když se název změní, ale téma a záměr ne, ponechte starý slug. Pokud se stránka skutečně přesune, vytvořte novou cestu, ponechte starou cestu v aliases, aktualizujte interní odkazy a otestujte cíl přesměrování.
• Časté chyby — Regenerování slugu při každé změně názvu, vkládání synonym do cesty, uchovávání dat, která způsobují, že evergreen obsah vypadá zastarale, používání smíšených velikostí písmen nebo podtržítek, vytváření dvou URL lišících se pouze koncovým lomítkem a změna cesty bez zachování té staré.

canonical

• Účel — Kanonická URL identifikuje preferovanou URL mezi ekvivalentními nebo téměř ekvivalentními dostupnými verzemi. Konsoliduje identitu; nepřesměrovává návštěvníka ani neomlouvá nekontrolovanou duplicitu.
• Typ a formát — Jedna absolutní HTTPS URL, včetně zamýšleného hostitele a normalizované cesty: https://amicited.com/academy/rotate-an-api-key/. Šablona může odvodit self-reference z permalinku stránky, pokud má web jednoho důvěryhodného hostitele a politiku směrování.
• Povinné? — Každá indexovatelná stránka musí emitovat jednu canonical. Samotné pole je podmíněné, když je správná self-referencující hodnota odvozena automaticky; explicitně ji nastavte pro schválenou cross-domain nebo výjimečnou canonical.
• Limity — Přesně jeden canonical cíl. Cíl musí vracet úspěšný indexovatelný dokument, používat preferovaný protokol a hostitele a představovat v podstatě stejný obsah.
• Kdo nebo co ho spotřebovává — HTML <link rel="canonical">, vyhledávače, kontroly sitemap a interních odkazů, deduplikační reporty a URL identifikátory schema.
• Pravidla — Standardně self-reference. Používejte cross-domain canonical pouze tehdy, když jiný vydavatel vlastní preferovanou ekvivalentní verzi a obě strany zamýšlejí konsolidaci. Použijte přesměrování, nikoli canonical, když byla stará URL nahrazena a uživatelé by měli vždy přistát na nové. Udržujte canonical, sitemap URL, hreflang, interní odkazy a schema identitu v souladu.
• Časté chyby — Směřování každé stránkované nebo lokalizované stránky na obecného rodiče, canonicalizace odlišného obsahu, cílení na přesměrování nebo chybovou stránku, míchání HTTP a HTTPS, používání pole jako náhrady za alias a předpoklad, že canonical direktivy jsou zaručeně dodržovány.

aliases

• Účel — aliases uchovává cesty, které dříve identifikovaly stejnou stránku, aby přesun neproměnil stávající odkazy a záložky ve slepé uličky. Zaznamenává historii cest, nikoli vytváří alternativní indexovatelné identity.
• Typ a formát — TOML pole cest relativních k webu, například aliases = [ "/blog/old-api-key-guide/" ]. Každá hodnota obsahuje úvodní a koncové lomítko a musí být na webu jedinečná.
• Povinné? — Volitelné pro novou stránku; povinné, když se publikovaná stránka přesouvá z cesty, kterou web kontroloval.
• Limity — Zahrňte každou známou dřívější first-party cestu, která stále dostává odkazy nebo návštěvnost. Nepřidávejte spekulativní varianty pravopisu nebo neomezený seznam URL s klíčovými slovy.
• Kdo nebo co ho spotřebovává — Výstup aliasů Hugo, zpracování přesměrování při nasazení, migrační QA, monitory odkazů a uživatelé následující staré URL. Protože Hugo může emitovat alias stránku namísto HTTP přesměrování na úrovni serveru, chování při nasazení musí být ověřeno, nikoli předpokládáno.
• Pravidla — Přesunutá stránka udržuje svou starou cestu funkční. Každý alias musí vyřešit v jednom kroku na aktuální canonical cestu. Aktualizujte interní odkazy na novou URL, i když alias funguje, a zachovejte alias při pozdějších úpravách, pokud ho zdokumentovaný systém přesměrování nenahradí.
• Časté chyby — Smazání staré stránky bez aliasu, řetězení staré cesty na mezilehlou cestu na aktuální cestu, zacházení s aliasy jako s duplicitními publikačními cestami, směřování několika nesouvisejících stránek na jedno pohodlné místo nebo předpoklad, že lokální Hugo výstup dokazuje produkční HTTP status.

type a layout

• Účel — Tato pole vybírají renderovací kontrakt. type umísťuje stránku do třídy obsahu se sdílenými šablonami a chováním; layout požaduje konkrétní šablonu v rámci této třídy. Správný výběr zajišťuje, že stránka obdrží zamýšlenou navigaci, obsahový slot, assety a schema chování.
• Typ a formát — Malými písmeny registrované řetězce. Tato stránka používá type = "academy". Hodnota layout je základní název šablony jako single, bez přípony souboru nebo procházení cest.
• Povinné? — type je povinný, když umístění obsahu bezpečně neimplikuje zamýšlený typ nebo když to kontrakt playbooku vyžaduje. layout je volitelný a měl by být vynechán, když je výchozí šablona typu správná.
• Limity — Jedna hodnota pro každé pole, vybraná pouze ze šablon udržovaných webem. Nová hodnota je technická změna, nikoli redakční improvizace.
• Kdo nebo co ho spotřebovává — Vyhledávací pořadí Hugo, šablony, výběr partials, zahrnutí CSS a JavaScriptu, schema adaptéry a validační pravidla.
• Pravidla — Zvolte typ příspěvku a renderovací kontrakt před psaním. Používejte layout pouze pro skutečnou podporovanou variantu; nepoužívejte ho ke kompenzaci obsahu, který patří do jiného type. Ověřte, že přepis existuje a přijímá tvar frontmatter stránky.
• Časté chyby — Zaměňování redakčního entity s Hugo type, pojmenování souboru šablony, který neexistuje, kopírování typu vstupní stránky na akademický dokument, spoléhání se na odvození složky během migrace a zavádění jednorázových názvů layoutů, které obcházejí sdílená vylepšení.

Objevování

description

• Účel — Popis pomáhá kvalifikovanému vyhledávači nebo příjemci sdílení rozhodnout, zda tato stránka odpovídá na jeho potřebu. Je to náhledový text, nikoli zhutněný úvod a ne místo pro prokazování relevance opakováním.
• Typ a formát — Jedna věta v prostém textu. Měla by přirozeně pojmenovat primární termín, uvést konkrétní hodnotu a přidat užitečný rozsah, cílové publikum, metodu nebo výsledek.
• Povinné? — Povinné pro každou indexovatelnou stránku v tomto playbooku.
• Limity — 150–160 znaků včetně mezer. Toto je redakční konzistenční pásmo, nikoli záruka zobrazení: vyhledávače ho mohou zkrátit nebo přepsat úryvek z těla stránky, když jiná pasáž lépe odpovídá dotazu.
• Kdo nebo co ho spotřebovává — Meta description tagy, výchozí popisy Open Graph a Twitter, výpisové karty, feedy, CMS náhledy, kontroly kvality vyhledávání a někdy schema description.
• Pravidla — Pište pro kliknutí od správného čtenáře. Udělejte větu dostatečně konkrétní, aby odlišila stránku od jiného výsledku s podobným názvem. Sekce Pravidla pro popis níže uvádí zdůvodnění a testy zamítnutí.
• Časté chyby — Duplikování názvu, výčet klíčových slov, začínání větou „Naučte se vše o", nepodložené tvrzení o nejlepším nebo nejrychlejším, vágní výzva k akci, překročení pásma neviditelnou příponou značky nebo předpoklad, že autorův text se musí objevit doslovně ve výsledcích vyhledávání.

keywords

• Účel — V tomto repozitáři keywords zaznamenává kompaktní sadu dotazů a terminologie používanou pro redakční QA, vyhledávání v korpusu, analýzu pokrytí a interní nástroje. Pomáhá editorům rozpoznat jazyk, který stránka musí používat přesně; není to příslib zahrnout každou frázi mechanicky.
• Typ a formát — Pole řetězců v přirozeném jazyce, seřazené od primárního termínu přes smysluplné varianty a úzce související terminologii.
• Povinné? — Povinné podle tohoto playbooku, včetně stránek, jejichž veřejné šablony hodnoty nerenderují.
• Limity — Šest až osm odlišných položek. Každá položka musí představovat skutečnou dotazovou frázi nebo nezbytný termín, nikoli variantu na úrovni tokenů.
• Kdo nebo co ho spotřebovává — Redakční validátory, inventáře obsahu, analýza vyhledávání a příležitostí, interní vyhledávání a migrační nástroje. Veřejné vyhledávače nepoužívají toto pole jako signál hodnocení jen proto, že existuje.
• Pravidla — Udržujte sadu zaměřenou na rozsah jedné stránky. Slučte duplicity ve velikosti písmen, interpunkci, jednotném/množném čísle a triviálním pořadí slov. Používejte fráze ke kontrole pokrytí a terminologie, nikdy k diktování nepřirozené hustoty.
• Časté chyby — Zacházení s polem jako s mechanismem hodnocení meta-keywords, přidávání desítek variant, opakování názvu jako osmi téměř duplicit, vkládání jmen konkurentů, které tělo nezmíňuje, a umožnění pole nahradit řádnou taxonomii nebo cíle promptů.

targetPrompts

• Účel — targetPrompts zaznamenává úplné otázky nebo požadavky, které může osoba zadat AI systému a pro které by tato stránka měla být užitečným zdrojem. Cílové prompty zachovávají konverzační kontext, který krátké klíčové fráze vynechávají.
• Typ a formát — Pole úplných řetězců v přirozeném jazyce, například targetPrompts = [ "How do I rotate an API key without downtime?", "What should I check before revoking an old API key?" ]. Udržujte znění tak, jak by se uživatel ptal, včetně publika, omezení nebo požadovaného srovnání.
• Povinné? — Podmíněné pro stránky zahrnuté do sledování promptů nebo programu AI viditelnosti obsahu; volitelné, když neexistuje žádná sledovaná sada promptů.
• Limity — Používejte malou, záměrnou sadu, obvykle jeden primární prompt a až čtyři smysluplné varianty. Prompt může být delší než klíčové slovo, protože jeho kvalifikátory nesou záměr.
• Kdo nebo co ho spotřebovává — Zadání obsahu, workflow sledování promptů, audity vyhledávání a pokrytí, monitorování AI odpovědí a redakční hodnocení. Není renderován jako skrytý vyhledávací text.
• Pravidla — Oddělujte prompty podle skutečné informační potřeby, nikoli podle interpunkce. Klíčové slovo jako „rotace API klíče" pojmenovává téma; „Jak může tým SaaS rotovat API klíč bez přerušení integrací?" pojmenovává publikum, úkol a omezení. Stránka musí na každý uložený prompt poctivě odpovědět.
• Časté chyby — Kopírování pole keywords do tohoto pole, vytváření desítek syntaktických variant, zaznamenávání promptů širších než stránka, používání promptů jako nadpisů těla bez ohledu na tok čtení a tvrzení o pokrytí promptů, když odpověď závisí na informacích, které stránka neposkytuje.

Důvěra a původ

date a updated

• Účel — date uchovává, kdy byla stránka poprvé publikována; updated vykazuje poslední věcnou změnu nebo dokončený přezkum. Dvě pole zachovávají historii a zároveň ukazují, zda se změnily informace, na které se čtenáři spoléhají.
• Typ a formát — Časové řetězce v konvenci webu, YYYY-MM-DD HH:MM:SS. Udržujte jednu časovou zónu napříč korpusem, aby feedy a srovnání zůstaly deterministické.
• Povinné? — date je povinné pro publikované redakční stránky. updated je volitelné, dokud nenastane kvalifikující změna, pak povinné, pokud stránka zobrazuje datum změny.
• Limity — Jedna hodnota každé. updated nesmí předcházet date ani být v budoucnosti. Oprava provedená minuty po publikaci může být stále zdokumentována, ale běžné revize konceptu před publikací nevytvářejí datum aktualizace.
• Kdo nebo co ho spotřebovává — Viditelné popisky a značky aktuálnosti, feedy, sitemapy, schema datePublished a dateModified, audity aktuálnosti, řazení a redakční fronty.
• Pravidla — Resetujte updated pro faktickou opravu, změněnou instrukci, nový nebo odstraněný důkaz, revidovaný rozsah, podstatně změněné doporučení nebo zdokumentovaný přezkum časově citlivých tvrzení. Nikdy ho neresetujte pro interpunkci, formátování, práci na šabloně nebo úpravu pouze časového razítka. Viz Data, autoři a recenzenti pro zdůvodnění politiky.
• Časté chyby — Přepsání původního data při obnově, budoucí datování stránky, aby vypadala čerstvě, navyšování dat bez rozdílu v obsahu, zacházení s automatickým nasazením jako s redakční aktualizací a nezaznamenání toho, co se změnilo v udržované historii aktualizací.

author

• Účel — author spojuje dokument s odpovědnou osobou, která je za jeho práci zodpovědná. Toto propojení dává čtenáři a stroji cestu od stránky s tvrzeními k udržované identitě, odbornosti a dalším pracím.
• Typ a formát — Stabilní identifikátor autora, který se přes autorizovaný registr webu vyřeší na URL profilu a Person záznam. Například author = "maya-chen" je platné pouze tehdy, pokud se tento identifikátor vyřeší; zobrazované jméno jako "Maya Chen, SEO Expert" není náhradou za entitní propojení.
• Povinné? — Povinné pro věcné redakční stránky. Transakční stránky mohou používat řízeného organizačního vlastníka pouze tehdy, když šablona a politika podporují tento typ entity.
• Limity — Standardně jeden odpovědný vedoucí; používejte zdokumentované pole identifikátorů pouze tehdy, když schema a šablony popisků podporují skutečné spoluautorství.
• Kdo nebo co ho spotřebovává — Viditelné popisky, odkazy na profil autora, Article schema, feedy, reporty redakčního vlastnictví, workflow recenzí a entity grafy.
• Pravidla — Vyřešte identifikátor před publikací. Profil musí identifikovat stejnou osobu zobrazenou v popisku a zůstat udržovaný. Připište zásluhy osobě, která je za obsah odpovědná, nikoli osobě, která ho pouze nahrála.
• Časté chyby — Zadání nepropojeného jmenného řetězce, použití „Admin" nebo vymyšleného redakčního týmu, přiřazení výkonného manažera, který práci nevykonal, umožnění identifikátoru vyřešit se na žádný profil a změna autorství k naznačení odbornosti, která nebyla zapojena.

reviewedBy, reviewedAt a reviewScope

• Účel — Tato pole zaznamenávají nezávislý přezkum odlišný od autorství. reviewedBy identifikuje recenzenta; reviewedAt uvádí, kdy byl přezkum dokončen; reviewScope říká, co recenzent kontroloval, aby odznak neimplikoval schválení nad rámec důkazů.
• Typ a formát — reviewedBy je stabilní identifikátor vyřešitelný na udržovaný profil osoby. reviewedAt používá formát časového razítka webu. reviewScope je stručné prohlášení v prostém textu jako „Kroky rotace pověření a bezpečnostní upozornění."
• Povinné? — Podmíněné, když zákon, politika rizik, citlivost tématu nebo specifikace typu příspěvku vyžaduje nezávislý přezkum. Když je reviewedBy přítomno, datum a rozsah recenze jsou vyžadovány jako data recenzního záznamu, i když konkrétní šablona ukládá v propojeném redakčním záznamu namísto veřejného frontmatter.
• Limity — Jmenujte pouze skutečné recenzenty. Rozsah by měl být dostatečně specifický, aby odhalil výjimky, aniž by se stal recenzní zprávou. Recenzent musí mít relevantní kompetenci a nesmí jednoduše duplikovat roli autora.
• Kdo nebo co ho spotřebovává — Komponenty recenzováno, propojení entit osob, audity správy, brány publikace s vysokým rizikem, strukturovaný původ a protokoly aktualizací.
• Pravidla — Dokončete recenzi poté, co je obsah stabilní, zachyťte zjištění a řešení v redakční historii a znovu recenzujte, když pozdější změny ovlivní recenzovaný rozsah. Nezávislý znamená, že recenzent testuje práci, nikoli schvaluje vlastní návrh.
• Časté chyby — Zacházení s korekturou jako s odbornou recenzí, zobrazení recenzenta bez data nebo rozsahu, jmenování někoho, kdo nikdy neviděl finální verzi, ponechání odznaku po věcném nerecenzovaném přepsání a implikování právního, lékařského nebo technického schválení mimo uvedený rozsah.

Média a sociální sítě

image a imageAlt

• Účel — image vybírá reprezentativní hero a sociální asset; imageAlt poskytuje funkční textovou alternativu, když je tento asset renderován jako smysluplný obsah stránky. Udržování páru pohromadě zabraňuje tomu, aby se z obrázku pro objevování stalo opomenutí přístupnosti.
• Typ a formát — image je vyřešitelná cesta webu nebo schválená absolutní URL. imageAlt je prostý text popisující užitečné informace obrázku v kontextu stránky, nikoli jeho název souboru nebo cílové klíčové slovo.
• Povinné? — Podmíněné typem příspěvku a šablonou. Pokud stránka vyžaduje hero nebo dedikovaný sociální obrázek, image je povinný. imageAlt je povinný, kdykoli se tento obrázek renderuje informativně; čistě dekorativní renderování musí v šabloně používat prázdný alt atribut, nikoli vymyšlený popisný text.
• Limity — Použijte jeden reprezentativní asset. Pro sociální kompatibilitu poskytněte zdroj 1200 × 6 pixelů v očekávaném poměru oříznutí, udržujte důležitý obsah mimo okraje a imageAlt udržujte stručný – obvykle 5–160 znaků. Soubor musí existovat před tím, než je na něj odkazováno.
• Kdo nebo co ho spotřebovává — Hero komponenty, výpisové karty, Open Graph a Twitter tagy, schema image pole, feedy, obrazové pipeline, screen readery, když je viditelný, a QA assetů.
• Pravidla — Vyberte obrázek, který stále komunikuje po středovém oříznutí a v miniaturní velikosti. Popište jeho funkci v kontextu: „Nastavení API klíče s zvýrazněnou akcí Rotate key" je užitečné; „API klíč" není. Nevkládejte podstatná tvrzení pouze do pixelů.
• Časté chyby — Odkazování na plánovaný asset, který neexistuje, použití loga jako každého obrázku článku, vložení malého textu, který se stane nečitelným při sdílení, psaní „obrázek", vkládání klíčových slov do alt textu a předpoklad, že sociální alt text a alt chování viditelného obrázku jsou identické napříč platformami.

Open Graph a Twitter card pole

• Účel — Sociální metadata řídí, jak je URL shrnuta při sdílení. Konzistentní název, popis, URL, typ a obrázek pomáhají příjemcům rozpoznat stránku před kliknutím a snižují šanci, že platforma vybere irelevantní asset.
• Typ a formát — V tomto repozitáři šablony odvozují og:title a twitter:title z title, popisy z description, URL z permalinku, og:type z kontextu layoutu a oba obrázkové tagy z image s fallbackem webu. twitter:card je emitován jako summary_large_image. Toto jsou generované tagy, nikoli duplicitní pole frontmatter standardně.
• Povinné? — Výstupní tagy jsou povinné na veřejných stránkách. Samostatné přepisy jsou volitelné a měly by být zavedeny pouze prostřednictvím zdokumentovaného kontraktu šablony; nepodporovaná ad hoc pole jako ogTitle nic nedělají.
• Limity — Jeden koherentní náhled na stránku a jeden reprezentativní obrázek 1200 × 6. Udržujte odvozené znění v pásmech názvu a popisu, pak otestujte skutečné oříznutí a chování překryvů na hlavních sdílecích platformách.
• Kdo nebo co ho spotřebovává — Sociální sítě, klienti pro zasílání zpráv, unfurlery odkazů, rozšíření prohlížeče, nástroje pro spolupráci a debuggery náhledů sdílení.
• Pravidla — Preferujte odvození, aby vyhledávací a sociální tvrzení zůstala v souladu. Přepište pouze tehdy, když sociální kontext skutečně potřebuje jiné zarámování a šablona to podporuje. Špatný obrázek stojí rozpoznání a důvěru: příjemce může vidět zastaralé rozhraní, jiný produkt, zavádějící tvrzení nebo oříznutí, které skrývá předmět.
• Časté chyby — Vytváření polí, která žádná šablona nečte, umožnění globálnímu fallbacku maskovat chybějící povinný hero obrázek, použití portrétu nebo malého obrázku pro širokou kartu, změna sociálního textu k silnějšímu příslibu než stránka a validace pouze HTML zdroje namísto načteného náhledu.

Klasifikace

taxonomy, categories a tags

• Účel — Klasifikace připojuje stránku k řízeným kolekcím témat, formátů, publika nebo produktů. Umožňuje užitečné archivy a filtry pouze tehdy, když má každý slovník deklarovaný význam; jinak se štítky stanou nekontrolovanou hromadou synonym.
• Typ a formát — Pole registrovaných slugů malými písmeny. Použijte taxonomy pro řízený tematický slovník repozitáře. Použijte categories pouze pro malou vzájemně srozumitelnou redakční hierarchii a tags pouze pro řízený průřezový slovník, když jsou tyto taxonomie nakonfigurovány.
• Povinné? — Podmíněné typem příspěvku a návrhem archivu. Tématické redakční stránky obvykle vyžadují jeden nebo více řízených termínů; utilitní stránky nemusí vyžadovat žádný. Pole nesmí být vyplněno jen proto, že ho CMS vystavuje.
• Limity — Pro obecnou taxonomii jedna až pět hodnot na řízený slovník. Každý termín potřebuje definici, vlastníka a pravidlo slučování. Vytvořte indexovatelný archiv pouze tehdy, když termín představuje trvalou čtenářskou poptávku a archiv může nabídnout jedinečný úvod, koherentní inventář, interní odkazy a průběžnou údržbu.
• Kdo nebo co ho spotřebovává — Archivní stránky, breadcrumbs, filtry, systémy souvisejícího obsahu, fasetová navigace, audity obsahu a segmentace analytiky.
• Pravidla — Zvolte nejužší registrovaný termín, který přesně seskupuje stránku. Udržujte jednotné/ množné číslo, zkratky a varianty pravopisu mapované na jednu kanonickou hodnotu. Rozhodněte, zda archivy jsou indexovatelné na úrovni slovníku, ne tag po tagu po náhodném vytvoření.
• Časté chyby — Použití seo, SEO, search-optimization a search engine optimization jako samostatných hodnot, přidávání jednorázových tagů k popisu každého podstatného jména, záměna obchodního typu s tématem, generování tenkých indexovatelných archivů a mazání termínů bez migrace jejich členů.

Klíče propojení playbooku

• Účel — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage a amicitedFeatures jsou typované klíče propojení. Umožňují jedné zdrojové stránce objevit se v generovaných knihovnách a maticích, aniž by editoři ručně kopírovali karty. Tato stránka je pracovním příkladem: její pilíř identifikuje prvek, její rodina seskupuje metadata guideliny a její pole postTypes deklaruje specifikace, které ji spotřebovávají.
• Typ a formát — Jednotlivé klíče používají registrované slugy malými písmeny: playbookPillar a playbookFamily jsou řetězce, playbookWave je celé číslo a journeyStage je řízený řetězec. Vztahové klíče — postTypes, elements, businessTypes a amicitedFeatures — jsou pole registrovaných slugů z jejich příslušných registrů.
• Povinné? — playbookPillar a playbookWave jsou povinné na záznamech playbooku. playbookFamily je povinný tam, kde má pilíř řízené rodiny. Pole propojení a journeyStage jsou podmíněné: vyplňte pouze vztahy, které kontrakt stránky skutečně podporuje.
• Limity — Jeden pilíř, jedna rodina v rámci pilíře, jedna vlna a jedna fáze cesty, pokud model explicitně nepovoluje více fází. Pole obsahují unikátní registrované klíče, nikoli zobrazované popisky, text nebo URL.
• Kdo nebo co ho spotřebovává — Výpisy hubu playbooku, mezipilířové matice, filtry, vztahové karty, reporty úplnosti, pohledy podle vln a interní nástroje, které hledají relevantní schopnosti AmICited.
• Pravidla — Validujte každou hodnotu proti kanonickému registru. Směr záleží: stránka typu příspěvku uvádí své požadované elements; stránka prvku uvádí použitelné postTypes; stránka obchodního typu uvádí užitečné typy příspěvků. Na popisky pohlížejte jako na prezentaci a na klíče jako na trvalá data. Přejmenujte klíč pouze prostřednictvím migrace, která aktualizuje každou stranu propojení.
• Časté chyby — Vymýšlení téměř synonym, ukládání názvů místo slugů, míchání celých čísel a řetězců pro vlny, přidávání vztahu, protože se dvě stránky zmiňují, umožnění vzájemným polím si odporovat a vytváření ručně udržovaného markupu výpisů, který se odchyluje od metadat.

Odvozená a strukturální pole

schemaType

• Účel — schemaType vybírá nejkonkrétnější podporované mapování strukturovaných dat, které přesně popisuje viditelnou stránku. Říká schema adaptéru, který slovníkový kontrakt použít; neproměňuje stránku v danou věc pouhým prohlášením.
• Typ a formát — Jeden registrovaný název typu Schema.org jako Article, vybraný z typů, které webový adaptér podporuje. Velikost písmen a pravopis musí odpovídat registru.
• Povinné? — Podmíněné. Nastavte ho tam, kde je pro stejný Hugo typ platných více mapování schema nebo kde kontrakt typu příspěvku vyžaduje explicitní typ. Jinak nechte šablonu odvodit bezpečnou výchozí hodnotu.
• Limity — Jeden primární typ stránky, s vnořenými entitami vytvořenými adaptérem ze skutečného obsahu. Vybraný typ musí splňovat všechny požadované vlastnosti a odpovídat tomu, co čtenář vidí.
• Kdo nebo co ho spotřebovává — JSON-LD adaptéry, validace rich results, QA obsahu a reporty inventáře schema.
• Pravidla — Vybírejte podle funkce stránky a viditelných důkazů, nikoli podle vyhledávací funkce, kterou si editor přeje. Stránka s návodem bez úplného viditelného postupu nemůže získat přesnost nastavením typu how-to. Udržujte schema URL, data, osoby a obrázky synchronizované s jejich zdrojovými poli.
• Časté chyby — Výběr specifičtějšího typu bez jeho požadovaného obsahu, emitování několika konfliktních primárních typů, kopírování hodnoty schema z nesouvisející šablony, předpoklad, že platná syntaxe zaručuje způsobilost, a vkládání tvrzení do JSON-LD, která čtenáři nemohou zkontrolovat.

Doba čtení

• Účel — Doba čtení dává čtenáři hrubý odhad úsilí. Je odvozena z finálního renderovatelného těla, takže odhad se mění, když se mění skutečná čtecí zátěž.
• Typ a formát — Vypočítané celé číslo minut vytvořené z politiky počtu slov obsahového pipeline. Kódové bloky, tabulky, titulky a vložená média by měly následovat jedno zdokumentované pravidlo počítání.
• Povinné? — Zobrazení je volitelné podle šablony. Autorové pole frontmatter není povoleno jako zdroj pravdy.
• Limity — Zaokrouhlujte konzistentně a aplikujte rozumný minimální zobrazovaný údaj, například jednu minutu. Přesný předpoklad slov za minutu je méně důležitý než použití stejné metody na celém webu a označení výsledku jako odhadu.
• Kdo nebo co ho spotřebovává — Hlavičky stránek, karty, feedy, segmentace analytiky a čtenáři rozhodující se, zda začít dlouhého průvodce.
• Pravidla — Počítejte po zpracování shortcodes a vyloučených oblastí podle politiky webu. Přepočítávejte při každém sestavení. Pokud video nebo interaktivní úkol podstatně mění čas dokončení, označte to samostatně, namísto narušení doby čtení.
• Časté chyby — Uvedení readingTime = 8, zapomenutí aktualizace po přepsání, prezentování falešné přesnosti, počítání navigace a boilerplate a zacházení s návodem náročným na provedení jako s osmi minutami čtení plus žádný čas na úkol.

[[faq]]

• Účel — [[faq]] ukládá viditelné páry otázek a odpovědí jednou, aby stránka a případná strukturovaná data FAQ nemohly driftovat od sebe.
• Typ a formát — TOML pole tabulek; každá položka obsahuje jeden question v prostém textu a jeden samostatný řetězec answer.
• Povinné? — Podmíněné, když po hlavní stránce zůstávají skutečné doplňující otázky. Nikdy není povinné pouze k vyplnění šablony nebo dosažení vyhledávací funkce.
• Limity — Obvykle čtyři až osm užitečných položek na stránkách playbooku. Každá otázka se objeví jednou a každá odpověď musí být úplná bez spoléhání se na pořadí accordionu.
• Kdo nebo co ho spotřebovává — Viditelné renderování FAQ, FAQPage schema, pokud je způsobilé, navigace stránky, QA obsahu a extrakce odpovědí.
• Pravidla — Toto je cross-reference kontrakt: postupujte podle Proč FAQ žije ve frontmatter a pozdějšího FAQ guidelinu namísto udržování samostatných viditelných a schema kopií. Ukládejte pouze otázky, ke kterým má každý čtenář na stránce přístup.
• Časté chyby — Skryté odpovědi pouze pro schema, duplicitní nadpisy maskované jako otázky, propagační odpovědi, nepodložená tvrzení, zastaralé JSON-LD a zacházení se způsobilostí ve výsledcích vyhledávání jako s garantovanou.

[[lnks]]

• Účel — [[lnks]] zaznamenává každý řízený interní odkaz použitý v těle, páruje jeho viditelnou kotvu s cílem a udržovaným popisem. Záznam umožňuje kontrolovat odkazy bez scrapování renderovaného HTML a podporuje migraci a QA.
• Typ a formát — TOML pole tabulek s text, path a title. text je přesná viditelná kotva, path je URL relativní k webu s úvodním a koncovým lomítkem a title je popis cílové stránky.
• Povinné? — Povinné pro každý interní odkaz v těle řízený touto obsahovou konvencí. Hluboké odkazy v aplikacích a externí zdroje následují své vlastní záznamy a nejsou maskovány jako položky [[lnks]].
• Limity — Jeden záznam na výskyt odkazu v těle, když stejná kotva může směřovat na různé cíle; jinak by měly být přesné duplicitní záznamy odstraněny. Cíl musí existovat nebo být ve schváleném kanonickém registru slugů pro koordinované vydání.
• Kdo nebo co ho spotřebovává — Validace interních odkazů, migrace obsahu, analýza vztahů, generování názvů odkazů, pokud je podporováno, a redakční přezkum.
• Pravidla — Přiřaďte text ke kotvě v těle doslovně, včetně velikosti písmen a interpunkce uvnitř odkazu. Použijte kanonickou cestu relativní k webu. Pište title jako přesný popis cíle, nikoli jako instrukce pro aktuální stránku. Aktualizujte záznam a tělo společně.
• Časté chyby — Použití delší hodnoty text, než je skutečná kotva, vymýšlení neregistrovaného slugu, vynechání koncového lomítka, zaznamenávání staré přesměrovávací cesty, popis zdroje namísto cíle a ponechání záznamu po odstranění jeho odkazu v těle.

Povinné versus volitelné podle typu příspěvku

Matice aplikuje výše uvedené kontrakty na dvanáct typů příspěvků aktuálně deklarovaných tímto prvkem. R znamená povinné, C znamená podmíněné podle pravidel polí, D znamená povinný výstup, který může být bezpečně odvozen, a O znamená volitelné. „Identita" zahrnuje entity, id, title, type a stabilní cestu. „Objevování" zahrnuje description a keywords; cílové prompty zůstávají podmíněné pro každý řádek. aliases je vždy podmíněné přesunem, zatímco autorova doba čtení není nikdy povinná.

„Podmíněný recenzent" není svolení vynechat recenzi tam, kde to vyžaduje přesnost nebo obchodní riziko. Stránky nejlepší X a alternativ vyžadují nezávislý přezkum, protože jejich doporučení mohou podstatně ovlivnit rozhodnutí a často se mění s produkty, cenami a způsobilostí. Pro ostatní řádky aktivuje požadavek politika rizik, nikoli dostupný čas editora. Stejně tak canonical označený D je stále vyžadován v renderovaném HTML; pouze vstup frontmatter může být vynechán, když šablona může vygenerovat správnou self-reference.

Validace frontmatter

Validace by měla automaticky zamítat deterministické vady a ponechat posouzení otázkám závislým na významu, důkazech nebo odborné způsobilosti. Toto rozdělení zabraňuje dvěma opačným selháním: žádání recenzentů, aby chytali syntaxi, kterou parser chytí dokonale, a předstírání, že pravidlo počtu znaků může rozhodnout, zda je text poctivý.

Spouštějte deterministické kontroly před redakčním přezkumem, aby recenzent viděl koherentní záznam. Pak kontrolujte renderované HTML, nikoli pouze frontmatter: platná zdrojová hodnota je stále produkční vadou, pokud ji vybraná šablona ignoruje, mapuje na nesprávný tag, skrývá požadovaný původ nebo generuje canonical, který nesouhlasí s veřejnou cestou. Publikace je dokončena pouze tehdy, když se zdroj, render a chování cíle shodují.

Pole entity

entity odpovídá na otázku „jakého přesného typu příspěvku je tento dokument instancí?" Neodpovídá na otázku „jaké téma tato stránka popisuje?" Tento rozdíl je důležitý, protože dva dokumenty mohou popisovat stejné téma, ale dělat různé úkoly. Glosářová položka definuje „diagnózu"; blogový článek může reportovat změnu v diagnostickém vedení. Pokud oba použijí entity = "diagnosis", downstream systémy nemohou spolehlivě vybrat správnou šablonu, validační pravidla, analytickou skupinu nebo migraci.

Použijte prefix skupiny plus slug typu příspěvku pro varianty v rámci rodiny: guide-how-to, guide-ultimate, comparison-a-vs-b a comparison-alternatives-to-x. Použijte holý název pro samostatný typ: product-page nebo case-study. Zaregistrujte identifikátor jednou, udržujte ho stabilní a nikdy ho neměňte, protože se změní téma nebo cílový dotaz. Vložte koncepty tématu do taxonomy a jazyk dotazů do keywords.

Název, H1 a SEO název

Tyto hodnoty se mohou lišit podle kontextu, ale musí popisovat stejnou stránku. title je trvalá výchozí hodnota. h1 je viditelný nadpis a může být v kontextu přirozenější. seoTitle slouží prohlížeči a výsledkům vyhledávání a může přidat stručný rozlišovač, legitimní rok nebo příponu značky.

Například title = "API Key Rotation", h1 = "How to Rotate an API Key Without Downtime" a seoTitle = "API Key Rotation: Safe Step-by-Step Guide" se shodují na jednom úkolu. „Free Security Tool" jako SEO název by byl klamavý, protože mění příslib. Nevytvářejte rozdíly pouze za účelem vložení více klíčových slov.

Pravidla pro popis

Popis existuje, aby pomohl kvalifikovanému čtenáři rozhodnout se kliknout. Udržujte ho v rozmezí 150–160 znaků, přirozeně zahrňte primární termín, uveďte konkrétní přínos stránky a přidejte smysluplný kvalifikátor, jako je publikum, rozsah nebo výsledek. Napište jednu plynulou větu, nikoli seznam klíčových slov.

Termín potvrzuje relevanci; opakování nepřidává hodnotu. Neduplikujte název, nepoužívejte „Naučte se vše o", nedělejte nepodložené superlativy a nekončete uprostřed myšlenky. Vyhledávací systémy mohou stále pro daný dotaz vybrat jiný viditelný text.

Data, autoři a recenzenti

date uchovává časové razítko prvního publikování. updated zaznamenává poslední věcnou změnu: faktickou opravu, nový důkaz, změněné instrukce, revidovaný rozsah, změněné doporučení nebo úplný přezkum, který potvrzuje časově citlivá tvrzení. Zaznamenejte, co se změnilo v redakční historii, když to politika vyžaduje.

Oprava interpunkce, změna stylu tlačítka, přestavba šablony nebo dotyk samotného časového razítka neresetuje updated. Posunutí data bez práce za ním je porušením politiky, protože říká čtenářům a strojům, že obsah byl obnoven, když nebyl. Je to zkreslování, nikoli růstová taktika.

Pole autora a recenzenta nesou odpovědné identity do popisků a strukturovaných dat. Autor je zodpovědný za práci. Použijte reviewedBy pouze tehdy, když proběhla kvalifikovaná recenze, a propojte oba identifikátory s udržovanými profily. Stránka o základech důvěry vysvětluje, jak autorství, data, důkazy a srozumitelnost entit podporují důvěru bez záruky pořadí.

Proč FAQ žije ve frontmatter

FAQ je viditelný obsah a strukturovaná kolekce. Uložení jednou v [[faq]] umožňuje šabloně renderovat accordion a identické FAQPage JSON-LD, čímž se zabrání zastaralému skrytému schematu.

Zahrňte skutečné doplňující otázky viditelné pro každého čtenáře. Neduplikujte nadpisy, neschovávejte propagace v odpovědích ani neoznačujte nezobrazené otázky. Platný markup nezaručuje vyhledávací funkci.

Syntaxe a příklady kódu

Meziplatformní kontrakt mapuje pole, nikoli viditelnou komponentu. Následující přenosná obálka je platná pouze v inter-change souboru, jehož importér rozpoznává metadata direktivy:

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

Musí být během importu normalizována do nativních metadat stránky. Není platná v těle produkčního článku. V Hugo je správné mapování TOML mezi +++ ohraničeními na prvním bajtu, jak je ukázáno v živém vzorku. Záměrně neexistuje žádný {{< frontmatter >}} shortcode: shortcode by běžel příliš pozdě a v nesprávné oblasti dokumentu.

Ve WordPress mapujte stejná kanonická pole na registrovaná post pole a post meta, například post_title, post_excerpt, post_name, _amicited_entity, _amicited_author a _amicited_reviewed_by. Komentář jako <!-- wp:amicited/frontmatter --> nebo shortcode [frontmatter] je neplatný, protože vytváří blok v těle namísto metadat dokumentu. Importéři a editoři mohou zobrazit panel metadat, ale uložené hodnoty musí zůstat připojené k záznamu příspěvku.

Příklady

Dobrý: jeden koherentní, odpovědný záznam

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

Toto identifikuje variantu návodu, uchovává historii, jmenuje odpovědné osoby a odděluje téma od identity stránky. Časové razítko aktualizace je podloženo zdokumentovanou změnou instrukcí a recenzí.

Špatný: název zopakovaný jako popis

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

Popis nepřidává žádný přínos, rozsah ani důvod ke kliknutí. Také plýtvá prostorem náhledu, který by mohl odlišit tuto stránku od každého jiného výsledku používajícího stejný název.

Špatný: jedna entita znovu použitá pro dva typy příspěvků

# glosářová položka
entity = "diagnosis"

# redakční průvodce
entity = "diagnosis"

Sdílené téma nahradilo identitu typu příspěvku. Použijte registrované hodnoty jako glossary-term a guide-ultimate, pak přiřaďte „diagnosis" prostřednictvím taxonomie nebo klíčových slov.

Špatný: aktualizované datum bez rozdílu v obsahu

date = "2026-01-15 09:00:00"
updated = "2026-08-27 10:00:00" # změnilo se pouze datum

Žádná věcná úprava nebo recenze nepodporuje tvrzení o aktuálnosti. Ponechte updated nezměněné nebo vynechané, dokud neexistuje skutečná změna a nemůže být zkontrolována v redakční historii.

Schema markup a přístupnost

Metadata poskytují hodnoty; šablona zůstává zodpovědná za sémantické HTML, focus, kontrast, účel odkazu a alternativní text.

Pravidla psaní

• Udržujte identifikátory stabilní, malými písmeny a strojově bezpečné. Nikdy znovu nepoužívejte id nebo tiše neměňte entity po publikaci.
• Používejte prostý text v polích podobných názvu. HTML, Markdown odkazy, emoji dekorace a vynucené zalomení řádků nepatří do metadatových řetězců.
• Udržujte popis na 150–160 znacích a pole klíčových slov na šesti až osmi odlišných frázích pro tento playbook.
• Používejte skutečné registrované osoby pro pole autora a recenzenta. Nikdy nevytvářejte ceremoniálního recenzenta nebo generickou identitu „Redakční tým", pokud se nejedná o udržovanou odpovědnou entitu.
• Používejte řízenou taxonomii. Varianty pravopisu a duplicity jednotného/množného čísla vytvářejí fragmentované archivy.
• Odkazujte pouze na obrázky, které existují a mají publikační práva. imageAlt popisuje informativní obsah obrázku, nikoli jeho SEO cíl.
• Udržujte FAQ odpovědi přímé a samostatné. Tvrzení stále vyžadují stejné důkazy a zveřejnění jako próza jinde na stránce.
• Nikdy neumísťujte tajemství, soukromé poznámky, přístupové tokeny, instrukce o embargu, osobní data nebo nerecenzovaná právní tvrzení do publikovatelného frontmatter.

Které typy příspěvků používají frontmatter a kde

Každý typ příspěvku používá frontmatter na prvním bajtu. Požadovaná hloubka se mění s rizikem, záměrem a schematem, nikoli s vizuálním designem.

QA checklist

• Začíná soubor +++, obsahuje platný TOML a uzavírá záznam před obsahem těla?
• Je entity registrovaný přesný identifikátor typu příspěvku, nikoli téma, kampaň nebo název webu?
• Je id unikátní a stabilní a odpovídá url kanonickému registru slugů?
• Popisují title, volitelný h1 a volitelný seoTitle stejnou stránku bez klamavých změn rozsahu?
• Má popis 150–160 znaků, obsahuje přirozeně primární termín a nabízí konkrétní důvod ke kliknutí?
• Existuje každý odkazovaný obrázek a je imageAlt přesný pro obrázek, který se renderuje?
• Je datum publikace zachováno a je každá hodnota updated podložena věcným rozdílem nebo zdokumentovanou recenzí?
• Vyřeší se identifikátory autora a recenzenta na skutečné udržované profily a provedl jmenovaný recenzent skutečnou recenzi práce?
• Jsou klíčová slova omezena na šest až osm užitečných frází a hodnoty taxonomie čerpány z řízených slovníků?
• Používá canonical HTTPS, řeší se na preferovanou stránku a shoduje se s sitemap a interními odkazy?
• Obsahuje každá položka [[faq]] jednu užitečnou otázku a samostatnou odpověď, které se renderují viditelně v identickém znění?
• Odpovídá generované JSON-LD viditelnému obsahu, používá stabilní identifikátory a prochází syntaktickou validací bez tvrzení nepodporovaných typů?
• Jsou ze záznamu nepřítomna tajemství, soukromé redakční poznámky, nepodložená tvrzení a zveřejnění pouze v těle?

FAQ

Je frontmatter viditelný na publikované stránce?

Zdrojový záznam je skrytý, ale šablony mohou renderovat název, osoby, data a FAQ. Další pole napájejí náhledy, kanonické tagy, feedy, sitemapy, schema a interní systémy.

Má pole entity obsahovat téma nebo typ příspěvku?

Identifikuje přesný typ příspěvku. Sdílená témata patří do taxonomie a klíčových slov, ne na místo identity dokumentu.

Může se lišit název, H1 a SEO název?

Ano. H1 může znít přirozeněji a SEO název může přidat rozlišovač, ale všechny verze musí dávat stejný příslib.

Kdy by se mělo změnit datum aktualizace?

Změňte ho po věcném faktickém přezkumu nebo úpravě. Neměňte ho pro interpunkci, stylování, práci na šabloně nebo obnovu pouze data.

Proč jsou otázky FAQ uloženy ve frontmatter?

Strukturované pole umožňuje jednomu zdroji renderovat jak viditelné FAQ, tak odpovídající FAQPage JSON-LD. To zabraňuje odchýlení schema od toho, co čtenáři mohou zkontrolovat.