Astro und statische Websites: Wann der Ansatz passt – und wann nicht

Was eine statische Website ist

Eine statische Website besteht aus fertigen Dateien: HTML, CSS, JavaScript und Bildern. Sie entstehen einmal beim Build und werden danach unverändert ausgeliefert. Bei einer Anfrage muss kein Server mehr Seiten zusammensetzen oder eine Datenbank befragen; der Webserver liefert nur die passende Datei. Das Werkzeug, das aus Quelldateien diese Ausgabe erzeugt, heißt Static Site Generator (SSG).

Das Gegenstück ist das Rendering bei Anfrage: Ein Server erzeugt die Seite, sobald jemand sie aufruft. Welche der beiden Varianten du wählst, hängt nicht vom Framework ab, sondern davon, wie oft sich Inhalte ändern und ob jede Seite für jeden Besucher gleich aussieht. Wenn ja, spricht vieles für vorab gerenderte Seiten.

Der Begriff „Jamstack" beschreibt diese Architektur ungefähr: vorab gerenderte Seiten, dynamische Teile über JavaScript und APIs. Wichtiger als das Label ist die Frage, was zur Laufzeit wirklich dynamisch sein muss.

Wie Astro funktioniert

Astro ist ein Web-Framework für inhaltsgetriebene Websites. Stand Oktober 2026 ist Astro 7 aktuell; der Astro-Blog nennt Astro 7.4 vom 15. Oktober 2026 als jüngstes Release. Drei Eigenschaften prägen den Ansatz.

Statisch als Standard. Laut Astro-Dokumentation wird die gesamte Seite standardmäßig vorab gerendert (prerendered): Seiten, Routen und Endpunkte entstehen beim Build als statisches HTML. Wenn du mehr brauchst, kannst du mit einem Adapter On-Demand-Rendering aktivieren, entweder für einzelne Seiten über export const prerender = false oder für die ganze Seite über output: 'server'. Die Dokumentation empfiehlt, mit dem statischen Standard zu starten und erst dann umzustellen, wenn die meisten Seiten dynamisch sind.

Kein JavaScript ohne Auftrag. Astro rendert UI-Komponenten zu HTML und CSS und entfernt dabei automatisch clientseitiges JavaScript. Interaktive Komponenten markierst du mit einer client:*-Direktive. Dann lädt nur dieses „Island" JavaScript: client:load hydratisiert beim Laden der Seite, client:idle, wenn der Browser untätig ist, client:visible, sobald die Komponente im Viewport erscheint. Die Dokumentation nennt dieses Muster Islands-Architektur und führt den Begriff auf Katie Sylor-Miller (2019) und Jason Miller (2020) zurück. Mit server:defer lassen sich außerdem „Server Islands" einzelner dynamischer Teile separat rendern; dafür ist ein Adapter nötig.

Inhalte als Collections. Content Collections sind Astros Mechanismus für Gruppen strukturgleicher Inhalte wie Blogbeiträge oder Produktbeschreibungen. Jede Collection braucht einen Loader: glob() liest viele lokale Dateien (Markdown, MDX, JSON, YAML oder TOML), file() liest mehrere Einträge aus einer Datei, und eigene oder Community-Loader können Daten aus einem CMS oder einer API holen. Ein Schema auf Basis von Zod validiert die Frontmatter-Daten; Dateien, die dem Schema widersprechen, erzeugen einen Fehler. Content Collections gibt es seit Astro 2.0.0.

Eine Komponente und eine Collection

Eine Astro-Komponente besteht aus einem Frontmatter-Block (der Code zwischen den ----Zeilen, der beim Build läuft) und dem Template darunter. Das folgende Beispiel zeigt eine Hinweis-Box mit typisierten Props und einem Slot für den Inhalt:

---
interface Props {
  titel: string;
  typ?: 'info' | 'warnung';
}

const { titel, typ = 'info' } = Astro.props;
---
<aside class={`hinweis hinweis--${typ}`}>
  <strong>{titel}</strong>
  <slot />
</aside>

<style>
  .hinweis { border-left: 4px solid currentColor; padding: 0.5rem 1rem; }
</style>

Eingebunden wird sie wie jede andere Komponente. Das Ergebnis im Build ist reines HTML plus das auf die Komponente begrenzte CSS, ohne ein Byte JavaScript:

---
import Hinweis from '../components/Hinweis.astro';
---
<Hinweis titel="Statisch ausgeliefert" typ="warnung">
  Diese Seite enthält kein clientseitiges JavaScript.
</Hinweis>

Für Inhalte definierst du in src/content.config.ts eine Collection. Dieses Beispiel folgt dem Muster aus der Astro-Dokumentation:

import { defineCollection } from 'astro:content';
import { glob } from 'astro/loaders';
import { z } from 'astro/zod';

const blog = defineCollection({
  loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    pubDate: z.coerce.date(),
  }),
});

export const collections = { blog };

Der Loader entscheidet, woher die Einträge kommen. Liegen sie als Markdown-Dateien im Repository, reicht glob(). Stammen sie aus einem CMS, ersetzt ein eigener oder Community-Loader diesen Teil, während Schema und Abfrage im Rest des Projekts gleich bleiben. Dieser Austausch ist der Grund, warum der Wechsel von Dateien zu einem Headless CMS kein Neubau sein muss.

Abgefragt wird die Collection mit getCollection('blog'). Die Reihenfolge der Ergebnisse ist laut Dokumentation nicht garantiert; sortiere also selbst, etwa nach Datum.

Praxis-Tipp: Das Schema ist der eigentliche Gewinn bei redaktionellen Inhalten. Ein fehlender Titel oder ein falsches Datumsformat bricht den Build ab, statt unbemerkt live zu gehen.

