Blöcke für verwandte Inhalte: Regeln für interne Verlinkung

Ein Block für verwandte Inhalte ist eine kurze, manuell ausgewählte Sammlung von Links, die am Ende des Hauptinhalts platziert wird. Er führt den Leser zur nützlichsten nächsten Seite und leitet gleichzeitig interne Autorität über denselben Link weiter. Jedes Ziel muss einen redaktionellen Grund für seine Existenz haben; geteilte Schlagworte allein reichen nicht aus.

Das dargestellte Beispiel ist bewusst schlicht gehalten. Die Überschrift erklärt die Auswahl, jeder Anker sagt das Ziel voraus und jeder Grund sagt dem Leser, warum diese Seite als Nächstes kommt. Der Block konkurriert nicht mit dem Artikel, den er abschließt.

Warum dieses Element wichtig ist

Das Beenden einer nützlichen Seite schafft einen Entscheidungspunkt. Der Leser versteht vielleicht das unmittelbare Thema, muss es aber dennoch anwenden, Optionen vergleichen, eine Voraussetzung lernen oder sich einem Produkt zuwenden. Ein Block für verwandte Inhalte reduziert den Aufwand, diesen nächsten Schritt zu finden. Er bietet eine kleine Auswahl zielgerichteter Wege in dem Moment, in dem der Leser bereit ist zu wählen, anstatt ihn aufzufordern, zur globalen Navigation zurückzukehren oder erneut zu suchen.

Die zweite Aufgabe ist architektonisch. Interne Autorität ist die Bedeutung und kontextuelle Relevanz, die Links dabei helfen, zwischen Seiten derselben Website zu verteilen. Ein Link erzeugt eine Kante zwischen zwei Dokumenten. Seine Position, sein Anker und seine Erklärung sagen den Retrieval-Systemen, was diese Kante repräsentiert: welche Seite die breite Autorität ist, welche ein Unterthema abdeckt und welche ein angrenzendes Bedürfnis beantwortet.

Maschinelle Extrahierbarkeit bedeutet, dass ein automatisiertes System diese Beziehungen aus dem HTML wiederherstellen kann, ohne anhand des Layouts raten zu müssen. Ein semantischer Navigationsbereich, eine sichtbare Überschrift, gewöhnliche crawlbare Links, beschreibende Anker und ein Eintrag pro Ziel legen einen klaren Satz von Quelle-Beziehung-Ziel-Aussagen offen. Nur-JavaScript-Karussells, Nur-Bild-Karten und generische Anker verschleiern diese Aussagen, selbst wenn sie ausgefeilt aussehen.

Beide Aufgaben müssen einer Überprüfung standhalten. Ein Block, der Klicks erzielt, aber Autorität an unzusammenhängende Seiten sendet, schadet dem Inhaltsmodell; eine korrekte Clusterkarte mit irrelevanten Links verschwendet den Entscheidungspunkt des Lesers.

Wann es verwendet wird

Verwenden Sie dieses Element, wenn die Seite zwei bis fünf glaubwürdige nächste Ziele hat und die Beziehung in einem Satz dargestellt werden kann. Es gehört zu dauerhaften Bildungsinhalten, kommerziellen Erklärseiten, Vergleichen, Produkt- und Kategorieseiten, Anwendungsfallseiten und Fallstudien, wenn eine andere Seite die gleiche Aufgabe oder Entscheidung tatsächlich voranbringt.

Fügen Sie es nicht einfach hinzu, weil eine Vorlage leeren Platz hat. Eine reine Konvertierungsseite mit einer einzigen notwendigen Aktion benötigt möglicherweise nur ihren abschließenden Aufruf zum Handeln. Ein rechtlicher Hinweis, ein Kontobildschirm, ein Support-Vorfall oder eine kurze Hilfsseite haben möglicherweise keine sinnvolle redaktionelle Fortsetzung. Ein Index, dessen Hauptteil bereits aus Navigationskarten besteht, benötigt keine zweite Liste, die sie wiederholt.

Häufige Beinahe-Fehler sind:

