Ich habe 3 Kundenseiten von WordPress zu Astro migriert. Mit Claude ging nichts kaputt.

Ich baue seit über sechs Jahren WordPress-Seiten für Kunden. Hunderte davon. Und die meiste Zeit war WordPress okay. Gut genug. Das, womit die Rechnungen bezahlt werden.

Aber irgendwann, so um Projekt Nummer 150, fing ich an, die Updates zu fürchten. Die Plugin-Konflikte. Die "dieser Page Builder hat gerade ein Breaking Update rausgehauen" Panik um 23 Uhr. Ich wollte WordPress nicht mehr reparieren. Ich wollte Websites bauen, die keine Reparatur brauchen.

Also habe ich drei Kundenseiten in einem Monat von WordPress zu Astro migriert. Und weil Claude den Großteil der UI-Konvertierung übernommen hat, ging so gut wie nichts kaputt.

Warum ich einfach nur einen Dist-Ordner mit sauberem HTML wollte

Was ich wollte: Ein Build-Befehl, der einen dist-Ordner mit sauberen, statischen HTML-Dateien ausspuckt. Keine JavaScript-Runtime. Keine Hydration. Keine Islands. Keine dynamischen Routen. Nur Markup, CSS, fertig.

Ich habe schon mal geschrieben, warum ich WordPress verlassen habe. Die Kurzversion: 20+ Plugins pro Seite, Sicherheitsupdates jede Woche, Hosting-Kosten, die ständig gestiegen sind. Aber der eigentliche Auslöser war simpler. Ich schaute mir die Marketing-Seite eines Kunden an, eine Seite mit im Grunde fünf statischen Seiten und einem Blog, und stellte fest, dass sie 23 Plugins, eine MySQL-Datenbank, PHP 8.2 und einen Caching-Layer brauchte, nur um das auszuliefern, was auch einfache HTML-Dateien sein könnten.

Das fühlte sich absurd an.

Genau das ist Astros Versprechen. Null JavaScript wird standardmäßig ausgeliefert. Du schreibst Komponenten, Astro kompiliert sie zur Build-Zeit in statisches HTML. Das Ergebnis ist ein Ordner, den du überall hosten kannst. Cloudflare Pages, Netlify, ein 5-Euro-VPS, buchstäblich überall. Keine Server-Runtime nötig.

Mich interessierte Astros Island-Architektur nicht, und auch nicht die Möglichkeit, React- und Vue-Komponenten auf derselben Seite zu mischen. Coole Features, klar. Aber für meinen Anwendungsfall wollte ich das Gegenteil von Komplexität. Ich wollte den einfachstmöglichen Output.

ACF, Bricks, Elementor: Die Migration klang unmöglich

Jetzt wird es interessant. Das waren keine simplen WordPress-Seiten mit einem einfachen Theme. Eine war mit Elementor gebaut, eine mit Bricks Builder, und eine hatte Advanced Custom Fields mit eigenen PHP-Templates.

Wenn du jemals den Quellcode einer Elementor-Seite gesehen hast, weißt du, wovon ich rede. Div in Div in Div in Div. Automatisch generierte Klassennamen wie elementor-element-a8b2f3c. Inline-Styles überall. Das ist kein HTML, das man lesen kann. Das ist HTML, das eine Maschine generiert hat, damit eine andere Maschine es interpretiert.

Bricks ist besser, ehrlich gesagt. Saubererer Output. Aber immer noch tief verschachtelt, immer noch Builder-spezifische Klassen, immer noch nichts, was du von Hand warten möchtest.

Und ACF-Seiten? Die Inhalte stecken in Custom Fields, verteilt über die Datenbank. Die Templates sind PHP-Dateien, die get_field('hero_title') an zwanzig verschiedenen Stellen aufrufen. Es gibt keinen sauberen "Exportieren"-Button.

Das alles manuell in Astro-Komponenten zu konvertieren, hätte Wochen pro Seite gedauert. Ich rechnete mit einem zwei- bis dreimonatigen Projekt.

Dachte ich zumindest.

