Zehn Monate Migration von WordPress zu Astro auf Cloudflare Pages

Der Plattformwechsel von WordPress zu Astro sollte das gesamte Projekt darstellen. Er erwies sich jedoch als reiner Prolog. Inhalte exportieren, Templates in Astro neu bauen, eine statische Website zum Kompilieren und Ausliefern auf Cloudflare Pages bringen, das dauerte nur wenige Wochen. Dann begannen die eigentlichen Monate: Redirects, hreflang-Graphen, die strikte Parität von sechs Sprachen und ein Build, der der Plattform entwuchs, auf der er ausgeliefert wurde. Dies ist ein technischer Bericht darüber, wohin die Zeit tatsächlich ging, denn die Zeit ging nicht dorthin, wohin die ursprüngliche Planung sie geschickt hatte.

Die Polemik, falls es eine gibt, richtet sich gegen die oberflächliche Auffassung des Plattformwechsels als einmaliger Umzug. “Weg von WordPress hin zu einer statischen Website” klingt nach einer einmaligen Migration. Für eine mehrsprachige Content-Website kommt es eher dem dauerhaften Übernehmen der Verantwortung für drei fundamentale Systeme gleich, die WordPress bisher verborgen hat: die Routing-Schicht, den Build-Prozess und die sprachübergreifende Inhaltsstruktur. Keines davon ist unlösbar. Alle sind jedoch fortlaufend zu pflegen.

[!NOTE] Der Fall auf einen Blick

• Projekt: wppoland.com von WordPress zu Astro auf Cloudflare Pages umgestellt, ein hauseigener Neuaufbau meiner eigenen Website
• Umfang: sechs Sprachen, 15.718 vorgerenderte Seiten und 8180 Adressen in der Sitemap (Build vom 20.10.2026), mit vollständiger Hreflang-Verknüpfung
• Zeitrahmen: Start im Dezember 2025 (am 2. Dezember lief die Website laut Wayback Machine noch auf WordPress mit WPML und WP Rocket; das Astro-Repository entstand am 21. Dezember), Wochen bis zu einem funktionierenden Build, erste Fassung dieses Berichts nach fünf Monaten, diese Aktualisierung nach zehn
• Build: überschritt die 8-GB-Runner-Grenze von Cloudflare Pages, gelöst durch lokales Bauen mit einem 16-GB-Heap und Ausliefern des Artefakts mit Wrangler
• Redirects: 301-Regeln, die an Cloudflares 100-KB-_redirects-Grenze stießen; heute liegen 3619 davon in einer Map in Cloudflare Functions und 249 in _redirects
• Stack: Astro mit Tailwind CSS, AVIF-Bildpipeline, statisches HTML vom globalen Edge ausgeliefert
• Ergebnis: PageSpeed (Labor, mobil, 20.10.2026) 94 für die polnische Startseite und 98 für die Astro-Leistungsseite, kein PHP und keine Datenbank in der Produktion, Parität über sechs Sprachen gehalten

#Was kostet eine Migration von WordPress zu Astro

1. Der Umzug ist der billige Teil. Templates und Inhaltsexport dauerten Wochen; nach zehn Monaten braucht der lange Schwanz der Migration noch immer Korrekturen.
2. Die Redirect-Schicht ist die erste Überraschung. Tausende zuvor indexierter URLs brauchen jede einen 301-Code, und das schiere Volumen kollidierte mit einer Dateigrößenbegrenzung von Cloudflare Pages, die Regeln stillschweigend verwarf.
3. Die Parität von sechs Sprachen ist fortlaufende Arbeit, keine einmalige Aufgabe. Hreflang, kanonische URLs und Abschnittsstruktur müssen über jede Sprachversion hinweg synchron bleiben.
4. Der Build entwuchs dem hauseigenen Runner der Plattform. Eine Speichergrenze von 8 GB reicht nicht für mehr als 15.000 vorgerenderte Seiten; die Antwort war, lokal mit einem 16-GB-Heap zu kompilieren und das fertige Artefakt via CLI auszuliefern.

