Folge 004: Seiten sind nur Dateien und trotzdem schlau strukturiert

Keine Datenbank, kein WordPress-Monster: Pages sind normale Markdown-Dateien unter src/content/pages/. Collections sind die Typen: Pages, Articles, Menüs, Tags, Glossar, Bausteine (blocks). Warum Issues dafür sinnvoll sind: Folge 002. Bausteine im Alltag: Folge 020.

Was config.yml macht

In public/admin/config.yml steht in YAML (strukturierte Textdatei), was Redakteure im CMS sehen: Titel, Beschreibung, Body, …

Früher hing das Menü an jeder Seite, bei hautuu gibt’s eine eigene menus-Collection. Für Pages kam hinzu:

• parent (im CMS Übergeordnete Seite): Verweis auf eine übergeordnete Seite → URL wie /ueber-uns/preise/ statt flach /preise/.

Eine Seite angucken

src/content/pages/index/index.md = Startseite.

• Oben Frontmatter = ausgefüllte Felder (im CMS links: Titel, Description (Beschreibung), Übergeordnete Seite, SEO usw.).
• Darunter Body (Inhalt) = Markdown (rechts im CMS eine einfache Preview).

Du speicherst → Datei ändert sich → beim Build wird HTML. In der IDE-Preview siehst du ungefähr, was GitHub auch rendert.

Articles & Tags (kurz)

Articles kriegen Tags wie Hashtags, keine Kategorien-Wüste. Verwandte Artikel per Extra-Feld wäre möglich; Tags reichen oft.

SEO: einmal definieren

Statt überall lose Felder zu kopieren: ein SEO-Objekt für mehrere Collections (DRY = don’t repeat yourself).

Praktisch:

• index / noindex: Impressum & Datenschutz oft noindex, damit Google nicht den Legal-Text als Hauptinhalt feiert.
• Tab-Titel und Meta-Beschreibung getrennt vom sichtbaren Seitentitel.

Backlog-Idee: optionales Inhaltsverzeichnis oben bei langen Texten.

Editor heute, CMS morgen

Jetzt tippst du Markdown oder lässt Cursor schreiben, später Sveltia unter /admin/ (Folge 013 zeigt PAT und ersten Login): links Seiten (Collection pages), Felder wie Titel, Status (Veröffentlicht = live nach Push). Gleiche Felder, gleiche Dateien, gleiche Git-History.