Migration zu Next.js / Astro in Köln

Ein Relaunch an einem Stichtag ist bequem zu planen und unangenehm, wenn am Morgen danach das Kontaktformular schweigt und niemand weiß, ob es am neuen Framework, am neuen Hosting oder am neuen Layout liegt. Für Kölner Unternehmen mit gewachsenen Websites auf WordPress, Joomla oder Drupal baue ich die Migration zu Astro oder Next.js deshalb meist als Folge kleiner Schritte: Altes und neues System laufen unter derselben Domain, ein Bereich nach dem anderen wechselt, und jeder Wechsel lässt sich zurücknehmen. Auf dieser Seite steht, wie das technisch funktioniert, wann es sich nicht lohnt und was Sie für einen solchen Umzug vorbereiten.

#Wann sich ein Umzug in Etappen lohnt und wann nicht

Google beschreibt im Leitfaden zu Website-Umzügen mit URL-Änderungen zwei Wege. Für kleine und mittlere Websites empfiehlt Google, alle URLs gleichzeitig umzuziehen, weil Nutzer dann die neue Form auf einmal erleben und die Systeme den Umzug schneller erkennen. Große Websites können Bereich für Bereich umziehen, was Probleme leichter sichtbar und schneller behebbar macht. Die Bedingung dahinter: Die Adressen ändern sich.

Etappen im Sinne dieser Seite meinen etwas anderes. Die URLs bleiben gleich, nur das System, das unter einer Adresse antwortet, wechselt. Für Google ist das zunächst kein Umzug von Adressen, sondern ein Austausch dessen, was hinter ihnen steht. Im selben Leitfaden steht der Satz, an dem ich solche Projekte ausrichte: nur eine Sache auf einmal ändern. Als Beispiel nennt Google Domain, CMS und Layout, die nacheinander statt gleichzeitig geändert werden sollten.

Daraus ergibt sich meine Reihenfolge:

1. Zuerst wechselt das System, bei gleichen URLs und möglichst gleichem Inhalt.
2. Dann folgen inhaltliche oder gestalterische Änderungen, Bereich für Bereich.
3. Neue URL-Strukturen kommen zuletzt, mit einem eigenen Weiterleitungsplan.

Bei einer Website mit zwanzig Seiten ist dieser Aufwand meist größer als der Nutzen. Dann rate ich zu einem sauberen Wechsel an einem Tag, gut vorbereitet auf einer Staging-Umgebung. Bei hunderten Beiträgen, mehreren Redaktionen, einem Shop neben dem Magazin oder einem Login-Bereich spielt der schrittweise Weg seine Stärke aus.

#Wie sich zwei Systeme eine Domain teilen

Irgendetwas muss entscheiden, welcher Pfad von welchem System beantwortet wird. Dafür gibt es drei Stellen, und welche passt, hängt davon ab, wo Ihre Website heute läuft.

#Next.js als vorderste Instanz

Next.js kann Anfragen, die es selbst nicht beantworten kann, an eine bestehende Website weiterreichen. Die Dokumentation zu Rewrites beschreibt dafür die Gruppe fallback: Diese Regeln greifen erst, nachdem Next.js seine eigenen Seiten, statischen Dateien und dynamischen Routen geprüft hat, und vor der 404-Seite. Die Docs nennen das ausdrücklich als Weg zur schrittweisen Einführung, bei dem die Konfiguration nicht für jede umgezogene Seite angepasst werden muss.

// next.config.js
module.exports = {
  async rewrites() {
    return {
      fallback: [
        { source: '/:path*', destination: 'https://alt.ihre-firma.de/:path*' },
      ],
    };
  },
};

Jede Seite, die im neuen Projekt entsteht, übernimmt damit automatisch ihre Adresse. Alles andere liefert weiter das alte System. Ein Rewrite verbirgt dabei das Ziel: Die Adresse im Browser bleibt dieselbe. Enden Ihre alten Adressen mit einem Schrägstrich und ist in Next.js trailingSlash: true gesetzt, muss der Schrägstrich laut Doku auch in source und, wenn der Zielserver ihn erwartet, in destination stehen. Das ist eine typische Stelle für doppelte Adressen, die ich vor dem ersten Schritt teste.

