# 40 WordPress-Websites auf Astro und Cloudflare Workers: Was unser Umbau wirklich gebracht hat > Wir haben 40 WordPress-Websites auf Astro und Cloudflare Workers umgebaut. Was das Setup leistet, wo die Grenzen des Free-Plans liegen und warum… - Quelle: https://www.agentifizierung.de/blog/wordpress-zu-astro-und-cloudflare-workers-40-websites-migriert - Übersicht: https://www.agentifizierung.de/llms.txt - Volltext: https://www.agentifizierung.de/llms-full.txt --- [Zurück zum Blog](https://www.agentifizierung.de/blog) ![KI-generierte Symbolillustration: Ein überladener Server-Turm mit Plugin-Modulen wird durch ein Tor in einen Strom leichter statischer Seiten verwandelt, die auf einem globalen Edge-Netzwerk landen.](https://www.agentifizierung.de/blog-media/2026/11/wordpress-zu-astro-cloudflare-workers-migration.webp) Neu Artikel ## 40 WordPress-Websites auf Astro und Cloudflare Workers: Was unser Umbau wirklich gebracht hat [Gorden Wübbe](https://www.agentifizierung.de/autoren/gorden-wuebbe) 2\. November 2026 **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. Kennzahl Wert Einordnung Umfang 40 WordPress-Websites im ersten Durchgang Portfolio, keine Einzelseite; weitere Websites folgten später Dauer der Migration 2 bis 3 Monate Rechnerisch etwa ein bis anderthalb Arbeitstage je Website, inklusive Prüfung Vorher Hetzner-Server plus Plesk Eigener Server, eigene Verantwortung für Updates und Sicherheit Nachher Astro, statische Seiten, Cloudflare Workers Free; einzelne Websites auf anderen statischen Frameworks Keine Plugins, kein Server, keine Datenbank im Betrieb Ersparnis rund 90 US-Dollar im Monat Nur Hosting und Verwaltung, ohne den Zeitaufwand für Wartung Pflege danach Team aus KI-Agenten Änderungen laufen über Code, Build und Deploy 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. Vorher: WordPress auf eigenem Server Besucher → Webserver + PHP → Plugins + Theme → Datenbank - Seite entsteht bei jedem Aufruf neu - Updates für Core, Plugins, PHP und Server - Backups, Monitoring und Sicherheitspatches im eigenen Betrieb Nachher: Astro auf Cloudflare Workers Besucher → Statische Dateien am Edge Git-Repository → astro build → wrangler deploy - Seite entsteht einmal beim Build - Keine Plugins, keine Datenbank, kein Server im Betrieb - Änderungen sind Commits, Rollback ist ein Revert Schematische Darstellung. Der Build läuft nur bei Änderungen; die Auslieferung besteht aus fertigen Dateien. Für einen rein statischen Astro-Auftritt ist nicht einmal der Cloudflare-Adapter nötig. Cloudflare beschreibt in seiner [Astro-Anleitung für Workers](https://developers.cloudflare.com/workers/framework-guides/web-apps/astro/), 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. Animation anhaltenAnimation fortsetzen Illustrativer Ablauf, keine Live-Daten. Die Animation lässt sich über die Schaltfläche anhalten und wird bei reduzierter Bewegung automatisch deaktiviert. #### 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](https://developers.cloudflare.com/workers/platform/limits/) und [Preisen](https://developers.cloudflare.com/workers/platform/pricing/), Stand November 2026. Grenze im Workers-Free-Plan Wert Bedeutung für 40 statische Websites Worker-Aufrufe 100.000 pro Tag, Zurücksetzung um Mitternacht UTC Zählt nur, wenn Programmcode läuft, etwa für Formulare oder dynamische Routen Anfragen an statische Assets kostenlos und unbegrenzt Normale Seitenaufrufe einer statischen Website zählen nicht gegen das Tageslimit Worker je Account 100 40 Websites als 40 Worker passen in den kostenlosen Plan Dateien je Worker-Version 20.000 Für Unternehmenswebsites und Blogs ausreichend; große Bildarchive vorher prüfen Größe je Datei 25 MiB Videos und große Downloads gehören in einen separaten Speicher CPU-Zeit je Aufruf 10 ms Für statische Auslieferung irrelevant, für Serverlogik eine harte Grenze 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. Funktion in WordPress Lösung im statischen Astro-Setup Aufwand Visueller Editor für Redakteure Markdown-Dateien im Repository oder ein Headless-CMS, das in den Build schreibt Schulung oder zusätzlicher Dienst Kontaktformulare Externer Formulardienst oder ein kleiner Worker-Endpunkt gering, zählt gegen Worker-Aufrufe Seiteninterne Suche Suchindex beim Build, zum Beispiel mit Pagefind gering Kommentare, Logins, Mitgliederbereiche Externe Dienste oder bewusster Verzicht hoch, oft Grund gegen die Migration Plugins für SEO, Caching, Sicherheit Entfallen; Meta-Daten, Sitemap und Caching sind Teil des Builds einmalig im Template Updates und Patches Abhängigkeiten im Projekt aktualisieren, prüfbar in CI planbar statt dringend 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](https://www.agentifizierung.de/ki-agenten-management) 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](https://www.agentifizierung.de/website-fuer-ki-agenten) und im Beitrag zur [Agent-Readiness der eigenen Website](https://www.agentifizierung.de/blog/agent-readiness-pruefen-ist-ihre-website-bereit-fuer-ki-agenten). Aufgabe des Agenten Mit WordPress Mit Astro, Git und Cloudflare Text auf 40 Websites aktualisieren 40 Logins, 40 Editor-Sitzungen, kein gemeinsamer Diff Ein Commit über ein gemeinsames Template, ein Review, ein Deploy Neue Landingpage anlegen Seite im Backend bauen, Theme-Abhängigkeiten beachten Markdown-Datei und Komponente, Vorschau-URL im Pull Request Fehler nach Änderung beheben Backup einspielen oder manuell zurückbauen Revert des Commits, automatischer Deploy Sicherheitsupdate Dringend, pro Installation, mit Ausfallrisiko Abhängigkeiten im Projekt aktualisieren, Build prüft das Ergebnis Nachweis, wer was geändert hat Revisionshistorie je Seite, Plugin-Änderungen unsichtbar Vollständige Git-Historie mit Auftrag, Autor und Zeitpunkt ### 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](https://www.agentifizierung.de/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](https://developers.cloudflare.com/workers/platform/limits/), [Cloudflare Static Assets](https://developers.cloudflare.com/workers/static-assets/), [Cloudflare Workers Pricing](https://developers.cloudflare.com/workers/platform/pricing/), [Astro: Deploy to Cloudflare](https://docs.astro.build/en/guides/deploy/cloudflare/). Grenzen können sich ändern; maßgeblich ist die jeweils aktuelle Dokumentation. Auf Ihr Unternehmen übertragen ### Welcher Prozess eignet sich wirklich für einen KI-Agenten? Im persönlichen Agentifizierungs-Check ordnen wir Ziel, Prozess, Systeme und einen realistischen Einstieg ein. [Agentifizierungs-Check starten](https://www.agentifizierung.de/agentifizierungs-check) ### Häufig gestellte Fragen #### #### #### #### #### Veröffentlicht am 2\. November 2026 Von [Gorden Wübbe](https://www.agentifizierung.de/autoren/gorden-wuebbe) [← Weitere Artikel](https://www.agentifizierung.de/blog) ### Ähnliche Artikel [ ![Moltworker auf Cloudflare 2026: Serverless OpenClaw ohne eigenen Rechner](https://www.agentifizierung.de/blog-media/2026/02/moltworker-auf-cloudflare-serverless-openclaw-ohne-eigenen-rechner-funktioniert-.jpg) Moltworker auf Cloudflare 2026: Serverless OpenClaw ohne eigenen Rechner Erfahren Sie, ob Moltworker auf Cloudflare 24/7 funktioniert. Kosten, Leistung & Alternativen im Vergleich für Marketing-Entscheider in 2026. 23\. Feb. 2026 Lesen ](https://www.agentifizierung.de/blog/moltworker-auf-cloudflare-2026-serverless-openclaw-ohne-eigenen-rechner) [ ![Gemini Quellen: Welche Websites 2026 am häufigsten zitiert werden](https://www.agentifizierung.de/blog-media/2026/02/welche-websites-werden-von-gemini-am-haeufigsten-zitiert.jpg) Gemini Quellen: Welche Websites 2026 am häufigsten zitiert werden Entdecken Sie, welche Websites Gemini 2026 am häufigsten zitiert & wie Sie davon profitieren. SEO-Vergleich für Marketing-Entscheider. 10\. Feb. 2026 Lesen ](https://www.agentifizierung.de/blog/gemini-quellen-welche-websites-2026-am-haeufigsten-zitiert-werden) [ ![Was Geschäftsführer aus BMWs KI-Umbau ableiten können](https://www.agentifizierung.de/blog-media/2026/10/bmw-ki-transformation.webp) Was Geschäftsführer aus BMWs KI-Umbau ableiten können BMWs KI-Umbau als Anlass für den eigenen Business Case: Prozesse, Unternehmenswissen, Systemintegration und wirtschaftliche Wirkung gemeinsam betrachten. 13\. Okt. 2026 Lesen ](https://www.agentifizierung.de/blog/bmw-ki-transformation-was-geschaeftsfuehrer-ableiten-koennen) [Alle Artikel ansehen](https://www.agentifizierung.de/blog)