thecatthatflies/content-site-design

Design von Inhaltsseiten

Eine Inhaltsseite existiert, damit ein Leser eine Seite findet, bestätigen kann, dass es die richtige ist, die gewünschte Antwort oder das Verständnis erhält und zur nächsten Sache übergeht. Die meisten Leser gelangen über eine Suche auf eine tiefe Seite, überfliegen sie, bevor sie lesen, und verlassen sie, sobald sie haben, was sie brauchen. Der häufigste Fehler von Modellen ist es, das Gehäuse zu gestalten (Hero, Karten, Seitenleiste, Dunkelmodus-Umschalter) und die eigene Struktur des Inhalts zu vernachlässigen: vage Titel, Überschriften, die nichts aussagen („Übersicht“, „Einleitung“), die Antwort drei Absätze weiter unten, eine Seite, die Tutorial, Referenz und Meinung mischt, Linktexte wie „hier“, keine Daten und eine Seitensuche, die nichts Nützliches liefert.

Wende die ranggeordneten Prinzipien von interface-guidelines an (Jeder kann es nutzen > Es sagt die Wahrheit > Es sagt, was es meint > Die Antwort kommt zuerst > Fehler sind überlebbar > Es bleibt bestehen > Das Mögliche ist sichtbar > Konvention > Poliert). Wenn dieser Skill installiert ist, lies zuerst seine SKILL.md. Schriftgröße für Fließtext, Zeilenlänge, Kontrast und Umfließen werden dort behandelt (references/human-interface.md Abschnitte 6 und 7); dieser Skill behandelt Inhaltsstruktur, Navigation, Suche und den KI-Leser.

Kurzüberblick

• Art der Seite: Dokumentation, Helpcenter, Wissensdatenbank, Redaktion/Blog oder eine Mischung. Gemischte Seiten benennen eine primäre Aufgabe pro Abschnitt.
• Leser und ihr Zugang: von der Suche zu einer tiefen Seite, von innerhalb eines Produkts („?“-Link), beim Surfen oder abonniert. Wer ist neu und wer Experte?
• Top-Aufgaben: die 10 bis 20 Fragen, die Leser mitbringen, in ihren eigenen Worten. Entnimm sie Suchprotokollen, Support-Tickets und Forenbeiträgen, nicht dem Organigramm.
• Inhaltstypen: für Docs: welche aus Tutorial, How-to, Referenz, Erklärung; für redaktionelle Inhalte: welche aus Nachrichten, Analysen, Meinungen, Guides.
• Aktualität: wie oft sich Inhalte ändern, wer jede Seite besitzt, was passiert, wenn sich eine Produktversion ändert.
• KI-Leser: Coding-Agenten, die Docs lesen, Such- und Antwortmaschinen, die Seiten zitieren, Browser-Agenten, die navigieren. Was müssen sie richtig machen?
• Wer schreibt: nur Mitarbeiter oder auch Nutzer (Kommentare, Community-Antworten)? Markiere von Externen geschriebene Inhalte.

Regeln

Tags: [E] empirisch, [S] Standard oder institutionell, [P] Praktiker, [J] Urteilsvermögen. Quellen befinden sich in den Referenzdateien.

Seiten