#Next.js Multi-Zones

Wenn mehrere Bereiche getrennt entwickelt werden sollen, etwa ein Blog und ein Kundenbereich, beschreibt Next.js Multi-Zones. Jede Zone ist eine eigene Anwendung, die bestimmte Pfade bedient, und alle laufen unter derselben Domain. Die Doku hält einige Punkte fest, die für die Planung zählen:

• Jede Zone braucht ein eigenes assetPrefix, damit JavaScript und CSS der Zonen nicht kollidieren.
• Ein Pfad darf nur zu einer Zone gehören. Zwei Zonen, die beide /blog bedienen, erzeugen einen Konflikt.
• Wechsel innerhalb einer Zone sind weiche Navigationen, Wechsel zwischen Zonen sind harte Navigationen, bei denen die Seite neu lädt.
• Für eine dynamische Entscheidung, etwa per Feature-Flag während einer Migration, nennt die Doku proxy als Alternative zu Rewrites.

Seiten, die Besucher oft nacheinander aufrufen, gehören deshalb in dieselbe Zone.

#Astro hinter einem Reverse Proxy

Astro bringt kein eigenes Gegenstück zu den Fallback-Rewrites mit. Hier sitzt ein Proxy vor beiden Systemen, und Astro bedient die Pfade, die ihm zugewiesen werden. Drei Optionen aus der Konfigurationsreferenz entscheiden, ob das sauber funktioniert:

• site ist die endgültige öffentliche Adresse. Astro erzeugt daraus Sitemap und Canonical-URLs. Steht hier der Hostname des internen Servers, zeigen die Canonicals auf eine Adresse, die niemand besuchen soll.
• base legt den Pfad fest, unter dem Astro Seiten und Assets ablegt, zum Beispiel /ratgeber. Dann genügt eine einzige Proxy-Regel für diesen Pfad.
• security.allowedDomains betrifft serverseitig gerenderte Seiten. Ohne diese Option ignoriert Astro den Header X-Forwarded-Host, den der Proxy mitschickt, und arbeitet mit dem Host der ursprünglichen Anfrage.

Dazu kommt trailingSlash. Der Standardwert ignore beantwortet /about und /about/ gleich. Die Schreibweise der alten Website halte ich bewusst fest, damit nicht zwei Varianten einer Adresse entstehen.

#Cloudflare vor beiden Systemen

Liegt Ihre Domain bei Cloudflare, kann die Aufteilung dort stattfinden, unabhängig vom Framework. Eine Workers-Route ordnet ein URL-Muster einem Worker zu, der vor dem bestehenden Server läuft. Anfragen, die zu keinem Muster passen, gehen wie bisher an den Server aus den DNS-Einstellungen. Voraussetzung ist, dass der DNS-Eintrag über Cloudflare geleitet wird.