• Ein Schlagwort-Feed beantwortet „Was teilt dieses Label?“, nicht „Was sollte dieser Leser als Nächstes tun?“ Zwei Artikel mit dem Schlagwort „Analytik“ können unterschiedliche Zielgruppen und Phasen bedienen.
• Neueste Beiträge belohnen das Veröffentlichungsdatum statt der Relevanz. Aktualität ist nützlich für die Nachrichtenentdeckung, aber kein Beziehungsmodell.
• Beliebte Beiträge optimieren auf Gesamtverkehr, nicht auf die aktuelle Frage.
• Eine Fußzeilen-Sitemap unterstützt die breite Entdeckung, nicht einen kleinen redaktionell ausgewählten Pfad.
• Eine Vorher-/Nächstes-Steuerung spiegelt die Veröffentlichungsreihenfolge wider. Sie zählt nur, wenn diese Reihenfolge selbst ein bewusster Kurs oder eine Abfolge ist.
• Kontextbezogene Inline-Links erklären Begriffe oder untermauern Behauptungen am Punkt des Bedarfs. Sie ergänzen diesen Block, ersetzen aber nicht seine Entscheidungsfunktion am Seitenende.

Die Auswahl erfolgt standardmäßig manuell. Für jeden vorgeschlagenen Link notiert der Redakteur einen Grund wie „wendet die Methode an“, „definiert die Voraussetzung“, „vergleicht die beiden hier vorgestellten Optionen“ oder „zeigt Belege in der Praxis“. Wenn der Grund lediglich „gleiches Schlagwort“ lautet, entfernen Sie den Eintrag.

Automatische Auswahl ist in Nachrichtenarchiven, nutzergenerierten Sammlungen oder Beständen akzeptabel, die zu groß und zu volatil für eine Einzelpflege sind. Auch dort sind ein kontrollierter Kandidatenpool, Ausschlüsse für die aktuelle URL und abgelaufene Seiten, Aktualität wo Zeit eine Rolle spielt, Relevanz über ein Schlagwort hinaus, ein stabiler Tie-Breaker und eine redaktionelle Überschreibmöglichkeit erforderlich.

Wo es platziert wird

Platzieren Sie den Block nach dem vollständigen Hauptteil und nach dem Quellenblock, aber vor dem abschließenden Aufruf zum Handeln. Der Grund ist sequenziell: Quellen schließen die Belegpflicht der aktuellen Seite ab; verwandte Inhalte bieten den nächsten Lern- oder Bewertungspfad; der abschließende Aufruf zum Handeln bietet den kommerziellen oder produktbezogenen Pfad. Wenn eine Seite keinen Quellenblock hat, folgen die verwandten Inhalte auf den letzten inhaltlichen Abschnitt.

Platzieren Sie keinen zweiten Block für verwandte Inhalte an anderer Stelle auf der Seite. Setzen Sie ihn nicht neben eine duplizierte Vorher-/Nächstes-Navigation, eine dichte Schlagwortwolke oder eine andere Sammlung mit dem Titel „Das könnte Ihnen auch gefallen.“ Ein klarer Empfehlungsbereich ist genug.

Anatomie

Dargestellte Legende:

1. Abschnittsüberschrift: benennt die Beziehung, wie „Wenden Sie an, was Sie gelernt haben“ oder „Vergleichen Sie die nächsten Optionen.“ Generisches „Verwandt“ ist nur akzeptabel, wenn die Ziele tatsächlich verschiedene Aktionen umfassen.
2. Eintragstitel: liefert den beschreibenden Anker und sagt den primären Wert des Ziels voraus.
3. Ziel-URL: löst auf eine kanonische, crawlbare interne URL ohne Weiterleitungskette auf.
4. Vorschaubild: unterscheidet optional ein Ziel, wenn Bildmaterial echte identifizierende Informationen trägt.
5. Einzeiliger Grund: erklärt optional, warum diese Seite der logische nächste Schritt ist; es wird dringend empfohlen, wenn die Beziehung aus dem Titel nicht offensichtlich ist.
6. Blockbegrenzung: gruppiert die Links als Navigation, ohne die gesamte Karte zu einem mehrdeutigen Klickziel zu machen.

Die Legende gehört in die Seite und nicht in das Bild, damit sie auswählbar, übersetzbar und für assistive Technologien verfügbar bleibt.

Designbeispiele

Die Varianten ändern die Informationsdichte, nicht die redaktionelle Logik.

Nur Text: der Standard, wenn die Ziel-Titel die Beziehung klar machen.

Mit Gründen: der Standard für verschiedene Journey-Phasen. Der Grund fügt die Beziehung hinzu, anstatt den Titel zu wiederholen.

