Content Frontmatter: Felder und SEO-Metadaten

Frontmatter ist das Seitenelement, das Leser nie als einen Block sehen und von dem jedes Veröffentlichungssystem abhängt. Es gibt einem Dokument eine Identität, einen Rendering-Vertrag, eine Suchvorschau, einen Eigentumsnachweis, Daten und Schema-Eingaben. Defektes Frontmatter kann die falsche Vorlage auswählen, kanonische Konflikte erzeugen, den Autor verlieren oder Markup erzeugen, das der Seite widerspricht.

Das Live-Beispiel ist ein dokumentenebenen-Eintrag, der als Code dargestellt wird, weil Frontmatter keine dekorative Body-Box werden darf.

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

Warum Frontmatter existiert

Für einen Leser reduziert Metadaten Unsicherheit. Ein präziser Titel setzt den Rahmen, eine nützliche Beschreibung verdient den Klick, Identitäten machen Behauptungen nachvollziehbar, und Daten zeigen, ob Informationen möglicherweise veraltet sind. Diese Signale können schwache Inhalte nicht ausgleichen, aber ihr Fehlen zwingt den Leser zum Raten.

Für Maschinen ersetzt Frontmatter Rückschlüsse durch benannte Werte. Vorlagen ordnen Felder Browsertiteln, kanonischen Links, Personeneinträgen, Daten, Feeds, Indizes und JSON-LD zu, ohne Prosa zu durchsuchen. Dies ist maschinelle Extrahierbarkeit: Wichtige Fakten haben einen konsistenten Ort und Typ.

Befolgen Sie die Element-Schreibregeln: Metadaten gehören auf Dokumentebene; leserorientierte Elemente gehören in den Body. Ein Autorenvermerk kann aus dem Frontmatter gerendert werden, aber seine autoritative Kennung bleibt dort.

Wann man es verwendet – und wann nicht

Jede indexierbare Seite benötigt einen Frontmatter-Eintrag für Identität, Rendering und Routing. Entwürfe benötigen ihn, sobald sie in die Produktion gehen, damit die Validierung früh fehlschlagen kann.

Verstecken Sie Artikel-Fakten nicht im Frontmatter. Produkteinschränkungen, Sicherheitswarnungen, Affiliate-Offenlegungen, Methoden und Quellen müssen dort sichtbar bleiben, wo Leser sie bewerten können. Ein strukturierter Wert ersetzt niemals eine Offenlegung.

Beinahe-Fehler verursachen den größten Schaden:

• Unabhängig voneinander variierende Navigationsbezeichnungen, Kampagnentexte und soziale Bildunterschriften sind Kanaleinstellungen; überladen Sie nicht den title.
• Organisationsfakten, die für die gesamte Website gelten, gehören in den Organisationsdatensatz der Website, nicht kopiert in jede Seite, wo sie auseinanderdriften.
• Ein Frage-und-Antwort-Bereich gehört nur dann in [[faq]], wenn derselbe Inhalt sichtbar gerendert wird. Verstecktes, reines Schema-FAQ ist ungültig.
• Eine Themenbezeichnung gehört in die taxonomy; sie darf nicht das entity ersetzen, das den Beitragstyp des Dokuments identifiziert.
• Eine Weiterleitung gehört in die Routing-Konfiguration oder ein genehmigtes Aliase-Feld. canonical identifiziert die bevorzugte Version; es leitet Besucher nicht weiter.

Wo es platziert wird

Frontmatter beginnt beim ersten Byte mit +++ und endet mit der passenden Begrenzung vor dem Body. Keine Überschrift, kein Kommentar, keine Notiz, kein Shortcode und kein Metadatenblock darf ihm vorausgehen. TOML-Felder und -Arrays gehören innerhalb dieses einen Eintrags.

Der Body beginnt nach der schließenden Begrenzung. Frontmatter kann nicht zwischen H1 und Einleitung, neben einem Screenshot, innerhalb einer Komponente oder am Ende sitzen. Ein Byte-Order-Mark oder ein versehentlicher Kommentar kann die Erkennung verhindern. Doppelte Schlüssel, YAML-Begrenzungen und zweite Blöcke sind ungültig.

Anatomie

Die gerenderte Legende bleibt auf der Seite, damit sie unabhängig vom Bild lesbar und übersetzbar bleibt:

1. Begrenzung: Die öffnenden und schließenden +++-Begrenzungen definieren den einzigen Metadatenbereich.
2. Identität: entity, id, type und url teilen Systemen mit, was das Dokument ist und wo es sich befindet.
3. Discovery: title, seoTitle, description, image, imageAlt und keywords unterstützen Vorschauen und Abruf.
4. Herkunft: date, updated, author und reviewedBy geben an, wer verantwortlich ist und wann die Arbeit gültig geändert wurde.
5. Klassifikation: taxonomy verbindet die Seite mit kontrollierten Themensammlungen, ohne ihre Identität neu zu definieren.
6. Duplikationskontrolle: canonical benennt die bevorzugte öffentliche URL, wenn gleichwertige Versionen an anderer Stelle erreichbar sind.
7. Strukturierte Sammlungen: Jeder [[faq]]-Eintrag erstellt einen typisierten Frage-und-Antwort-Eintrag für sichtbares Rendering und Schema.

Designbeispiele

Frontmatter hat Datenvertragsvarianten, keine visuellen Stile. Screenshots paarweise Quelleneinträge mit der daraus resultierenden Vorschau oder dem Autorenvermerk.

Parameter

Dies sind redaktionelle Grenzen, auch wenn ein Parser mehr akzeptiert. „Bedingt“ bedeutet erforderlich, wenn die angegebene Bedingung zutrifft.

Einzelfeld-Referenz

Diese Referenz definiert den Veröffentlichungsvertrag für jedes Feld. „Erforderlich“ bedeutet, dass die Validierung die Veröffentlichung stoppen sollte, wenn das Feld oder seine gültige Ableitung fehlt. „Bedingt“ bedeutet, dass die Anforderung durch eine angegebene Tatsache aktiviert wird, z. B. durch ein gerendertes Bild oder eine durchgeführte unabhängige Überprüfung. Ein Standardwert ist nur dann sicher, wenn er dieselbe Bedeutung erzeugt, die ein Redakteur bewusst gewählt hätte.

Identität und Routing

title, h1 und seoTitle

• Zweck — title gibt dem Dokument seinen dauerhaften redaktionellen Namen. h1 steuert die Hauptseitenüberschrift, wenn der Layoutkontext eine andere Formulierung erfordert. seoTitle steuert den Browser-/Suchtitel, wenn der Standard eine prägnante Qualifikation oder Markenbehandlung benötigt. Die Trennung verhindert, dass eine Navigationsbezeichnung, Seitenüberschrift und Suchvorschau in einen einzigen unpassenden String gezwungen werden.
• Typ und Format — Jedes ist ein Klartext-String. title ist der Quellwert; fehlende Überschreibungen müssen darauf zurückfallen. HTML, Markdown, Emoji-Dekoration und manuelle Kürzungszeichen sind keine gültigen Werte.
• Erforderlich? — title ist auf jeder öffentlichen Seite erforderlich. h1 und seoTitle sind optional und sollten weggelassen werden, wenn title in allen drei Kontexten funktioniert.
• Grenzen — Verwenden Sie 30–70 Zeichen für title, 20–80 für h1 und 30–60 für seoTitle als redaktionelle Bereiche, nicht als Zusicherung, dass eine Suchoberfläche jedes Zeichen anzeigt. Es muss eine gerenderte H1 geben.
• Wer oder was es verwendet — Seitenvorlagen, Browsertitel, Such- und Social-Adapter, Navigationskarten, Feeds, Schema headline, Barrierefreiheits-Gliederungen und redaktionelle Auflistungen.
• Regeln — Alle Versionen müssen dasselbe Subjekt, dieselbe Absicht und denselben Umfang identifizieren. Ein legitimer Unterschied löst eine Kanaleinschränkung: Die H1 könnte zum Beispiel „API-Schlüssel ohne Ausfallzeiten rotieren“ lauten, während der kürzere SEO-Titel „API-Schlüsselrotation: Sicherer Schritt-für-Schritt-Leitfaden“ heißt. Der spätere Abschnitt Titel, H1 und SEO-Titel erläutert den redaktionellen Test.
• Häufige Fehler — Wiederholen eines Keywords in allen drei Varianten, Einfügen eines Marken-Suffixes in die H1, Ändern des Versprechens, um Klicks zu jagen, Einbetten des aktuellen Jahres, wenn die Seite nicht jährlich gepflegt wird, oder Erstellen von drei Werten nur, weil drei Felder existieren.