#Glossar: statischer Build, Prerender, hreflang, Edge

Der Bericht stützt sich auf einige Plattformbegriffe:

• Statischer Build - die gesamte Website wird im Voraus, während eines Build-Schritts, in einfache HTML-Dateien gerendert, statt pro Anfrage dynamisch erzeugt zu werden.
• Prerender - das vollständige DOM jeder Unterseite wird zur Build-Zeit in physische HTML-Dateien geschrieben. Eine Website mit sechs Sprachen multipliziert den Seitenumfang mit der Sprachanzahl.
• Cloudflare Pages - die Hosting-Plattform, die vorgebaute Dateien weltweit über das CDN-Edge-Netzwerk ausliefert und Edge-Logik über Pages Functions ausführt.
• Wrangler - das CLI-Werkzeug von Cloudflare, hier verwendet, um das lokal kompilierte dist/-Verzeichnis direkt hochzuladen und Runner-Grenzen zu umgehen.
• Hreflang - HTML-Header-Attribute, die Suchmaschinen mitteilen, welche URL das lokale Äquivalent in einer anderen Sprache darstellt.
• 301-Redirect - eine permanente HTTP-Weiterleitung, die das Ranking-Signal und die Indexhistorie einer verschobenen URL auf ihre neue Zieladresse überträgt.

#Wie lange dauert der Umzug von WordPress zu Astro

Die sichtbare Migration ist der Teil, der geschätzt wird, und die Schätzung ist anfangs meist zutreffend. Inhalte werden aus WordPress-MySQL-Tabellen in Markdown-Dateien mit YAML-Frontmatter exportiert. PHP-Templates und Child-Themes werden als Astro-Komponenten mit Tailwind CSS neu geschrieben. Der Build kompiliert sauber und das Deployment landet auf Cloudflare Pages. Eine Content-Website mittlerer Größe erreicht in wenigen Wochen einen funktionierenden statischen Build. Das ist die Phase, die sich in internen Reviews hervorragend präsentiert und das Management überzeugt, dass das Projekt fast fertig sei.

In Wahrheit steht das Projekt erst am Anfang seiner eigentlichen ingenieurtechnischen Herausforderungen. Ein lauffähiger Build beweist lediglich, dass Astro-Komponenten fehlerfreies HTML zusammensetzen können. Er beweist nichts darüber, ob Tausende historischer URLs den Suchverkehr korrekt weiterleiten, ob hreflang-Graphen im Google-Index intakt bleiben oder ob der Node.js-Buildprozess weiteres Inhaltswachstum verkraftet.

#301-Weiterleitungen nach dem Wechsel zu Astro

Nachdem der Build lief, kam die Redirect-Infrastruktur an die Reihe. Jede URL, die WordPress seit 2006 je erzeugt hatte (einschließlich Datumsarchive, Kategorien, Autoren-Taxonomien und Plugin-Pfade), benötigte eine präzise 301-Weiterleitung auf die neue Astro-Struktur. Ohne eine lückenlose Mapping-Schicht stiegen die 404-Fehler in der Google Search Console sprunghaft an und gewachsenes SEO-Kapital ging verloren.

Auf einer einsprachigen Website ist das eine überschaubare Listenaufgabe. Auf einer Website mit sechs Sprachen und lokalisierten Slugs (deutsche, polnische, norwegische, spanische und portugiesische Pfade) ging die Liste schnell in die Tausende. Im Oktober 2026 enthält die Map in Cloudflare Functions 3619 Regeln, die Datei _redirects 249.