Mit Vorschaubildern: reserviert für Fälle, in denen originäres Bildmaterial zur Wiedererkennung beiträgt. Bilder benötigen Abmessungen und nützlichen Alternativtext oder einen leeren Alternativtext, wenn der Titel das Ziel bereits benennt.

Säulenübergreifend: macht Beziehungen zwischen Beitragstypen, Elementen und Geschäftsanwendungen explizit. Es wird aus überprüftem Frontmatter generiert, nicht aus Schlagworten.

Parameter

Zwei Einträge sind nur erlaubt, wenn die Seite eine enge, glaubwürdige Gabelung hat. Drei bis fünf ist der normale Bereich: genug Auswahl, um verschiedene nächste Bedürfnisse zu bedienen, aber wenige genug, dass jeder Link sichtbar und absichtsvoll bleibt. Sechs ist eine harte Ausnahme für eine Säule, die ein vollständiges kleines Cluster offenlegen muss. Mehr als sechs wird zu einem Verzeichnis, schwächt das redaktionelle Signal jeder Kante und macht mobiles Scannen aufwändig.

Ein weggelassenes Titelattribut kann aus der ersten Überschrift im Eintragsbody abgeleitet werden. Geben Sie nicht beide mit unterschiedlichem Text an. Ein Grund kann im Attribut für einen einfachen Satz oder im Body leben, wenn er Inline-Betonung benötigt; er darf nicht zweimal erscheinen.

Syntax und Codebeispiele

Der kanonische Komponentenname ist related-content. Die verschachtelte ::item{}-Form hält die Felder jedes Ziels zusammen und verhindert, dass parallele Arrays auseinanderdriften.

Portable Markdown-Direktive

:::related-content{heading="Mit dem Playbook fortfahren" variant="reason"}
::item{title="Eine zuverlässige Anleitung schreiben" url="/seo-playbook/post-types/how-to-guide/" reason="Die Elementregeln in eine vollständige Anleitungsseite umsetzen."}
::item{title="Einen ultimativen Leitfaden strukturieren" url="/seo-playbook/post-types/ultimate-guide/" reason="Dieses Element mit einer breiten Säule und ihren unterstützenden Speichen verbinden."}
::item{title="Eine Anwendungsfallseite erstellen" url="/seo-playbook/post-types/use-case-page/" reason="Bildungsabsicht in eine spezifische Zielgruppe und ein spezifisches Ergebnis übertragen."}
:::

Hugo-Shortcode

{{< related-content heading="Mit dem Playbook fortfahren" variant="reason" >}}
  {{< item title="Eine zuverlässige Anleitung schreiben" url="/seo-playbook/post-types/how-to-guide/" reason="Die Elementregeln in eine vollständige Anleitungsseite umsetzen." />}}
  {{< item title="Einen ultimativen Leitfaden strukturieren" url="/seo-playbook/post-types/ultimate-guide/" reason="Dieses Element mit einer breiten Säule und ihren unterstützenden Speichen verbinden." />}}
  {{< item title="Eine Anwendungsfallseite erstellen" url="/seo-playbook/post-types/use-case-page/" reason="Bildungsabsicht in eine spezifische Zielgruppe und ein spezifisches Ergebnis übertragen." />}}
{{< /related-content >}}

Dies ist der portable Zielvertrag, keine Behauptung, dass dieses Repository den Shortcode registriert. Das Live-Beispiel verwendet semantisches HTML und fügt keine Layout-Abhängigkeit hinzu.

WordPress-Block oder Shortcode

<!-- wp:amicited/related-content {"heading":"Mit dem Playbook fortfahren","variant":"reason"} -->
[related_item title="Eine zuverlässige Anleitung schreiben" url="/seo-playbook/post-types/how-to-guide/" reason="Die Elementregeln in eine vollständige Anleitungsseite umsetzen."]
[related_item title="Einen ultimativen Leitfaden strukturieren" url="/seo-playbook/post-types/ultimate-guide/" reason="Dieses Element mit einer breiten Säule und ihren unterstützenden Speichen verbinden."]
[related_item title="Eine Anwendungsfallseite erstellen" url="/seo-playbook/post-types/use-case-page/" reason="Bildungsabsicht in eine spezifische Zielgruppe und ein spezifisches Ergebnis übertragen."]
<!-- /wp:amicited/related-content -->