slug und url

• Zweck — Der Slug ist das letzte Pfadsegment; url ist die site-relative öffentliche Route, die es enthält. Zusammen geben sie der Seite eine stabile Adresse für Leser, Crawler, Links, Berichte und Migrationen. Stabilität ist wichtig, weil jeder verdiente Link und jedes gespeicherte Lesezeichen von dieser Adresse abhängt.
• Typ und Format — Verwenden Sie einen kleingeschriebenen, durch Bindestriche getrennten Pfad-String wie /academy/rotate-an-api-key/. Dieses Repository zeichnet die vollständige Route in url auf; ein CMS, das ein separates slug-Feld hat, muss dasselbe endgültige Segment ableiten.
• Erforderlich? — Eine eindeutige Route ist für jede öffentliche Seite erforderlich. Sie darf nur generiert werden, wenn ein Abschnitt eine genehmigte deterministische Regel und Kollisionsprüfungen hat; Playbook-Seiten verwenden ihre registrierten url-Werte.
• Grenzen — Bevorzugen Sie einen kurzen, lesbaren Slug, der das unterscheidende Subjekt bewahrt, normalerweise drei bis acht sinnvolle Wörter. Entfernen Sie Satzzeichen und leere Modifikatoren. Entfernen Sie Stoppwörter wie „der“, „die“, „das“ nur, wenn das Ergebnis natürlich und eindeutig bleibt; es gibt keine willkürliche Zeichenbegrenzung, die eine Beschädigung der Bedeutung rechtfertigt.
• Wer oder was es verwendet — Hugo-Routing, interne Links, Breadcrumbs, kanonische Generierung, Sitemaps, Feeds, Analysen, Weiterleitungen und externe Referenzen.
• Regeln — Behandeln Sie einen veröffentlichten Slug als dauerhafte Verpflichtung. Entscheiden Sie ihn basierend auf dem dauerhaften Thema, nicht einer Kampagnenüberschrift oder einem vorübergehenden Jahr. Wenn sich der Titel ändert, aber Thema und Absicht gleich bleiben, behalten Sie den alten Slug. Wenn die Seite tatsächlich umzieht, erstellen Sie die neue Route, behalten Sie die alte Route in aliases, aktualisieren Sie interne Links und testen Sie das Weiterleitungsziel.
• Häufige Fehler — Neugenerieren des Slugs bei jeder Titeländerung, Einfügen von Synonymen in den Pfad, Beibehalten von Daten, die Evergreen-Inhalte veraltet aussehen lassen, Verwenden von Groß-/Kleinschreibung oder Unterstrichen, Erstellen von zwei URLs, die sich nur durch einen abschließenden Schrägstrich unterscheiden, und Ändern einer Route ohne Beibehaltung der alten.

canonical

• Zweck — Ein Canonical identifiziert die bevorzugte URL unter gleichwertigen oder nahezu gleichwertigen zugänglichen Versionen. Es konsolidiert die Identität; es bewegt keinen Besucher und entschuldigt keine unkontrollierte Duplizierung.
• Typ und Format — Eine absolute HTTPS-URL, einschließlich des vorgesehenen Hosts und normalisierten Pfads: https://amicited.com/academy/rotate-an-api-key/. Die Vorlage kann eine Selbstreferenz vom Seiten-Permalink ableiten, wenn die Website eine vertrauenswürdige Host- und Routenrichtlinie hat.
• Erforderlich? — Jede indexierbare Seite muss ein Canonical ausgeben. Das Feld selbst ist bedingt, wenn ein korrekter selbstreferenzierender Wert automatisch abgeleitet wird; setzen Sie es explizit für eine genehmigte Domain-übergreifende oder außergewöhnliche kanonische Angabe.
• Grenzen — Genau ein kanonisches Ziel. Das Ziel muss ein erfolgreiches indexierbares Dokument zurückgeben, das bevorzugte Protokoll und den bevorzugten Host verwenden und im Wesentlichen denselben Inhalt darstellen.
• Wer oder was es verwendet — Das HTML <link rel="canonical">, Suchmaschinen, Sitemap- und interne Link-Prüfungen, Deduplizierungsberichte und Schema-URL-Bezeichner.
• Regeln — Standardmäßig Selbstreferenz. Verwenden Sie einen domainübergreifenden Canonical nur, wenn ein anderer Herausgeber die bevorzugte gleichwertige Version besitzt und beide Parteien eine Konsolidierung beabsichtigen. Verwenden Sie eine Weiterleitung, keinen Canonical, wenn die alte URL ersetzt wurde und Benutzer immer auf der neuen landen sollen. Halten Sie Canonical, Sitemap-URL, Hreflang, interne Links und Schema-Identität abgestimmt.
• Häufige Fehler — Jede paginierte oder lokalisierte Seite auf ein generisches Elternteil verweisen, unterschiedliche Inhalte kanonisieren, auf eine Weiterleitung oder Fehlerseite abzielen, HTTP und HTTPS mischen, das Feld als Ersatz für einen Alias verwenden und annehmen, dass kanonische Direktiven garantiert befolgt werden.

aliases

• Zweck — aliases bewahrt Routen, die zuvor dieselbe Seite identifizierten, damit ein Umzug vorhandene Links und Lesezeichen nicht zu Sackgassen macht. Es zeichnet Routenverlauf auf, anstatt alternative indexierbare Identitäten zu erstellen.
• Typ und Format — Ein TOML-Array von site-relativen Pfaden, zum Beispiel aliases = [ "/blog/old-api-key-guide/" ]. Jeder Wert enthält einen führenden und abschließenden Schrägstrich und muss siteweit eindeutig sein.
• Erforderlich? — Optional für eine neue Seite; erforderlich, wenn eine veröffentlichte Seite von einem Pfad verschoben wird, den die Site kontrollierte.
• Grenzen — Fügen Sie jede bekannte frühere First-Party-Route hinzu, die noch Links oder Traffic erhält. Fügen Sie keine spekulativen Schreibvarianten oder eine unbegrenzte Liste von Keyword-URLs hinzu.
• Wer oder was es verwendet — Hugos Alias-Ausgabe, Deployment-Weiterleitungsverarbeitung (wo konfiguriert), Migrations-QA, Link-Monitore und Benutzer, die alten URLs folgen. Da Hugo eine Alias-Seite anstelle einer HTTP-Weiterleitung auf Ursprungsebene ausgeben kann, muss das Deployment-Verhalten überprüft und nicht angenommen werden.
• Regeln — Eine verschobene Seite hält ihren alten Pfad funktionsfähig. Jeder Alias muss in einem Schritt zur aktuellen kanonischen Route auflösen. Aktualisieren Sie interne Links auf die neue URL, auch wenn der Alias funktioniert, und bewahren Sie den Alias bei späteren Bearbeitungen, es sei denn, ein dokumentiertes Weiterleitungssystem ersetzt ihn.
• Häufige Fehler — Löschen der alten Seite ohne Alias, Verkettung von altem Pfad zu Zwischenpfad zu aktuellem Pfad, Behandlung von Aliassen als doppelte Veröffentlichungsrouten, Verweis mehrerer nicht verwandter Seiten auf ein einziges praktisches Ziel oder Annahme, dass die lokale Hugo-Ausgabe den Produktions-HTTP-Status beweist.

type und layout

