Zum Inhalt springen

Astro Content Collections – Typsichere Inhalte

Astro Content Collections sind ein eingebautes System für strukturierte Inhalte — Artikel, Produkte, Team-Mitglieder oder jede andere Art von strukturierten Daten. Mit einem Zod-Schema werden Frontmatter-Felder typsicher validiert: Falsche Felder brechen den Build, statt stillschweigend zu verschwinden. Das Ergebnis ist ein Content-System, das sich wie ein leichtgewichtiges CMS verhält — ohne externe Abhängigkeiten, ohne API-Calls, mit voller TypeScript-Unterstützung.

Wie Content Collections funktionieren

Content Collections liegen in src/content/. Jeder Unterordner ist eine Collection — zum Beispiel src/content/blog/ für Blog-Artikel oder src/content/weboptimierung/seo/ für SEO-Artikel. Dateien können Markdown (.md), MDX (.mdx) oder JSON sein. Das Schema wird in src/content/config.ts (oder content.config.ts) mit Zod definiert. Astro generiert daraus TypeScript-Typen, die überall in der Anwendung verfügbar sind.

Schema mit Zod definieren

Ein typisches Collection-Schema mit Zod sieht so aus — alle Felder sind typsicher, optionale Felder mit .optional() markiert, Arrays mit z.array() definiert. Astro prüft beim Build jede Datei gegen dieses Schema.

Inhalte abfragen mit getCollection()

getCollection('collection-name') gibt alle Einträge einer Collection zurück. Das Ergebnis ist vollständig typisiert — TypeScript kennt alle Frontmatter-Felder und zeigt Fehler wenn auf nicht-existente Felder zugegriffen wird. Filtern, Sortieren und Paginieren ist direkt mit JavaScript Array-Methoden möglich: .filter(), .sort(), .slice(). Keine eigene Query-Sprache, kein ORM — reines JavaScript.

Dynamische Routen mit Collections

Für dynamische Routen (eine Seite pro Artikel) kombiniert man Content Collections mit File-based Routing. Eine Datei src/pages/[pillar]/[slug].astro mit getStaticPaths() generiert für jeden Collection-Eintrag eine eigene Seite. Bei output: 'server' (SSR) können einzelne Routen mit export const prerender = true statisch vorgerendert werden — das kombiniert die Performance von Static Generation mit der Flexibilität von SSR.

MDX — Komponenten in Markdown

MDX erweitert Markdown um die Möglichkeit, React- oder Astro-Komponenten direkt im Content zu verwenden. Das ermöglicht reichhaltige Inhalte ohne eigenes CMS: Infoboxen, FAQ-Akkordeons, interaktive Demos — alles direkt im Artikel. Mit dem Block-System auf dieser Website sind Komponenten noch einen Schritt weiter abstrahiert: Sie werden im Frontmatter als blocks-Array definiert, kein Import nötig, keine Komponenten-Syntax im Content.

Content Collections vs. externes CMS

Setup

Sofort, kein Extra-Service — vs. CMS installieren/konfigurieren

Typsicherheit

Vollständig (Zod + TypeScript) — vs. Abhängig vom CMS

Versionierung

Git (automatisch) — vs. Meist separate Lösung

Performance

Maximal (kein API-Overhead) — vs. API-Calls im Build

Redakteur-UI

Code-Editor / YAML — vs. Web-Interface

Skalierbarkeit

Bis ~10.000 Dateien gut — vs. Unbegrenzt beim externen CMS

Häufig gestellte Fragen

Wie viele Dateien kann eine Content Collection haben?

Astro Content Collections funktionieren gut bis etwa 10.000 Dateien — dann steigen Build-Zeiten spürbar. Für die meisten Websites (selbst große Blogs) ist das kein Problem. Bei sehr großen Content-Mengen ist ein externes CMS mit API effizienter.

Kann ich Collection-Eintraege zwischen Collections verlinken?

Ja — Zod unterstuetzt reference() fuer Collection-Referenzen. Ein Blog-Artikel kann auf einen Autoren-Eintrag referenzieren, Astro loest diese Referenz typsicher auf. Das ermoeglicht relationale Datenstrukturen ohne Datenbank.

Unterstuetzen Content Collections Bilder?

Ja — mit image() im Zod-Schema werden Bild-Pfade zu optimierten Astro-Image-Objekten. Astro generiert automatisch responsive srcsets, AVIF/WebP-Varianten und Blur-Placeholder.

Kann ich Content Collections mit einem CMS-Frontend kombinieren?

Ja — Tools wie Decap CMS (frueher Netlify CMS) oder Tina CMS bieten ein Web-Interface fuer Git-basierte Inhalte. Redakteure sehen ein CMS-Interface, technisch liegen die Inhalte als Markdown-Dateien im Repository.