Ein minimaler Worker für die Route www.ihre-firma.de/ratgeber/* könnte so aussehen:

export default {
  async fetch(request) {
    const url = new URL(request.url);
    url.hostname = 'neu.ihre-firma.pages.dev';
    return fetch(new Request(url, request));
  },
};

Origin Rules wären der Weg ohne Code, doch das Überschreiben von Host-Header und DNS-Eintrag ist laut Cloudflare den Enterprise-Tarifen vorbehalten. Ohne Enterprise-Tarif bleibt deshalb der Worker.

#Welcher Bereich zuerst wechselt

Google rät, für den ersten Testbereich einen zu wählen, der sich selten ändert und nicht stark von häufigen oder unvorhersehbaren Ereignissen abhängt. Im selben Absatz steht die Einschränkung, dass ein einzelner Bereich nicht repräsentativ für den ganzen Umzug ist: Je mehr Seiten wechseln, desto mehr Probleme tauchen auf.

In der Praxis eignen sich als erste Etappe oft Ratgeber, Glossare oder Referenzseiten. Die Startseite, Kontakt- und Anfrageseiten und alles mit Formularen kommen später, wenn Routing, Analyse und Rückweg sich bewährt haben.

Den Zeitpunkt richte ich nach Ihrem Kalender. Google empfiehlt, einen Umzug möglichst in eine Phase mit weniger Besuchern zu legen, wenn der Traffic saisonal schwankt. In Köln hat das Festkomitee Kölner Karneval die Sessionseröffnung am 11.11.2026 auf dem Heumarkt im Kalender geführt. Für Gastronomie, Hotels, Veranstalter oder Kostümhandel ist die Session die Zeit, in der Anfragen kommen, und damit kein guter Moment für den Wechsel eines wichtigen Bereichs. Bei einem Industriezulieferer sieht die Kurve anders aus. Ich lese sie aus Ihren eigenen Daten, nicht aus einem Branchendurchschnitt.

Foto: Raimond Spekking, CC BY-SA 4.0, Wikimedia Commons.

#Kopfzeile und Navigation aus einem Guss

Für Besucher soll die Website während der Etappen wie eine einzige aussehen. Das ist der aufwendigste Teil, weil zwei Systeme dieselbe Kopfzeile, dieselbe Navigation und denselben Fußbereich ausliefern müssen.

Ich löse das, indem die neue Kopfzeile zuerst im neuen Projekt entsteht und das alte Theme danach so angepasst wird, dass es dieselben Links, dieselbe Reihenfolge und dieselben Stile zeigt. Bei Multi-Zones schlägt Next.js vor, gemeinsamen Code in einem Monorepo oder über npm-Pakete zu teilen. Für ein WordPress-Theme ist das selten möglich, dort pflege ich die Navigation an einer Stelle und übertrage sie in beide Systeme.

Zwei Details aus der Next.js-Doku betreffen genau diese Kopfzeile. Links zu Pfaden einer anderen Zone gehören in ein normales a-Element statt in die Komponente Link, weil Next.js sonst versucht, die Seite vorzuladen und weich zu wechseln, was über Zonengrenzen nicht funktioniert. Und weil Zonen zu unterschiedlichen Zeiten veröffentlicht werden, empfiehlt die Doku Feature-Flags, um Funktionen in allen Zonen gleichzeitig ein- oder auszuschalten.

Auch der Link zum Impressum gehört in beide Varianten. Nach § 5 DDG müssen die Pflichtangaben leicht erkennbar, unmittelbar erreichbar und ständig verfügbar sein, also auch auf Seiten, die noch das alte System ausliefert.

Gestaltung, Entwürfe und Wireframes liefern Sie oder Ihre Agentur. Ich setze sie in beiden Systemen technisch um.

#Analyse ohne Bruch

Google empfiehlt bei einem Umzug, die Nutzung über Webanalyse zu beobachten, und nennt Server-Zugriffsprotokolle und Fehlerprotokolle als zweite Quelle: Crawling durch Googlebot, URLs mit unerwarteten Fehlerstatus und normaler Besucherverkehr. Für Etappen unter einer Domain bedeutet das:

• Ein Messskript, eine Konfiguration. Beide Systeme laden dasselbe Skript mit denselben Einstellungen. Unterschiedliche Versionen erzeugen Sprünge, die wie Erfolg oder Verlust aussehen und keiner sind.
• Ein Merkmal für das System. Jede Seite meldet, ob sie vom alten oder vom neuen System kommt. So vergleiche ich denselben Bereich vor und nach dem Wechsel.
• Dieselbe Einwilligung. Nach § 25 TDDDG ist das Speichern oder Auslesen von Informationen auf dem Endgerät nur mit Einwilligung zulässig, außer es ist unbedingt erforderlich für einen ausdrücklich gewünschten Dienst. Weil beide Systeme unter einer Domain laufen, gilt die gespeicherte Entscheidung aus dem Banner auf beiden Seiten. Das Banner muss dafür in beiden Systemen dieselben Kategorien kennen.
• Search Console nach Seitengruppen. Ich vergleiche Klicks und Impressionen des umgezogenen Bereichs mit einem gleich langen Zeitraum davor und lege die Grenzen der Gruppe vorher fest.

#Der Rückweg für jede Etappe

Eine Etappe ist erst dann klein, wenn sie sich zurücknehmen lässt. Ich schreibe deshalb vor jedem Schritt auf, woran ich ein Problem erkenne und was dann passiert.

Laut Cloudflare-Dokumentation erzeugt ein Rollback sofort eine neue Bereitstellung mit der gewählten Version, die auf allen Routen und Domains aktiv wird.

Damit der Rückweg funktioniert, gilt für die Laufzeit des Projekts:

• Das alte System bleibt betriebsbereit und bekommt weiter Sicherheitsupdates.
• Inhalte eines umgezogenen Bereichs werden nur noch im neuen System gepflegt. Wer im alten System weiter schreibt, erzeugt zwei Wahrheiten.
• Auslöser für den Rückweg sind messbar: Fehlerstatus im Serverprotokoll, ein Formular, das keine Testmail zustellt, oder Seiten, die im Bericht zur Indexierung als ausgeschlossen auftauchen.

Abgeschaltet wird das alte System erst am Ende. Für den Wechsel der Hosting-Infrastruktur formuliert Google das so: abschalten, wenn sicher ist, dass alle Nutzer einschließlich Googlebot ihre Inhalte von der neuen Infrastruktur bekommen und niemand die alte mehr verwendet.

#Datenschutz in Nordrhein-Westfalen während des Parallelbetriebs

Für Unternehmen in Köln ist die Landesbeauftragte für Datenschutz und Informationsfreiheit NRW (LDI NRW) in Düsseldorf zuständig. Sie erklärt auf ihrer Seite zum Verarbeitungsverzeichnis nach Art. 30 DS-GVO, dass Verantwortliche und Auftragsverarbeiter dieses Verzeichnis führen müssen und es der Aufsichtsbehörde auf Anfrage vorzulegen ist.

Ein Parallelbetrieb ändert dort etwas: Für einige Wochen oder Monate gibt es einen Server mehr, der Protokolle schreibt, oft einen zusätzlichen Dienstleister wie ein CDN oder eine Plattform für das neue Frontend, und zwei Wege, auf denen Formulardaten ankommen können. Die LDI NRW weist in ihrem Muster für Datenschutzhinweise darauf hin, dass jede Website personenbezogene Daten für die Bereitstellung und die Protokolldateien verarbeitet und jede Erklärung an den Einzelfall anzupassen ist. Ich liefere Ihnen zu Beginn eine Liste aller Systeme und Dienstleister in der Kette, damit Ihre Datenschutzberatung beides aktualisieren kann.

#Checkliste für einen Umzug in Etappen

#So läuft ein Projekt mit mir

Ich arbeite allein, aus Gdynia, und ausschließlich schriftlich. Sie bekommen keine Termine und keine Videocalls, sondern Dokumente, die Sie weitergeben und prüfen können.

1. Schriftliche Anfrage. Sie schicken mir die Eckdaten (siehe unten). Rückfragen stelle ich schriftlich.
2. Bestandsaufnahme. Ich lese mit Ihrem Zugang Search Console, Hosting und CMS aus und erstelle die Liste der Bereiche mit ihren Adressen.
3. Etappenplan. Ein Dokument mit Reihenfolge, Routing-Stelle, Rückweg und Annahmen für jede Etappe. Was nicht darin steht, gehört nicht zum Umfang.
4. Staging. Jede Etappe läuft zuerst auf einer nicht indexierten Testumgebung mit demselben Routing wie später live.
5. Abnahme und Umschalten. Sie nehmen die Etappe ab, ich schalte um und vergleiche danach die Zahlen.
6. Nach dem letzten Schritt. Auf Wunsch übernimmt die Wartung für Köln Updates und Backups des neuen Systems.

Was ich von Ihnen brauche: Lesezugriff auf die Search Console, Zugang zum Hosting oder zu Cloudflare, die Entwürfe für Gestaltung und Navigation sowie eine Ansprechperson für Inhalte, die Fragen schriftlich beantwortet.

#Häufige Fragen

#Lohnt sich ein Umzug in Etappen für jede Website?

Nein. Ändern sich die URLs, empfiehlt Google für kleine und mittlere Websites, alle Adressen gleichzeitig umzuziehen, und nur großen Websites den Weg Bereich für Bereich. Etappen lohnen sich, wenn die Adressen gleich bleiben und nur das System dahinter wechselt, oder wenn die Website groß genug ist, dass ein Stichtag zu viel auf einmal ändert.

#Sieht Google, dass hinter meiner Domain zwei Systeme laufen?

Ein Rewrite oder Proxy verbirgt das Ziel: Besucher und Crawler bekommen unter derselben Adresse eine Antwort. Entscheidend ist, was in dieser Antwort steht. Ich prüfe deshalb, dass Canonical, interne Links und Sitemap auf beiden Seiten die öffentliche Domain tragen und nie den Hostnamen des alten Servers.

#Brauche ich Weiterleitungen, wenn ein Bereich umzieht?

Nur, wenn sich seine Adressen ändern. Bleiben die URLs gleich, ersetzt der Proxy die Quelle der Antwort, und es gibt nichts weiterzuleiten. Ändern sie sich, setze ich serverseitige permanente Weiterleitungen (301 oder 308), die laut Google mindestens ein Jahr bestehen sollten.

#Wie nehme ich einen Schritt zurück, wenn etwas nicht stimmt?

Jede Etappe ist eine einzelne Routing-Regel. Bei Next.js entferne ich den Eintrag in der Konfiguration und stelle neu bereit, bei Cloudflare rolle ich den Worker auf die vorige Version zurück. Das alte System bleibt dafür bis zum Ende des Projekts betriebsbereit.

#Bleiben meine Zahlen in der Webanalyse vergleichbar?

Ja, wenn beide Systeme dasselbe Messskript mit derselben Einwilligung laden. Weil alles unter einer Domain läuft, gilt die gespeicherte Entscheidung aus dem Einwilligungsbanner auf beiden Seiten. Ich ergänze ein Merkmal, das zeigt, welches System die Seite ausgeliefert hat.

#Was ändert sich beim Datenschutz, solange beide Systeme laufen?

Es gibt für die Zeit des Parallelbetriebs mindestens einen Server mehr, der Protokolldaten schreibt, und oft einen zusätzlichen Dienstleister in der Kette. Beides gehört in Ihr Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 DS-GVO und in die Datenschutzhinweise.

#Schreiben Sie mir, welcher Bereich zuerst umziehen soll

Wenn Ihre Website zu groß für einen Wechsel an einem Tag ist oder Sie das Risiko lieber in kleine Stücke teilen, schreiben Sie mir über die Kontaktseite. Hilfreich sind die Adresse der Website, das heutige System mit Version, wo Domain und DNS liegen, Ihr Ziel, ein gewünschter Termin und der Bereich, bei dem Sie anfangen möchten. Die erste schriftliche Einschätzung ist kostenlos und enthält einen Vorschlag für die Reihenfolge der Etappen. Mehr zur Wahl zwischen den Frameworks steht auf der Seite zur Migration zu Astro und Next.js und im Leitfaden zur Website-Migration. Wechseln bei Ihnen auch die Adressen, beschreibt die Seite für Bremen den Weiterleitungsplan; zu den Frameworks selbst finden Sie die Seiten Next.js in Köln und Astro in Köln.