• Antwort zuerst. Die ersten beiden Absätze vermitteln die Hauptbotschaft; Details folgen in absteigender Wichtigkeit (umgekehrte Pyramide) [S: GOV.UK; P: NN/g]. Leser lesen nur einen Bruchteil der Wörter einer Seite, Nielsen schätzt etwa 20 bis 28 % [P: Nielsen 2008, basierend auf Daten von Weinreich et al. 2008].
• Eine Seite, eine Aufgabe. Ein Tutorial lehrt, ein How-to leitet an, eine Referenz beschreibt, eine Erklärung diskutiert; mische sie nicht auf einer Seite [P: Procida, Diátaxis].
• Titel sind einzigartig, spezifisch und vorderlastig, in den Worten des Lesers, etwa 65 Zeichen oder weniger, damit sie in Suchergebnissen nicht abgeschnitten werden [S: GOV.UK]. Aufgabenseiten beginnen mit einem Verb („API-Schlüssel rotieren“); Anleitungen zu einer Aufgabe verwenden die -ing-Form („API-Schlüssel rotieren lassen“) [S: GOV.UK].
• Eine Zusammenfassung unter dem Titel von einem Satz, 160 Zeichen oder weniger, die Wörter hinzufügt, die der Titel nicht enthält; derselbe Text dient als Meta-Beschreibung [S: GOV.UK].
• Überschriften sagen, was der Abschnitt sagt, vorderlastig, nicht „Übersicht“ oder „Weitere Informationen“, und nicht als Frage formuliert; der Inhalt ergibt auch ohne Überschriften noch Sinn [S: GOV.UK]. Überschriftsebenen folgen der Struktur: eine h1, keine ausgelassenen Ebenen [S: WCAG 1.3.1, 2.4.6].
• Kurze Sätze und Absätze, einfache Wörter. Teile Sätze, die etwa 25 Wörter überschreiten; halte Absätze bei fünf Sätzen oder weniger; erkläre einen Fachbegriff bei erster Verwendung [S: GOV.UK]. Spreche den Leser mit „Sie“ an, verwende Aktiv, Bedingung vor Anweisung („Um ein Projekt zu löschen, öffnen Sie Einstellungen“) [S: Google Entwickler-Styleguide].
• Nummerierte Listen für Schritte, Aufzählungslisten für Mengen, Tabellen für Vergleiche [S: Google Entwickler-Styleguide; GOV.UK].
• Für das Überfliegen formatieren: aussagekräftige Überschriften und vorderlastige Absätze wirken dem F-förmigen Scan entgegen, bei dem Leser die rechte Seite und die unteren Teile einer Seite überspringen [P: Pernice, NN/g 2017].
• Aussagekräftige Daten: „Zuletzt aktualisiert am 4. Nov. 2026“ mit einem kurzen Änderungshinweis für wesentliche Änderungen und ein Veröffentlichungsdatum bei Artikeln. Alte, aber noch korrekte Seiten tragen „Geprüft“ [S: GOV.UK Änderungshinweise; J].
• Fußnoten: GOV.UK verbietet sie für Service-Inhalte; wissenschaftliche und redaktionelle Langformen benötigen sie möglicherweise. Entscheide anhand der Frage, ob Leser Quellen überprüfen müssen [S: GOV.UK; J].

Links