• Zweck — Diese Felder wählen den Rendering-Vertrag. type ordnet eine Seite einer Inhaltsklasse mit gemeinsamen Vorlagen und Verhalten zu; layout fordert eine bestimmte Vorlage innerhalb dieser Klasse an. Die korrekte Auswahl stellt sicher, dass die Seite die beabsichtigte Navigation, den Inhaltsplatz, die Assets und das Schema-Verhalten erhält.
• Typ und Format — Kleingeschriebene registrierte Strings. Diese Seite verwendet type = "academy". Ein layout-Wert ist ein Vorlagen-Basename wie single, ohne Dateierweiterung oder Pfad-Traversal.
• Erforderlich? — type ist erforderlich, wenn der Inhaltsort nicht sicher den beabsichtigten Typ impliziert oder wenn der Playbook-Vertrag dies vorschreibt. layout ist optional und sollte weggelassen werden, wenn die Standardvorlage des Typs korrekt ist.
• Grenzen — Ein Wert pro Feld, nur ausgewählt aus von der Site gepflegten Vorlagen. Ein neuer Wert ist eine technische Änderung, keine redaktionelle Improvisation.
• Wer oder was es verwendet — Hugos Lookup-Reihenfolge, Vorlagen, partielle Auswahl, CSS- und JavaScript-Einbindung, Schema-Adapter und Validierungsregeln.
• Regeln — Wählen Sie den Beitragstyp und den Rendering-Vertrag vor dem Entwurf. Verwenden Sie layout nur für eine echte unterstützte Variante; verwenden Sie es nicht, um Inhalte zu kompensieren, die zu einem anderen type gehören. Überprüfen Sie, ob eine Überschreibung existiert und die Frontmatter-Form der Seite akzeptiert.
• Häufige Fehler — Verwechseln des redaktionellen entity mit Hugo type, Benennen einer Vorlagendatei, die nicht existiert, Kopieren eines Landing-Page-Typs auf ein Academy-Dokument, Verlassen auf Ordner-Inferenz während einer Migration und Einführen von einmaligen Layout-Namen, die gemeinsame Verbesserungen umgehen.

Discovery

description

• Zweck — Die Beschreibung hilft einem qualifizierten Suchenden oder dem Empfänger einer Freigabe zu entscheiden, ob diese Seite die Anforderung erfüllt. Es ist Vorschautext, keine komprimierte Einleitung und kein Ort, um Relevanz durch Wiederholung zu beweisen.
• Typ und Format — Ein Klartext-Satz. Er sollte den primären Begriff natürlich nennen, den konkreten Wert angeben und nützlichen Umfang, Zielgruppe, Methode oder Ergebnis hinzufügen.
• Erforderlich? — Erforderlich für jede indexierbare Seite in diesem Playbook.
• Grenzen — 150–160 Zeichen, einschließlich Leerzeichen. Dies ist ein redaktioneller Konsistenzbereich, keine Anzeigegarantie: Suchmaschinen können ihn kürzen oder den Ausschnitt aus dem Body-Inhalt umschreiben, wenn eine andere Passage besser zur Suchanfrage passt.
• Wer oder was es verwendet — Meta-Beschreibungs-Tags, Open Graph- und Twitter-Beschreibungs-Standardwerte, Auflistungskarten, Feeds, CMS-Vorschauen, Suchqualitätsprüfungen und manchmal Schema description.
• Regeln — Schreiben Sie für einen Klick vom richtigen Leser. Machen Sie den Satz spezifisch genug, um die Seite von einem anderen Ergebnis mit einem ähnlichen Titel zu unterscheiden. Der Abschnitt Beschreibungsregeln unten enthält die Begründung und Ablehnungstests.
• Häufige Fehler — Duplizieren des Titels, Auflisten von Keywords, Beginnen mit „Erfahren Sie alles über“, Aufstellen einer nicht belegten Best-oder-Schnellsten-Behauptung, Verwenden eines vagen Aufrufs zum Handeln, Überschreiten des Bereichs durch ein unsichtbares Marken-Suffix oder Annahme, dass der verfasste Text wörtlich in den Suchergebnissen erscheinen muss.

keywords

• Zweck — In diesem Repository zeichnet keywords den kompakten Satz von Suchbegriffen und Terminologie auf, der für redaktionelle QA, Korpus-Suche, Coverage-Analyse und interne Werkzeuge verwendet wird. Es hilft Redakteuren, die Sprache zu erkennen, die eine Seite genau verwenden muss; es ist kein Versprechen, jede Phrase mechanisch einzubinden.
• Typ und Format — Ein Array von natürlichsprachlichen Strings, geordnet vom primären Begriff über sinnvolle Varianten und eng verwandte Terminologie.
• Erforderlich? — Erforderlich gemäß diesem Playbook, auch für Seiten, deren öffentliche Vorlagen die Werte nicht rendern.
• Grenzen — Sechs bis acht eindeutige Einträge. Jeder Eintrag muss eine echte Suchanfragenphrase oder einen notwendigen Begriff darstellen, keine Variation auf Token-Ebene.
• Wer oder was es verwendet — Redaktionelle Validatoren, Inhaltsinventare, Such- und Chancenanalyse, interner Abruf und Migrationstools. Öffentliche Suchmaschinen verwenden dieses Feld nicht allein aufgrund seiner Existenz als Ranking-Signal.
• Regeln — Halten Sie die Menge auf den Umfang einer Seite fokussiert. Führen Sie Groß-/Kleinschreibung, Zeichensetzung, Singular-/Plural- und triviale Wortstellungs-Duplikate zusammen. Verwenden Sie die Phrasen, um Coverage und Terminologie zu überprüfen, niemals, um eine unnatürliche Dichte vorzuschreiben.
• Häufige Fehler — Behandeln des Feldes als veralteten Meta-Keywords-Ranking-Mechanismus, Hinzufügen von Dutzenden von Varianten, Wiederholen des Titels als acht nahezu identische Duplikate, Einfügen von Wettbewerbernamen, die der Body nicht diskutiert, und Zulassen, dass das Array eine ordnungsgemäße Taxonomie oder Prompt-Ziele ersetzt.

targetPrompts

• Zweck — targetPrompts zeichnet die vollständigen Fragen oder Anfragen auf, die eine Person einem KI-Antwortsystem geben kann und für die diese Seite eine nützliche Quelle sein sollte. Prompt-Ziele bewahren den Gesprächskontext, den kurze Keyword-Phrasen auslassen.
• Typ und Format — Ein Array von vollständigen, natürlichsprachlichen Strings, zum Beispiel targetPrompts = [ "Wie rotiere ich einen API-Schlüssel ohne Ausfallzeiten?", "Was sollte ich vor dem Widerruf eines alten API-Schlüssels überprüfen?" ]. Formulieren Sie, wie ein Benutzer fragen würde, einschließlich Zielgruppe, Einschränkungen oder gewünschtem Vergleich.
• Erforderlich? — Bedingt für Seiten, die in Prompt-Tracking oder einem KI-Sichtbarkeits-Content-Programm enthalten sind; optional, wenn kein verfolgter Prompt-Satz existiert.
• Grenzen — Verwenden Sie einen kleinen, absichtlichen Satz, normalerweise einen primären Prompt und bis zu vier sinnvolle Varianten. Ein Prompt kann länger sein als ein Keyword, weil seine Qualifikatoren die Absicht tragen.
• Wer oder was es verwendet — Content-Briefings, Prompt-Tracking-Workflows, Abruf- und Coverage-Audits, KI-Antwortüberwachung und redaktionelle Bewertung. Es wird nicht als versteckter Suchtext gerendert.
• Regeln — Trennen Sie Prompts nach tatsächlichem Informationsbedarf, nicht nach Zeichensetzung. Ein Keyword wie „API-Schlüsselrotation“ benennt ein Thema; „Wie kann ein SaaS-Team einen API-Schlüssel rotieren, ohne Integrationen zu unterbrechen?“ benennt eine Zielgruppe, Aufgabe und Einschränkung. Die Seite muss jeden gespeicherten Prompt ehrlich beantworten.
• Häufige Fehler — Kopieren des Keywords-Arrays in dieses Feld, Erfinden von Dutzenden syntaktischer Variationen, Aufzeichnen von Prompts, die breiter sind als die Seite, Verwenden von Prompts als Body-Überschriften unabhängig vom Lesefluss und Behaupten von Prompt-Coverage, wenn die Antwort von Informationen abhängt, die die Seite nicht liefert.

Vertrauen und Herkunft

date und updated

