Astro vs. WordPress: zwei Systemformen, nicht zwei Produkte.

Die Frage lässt sich so nicht beantworten, weil die beiden nicht dasselbe sind: WordPress ist ein Redaktionssystem, das die Seite mitrendert, Astro ein Website-Framework ohne eigenes CMS. Nützlich wird die Frage anders gestellt: Wo klemmt es? Klemmt es in der Redaktion, gewinnt WordPress. Klemmt es bei dem, was der Browser laden muss, gewinnt Astro. Klemmt es an beidem, kombinieren Sie beide.

So pauschal stimmt das nicht. Der WordPress-Core wird gut gepflegt, und eine sauber aktualisierte Installation ist kein Sicherheitsproblem. Der strukturelle Unterschied ist die Angriffsfläche: Eine statisch ausgelieferte Seite führt im Request-Pfad keinen Anwendungscode aus, eine PHP-Anwendung mit aktiven Plugins schon. Risiko konzentriert sich erfahrungsgemäß auf Plugins und auf Installationen, die niemand aktualisiert.

Nicht automatisch – aber die Ausgangslage ist besser, weil statisches HTML der Standard ist und Client-JavaScript nur dort landet, wo es angefordert wird. Eine schlecht gebaute Astro-Seite kann trotzdem langsam sein. Deshalb messen wir Ihre Core Web Vitals vor und nach dem Umbau mit Ihren eigenen Felddaten. Mehr dazu auf der Seite zur Astro-Performance-Optimierung.

Ja, aber Sie entscheiden das Wie. Drei Wege: Inhalte bleiben als Markdown im Repository und werden dort bearbeitet; ein Headless CMS liefert eine Redaktionsoberfläche, gern auch WordPress selbst; oder Änderungen laufen per Chat. Der Block-Editor mit seinen freien Layouts kommt so nicht mit – gepflegt werden Felder, nicht Layouts.

Der bleibt in aller Regel, wo er ist. Ein funktionierender Shop mit Zahlungsanbindung, Steuerlogik und Bestellverwaltung wird nicht als Nebeneffekt eines Website-Umbaus ersetzt. Üblich ist ein geteilter Auftritt: Astro liefert die Marketing- und Inhaltsseiten, der Shop läuft weiter unter seiner Adresse. Ob sich mehr lohnt, ist eine getrennte Entscheidung mit eigenem Budget.

Nicht, wenn die Migration als SEO-Projekt geplant wird. Dazu gehören eine vollständige URL-Aufnahme, ein Redirect-Konzept für jede alte Adresse, die Übernahme von Titeln, Meta-Daten und strukturierten Daten sowie ein Monitoring nach dem Go-live. Der übliche Grund für Einbrüche sind fehlende Redirects und geänderte Seitenstrukturen, nicht das Framework. Details auf WordPress zu Astro.

Den Rahmen bestimmen drei Dinge: die Zahl der Seitentypen, die Menge geschäftskritischer Plugin-Funktionen, die neu gebaut werden müssen, und ob eine Redaktionsoberfläche dazukommt. Eine überschaubare Firmenwebsite liegt deutlich unter einem Portal mit Mehrsprachigkeit und Shop-Anbindung. Nach dem Erstgespräch bekommen Sie eine nachvollziehbare Schätzung; die Systematik dahinter steht unter Astro-Kosten.

Die Anzahl der Beiträge ist selten der Engpass: Vier Vorlagen für 4.000 Beiträge sind vier Seitentypen, und Content Collections sind ausdrücklich mit eingebautem Caching für tausende Einträge dokumentiert. Aufwand macht der Zustand der Inhalte – Shortcodes, Page-Builder-Markup, eingebettete Plugin-Blöcke, alte Bildpfade. Für ein gewachsenes Archiv planen wir eher 8 bis 16 Wochen. Gebaut wird parallel, Ihre WordPress-Seite bleibt bis zur Abnahme online, umgeschaltet wird in einem geplanten Fenster mit fertiger Weiterleitungskarte.

Nicht zwangsläufig – genau dafür gibt es die dritte Option. Bleibt WordPress als Headless CMS im Hintergrund, arbeitet Ihre Redaktion weiter in der gewohnten Oberfläche; nur die Auslieferung wechselt. Entscheiden Sie sich gegen WordPress, ändert sich die Arbeitsweise spürbar: Gepflegt werden dann definierte Felder in einem Headless CMS, Markdown-Dateien im Repository oder Nachrichten im Chat – keine frei gebauten Layouts mehr. Was besser passt, hängt daran, wie oft und wie frei Ihr Team publiziert.

Sie kommen nicht als Layout mit. Page-Builder speichern Gestaltung und Inhalt gemeinsam in der Datenbank, in einem Format, das nur das jeweilige Plugin versteht. Übernommen wird der Inhalt, nicht der Baukasten. Wir übersetzen die vorhandenen Layouts in eine überschaubare Zahl von Abschnitts-Komponenten, die Ihre Redaktion danach kombiniert. Das ist echter Aufwand – meist aber auch der Moment, in dem aus vierzig Einzelfall-Layouts ein System wird.

