Astro oder WordPress: Welche Architektur passt zu Ihrem Projekt?

Astro oder WordPress ist keine Entscheidung zwischen einer modernen und einer überholten Technik. Entscheidend ist, welche Aufgaben Ihre Website erfüllen muss: Wie werden Inhalte erstellt und geprüft? Welche Daten und Funktionen gehören zum Produkt? Wer betreibt das System nach dem Start? Astro eignet sich besonders für strukturierte Content-Sites, bei denen Inhalte kontrolliert veröffentlicht und Seiten überwiegend statisch ausgeliefert werden können. WordPress ist oft passender, wenn Redaktionen direkt im System arbeiten, Inhalte häufig ändern oder die Website eng mit Rollen, Daten und Geschäftsprozessen verbunden ist. Für Geschäftsführung, Produktverantwortliche und technische Leitung zählt deshalb nicht die Funktionsliste eines Systems, sondern die Architektur, die den tatsächlichen Arbeitsablauf mit vertretbarem Aufwand trägt.

Kurz gesagt

Astro passt, wenn Inhalte strukturiert vorliegen, Änderungen über einen Build- und Veröffentlichungsprozess laufen können und interaktive Funktionen gezielt ergänzt werden. WordPress passt, wenn die Redaktion direkt im Backend publiziert oder das System zugleich Daten, Benutzerrollen und Abläufe verwaltet. Beide Systeme können Teil einer größeren Architektur sein; weder ist automatisch schneller noch einfacher im Betrieb. Entscheiden Sie nach Redaktionsprozess, Datenmodell, dynamischen Funktionen und Betriebsverantwortung.

Ausgangslage

Die Frage entsteht häufig bei einem Relaunch, einer technischen Überarbeitung oder dem Ausbau einer bestehenden Website. WordPress kann mit Plugins und individueller Entwicklung über die klassische redaktionelle Website hinauswachsen. Astro kann um interaktive Oberflächen und angebundene Dienste ergänzt werden. Dadurch lassen sich die Systeme nicht allein anhand der Bezeichnung „CMS“ oder „Static Site Generator“ sauber vergleichen.

Die grundlegende Differenz liegt darin, wann und wo Inhalte verarbeitet werden. Bei Astro werden Seiten typischerweise aus Inhalten und Vorlagen erzeugt und anschließend ausgeliefert. Änderungen müssen dafür einen Veröffentlichungs- oder Build-Prozess durchlaufen. WordPress erzeugt Seiten üblicherweise aus einer laufenden Anwendung, Datenbank und Templates. Redaktionen können Inhalte im Backend ändern und veröffentlichen, ohne für jede Änderung eine neue Website-Version zu bauen.

Das hat Folgen für den gesamten Betrieb. Astro verlangt einen verlässlichen Weg vom bearbeiteten Inhalt bis zum veröffentlichten Ergebnis. WordPress verlangt eine gepflegte Laufzeitumgebung und eine kontrollierte Konfiguration aus Core, Theme, Plugins und gegebenenfalls eigener Entwicklung. Die entscheidende Frage ist nicht, welche Betriebsform abstrakt besser ist. Es ist die, welche Ihr Team dauerhaft beherrschen kann.

Für die Einordnung des größeren Architekturkontexts hilft der Beitrag CMS, Static Site oder Web-App?. Hier geht es konkreter um die Wahl zwischen Astro und WordPress.

Entscheidungskriterien

1. Wie arbeitet Ihre Redaktion?

Klären Sie, wer Inhalte erstellt, prüft und veröffentlicht und ob diese Personen dafür in einer technischen Oberfläche arbeiten können. Astro kann Inhalte aus Dateien oder einem angebundenen CMS beziehen. In beiden Fällen brauchen Sie einen definierten Veröffentlichungsweg. Wenn die Redaktion unmittelbar in WordPress arbeitet, ist dieser Ablauf bereits Teil des Systems.

Prüfen Sie nicht nur, ob sich Texte bearbeiten lassen. Relevant sind Vorschau, Freigabe, Rollen, geplante Veröffentlichungen, Korrekturen und der Umgang mit Änderungen nach dem Publizieren. Eine Architektur ist nur dann redaktionstauglich, wenn diese Abläufe verlässlich abgebildet sind.

2. Sind Ihre Inhalte strukturierte Daten oder überwiegend freie Seiten?

Astro Content Collections eignen sich, wenn wiederkehrende Inhaltstypen klare Felder und Regeln haben. Ein Pflanzenprofil kann etwa einen Namen, eine Beschreibung, Standortangaben und Beziehungen zu anderen Inhalten enthalten. Ein Schema macht fest, welche Daten erwartet werden, und hilft, fehlerhafte Inhalte bereits beim Build zu erkennen.