• Zweck — date bewahrt, wann die Seite erstmals veröffentlicht wurde; updated meldet die letzte inhaltliche Änderung oder abgeschlossene Überprüfung. Zwei Felder bewahren die Historie und zeigen gleichzeitig, ob sich Informationen, auf die Leser angewiesen sind, geändert haben.
• Typ und Format — Zeitstempel-Strings in der Site-Konvention, YYYY-MM-DD HH:MM:SS. Halten Sie eine Zeitzonenrichtlinie über das gesamte Korpus ein, damit Feeds und Vergleiche deterministisch bleiben.
• Erforderlich? — date ist für veröffentlichte redaktionelle Seiten erforderlich. updated ist optional, bis eine qualifizierende Änderung eintritt, dann erforderlich, wenn die Seite ein geändertes Datum anzeigt.
• Grenzen — Jeweils ein Wert. updated kann nicht vor date liegen oder in der Zukunft liegen. Eine Korrektur Minuten nach der Veröffentlichung kann noch dokumentiert werden, aber routinemäßige Entwurfsrevisionen vor der Veröffentlichung erzeugen kein aktualisiertes Datum.
• Wer oder was es verwendet — Sichtbare Autorenvermerke und Aktualitätsstempel, Feeds, Sitemaps, Schema datePublished und dateModified, Aktualitätsaudits, Sortierung und redaktionelle Warteschlangen.
• Regeln — Setzen Sie updated zurück bei einer faktenbezogenen Korrektur, geänderter Anweisung, neuen oder entfernten Belegen, überarbeitetem Umfang, wesentlich geänderter Empfehlung oder einer dokumentierten Überprüfung zeitkritischer Behauptungen. Setzen Sie es niemals zurück für Zeichensetzung, Formatierung, Vorlagenarbeit oder eine reine Zeitstempel-Bearbeitung. Siehe Daten, Autoren und Prüfer für die Richtlinienbegründung.
• Häufige Fehler — Überschreiben des ursprünglichen Datums während einer Aktualisierung, zukünftiges Datieren einer Seite, um sie aktuell erscheinen zu lassen, Erhöhen von Daten ohne Inhaltsänderung, Behandeln einer automatischen Bereitstellung als redaktionelles Update und Versäumnis, aufzuzeichnen, was sich in der gepflegten Update-Historie geändert hat.

author

• Zweck — author verbindet das Dokument mit der verantwortlichen Personenentität, die für seine Arbeit verantwortlich ist. Die Verbindung gibt einem Leser und einer Maschine einen Pfad von einer Seite mit Behauptungen zu einer gepflegten Identität, Expertise und anderen Arbeiten.
• Typ und Format — Ein stabiler Autoren-Bezeichner, der über das Autorenregister der Site zu einer Profil-URL und einem Person-Eintrag auflöst. Zum Beispiel ist author = "maya-chen" nur gültig, wenn dieser Bezeichner aufgelöst werden kann; ein Anzeigename wie „Maya Chen, SEO-Expertin“ ist kein Ersatz für den Entitätslink.
• Erforderlich? — Erforderlich für inhaltlich wichtige redaktionelle Seiten. Transaktionsseiten können einen verwalteten Organisations-Eigentümer nur dann verwenden, wenn die Vorlage und Richtlinie diesen Entitätstyp unterstützen.
• Grenzen — Standardmäßig ein verantwortlicher Hauptautor; verwenden Sie ein dokumentiertes Bezeichner-Array nur, wenn das Schema und die Autorenvermerk-Vorlagen echte Co-Autorenschaft unterstützen.
• Wer oder was es verwendet — Sichtbare Autorenvermerke, Autorenprofil-Links, Article-Schema, Feeds, redaktionelle Eigentumsberichte, Überprüfungs-Workflows und Entitätsgraphen.
• Regeln — Lösen Sie den Bezeichner vor der Veröffentlichung auf. Das Profil muss dieselbe Person identifizieren, die im Autorenvermerk gezeigt wird, und gepflegt bleiben. Nennen Sie die Person, die für den Inhalt verantwortlich ist, nicht die Person, die ihn nur hochgeladen hat.
• Häufige Fehler — Eingabe eines unverlinkten Namens-Strings, Verwenden von „Admin“ oder eines erfundenen Redaktionsteams, Zuordnung einer prominenter Führungskraft, die die Arbeit nicht verfasst hat, Zulassen, dass ein Bezeichner zu keinem Profil auflöst, und Ändern der Autorenschaft, um Expertise vorzutäuschen, die nicht involviert war.

reviewedBy, reviewedAt und reviewScope

• Zweck — Diese Felder zeichnen eine unabhängige Überprüfung auf, die von der Autorenschaft getrennt ist. reviewedBy identifiziert die Prüfer-Entität; reviewedAt gibt an, wann die Überprüfung abgeschlossen wurde; reviewScope sagt, was der Prüfer geprüft hat, damit das Abzeichen keine Zustimmung über die Belege hinaus impliziert.
• Typ und Format — reviewedBy ist ein stabiler Bezeichner, der zu einem gepflegten Personenprofil auflöst. reviewedAt verwendet das Site-Zeitstempel-Format. reviewScope ist eine prägnante Klartext-Aussage wie „Schritte zur Anmeldedatenrotation und Sicherheitshinweise.“
• Erforderlich? — Bedingt, wenn Gesetz, Risikopolitik, Themenempfindlichkeit oder die Spezifikation des Beitragstyps eine unabhängige Überprüfung erfordern. Wenn reviewedBy vorhanden ist, sind Prüfdatum und -umfang als Prüfungsaufzeichnungsdaten erforderlich, auch wenn eine bestimmte Vorlage sie in einem verbundenen redaktionellen Eintrag und nicht im öffentlichen Frontmatter speichert.
• Grenzen — Nennen Sie nur tatsächliche Prüfer. Der Umfang sollte spezifisch genug sein, um Ausschlüsse offenzulegen, ohne ein Prüfbericht zu werden. Ein Prüfer muss relevante Kompetenz haben und darf nicht einfach die Autorenrolle duplizieren.
• Wer oder was es verwendet — Geprüft-von-Komponenten, Personenentitäts-Joins, Governance-Audits, Publikationsgates für hohes Risiko, strukturierte Herkunft und Aktualisierungsprotokolle.
• Regeln — Schließen Sie die Überprüfung ab, nachdem der Inhalt stabil ist, erfassen Sie Ergebnisse und Lösungen in der redaktionellen Historie und überprüfen Sie erneut, wenn spätere Änderungen den geprüften Umfang betreffen. Unabhängig bedeutet, dass der Prüfer die Arbeit testet, anstatt seinen eigenen Entwurf zu bestätigen.
• Häufige Fehler — Behandeln von Lektorat als Expertenprüfung, Anzeigen eines Prüfers ohne Datum oder Umfang, Nennen einer Person, die nie die endgültige Version gesehen hat, Belassen des Abzeichens nach einer inhaltlichen, nicht geprüften Umschreibung und Implizieren von rechtlicher, medizinischer oder technischer Genehmigung außerhalb des angegebenen Umfangs.

Medien und Soziales

image und imageAlt

• Zweck — image wählt das repräsentative Hero- und Social-Asset aus; imageAlt liefert den funktionalen Text-Alternativwert, wenn dieses Asset als sinnvoller Seiteninhalt gerendert wird. Das Zusammenhalten des Paares verhindert, dass Discovery-Bildmaterial zu einem Barrierefreiheits-Mangel wird.
• Typ und Format — image ist ein auflösbarer Site-Pfad oder eine genehmigte absolute URL. imageAlt ist Klartext, der die nützlichen Informationen des Bildes in seinem Seitenkontext beschreibt, nicht seinen Dateinamen oder das Ziel-Keyword.
• Erforderlich? — Bedingt nach Beitragstyp und Vorlage. Wenn die Seite ein Hero- oder dediziertes Social-Bild benötigt, ist image erforderlich. imageAlt ist erforderlich, wenn dieses Bild informativ gerendert wird; eine rein dekorative Darstellung muss ein leeres alt-Attribut in der Vorlage verwenden, keinen erfundenen beschreibenden Text.
• Grenzen — Verwenden Sie ein repräsentatives Asset. Für soziale Kompatibilität stellen Sie eine 1200 × 630 Pixel Quelle im erwarteten Zuschnittverhältnis bereit, halten Sie wichtige Inhalte von den Rändern fern und halten Sie imageAlt prägnant – normalerweise 5–160 Zeichen. Die Datei muss existieren, bevor sie referenziert wird.
• Wer oder was es verwendet — Hero-Komponenten, Auflistungskarten, Open Graph- und Twitter-Tags, Schema-Bildfelder, Feeds, Bild-Pipelines, Screenreader (wenn sichtbar) und Asset-QA.
• Regeln — Wählen Sie ein Bild, das auch nach einem Zentrumszuschnitt und in Thumbnail-Größe noch kommuniziert. Beschreiben Sie seine Funktion im Kontext: „API-Schlüsseleinstellungen mit hervorgehobener Rotieren-Taste“ ist nützlich; „API-Schlüssel“ ist es nicht. Platzieren Sie keine wesentlichen Behauptungen nur innerhalb von Pixeln.
• Häufige Fehler — Referenzieren eines geplanten Assets, das nicht existiert, Verwenden eines Logos als jedes Artikelbild, Einbetten von kleinem Text, der in Freigaben unlesbar wird, Schreiben von „Bild von“, Einfügen von Keywords in Alt-Text und Annahme, dass Social-Alt-Text und sichtbares Bild-Alt-Verhalten plattformübergreifend identisch sind.

