40 WordPress-Websites auf Astro und Cloudflare Workers: Was unser Umbau wirklich gebracht hat

Eine statische Website kostet im Betrieb fast nichts, braucht keine Updates und lässt sich vollständig aus dem Code-Repository heraus steuern. Genau deshalb haben wir 40 unserer WordPress-Websites auf Astro umgebaut und liefern sie heute über Cloudflare Workers aus. Dieser Erfahrungsbericht zeigt, was dabei realistisch zu erwarten ist und welche Arbeit vorher anfällt.

Der Beitrag beschreibt unser eigenes Projekt, kein Kundenprojekt. Das Team hinter Agentifizierung betreibt inzwischen deutlich mehr als 40 Websites, und weitere sind seit dem ersten Durchgang aus WordPress herausgezogen worden. Nicht jede davon läuft auf Astro; einige nutzen andere statische oder vorgerenderte Frameworks. Das Prinzip ist aber überall dasselbe: Inhalte als Dateien, ein Build, fertige Seiten am Edge. Wir prüfen die technischen Aussagen gegen die aktuellen Cloudflare-Dokumentationen und zeigen, warum dieses Setup für den Betrieb mit KI-Agenten besonders gut geeignet ist.

Unser Umbau in Zahlen

Der Ausgangspunkt: 40 WordPress-Websites auf gemieteten Hetzner-Servern mit Plesk als Verwaltungsoberfläche. Dazu kamen die laufenden Aufgaben, die jede WordPress-Installation mitbringt: Core-Updates, Plugin-Updates, Sicherheitspatches, Backups und gelegentliche Reparaturen nach fehlgeschlagenen Aktualisierungen.

Die Ersparnis von rund 90 US-Dollar im Monat klingt für ein Unternehmen zunächst unspektakulär. Der eigentliche Effekt liegt woanders: Mit dem Server verschwanden die Wartungsaufgaben, die bei 40 Installationen wöchentlich Zeit gekostet haben. Wer diese Stunden einrechnet, kommt auf einen deutlich höheren Wert. Wir haben sie nicht einzeln erfasst und nennen deshalb bewusst keine Zahl.

Warum das Setup funktioniert: statisch statt dynamisch

WordPress baut jede Seite beim Aufruf neu zusammen. PHP liest Inhalte aus der Datenbank, Plugins hängen sich in den Ablauf, Caching-Erweiterungen versuchen, das Ergebnis zwischenzuspeichern. Das ist flexibel, braucht aber einen laufenden Server und eine Software-Kette, die aktuell gehalten werden muss.

Astro geht den umgekehrten Weg. Die Inhalte liegen als Markdown- oder Datendateien im Projekt. Ein Build-Lauf erzeugt daraus fertige HTML-, CSS- und Bilddateien. Diese Dateien werden auf das Cloudflare-Netzwerk hochgeladen und von dort ausgeliefert. Zwischen Besucher und Inhalt läuft im Normalfall kein Programmcode mehr.

Für einen rein statischen Astro-Auftritt ist nicht einmal der Cloudflare-Adapter nötig. Cloudflare beschreibt in seiner Astro-Anleitung für Workers, dass Astro alle Seiten standardmäßig beim Build vorrendert und die Ausgabe direkt als statische Assets hochgeladen wird. Der Befehl dafür besteht aus zwei Schritten: npx astro build && npx wrangler deploy.

Die fünf Schritte der Migration

Wir sind in fünf Schritten vorgegangen. Sie sind in dieser Reihenfolge sinnvoll, weil jeder Schritt das Risiko des nächsten begrenzt: Erst wenn eine Website unter der neuen Adresse geprüft ist, wird die alte abgeschaltet.

1. Inhalte aus WordPress herausziehen

Texte, Bilder, Seitenstruktur, Kategorien und Weiterleitungen werden exportiert. Technisch geht das über die WordPress-REST-API oder den klassischen XML-Export. Wichtig ist die Vollständigkeit: alte URLs, Meta-Beschreibungen, Alt-Texte und Bilddateien in Originalgröße. Was hier fehlt, fehlt später auch in der Suche.

2. Jede Website in Astro neu aufbauen