WordPress sollte einen registrierten dynamischen Block mit verschachtelten Eintragssteuerungen verwenden. Die Shortcode-Form ist für Systeme gedacht, die keine verschachtelten Blöcke speichern können, und muss vor der Veröffentlichung registriert werden.

Beispiele

Gut: Jeder Link beantwortet ein anderes nächstes Bedürfnis

:::related-content{heading="Die Methode in die Praxis umsetzen" variant="reason"}
::item{title="Die Pre-Publish-QA-Checkliste durchführen" url="/seo-playbook/process/checklists/pre-publish-qa/" reason="Links, Belege, Barrierefreiheit und Seitenstruktur vor der Veröffentlichung überprüfen."}
::item{title="Eine Anleitung erstellen" url="/seo-playbook/post-types/how-to-guide/" reason="Das Element innerhalb eines vollständigen Anleitungsformats anwenden."}
::item{title="Das Playbook für SaaS anpassen" url="/seo-playbook/business-types/saas/" reason="Die gemeinsamen Regeln in eine produktgeführte Content-Journey übersetzen."}
:::

Dies funktioniert, weil die Ziele unterschiedlich, aber verbunden sind: Überprüfung, Implementierung und geschäftliche Anpassung. Die Anker geben an, was jede Seite liefert, und die Gründe erklären die Beziehung zur aktuellen Seite.

Schlecht: Das Schlagwort-Widget als redaktionelle Auswahl getarnt

:::related-content{heading="Das könnte Ihnen auch gefallen"}
::item{title="Weiterlesen" url="/blog/new-office/"}
::item{title="Hier klicken" url="/features/ai-visibility/"}
::item{title="Neuester Beitrag" url="/blog/quarterly-roundup/"}
::item{title="SEO" url="/seo-playbook/"}
::item{title="Mehr SEO" url="/blog/old-seo-notes/"}
::item{title="Ein weiterer Artikel" url="/academy/how-to-export-prompt-data/"}
::item{title="Empfohlen" url="/case-studies/hz-containers/"}
:::

Das Beispiel scheitert, selbst wenn jede URL aufgelöst werden kann. Sieben Auswahlmöglichkeiten überschreiten den Bereich. Die Anker sagen das Ziel nicht voraus. Die Ziele mischen Unternehmensnachrichten, Produkt, Archiv, Academy und Fallstudien-Absicht ohne angegebene Gründe. „Neuester“ ist eine Datumsregel, „SEO“ ist zu breit, und nichts beweist, dass die Links die nächste Aufgabe dieses Lesers bedienen.

Der Cluster-Vertrag

Ein Themencluster ist eine geplante Gruppe von Seiten zu einem Thema. Seine Säule ist die breite Seite, die das Thema organisiert; seine Speichen sind schmalere Seiten, die Teile davon beantworten. Der Block für verwandte Inhalte verwandelt diesen Plan in tatsächliche HTML-Links:

• Jede Speiche verlinkt hinauf zu ihrer Säule. Dies sagt dem Leser, wohin die schmale Antwort gehört, und verhindert, dass die Speiche zu einem isolierten Endpunkt wird.
• Die Säule verlinkt hinunter zu jeder aktuellen Speiche. Wenn das Cluster mehr als sechs Speichen hat, verwenden Sie organisierte Abschnitte im Säulenkörper, anstatt die gesamte Sammlung in einen Block für verwandte Inhalte zu zwingen.
• Laterale Links verbinden eine Speiche mit einer anderen nur, wenn ein Leser die Beziehung zum nächsten Schritt angeben kann. Ein gemeinsames übergeordnetes Element reicht nicht aus.
• Jede Kante ist bidirektional, wenn beide Richtungen einem Leser helfen. Der umgekehrte Anker und Grund können sich unterscheiden, weil die Reise unterschiedlich ist.
• Das Entfernen, Zusammenführen oder Weiterleiten einer Seite löst eine Überprüfung jeder gespeicherten Kante aus, die auf sie verweist.

