Von WordPress zu Cloudflare, Astro und Claude Code: Warum wir gewechselt haben

Falls dir keiner dieser Namen etwas sagt: kein Problem, es sind nur Werkzeuge. Hier geht es darum, wie die Website eines echten Unternehmens, ESGready, einer ESG-Transformationsberatung für den deutschen Mittelstand, auf einen neueren Stack umgezogen ist: Astro, Cloudflare und ein KI-Coding-Tool namens Claude Code. Der Text richtet sich an alle, die keine Entwickler sind, aber wissen wollen, was so ein Umzug tatsächlich bedeutet. (Alle Zahlen und die komplette Timeline stehen in der ausführlichen Fallstudie; dieser Beitrag ist die kürzere Version zum Mitlernen.)

1. Warum jetzt

ESGready-Gründer Frank Siebke gewann Aufträge über Direktansprache und Konferenzvorträge, und im August 2026 tauchte das Unternehmen mit seiner neuen Positionierung auch in Fachartikeln auf. Der Schwung war echt. Die Website hielt damit noch nicht Schritt: Bei Auffindbarkeit und Ladegeschwindigkeit war viel Luft nach oben, und bis zum nächsten Webinar blieben neun Tage.

Frank hatte selbst schon mit einem einzigen KI-Prompt einen Redesign-Entwurf skizziert, ein wirklich guter Ausgangspunkt für Richtung und Inhalte. Die eigentliche Schwäche für die Auffindbarkeit lag nicht darin, dass er JavaScript nutzte (Google kann JavaScript rendern), sondern darin, dass alles auf einer einzigen Seite stand. Es gab keine einzelnen, eigenständig adressierbaren Seiten, die Suchmaschinen und KI-Systeme jeweils für sich finden und verlinken konnten. Eine starke Vision, aber die falsche Form für Auffindbarkeit, die Seite für Seite funktioniert.

Das war der eigentliche Auslöser: nicht "WordPress ist veraltet", sondern "wir haben neun Tage, echten Schwung, den die Website tragen muss, und einen Entwurf, der eine andere Form braucht, um gefunden zu werden."

2. Was sich konkret geändert hat

Der neue Stack besteht aus wenigen Teilen, und jedes hat eine klare Aufgabe:

• Astro als Framework. Es baut die Seiten vorab als fertiges, schlichtes HTML, statt jede Seite erst bei der Anfrage zusammenzusetzen, wie es ESGreadys bisheriger Aufbau tat.
• Cloudflare Workers für Hosting und Deployment. Die fertigen Seiten liegen im Edge-Netzwerk von Cloudflare, sodass Besucher in Berlin und in São Paulo die Seite jeweils aus einem Rechenzentrum in ihrer Nähe laden.
• Git und GitHub als Review-Ebene, mit automatischen Deployments und Rollback per Klick, falls etwas zurückgenommen werden muss.
• Claude Code übernimmt vieles, was früher ein Page-Builder-Plugin erledigt hat: Es hat aus dem einseitigen Entwurf mehr als zwanzig eigenständige, crawlbare Seiten gemacht und dabei Kostenrechner, Paket-Selbsttest und Pflichten-Radar als funktionierende interaktive Features erhalten.
• Keystatic, ein Git-basiertes CMS, eingebunden in die Inhalte der Seite, damit Frank FAQ-Einträge, Kundenstimmen und Seitentexte nach dem Launch selbst bearbeiten kann, ohne Entwickler.

Die Seite ging innerhalb der neun Tage live, noch vor dem Webinar. (Komplette Build-Timeline, Screenshots und alle Zahlen: siehe Fallstudie.)

3. Wo der neue Aufbau klar besser ist

Nicht "schneller" oder "sicherer" als vage Adjektive. Hier ist der konkrete Mechanismus hinter jeder Aussage.

Geschwindigkeit. ESGreadys bisheriger Aufbau hat jede Seite erst bei der Anfrage gerendert. Die öffentlichen Seiten der neuen Website werden einmal vorab gerendert und als fertiges HTML aus dem Cloudflare-Rechenzentrum ausgeliefert, das dem Besucher am nächsten liegt. Gemessen mit Lighthouse: Genau diese Seite ging von einem Performance-Wert von 19 von 100 auf 100. Das ist das gemessene Ergebnis dieses Umzugs, keine Garantie, dass jede WordPress-Seite langsam ist oder jede Astro-Seite 100 erreicht (ein gut gecachtes WordPress kann auch schnell sein).

Auffindbarkeit. Aus einer Seite wurden mehr als zwanzig eigenständig adressierbare Seiten, jede mit strukturierten Daten, die ihren Inhalt beschreiben. Das macht es Suchmaschinen und KI-Systemen leichter, die Inhalte zu finden und einzuordnen. Eine Indexierung, bestimmte Rankings oder die Nennung in einer KI-Antwort garantiert das allein nicht.