Die exportierten Inhalte werden zu Markdown- oder JSON-Dateien im Astro-Projekt. Layouts, Navigation und Komponenten entstehen einmal und lassen sich über alle 40 Websites wiederverwenden. Plugin-Funktionen werden nicht übernommen, sondern bewusst entschieden: Was wird durch Code ersetzt, was durch einen externen Dienst, was entfällt?

3. Auf Cloudflare Workers ausliefern

Jede Website wird ein eigener Worker mit statischen Assets. Der Deploy läuft über die Kommandozeile oder eine CI-Pipeline, die bei jedem Commit baut und veröffentlicht. Vor der Umstellung lässt sich jede Website unter einer Vorschau-Adresse vollständig testen.

4. DNS Website für Website umstellen und live prüfen

Dieser Schritt ist die eigentliche Freigabe. Pro Website werden Startseite, wichtige Unterseiten, Weiterleitungen, Formulare, Sitemap und die Anzeige in der Google Search Console geprüft. Erst wenn alles stimmt, folgt die nächste Website. Wer alle 40 an einem Tag umschaltet, verliert bei Fehlern den Überblick.

5. Sichern, dann kündigen

Ein vollständiges Backup der alten Installationen bleibt erhalten, bevor Server und Plesk gekündigt werden. Erst ab diesem Zeitpunkt entsteht die Ersparnis.

Was der kostenlose Workers-Plan hergibt

Die Aussage „läuft kostenlos“ hängt an konkreten Grenzen. Die folgenden Werte stammen aus den Cloudflare-Dokumentationen zu Limits und Preisen, Stand November 2026.

Der entscheidende Punkt steht in der zweiten Zeile: Cloudflare liefert statische Assets ohne Anrechnung auf das Tageslimit aus. Wer seine Websites konsequent statisch baut, bleibt damit auch bei hohem Besucheraufkommen im kostenlosen Plan. Sobald Formulare, Suche oder personalisierte Inhalte über Worker-Code laufen, zählen diese Aufrufe. Der kostenpflichtige Workers-Plan beginnt laut Cloudflare bei 5 US-Dollar im Monat und enthält deutlich höhere Kontingente. Für ein Portfolio dieser Größe bleibt also selbst der Fall „nicht mehr kostenlos“ überschaubar.

Was Sie aufgeben und wie Sie es ersetzen

Die Entscheidung gegen WordPress ist eine Entscheidung gegen bestimmte Komfortfunktionen. Sie lassen sich ersetzen, aber nicht ohne Aufwand. Die Tabelle zeigt die typischen Punkte und die üblichen Lösungen im statischen Setup.

Die ehrliche Rechnung lautet: Zwei bis drei Monate Migrationsarbeit für 40 Websites sind ein ernsthaftes Projekt. Für eine einzelne Website mit aktiver Redaktion und vielen dynamischen Funktionen fällt der Nutzen deutlich kleiner aus als für ein Portfolio aus Unternehmens- und Landingpages, die sich selten ändern. Je mehr Websites und je weniger Dynamik, desto klarer das Ergebnis.

Warum KI-Agenten mit diesem Setup besser arbeiten

Der für uns wichtigste Effekt: Alle umgezogenen Websites werden heute von einem Team aus KI-Agenten gepflegt. Das funktioniert nicht, weil die Agenten besonders klug wären, sondern weil das Setup die Voraussetzungen dafür schafft, die wir in der Agent-Operations-Arbeit immer wieder sehen.

• Jede Änderung ist eine Datei. Ein Agent, der einen Text korrigiert, ein Angebot ergänzt oder eine Weiterleitung einträgt, schreibt in eine Datei und erzeugt einen Commit. Die Änderung ist lesbar, vergleichbar und einem Auftrag zuordenbar.
• Jeder Schritt ist prüfbar. Build, Linting, Linkprüfung und Vorschau laufen automatisch. Ein Agent bekommt eine klare Rückmeldung, ob sein Ergebnis funktioniert, bevor ein Mensch es sieht.
• Die Freigabe bleibt beim Menschen. Ein Pull Request mit Vorschau ist die natürliche Übergabe: Der Agent schlägt vor, die verantwortliche Person gibt frei, der Deploy läuft danach automatisch.
• Rollback ist trivial. Ein fehlerhafter Stand wird mit einem Revert zurückgenommen. Es gibt keine Datenbank, deren Zustand sich zwischenzeitlich verändert hat.
• Kein Admin-Interface. Agenten müssen sich nicht durch ein WordPress-Backend klicken, Plugin-Dialoge interpretieren oder nach Updates prüfen, ob ein Theme noch funktioniert.