Das folgende vereinfachte Beispiel zeigt eine Collection mit einem Zod-Schema. Es verwendet den Glob-Loader, um Markdown-Dateien aus einem Verzeichnis zu laden:

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

const pflanzen = defineCollection({
  loader: glob({
    pattern: '**/*.md',
    base: './src/content/pflanzen',
  }),
  schema: z.object({
    name: z.string(),
    beschreibung: z.string(),
    standort: z.enum(['sonne', 'halbschatten', 'schatten']),
    regionen: z.array(z.string()).default([]),
  }),
});

export const collections = { pflanzen };

Das Schema ist sinnvoll, wenn Inhalte tatsächlich nach diesem Modell gepflegt werden und die Felder für Seiten, Suche oder Filter gebraucht werden. Es ersetzt aber weder einen geeigneten Redaktionsprozess noch eine Benutzeroberfläche für Personen, die nicht direkt mit Dateien arbeiten sollen. Für solche Teams kann ein CMS als Eingabequelle dienen, während Astro die veröffentlichten Seiten erzeugt.

WordPress bietet ebenfalls strukturierte Inhalte, etwa über eigene Inhaltstypen und Taxonomien. Es ist nicht auf freie Seiten beschränkt. Der Unterschied liegt darin, ob das gewünschte Datenmodell in einer laufenden WordPress-Anwendung verwaltet werden soll oder ob ein separater Build- und Publikationsweg besser zum Projekt passt.

3. Welche Funktionen müssen zur Laufzeit arbeiten?

Listen Sie Funktionen auf, die Daten abhängig von Nutzern oder aktuellen Eingaben verändern: Konten, personalisierte Bereiche, häufig aktualisierte Bestände, Formulare mit Verarbeitung, Berechnungen oder Schnittstellen. Fragen Sie bei jeder Funktion, ob sie serverseitig, im Browser oder über einen angebundenen Dienst laufen muss.

Eine Astro-Site kann interaktive Bereiche und externe oder eigene Dienste einbinden. Sie ist deshalb nicht auf rein statische Seiten beschränkt. Doch sobald eine Funktion eine Datenbank, Berechtigungen oder veränderliche Zustände benötigt, muss dafür eine passende Laufzeit oder ein Backend vorgesehen werden. WordPress kann solche Aufgaben innerhalb einer Anwendung übernehmen, wenn Datenmodell, Rollen und Abläufe in WordPress sinnvoll aufgehoben sind.

4. Wie häufig und auf welchem Weg ändern sich Inhalte?

Bei seltenen, geprüften Veröffentlichungen kann ein Build-Prozess gut zum Arbeitsablauf passen. Bei vielen täglichen Änderungen, kurzfristigen Korrekturen oder mehreren Freigabestufen müssen Auslöser, Vorschau und Veröffentlichung zuverlässig organisiert sein. Ein statisches Ergebnis macht die redaktionelle Arbeit nicht automatisch einfacher; es verschiebt einen Teil des Aufwands in die Veröffentlichungskette.

5. Wer verantwortet den Betrieb?

Vergleichen Sie nicht nur Hostingmodelle, sondern die benötigten Fähigkeiten und Zuständigkeiten. Bei WordPress gehören Updates, Erweiterungen, Backups, Rechte und die laufende Anwendung zum Betrieb. Bei Astro müssen unter anderem Build, Deployment, Inhaltsquellen und gegebenenfalls angeschlossene Backends gepflegt werden. Die Frage lautet: Gibt es ein Team oder einen verlässlichen Dienstleister, der diese Aufgaben nachvollziehbar übernehmen kann?

6. Wie stark ist die Website mit Geschäftsprozessen verbunden?

Eine Website mit mehreren Rollen, internen Abläufen, Datenquellen und Benutzerbereichen ist nicht nur ein Veröffentlichungsprojekt. Prüfen Sie, ob das CMS dafür ein geeignetes Backend sein kann oder ob eine getrennte Webanwendung sinnvoller ist. WordPress kann als Plattform dienen, wenn das Datenmodell und die Anwendungslogik bewusst entwickelt werden. Astro kann die öffentliche Content-Schicht bilden, während die dynamische Anwendung separat läuft.

Szenarien

Astro: strukturierte Inhalte, kontrollierte Veröffentlichung

Astro ist eine passende Wahl, wenn die Website vor allem Inhalte präsentiert, deren Struktur sich klar beschreiben lässt. Typische Hinweise sind wiederkehrende Seitentypen, eine redaktionelle Prüfung vor Veröffentlichung und Funktionen, die sich gezielt ergänzen lassen, ohne dass die gesamte Website dynamisch erzeugt werden muss.

