Ausgangslage
Die bestehende WordPress-Seite hatte redaktionellen Wert, indexierte URLs, historische Inhalte und Integrationen. Das Risiko war nicht, ob Astro oder Next.js Seiten rendern kann. Das Risiko war der Verlust von Workflow, strukturierten Daten, Redirects und Vertrauen beim Cutover.
Der Plan behandelte WordPress zuerst als Content-System und erst danach als Rendering-Schicht.
Diagnose
Der Audit startete mit Content Types, Taxonomien, URL-Mustern, Canonicals, hreflang, Schema, Preview, Suche und Integrationen.
Erst danach war die Frontend-Wahl sinnvoll: Astro für Content-Flächen, Next.js für authentifizierte oder personalisierte Flows.
Architekturentscheidung
WordPress blieb die redaktionelle Source of Truth. Das öffentliche Frontend wanderte in eine Composable-Schicht mit Edge Delivery, strikter URL-Map und getesteten Redirects.
Der Plan vermied einen Big-Bang-Rewrite. Routen wurden nach Risiko gruppiert: statischer Content zuerst, dynamische Flächen später, Checkout oder Accounts erst nach separater Validierung.
Risikokontrolle
Die Checkliste umfasste 301-Maps, Canonicals, Sitemap-Parität, Schema-Parität, Bildgrößen, Editorial Preview, Cache-Invalidierung und Monitoring nach dem Cutover.
Rollback war Teil des Plans. Das alte WordPress-Frontend blieb verfügbar, bis das neue Frontend Parität auf den kritischen Templates bewiesen hatte.