WordPress zu Cloudflare Pages & Astro migrieren: Der Praxis-Guide für 100/100 Core Web Vitals

Diese Website lief neun Jahre auf WordPress. Seit dem 20. September 2026 läuft sie als statische Astro-Seite auf Cloudflare Workers – ohne Datenbank, ohne PHP, ohne Plugins, ohne Hosting-Rechnung. Der Weg dahin war lehrreicher als geplant, und genau deshalb ist dieser Artikel kein Verkaufsprospekt für Static Site Generators, sondern ein Protokoll: was funktioniert hat, was schiefging und was ich beim nächsten Mal anders machen würde.

Aktualisiert am 20. September 2026, nach dem Go-Live. Die Vorfassung entstand vor der Umstellung und versprach «100/100 Core Web Vitals», «unknackbare Sicherheit» und eine «KI-Pipeline, die wöchentlich fundierte Fachartikel veröffentlicht». Der Titel bleibt aus SEO-Gründen; die Behauptungen darunter sind durch das ersetzt, was tatsächlich passiert ist. Lighthouse-Werte habe ich noch nicht systematisch gemessen – die Ladezeit-Angaben unten stammen aus dem Browser.

Warum überhaupt wechseln

WordPress betreibt über 40 Prozent aller Websites, und für viele ist es die richtige Wahl. Für einen Fachblog mit 27 Artikeln, einem Autor und ohne Kommentare, Shop oder Mitgliederbereich war es das nicht mehr:

Plugins. Page Builder, SEO-Plugin, Cookie-Plugin, Caching, Sicherheit – jedes lädt eigenes CSS und JavaScript, jedes will Updates, jedes kann brechen. Die alte Seite lud auf der Startseite ein Dutzend Skriptdateien, bevor der erste Text sichtbar war.

Angriffsfläche. Eine öffentlich erreichbare Login-Seite, eine Datenbank, PHP und Plugins von Drittanbietern sind der Normalfall erfolgreicher Angriffe auf kleine Websites. Ein statischer Build hat nichts davon.

Kosten und Wartung. Hosting, Backups, PHP-Versionen, Plugin-Lizenzen – jedes für sich klein, zusammen ein laufender Posten für eine Seite, die sich zweimal im Monat ändert.

Was WordPress dagegen gut kann – im Browser schreiben und veröffentlichen –, braucht man bei 27 Artikeln nicht zwingend. Das war die Wette.

Die Zielarchitektur

Bei einem Static Site Generator wird die Website beim Veröffentlichen einmal in fertige HTML-, CSS- und Bilddateien gebaut und dann als Dateien ausgeliefert. Es gibt zur Laufzeit keinen Server, der etwas berechnet.

	WordPress (vorher)	Astro auf Cloudflare (nachher)
Inhalt	MySQL-Datenbank	Markdown-Dateien in einem Git-Repository
Auslieferung	PHP auf einem Server in einem Rechenzentrum	Statische Dateien auf Cloudflares Netzwerk, weltweit
Angriffsfläche	Login, Datenbank, Plugins	Keine serverseitige Logik
Kosten	Hosting-Paket	Cloudflare Free Plan
Veröffentlichen	Browser-Editor	Git Push, danach automatischer Build
Ladezeit Startseite	Mehrere Sekunden, ein Dutzend Skripte	Rund 0,7 Sekunden bis Load, 284 KB, 40 Requests (im Browser gemessen)

Astro ist der Generator, Cloudflare Workers mit statischen Assets die Ausspielung, GitHub das Repository, das Cloudflare bei jedem Push neu baut.

Der Migrationsprozess – und wo er brach

Schritt 1: Inhalte extrahieren

Statt den WordPress-XML-Export zu parsen, habe ich die REST-API genutzt (/wp-json/wp/v2/posts). Sie liefert Beiträge, Seiten, Kategorien und die Yoast-Metadaten als JSON. Das funktionierte fehlerfrei: Alle 24 Artikel kamen vollständig an, 14’800 Wörter, mit Titeln, Daten und Kategorien.

Schritt 2: HTML in Markdown wandeln

Page-Builder-Shortcodes mussten raus, Überschriften, Listen und Links in Markdown. Auch das lief – mit drei Nebenwirkungen, die erst später auffielen: HTML-Entities wie „ blieben als Text stehen, mehrere Artikel hatten nur H4-Überschriften und damit später kein Inhaltsverzeichnis, und Bilder klebten im Überschriftentext.

Schritt 3: Der Fehler, der fast alles kostete

Nach der Migration kam eine «Überarbeitung aller 25 Beiträge mit aktuellen Daten» – ein einzelner Commit. Er ersetzte die vollständigen Artikel durch KI-generierte Zusammenfassungen von 50 bis 250 Wörtern, mit neuen Titeln, neuen Daten und teils gegenteiligen Aussagen. Ein Konferenzbericht von 2017 mit 1’200 Wörtern wurde zu einem 107-Wörter-Text, der das Gegenteil behauptete. Die Lesezeit stand weiterhin auf «7 Min.», weil sie im Frontmatter hart codiert war.

Gerettet hat das Git: Der Migrations-Commit lag noch im Verlauf, und git show <commit>:pfad holt jede Datei in ihrer alten Fassung zurück. Lehre: Inhalte erst nach dem Go-Live überarbeiten, artikelweise, mit Diff-Kontrolle – nie alle auf einmal, und nie ohne den Vergleich alt gegen neu zu lesen.

Schritt 4: Die Pipeline, die Platzhalter veröffentlichte

