Migration zu Next.js / Astro in Dortmund

Ein Frontend aus der Zeit von Gatsby, Create React App oder AngularJS läuft oft jahrelang unauffällig, bis ein Update einer Abhängigkeit scheitert oder die Suchmaschine nur eine leere Hülle sieht. Diese Seite richtet sich an Betriebe in Dortmund, die so ein Frontend besitzen und wissen wollen, was der Wechsel zu Astro oder Next.js bedeutet: was übernehmbar ist, wie Routing und Datenabruf danach funktionieren und was sich bei der Indexierung ändert.

Mein Name ist Mariusz Szatkowski. Ich entwickle seit 2006 mit WordPress und baue Frontends als Einzelperson, remote von Gdynia aus. Die Abstimmung läuft ausschließlich schriftlich.

Foto: G. Rieß, CC BY-SA 3.0, Wikimedia Commons.

#Welcher alte Stack läuft bei Ihnen, und was sagen die Projekte dazu?

Welche Zeile auf Sie zutrifft, sehen Sie in der Datei package.json Ihres Projekts. Steht dort react-scripts, ist es Create React App. Steht dort gatsby, ist es Gatsby. Ein Paket angular in der Versionsreihe 1.x ist AngularJS. Fehlt ein Framework ganz, ist es meist jQuery mit Plugins.

#Gatsby: Stand November 2026

Die Seite gatsbyjs.com nennt Netlify als nächste Entwicklung von Gatsby Cloud und bietet Gatsby-Cloud-Kunden Wege zur Migration zu Netlify an. Zum Status des Open-Source-Frameworks steht dort nichts. Auf npm ist gatsby 5.16.1 vom 10. Februar 2026 die aktuelle Version, davor erschien 5.16.0 am 26. Januar 2026. Das GitHub-Repository ist nicht archiviert. Die drei jüngsten Commits stammen vom 9. November, 15. Oktober und 16. September 2026 und betreffen eine Renovate-Regel, einen Link in der Dokumentation und einen E2E-Test.

Das Bild: nicht eingestellt, aber ruhig. Für Sie zählt weniger die Nachrichtenlage als die eigene Lage. Wie viele Gatsby-Plugins hängen im Projekt, wie lange dauert der Build, und wer aktualisiert sie. Die Astro-Anleitung für Gatsby ordnet einzelne Plugins nicht zu. Diese Zuordnung entsteht deshalb in der Bestandsaufnahme, Plugin für Plugin.

#Create React App: was React dazu schreibt

React hat am 14. Februar 2025 erklärt, Create React App für neue Apps als veraltet einzustufen und bestehenden Apps den Wechsel zu einem Framework oder zu Vite, Parcel oder Rsbuild zu empfehlen. Als Gründe nennt der Beitrag fehlende aktive Maintainer und die Lücken bei Routing, Datenabruf und Code-Splitting. Die Anwendung läuft im Wartungsmodus weiter, eine neue Version arbeitet mit React 19. Als Faustregel steht dort: Braucht Ihre App Routing, hilft ein Framework.

Heißt für Sie: Es gibt keinen Stichtag, aber auch keinen Maintainer, der Probleme behebt. Wer die Anwendung nur intern nutzt und selten ändert, kann abwarten. Wer sie öffentlich betreibt und gefunden werden will, hat mit dem reinen Client-Rendering ein eigenes Problem, das ich weiter unten erläutere.

#AngularJS und jQuery

Auf docs.angularjs.org steht: AngularJS support has officially ended as of January 2022. Eine Migrationsanleitung für AngularJS finde ich in der Astro-Dokumentation nicht. Ich gehe so vor: erst die Liste der Ansichten, dann die Frage, welche davon noch jemand öffnet. Für diese schreibe ich die Ansichten neu und übernehme alles, was keinen Framework-Bezug hat, als TypeScript-Module, etwa Berechnungen, Validierungen und API-Aufrufe.