Ich ließ Claude die UI bauen und es war im Nu erledigt

Das ist der Teil, der mich überrascht hat.

Ich nahm das gerenderte HTML jeder Seite (einfach "Quellcode anzeigen" im Browser, nichts Ausgefallenes), gab es Claude und bat darum, das Markup in saubere Astro-Komponenten umzuwandeln. Builder-Klassen rauswerfen. Visuelle Struktur beibehalten. Tailwind fürs Styling.

Mit etwas Feintuning und Hin und Her hat Claude das hinbekommen. Die tief verschachtelten Elementor-Divs? Zu semantischem HTML vereinfacht. Die Bricks-Klassen? Durch Tailwind-Utilities ersetzt. Die ACF-Template-Logik? In Astros Frontmatter-Datenabruf konvertiert.

Ich sage nicht, dass es null Aufwand war. Es gab Feintuning. Manche Komponenten brauchten ein paar Runden "nein, der Abstand stimmt nicht" oder "das mobile Layout ist kaputt." Aber vergleich das mal mit dem manuellen Neuschreiben jeder Seite von Grund auf? Das war nicht mal im Ansatz vergleichbar.

Die drei Seiten, für die ich zwei bis drei Monate geschätzt hatte? In etwa drei Wochen erledigt. Und die meiste Zeit habe ich gereviewed und getestet, nicht Code geschrieben.

Berechtigte Frage: Musste der Output aufgeräumt werden? Ja. Claude überengineert manchmal Komponentenstrukturen oder fügt Klassen hinzu, die du nicht brauchst. Aber das Aufräumen ging schnell. Viel schneller, als von einer leeren Datei anzufangen und zu versuchen, zurückzuentwickeln, wie ein Elementor-Abschnitt eigentlich aussehen sollte.

Die Performance-Zahlen sprechen für sich

Ich lass die Zahlen reden.

Vor der Migration (WordPress + Elementor, typisches Mittelklasse-Hosting):

• LCP: 0,81s
• Erster Seitenaufruf: 1,2-2,1s
• Lighthouse Performance: 72-85
• Gesamte Seitengröße: durchschnittlich 1,8MB

Nach der Migration (Astro SSG, Cloudflare Pages):

• LCP: 0,44s (46% schneller)
• Erster Seitenaufruf: 200-400ms
• Lighthouse Performance: 98-100
• Gesamte Seitengröße: unter 500KB

Das sind 72% weniger HTML, 60% weniger JavaScript (naja, null JavaScript in den meisten Fällen) und 90% weniger CSS als die WordPress-Versionen. Und das sind keine synthetischen Benchmarks. Das sind echte Zahlen von echten Kundenseiten mit echtem Traffic.

Die Hosting-Kosten gingen von ungefähr 25-40 Euro pro Monat pro Seite auf Managed WordPress Hosting auf buchstäblich 0 Euro auf Cloudflare Pages' kostenlosem Tier. Für statische Seiten musst du ehrlich gesagt nicht mehr für Hosting bezahlen. Wenn du tiefer eintauchen willst, habe ich einen umfassenden Guide zur Website-Optimierung geschrieben, der die Grundlagen abdeckt.

Wo dieser Ansatz scheitert

Lass mich ehrlich sein über die Grenzen. Denn die sind klar.

Wenn eine Seite Blog-Kommentare, ein Kontaktformular mit serverseitiger Verarbeitung, Benutzer-Authentifizierung, eine Suchfunktion oder irgendetwas braucht, das zur Laufzeit eine Datenbank erfordert, ist reines SSG Astro nicht das richtige Werkzeug.

Du kannst diese Dinge dranbasteln. Astro unterstützt API-Routen, serverseitiges Rendering und Drittanbieter-Services für Formulare und Kommentare. Aber an dem Punkt kämpfst du gegen das Framework. Du fügst Komplexität zu einem Tool hinzu, dessen ganzer Wert darin besteht, Komplexität zu entfernen.

Ich habe Cloudflares EmDash CMS ausprobiert als Alternative für Seiten, die etwas mehr brauchen. Aber ehrlich gesagt greife ich für alles mit echten dynamischen Anforderungen zu einem ganz anderen Tool.