Innerhalb dieses Playbooks verlinkt eine Beitragstyp-Seite auf die Elemente, die sie benötigt, und auf die Geschäftstypen, die sie anpassen. Eine Elementseite verlinkt zurück auf die Beitragstypen, die sie verwenden. Diese Beziehungen werden aus überprüftem Frontmatter unter den säulenübergreifenden Regeln generiert: Das postTypes-Array dieser Seite ist die Quelle für ihre Beitragstyp-Links, während die entsprechenden Beitragstyp-Metadaten die Rückkante liefern. Die Generierung übernimmt die Darstellung; Redakteure entscheiden dennoch, ob die Beziehung in die Metadaten gehört.

Die umfassenderen Element-Schreibregeln bestimmen, wie diese Metadaten portabel bleiben. Reparieren Sie eine fehlende redaktionelle Beziehung niemals durch das Hinzufügen eines Schlagworts in der Hoffnung, dass ein Widget die richtige Wahl trifft.

Ankertext-Regeln

Ankertext ist die sichtbare, klickbare Formulierung eines Links. Schreiben Sie ihn so, dass ein Leser das Ziel vorhersagen kann, ohne die URL zu lesen. „Eine Anleitung erstellen“ ist nützlich; „weiterlesen“, „hier klicken“, „mehr erfahren“ und eine nackte URL sind es nicht.

Variieren Sie Anker natürlich, während Sie das Thema des Ziels bewahren. „Eine Anleitung erstellen“ und „Eine Anleitungsseite strukturieren“ funktionieren; unzusammenhängende Keyword-Synonyme nicht. Versprechen Sie niemals eine Vorlage, einen Rechner, einen Preis, eine Studie oder eine Checkliste, die das Ziel nicht bietet.

Innerhalb des Blocks sollten Titel-Anker eindeutig sein. Wenn zwei Ziele denselben Titel verwenden würden, fügen Sie die unterscheidende Zielgruppe, Methode oder das unterscheidende Ergebnis hinzu. Halten Sie den optionalen Grund außerhalb des Ankers, sodass das Klickziel prägnant bleibt und die Linklisten assistiver Technologien nützlich bleiben.

Schema-Markup und Barrierefreiheit

Es ist kein spezieller JSON-LD-Typ erforderlich. JSON-LD ist ein skriptbasiertes Format für strukturierte Daten, und Schema.org ist das gemeinsame Vokabular, das üblicherweise damit kodiert wird. Die Links bleiben normalerweise Teil des umgebenden Article, TechArticle, Product oder WebPage. Erfinden Sie keinen RelatedContent-Schema-Typ.

Ein ItemList darf den Block nur beschreiben, wenn es sich tatsächlich um eine geordnete oder benannte redaktionelle Liste handelt und die websiteweite Schema-Richtlinie dies vorsieht. Wenn verwendet, muss itemListElement mit der sichtbaren Reihenfolge, URLs und Namen übereinstimmen. Fügen Sie keine versteckten Ziele oder synthetischen Bewertungen hinzu. Eine Breadcrumb ist eine andere Beziehung und darf diese Links nicht absorbieren.

Barrierefreiheit beginnt mit einer <nav>-Landmarke, also einem Bereich, den assistive Technologien als Navigation identifizieren können. Geben Sie ihr eine sichtbare Überschrift, die über aria-labelledby verbunden ist; ARIA ist der Satz von Attributen, die verwendet werden, um Schnittstellennamen und -zustände offenzulegen, wenn natives HTML allein nicht ausreicht. Verwenden Sie ein <ul>, da die Reihenfolge normalerweise keine Rangfolge trägt. Bewahren Sie den sichtbaren Tastaturfokus, machen Sie den Titel zum primären Link und vermeiden Sie es, eine interaktive Karte in einen anderen Link zu verschachteln.

Alternativtext von Vorschaubildern darf den verlinkten Titel nicht duplizieren. Verwenden Sie leeren Alternativtext für ein dekoratives Vorschaubild. Wenn das Bild eindeutige Informationen beiträgt, beschreiben Sie nur diese Informationen. Der Block muss mit deaktivierten Bildern oder JavaScript vollständig bleiben, und er darf den Tastaturfokus nicht verschieben, wenn Empfehlungen aktualisiert werden.

Schreibregeln

Verwenden Sie standardmäßig drei bis fünf Einträge, zwei für eine enge Gabelung und nicht mehr als sechs für einen dokumentierten Bedarf eines kleinen Clusters. Schreiben Sie eine Überschrift von zwei bis acht Wörtern, Titel-Anker von drei bis zwölf Wörtern und optionale Gründe von acht bis zweiundzwanzig Wörtern. Gründe verwenden einen Satz, aktive Stimme und eine konkrete Beziehung: anwenden, vergleichen, überprüfen, definieren, diagnostizieren oder Belege sehen.