jQuery-Seiten sind einfacher, als sie aussehen. Astro bündelt Skripte, die Dateien und npm-Module importieren, und gibt sie als Module aus. Daraus folgt, dass ein per npm installiertes jQuery in einem Astro-Skript importiert werden kann. Das ist ein Zwischenschritt, kein Ziel. Wo ein Plugin nur ein Menü auf- und zuklappt, ersetze ich es durch HTML und ein paar Zeilen eigenes Skript.

#Was sich wiederverwenden lässt

Aus der Astro-Anleitung für Gatsby und der für Create React App ergibt sich folgende Aufteilung:

• React-Komponenten: laufen über die offizielle Integration @astrojs/react weiter, Dateien brauchen die Endung .jsx oder .tsx. Astro-Komponenten dürfen React-Komponenten importieren, React-Komponenten aber nur andere React-Komponenten.
• MDX und Markdown: MDX läuft über @astrojs/mdx, Markdown ist eingebaut. Die Frontmatter-Felder müssen teils angepasst werden.
• npm-Pakete: die meisten React-Bibliotheken funktionieren weiter. Nicht jede Abhängigkeit läuft in Astro, das teste ich einzeln.
• Tailwind: funktioniert über das Tailwind-Vite-Plugin, ohne dass die Klassen im Code angefasst werden.
• Nicht übernehmbar: Gatsbys .js-Seitendateien. Sie werden zu .astro-Dateien. Ebenso Gatsbys <Helmet>, denn das <head> steht in Astro direkt im Layout.

Bei Next.js bleiben Komponenten React. Dort sind die Änderungen anders gelagert: Die Next.js-Anleitung nennt für Create React App unter anderem das Layout statt public/index.html, die Metadata-API statt Tags im Head, Bildimporte, die ein Objekt statt einer URL liefern, und den Wechsel des Variablenpräfix von REACT_APP_ zu NEXT_PUBLIC_.

#Routing und Datenabruf: was sich ändert

Routing. Gatsby und Create React App bauen eine Single-Page-App mit index.js als Wurzel. Astro baut eine Seite mit mehreren HTML-Dokumenten, die Routen ergeben sich aus den Dateien unter src/pages/. Next.js nutzt im App Router Ordner mit einer page.tsx. Eine eigene Routenkonfiguration entfällt in beiden.

Datenabruf. In Gatsby kommen Daten über GraphQL. In Astro treten getCollection() und getEntry() aus astro:content, Importe oder fetch() an die Stelle. GraphQL ist nicht standardmäßig dabei, lässt sich aber nachrüsten. In Create-React-App-Code lädt oft ein useEffect die Daten nach dem Rendern. Astro ersetzt das laut Anleitung durch Top-Level-await im Frontmatter. Next.js lässt Daten in Server Components laden und kann sie mit use() an Client-Komponenten streamen, was Anfrage-Kaskaden im Browser vermeidet.

Interaktivität. Astro rendert Komponenten zu HTML und CSS und liefert JavaScript nur, wenn Sie eine client:*-Direktive setzen. Das ist die Insel. Ohne Direktive rendert Astro eine React-App als statisches HTML. client:load rendert auf dem Server und lädt die App sofort. client:only="react" überspringt das Server-Rendering, die App läuft dann komplett im Browser.

#Was Google sieht: Client-Rendering gegen fertiges HTML

Die Dokumentation von Google zu JavaScript und SEO beschreibt, was sich ändert:

• Bei Server-Rendering enthält die HTTP-Antwort den gesamten Inhalt. Beim App-Shell-Modell enthält das erste HTML den Inhalt nicht, Google muss JavaScript ausführen.
• Google stellt alle Seiten mit Status 200 in eine Rendering-Warteschlange. Die Seite kann dort Sekunden, aber auch länger liegen.
• Google empfiehlt Pre-Rendering, weil nicht alle Bots JavaScript ausführen können.
• Links werden nur erkannt, wenn sie <a>-Elemente mit href sind. Eine Schaltfläche mit Klick-Handler gehört nicht dazu.
• Unterschiedliche Inhalte dürfen nicht über URL-Fragmente nach dem # geladen werden. Das betrifft jede Anwendung, deren Ansichten nur über ein # in der Adresse erreichbar sind.
• Bei Client-Routing sind sinnvolle HTTP-Statuscodes oft unmöglich, was Soft-404-Seiten erzeugt.