Hosting und Kosten

Das Ergebnis eines statischen Builds sind Dateien. Jeder Webserver und jeder Hoster für statische Seiten kann sie ausliefern; eine Laufzeitumgebung mit Datenbank ist nicht nötig. Das senkt den Betriebsaufwand: weniger Komponenten, die ausfallen, aktualisiert oder abgesichert werden müssen. Konkrete Preise unterscheiden sich je nach Anbieter und ändern sich; prüfe sie dort, bevor du planst.

Der Preis für diese Einfachheit ist der Build-Schritt. Jede inhaltliche Änderung braucht einen neuen Build und ein neues Deployment. Bei kleinen und mittleren Seiten ist das eine Sache von Sekunden bis Minuten, bei sehr großen Seiten kann es zum Thema werden. Astro 7.2 und 7.4 führen laut Astro-Blog dazu experimentelle Funktionen wie inkrementelle statische Builds und paralleles Prerendering ein; als experimentell solltest du sie nicht ungeprüft in Produktion nehmen.

Statisch, WordPress oder Next.js

Der Vergleich ist kein Qualitätsranking, sondern eine Frage der Passung. Die Tabelle beschreibt typische Eigenschaften der drei Ansätze; Next.js-Angaben stammen aus der Dokumentation zum Static Export, die WordPress-Spalte beschreibt das klassische Betriebsmodell mit Theme.

Zwei Punkte verdienen Aufmerksamkeit. Erstens: Auch Next.js kann statisch exportieren, doch die Dokumentation listet ausdrücklich Funktionen auf, die dann nicht laufen, darunter Cookies, Server Actions, Rewrites, Redirects, Headers und Incremental Static Regeneration. Zweitens: WordPress und eine statische Seite schließen sich nicht aus. Die WordPress-REST-API liefert Inhalte als JSON an separate Anwendungen, sodass WordPress als Redaktionssystem dienen kann, während Astro das Frontend baut. Wie dieses Modell aufgebaut ist, erklärt der Artikel zum Headless CMS.

SEO und Performance: was sich sagen lässt

Statische Seiten haben bei der Auslieferung strukturelle Vorteile: Der Server muss nichts berechnen, und der Browser bekommt vollständiges HTML. Das kann den Aufbau der Seite beschleunigen und macht Inhalte für Crawler ohne Rendering sichtbar. Wie Google JavaScript-Seiten verarbeitet, beschreibt der Artikel zu JavaScript-SEO.

Mehr als „kann helfen" lässt sich allgemein nicht behaupten. Ob eine Seite gute Werte erreicht, entscheiden Bilder, Schriften, Drittanbieter-Skripte und Layout, nicht das Framework allein. Eine statische Seite mit einem schweren Werbe-Skript ist langsam, eine sorgfältig gebaute WordPress-Seite mit Caching kann schnell sein. Die Metriken und ihre Schwellenwerte erklärt der Beitrag zu den Core Web Vitals; gemessen wird mit Felddaten und Lab-Tools, nicht mit der Wahl des Generators. Auch für das technische Fundament (Statuscodes, Weiterleitungen, Canonical) gilt: Das Framework erleichtert es, ersetzt aber keine Prüfung, wie sie der Leitfaden zu technischem SEO beschreibt.

Wann statisch nicht passt

Statisch ist die falsche Grundlage, wenn mindestens eines davon zutrifft:

• Inhalte hängen vom Nutzer ab. Konten, Warenkörbe oder Dashboards brauchen Daten pro Anfrage. Astro bietet dafür On-Demand-Rendering und Server Islands, beides mit Adapter. Wenn fast alles dynamisch ist, ist ein Framework mit Fokus auf Web-Anwendungen die ehrlichere Wahl.
• Inhalte ändern sich minütlich. Ein Build pro Änderung wird dann zur Bremse. Live Collections laden Daten laut Dokumentation zur Anfragezeit, brauchen aber ebenfalls On-Demand-Rendering.
• Redakteure sollen ohne Entwickler publizieren. Markdown-Dateien in einem Repository sind für Entwickler bequem, für ein Redaktionsteam oft nicht. Hier brauchst du ein CMS, das du anbindest. Die Astro-Dokumentation beschreibt ein Headless CMS als System, das beim Schreiben der Inhalte hilft, aber keine Seite zur Anzeige erzeugt; du holst die Inhalte in dein Astro-Projekt. Entscheidungskriterien dafür stehen im Artikel zur Trennung von Inhalt und Frontend.
• Ein bestehendes System funktioniert. Eine laufende WordPress-Seite mit eingespieltem Team ist kein Grund für eine Migration, nur weil es eine Alternative gibt.

Offenlegung: PowerWire selbst

PowerWire selbst ist mit Astro gebaut und wird als statische Ausgabe ausgeliefert. Das ist kein Argument für den Ansatz, sondern eine Angabe, damit du die Perspektive dieses Artikels einordnen kannst. Aussagen über Vor- und Nachteile stützen sich auf die verlinkten Dokumentationen, nicht auf Messungen an dieser Seite. Die installierte Astro-Version ist 7.4.1.

Dein nächster Schritt

Probiere es an einem kleinen, realen Inhalt aus, statt Frameworks abstrakt zu vergleichen. Lege ein Astro-Projekt an, definiere eine Collection mit zwei oder drei Feldern und rendere eine Liste wie im Beispiel oben. Baue die Seite und öffne die Ausgabe-HTML-Dateien: Prüfe, ob sie deinen kompletten Inhalt enthalten und ob irgendein JavaScript mitgeliefert wird. Wenn das Ergebnis für dein Vorhaben reicht, fehlt dir nur noch die Antwort auf eine Frage: Wer pflegt die Inhalte später, und womit?