Sicherheit. Die öffentlichen Seiten sind schreibgeschützt, ohne Datenbank und ohne Plugins dahinter. Damit fällt eine ganze Kategorie typischer WordPress-Angriffspunkte weg. Die CMS-Login-Seite ist trotzdem eine öffentliche Adresse, die jeder finden kann. Sie hat allerdings kein eigenes Passwort, sondern leitet an einen GitHub-Login weiter. Was Fremde vom Bearbeiten der Seite abhält, sind also die GitHub-Konten mit Projektzugriff (mit aktiver 2-Faktor-Anmeldung und so wenigen Personen wie möglich) sowie private Deploy-Keys. Der Gewinn: weniger öffentlich erreichbare Teile, die gepatcht werden müssen. Sicherheitsarbeit fällt trotzdem an.

Vorschau vor dem Veröffentlichen. In diesem Projekt bekommt jede Änderung eine echte Vorschau-URL, bevor sie die Live-Version berührt, und ein Rollback per Klick ist jederzeit möglich. So arbeitet dieses Team; das ist keine automatische Eigenschaft jeder Astro- oder Cloudflare-Seite, und auch WordPress kann mit einer Staging-Umgebung ähnlich arbeiten, nur ist das dort nicht der Standard.

Hostingkosten. Bei ESGreadys Besucherzahlen kostet das Cloudflare-Hosting fast nichts, verglichen mit dem WordPress-Tarif für rund 10 Euro im Monat, den es ersetzt hat. Das ist der konkrete Vergleich für diese Seite, keine allgemeine Regel: Cloudflare rechnet statische Dateien und Worker-Anfragen getrennt ab, und Hosting ist nur ein Teil der Gesamtkosten einer Website.

4. Ein echter Stolperstein, und was wir daraus gelernt haben

Diesen Teil lassen die meisten Vergleichsartikel weg: Dieser Stack geht nicht so kaputt wie WordPress. Er geht auf seine eigene, andere Art kaputt, und einen dieser Fehler zu finden, war ein paar Stunden richtig spannende Detektivarbeit.

Kurz nachdem das CMS live war, zeigte seine Login-Seite in jedem echten Browser "Seite nicht gefunden", während Kommandozeilen-Tools unter derselben Adresse jedes Mal die richtige Seite bekamen. Dieser Widerspruch sah zuerst nach einem Caching-Problem aus. Die eigentliche Ursache war eine Routing-Einstellung: Der statische Dateiserver von Cloudflare beantwortete Seitenanfragen von Browsern direkt mit der Nicht-gefunden-Seite, ohne die Anfrage je an den Anwendungscode weiterzugeben, der das CMS korrekt ausgeliefert hätte. Kommandozeilen-Tools fragen Seiten anders an als Browser, deshalb rutschten sie genau an der Stelle vorbei, die kaputt war.

Die Lösung war eine einzeilige Konfigurationsänderung. Ehrlich gesagt: Dieses Projekt hat keine automatisierte Testsuite, also hing das Entdecken davon ab, dass jemand es bemerkt und genau hinschaut, nicht davon, dass eine automatische Prüfung anschlägt. Das ist eine nützliche Erkenntnis über diese Art zu bauen, und sie ist jetzt als Lektion für das nächste Projekt dokumentiert.

5. Wo WordPress wirklich einfacher war

• Der visuelle Editor. Mit dem Gutenberg-Editor von WordPress kann sich jeder einloggen und jede Seite jederzeit ändern, ohne Entwickler. Und zwar nicht nur bestehende Inhalte bearbeiten, sondern auch neue Seiten bauen oder ganze Abschnitte von Grund auf umstellen. Keystatic, das CMS in diesem Projekt, bearbeitet vordefinierte Felder (eine FAQ-Antwort, eine Kundenstimme, einen Textabsatz), nicht das Layout selbst.
• Seiten selbst bauen. Mit WordPress kann ein Gründer selbst eine Seite hinzufügen oder Abschnitte umstellen, wann immer er will, ohne auf jemanden zu warten.
• Ein ganzes Plugin-Ökosystem. Formulare, SEO-Tools, Bildergalerien, Buchungskalender: Für fast alles gibt es ein installationsfertiges WordPress-Plugin. Im neuen Stack wird jedes davon entweder selbst gebaut oder fällt weg.
• Bekanntheit. WordPress betreibt einen großen Teil des Webs. Weit mehr Menschen, Freelancer, Agenturen, interne Mitarbeitende, können damit arbeiten als mit Astro und Cloudflare Workers.