Das heißt für Ihr Projekt: Wer eine Create-React-App-Anwendung in Next.js zunächst als reine Client-Anwendung einbindet, wie es die Next.js-Anleitung als ersten Schritt vorsieht, hat noch kein Server-HTML. Die Anleitung deaktiviert dort das Server-Rendering mit ssr: false ausdrücklich. Der SEO-Effekt kommt erst, wenn Routen wirklich als eigene Seiten entstehen. Dasselbe gilt für Astro mit client:only.

Ein Versprechen zu Rankings gebe ich nicht. Vor dem Umbau halte ich fest, welche URLs Besucher bringen, was Google indexiert hat und wie die Werte für LCP bis 2,5 s, INP bis 200 ms und CLS bis 0,1 heute stehen. Danach messe ich dasselbe und nenne die Abweichungen.

#URLs und Weiterleitungen beim Wechsel

Sobald aus einer Anwendung mit einer Adresse viele Seiten werden, ändern sich Adressen. Google rät in der Anleitung zu Umzügen, jede alte URL einem Ziel zuzuordnen, serverseitige permanente Weiterleitungen zu verwenden, direkt auf das endgültige Ziel zu leiten, Änderungen nacheinander statt gleichzeitig vorzunehmen und die Weiterleitungen so lange wie möglich, in der Regel mindestens ein Jahr, zu behalten. JavaScript-Weiterleitungen sind laut Google nur der letzte Ausweg, weil Google sie womöglich nie sieht, wenn das Rendering scheitert. Wie ich eine URL-Karte baue und teste, steht ausführlich auf der Seite zu den Weiterleitungen in Bremen, den Testplan für den Umschalttag beschreibt die Seite zur Qualitätssicherung vor dem Go-live in Zürich.

#Recht in Nordrhein-Westfalen beim Umbau

Alte Frontends laden oft Skripte, die niemand mehr kennt: Analytics-Snippets, Chat-Widgets, Schriftarten von fremden Servern. § 25 des TDDDG erlaubt das Speichern von Informationen auf dem Endgerät oder den Zugriff darauf nur mit Einwilligung, außer es ist unbedingt erforderlich, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten digitalen Dienst bereitstellen kann. Ich lege beim Neubau eine Liste aller Skripte und Dienste an und nehme nur auf, was Sie ausdrücklich behalten wollen. Ihre Datenschutzerklärung gleichen Sie danach mit dieser Liste ab. Für Dortmund ist die Datenschutzaufsicht die LDI NRW. Eine Rechtsberatung ersetzt das nicht, die Bewertung liegt bei Ihrer Datenschutzbeauftragten oder Ihrem Datenschutzbeauftragten oder bei einer Kanzlei.

#Wie ein Umbau des JavaScript-Frontends bei mir abläuft

1. Schriftliche Anfrage. Sie senden die Adresse der Seite, den Stack und das Ziel.
2. Bestandsaufnahme. Ich lese package.json, liste Plugins, Routen, Datenquellen und eingebundene Skripte auf und crawle die Seite.
3. Schriftlicher Umfang. Welche Ansichten umziehen, was entfällt, Astro oder Next.js, Annahmen und Ausschlüsse. Grafikdesign, Mockups und Wireframes liefern Sie, ich setze sie um.
4. Staging. Das neue Frontend läuft auf einer Testadresse, mit URL-Test und Stichproben zu den Inhalten.
5. Abnahme und Umstellung. Sie prüfen, dann schalte ich um.
6. Wartungsoption. Den Code und das Repository erhalten Sie zur freien Verfügung, eine Wartung buchen Sie nur, wenn Sie sie wollen.

Checkliste vor dem Start, auch ohne mich nutzbar:

Ich brauche von Ihnen Zugang zum Repository und zum Hosting sowie die Layoutvorgaben, wenn sich etwas ändern soll.

#Für wen in Dortmund passt das?