Hier stieß ich auf ein undokumentiertes Limit von Cloudflare Pages: die Datei _redirects besitzt eine harte Grenze von 100 KB. Ab dieser Größe ignoriert der Parser der Plattform überschüssige Zeilen ohne jegliche Fehlermeldung beim Deployment. In der Folge griffen frühe Regeln fehlerfrei, während spätere Regeln in 404-Fehlern endeten. Die Lösung bestand darin, die gesamte Weiterleitungslogik in eine TypeScript-basierte Edge-Middleware (functions/redirect-map.ts) auszulagern, die Weiterleitungen im Arbeitsspeicher mit O(1)-Komplexität auf Edge-Ebene auflöst.

#Wie hält man hreflang in sechs Sprachen synchron?

In herkömmlichen WordPress-Installationen verbergen mehrsprachige Plugins wie WPML oder Polylang die relationalen Verknüpfungen hinter Datenbanktabellen. Ein statischer SSG-Build legt diese Beziehungen in Markup und Dateien vollständig offen.

Sechs Sprachversionen jedes Artikels müssen dauerhaft strukturell synchron bleiben:

• Identische H2- und H3-Gliederung in identischer logischer Reihenfolge.
• Vollständige, wechselseitige hreflang-Verweise im HTML-Head zu allen fünf Geschwister-Sprachen.
• Exakte kanonische URLs, die die regionale Routing-Struktur widerspiegeln.
• Einheitliche Kategorisierung und Taxonomie-Zuordnungen über alle Märkte.

Wenn eine Sprachversion abweicht (etwa durch eine hinzugefügte Unterüberschrift oder einen geänderten Slug), beginnen Suchmaschinen, asymmetrische hreflang-Signale zu ignorieren. Dies führt zu Keyword-Kannibalisierung zwischen Ländermärkten. Aus diesem Grund führte ich automatisierte Paritäts-Prüfskripte ein, die vor jedem Commit die Konsistenz aller Sprachversionen verifizieren.

#JavaScript heap out of memory beim Astro-Build beheben

Astro kompiliert statische Seiten in einem einzigen Hauptprozess. Als das Repository auf über 14.000 Unterseiten anwuchs (im Oktober 2026 sind es 15.718) (durch die Kombination aus technischen Leitfäden, Leistungsseiten, Portfolio-Fallstudien und Städteseiten in 6 Sprachen), war das standardmäßige 4-GB-Heap-Limit der V8-Engine rasch erschöpft.

Der Standard-Build-Runner von Cloudflare Pages stellt 8 GB RAM bereit. Während der intensiven TypeScript-Typüberprüfung, der MDX-AST-Transformation und des CSS-Tree-Shakings stürzte der Prozess regelmäßig mit JavaScript heap out of memory ab.

Ich löste diesen Engpass durch eine Umstrukturierung des Deployment-Prozesses:

1. Lokal gesteuerter Build auf Apple Silicon: Der Build läuft lokal auf M-Series-Prozessoren mit ausdrücklich festgelegtem Heap (--max-old-space-size, im Produktionsprofil 16 GB). Am 20. Oktober 2026 erzeugte der Schritt astro build 15.718 Seiten in 5 Minuten 30 Sekunden, der Upload über Wrangler dauerte weitere 338 Sekunden.
2. Prerender-Artefakt-Bereinigung: Astro erzeugt beim Kompilieren das Verzeichnis dist/.prerender für Server-Module. Einzelne Chunk-Dateien erreichten 43,9 MiB, was gegen das 25-MiB-Dateilimit von Cloudflare Pages verstieß. Ein Bereinigungsskript entfernt diese internen Prerender-Chunks vor dem Upload.
3. Direkter Upload via Wrangler: Das verifizierte dist/-Verzeichnis wird direkt ins Cloudflare-Edge-Netzwerk übertragen, wodurch Build-Limits in der Cloud vollständig umgangen werden.

#Große Sitemap in Astro auf mehrere Dateien aufteilen

Eine weitere Herausforderung lag in der Sitemap-Architektur. Die Standardintegration @astrojs/sitemap kennt die Indexierungsregeln nicht, die ich pro Collection pflege (noindex, Mindestlängen, Städteseiten).

Ich baute einen eigenen Generator. Im Oktober 2026 erzeugt er diese Struktur:

• Eine zentrale sitemap-index.xml listet 24 Sitemaps auf, vier für jede der sechs Sprachen.
• Jede Sprache hat eigene Dateien für Leistungsseiten (sitemap-pages.xml), Blog, Portfolio und Städteseiten (sitemap-locations.xml), zusammen 8180 Adressen.
• Ein strikter Filter schließt alle Seiten mit noindex-Attribut aus (überwacht durch das Skript check:noindex-sitemaps).

Dank dieser Aufteilung können Suchmaschinen und KI-Crawler die Sitemap-Struktur schrittweise ohne Timeouts abarbeiten.

#Automatische Prüfungen vor dem Deploy einer Astro-Website

Ein oft übersehener Aufwand beim Abschied von einem CMS ist der Neubau jener Qualitätssicherungen, die WordPress und sein Plugin-Ökosystem unsichtbar im Hintergrund ausführten. WordPress verhinderte doppelte Slugs, überwachte Datenbankrelationen und prüfte Links bei der Eingabe. In einem statischen System landet jeder Tippfehler im Frontmatter ungefiltert in der Produktion, sofern er nicht durch automatische Tests abgefangen wird.

Bis Mai 2026 entstanden 34 automatisierte Qualitäts-Gates (run-gates.mjs); im Oktober 2026 listet npm run gates mehr als 120 auf. Beispiele:

• Interne Link-Integrität (check:incoming-internal-links und check:service-navigation-parity): Prüft, dass jede Leistung eingehende Links hat und die Navigation in allen Sprachen übereinstimmt.
• Zeichensatz- und Diakritika-Prüfung (check:diacritic-wordlist): Erkennt Zeichensatzfehler und falsche Sonderzeichen in allen sechs Sprachen.
• Preisschutz-Wächter (check:no-own-prices): Verhindert, dass ungeprüfte Stundensätze oder Festpreise in redaktionellen Texten außerhalb freigegebener Preisseiten auftauchen.
• Content Security Policy Validierung (check:csp-inline): Berechnet SHA-256-Hashes für alle Inline-Skripte im generierten HTML und setzt strikte CSP-Header ohne unsafe-inline durch.
• KI-Rhetorik-Audit (check:slop-rhetoric): Filtert nichtssagende Marketing-Floskeln und wahrt eine nüchterne, ingenieurmäßige Tonalität.

Jedes dieser Gates entstand nach einem konkreten Fehler, der vorher schon in der Produktion gelandet war.

#Astro Content Collections mit Zod validieren

Im Unterschied zu WordPress, wo benutzerdefinierte Felder (Advanced Custom Fields / ACF) als unstrukturierte Meta-Einträge in der Tabelle wp_postmeta landen, erzwingt Astro strikte Typsicherheit über Content-Collections mit Zod-Schemata:

• Strikte Typisierung von Metadaten: Jedes Markdown-Dokument wird zur Build-Zeit gegen ein Zod-Schema validiert. Fehlende Pflichtfelder wie title, description, canonicalUrl oder fehlerhaft formatierte ISO-Datumsangaben stoppen den Build sofort mit präzisen Zeilenangaben.
• Schema.org-JSON-LD-Automatisierung: Strukturierte Daten für Suchmaschinen (darunter FAQPage, HowTo und Article) werden typsicher aus dem Frontmatter generiert, wodurch fehlerhafte strukturierte Daten im Google-Suchindex ausgeschlossen sind.
• Automatisierte Beziehungsauflösung: Querverweise zwischen Autoren, Kategorien und mehrsprachigen Äquivalenten werden direkt zur Kompilierzeit aufgelöst, ohne zur Laufzeit relationale Datenbank-Joins ausführen zu müssen.

#Bilder optimieren und Google Fonts lokal einbinden

In dynamischen WordPress-Setups erfolgt die Bildverarbeitung beim Medien-Upload über GD oder ImageMagick. In Astro wird die Bildoptimierung zu einem integralen Schritt des Build-Prozesses.