Meine Regel: Wenn die Kundenseite theoretisch auf Papier gedruckt werden könnte und trotzdem Sinn ergeben würde, ist es eine Astro-Seite. Wenn sie Dinge tun muss, auf Benutzer reagieren, Daten verarbeiten, Zustand verwalten, dann nicht.

Astro für Statisches, Next.js für Dynamisches. Das war's.

Ich sehe endlose "Astro vs Next.js" Vergleichsposts. Die meisten verfehlen den Punkt komplett. Diese Frameworks konkurrieren nicht miteinander. Sie lösen völlig verschiedene Probleme.

Astro ist für Content-Seiten, Marketing-Pages, Blogs, Portfolios, Dokumentation. Seiten, deren Inhalt sich nicht ändert, je nachdem wer draufschaut. Du baust es einmal, deployest statische Dateien, und es ist für immer schnell.

Next.js ist für Anwendungen. Dashboards, E-Commerce, Plattformen mit Benutzerkonten, alles was ein Backend, eine Datenbank oder serverseitige Logik braucht. Ich habe davon auch einiges gebaut und hatte meine eigenen Next.js-Build-Probleme. Aber für dynamische Projekte greife ich immer noch dazu, weil ich damit einfach vertrauter bin.

Der Entscheidungsbaum ist simpel: Braucht die Seite ein Backend? Next.js (oder welches Full-Stack-Framework du bevorzugst). Muss sie schnell, günstig und statisch sein? Astro.

Keine Framework-Kriege. Einfach das richtige Tool für den Job.

Was ich dir raten würde, bevor du es versuchst

Wenn du darüber nachdenkst, WordPress-Seiten zu Astro zu migrieren, hier ist, was ich mir gewünscht hätte, dass mir jemand gesagt hätte.

Prüfe deine Seiten zuerst. Schau dir jede Seite an und frag: Muss die wirklich dynamisch sein? Die meisten Marketing-Seiten müssen das nicht. Aber die eine Seite mit dem Buchungsformular oder dem Kundenportal? Das ändert die Rechnung.

Kläre deine CMS-Situation, bevor du anfängst. Wenn dein Kunde Inhalte selbst bearbeiten muss (und das wird er), brauchst du ein Headless CMS. Directus, Storyblok, was auch immer. Rechne die Setup-Zeit in deine Schätzung ein. Es ist nicht schwer, aber es kostet trotzdem Zeit.

Lass die KI die Builder-zu-Komponenten-Konvertierung machen. Ernsthaft. Sitz nicht da und schreib Elementor-Output manuell um. Gib das gerenderte HTML in Claude, sag was du willst und iteriere. Du sparst Wochen.

Erfasse jede URL vor der Migration. Ich hätte das fast auf die harte Tour gelernt. Deine WordPress-Seite hat URLs. Deine Astro-Seite muss exakt dieselben URLs haben, oder 301-Redirects für jede einzelne. Vergiss diesen Schritt und dein SEO geht den Bach runter. Wenn du eine Migration planst, deckt die Website-Relaunch-Checkliste die SEO-Erhaltungsschritte im Detail ab.

Plane weniger Zeit ein als du denkst. Das klingt kontraintuitiv für eine Migration. Aber mit KI für die UI-Konvertierung ist die eigentliche Entwicklungszeit überraschend kurz. Das Testen und Reviewen dauert länger als das Bauen.

Drei Seiten. Drei Wochen. Sauberes HTML in einem Dist-Ordner. Null JavaScript-Overhead. Und Hosting, das nichts kostet.

Ich sage nicht, dass Astro die Antwort auf alles ist. Ist es nicht. Aber für statische Seiten, die nichts Ausgefallenes können müssen? Es ist genau das, was ich mir von WordPress immer gewünscht habe.

Du überlegst, deine Seiten auf etwas Schnelleres und Einfacheres zu migrieren? Lass uns reden darüber, ob Astro für deine Situation Sinn ergibt.