Astro-Inhaltskollektionen: Die praktische Methode zur strukturierten Inhaltsverwaltung

Astro-Inhaltskollektionen sind die strukturierte Methode von Astro zur Verwaltung von Inhaltsdateien wie Markdown, MDX, JSON und YAML. Sie sind wichtig, weil sie lose Dateien in validierte, abfragbare Inhalte mit TypeScript-Unterstützung umwandeln, was Inhaltsfehler reduziert und größere Seiten einfacher wartbar macht.

Für Händler, Marketer und Entwickler, die inhaltsreiche Astro-Seiten erstellen, ist der praktische Wert einfach: Sie können redaktionelle Arbeitsabläufe organisiert halten, ohne die Kontrolle der Entwickler aufzugeben. Anstatt Inhalte als einen Haufen von Dateien zu behandeln, definieren Sie, was wo gehört, welche Felder erforderlich sind und wie diese Einträge abgefragt werden können.

Wichtigste Erkenntnisse

• Inhaltskollektionen sind am besten, wenn Inhalte Struktur benötigen, nicht nur Speicherung.
• Schemata erfassen fehlende oder fehlerhafte Felder, bevor sie die Vorlagen erreichen.
• Typensicherheit macht Inhaltsabfragen sicherer, wenn die Seite wächst.
• Getrennte Kollektionen sind normalerweise besser, als verschiedene Inhaltstypen in einem Ordner zu zwingen.
• Unterverzeichnisse helfen, Inhalte zu organisieren, aber die Kollektion selbst lebt weiterhin auf der obersten Ebene von src/content.

Was ist das?

Astro-Inhaltskollektionen sind Ordner auf oberster Ebene im reservierten Verzeichnis src/content. Jede Kollektion enthält Einträge, die einen ähnlichen Zweck und eine ähnliche Struktur haben, wie Blogbeiträge, Autorenprofile, Dokumentenseiten, Newsletter oder Produktnotizen. Astro behandelt diese Einträge als Inhalte, die validiert und abgefragt werden können, anstatt als willkürliche Dateien in einem Projekt.

Ein praktisches Beispiel ist eine Blog-Einrichtung mit src/content/blog/ für Beiträge und src/content/authors/ für Autorenprofile. Die Beiträge könnten Markdown-Dateien mit Feldern wie Titel, Veröffentlichungsdatum und Zusammenfassung sein, während die Autoren JSON-Dateien mit Name, Rolle und sozialen Links sein könnten. Obwohl beide Inhalte sind, sind sie unterschiedlich genug, dass sie in separaten Kollektionen leben sollten.

Diese Trennung ist der Punkt. Wenn Sie Kollektionen verwenden, kann Astro verstehen, welche Art von Daten jeder Eintrag enthalten sollte. Eine Inhaltskollektion ist nicht nur eine Ordnerkonvention; es ist ein Vertrag zwischen Ihren Inhalten und Ihren Vorlagen. Wenn ein Beitrag ein erforderliches Feld fehlt, kann Astro dieses Problem frühzeitig aufzeigen, anstatt es später beim Rendern scheitern zu lassen.

Für Teams ist dies eine bessere Lösung als ad-hoc Dateiverwaltung. Eine Marketing-Seite könnte eine Kollektion für Fallstudien, eine andere für Autoren und eine weitere für Dokumentationen haben. Eine Entwicklerdokumentationsseite könnte Dokumente in Markdown und Lokalisierungsdaten in YAML haben. Die Struktur bleibt lesbar, und das Inhaltsmodell bleibt explizit.

Warum ist es wichtig?

Der größte Geschäftswert von Astro-Inhaltskollektionen ist Konsistenz. Wenn Inhalte in einer vorhersehbaren Struktur leben, verbringen Redakteure und Entwickler weniger Zeit damit, zu raten, wo Dinge hingehören oder warum eine Seite nach einer Inhaltsaktualisierung kaputtgegangen ist. Das ist wichtig auf Seiten, auf denen sich Inhalte häufig ändern, insbesondere wenn mehrere Personen dasselbe Repository bearbeiten.

Aus technischer Sicht reduzieren Kollektionen das Risiko von Vorlagen. Wenn eine Seite einen Titel, ein Datum und einen Auszug erwartet, kann ein Schema diese Felder verlangen, bevor der Inhalt akzeptiert wird. Das bedeutet weniger Überraschungen zur Laufzeit und weniger defensives Prüfen, das sich durch Ihre Komponenten zieht. Anstatt Code zu schreiben, der davon ausgeht, dass der Inhalt korrekt ist, können Sie sich auf den Kollektionenvertrag verlassen.