Aus dem Plugin-Inventar, und das steht am Anfang, nicht als Fußnote im Angebot. Wir sortieren jedes Plugin in vier Fächer: fällt weg, weil Astro es selbst mitbringt (Bildoptimierung, Caching, ein Teil des SEO-Markups); wird durch einen Dienst ersetzt (Formular, Consent, Analytics); muss neu gebaut werden (alles Geschäftskritische); oder bleibt in WordPress. Erst diese Liste macht Aufwand und Zeitrahmen belastbar – und manchmal beendet sie die Migrationsfrage sofort.

Ja, aber anders. Astro hat kein Übersetzungs-Plugin, sondern Routing und Content-Modell: Jede Sprachfassung ist ein eigener Eintrag in einer Collection, die URL-Struktur legen Sie fest, hreflang-Angaben entstehen aus dem Modell statt aus einer Plugin-Tabelle. Das ist sauberer und langfristig billiger zu pflegen, aber es ist Bauarbeit. Rechnen Sie Mehrsprachigkeit als eigenen Posten ein: Sie verdoppelt den Aufwand nicht, verschiebt den Zeitrahmen aber spürbar nach oben.

Das Argument stimmt, und wir halten es für keinen Nebenpunkt. WordPress hat den mit Abstand größten Markt an Menschen, die eine Seite übernehmen können. Auf der anderen Seite: Astro steht unter MIT-Lizenz, folgt Semantic Versioning und ist ein gewöhnliches Webprojekt ohne proprietäre Zwischenschicht. Wer React, Vue oder Svelte kann, arbeitet sich in Tagen ein, nicht in Monaten. Der Markt ist kleiner, die Einstiegshürde aber niedrig – beides gehört in die Abwägung.

Ja, und bei gewachsenen Auftritten ist das oft der ruhigere Weg. Üblich ist eine Trennung nach Pfad oder Subdomain: Marketing- und Landingpages ziehen zuerst nach Astro, Blog und Shop bleiben vorerst in WordPress, und ein Reverse Proxy oder die Hosting-Konfiguration verteilt die Anfragen. Das kostet für die Übergangszeit etwas Betriebskomplexität und verlangt saubere kanonische Angaben – senkt aber das Risiko deutlich gegenüber einer Umstellung in einer Nacht.

Ja. Repository, Hosting-Konten und Domains laufen von Anfang an auf Sie – wir arbeiten darin, wir besitzen es nicht. Was entsteht, ist ein Standard-Astro-Projekt unter MIT-Lizenz: übliche Konventionen, dokumentierte Struktur, keine Blackbox und kein Lizenzschlüssel, der bei uns liegt. Zur Übergabe gehören ein Setup-Dokument und auf Wunsch eine gemeinsame Sitzung mit Ihrem Team oder Ihrer neuen Agentur.

Was wir liefern, verantworten wir. Vor dem Go-live halten wir schriftlich fest, was als Fehler gilt und in welcher Frist wir reagieren; die vertraglichen Regelungen dazu stehen im Angebot, nicht in einer FAQ. Technisch arbeiten wir so, dass Fehler früh auffallen: Abnahme im Staging, Prüfliste für URLs, Weiterleitungen, Meta-Daten und strukturierte Daten – und jede Änderung als eigener Commit mit Deploy-Historie, sodass ein Rollback Minuten dauert.

Der Wechsel macht die Sache eher einfacher, weil viele Datenabflüsse in WordPress aus Plugins und Themes stammen, die niemand bewusst ausgewählt hat: eingebundene Schriften, externe Skripte, Tracking in Theme-Bausteinen. In einem Astro-Projekt ist jede externe Einbindung eine bewusste Zeile Code und damit prüfbar. Consent-Management, Auftragsverarbeitung und Hosting-Standort bleiben trotzdem Ihre Entscheidungen – wie wir das umsetzen, steht auf DSGVO-konforme Website.

Ja. Astro ist freie Open-Source-Software unter MIT-Lizenz, WordPress ist ebenfalls freie Software. Lizenzgebühren fallen bei keinem von beiden an. Kosten entstehen durch Entwicklung, Hosting und Betrieb – bei WordPress zusätzlich häufig durch kostenpflichtige Plugins und Themes.

Ja, das ist einer seiner Kernfälle. Beiträge liegen als Markdown oder MDX in einer Content Collection mit Zod-Schema; daraus entstehen Übersichten, Kategorien, Feeds und Detailseiten mit TypeScript-Typen. Was Astro nicht mitbringt, ist die Schreiboberfläche – die kommt aus einem Headless CMS, aus dem Repository oder per Chat.

Die Voraussetzungen sind gut: Standardmäßig wird die Seite vorgerendert und als statisches HTML ausgeliefert, Crawler sehen also fertigen Inhalt, und wenig Client-JavaScript hilft den Core Web Vitals. Rankings entstehen trotzdem aus Inhalt, Struktur und Verlinkung. Ein Frameworkwechsel ersetzt keine SEO-Arbeit – siehe SEO-Audit.

Ja. WordPress gehört zu den Quellen, für die die Astro-Dokumentation einen eigenen Migrations-Guide führt. Praktisch lesen wir Inhalte über die WordPress-API oder einen Export aus und überführen sie in Content Collections. Übernommen werden Texte, Medien und Metadaten – nicht Page-Builder-Layouts und nicht Shortcodes.

WordPress läuft weiter als Redaktionssystem, rendert aber nicht mehr die öffentliche Seite. Die Inhalte gibt es über eine API aus, das Frontend baut Astro und liefert es statisch aus. Der Editor bleibt, die Auslieferung wechselt. Details auf WordPress als Headless CMS.