In WordPress ist der Zustand einer Website auf Datenbank, Dateisystem, Plugin-Einstellungen und Server verteilt. Ein Agent kann dort zwar arbeiten, aber die Nachvollziehbarkeit und die Prüfbarkeit sind deutlich schlechter. Genau diese beiden Eigenschaften entscheiden darüber, ob ein Unternehmen Agenten Verantwortung für seine digitalen Kundenwege übertragen kann. Wie eine Website aussehen muss, damit Agenten sie auch lesen und nutzen können, beschreiben wir auf der Seite Websites für KI-Agenten und im Beitrag zur Agent-Readiness der eigenen Website.

Für wen sich der Umbau lohnt

Die folgenden Kriterien helfen bei der Entscheidung. Treffen die ersten drei zu, ist die Migration in den meisten Fällen wirtschaftlich sinnvoll.

• Sie betreiben mehrere Websites, die sich im Aufbau ähneln: Unternehmensauftritte, Landingpages, Produktseiten, Blogs.
• Die Inhalte ändern sich planbar und selten, nicht mehrmals täglich durch eine große Redaktion.
• Dynamische Funktionen beschränken sich auf Formulare, Terminbuchung oder Suche und lassen sich durch externe Dienste abdecken.
• Sie möchten, dass KI-Agenten Pflege und Ausbau übernehmen, und brauchen dafür prüfbare, rückgängig machbare Schritte.
• Sie wollen Server, Plesk und die laufende Update-Verantwortung aus dem Unternehmen herausnehmen.

Weniger geeignet ist der Umbau für Shops mit Warenkorb und Kundenkonten, für Portale mit Logins oder für Websites, deren Mehrwert in einem Plugin-Ökosystem liegt, das sich nicht nachbauen lässt. Hier ist ein gemanagtes WordPress-Hosting oft die ruhigere Lösung. Wer dagegen schon einmal nach einem Update eine kaputte Startseite reparieren musste, kennt das Argument für statische Dateien aus eigener Erfahrung.

Welche Entscheidung jetzt sinnvoll ist

Beginnen Sie mit einem Inventar: Welche Websites gibt es, wer verantwortet sie, welche Funktionen sind wirklich dynamisch? Wählen Sie dann eine Website mit geringer Dynamik und geringem Risiko als Pilot. Bauen Sie sie in Astro nach, liefern Sie sie unter einer Vorschau-Adresse aus und lassen Sie die Pflege für einige Wochen testweise über einen Agenten laufen: Textänderung, Vorschau, Freigabe, Deploy. Erst wenn dieser Ablauf stabil ist, lohnt sich die Entscheidung über das gesamte Portfolio.

Die Ersparnis beim Hosting ist dabei der kleinste Posten. Der größere liegt in Wartungszeit, Ausfallrisiko und in der Frage, wie viel Verantwortung Sie KI-Agenten für Ihre Websites überhaupt übertragen können. Ein Setup aus Dateien, Build und automatischem Deploy beantwortet diese Frage deutlich besser als ein Server mit 40 Installationen. Wenn Sie prüfen möchten, welche Ihrer Websites und Prozesse sich für diesen Weg eignen, ordnen wir das im Agentifizierungs-Check gemeinsam ein.

Redaktionsstand: 3. November 2026. Die Angaben zum Portfolio beziehen sich auf eigene Websites des Teams hinter Agentifizierung. Es handelt sich um ein eigenes Projekt, nicht um eine Kundenreferenz; Dauer und Ersparnis sind unsere eigenen Werte aus dem ersten Migrationsdurchgang. Technische Grenzen und Preise: Cloudflare Workers Limits, Cloudflare Static Assets, Cloudflare Workers Pricing, Astro: Deploy to Cloudflare. Grenzen können sich ändern; maßgeblich ist die jeweils aktuelle Dokumentation.