Typensicherheit ist ein weiterer großer Vorteil. Astro generiert TypeScript-Unterstützung aus dem Schema, sodass Sie beim Abfragen von Einträgen Autovervollständigung und Typprüfung erhalten. Das ist nicht nur eine Komfortfunktion für Entwickler; es ist eine Wartungsfunktion. Wenn sich Inhaltsmodelle entwickeln, hilft der Compiler Ihnen, Abweichungen zwischen der Inhaltsquelle und der Seitenlogik zu erkennen.

Es gibt auch einen organisatorischen Vorteil für Inhaltsoperationen. Kollektionen erleichtern es, redaktionelle Inhalte von strukturierten Daten zu trennen. Beispielsweise kann eine Händlerseite Blogbeiträge in einer Kollektion und Autorenbiografien in einer anderen aufbewahren, während eine produktorientierte Seite Änderungsnotizen von Dokumenten trennen kann. Diese Trennung macht die Inhaltsverwaltung klarer, insbesondere wenn verschiedene Personen unterschiedliche Teile der Seite besitzen.

In der Praxis zeigt sich die Geschäftsauswirkung in weniger kaputten Seiten, schnelleren Inhaltsaktualisierungen und weniger Zeit, die mit der Fehlersuche nach einfachen Feldabweichungen verbracht wird. Die technische Auswirkung zeigt sich in saubereren Vorlagen, klareren Datenverträgen und einfacheren Refaktorisierungen, wenn sich die Seitenstruktur ändert. Wenn Sie zwischen “einfach Dateien speichern” und “Inhalte modellieren” entscheiden, sind Kollektionen die bessere Wahl, wann immer der Inhalt wiederverwendet, abgefragt oder von mehr als einer Person bearbeitet wird.

Wie es funktioniert

Auf hoher Ebene funktionieren Astro-Inhaltskollektionen in drei Phasen: Definieren Sie die Kollektion, validieren Sie die Einträge und fragen Sie dann den Inhalt in Ihren Seiten oder Komponenten ab. Der Ablauf ist unkompliziert, aber die Details sind wichtig, da sie bestimmen, wie robust Ihr Inhaltssystem sein wird.

Zuerst erstellen Sie eine Datei src/content/config.ts. Astro lädt diese Datei automatisch und verwendet sie, um Ihre Kollektionen zu registrieren. In dieser Datei importieren Sie Helfer von astro:content, definieren jede Kollektion und exportieren ein Objekt collections. Hier teilen Sie Astro mit, welche Ordner Kollektionen sind und welchem Schema jede folgen sollte.

Zweitens definieren Sie ein Schema für jede Kollektion. Schemata beschreiben die Form der Frontmatter oder Daten in dieser Kollektion. Wenn eine Datei ein erforderliches Feld fehlt oder einen Wert im falschen Format enthält, meldet Astro einen Fehler. Diese Validierung verwandelt einen Ordner von Dateien in eine zuverlässige Inhaltsquelle.

Drittens generiert Astro Typen aus dem Schema. Wenn Sie die Kollektion abfragen, versteht Ihr Editor die verfügbaren Felder. Das bedeutet bessere Autovervollständigung, weniger Tippfehler und sicherere Refaktorisierungen. Wenn Sie ein Feld im Schema umbenennen, können Ihre Vorlagen die Stellen aufzeigen, die geändert werden müssen.

Eine nützliche Art, über den Mechanismus nachzudenken, ist: Die Ordnerstruktur sagt Astro, wo Inhalte leben, die Konfigurationsdatei sagt Astro, wie der Inhalt aussehen sollte, und das Schema sagt Astro, wie es diese Form schützen kann. Die Abfrageschicht gibt Ihren Seiten dann eine typisierte Ansicht des Inhalts, sodass Sie Listen, Detailseiten und Abschnitte zu verwandten Inhalten erstellen können, ohne zu raten.

Inhaltstypen und Dateiformate