Zur Migration gehörte eine GitHub Action, die jeden Dienstag einen neuen Artikel per Gemini-API generieren und veröffentlichen sollte. Zwischen dem 25. August und dem 15. September veröffentlichte sie vier Artikel – alle identisch, 250 Wörter, nur der Titel ausgetauscht. Der API-Aufruf war fehlgeschlagen, und das Skript fiel still auf eine eingebaute Vorlage zurück.

Lehre: Automatisierung, die Inhalte unter deinem Namen veröffentlicht, braucht harte Abbruchbedingungen statt Fallbacks. Das Skript bricht jetzt ab, wenn der API-Key fehlt, die Antwort unter 900 Wörtern liegt oder keine Struktur hat. Und der Wochenlauf ist aus – Artikel gehen nur noch manuell und nach Review raus.

Schritt 5: URLs erhalten

Die Astro-Routen entsprechen exakt den alten Permalinks (/[kategorie]/[slug]/). Alles andere – Kategorie-Archive unter /category/, Paginierung, Tag-Seiten, Autorenseite, Feeds, Yoast-Sitemaps, drei Lexikon-Einzelseiten – leitet per 301 in einer _redirects-Datei weiter.

Zwei Dinge, die ich erst beim Testen lernte: Ein Meta-Refresh ist kein Redirect – die erste Fassung der Kategorie-Weiterleitungen lieferte HTTP 200 mit http-equiv="refresh" und stand zusätzlich in der Sitemap. Und Cloudflare Workers unterstützen in _redirects keine Domain-Level-Regeln; eine Zeile für www → Hauptdomain liess den Build scheitern. Die www-Weiterleitung läuft jetzt als Redirect Rule in der Cloudflare-Zone.

Schritt 6: Bilder

23 Artikelbilder verwiesen noch auf wp-content/uploads/ des alten Servers, kaschiert durch eine Proxy-Weiterleitung. Nach dem Abschalten von WordPress wären sie weg gewesen. Ein Skript hat sie vor dem Umzug heruntergeladen, ins Repository gelegt und die Pfade umgeschrieben. Lehre: Vor dem Go-Live einmal im Build nach der alten Domain suchen – jede Fundstelle ist ein Bild, das bald fehlt.

Schritt 7: Tracking und Consent

Die alte Seite hatte einen Cookie-Banner, aber Google Tag Manager und Analytics feuerten vor jeder Zustimmung. Die neue lädt den Tag Manager erst nach dem Klick auf «Zustimmen» – Basic Consent Mode. Ohne Zustimmung geht keine Anfrage an Google. Die Datenschutzerklärung beschreibt genau das. Warum ein Blog den Basic Mode wählt und ein Kampagnenkonto eher den Advanced Mode, steht im Leitfaden zu Consent Mode v2.

Schritt 8: DNS und Mail

Ein Worker mit eigener Domain setzt voraus, dass die Domain als Zone bei Cloudflare liegt – ein CNAME beim alten Hoster reicht nicht. Der Nameserver-Wechsel dauerte unter einer Stunde. Die Falle lag bei der Mail: Der MX-Eintrag zeigte auf die Hauptdomain, und die gehört nach dem Umzug Cloudflare. Ohne einen eigenen mail-Eintrag mit «DNS only» und einen MX darauf wäre die Weiterleitung von info@ mit dem Go-Live gestorben. Lehre: Vor dem Nameserver-Wechsel jeden MX-, SPF- und DKIM-Eintrag einzeln prüfen.

Was nach dem Go-Live blieb

Die Umstellung selbst war unspektakulär: DNS-Eintrag löschen, Custom Domain am Worker hinzufügen, zwei Minuten warten, Zertifikat da. Danach: Sitemap in der Search Console neu einreichen (der erste Abruf kam während der DNS-Umstellung und scheiterte), alten Universal-Analytics-Tag aus dem GTM-Container löschen, Google-Signale in GA4 abschalten, damit die Datenschutzerklärung stimmt.

Offen bleibt die Frage, wie sich die Rankings entwickeln. Die URLs sind identisch, die Inhalte sind länger und aktueller als vorher – aber Google muss 27 überarbeitete Seiten neu bewerten, und das dauert Wochen.

Checkliste für die eigene Migration

• Inhalte per REST-API exportieren und wortgenau gegen die alte Seite prüfen
• Markdown auf Entities, Überschriften-Hierarchie und Bilder in Überschriften kontrollieren
• Jede URL der alten Sitemap gegen die neue testen: 200 oder 301, nichts anderes
• Im Build nach der alten Domain suchen – jede Fundstelle ist ein Bild oder Link, der bricht
• Consent so umsetzen, wie die Datenschutzerklärung es beschreibt, und beides gegeneinander prüfen
• MX, SPF, DKIM vor dem Nameserver-Wechsel einzeln kontrollieren; mail als eigenen A-Record mit «DNS only»
• Keine Automatisierung, die ohne Review veröffentlicht
• Inhalte erst nach dem Go-Live überarbeiten, artikelweise, mit Diff

Fazit

Astro auf Cloudflare ist für einen Fachblog die bessere Architektur: schneller, sicherer, wartungsärmer, kostenlos. Die Technik war nicht das Problem. Das Problem waren die Abkürzungen – eine Massenüberarbeitung ohne Kontrolle, eine Pipeline ohne Abbruchbedingung, Bilder, die noch am alten Ort lagen. Alles davon liess sich beheben, weil Git jede Fassung aufbewahrt und weil die alte Seite bis zum letzten Tag online blieb. Wer beides einplant, kann den Umzug an einem Wochenende machen. Wer es nicht tut, macht ihn zweimal.