Open Graph- und Twitter-Card-Felder

• Zweck — Social-Metadaten steuern, wie eine URL beim Teilen zusammengefasst wird. Ein konsistenter Titel, eine Beschreibung, URL, Typ und ein Bild helfen Empfängern, die Seite vor dem Klicken zu erkennen, und verringern die Wahrscheinlichkeit, dass eine Plattform ein irrelevantes Asset auswählt.
• Typ und Format — In diesem Repository leiten Vorlagen og:title und twitter:title von title, Beschreibungen von description, URLs vom Permalink, og:type vom Layout-Kontext und beide Bild-Tags von image mit einem Site-Fallback ab. twitter:card wird als summary_large_image ausgegeben. Dies sind generierte Tags, standardmäßig keine doppelten Frontmatter-Felder.
• Erforderlich? — Die Ausgabe-Tags sind auf öffentlichen Seiten erforderlich. Separate Überschreibungen sind optional und sollten nur durch einen dokumentierten Vorlagenvertrag eingeführt werden; nicht unterstützte Ad-hoc-Felder wie ogTitle bewirken nichts.
• Grenzen — Eine kohärente Vorschau pro Seite und ein repräsentatives 1200 × 630 Bild. Halten Sie die abgeleiteten Formulierungen innerhalb der Titel- und Beschreibungsbereiche und testen Sie dann das tatsächliche Zuschnitt- und Overlay-Verhalten auf wichtigen Sharing-Oberflächen.
• Wer oder was es verwendet — Soziale Netzwerke, Messaging-Clients, Link-Unfurl-Bibliotheken, Browser-Erweiterungen, Kollaborationstools und Share-Preview-Debugger.
• Regeln — Bevorzugen Sie Ableitung, damit Such- und Social-Angaben abgestimmt bleiben. Überschreiben Sie nur, wenn der Social-Kontext tatsächlich eine andere Rahmung benötigt und die Vorlage dies unterstützt. Ein falsches Bild kostet Wiedererkennung und Vertrauen: Der Empfänger sieht möglicherweise eine veraltete Oberfläche, ein anderes Produkt, eine irreführende Behauptung oder einen Zuschnitt, der das Subjekt verbirgt.
• Häufige Fehler — Erstellen von Feldern, die keine Vorlage liest, Zulassen, dass ein globaler Fallback ein fehlendes erforderliches Hero-Bild maskiert, Verwenden eines Porträts oder winzigen Bildes für eine breite Karte, Ändern von Social-Text, um ein stärkeres Versprechen zu machen als die Seite, und Validieren nur der HTML-Quelle anstatt einer abgerufenen Vorschau.

Klassifikation

taxonomy, categories und tags

• Zweck — Klassifikation verbindet eine Seite mit verwalteten Themen-, Format-, Zielgruppen- oder Produktsammlungen. Sie ermöglicht nützliche Archive und Filter nur, wenn jedes Vokabular eine erklärte Bedeutung hat; andernfalls werden Bezeichnungen zu einem unkontrollierten Synonymhaufen.
• Typ und Format — Arrays von registrierten Kleinbuchstaben-Slugs. Verwenden Sie taxonomy für das kontrollierte Themenvokabular des Repositorys. Verwenden Sie categories nur für eine kleine, gegenseitig verständliche redaktionelle Hierarchie und tags nur für ein verwaltetes, querliegendes Vokabular, wenn diese Taxonomien konfiguriert sind.
• Erforderlich? — Bedingt nach Beitragstyp und Archiv-Design. Themenhaltige redaktionelle Seiten benötigen normalerweise einen oder mehrere kontrollierte Begriffe; Dienstprogrammseiten benötigen möglicherweise keine. Ein Feld darf nicht nur befüllt werden, weil ein CMS es anbietet.
• Grenzen — Für allgemeine Taxonomie, ein bis fünf Werte pro kontrolliertem Vokabular. Jeder Begriff benötigt eine Definition, einen Eigentümer und eine Zusammenführungsregel. Erstellen Sie ein indexierbares Archiv nur, wenn der Begriff eine dauerhafte Lesernachfrage darstellt und das Archiv eine einzigartige Einführung, ein kohärentes Inventar, interne Links und laufende Wartung bieten kann.
• Wer oder was es verwendet — Archivseiten, Breadcrumbs, Filter, Systeme für verwandte Inhalte, Facettennavigation, Inhaltsaudits und Analytik-Segmentierung.
• Regeln — Wählen Sie den engsten registrierten Begriff, der die Seite genau gruppiert. Ordnen Sie Singular-/Plural-, Abkürzungs- und Schreibvarianten einem kanonischen Wert zu. Entscheiden Sie, ob Archive auf Vokabular-Ebene indexierbar sind, nicht Tag für Tag nach versehentlicher Erstellung.
• Häufige Fehler — Verwenden von seo, SEO, search-optimization und search engine optimization als separate Werte, Hinzufügen von einmaligen Tags, um jedes Nomen zu beschreiben, Verwechseln eines Geschäftstyps mit einem Thema, Generieren von dünnen indexierbaren Archiven und Löschen von Begriffen ohne Migration ihrer Mitglieder.

Playbook-Join-Schlüssel

• Zweck — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage und amicitedFeatures sind typisierte Join-Schlüssel. Sie ermöglichen es, dass eine Quellseite in generierten Bibliotheken und Matrizen erscheint, ohne dass Redakteure Karten von Hand kopieren. Diese Seite ist das ausgearbeitete Beispiel: Ihre Säule identifiziert ein Element, ihre Familie gruppiert Metadaten-Anleitungen, und ihr postTypes-Array deklariert die Spezifikationen, die sie konsumieren.
• Typ und Format — Singuläre Schlüssel verwenden registrierte Kleinbuchstaben-Slugs: playbookPillar und playbookFamily sind Strings, playbookWave ist eine ganze Zahl und journeyStage ist ein kontrollierter String. Beziehungsschlüssel – postTypes, elements, businessTypes und amicitedFeatures – sind Arrays von registrierten Slugs aus ihren jeweiligen Registern.
• Erforderlich? — playbookPillar und playbookWave sind auf Playbook-Einträgen erforderlich. playbookFamily ist erforderlich, wenn die Säule verwaltete Familien hat. Die Array-Joins und journeyStage sind bedingt: Befüllen Sie nur Beziehungen, die der Seitenvertrag tatsächlich unterstützt.
• Grenzen — Eine Säule, eine Familie innerhalb dieser Säule, eine Welle und eine Journey-Phase, es sei denn, das Modell erlaubt explizit mehrere Phasen. Arrays enthalten eindeutige registrierte Schlüssel, keine Anzeigebezeichnungen, Prosa oder URLs.
• Wer oder was es verwendet — Playbook-Hub-Auflistungen, säulenübergreifende Matrizen, Filter, Beziehungskarten, Vollständigkeitsberichte, Release-Wave-Ansichten und interne Tools, die relevante AmICited-Funktionen finden.
• Regeln — Validieren Sie jeden Wert gegen das kanonische Register. Richtung ist wichtig: Eine Beitragstyp-Seite listet ihre erforderlichen elements auf; eine Elementseite listet anwendbare postTypes auf; eine Geschäftstyp-Seite listet nützliche Beitragstypen auf. Behandeln Sie Bezeichnungen als Präsentation und Schlüssel als dauerhafte Daten. Benennen Sie einen Schlüssel nur durch eine Migration um, die jede Seite des Joins aktualisiert.
• Häufige Fehler — Erfinden von nahen Synonymen, Speichern von Titeln anstelle von Slugs, Mischen von ganzen Zahlen und Strings für Wellen, Hinzufügen einer Beziehung, weil zwei Seiten sich gegenseitig erwähnen, Zulassen, dass reziproke Arrays einander widersprechen, und Erstellen von manuell gepflegtem Auflistungs-Markup, das von Metadaten abweicht.