Astro unterstützt Inhaltsautorenformate wie Markdown und MDX sowie Datenformate wie JSON und YAML. Das gibt Ihnen Flexibilität, wie Sie Inhalte modellieren. Ein Blogbeitrag oder Leitfaden gehört normalerweise in Markdown oder MDX, während ein Profil, ein Einstellungsobjekt oder eine Übersetzungsdatei besser als JSON oder YAML geeignet sein kann.

Die wichtige Entscheidung ist nicht, welches Format am beliebtesten ist, sondern welches Format der Aufgabe entspricht. Wenn der Eintrag reichhaltigen Text und eingebettete Komponenten benötigt, kann MDX eine gute Wahl sein. Wenn der Eintrag hauptsächlich strukturierte Felder enthält, sind JSON oder YAML möglicherweise einfacher und leichter zu validieren.

Eine praktische Regel: Verwenden Sie Markdown, wenn der Inhalt hauptsächlich aus geschriebenem Text besteht, verwenden Sie MDX, wenn der Text eingebettete Komponenten benötigt, und verwenden Sie JSON oder YAML, wenn der Eintrag hauptsächlich Daten enthält. Das hält das Inhaltsmodell für Redakteure lesbar und für Entwickler einfacher abfragbar.

Kollektionen, Einträge und Unterverzeichnisse

Eine Kollektion ist immer ein Ordner auf oberster Ebene innerhalb von src/content/. Sie können eine Kollektion nicht innerhalb einer anderen verschachteln, aber Sie können Unterverzeichnisse innerhalb einer Kollektion verwenden, um Einträge zu organisieren. Das ist nützlich, wenn Sie Inhalte nach Sprache, Thema oder Veröffentlichungszyklus gruppieren möchten, ohne die Kollektion selbst zu ändern.

Zum Beispiel könnte eine Dokumentationskollektion die Unterordner en/, es/ und de/ verwenden. Wenn Sie Einträge abfragen, können Sie nach Pfad oder anderen Metadaten filtern, um die richtige Sprachversion zu finden. Die Struktur bleibt organisiert, aber die Kollektion verhält sich weiterhin als eine validierte Einheit.

Hier ist auch, wo Teams manchmal die Dinge komplizieren. Unterverzeichnisse sind am besten für die Organisation innerhalb eines einzelnen Inhaltstyps geeignet, nicht für das Mischen von nicht verwandten Inhalten. Wenn die Einträge unterschiedliche Felder oder unterschiedliche Vorlagen benötigen, teilen Sie sie in separate Kollektionen auf, anstatt zu versuchen, die Ordnerhierarchie die Arbeit eines Schemas erledigen zu lassen.

Anwendungsfälle

Der häufigste Anwendungsfall ist ein Blog oder ein redaktionelles Zentrum. Ein Team kann Beiträge in einer Kollektion, Autoren in einer anderen und möglicherweise Kategorien oder Änderungsnotizen in einer dritten aufbewahren. Das erleichtert den Aufbau von Listen-Seiten, Autoren-Seiten und Blöcken zu verwandten Inhalten, ohne Annahmen über Dateien in Vorlagen hart zu codieren.

Ein zweiter Anwendungsfall ist die Dokumentation. Dokumentationsseiten benötigen oft eine Mischung aus langformatigen Markdown-Inhalten, strukturierten Metadaten und Lokalisierung. Kollektionen helfen dabei, diese Teile getrennt zu halten, während sie weiterhin abfragbar bleiben. Wenn Sie Dokumente in mehreren Sprachen haben, können Unterverzeichnisse innerhalb einer Kollektion helfen, sie zu organisieren, ohne ein separates System für jede Sprache zu erstellen.

Ein dritter Anwendungsfall sind strukturierte Daten, die eine Marketingseite unterstützen. Beispielsweise können Produktkataloge, Team-Biografien, Testimonials oder Änderungsprotokolle alles in Kollektionen leben, wenn sie Validierung und wiederholbare Felder benötigen. Dies ist besonders hilfreich, wenn Inhalte von Nicht-Entwicklern aktualisiert werden, aber dennoch in ein striktes Seitenlayout passen müssen.

Es gibt auch ein nützliches “Hybrid”-Szenario: Inhaltsteams benötigen oft eine Kollektion für menschlich geschriebene Seiten und eine andere für maschinenfreundliche Daten. Eine Landingpage kann aus Markdown-Kollektionen für redaktionellen Text und aus JSON-Kollektionen für wiederverwendbare Hinweise, Preisnotizen oder Lokalisierungsstrings ziehen. Diese Trennung macht die Seite einfacher skalierbar.