Jeder Eintrag benötigt einen eigenen redaktionellen Grund im Inhaltsmodell, auch wenn der Grund nicht dargestellt wird. Überprüfen Sie Titel, nachdem sich Zielüberschriften geändert haben. Verwenden Sie kanonische interne URLs mit führendem und abschließendem Schrägstrich. Entfernen Sie Tracking-Parameter, Fragmente, die keine stabilen Abschnitte identifizieren, Weiterleitungen und Links zurück zur aktuellen Seite.

Platzieren Sie niemals Werbung, Autorenbiografien, Social-Follow-Buttons, Newsletter-Formulare, Schlagwortwolken, nicht zusammenhängende Werbeaktionen oder Quellenangaben innerhalb dieses Elements. Mischen Sie keine externen Leseempfehlungen mit internen nächsten Schritten; externe Belege gehören in den Quellenblock. Verwenden Sie keine Abzeichen wie „am besten“, „beliebt“ oder „empfohlen“, es sei denn, die Seite definiert und begründet die Auswahlbasis.

Der Ton sollte hilfreich und spezifisch sein, nicht dringlich. Vermeiden Sie „muss gelesen werden“, „nicht verpassen“, künstliche Verknappung und Behauptungen, dass das Ziel umfassend ist, es sei denn, sein Umfang rechtfertigt dieses Wort. Der Block empfiehlt einen Weg; er erzeugt keine Wichtigkeit.

Beitragstypen, die es verwenden

Das Frontmatter-postTypes-Array ist die Quelle der Wahrheit für die folgenden säulenübergreifenden Beziehungen.

Nicht jeder Kandidat muss auf jeder Seite dargestellt werden. Der Beitragstyp definiert die berechtigte Beziehung; der Seitenredakteur wählt die Ziele aus, die für das tatsächliche Thema und die Reise sinnvoll sind.

QA-Checkliste

• Der Block erscheint einmal, nach den Quellen und vor dem abschließenden Aufruf zum Handeln.
• Die Seite enthält zwei bis fünf Links oder einen dokumentierten Grund für die Verwendung von sechs.
• Jeder Eintrag hat einen aufgezeichneten redaktionellen Grund, der über ein gemeinsames Schlagwort, eine Kategorie oder ein Veröffentlichungsdatum hinausgeht.
• Jeder Anker sagt voraus, was das Ziel tatsächlich liefert, und vermeidet „weiterlesen“, „hier klicken“ und ähnliche generische Formulierungen.
• Die Sammlung unterstützt den Cluster-Vertrag: Speiche hinauf, Säule hinunter und lateral nur bei tatsächlicher Verwandtschaft.
• Die aktuelle URL ist ausgeschlossen, Ziele sind kanonisch, und kein Link ist auf eine Weiterleitung oder einen Tracking-Parameter angewiesen.
• Das Frontmatter der verwandten Inhalte stimmt mit den dargestellten säulenübergreifenden Links überein.
• Der Block bleibt lesbar, navigierbar und vollständig ohne Vorschaubilder oder JavaScript.
• Der Navigationsbereich hat eine sichtbare Überschrift und einen barrierefreien Namen; der Tastaturfokus ist sichtbar.
• Vorschaubilder sind vorhanden, bieten identifizierenden Mehrwert, reservieren Abmessungen und verwenden korrekten Alternativtext.
• Gründe fügen eine Beziehung zum nächsten Schritt hinzu, anstatt Titel zu wiederholen.
• Quellen, Anzeigen, Formulare, Social-Media-Links und nicht zusammenhängende Werbeaktionen bleiben außerhalb des Blocks.
• Alle ItemList-strukturierten Daten stimmen exakt mit den sichtbaren Elementen und der Reihenfolge überein.
• Die mobile Darstellung zeigt jeden Titel und Grund ohne verstecktes horizontales Karussell.

Ein Prüfer sollte bloß plausible Links ablehnen. Jeder muss der richtige nächste Schritt sein, eine echte architektonische Kante ausdrücken und im HTML klar bleiben.

FAQ

Die Academy-Vorlage rendert die FAQ-Einträge aus dem Frontmatter.