Migration von WordPress zu Astro und Next.js

#Wann lohnt sich die Migration von WordPress zu Astro oder Next.js?

Der Engpass ist selten WordPress selbst, sondern meist eine einzelne Schicht: Abfragen, die ein Plugin bei jedem Aufruf erzeugt, ein Cache, der eingeloggte Nutzer auslässt, Bilder in Originalgröße oder ein Theme, das ein Dutzend CSS- und JS-Dateien lädt. Jede dieser Ursachen lässt sich einzeln messen, mehrere lassen sich ohne neues Frontend beheben.

Eine Frontend-Migration lohnt sich, wenn das Problem im Theme und im Rendering liegt, wenn Templates in ein Repository und Veröffentlichungen über einen Build laufen sollen oder wenn dieselben Inhalte per API auch andere Kanäle bedienen. Sie lohnt sich selten, wenn die Seite von Plugins lebt, die das Frontend erzeugen (Page Builder, WooCommerce mit vielen Erweiterungen), denn jede dieser Funktionen müsste neu geschrieben werden.

Die Trennung verändert auch die Angriffsfläche. Öffentlicher Verkehr erreicht kein PHP mehr, aber WordPress, Plugins, Konten und APIs brauchen weiterhin Updates, Zugriffskontrolle, Backups und Monitoring. Eine Headless-Architektur schützt nicht vor einem kompromittierten Backend oder einer unsicheren Integration.

#Astro oder Next.js?

Beide Frameworks können statisch generieren und auf dem Server rendern. Sie starten von verschiedenen Annahmen.

Astro ist eine Multi-Page-Architektur mit src/pages/index.astro als Startseite. Standard ist output: 'static': Seiten werden beim Build zu HTML. UI-Komponenten, auch React-Komponenten über @astrojs/react, kommen ohne Client-JavaScript an, bis Sie sie mit client:load, client:idle oder client:visible zu interaktiven Inseln machen. Einzelne Seiten rendern Sie mit export const prerender = false und einem Adapter (@astrojs/cloudflare, @astrojs/netlify, @astrojs/node, @astrojs/vercel) bei Bedarf. Mit server:defer wird eine Astro-Komponente zur Server-Insel, die getrennt vom Rest der Seite gerendert wird. Astro ist kein React-Framework, kann React aber einbinden.

Next.js ist ein React-Framework. Im App Router (app/) laufen Server Components auf dem Server, Client Components werden mit 'use client' markiert. Statische Seiten lassen sich mit export const revalidate per ISR neu erzeugen oder gezielt mit revalidatePath und revalidateTag invalidieren. Für die Vorschau von Entwürfen aus einem Headless CMS gibt es draftMode(). Ein reiner statischer Export mit output: 'export' verzichtet auf ISR, Proxy, Cookies, Redirects aus next.config.js und die Standard-Bildoptimierung.

Daraus folgt: Astro für Firmenwebsites, Blogs und Dokumentation, Next.js für Kundenportale, Anwendungen mit Login und Inhalte, die sich bei jeder Anfrage ändern. Was ein Astro-Entwickler im Detail mitbringen sollte, beschreibe ich auf einer eigenen Seite.

#Consent und Tracking im neuen Frontend

Mit dem Theme verschwinden auch die Plugins, die bisher Cookie-Banner und Tracking-Skripte eingebunden haben. Im neuen Frontend muss das neu gebaut werden, und dabei gilt § 25 TDDDG: Informationen auf dem Endgerät dürfen nur mit Einwilligung gespeichert oder ausgelesen werden, außer das ist für einen ausdrücklich gewünschten Dienst unbedingt erforderlich. Ich binde Consent-Tool und Analytics deshalb so ein, dass vor der Einwilligung nichts Nicht-Notwendiges lädt, und prüfe das im Netzwerk-Tab der neuen Seite. Für Websites in Österreich gilt dieselbe Regel nach § 165 Abs. 3 TKG 2021.

#Wie sieht der Migrationsprozess aus?

#Audit und Angebot

Ich messe die Seite, erfasse Inhaltstypen, ACF-Felder, Formulare und Integrationen mit CRM und Analytics und prüfe, welche Plugins etwas im Frontend ausgeben. Framework-Wahl, Umfang, Annahmen und Zeitplan stehen schriftlich im Angebot, bevor Code entsteht. Bekomme ich Zugang zu personenbezogenen Daten, schließen wir vorher einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO.

#WordPress als API

Ich räume das Backend auf, beschränke den Zugang zum Admin-Bereich und prüfe, was die REST API ausgibt. WPGraphQL installiere ich nur, wenn die Inhaltsstruktur es verlangt.

#Neues Frontend

Templates nach Ihrem Design, im privaten Git-Repository, mit einer Vorschauversion, auf der Sie abnehmen. Ich beschreibe jede Änderung schriftlich.

#Go-live

Die alte Seite läuft, bis der DNS-Eintrag umgestellt ist. Stimmt danach etwas nicht, zeigt die Domain wieder auf die alte Version. WordPress ist ab dann nicht mehr öffentlich erreichbar und dient nur noch der Redaktion.

#Typische Migrationsszenarien

Inhaltsseiten. Blogbeiträge, Artikel und Informationsseiten ändern sich selten und werden oft gelesen. Hier passt Astro mit statischer Generierung. Offen bleibt nur, was nach einer Veröffentlichung den Build auslöst.

WooCommerce-Shops. Katalog, Warenkorb, Zahlung und Kundenkonten müssen im Headless-Aufbau im Frontend neu entstehen. Bei Shops mit vielen Erweiterungen rate ich meist dazu, beim klassischen Theme zu bleiben und dessen Performance zu verbessern.

Anwendungen mit Login. Kundenbereiche und nutzerabhängige Daten sind das Terrain von Next.js: öffentliche Seiten vorab rendern, Bereiche nach dem Login auf dem Server.

#Kontakt und verwandte Leistungen

Schicken Sie mir über das Kontaktformular Ihren aktuellen Stack, das Ziel-Framework, URL-Vorgaben, Integrationen und Sprachen. Sie bekommen per E-Mail die nächsten Schritte und ein Angebot mit den Annahmen, auf denen es beruht. Verträge schließe ich als B2B-Vertrag nach polnischem Recht, Rechnungen laufen im Reverse-Charge-Verfahren mit meiner EU-USt-IdNr. PL7393037445.

Migration besprechen

Neue Next.js-Projekte ohne WordPress-Ausgangspunkt beschreibt die Seite Next.js-Entwickler. Einen Bericht über die Migration dieser Website lesen Sie unter WordPress zu Astro migrieren.