Für Händler und Agenturen hängt die Entscheidung normalerweise davon ab, wie viel Variation zwischen den Einträgen besteht. Wenn jeder Eintrag die gleiche Struktur hat, ist eine Kollektion eine starke Wahl. Wenn der Inhalt sehr unregelmäßig ist, müssen Sie möglicherweise das Modell überdenken oder in mehrere Kollektionen aufteilen, damit jede kohärent bleibt.

Wie man es implementiert oder anwendet

Die Implementierung beginnt mit dem Inhaltsmodell, nicht mit dem Code. Bevor Sie Ordner erstellen, entscheiden Sie, welche Arten von Inhalten Sie tatsächlich haben und ob sie die gleiche Struktur teilen. Ein Blogbeitrag und ein Autorenprofil können beide Inhalte sein, sollten jedoch normalerweise nicht ein Schema teilen, da die Felder und die Verwendung unterschiedlich sind.

Ein guter Implementierungsprozess beginnt mit einer Inhaltsinventur. Listen Sie die Seiten oder Datenobjekte auf, die Sie benötigen, und gruppieren Sie sie dann nach gemeinsamen Feldern. Stellen Sie einfache Fragen: Muss jeder Eintrag einen Titel haben? Muss er ein Datum haben? Braucht er einen Slug, ein Bild oder eine Zusammenfassung? Wenn die Antwort je nach Inhaltstyp unterschiedlich ist, ist das ein Zeichen dafür, dass Sie separate Kollektionen benötigen.

Sobald das Modell klar ist, erstellen Sie src/content/config.ts und definieren jede Kollektion dort. Verwenden Sie defineCollection und ein Schema, das zu den Feldern passt, die Ihre Vorlagen benötigen. Wenn die Kollektion Markdown oder MDX enthält, behandeln Sie die Frontmatter als Teil des Schemas. Wenn sie JSON oder YAML enthält, definieren Sie die erwartete Objektform direkt.

Danach organisieren Sie Ihre Dateien innerhalb von src/content/ mit einem Ordner pro Kollektion. Halten Sie die Benennung konsistent und lesbar. Die Dokumentation empfiehlt kleingeschriebene Namen mit Bindestrichen anstelle von Leerzeichen, und das ist eine sinnvolle Standardoption, da es die Dateipfade einfacher zu scannen und zu referenzieren macht. Wenn Sie eine Datei vom Erstellen ausschließen möchten, unterstützt Astro die Präfixierung des Dateinamens mit einem Unterstrich.

Verbinden Sie dann die Kollektion auf bewusste Weise mit Ihren Vorlagen. Abfragen Sie nur die Felder, die Sie tatsächlich benötigen, und halten Sie die Rendering-Logik mit dem Schema in Einklang. Wenn eine Vorlage ein Feld verwendet, sollte dieses Feld Teil des Kollektionenvertrags sein. Wenn ein Feld optional ist, sollte Ihre Komponente das Fehlen dieses Feldes elegant handhaben, anstatt anzunehmen, dass es immer existiert.

Ein praktischer Arbeitsablauf sieht so aus:

1. Identifizieren Sie die benötigten Inhaltstypen.
2. Teilen Sie sie in separate Kollektionen auf, wenn sich ihre Formen unterscheiden.
3. Definieren Sie Schemata für erforderliche und optionale Felder.
4. Fügen Sie Einträge in Markdown, MDX, JSON oder YAML hinzu.
5. Abfragen Sie die Kollektion in Ihren Seiten und Komponenten.
6. Lassen Sie TypeScript und die Schema-Validierung Abweichungen frühzeitig erkennen.
7. Überprüfen Sie das Schema, wann immer sich das Inhaltsmodell ändert.

Für Teams, die bereits Astro verwenden, ist es auch wichtig, die TypeScript-Einstellungen zu überprüfen. Wenn Ihr Projekt bereits nicht die strengen oder strengsten empfohlenen Einstellungen von Astro verwendet, benötigen Sie möglicherweise strictNullChecks für die beste Erfahrung. Wenn Sie .js oder .mjs-Dateien verwenden, kann die Aktivierung von allowJs bei IntelliSense und Typprüfung im Editor helfen.

Häufige Fehler und Fallstricke