Die unbedachte Verarbeitung tausender hochauflösender Rastergrafiken führte anfangs zu Speicherüberlastungen der Sharp-Bibliothek. Ich etablierte eine klare Trennung:

1. Vorab optimierte statische Assets: Dekorative Hintergründe werden vorab in AVIF und WebP umgewandelt und im Verzeichnis public/ abgelegt, sodass sie ohne Compiler-Last direkt vom CDN ausgeliefert werden.
2. Feste Bilddimensionen: Alle Inhaltsbilder erhalten explizite width- und height-Attribute, was Layout-Verschiebungen verhindert (Cumulative Layout Shift).
3. Selbst gehostete Schriftarten: Ich entfernte sämtliche Aufrufe zu Google Fonts. Die Schrift Geist wird von meiner eigenen Domain als WOFF2-Datei mit lateinischer Teilmenge ausgeliefert (Paket @fontsource/geist), was Render-Blockaden verhindert und die Anforderungen der DSGVO erfüllt.

#Content Security Policy ohne unsafe-inline einrichten

Ein wesentlicher Schwachpunkt gewachsener WordPress-Installationen ist das Risiko von Cross-Site-Scripting (XSS) durch Drittanbieter-Plugins, die unkontrolliert Skripte in den Dokumentenkörper injizieren. In einer statischen Astro-Architektur wird die Sicherheit bereits auf Build-Ebene deterministisch verankert:

1. Vollständige Eliminierung von unsafe-inline: Statt permissive Sicherheitsrichtlinien zuzulassen, analysiert ein automatisierter Build-Schritt (check:csp-inline) jedes generierte HTML-Dokument und berechnet kryptografische SHA-256-Hashes für alle erforderlichen Inline-Skripte.
2. Strikte Header-Verteilung am CDN-Edge: Die resultierende CSP-Richtlinie wird direkt in den HTTP-Headern von Cloudflare Pages forciert, inklusive Strict-Transport-Security: max-age=31536000; includeSubDomains; preload, X-Content-Type-Options: nosniff und Referrer-Policy: strict-origin-when-cross-origin.
3. Isolierte Third-Party-Integrationen: Analyse- und Nachverfolgungsdienste werden streng über definierte Berechtigungsrichtlinien (Permissions-Policy) isoliert, ohne Zugriff auf sensible Browser-APIs wie Geolocation, Mikrofon oder Kamera.

#Wie kommt JavaScript in Formulare einer statischen Astro-Website?

Der größte architektonische Vorteil von Astro liegt im Prinzip “Zero-JS by default”. Leser redaktioneller Inhalte laden reines HTML und CSS ohne jeglichen JavaScript-Overhead herunter.

Wo Interaktivität technisch zwingend erforderlich ist (Kontaktformular, Suche, Kalkulatoren), ergänze ich ein kleines Skript nur auf dieser Seite:

• Das Kontaktformular ist einfaches HTML mit einem kurzen Skript in der Komponente, ohne Framework im Browser.
• Spamschutz erfolgt über Cloudflare Turnstile, ohne Bilderrätsel.
• Die Daten gehen an einen Endpunkt in Cloudflare Pages Functions (functions/api/enquiry.ts), der die Nachricht über Resend versendet und, falls Resend ausfällt, über Web3Forms. Einen Anwendungsserver gibt es nicht zu warten.

#Suche auf einer statischen Astro-Website einbauen

Klassisches WordPress stützt sich bei Suchanfragen auf relationale SQL-Abfragen der Tabelle wp_posts. In einer rein statischen Architektur muss die Volltextsuche ohne Datenbankserver auskommen.

Statt Datenbankabfragen nutzt die Suche einen Index, der beim Build entsteht:

• Für jede Sprache entsteht eine eigene JSON-Datei (/api/search/<sprache>.json). Die Aufteilung nach Sprachen war nötig, weil eine gemeinsame Datei das Limit von 25 MiB pro Datei bei Cloudflare Pages überschritt.
• Die Suchseite lädt den Index ihrer Sprache und durchsucht ihn im Browser mit der Bibliothek Fuse.js. Eine Datei ist heute 7,7 bis 9,4 MB groß, deshalb lädt sie nur, wer die Suche öffnet, nicht jeder Leser.
• Der Server leistet bei der Suche keine Arbeit, unabhängig von der Zahl der Nutzer. Der Preis ist die Größe des Index, die mit dem Blog wächst.

#Wie misst man Core Web Vitals nach der Migration von WordPress zu Astro?

In WordPress-Umgebungen verschlechtern sich Web-Vitals-Werte häufig unbemerkt nach Plugin-Updates. In Astro behalte ich die Leistung so im Blick:

• Lighthouse in GitHub Actions: Den Workflow lighthouse.yml starte ich manuell oder per Label am Pull Request, wenn sich Templates oder Layout ändern. Er läuft nicht bei jedem Commit, weil das Kontingent an Actions-Minuten begrenzt ist.
• Messung mit PageSpeed Insights: Am 20. Oktober 2026 lag der Laborwert mobil bei 94 für /pl/ (LCP 2,7 s) und bei 98 für /en/astro-developer/ (LCP 2,3 s). Felddaten aus CrUX zeigt Google für diese Adressen noch nicht, es ist also eine Labormessung und keine Bewertung der Core Web Vitals.
• Sofortige Edge-Cache-Invalidierung: Nach dem Deployment ruft das Release-Skript die Cloudflare Zone API auf (purge_cache: {"purge_everything": true}), sodass weltweite Edge-Knoten ohne Wartezeit auf s-maxage-Abläufe aktualisierte Inhalte ausliefern.
• Deterministisches Caching für Hashed Assets: Statische CSS-, JS- und AVIF-Dateien tragen den Header Cache-Control: public, max-age=31536000, immutable, während HTML-Dokumente über max-age=0, must-revalidate mit Edge-Tags gesteuert werden. Dies ermöglicht sofortige Rollbacks ohne veraltete Zwischenspeicherartefakte.

#Checkliste für die Migration von WordPress zu Astro

Aus dieser Migration leitet sich folgende Checkliste vor der DNS-Umschaltung ab:

1. Vollständiges Routen-Inventar: Export aller historischen URLs aus WordPress-MySQL-Tabellen (Beiträge, Seiten, Archive, Kategorien, RSS-Feeds, Medienanhänge).
2. Design der Weiterleitungsarchitektur: Erstellung einer lückenlosen 301-Mapping-Tabelle unter Berücksichtigung aller Sprachpfade.
3. Bereitstellung von Edge Functions: Implementierung der Weiterleitungs-Engine in einer Edge Function (Cloudflare Functions / Worker), um statische Dateigrenzen zu umgehen.
4. Hreflang-Netzwerk-Validierung: Sicherstellung vollständiger wechselseitiger Verknüpfungen über alle Sprachversionen des gesamten Korpus.
5. JSON-LD-Schema-Audit: Validierung von Article-, FAQPage-, HowTo- und Organization-Schemas nach schema.org-Standards.
6. Modulare Sitemap-Bereitstellung: Segmentierung der XML-Sitemaps mit striktem Ausschluss aller noindex-Seiten.
7. Heap- und Build-Profiling: Testen der Kompilierung unter Speicherbeschränkungen und Feinjustierung der V8-Heap-Parameter.
8. Sicherheits-Header konfigurieren: Erzwingung von CSP, HSTS, X-Frame-Options und Permissions-Policy auf CDN-Ebene.
9. Indexierungs-Audit: Verifizierung, dass Staging-Umgebungen und Duplikate zuverlässig von der Indexierung ausgeschlossen sind.
10. Post-Cutover Smoke Testing: Automatisierte HTTP-Statuscode-Prüfungen und Monitoring der Search Console direkt nach der DNS-Propagierung.