Abgeleitete und strukturelle Felder

schemaType

• Zweck — schemaType wählt die spezifischste unterstützte strukturierte Datenzuordnung, die die sichtbare Seite genau beschreibt. Es teilt dem Schema-Adapter mit, welchen Vokabularvertrag er anwenden soll; es macht die Seite nicht allein durch Deklaration zu diesem Ding.
• Typ und Format — Ein registrierter Schema.org-Typname wie Article, ausgewählt aus den Typen, die der Site-Adapter unterstützt. Groß-/Kleinschreibung und Schreibweise müssen mit dem Register übereinstimmen.
• Erforderlich? — Bedingt. Setzen Sie es, wenn mehrere Schema-Zuordnungen für denselben Hugo-Typ gültig sind oder wenn der Beitragstyp-Vertrag einen expliziten Typ erfordert. Andernfalls lassen Sie die Vorlage ihren sicheren Standard ableiten.
• Grenzen — Ein primärer Seitentyp, mit verschachtelten Entitäten, die vom Adapter aus tatsächlichem Inhalt erstellt werden. Der ausgewählte Typ muss alle erforderlichen Eigenschaften erfüllen und mit dem übereinstimmen, was ein Leser sehen kann.
• Wer oder was es verwendet — JSON-LD-Adapter, Rich-Result-Validierung, Content-QA und Schema-Inventarberichte.
• Regeln — Wählen Sie nach Seitenfunktion und sichtbaren Belegen, nicht nach dem Suchfeature, das ein Redakteur wünscht. Eine How-to-Seite ohne vollständiges sichtbares Verfahren kann keine Genauigkeit durch Setzen eines How-to-Typs verdienen. Halten Sie Schema-URLs, Daten, Personen und Bilder mit ihren Quellfeldern synchronisiert.
• Häufige Fehler — Auswählen eines spezifischeren Typs ohne seinen erforderlichen Inhalt, Ausgeben mehrerer widersprüchlicher primärer Typen, Kopieren eines Schema-Werts aus einer nicht verwandten Vorlage, Annehmen, dass gültige Syntax die Eignung garantiert, und Platzieren von Behauptungen in JSON-LD, die Leser nicht überprüfen können.

Lesezeit

• Zweck — Die Lesezeit gibt dem Leser eine grobe Aufwandsabschätzung. Sie wird aus dem endgültig renderbaren Body abgeleitet, sodass sich die Schätzung ändert, wenn sich die tatsächliche Leselast ändert.
• Typ und Format — Eine berechnete ganze Zahl von Minuten, die aus der Wortzählungsrichtlinie der Content-Pipeline erzeugt wird. Code-Blöcke, Tabellen, Bildunterschriften und eingebettete Medien sollten einer dokumentierten Zählregel folgen.
• Erforderlich? — Die Anzeige ist optional je nach Vorlage. Ein verfasstes Frontmatter-Feld ist nicht als Quelle der Wahrheit zulässig.
• Grenzen — Runden Sie konsistent und wenden Sie eine sinnvolle Mindestanzeige wie eine Minute an. Die genaue Annahme von Wörtern pro Minute ist weniger wichtig als die Verwendung derselben Methode auf der gesamten Site und die Kennzeichnung des Ergebnisses als Schätzung.
• Wer oder was es verwendet — Seitenkopfzeilen, Karten, Feeds, Analytik-Segmentierung und Leser, die entscheiden, ob sie einen langen Leitfaden beginnen.
• Regeln — Berechnen Sie, nachdem Shortcodes und ausgeschlossene Bereiche gemäß der Site-Richtlinie behandelt wurden. Neuberechnung bei jedem Build. Wenn Video oder eine interaktive Aufgabe die Bearbeitungszeit wesentlich verändert, kennzeichnen Sie dies separat, anstatt die Lesezeit zu verfälschen.
• Häufige Fehler — Eingabe von readingTime = 8, Vergessen, es nach einer Umschreibung zu aktualisieren, Vortäuschen falscher Präzision, Zählen von Navigation und Standardtext und Behandeln einer ausführungsintensiven Anleitung als acht Minuten Lesezeit plus keine Aufgabenzeit.

[[faq]]

• Zweck — [[faq]] speichert sichtbare Frage-Antwort-Paare einmal, sodass die Seite und alle berechtigten FAQ-Strukturdaten nicht auseinanderdriften können.
• Typ und Format — Ein TOML-Array von Tabellen; jedes Element enthält einen Klartext-question und einen in sich geschlossenen answer-String.
• Erforderlich? — Bedingt, wenn echte Folgefragen nach der Hauptseite bleiben. Es ist niemals erforderlich, nur um eine Vorlage zu füllen oder ein Suchfeature zu verfolgen.
• Grenzen — Normalerweise vier bis acht nützliche Elemente auf Playbook-Seiten. Jede Frage erscheint einmal, und jede Antwort muss vollständig sein, ohne sich auf die Akkordeon-Reihenfolge zu verlassen.
• Wer oder was es verwendet — Sichtbare FAQ-Darstellung, FAQPage-Schema (wo berechtigt), Seitennavigation, Content-QA und Antwortextraktion.
• Regeln — Dies ist ein Querverweisvertrag: Befolgen Sie Warum FAQ im Frontmatter lebt und die spätere FAQ-Anleitung, anstatt separate sichtbare und Schema-Kopien zu pflegen. Speichern Sie nur Fragen, auf die jeder Leser auf der Seite zugreifen kann.
• Häufige Fehler — Versteckte, reine-Schema-Antworten, doppelte als Fragen getarnte Überschriften, werbliche Antworten, nicht belegte Behauptungen, veraltetes JSON-LD und Behandlung der Suchresultat-Eignung als garantiert.

[[lnks]]

• Zweck — [[lnks]] zeichnet jeden verwalteten internen Link auf, der im Body verwendet wird, und verbindet seinen sichtbaren Anker mit einem Ziel und einer gepflegten Beschreibung. Der Eintrag macht Links überprüfbar, ohne gerendertes HTML zu durchsuchen, und unterstützt Migration und QA.
• Typ und Format — Ein TOML-Array von Tabellen mit text, path und title. text ist der genaue sichtbare Anker, path ist eine site-relative URL mit führendem und abschließendem Schrägstrich, und title ist die Beschreibung der Zielseite.
• Erforderlich? — Erforderlich für jeden internen Body-Link, der durch diese Inhaltskonvention verwaltet wird. App-Deep-Links und externe Quellen folgen ihren eigenen Aufzeichnungen und werden nicht als [[lnks]]-Einträge getarnt.
• Grenzen — Ein Eintrag pro Body-Link-Vorkommen, wenn derselbe Anker auf verschiedene Ziele zeigen kann; andernfalls sollten exakt doppelte Einträge entfernt werden. Das Ziel muss existieren oder im genehmigten kanonischen Slug-Register für die koordinierte Veröffentlichung sein.
• Wer oder was es verwendet — Interne Link-Validierung, Content-Migration, Beziehungsanalyse, Link-Titel-Generierung (wo unterstützt) und redaktionelle Überprüfung.
• Regeln — Stimmen Sie text mit dem Body-Anker wörtlich überein, einschließlich Groß-/Kleinschreibung und Zeichensetzung innerhalb des Links. Verwenden Sie den kanonischen site-relativen Pfad. Schreiben Sie title als genaue Zielbeschreibung, nicht als Anweisungen für die aktuelle Seite. Aktualisieren Sie den Eintrag und den Body gemeinsam.
• Häufige Fehler — Verwenden eines längeren text-Werts als des tatsächlichen Ankers, Erfinden eines nicht registrierten Slugs, Auslassen eines abschließenden Schrägstrichs, Aufzeichnen eines weiterleitenden alten Pfads, Beschreiben der Quelle anstelle des Ziels und Hinterlassen eines Eintrags, nachdem sein Body-Link entfernt wurde.