Nichts davon verschwindet, nur weil dieser Umzug die Seite schneller, öffentlich weniger angreifbar und besser auffindbar gemacht hat. Es ist ein echter Kompromiss, kein einseitiger Sieg, und nicht jede WordPress-Seite ist langsam, unsicher oder teuer; eine gut konfigurierte vermeidet mehrere dieser Nachteile. Ebenso gilt: Die hier beschriebenen Grenzen von Keystatic spiegeln wider, wie es für dieses Projekt eingerichtet wurde, keine feste Obergrenze dessen, was eine Astro-Seite mit mehr CMS-Konfiguration leisten kann.

6. Der eigentliche Kompromiss, in einem Satz

WordPress optimiert darauf, dass "jeder ohne Technikkenntnisse über einen Login alles ändern kann", und bezahlt diese Flexibilität je nach Aufbau mit Geschwindigkeit, Sicherheit und laufender Wartung.

Dieser Stack, so wie er für ESGready gebaut wurde, optimiert auf schnell ausgelieferte Seiten, eine kleinere öffentliche Angriffsfläche, niedrige Hostingkosten bei diesen Besucherzahlen und Inhalte, die Suche und KI-Systeme leichter finden und einordnen können. Dafür braucht er für alles jenseits routinemäßiger Inhaltspflege einen Entwickler oder ein KI-Coding-Tool, und er bringt eigene, ungewohnte Fehlerbilder mit, die man erst kennenlernen muss.

Keins von beiden ist abstrakt die "bessere" Wahl. Sie sind für unterschiedliche Prioritäten gebaut, und dieser Stack würde nicht zu einem Unternehmen passen, das volle visuelle Kontrolle über Layout und neue Seitentypen ohne jede Entwicklerbeteiligung will. Das ist ein berechtigter Wunsch.

7. So wägst du das für deine eigene Website ab

Wenn dir dieser Kompromiss bekannt vorkommt, hier ist, wie du ihn anwendest, statt nur zu nicken.

Frag dich, was "die Website bearbeiten" für dich im Alltag heißt. Eine Überschrift oder eine FAQ-Antwort austauschen ist das eine. Eine neue Landingpage von Grund auf bauen oder einen ganzen Abschnitt umstellen ist etwas völlig anderes. Sei konkret, welches von beiden du tatsächlich machst.

Wenn die Antwort lautet "Ich will alles selbst ändern können, ohne Hilfe, wann ich will", ist das ein berechtigter Wunsch, und genau dafür ist WordPress (oder ein ähnliches CMS mit visuellem Editor) gebaut. Der Preis ist meist eine größere Angriffsfläche, die gepflegt werden muss, und Hostingkosten, die mit dem Traffic wachsen. Wie stark, hängt davon ab, wie die Seite aufgesetzt ist und aktuell gehalten wird.

Wenn die Antwort lautet "Mir ist vor allem wichtig, dass die Seite schnell ist, günstig zu hosten, öffentlich schwer kaputtzumachen und für Suche und KI-Systeme leicht zu finden, und für alles, was über eine Textänderung hinausgeht, hole ich gern einen Entwickler oder ein KI-Tool dazu", dann passt ein Stack wie Astro auf Cloudflare besser. Der Preis ist Unabhängigkeit, und eine andere Art von Fehlern, für deren Diagnose du jemanden mit Technikverständnis brauchst.

So oder so: Stell dir vor der Entscheidung noch eine Frage. Wer wird diese Website nach dem Launch tatsächlich anfassen, und wie oft? Wer allein gelegentlich etwas anpasst, hat andere Anforderungen als ein fünfköpfiges Marketingteam, das täglich veröffentlicht. Der richtige Stack ergibt sich aus dieser Antwort, nicht daraus, welcher beeindruckender klingt.

8. Was für ESGready galt

Für ESGready hat sich der Kompromiss zu diesem Zeitpunkt gelohnt. Geschwindigkeit, eine kleinere öffentliche Angriffsfläche, Inhalte, die Suche und KI-Systeme leichter finden und einordnen, und niedrigere laufende Hostingkosten waren wichtiger als volle visuelle Kontrolle über das Layout. Frank wusste von Anfang an, dass das CMS die routinemäßige Pflege abdeckt, nicht den Bau ganzer Seiten.

Zum Geschwindigkeitsunterschied sagte Frank selbst: "Das erreichst du mit WordPress nie." Das ist Franks eigene Erfahrung und Reaktion, die wir genau so wiedergeben, wie er sie gesagt hat, keine technische Regel, die dieser Beitrag als Fazit übernimmt; eine gut optimierte WordPress-Seite mit ordentlichem Caching kann ebenfalls schnell sein. Konkret und überprüft sind hier das gemessene Lighthouse-Ergebnis dieses Umzugs und Franks eigene Worte dazu.