#Nach PHP2Shell von WordPress auf eine statische Website wechseln?

Am 21. Oktober 2026 hat das PHP-Projekt Korrekturen für PHP2Shell veröffentlicht, zwei kritische Lücken in PHP selbst (CVE-2026-109618 und CVE-2026-109619). Laut php.net ist jede PHP-Installation gefährdet, die Webanfragen bedient, und für die riskanteste Konfiguration gibt es einen funktionierenden Exploit, der greift, bevor irgendein Anwendungscode startet (php.net). Wiz Research ergänzt, dass schon eine einfache “Hello World”-Anwendung auf einer betroffenen PHP-Version angreifbar sein kann (Wiz). Eine Website, die zu HTML-Dateien gebaut und ohne PHP ausgeliefert wird, fällt nicht unter diese Meldung. Diese Website gehört dazu: In jener Woche gab es hier kein PHP zu aktualisieren. Was auf einer Website zu tun ist, die weiter mit PHP läuft, steht in meinem Ratgeber zu PHP2Shell.

In derselben Woche beschrieb auf r/webdev der Betreiber einer technischen Publikation, der von WordPress zu Hugo auf Cloudflare Pages gewechselt ist, den Sicherheitsgewinn so:

Für mich ist der größte Gewinn, kein allgemein bekanntes, öffentlich erreichbares und ständig abgetastetes /wp-admin/-Portal mehr zu haben und mir danach keine Sorgen um Lücken im darunterliegenden Stack machen zu müssen.

(eigene Übersetzung, u/Select_From, r/webdev)

In einem zweiten Thread schrieb ein Entwickler, er habe nach PHP2Shell mit einem KI-Agenten 45 WordPress-Websites von Kunden in 36 Stunden auf Astro umgestellt. Eine der ersten Antworten fragte nach dem Teil, den ein statischer Build offen lässt:

Du erwähnst in deinem GitHub-README ständig statische Dateien, aber was ist mit neuen Beiträgen? Womit können Kunden neue Daten hinzufügen oder bestehende bearbeiten?

(eigene Übersetzung, u/Lower_Rabbit_5412, r/webdev)

Der Autor antwortete, er habe für die 2 oder 3 Kunden, die selbst bearbeiten wollten, ein Git-basiertes CMS gebaut. Die PHP-Angriffsfläche verschwindet, und jede dynamische Aufgabe, die WordPress an einer Stelle erledigt hat, wandert woandershin und braucht dort eine eigene Zuständigkeit:

Eine Antwort im Hugo-Thread nannte die Reihenfolge der Probleme so, wie ich sie erlebt habe:

Die größte Hürde sind meist die Permalinks, jede alte URL braucht eine 301, sonst verlierst du Rankings. Danach kommen die dynamischen Teile: Kommentare, Suche, Formulare.

(eigene Übersetzung, u/ResidentPomegranate6, r/webdev)

Die Portierung der Templates hat bei mir Wochen gedauert, die Monate danach gingen in Weiterleitungen, hreflang und die oben beschriebenen Prüfungen. Eine Migration heißt, die Website neu zu bauen.

Updates und laufende Wartung sind oft die bessere Antwort. PHP2Shell wurde durch ein PHP-Update geschlossen, und eine Migration, die Wochen dauert, hilft einem Server nicht, der heute ungepatcht ist. Bleiben Sie bei WordPress, WooCommerce, Magento oder einem anderen PHP-Stack und halten Sie ihn aktuell, wenn Ihre Redaktion täglich im Backend arbeitet, wenn Ihr Geschäft an Plugins mit echter Logik hängt (Shop, Buchungen, Mitgliedschaften, Kurse) oder wenn niemand im Team einen Git-Workflow übernimmt. Ein statischer Build passt, wenn sich Inhalte selten ändern, wenige Personen sie bearbeiten und der dynamische Teil aus einem Formular und einer Suche besteht. Eine PHP-Website braucht regelmäßige WordPress-Wartung inklusive PHP-Updates; den Neubau als statische Website übernimmt ein Astro-Entwickler.