Erforderlich versus optional nach Beitragstyp

Die Matrix wendet die obigen Verträge auf die zwölf Beitragstypen an, die derzeit von diesem Element deklariert werden. R bedeutet erforderlich, C bedeutet bedingt gemäß den Feldregeln, D bedeutet erforderliche Ausgabe, die sicher abgeleitet werden kann, und O bedeutet optional. „Identität“ umfasst entity, id, title, type und die stabile Route. „Discovery“ umfasst description und keywords; Ziel-Prompts bleiben für jede Zeile bedingt. aliases ist immer bedingt bei einem Umzug, während verfasste Lesezeit niemals erforderlich ist.

„Bedingter Prüfer“ ist keine Erlaubnis, eine Überprüfung zu überspringen, wo Genauigkeit oder kommerzielles Risiko es erfordern. Best-X- und Alternativen-Seiten erfordern eine unabhängige Überprüfung, weil ihre Empfehlungen eine Entscheidung materiell beeinflussen können und sich oft ändern, wenn sich Produkte, Preise und Eignung ändern. Für andere Zeilen aktiviert die Risikopolitik, nicht die verfügbare Zeit eines Redakteurs, die Anforderung. Ebenso ist ein mit D markiertes Canonical im gerenderten HTML immer noch erforderlich; nur die Frontmatter-Eingabe darf weggelassen werden, wenn die Vorlage die korrekte Selbstreferenz generieren kann.

Frontmatter-Validierung

Die Validierung sollte deterministische Fehler automatisch zurückweisen und das Urteil für Fragen zurückhalten, die von Bedeutung, Belegen oder beruflicher Kompetenz abhängen. Die Aufteilung verhindert zwei gegensätzliche Fehler: Prüfer zu bitten, Syntax abzufangen, die ein Parser perfekt abfangen kann, und vorzutäuschen, dass eine Zeichenzählregel entscheiden kann, ob ein Text ehrlich ist.

Führen Sie deterministische Prüfungen vor der redaktionellen Überprüfung durch, damit der Prüfer einen kohärenten Eintrag sieht. Überprüfen Sie dann das gerenderte HTML, nicht nur das Frontmatter: Ein gültiger Quellwert ist immer noch ein Produktionsfehler, wenn die ausgewählte Vorlage ihn ignoriert, ihn dem falschen Tag zuordnet, erforderliche Herkunftsinformationen verbirgt oder ein Canonical generiert, das nicht mit der öffentlichen Route übereinstimmt. Die Veröffentlichung ist erst abgeschlossen, wenn Quelle, Rendering und Zielverhalten übereinstimmen.

Das entity-Feld

entity beantwortet die Frage „Von welchem genauen Beitragstyp ist dieses Dokument eine Instanz?“ Es beantwortet nicht die Frage „Welches Thema behandelt diese Seite?“ Diese Unterscheidung ist wichtig, weil zwei Dokumente dasselbe Thema behandeln können, während sie unterschiedliche Aufgaben erfüllen. Ein Glossareintrag definiert „Diagnose“; ein Blogartikel kann über eine Änderung der Diagnoserichtlinien berichten. Wenn beide entity = "diagnosis" verwenden, können nachgelagerte Systeme nicht zuverlässig die richtige Vorlage, Validierungsregeln, Analysegruppe oder Migration auswählen.

Verwenden Sie das Gruppenpräfix plus den Post-Typ-Slug für Varianten innerhalb einer Familie: guide-how-to, guide-ultimate, comparison-a-vs-b und comparison-alternatives-to-x. Verwenden Sie den reinen Namen für eigenständige Typen: product-page oder case-study. Registrieren Sie den Bezeichner einmal, halten Sie ihn stabil und ändern Sie ihn niemals, weil sich das Thema oder die Zielsuchanfrage ändert. Platzieren Sie Themenkonzepte in der taxonomy und Abfragesprache in den keywords.

Titel, H1 und SEO-Titel

Diese Werte können je nach Kontext unterschiedlich sein, müssen aber dieselbe Seite beschreiben. title ist der dauerhafte Standard. h1 ist die sichtbare Überschrift und kann im Kontext natürlicher sein. seoTitle dient dem Browser und den Suchergebnissen und kann einen prägnanten Unterscheidungsmerkmal, ein legitimes Jahr oder ein Marken-Suffix hinzufügen.

Zum Beispiel stimmen title = "API Key Rotation", h1 = "How to Rotate an API Key Without Downtime" und seoTitle = "API Key Rotation: Safe Step-by-Step Guide" bei einer Aufgabe überein. „Free Security Tool“ als SEO-Titel wäre irreführend, weil es das Versprechen ändert. Erzeugen Sie keine Unterschiede nur, um mehr Keywords einzufügen.

Beschreibungsregeln

Die Beschreibung dient dazu, einem qualifizierten Leser bei der Entscheidung zum Klicken zu helfen. Halten Sie sie innerhalb von 150–160 Zeichen, schließen Sie den primären Begriff natürlich ein, geben Sie den konkreten Nutzen der Seite an und fügen Sie einen sinnvollen Qualifikator wie Zielgruppe, Umfang oder Ergebnis hinzu. Schreiben Sie einen flüssigen Satz, keine Keyword-Liste.

Der Begriff bestätigt die Relevanz; Wiederholung bringt keinen Mehrwert. Duplizieren Sie nicht den Titel, verwenden Sie nicht „Erfahren Sie alles über“, machen Sie keine nicht belegten Superlative und enden Sie nicht mitten im Gedanken. Suchsysteme können dennoch anderen sichtbaren Text für eine Suchanfrage auswählen.

Daten, Autoren und Prüfer

date bewahrt den ersten Veröffentlichungszeitstempel. updated zeichnet die letzte inhaltliche Änderung auf: eine faktenbezogene Korrektur, neue Belege, geänderte Anweisungen, überarbeiteten Umfang, geänderte Empfehlung oder vollständige Überprüfung, die zeitkritische Behauptungen bestätigt. Zeichnen Sie auf, was sich in der redaktionellen Historie geändert hat, wenn die Richtlinie es erfordert.

Das Korrigieren von Zeichensetzung, Ändern eines Button-Stils, Neuerstellen einer Vorlage oder alleiniges Berühren des Zeitstempels setzt updated nicht zurück. Ein Datum ohne dahinterstehende Arbeit vorzurücken, ist ein Richtlinienverstoß, weil es Lesern und Maschinen sagt, dass der Inhalt aktualisiert wurde, obwohl er es nicht wurde. Es ist Falschdarstellung, keine Wachstumstaktik.

Autor- und Prüferfelder tragen verantwortliche Identitäten in Autorenvermerke und strukturierte Daten. Der Autor ist für die Arbeit verantwortlich. Verwenden Sie reviewedBy nur, wenn eine qualifizierte Überprüfung stattgefunden hat, und verlinken Sie beide Bezeichner mit gepflegten Profilen. Die Trust-Grundlagenseite erklärt, wie Autorenschaft, Daten, Belege und Entitätsklarheit Vertrauen unterstützen, ohne Rankings zu garantieren.

Warum FAQ im Frontmatter lebt

Ein FAQ ist sichtbarer Inhalt und eine strukturierte Sammlung. Die einmalige Speicherung in [[faq]] ermöglicht es der Vorlage, das Akkordeon und identisches FAQPage-JSON-LD zu rendern und so veraltetes verstecktes Schema zu verhindern.

Fügen Sie echte Folgefragen hinzu, die für jeden Leser sichtbar sind. Duplizieren Sie keine Überschriften, verstecken Sie keine Werbung in Antworten und zeichnen Sie nicht angezeigte Fragen nicht aus. Gültiges Markup garantiert kein Suchfeature.