Das heißt nicht, dass jede Astro-Site aus lokalen Markdown-Dateien bestehen muss. Inhalte können auch aus einem CMS oder einer anderen Quelle kommen. Entscheidend ist, dass die Daten zuverlässig in den Veröffentlichungsprozess gelangen und Änderungen nachvollziehbar live gehen.

Das Projekt Garten 1x1 zeigt einen passenden Migrationsfall: Inhalte wurden von WordPress nach Astro übertragen. Ein einmaliges TypeScript-Skript wandelte den WXR-Export in Markdown um. Die Profile liegen in Content Collections mit Zod-Schema; hinzu kommen eine Suche und ein Gartenrechner im Browser. Das Affiliate-Backend blieb als eigenes PHP/MySQL-System bestehen, inklusive Freigabe im Admin. Das Beispiel zeigt eine Trennung nach Aufgaben: strukturierte Content-Seiten in Astro, dynamische und freizugebende Vorgänge in einem separaten Backend.

Auch erlebe-nrw nutzt Astro für eine datenreiche Content-Plattform. Rund 8.300 Ausflugsziele aus mehreren Datenquellen durchlaufen eine nummerierte Pipeline von SQLite über JSONL nach Astro. Slugs sind eingefroren, Quelle und Stand werden an den Angaben geführt, und dünne Seiten bleiben von der Indexierung ausgeschlossen. Hier ist Astro Teil einer kontrollierten Daten- und Veröffentlichungsarchitektur, nicht bloß ein anderes Template-System.

WordPress: Redaktion und Anwendung in einem System

WordPress passt, wenn Redaktionen unmittelbar im Backend arbeiten sollen und die Website zusätzlich strukturierte Daten, Benutzerrollen oder Geschäftslogik verwaltet. Das kann sinnvoll sein, wenn dieselbe Plattform Inhalte, interne Verwaltungsoberflächen und Schnittstellen bereitstellt und diese Aufgaben eng zusammenhängen.

Im Projekt Wendewerk blieb WordPress die Plattform. Sie verarbeitet Krankenkassen- und Leistungsdaten, nutzt ein Datenmodell auf Basis von ACF-Feldern und bildet Rollen für Krankenkassen, Experten, Präventionsanbieter und Versicherte ab. Besucher-Tools, eine token-authentifizierte REST-API und die KI-gestützte Extraktion von Satzungstexten mit Staging und Review gehören ebenfalls zum System. Das ist kein Beleg dafür, dass WordPress für jedes datenintensive Projekt die richtige Wahl ist. Es zeigt, dass WordPress tragfähig sein kann, wenn Datenmodell, Rollen, Freigaben und Erweiterungen gezielt zusammengeführt werden.

Mehr zu diesem Architekturansatz lesen Sie in WordPress als Plattform. Wenn ein CMS zugleich Backend wird, sollten Datenmodell und Grenzen der Anwendung ausdrücklich geplant werden.

Geteilte Architektur: CMS, Astro und Backend nach Aufgaben trennen

Nicht jedes Projekt muss vollständig in einem System liegen. Eine Redaktion kann Inhalte in einem CMS pflegen, während Astro daraus veröffentlichte Seiten erzeugt. Nutzerkonten, Transaktionen oder andere veränderliche Prozesse können in einer separaten Anwendung oder einem Backend laufen.

Die Trennung ist dann hilfreich, wenn Zuständigkeiten und Schnittstellen klar bleiben. Sie erhöht den Koordinationsaufwand: Vorschau, Freigabe, Synchronisation und Fehlerbehandlung müssen über Systemgrenzen hinweg funktionieren. Für ein kleines Team kann ein gut abgegrenztes WordPress-System einfacher zu betreiben sein. Für eine Content-Site mit eigenständigen Anwendungsfunktionen kann die Aufteilung dagegen verhindern, dass ein einzelnes System Aufgaben übernimmt, für die es nicht ausgelegt ist.

Typische Fehler