Ein häufiger Fehler besteht darin, zu viele nicht verwandte Dateien in eine Kollektion zu packen. Es ist verlockend, alles in einen einzigen content-Ordner zu stecken und es später zu sortieren, aber das führt normalerweise zu schwachen Schemata und verwirrenden Vorlagen. Wenn zwei Einträge keine ähnliche Struktur teilen, sollten sie wahrscheinlich keine Kollektion teilen.

Ein weiterer Fallstrick besteht darin, Kollektionen wie einen generischen Dateispeicher zu behandeln. Das Verzeichnis src/content ist für Inhaltskollektionen reserviert, nicht für beliebige Projektressourcen. Wenn Sie nicht verwandte Dateien dort platzieren, erschweren Sie das Verständnis des Inhaltsmodells und riskieren, den Zweck des Verzeichnisses zu verwässern.

Ein dritter Fehler besteht darin, das Schema-Design zu überspringen. Ohne ein Schema verlieren Sie viel von dem Wert der Inhaltskollektionen: Validierung und Typensicherheit. Das Ergebnis funktioniert vielleicht immer noch, aber Sie geben den Hauptgrund auf, diese Funktion überhaupt zu verwenden. Ein schwaches Schema kann fast genauso riskant sein wie kein Schema.

Teams vergessen auch manchmal, dass Unterverzeichnisse zur Organisation gedacht sind, nicht zur Neudefinition der Kollektion. Sie können Einträge innerhalb einer Kollektion gruppieren, aber die Kollektion selbst muss weiterhin ein Ordner auf oberster Ebene sein. Wenn Sie eine andere Form oder einen anderen Zweck benötigen, erstellen Sie eine andere Kollektion, anstatt alles in verschachtelten Ordnern zu erzwingen.

Ein weiteres subtiler Problem ist die übermäßige Verwendung von optionalen Feldern. Wenn alles optional ist, hört das Schema auf zu helfen und Ihre Vorlagen werden wieder defensiv. Machen Sie die Felder erforderlich, wenn die Seite von ihnen abhängt, und reservieren Sie optionale Felder für wirklich variable Inhalte. Das hält den Vertrag ehrlich.

Ein letzter Fallstrick besteht darin, das Schema von dem tatsächlichen redaktionellen Workflow abdriften zu lassen. Wenn Redakteure konsequent ein Feld benötigen, das im Schema nicht enthalten ist, werden sie einen Weg finden, es zu umgehen oder zu ignorieren. Die Lösung besteht nicht darin, mehr Dokumentation zu erstellen; es ist, das Kollektionenmodell zu aktualisieren, damit das Schema widerspiegelt, wie der Inhalt tatsächlich verwendet wird.

Beste Praktiken und schnelle Checkliste

Die beste Praxis besteht darin, Inhalte um die Verwendung herum zu modellieren, nicht nur um die Speicherung. Wenn eine Seitenvorlage jedes Mal die gleichen Felder benötigt, kodieren Sie diese Struktur im Schema. Wenn zwei Inhaltstypen unterschiedliche Vorlagen steuern, trennen Sie sie frühzeitig, damit das Projekt einfach zu durchdenken bleibt.

Es hilft auch, die Dateibenennung konsistent zu halten. Kleingeschriebene Namen mit Bindestrichen sind einfacher zu scannen, einfacher zu referenzieren und weniger wahrscheinlich, Verwirrung in größeren Repositories zu verursachen. Das mag geringfügig erscheinen, aber Namensdisziplin reduziert Reibung, wenn mehrere Personen Einträge hinzufügen oder aktualisieren.

Verwenden Sie Unterverzeichnisse zur Organisation, wenn sie Klarheit hinzufügen, wie Sprachordner oder Themenzusammenstellungen. Verwenden Sie sie nicht, um ein schwaches Inhaltsmodell zu verbergen. Wenn der Inhalt bedeutungsvoll unterschiedlich ist, ist eine separate Kollektion normalerweise die sauberere Wahl.

Wenn Sie entscheiden, ob Sie eine Kollektion verwenden möchten, fragen Sie: Wird dieser Inhalt von mehr als einer Person abgefragt, validiert, wiederverwendet oder bearbeitet? Wenn ja, sind Kollektionen normalerweise lohnenswert. Wenn die Datei wirklich einmalig ist und nie anderswo referenziert wird, kann eine Kollektion unnötige Überkopflasten verursachen.

Eine schnelle Checkliste für die Implementierung:

• Definieren Sie die Inhaltstypen, bevor Sie Schemata schreiben.
• Halten Sie jede Kollektion auf einen einzigen Eintragstyp fokussiert.
• Validieren Sie erforderliche Felder mit einem Schema.
• Verwenden Sie TypeScript-Typen als Teil Ihres Überprüfungsprozesses.
• Organisieren Sie Einträge mit klarer Benennung und sinnvollen Unterverzeichnissen.
• Überprüfen Sie das Modell, wenn die Inhaltsbedürfnisse driftend werden.
• Bevorzugen Sie explizite Verträge gegenüber impliziten Annahmen.

Wenn Sie eine inhaltsreiche Astro-Seite erstellen und einen sauberen Ausgangspunkt wünschen, kann ein strukturiertes Thema wie Minimal Studio ein nützlicher Referenzpunkt sein, wie ein fokussiertes Layoutsystem Inhalte unterstützt, ohne Unordnung hinzuzufügen.

Aus der Praxis — illustratives Szenario (hypothetisch, kein Kundenprojekt)

Illustratives Beispiel — kein reales Kundenprojekt: Stellen Sie sich eine kleine von Händlern geführte Astro-Seite vor, die wöchentliche Artikel, Team-Biografien und Produktaktualisierungsnotizen veröffentlicht. Zunächst lebt alles in einem einzigen src/content-Ordner, weil sich das einfach anfühlt. Das Team fügt schnell Dateien hinzu, aber die Struktur beginnt zu wandern: Einige Einträge haben Daten, einige nicht, und Vorlagen beginnen, nach Feldern zu suchen, die möglicherweise existieren oder nicht.

Ein typischer Händler könnte den Schmerz bemerken, wenn ein neuer Artikel hinzugefügt wird und die Listenseite kaputtgeht, weil die Frontmatter unvollständig ist. Das Problem ist nicht der Artikel selbst; es ist, dass das Inhaltsmodell dem Team nie gesagt hat, wie ein gültiger Eintrag aussehen sollte. Die Seite verlässt sich jetzt auf Erinnerung statt auf Validierung.

Ein besserer Ansatz ist es, den Inhalt in separate Kollektionen aufzuteilen: blog, authors und updates. Die Blogkollektion kann Titel, Veröffentlichungsdatum und Zusammenfassung erfordern. Die Autorenkollektion kann JSON mit Name, Rolle und Avatar-Pfad verwenden. Die Updatekollektion kann leichtgewichtig bleiben, aber dennoch eine konsistente Form durchsetzen. Sobald die Schemata festgelegt sind, können die Vorlagen jede Kollektion mit Vertrauen abfragen, da der Datenvertrag explizit ist.

Der Workflow des Teams wird dann vorhersehbarer. Ein Redakteur fügt einen Blogbeitrag hinzu, das Schema prüft die erforderlichen Felder, und der Build schlägt sofort fehl, wenn etwas fehlt. Ein Entwickler aktualisiert die Listenseite und muss nur die Felder behandeln, die die Blogkollektion garantiert. Wenn das Unternehmen später lokalisierte Versionen möchte, kann das Team Unterverzeichnisse innerhalb der relevanten Kollektion hinzufügen, ohne das gesamte System neu zu gestalten.

Die Entscheidungslogik ist einfach: Verwenden Sie eine Kollektion, wenn Einträge wirklich die gleiche Struktur teilen, und teilen Sie Kollektionen auf, sobald die Vorlagenlogik zu divergieren beginnt. Das hält das Inhaltsmodell im Einklang mit den tatsächlichen Bedürfnissen der Seite. In der Praxis bedeutet dies weniger “Sonderfälle” im Code, weniger inhaltsbezogene Fehler und einen saubereren Übergang zwischen Redakteuren und Entwicklern.

Verwandte Konzepte und weiterführende Literatur

Wenn du Astros Inhaltsmodell angehst, funktionieren Collections am besten zusammen mit Routing, Schema-Design und einem klaren Autorenformat. Diese Leitfäden verbinden die Content-Schicht mit dem Rest einer Astro-Site.

• Astro Islands Architektur: Der Schlüssel zu besserer Leistung — wie statische Inhalte und interaktive Komponenten zusammenspielen
• Astro Themes — Einstiegspunkte und Layouts für inhaltsreiche Sites
• Content Collections — offizielle Referenz für Schemas und Abfragen