• Linktext benennt das Ziel, vorderlastig und pro Ziel auf der Seite eindeutig; niemals „klicken Sie hier“, „weiterlesen“ oder „hier“ [S: GOV.UK, WCAG 2.4.4].
• Gib an, wenn ein Link die Seite verlässt, eine Datei öffnet oder die Sprache wechselt: „Preisblatt (PDF, 240 KB)“ [S: GOV.UK].
• Links dort, wo sie helfen, nicht am Ende gestapelt in „Weiterführende Literatur“; nächste Schritte am Ende einer Aufgabenseite sind in Ordnung, wenn sie spezifisch sind [S: GOV.UK].
• Jede Überschrift hat einen stabilen Anker (#schluessel-rotieren), mit einem sichtbaren Kopier-Link-Steuerelement. Wenn eine Überschrift umbenannt wird, bleibt der alte Anker funktionsfähig [J].
• URLs sind lesbar und permanent. Wenn eine Seite verschoben wird, leite die alte URL weiter; lass niemals Doc-Links 404 geben [J].

Navigation

• Leser landen tief. Jede Seite zeigt, wo sie sich befindet (Brotkrümel oder hervorgehobener Abschnitt) und was als nächstes und in der Nähe kommt [S: WCAG 2.4.8; P: NN/g Breadcrumbs].
• Navigationsbeschriftungen verwenden die Worte der Leser und sagen deren Inhalt voraus (Informationsduft) [E: Pirolli und Card 1999].
• Mindestens zwei Wege zu einer Seite: Navigation plus Suche oder eine Sitemap [S: WCAG 2.4.5].
• Ein Inhaltsverzeichnis auf der Seite für lange Seiten, generiert aus h2 und h3, das den aktuellen Abschnitt hervorhebt [J].
• Seitennummerierung oder „Mehr laden“ statt endlosem Scrollen für Archive und Suchergebnisse, damit Leser die Fußzeile erreichen, zu einer Stelle zurückkehren und eine Position teilen können [P: NN/g unendliches Scrollen].
• Docs: eine Seitenleiste, organisiert nach Leseaufgaben und Diátaxis-Typ, ein sichtbarer Versionswechsler, wenn Versionen sich unterscheiden, und ein Banner auf alten Versionsseiten, das auf die aktuelle Seite verweist [P: Procida; J].

Suche

• Suche ist ein primärer Pfad, kein Add-on. Das Suchfeld ist auf jeder Seite sichtbar, auf dem Desktop nicht hinter einem Icon versteckt [P: NN/g; J].
• Ergebnisse zeigen den Seitentitel, den Abschnitt oder Typ, einen Auszug mit den passenden Wörtern und das Datum. Tippfehler und Synonyme aus echten Suchanfragen werden toleriert [J].
• Seiten ohne Ergebnisse schlagen Korrekturen, allgemeinere Begriffe und Top-Seiten vor und protokollieren die Suchanfrage [J].
• Überprüfe monatlich Null-Ergebnis- und häufigste Suchanfragen; jede benennt eine fehlende Seite, ein fehlendes Synonym oder einen schlechten Titel [P: gängige Doc-Praxis; J].

Lesekomfort

• Schrifttart, Zeilenlänge, Zeilenabstand, Kontrast und Umfließen folgen der Grundlage. Auf Smartphones verstehen Leser kurze, einfache Texte genauso gut wie auf dem Desktop, verlangsamen sich jedoch bei schwierigen Texten; schwierige Inhalte benötigen daher eine zusätzliche Struktur auf mobilen Geräten [P: Moran, NN/g 2016].
• Keine Interstitials oder klebrigen Elemente, die Text verdecken; Werbung und Newsletter-Anfragen unterbrechen niemals den ersten Bildschirm der Antwort [S: WCAG 2.4.11 für Fokus; J].
• Bilder, die Informationen transportieren, haben Alt-Text, der die Information angibt; dekorative Bilder haben einen leeren Alt-Text [S: WCAG 1.1.1]. Diagramme haben eine Text-Erklärung in der Nähe [J].
• Codebeispiele sind Text, niemals Bilder, mit einer Kopierfunktion und einer Beschriftung der Sprache. Tabs für Sprachvarianten halten alle Varianten im DOM [J].
• Druck- und Lesemodi geben den Inhalt ohne Navigations-Chrome aus [J].

Für Agenten

• Der Inhalt ist im HTML, serverseitig gerendert, nicht durch Client-JavaScript nach dem Laden zusammengesetzt, damit Crawler und Agenten, die keine Skripte ausführen, ihn erhalten [J].
• Semantische Struktur ist die Schnittstelle: Überschriften, Listen, Tabellen, code und pre mit Sprachklassen, figure und figcaption [S: WCAG 1.3.1].
• Stabile, zitierbare URLs und Anker, eine kanonische URL pro Seite und ein Datum auf der Seite [J].
• Eine saubere Markdown-Kopie jeder Doc-Seite unter derselben URL mit angehängtem .md, verlinkt mit rel="alternate" type="text/markdown", ist ein kostengünstiger Weg, Coding-Agenten den Inhalt ohne Chrome zu geben. llms.txt im Stammverzeichnis der Site oder der Docs ist ein Community-Vorschlag; für allgemeine Seiten wurde eine geringe Nachfrage gemessen, aber es passt für Docs, die von Coding-Agenten gelesen werden [P: Howard, llms.txt; foundation agent-surfaces Abschnitt 6].
• Keine versteckten Anweisungen für Agenten im Seitentext, in Kommentaren oder unsichtbaren Elementen. Sie sind nicht von Prompt Injection zu unterscheiden [J; foundation oversight Abschnitt 5].
• Nutzer-generierte Inhalte (Kommentare, Community-Antworten, Forenbeiträge) werden im Markup und visuell als solche gekennzeichnet, mit Autor und Datum, damit Agenten und Menschen sie einordnen können [J].

Bauplan

1. Top-Aufgaben und Bestandsaufnahme der Inhalte: jede vorhandene oder geplante Seite mit Typ, Besitzer, letzter Überprüfung und der Aufgabe, die sie erfüllt. Lösche oder führe Seiten zusammen, die keine Aufgabe erfüllen.
2. Informationsarchitektur: Abschnitte aus Leseaufgaben und Inhaltstypen; beschrifte sie mit den Worten der Leser; teste die Beschriftungen mit einem Baumtest (Personen finden fünf Aufgaben in einem textbasierten Baum) [P: NN/g Baumtest].
3. Seitenvorlagen pro Inhaltstyp: Titel, Zusammenfassung, Daten, Textstruktur, nächste Schritte. Für Docs: Tutorial-, How-to-, Referenz- und Erklärungsvorlagen (references/docs.md).
4. Schreibe oder überarbeite zuerst die Seiten der Top-Aufgaben mit references/writing.md; eine vollständige, gute Seite ist besser als zwanzig Stubs.
5. Semantisches HTML-Gerüst: Landmarks, Skip-Link, Brotkrümel, Seitenleiste als nav mit aria-current, Inhaltsverzeichnis auf der Seite, Fußzeile. Serverseitig gerendert.
6. Suche mit echten Suchanfragen aus Protokollen oder der Top-Aufgaben-Liste; optimiere Synonyme.
7. Agenten-Schicht: kanonische URLs, Anker, Markdown-Kopien, Sitemap, optional llms.txt.
8. Style für langes Lesen; die Marke bestimmt das Aussehen (brand-identity).
9. Überprüfen (unten).

Überprüfen

1. Gerendertes Audit auf einer Startseite, einem langen Artikel oder einer Referenzseite, einer Suchergebnisseite und einer 404-Seite:

   node <interface-guidelines>/scripts/audit.mjs <dist-or-url> --out audit-output
   

2. Top-Aufgaben-Test: Beginne für jede Top-Aufgabe mit einer Suchmaschinenabfrage oder der Startseite und erreiche die Antwort. Zähle die Schritte und notiere, wo der Duft nachgelassen hat. Führe es einmal als Person mit Tastatur auf Telefonbreite durch und einmal als Agent mit nur dem Accessibility-Snapshot.

3. Inhalts-Lint auf jeder Seite (references/writing.md Abschnitt 8 enthält einen Skriptentwurf): eine h1; keine ausgelassenen Überschriftsebenen; Titel eindeutig und 65 Zeichen oder weniger; Zusammenfassung vorhanden und 160 oder weniger; keine generischen Überschriften oder Linktexte („Übersicht“, „klicken Sie hier“, „weiterlesen“); Sätze über 25 Wörter markiert; Bilder mit fehlendem Alt; Datum der letzten Aktualisierung vorhanden.

4. Links: Crawle nach defekten internen Links und fehlenden Ankern; überprüfe, ob alte URLs weiterleiten.

5. No-JS-Check: Rufe eine Seite mit curl auf und bestätige, dass der Hauptinhalt und die Überschriften im HTML sind.

6. Suche: Führe die 20 häufigsten Suchanfragen und 5 Rechtschreibfehler aus; die richtige Seite ist unter den ersten drei.

7. Agenten-Lesetest: Gib einem Agenten nur die URL einer Doc-Seite oder ihrer .md-Kopie und bitte ihn, die Aufgabe auszuführen; überprüfe, ob er die aktuelle Version verwendet und den richtigen Abschnittsanker zitiert.

Fallstricke

• Kartenraster mit Artikel-Teaser als Doc-Startseite, ohne Aufgabeneinstiegspunkte oder Suche.
• Überschriften mit den Namen „Einleitung“, „Übersicht“, „Details“ oder als Fragen formuliert.
• FAQ-Seiten, die nicht zusammenhängende Fragen sammeln, anstatt sie auf den Seiten zu beantworten, auf denen sie auftauchen.
• Die Antwort unter einem langen Vorwort darüber, warum das Thema wichtig ist.
• Ein Tutorial, das auf halbem Weg zur Referenz wird, oder eine mit Meinungen aufgeblähte Referenz.
• Undatierte Artikel und „zuletzt aktualisiert“ auf jeder Seite auf das Erstellungsdatum gesetzt.
• Inhalte, die nur durch Client-JavaScript gerendert werden, Tabs, deren versteckte Panels nicht im DOM sind, Code als Screenshots.
• Unendliches Scrollen in Archiven und Suchergebnissen.
• Anweisungstexte für KI-Crawler, die in der Seite versteckt sind.
• Neugestaltung einer Doc-Site, während Titel, Überschriften und Suche kaputt bleiben.

Referenzen

Datei	Lesen, wenn
references/writing.md	Schreiben oder Bearbeiten von Seiten: Titel, Zusammenfassungen, Überschriften, Sätze, Links, Daten, Zahlen, redaktionelle Besonderheiten und ein Lint-Entwurf
references/docs.md	Dokumentationen und Helpcenter: Diátaxis-Typen mit Vorlagen, API-Referenzseiten, Codebeispiele, Versionen, Changelogs, Docs für Coding-Agenten
references/navigation-search.md	Seitenstruktur, Beschriftungen, Seitenleisten, Brotkrümel, Inhaltsverzeichnisse, Archive, Suchergebnisse, 404-Seiten