Update vom 24. Oktober 2026, ein Mittelweg: Bei WordPress bleiben oder in Astro neu bauen sind nicht die einzigen beiden Optionen. Matt Cromwell beschrieb am 14. Oktober 2026, wie er die Website seiner Firma ohne öffentliche WordPress-Installation neu aufgebaut hat. WordPress läuft nur auf seinem Rechner in WordPress Studio, ein Compiler macht aus seinem Designsystem eine theme.json und wiederverwendbare Block-Patterns, das Plugin Simply Static exportiert die Seite als statische Dateien, und Cloudflare Pages liefert sie aus. Der Block-Editor bleibt, und auf der öffentlichen Website gibt es kein PHP mehr zu patchen. Aufwand entsteht bei Formularen: Ein WordPress-Formular-Plugin, das über PHP absendet, funktioniert auf exportierten Seiten nicht, also hat er einen eigenen Endpoint geschrieben, der Newsletter-Anmeldungen über die API an MailerLite schickt. Er weist auch darauf hin, dass eine statische Website grundsätzlich Grenzen hat, unabhängig vom Plugin. Das passt zu einer Unternehmenswebsite, die auf einem Rechner gepflegt wird. Ein Shop, ein Mitgliederbereich oder eine Redaktion, die täglich veröffentlicht, braucht weiter einen Server. Muss das Backend online bleiben, während das Frontend ohne PHP laufen soll, ist das ein Headless-CMS-Aufbau.

#Was bringt die Migration zu Astro nach zehn Monaten?

Nach zehn Monaten ist die Bilanz der Migration zu Astro auf Cloudflare Pages für meine Content- und Service-Plattform positiv:

1. Server-Antwortzeit (TTFB): Eine Seite aus dem Edge-Cache von Cloudflare antwortet aus Gdynia in etwa 0,21 bis 0,26 s, inklusive TLS-Verbindungsaufbau (curl, 20.10.2026). Eine vergleichbare Messung aus der WordPress-Zeit habe ich nicht, daher nenne ich keine prozentuale Verbesserung.
2. Kleinere Angriffsfläche: Ohne PHP, SQL-Datenbank und wp-admin fallen ganze Klassen typischer WordPress-Angriffe weg: SQL-Injection, Codeausführung über ein verwundbares Plugin, Brute-Force-Angriffe auf das Login. Eine kleinere Fläche bleibt zu überwachen: die Endpunkte in Cloudflare Functions (Formular, API) und die Sicherheits-Header.
3. KI- und Suchmaschinen-Verfügbarkeit: Schlankes, semantisches HTML ohne blockierendes JavaScript ermöglicht es Suchmaschinen und LLM-Crawlern (OpenAI, Anthropic, Perplexity), technische Inhalte unmittelbar zu erfassen (GEO/AEO).
4. Minimale Betriebskosten: Die Bereitstellung statischer Dateien über CDNs verursacht im Vergleich zu hochverfügbaren Datenbank-Clustern vernachlässigbare Infrastrukturkosten.

Das ehrliche Fazit: Die Migration von WordPress zu Astro ist kein oberflächlicher Relaunch. Es ist ein tiefgreifendes Softwareprojekt, bei dem das Erstellen der Templates der leichteste Schritt ist und die Hauptarbeit in Routing-Architektur, automatisierten Qualitäts-Gates und mehrsprachiger Disziplin liegt. Für Content-Websites, denen Geschwindigkeit und Reichweite in mehreren Sprachen wichtig sind, lohnt sich diese Arbeit. Wenn Sie diese Architektur für Ihr Unternehmen evaluieren möchten, erfahren Sie mehr über meine Arbeitsweise als Astro-Entwickler, oder informieren Sie sich über meinen Leitfaden zur WordPress-zu-Astro-Migration. Weitere ingenieurtechnische Analysen finden Sie im WPPoland-Blog.