Das gilt nicht für jedes Unternehmen, und das muss es auch nicht. Die Aussage dieses Beitrags ist nicht "ein Stack-Wechsel garantiert diese Ergebnisse". Sie lautet: "Das hat dieser Stack für ESGreadys Prioritäten geleistet, das haben wir dafür tatsächlich eingetauscht, und das war ein ehrlicher Stolperstein unterwegs, damit du denselben Kompromiss für deine eigene Situation abwägen kannst." (Die ganze Geschichte, alle Zahlen und Vorher-nachher-Screenshots: die Fallstudie.)

Häufige Fragen

Ist eine statische Seite auf Cloudflare günstiger als WordPress-Hosting?

Oft, aber nicht automatisch. Cloudflare rechnet statische Dateien und Worker-Anfragen getrennt ab, die genauen Kosten hängen also von der Seite ab. In diesem Fall sanken die Hostingkosten von einem WordPress-Tarif für rund 10 Euro im Monat auf fast null, bei ESGreadys Besucherzahlen. Hosting ist außerdem nur ein Teil der Gesamtkosten einer Website.

Kann jemand ohne Entwicklerkenntnisse eine Astro-Seite so bearbeiten wie WordPress?

Teilweise. Ein Git-basiertes CMS (hier Keystatic) lässt Nicht-Entwickler vordefinierte Inhalte wie FAQ-Einträge, Kundenstimmen und Seitentexte über eine formularartige Oberfläche bearbeiten, und der Gründer wurde darin geschult. Was fehlt, ist der Gutenberg-Editor von WordPress: neue Seiten bauen oder ein Layout frei umstellen. Dafür braucht es weiterhin einen Entwickler oder ein KI-Coding-Tool.

Schadet ein Umzug von WordPress zu Astro dem SEO-Ranking?

Nicht zwangsläufig, auch wenn keine Migration unveränderte Rankings garantiert. Permanente Weiterleitungen für jede alte URL helfen, Erreichbarkeit und Ranking-Signale zu erhalten, damit Besucher und Suchmaschinen auf der neuen Seite landen statt auf einem toten Link. Bei diesem Umzug wurden 21 alte URLs mit jeweils einer einzigen Weiterleitung umgeleitet.

Ersetzt Claude Code ein WordPress-Page-Builder-Plugin?

Funktional erfüllt es eine ähnliche Rolle: Es schreibt und ändert Seitenlayouts auf Anfrage. Der Unterschied liegt darin, was dahinter passiert. Ein Page-Builder-Plugin ändert eine Datenbankzeile auf der Live-Seite. Claude Code ändert Quelldateien, die dann über eine Vorschau-URL und einen Review-Schritt laufen, bevor etwas live geht.

Ist eine statische Seite sicherer als WordPress?

Die öffentlichen Seiten bieten in der Regel weniger Angriffsfläche: Sie sind schreibgeschützt, ohne Datenbank und ohne Plugins dahinter, und damit fällt eine ganze Kategorie typischer WordPress-Angriffspunkte weg. Das ist aber nicht das ganze Bild. Die CMS-Login-Seite ist weiterhin öffentlich erreichbar; in diesem Aufbau leitet sie an einen GitHub-Login weiter, also sind die GitHub-Konten mit Projektzugriff (2-Faktor aktiv, wenige Personen) und private Deploy-Keys das, was geschützt werden muss. Eine gut gepflegte WordPress-Seite kann ebenfalls ordentlich sicher sein.

Geht eine statische Seite auf Cloudflare im Betrieb auch mal kaputt?

Ja, nur auf andere Weise als WordPress. Bei einem Umzug lieferte eine serverseitig gerenderte Admin-Seite jedem echten Browser eine "Nicht gefunden"-Meldung, während Kommandozeilen-Tools die richtige Antwort bekamen. Eine einzeilige Konfigurationsänderung hat das behoben. Gut zu wissen: Ohne automatisierte Tests hängt das Entdecken solcher Fehler davon ab, dass jemand genau hinschaut, und genau so war es hier.

Was ist der größte Nachteil, wenn man WordPress verlässt?

Unabhängigkeit. Mit WordPress kann eine nicht-technische Inhaberin oder ein Inhaber eine ganze Seite selbst umbauen. Bei einem Stack wie Astro und Cloudflare braucht fast jede Änderung jenseits routinemäßiger Inhaltspflege im CMS einen Entwickler oder ein KI-Coding-Tool.

Quellen und weiterführende Links

Alles, was dieser Beitrag behauptet, kannst du selbst nachprüfen. Der erste Link enthält alle ESGready-Zahlen; die übrigen sind die offiziellen Dokumentationen (auf Englisch) hinter jedem technischen Punkt, ein guter Einstieg, wenn du ein Thema vertiefen willst. Alle Links geprüft am 30. September 2026.