• Die Entscheidung an Ladezeit oder Modernität festmachen. Aus dem Technologie-Namen allein lässt sich nicht ableiten, welche Architektur im konkreten Betrieb besser funktioniert.
• Den Redaktionsprozess erst nach der Migration betrachten. Dateibasierte Inhalte sind kein Ersatz für Vorschau, Rollen oder Freigaben, wenn das Team diese benötigt.
• WordPress mit einer ungeplanten Plugin-Sammlung gleichsetzen. Komplexität entsteht vor allem, wenn Erweiterungen Daten und Zuständigkeiten ohne klares Modell verwalten.
• Astro als vollständiges Backend behandeln. Datenbank, Authentifizierung und veränderliche Abläufe brauchen eine dafür geplante Laufzeit oder einen Dienst.
• Die Kosten der Trennung übersehen. CMS, Build-Prozess und Backend brauchen abgestimmte Schnittstellen und Verantwortlichkeiten.
• Bei der Migration nur Inhalte übertragen. URLs, Beziehungen, Suchverhalten, Metadaten und Freigabeprozesse müssen ebenfalls geprüft werden.
• Betrieb und Rückfallweg offenlassen. Legen Sie fest, wie Veröffentlichungen geprüft, Fehler behoben und Änderungen zurückgenommen werden.

Empfehlung

Wenn Ihre Website überwiegend strukturierte Inhalte veröffentlicht, Änderungen geprüft durch einen Build-Prozess laufen können und keine umfangreiche Backend-Logik im CMS benötigt wird, ist Astro eine geeignete Option.

Wenn Ihre Redaktion direkt im Backend publiziert, mehrere Rollen und Datenprozesse zusammenarbeiten oder WordPress bereits als kontrollierte Plattform dient, spricht viel dafür, WordPress weiterzuentwickeln. Prüfen Sie zuerst Datenmodell, Erweiterungen und Betriebsrisiken, bevor Sie eine Migration ansetzen.

Wenn Inhalte in einem CMS gepflegt werden sollen, aber öffentliche Seiten und dynamische Funktionen unterschiedliche Anforderungen haben, kann eine geteilte Architektur passen. Entscheiden Sie dabei bewusst, welches System für Inhalte, Veröffentlichung, Nutzerzustände und Daten jeweils verantwortlich ist.

Wenn weder Astro noch WordPress die Anforderungen ohne viele Sonderlösungen erfüllt, vergleichen Sie auch eine individuelle Webanwendung oder ein anderes CMS. Die Entscheidung sollte der Prozess bestimmen, nicht die Vorliebe für ein Werkzeug.

Checkliste

• Beschreiben Sie, wer Inhalte erstellt, prüft und veröffentlicht.
• Erfassen Sie die Inhaltstypen, Felder und Beziehungen, die das Projekt braucht.
• Trennen Sie statische Inhalte von Funktionen mit veränderlichen Daten oder Nutzerzuständen.
• Legen Sie fest, wie Vorschau, Freigabe und Veröffentlichung funktionieren.
• Prüfen Sie, welche Rollen und Berechtigungen erforderlich sind.
• Benennen Sie die Personen oder Dienstleister, die Build, Backend und laufenden Betrieb verantworten.
• Bewerten Sie Migrationsaufwand einschließlich URLs, Metadaten und interner Verknüpfungen.
• Definieren Sie, wie Fehler erkannt und Änderungen zurückgenommen werden.

Häufige Fragen

Ist Astro grundsätzlich schneller als WordPress?

Die Architektur beeinflusst, wie Seiten erzeugt und ausgeliefert werden. Das Ergebnis hängt aber auch von Seitenaufbau, Daten, eingebundenen Funktionen und Betrieb ab. Ein Systemname allein ist kein belastbarer Geschwindigkeitsvergleich.

Kann eine Redaktion Astro ohne technische Kenntnisse nutzen?

Das hängt davon ab, wie Inhalte eingegeben werden. Bei dateibasierten Content Collections arbeitet die Redaktion direkt mit Dateien. Ein angebundenes CMS kann eine redaktionelle Oberfläche bereitstellen; dessen Verbindung mit Vorschau und Veröffentlichung muss geplant werden.

Muss WordPress ersetzt werden, wenn eine Website viele Inhalte hat?

Nein. Umfangreiche Inhalte sind allein kein Grund für eine Migration. Entscheidend ist, ob Datenmodell, Suche, Veröffentlichung und Betrieb die Anforderungen erfüllen. Eine Modernisierung oder gezielte Trennung von Aufgaben kann ausreichen.

Können Astro und WordPress gemeinsam eingesetzt werden?

Ja. WordPress kann Inhalte verwalten und Astro öffentliche Seiten daraus erzeugen. Dafür müssen Synchronisation, Vorschau, Freigabe und Zuständigkeiten zwischen den Systemen festgelegt sein.

Weiterführend

• CMS, Static Site oder Web-App?
• Astro für Content-Sites
• Astro mit CMS
• WordPress als Plattform

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die behandelten Themen.

• Astro: Content Collections
• Astro: Why Astro?
• Astro: Using a CMS