Für die meisten Unternehmensseiten ist Astro 7 auf Cloudflare günstiger, schneller und leichter abzusichern als WordPress 7.0. Dieser Vorsprung hat allerdings einen Preis, den die vorherige Fassung dieses Vergleichs verschwiegen hat: Das Framework hat einen eigenen Release-Takt, und jemand bezahlt ihn in Entwicklerzeit.
Die erste Fassung dieses Vergleichs entstand im April, gegen Astro 6 und ein WordPress 7.0, das noch im Release Candidate steckte. Beide sind inzwischen erschienen, und wir haben diese Seite von Astro 6 auf Astro 7 gehoben. Damit habe ich etwas, das mir damals fehlte: eine aufgeschlüsselte Rechnung für eine große Framework-Migration, gelaufen auf unserem eigenen Korpus von deutlich über zehntausend Seiten.
An der Plattform-Empfehlung hat sich nichts geändert. Geändert hat sich, wie viel ich über die versteckten Kosten auf der Astro-Seite weiß.
WordPress 7.0, drei Monate nach dem Release
WordPress 7.0 erschien am 20. Mai 2026. Es lohnt sich, das Angekündigte vom tatsächlich Ausgelieferten zu trennen.
AI Client und Abilities API
AI Client ist Infrastruktur, kein fertiger AI Writer. WordPress 7.0 liefert eine einheitliche API für die Kommunikation mit Modellen, will aber einen externen Schlüssel und Konfiguration, bevor überhaupt etwas passiert. Die Abilities API erlaubt Agenten, WordPress-Funktionen programmatisch zu entdecken und aufzurufen. Das ist für Plugin-Autoren relevant und für die Redaktion praktisch unsichtbar.
Ein wichtiges Fundament. Keine Funktion, die ein Kunde am ersten Tag im Backend bemerkt.
Real-time Collaboration ist nicht erschienen
Das gleichzeitige Bearbeiten war das lauteste Versprechen dieses Releases und wurde nach technischen Problemen gestrichen. Drei Monate später fehlt es in der 7.0-Linie weiterhin. Wer einem Kunden WordPress 7.0 mit der Aussicht auf mehrere Redakteure in einem Dokument verkauft hat, führt jetzt ein unangenehmes Gespräch.
Die Architektur darunter hat sich nicht bewegt
Das aufgefrischte Backend und die neuen Blöcke sind optisch ein Fortschritt. Darunter stehen weiterhin PHP, MySQL und ein klassischer Server, der gepatcht, gecacht und überwacht werden will. Keine der 7.0-Neuerungen ändert daran, dass jedes Plugin die Angriffsfläche vergrößert und Performance erst nach einer Caching- und CDN-Schicht eintritt.
WordPress 7.0, der Handel
Was es liefert:
- Den besten Content-Editor für nicht-technische Menschen, in dieser Kategorie ohne echte Konkurrenz
- Ein Plugin-Ökosystem im Bereich von Zehntausenden
- WooCommerce als vollständige Commerce-Plattform
- Die Abilities API als Grundlage für Agenten-Anbindungen
Was es kostet:
- Core-Gewicht und Overhead, den man nicht abschalten kann
- Eine Angriffsfläche, die mit jedem Plugin wächst
- Budgets für Hosting, Backups, Monitoring und Sicherheits-Plugins
- Performance, die erst nach Caching und CDN eintritt
- Sicherheitsreleases im Wochenrhythmus
Astro 7 und was sich gegenüber Version 6 wirklich geändert hat
Astro 7.0.0 erschien am 22. Juni 2026, 104 Tage nach Astro 6.0.0. Drei Änderungen haben Folgen, die im Changelog nicht sichtbar werden, bis der eigene Build läuft.
Der Rust-Compiler ist kein Experiment mehr
In Astro 6 war der in Rust geschriebene Compiler ein optionales Experiment. Astro 7 tauscht die Abhängigkeit @astrojs/compiler gegen @astrojs/compiler-rs und macht sie zum Standard. Die Builds werden schneller. Der Parser wird zugleich strenger.
Uns hat es an genau einer Zeile zerlegt. Ein HTML-Kommentar innerhalb eines JSX-Ausdrucks, etwa {import.meta.env.DEV && ( <!-- ... --> )}, kam durch den alten Compiler und wird vom neuen abgelehnt. Die Korrektur ist ein JavaScript-Kommentar. Eine Minute Arbeit, sofern man weiß, wonach man sucht, denn die Fehlermeldung zeigt auf eine Position im kompilierten Ergebnis und nicht im Quelltext.
Vite 8 darunter
Astro 6 stand auf Vite 7. Astro 7 wechselt auf Vite 8, die Rolldown-basierte Linie. Für die meisten Projekte ist das unsichtbar, bei großen Korpora lohnt jedoch ein Blick auf den Speicherverbrauch im Build, weil das Allokationsprofil anders aussieht als zuvor.
CSP hasht Inline-Styles, und genau das beißt
Diese Änderung hat uns einen ganzen Tag gekostet.
Astro 7 berechnet Hashes für eingebettete <style>-Blöcke und trägt sie in die style-src-Direktive ein. Nach der Content-Security-Policy-Spezifikation hebt jeder Hash in einer Direktive 'unsafe-inline' auf. Ergebnis: Sämtliche dynamischen style=""-Attribute funktionieren nicht mehr. Bei uns fielen die Shiki-Token-Farben in Codeblöcken aus, dazu Theme-Variablen, Animationsgeschwindigkeiten und Hintergrundbilder. Allein die Startseite produzierte 26 CSP-Verstöße, betroffen war jede Seite mit Syntaxhervorhebung.
Ein Schalter zum Abstellen existiert nicht. 'unsafe-hashes' allein hilft ebenfalls nicht, weil es Style-Attribute abdeckt, nicht aber den Inhalt von <style>-Elementen.
Die Lösung fiel einfacher aus als befürchtet, denn die Menge der Inline-Styles ist endlich. Bei rund 260.000 Vorkommen im gesamten Korpus gab es 143 eindeutige Werte. Einmal einsammeln, die Hashes in die Konfiguration schreiben, 'unsafe-hashes' für den Attributfall ergänzen, und die Verstöße fallen über alle Template-Typen auf null.
Bleibt eine Dauerverpflichtung. Jede neue Komponente, die einen neuen Inline-Style-Wert einführt, kommt entweder auf die Liste oder wird in der Produktion still blockiert. Dafür braucht es ein CI-Gate, sonst erfährt man davon aus einer Nutzermeldung.
Eine neue Standard-Markdown-Pipeline
Astro 7 ändert die Standardverarbeitung von Markdown. Wer eine eigene remark- und rehype-Kette betreibt, muss @astrojs/markdown-remark explizit einbinden, um das bisherige Verhalten zu behalten. Eine Zeile in den Abhängigkeiten, aber wenn sie fehlt, entsteht ein stiller Renderunterschied statt eines Build-Fehlers, und genau deshalb rutscht das leicht durch.
Was uns die Migration von Astro 6 auf 7 tatsächlich gekostet hat
Zahlen aus unserem eigenen Rollout, nicht aus der Dokumentation.
| Position | Ergebnis |
|---|---|
| Geänderte Dateien | 5 |
| Geänderte Zeilen Template-Quellcode | 1 |
| Zutreffende Headline-Breaking-Changes | 1 von 4 |
| CSP-Verstöße vor der Korrektur, nur Startseite | 26 |
| Zu hashende eindeutige Inline-Style-Werte | 143 |
| Seiten im Preview-Build nach der Migration | 15.850, Exit-Code 0 |
| Unit-Tests | 103 von 103 |
| Typecheck-Fehler | 0 |
Drei der vier Headline-Breaking-Changes trafen auf uns nicht zu, und darin liegt der Kern. Wir haben keine Astro DB, keinen Server-Adapter zu verschieben und bauen statisch, also ging die Umstellung des Server-Einstiegspunkts an uns vorbei. Ein Projekt mit SSR, Adapter und Astro-Datenbank bekommt für dieselbe Migration eine völlig andere Rechnung.
Die praktische Lehre: Die Kosten eines großen Astro-Releases skalieren nicht mit der Seitenzahl, sondern mit der Zahl der Berührungspunkte zur Laufzeitumgebung. Unsere über vierzehntausend Seiten kosteten weniger als eine einzelne Anwendung mit Astro DB und eigenem Adapter gekostet hätte.
Direkter Vergleich 2026
| Merkmal | WordPress 7.0 | Astro 7 + Cloudflare | Sieger |
|---|---|---|---|
| Ladezeit | 1,5 bis 4 s | unter 500 ms, meist 200 bis 300 ms | Astro |
| Hosting-Kosten pro Jahr | mehrere Hundert Euro | null bis niedrig zweistellig | Astro |
| Sicherheit | breite Angriffsfläche | statisches HTML plus Inseln | Astro |
| Redaktionelle Bedienung | Block-Editor, ohne echte Konkurrenz | gut, Content Collections plus CMS | WordPress |
| Core Web Vitals | gut nach Optimierung | fast immer 100/100 | Astro |
| Skalierbarkeit | mittel, braucht Caching | sehr hoch, Auslieferung am Edge | Astro |
| Plugin-Ökosystem | Zehntausende | npm- und Cloudflare-Integrationen | WordPress |
| E-Commerce | WooCommerce | kein natives Gegenstück | WordPress |
| Lernkurve | leicht für Inhalte, schwer für Code | mittel | Unentschieden |
| Infrastruktur-Wartung | hoch | minimal | Astro |
| Am Framework dranbleiben | gering, Majors selten | real, Majors im Monatsabstand | WordPress |
Ergebnis: Astro 7, WordPress 3, ein Unentschieden.
WordPress hat in dieser Ausgabe einen Punkt zurückgeholt, und zwar nicht über eine neue Funktion, sondern über den Release-Takt. Eine WordPress-Seite von vor drei Jahren baut noch, weil es keinen Build gibt. Eine Astro-Seite von vor drei Jahren liegt zwei Majors zurück und jemand muss sie nachziehen.
Wann 2026 migrieren, meine 8-Punkte-Checkliste
Eine Migration lohnt sich, wenn mindestens fünf von acht Punkten zutreffen:
- Content-Seite, Blog oder Landingpage, also genau das, wofür Astro gebaut wurde
- PageSpeed unter 80 trotz WordPress-Optimierung, was ein Architektur- und kein Konfigurationsproblem bedeutet
- Hosting-Kosten über etwa zweihundert Euro im Monat
- Wiederkehrende Sicherheitsvorfälle, Plugin-Patches, Brute-Force-Versuche
- Ein Entwicklerteam, das JavaScript und TypeScript beherrscht und noch da ist, wenn das nächste große Update ansteht
- Kein Bedarf an WooCommerce oder einem umfangreichen Login-Bereich
- SEO hat Priorität und Core Web Vitals bewegen die Positionen
- Die Seite bedient mehrere Länder und globale TTFB zählt
Punkt fünf ist gegenüber der April-Fassung dieser Liste bewusst breiter gefasst. Die Anforderung ist nicht, am Launch-Tag JavaScript zu können. Die Anforderung ist zu wissen, wer neun Monate später npm update ausführt.
Drei Punkte oder weniger: bei WordPress bleiben. Vier: Hybrid prüfen. Fünf oder mehr: Migration lohnt sich.
Fallstudie, vorher und nachher
Unternehmensauftritt, Kunde aus Warschau
Vorher: WordPress mit Elementor, PageSpeed mobil im roten Bereich, Ladezeit in Sekunden, eine laufende monatliche Hosting-Position.
Nachher: Astro auf Cloudflare Pages, PageSpeed im grünen Bereich, Ladezeit deutlich unter einer Sekunde, statisches Hosting im kostenlosen Tarif.
Nettoeffekt: Die Hosting-Kostenposition verschwand, und die Core Web Vitals gingen auf den Haupttemplates von Rot auf Grün. Dieselbe Seite hat später unter unserer Wartung die Migration von Astro 6 auf 7 durchlaufen, und der Kunde bemerkte davon nichts außer einem Deploy.
wppoland.com, diese Seite
Über vierzehntausend vorgerenderte Seiten in sechs Sprachen, von denen etwa dreitausend als indexierbarer Inhalt in den Sitemaps stehen. Der Rest ist ein Stadt-mal-Leistung-Fan-out mit noindex. Hosting im kostenlosen Cloudflare-Tarif. Dieselbe Seite lief zuvor auf WordPress mit bezahltem Monatshosting.
Die Migration dieses Korpus von 6 auf 7 waren fünf Dateien und ein Arbeitstag, davon fast alles Content Security Policy.
Wer pflegt die Seite in drei Jahren? Der Kompetenzmarkt im DACH-Raum
In fast jedem Angebotsgespräch in Deutschland und Österreich kommt eine Frage, die in keiner Feature-Tabelle steht: wer arbeitet an dieser Seite weiter, wenn die heutige Agentur nicht mehr im Boot ist. Technisch ist die Antwort bei WordPress und Astro dieselbe, denn beides lässt sich übergeben. Am Markt ist sie es nicht.
WordPress-Kompetenz ist im DACH-Raum breit gestreut. In fast jeder mittelgroßen Stadt sitzen freie Entwickler, die eine bestehende Installation übernehmen können, dazu kommen regelmäßige Meetups und WordCamps, über die man diese Leute überhaupt erst findet. Ein Dienstleisterwechsel ist dann unangenehm, aber selten ein Projektrisiko.
Bei Astro sieht der Markt anders aus. TypeScript-Entwickler gibt es reichlich, nur sitzen sie überwiegend in Produktteams und in Agenturen mit eigener Entwicklungsabteilung, nicht im Pool der Freiberufler, die kurzfristig eine fremde Codebasis übernehmen. Wer Astro wählt, wählt implizit einen kleineren Kreis möglicher Nachfolger. Dafür findet dieser Nachfolger ein typisiertes Repository mit Git-Historie vor und keine über Jahre gewachsene Plugin-Landschaft, deren Entscheidungen niemand mehr begründen kann.
Der Release-Takt aus dem vorigen Abschnitt verschärft das hier zusätzlich. Eine übernommene WordPress-Installation ist auch nach zwei Jahren Stillstand betriebsbereit. Ein übernommenes Astro-Projekt, das zwei Majors zurückliegt, verlangt vom Nachfolger zuerst eine Migration, bevor er die erste inhaltliche Änderung ausliefern kann. Das gehört in den Übergabevertrag und nicht in die erste Rechnung des Nachfolgers.
Dazu kommt eine Eigenheit, die man außerhalb des deutschsprachigen Raums selten sieht. In größeren Vergabeverfahren steht hier fast nie nur WordPress gegen Astro. Sobald ein Verband, ein Konzern oder eine öffentliche Einrichtung beteiligt ist, liegt TYPO3 mit auf dem Tisch, meist samt einem Redaktionsteam, das seit Jahren damit arbeitet. Gegen TYPO3 gewinnt Astro praktisch nie mit Argumenten aus der Entwicklungsabteilung, sondern nur über die Redaktion und den laufenden Betrieb.
| Frage beim Dienstleisterwechsel | WordPress 7.0 | Astro 7 |
|---|---|---|
| Nachfolger kurzfristig findbar | breiter Markt an Freiberuflern | kleiner, meist Agenturen |
| Einarbeitung in den Bestand | viele Plugins, wenig Doku | typisiertes Repo, Git-Historie |
| Redaktion arbeitet ohne Entwickler weiter | ja | nur mit angebundenem CMS |
| Übergabe ohne Betriebsstillstand | Zugangsdaten genügen meist | Repo, Build und Deploy-Kette nötig |
| Zustand nach zwei Jahren ohne Pflege | lauffähig, ungepatcht | lauffähig, aber Majors im Rückstand |
Die praktische Konsequenz aus unseren Projekten: Wenn die Redaktion im Haus sitzt und dort personell wechselt, ist WordPress die risikoärmere Wahl. Wenn Entwicklung ohnehin extern und projektweise vergeben wird, lässt sich ein sauberes Astro-Repository leichter übergeben als eine gewachsene WordPress-Installation, bei der die Übernahme erst einmal mit einem Plugin-Audit beginnt.
So läuft eine Migration von WordPress zu Astro in der Praxis
Schritt 1, Audit der WordPress-Seite
Custom Post Types zählen, Plugins mit ihrer tatsächlichen Funktion auflisten, Templates kartieren. Das bestimmt die Komplexität von allem Weiteren.
Schritt 2, Inhalte exportieren
WP CLI oder REST-API, um Beiträge, Seiten und Medien nach Markdown oder JSON zu ziehen. Der Großteil davon lässt sich automatisieren.
Schritt 3, Astro-Templates bauen
Layouts und Komponenten in .astro-Syntax nachbauen. Tailwind CSS verhält sich identisch. Die meisten WordPress-Templates haben direkte Entsprechungen.
Schritt 4, Content Collections
Inhaltstypen mit Zod-Validierung definieren. Das Gegenstück zu Custom Post Types, nur dass die Typisierung den Fehler im Build statt in der Produktion fängt.
Schritt 5, Hosting und DNS
Cloudflare Pages mit dem Git-Repository verbinden, Domain konfigurieren. Builds laufen bei jedem Push.
Schritt 6, Eins-zu-eins-Redirects
Jede alte URL auf ihren neuen Pfad abbilden. Das ist der Schritt, an dem Rankings sterben, wenn er nebenbei erledigt wird.
Schritt 7, Tests und GSC-Einreichung
Vollständiger Crawl, Lighthouse-Läufe auf jedem Template-Typ, neue Sitemap in der Google Search Console.
Schritt 8, dreißig Tage Monitoring
Positionen, Indexierung und Core Web Vitals im ersten Monat verfolgen.
Heute käme ein neunter Schritt dazu: Notieren, welche Astro-Version ausgeliefert wurde und was beim nächsten Major zu prüfen ist. Ein Runbook am Migrationstag kostet eine Stunde. Dasselbe Wissen ein halbes Jahr später zu rekonstruieren kostet einen Tag.
Hybridlösung, WordPress plus Astro
Man muss sich nicht entscheiden. Der Hybrid sieht so aus:
- WordPress als Headless CMS, das Redaktions-Backend
- Astro als Frontend, das statische Seiten aus WordPress-Daten erzeugt
- WPGraphQL oder die REST-API als Brücke
- Cloudflare Pages als Hosting für das Frontend
Die Redaktion behält ihre gewohnte Oberfläche, Besucher bekommen eine statische Seite, Entwickler einen modernen Stack. Das vollständige Kostenmodell dahinter steht im TCO-Leitfaden headless gegen Monolith.
Die versteckten Kosten, über die ich im April nicht geschrieben habe
Astro 6.0.0 erschien am 10. März 2026. Astro 7.0.0 am 22. Juni. Ende August stand die 7.x-Linie bei 7.2.8. Diesen Takt hatte WordPress nie.
Für uns ist das tragbar, weil wir den eigenen Stack pflegen und CI-Gates haben, die Drift abfangen, bevor sie in die Produktion gelangt. Für einen Kunden, der eine Seite erhalten hat und dann zwei Jahre verschwunden ist, sieht es anders aus. Die Seite läuft weiter, denn statisches HTML hört nicht auf zu funktionieren. Aber nach zwei Jahren noch etwas hinzuzufügen heißt, zwei Majors auf einmal zu überspringen, und das ist deutlich schwerer als zwei aufeinanderfolgende Migrationen.
Die ehrliche Fassung der Empfehlung lautet deshalb: Astro gewinnt bei Performance, Infrastrukturkosten und Sicherheit. WordPress gewinnt darin, dass man es länger sich selbst überlassen kann. Wenn im Wartungsbudget keine Position für technische Reviews steht, ist diese zweite Eigenschaft mehr wert, als die Tabelle vermuten lässt.
Energieverbrauch und CSRD-Berichterstattung
Bei Kunden, die unter die Nachhaltigkeitsberichterstattung fallen, taucht der Energieverbrauch der Website inzwischen in Ausschreibungsunterlagen auf. Es lohnt sich, gleich zu trennen, was belegbar ist, und was im Angebot nur gut klingt.
Der Mechanismus ist real und einem Prüfer leicht zu erklären. Jeder dynamische Seitenaufruf in WordPress startet einen PHP-FPM-Prozess und eine Reihe von MySQL-Abfragen, der Aufruf verbraucht also Rechenzyklen im Rechenzentrum. Eine statische Seite kommt aus dem Edge-Cache und beschäftigt bei einem normalen Cache-Treffer gar keinen Anwendungsprozess. Über die Richtung des Unterschieds gibt es keinen Streit.
Über die Zahl schon. Wir geben Kunden keine prozentuale Einsparung beim Energieverbrauch, weil wir keine gemessen haben und die in Anbietermaterial kursierenden Werte keine veröffentlichte Methodik hinter sich haben. Wenn eine konkrete Zahl in einen Bericht soll, muss sie aus den Daten des Hosters für den jeweiligen Zeitraum stammen und nicht aus einem Architekturvergleich.
Praktischer Rat: Nehmen Sie das, was Ihr Anbieter tatsächlich über seine Infrastruktur und seinen Energiemix veröffentlicht, und zitieren Sie es als dessen Aussage, nicht als eigene Messung. Der Wechsel auf eine statische Architektur ist ein Argument über Ressourcenverbrauch, kein Umweltzertifikat.
Meine Prognose für 2026 und 2027
WordPress bleibt führend bei WooCommerce-Shops, Seiten mit nicht-technischer Redaktion, Projekten auf Basis fertiger Plugins und Unternehmen, die schnell und günstig starten müssen.
Astro mit Cloudflare übernimmt Content-Seiten und performance-getriebene Blogs, Unternehmensauftritte und Landingpages, technische Dokumentation sowie mehrsprachige Seiten mit globaler Reichweite.
Meine April-Schätzung sah statische Frameworks bis Ende 2027 bei 30 bis 40 Prozent der heute auf WordPress laufenden content-getriebenen Seiten. Daran halte ich fest, mit dem Vorbehalt aus dem Abschnitt darüber: Diese Migration rechnet sich nur dort, wo das Frontend als Software budgetiert ist.
Fazit
WordPress 7.0 ist ein solides Release, das die Grundlagen der Plattform nicht antastet. Astro 7 ist eher Aufräumarbeit unter der Haube als neue Funktionen für Nutzer: Rust-Compiler als Standard, Vite 8 und eine strengere CSP.
Onlineshop bauen: WordPress. Unternehmensauftritt, Blog oder Landingpage mit Fokus auf Performance und SEO: Astro 7 mit Cloudflare. Beides: den Hybrid prüfen.
Wenn Sie unsicher sind, schreiben Sie mir. Falls Astro die richtige Wahl für Ihr Projekt ist, steht mehr auf der Seite Astro Entwickler.
Mariusz Szatkowski, WordPress- und Astro-Entwickler. Organisator des WordCamp Gdynia, WordPress-Core-Contributor. Baut auf beiden Plattformen für Kunden in Polen und Europa.