Syntax und Codebeispiele

Der plattformübergreifende Vertrag bildet Felder ab, kein sichtbares Bauteil. Die folgende portable Hülle ist nur in einer Austauschdatei gültig, deren Importprogramm Metadaten-Direktiven erkennt:

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

Sie muss während des Imports in native Seitenmetadaten normalisiert werden. Sie ist nicht im Body eines Produktionsartikels gültig. In Hugo ist die korrekte Zuordnung TOML zwischen +++-Begrenzungen am ersten Byte, wie im Live-Beispiel gezeigt. Es gibt bewusst keinen {{< frontmatter >}}-Shortcode: Ein Shortcode würde zu spät und in der falschen Dokumentenregion ausgeführt.

In WordPress ordnen Sie dieselben kanonischen Felder registrierten Beitragsfeldern und Beitrags-Meta zu, zum Beispiel post_title, post_excerpt, post_name, _amicited_entity, _amicited_author und _amicited_reviewed_by. Ein Kommentar wie <!-- wp:amicited/frontmatter --> oder ein [frontmatter]-Shortcode ist ungültig, weil er einen Body-Block anstelle von Dokumentenmetadaten erzeugt. Importprogramme und Editoren können ein Metadaten-Panel anzeigen, aber die gespeicherten Werte müssen an den Beitragseintrag gebunden bleiben.

Beispiele

Gut: ein kohärenter, verantwortlicher Eintrag

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

Dies identifiziert eine How-to-Variante, bewahrt die Historie, nennt verantwortliche Personen und trennt Thema von Seitenidentität. Der aktualisierte Zeitstempel wird durch eine dokumentierte Anweisungsänderung und Überprüfung gestützt.

Schlecht: der Titel als Beschreibung wiederholt

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

Die Beschreibung bietet keinen Mehrwert, keinen Umfang und keinen Grund zum Klicken. Sie verschwendet auch den Vorschauraum, der diese Seite von jedem anderen Ergebnis mit demselben Titel unterscheiden könnte.

Schlecht: eine Entität, die für zwei Beitragstypen wiederverwendet wird

# glossary entry
entity = "diagnosis"

# editorial guide
entity = "diagnosis"

Das gemeinsame Thema hat die Beitragstyp-Identität ersetzt. Verwenden Sie registrierte Werte wie glossary-term und guide-ultimate und weisen Sie dann „Diagnose“ über Taxonomie oder Keywords zu.

Schlecht: ein aktualisiertes Datum ohne Inhaltsänderung

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

Keine inhaltliche Bearbeitung oder Überprüfung stützt die Aktualitätsbehauptung. Lassen Sie updated unverändert oder weggelassen, bis eine echte Änderung existiert und in der redaktionellen Historie eingesehen werden kann.

Schema-Markup und Barrierefreiheit

Metadaten liefern Werte; die Vorlage bleibt für semantisches HTML, Fokus, Kontrast, Linkzweck und Alternativtext verantwortlich.

Schreibregeln

• Halten Sie Bezeichner stabil, kleingeschrieben und maschinensicher. Recyceln Sie niemals eine id oder ändern Sie stillschweigend entity nach der Veröffentlichung.
• Verwenden Sie Klartext in titelähnlichen Feldern. HTML, Markdown-Links, Emoji-Dekoration und erzwungene Zeilenumbrüche gehören nicht in Metadaten-Strings.
• Halten Sie die Beschreibung bei 150–160 Zeichen und Keyword-Arrays bei sechs bis acht unterschiedlichen Phrasen für dieses Playbook.
• Verwenden Sie echte registrierte Personen für Autor- und Prüferfelder. Erstellen Sie niemals einen zeremoniellen Prüfer oder eine generische „Redaktionsteam“-Identität, es sei denn, es handelt sich um eine gepflegte verantwortliche Entität.
• Verwenden Sie eine kontrollierte Taxonomie. Rechtschreibvarianten und Singular-/Plural-Duplikate erzeugen fragmentierte Archive.
• Referenzieren Sie nur Bilder, die existieren und Veröffentlichungsrechte haben. imageAlt beschreibt den informativen Inhalt des Bildes, nicht sein SEO-Ziel.
• Halten Sie FAQ-Antworten direkt und in sich geschlossen. Behauptungen erfordern dennoch dieselben Belege und Offenlegungen wie Prosa an anderer Stelle auf der Seite.
• Platzieren Sie niemals Geheimnisse, private Notizen, Zugriffstoken, Embargo-Anweisungen, personenbezogene Daten oder nicht geprüfte rechtliche Behauptungen in veröffentlichbarem Frontmatter.

Welche Beitragstypen verwenden Frontmatter und wo

Jeder Beitragstyp verwendet Frontmatter am ersten Byte. Die erforderliche Tiefe ändert sich mit Risiko, Absicht und Schema, nicht mit dem visuellen Design.

QA-Checkliste

• Beginnt die Datei mit +++, enthält gültiges TOML und schließt den Eintrag vor dem Body-Inhalt?
• Ist entity ein registrierter genauer Beitragstyp-Bezeichner und nicht das Thema, die Kampagne oder der Site-Name?
• Ist id eindeutig und stabil, und stimmt url mit dem kanonischen Slug-Register überein?
• Beschreiben title, optionales h1 und optionales seoTitle dieselbe Seite ohne irreführende Umfangsänderungen?
• Ist die Beschreibung 150–160 Zeichen lang, enthält sie den primären Begriff natürlich und bietet sie einen konkreten Grund zum Klicken?
• Existiert jedes referenzierte Bild, und ist imageAlt für das Bild, das gerendert wird, korrekt?
• Ist das Veröffentlichungsdatum erhalten, und wird jeder updated-Wert durch eine inhaltliche Änderung oder dokumentierte Überprüfung gestützt?
• Lösen Autor- und Prüfer-Bezeichner zu echten gepflegten Profilen auf, und hat der genannte Prüfer die Arbeit tatsächlich überprüft?
• Sind Keywords auf sechs bis acht nützliche Phrasen beschränkt und Taxonomiewerte aus kontrollierten Vokabularen entnommen?
• Verwendet das Canonical HTTPS, löst es zur bevorzugten Seite auf und stimmt es mit der Sitemap und internen Links überein?
• Enthält jedes [[faq]]-Element eine nützliche Frage und eine in sich geschlossene Antwort, die sichtbar in identischer Formulierung gerendert werden?
• Stimmt das generierte JSON-LD mit dem sichtbaren Inhalt überein, verwendet es stabile Bezeichner und besteht es die Syntaxvalidierung, ohne nicht unterstützte Typen zu beanspruchen?
• Sind Geheimnisse, private redaktionelle Notizen, nicht belegte Behauptungen und Nur-Body-Offenlegungen im Eintrag nicht vorhanden?

FAQ

Ist Frontmatter auf der veröffentlichten Seite sichtbar?

Der Quelleneintrag ist versteckt, aber Vorlagen können den Titel, Personen, Daten und FAQ rendern. Andere Felder versorgen Vorschauen, kanonische Tags, Feeds, Sitemaps, Schema und interne Systeme.

Soll das Entitätsfeld das Thema oder den Beitragstyp enthalten?

Es identifiziert den genauen Beitragstyp. Gemeinsame Themen gehören in die Taxonomie und Keywords, nicht anstelle der Dokumentenidentität.

Können der Titel, die H1 und der SEO-Titel unterschiedlich sein?

Ja. Die H1 kann natürlicher klingen und der SEO-Titel kann einen Unterscheidungsmerkmal hinzufügen, aber alle Versionen müssen dasselbe Versprechen machen.

Wann sollte das Aktualisierungsdatum geändert werden?

Ändern Sie es nach einer inhaltlichen faktenbezogenen Überprüfung oder Bearbeitung. Ändern Sie es nicht für Zeichensetzung, Styling, Vorlagenarbeit oder eine reine Datumsaktualisierung.

Warum werden FAQ-Fragen im Frontmatter gespeichert?

Das strukturierte Array ermöglicht es einer Quelle, sowohl das sichtbare FAQ als auch passendes FAQPage-JSON-LD zu rendern. Das verhindert, dass Schema von dem abweicht, was Leser überprüfen können.