Für Betriebe, deren öffentliche Seite als Gatsby-Projekt, als Create-React-App-Anwendung oder als AngularJS-Oberfläche gebaut wurde und deren Inhalte gefunden werden sollen. Was ich zu den Zielsystemen selbst schreibe, steht auf den Seiten zur Astro-Entwicklung in Dortmund und zur Next.js-Entwicklung in Dortmund. Den Ablauf, der für jede Quelle gleich bleibt, zeigt die Hauptseite zur Migration.

#Häufige Fragen

#Ist Gatsby abgekündigt?

Nein, nicht nach dem, was die Quellen zeigen. Das Repository gatsbyjs/gatsby ist nicht archiviert, und auf npm ist gatsby 5.16.1 vom 10. Februar 2026 die aktuelle Version (Stand November 2026). Die Aktivität ist aber gering: Seit Februar gab es kein Release. Ob das für Ihr Projekt ein Problem ist, hängt davon ab, wie viele Plugins Sie einsetzen und wie lange der Build dauert.

#Muss meine Create-React-App-Anwendung sofort ersetzt werden?

Nein. React schreibt, die Anwendung laufe im Wartungsmodus weiter, und eine neue Version arbeite mit React 19. Die Empfehlung an bestehende Apps lautet aber, auf ein Framework oder ein Build-Tool wie Vite, Parcel oder Rsbuild zu wechseln. Ein Datum, an dem etwas abgeschaltet wird, nennt React nicht. Der Handlungsdruck entsteht eher durch fehlende Maintainer und durch das Client-Rendering.

#Kann ich meine React-Komponenten behalten?

Meist ja. Die Astro-Anleitung für Gatsby und für Create React App nennt dafür die React-Integration: Komponenten mit der Endung .jsx oder .tsx laufen weiter, die meisten npm-Pakete ebenfalls. Nicht jede React-Abhängigkeit funktioniert in Astro, das prüfe ich Paket für Paket. Bei Next.js bleiben Komponenten ohnehin React.

#Was passiert mit einer AngularJS-Anwendung?

AngularJS ist seit Januar 2022 offiziell ohne Support. Eine Migrationsanleitung für AngularJS finde ich in der Astro-Dokumentation nicht. In der Praxis heißt das: Die Ansichten werden neu geschrieben, Geschäftslogik ohne Framework-Bezug übernehme ich als TypeScript-Module. Vorher klären wir schriftlich, welche Ansichten wirklich gebraucht werden.

#Verändert der Wechsel von Client-Rendering zu fertigem HTML meine Rankings?

Dazu gebe ich kein Versprechen. Google verarbeitet JavaScript-Seiten in einer Warteschlange und rät zu Pre-Rendering, weil nicht alle Bots JavaScript ausführen. Fertiges HTML nimmt diese Abhängigkeit weg. Ob Sichtbarkeit und Core Web Vitals danach besser oder schlechter sind, messe ich mit Search Console und Crawl vorher und nachher und benenne Abweichungen.

#Astro oder Next.js für den Ersatz?

Astro passt, wenn die Seite überwiegend Inhalte zeigt und einzelne Teile interaktiv sind. Next.js passt, wenn die Anwendung als Ganzes interaktiv bleibt, etwa mit Login oder Konfigurator, oder wenn Server-Funktionen gebraucht werden. Bei einer CRA-Anwendung mit vielen Routen und Zustand ist Next.js oft der kürzere Weg, bei einer Gatsby-Seite mit Blog und Landingpages Astro.

#Schreiben Sie mir, bevor der alte Stack ausläuft

Schicken Sie mir über das Kontaktformular die Adresse Ihrer Seite, den eingesetzten Stack, Ihr Ziel und einen Wunschtermin für die Umstellung. Ein Export der Search-Console-Leistung hilft, ist aber kein Muss. Ich antworte schriftlich an Werktagen mit einer ersten Einschätzung: Passt Astro oder Next.js, was bleibt, was wird neu geschrieben und welche Fragen sind offen. Diese erste Einschätzung ist kostenlos.