Migration zu Next.js / Astro in Stuttgart

Viele Unternehmen in Stuttgart und im Umland betreiben nicht eine Website, sondern mehrere: eine pro Marke, pro Tochtergesellschaft, pro Produktlinie oder pro Land. Manchmal ist das eine WordPress-Multisite, manchmal sind es fünf getrennte Installationen bei drei Hostern, jede mit eigenem Theme und eigenem Update-Stand. Ich führe solche Bestände in eine Codebasis mit Astro oder Next.js zusammen. Komponenten, Formularlogik und Barrierefreiheit pflege ich danach einmal, Inhalte, Domains und Pflichtangaben bleiben pro Website getrennt. Ich arbeite allein, von Gdynia aus und ausschließlich schriftlich.

Foto: Felix König, CC BY 3.0, Wikimedia Commons.

#Warum in Baden-Württemberg so oft Länder-Websites entstehen

Das Statistische Landesamt meldet für das erste Halbjahr 2026 nach vorläufigen Ergebnissen die USA als wichtigstes Zielland der Ausfuhren aus Baden-Württemberg, dahinter die Schweiz, Frankreich, die Niederlande und das Vereinigte Königreich (Pressemitteilung vom 24.08.2026). Das Vereinigte Königreich erreichte damit laut Landesamt den höchsten Rang seit 2015.

Wer in diese Märkte liefert, hat auf der Website meist mehr als eine deutsche Fassung. Typisch ist eine .ch-Domain für Schweizer Kunden, eine französische Fassung und eine englische, die gleichzeitig Großbritannien und die USA bedienen soll. Dazu kommen Marken, die nach einer Übernahme ihre alte Domain behalten haben. Jede dieser Websites wurde irgendwann von jemand anderem gebaut. Gemeinsam ist ihnen oft nur, dass niemand mehr weiß, welches Kontaktformular an welches Postfach schreibt.

#Bestandsaufnahme: was heute unter welcher Domain läuft

Bevor ich über Frameworks rede, lege ich eine Tabelle an, eine Zeile pro Domain. Sie können sie auch ohne mich ausfüllen:

Die letzte Spalte entscheidet über den Aufwand. Eine Website, die ihre Domain behält und nur das System wechselt, ist ein Austausch hinter derselben Adresse. Eine Website, die in eine andere Domain aufgeht, ist ein Umzug mit eigener Weiterleitungskarte.

#Was beim Export aus einer WordPress-Multisite anders ist

Die Dokumentation beschreibt eine Multisite als mehrere WordPress-Instanzen, die in einer Installation verwaltet werden. Als typischen Einsatz nennt sie ausdrücklich Unternehmen, die Theme oder Erweiterungen teilen und für ihre Regionen unterschiedliche Inhalte pflegen (developer.wordpress.org). Für den Export zählen vier Eigenschaften:

• Getrennte Tabellen, gemeinsame Benutzer. Jede Website hat eigene Tabellen in der Datenbank. Nur die Benutzertabelle teilen sich alle.
• Getrennte Medien. Die Websites haben keine eigenen Verzeichnisse auf dem Server, aber jeweils ein eigenes Upload-Verzeichnis innerhalb der gemeinsamen Installation (Create A Network).
• Erweiterungen pro Website. Jede Website kann Themes und Plugins aktivieren, aber keine installieren. Dieselbe Installation enthält also Erweiterungen, die nur auf einer einzigen Website laufen.
• Pfade oder Domains. Ein Netzwerk arbeitet mit Unterverzeichnissen oder mit Domains und Subdomains. Seit WordPress 4.5 ist die Zuordnung einer eigenen Domain eingebaut: Sie steht im Feld für die Website-Adresse der jeweiligen Website (Domain Mapping).

Mit WP-CLI hole ich mir zuerst die Liste. wp site list zeigt standardmäßig blog_id, url, last_updated und registered, auf Wunsch auch domain, path, public und archived (wp site list). Archivierte Websites fallen so sofort auf, und Sie entscheiden, ob sie mitkommen oder nur eine Weiterleitung bekommen.

Exportiert wird Website für Website. wp export schreibt WXR-Dateien mit Autoren, Begriffen, Beiträgen, Kommentaren und Anhängen, aber ohne Website-Einstellungen und ohne die Mediendateien selbst. In einer Multisite wählt der globale Parameter --url die Website aus (wp export). Die Mediendateien kopiere ich getrennt aus dem jeweiligen Upload-Verzeichnis. Wie ich WXR, REST API und Shortcodes im Einzelnen behandle, steht auf der Seite für Essen.

Bei den Benutzern liegt die Falle. wp user list --network listet alle Konten des Netzwerks, aber ohne Rollen, weil dieselbe Person auf jeder Website eine andere Rolle haben kann (wp user list). Eine Redakteurin der Schweizer Website ist auf der deutschen vielleicht nur Abonnentin. Ich lese die Rollen deshalb pro Website aus und lege daraus fest, wer im neuen Redaktionssystem welche Website bearbeiten darf.

#Eine Codebasis, mehrere Websites: drei Aufbauten

Welcher Aufbau passt, hängt davon ab, wie ähnlich die Websites sind und ob sie auf dem Server gerendert werden müssen.

#Monorepo mit Workspaces

Jede Website ist eine eigene Anwendung, die gemeinsamen Teile liegen als Pakete daneben. npm unterstützt das mit Workspaces: Die Pakete werden im Feld workspaces der obersten package.json eingetragen und bei npm install verlinkt. Befehle laufen gezielt in einem Paket oder in allen, etwa mit npm run test --workspaces (npm Docs). Ein Paket mit Kopfzeile, Fußzeile, Formularen und Produktkarten nutzen dann alle Websites, jede Anwendung hat aber ihren eigenen Build und ihre eigene Bereitstellung. Das passt, wenn sich die Websites im Aufbau deutlich unterscheiden, etwa ein Shop-Frontend in Next.js neben drei statischen Markenseiten in Astro.

#Eine Next.js-Anwendung für mehrere Domains

Rewrites und Redirects in next.config.js kennen die Bedingung has, und einer ihrer Typen ist host (Rewrites, Redirects). Eine Regel greift damit nur für Anfragen an einen bestimmten Hostnamen. So bedient eine Anwendung mehrere Domains, und jede Domain bekommt ihren eigenen Bereich im Projekt. Rewrites in beforeFiles werden geprüft, bevor Next.js Dateien und Routen sucht.

Für Entscheidungen, die sich erst zur Laufzeit ergeben, gibt es die Datei proxy.ts. Sie hieß bis Next.js 16 middleware.ts. Die Next.js-Dokumentation empfiehlt Rewrites, weil sie weniger Latenz kosten, und den Proxy nur für dynamisches Routing, etwa hinter einem Feature-Flag während einer Migration (Multi-Zones, proxy.js). Ich halte mich daran: Die Zuordnung von Domain zu Website steht als Regel in der Konfiguration, nicht als Code im Proxy.

Der Preis dieses Aufbaus ist eine gemeinsame Bereitstellung. Ein Fehler in einer geteilten Komponente erscheint auf allen Domains gleichzeitig. Ich setze deshalb auf eine Testumgebung, die jede Domain einzeln durchspielt, bevor etwas live geht.

Multi-Zones lösen eine andere Aufgabe: Sie teilen eine einzige Domain nach Pfaden auf mehrere Anwendungen auf. Das beschreibt die Seite für Köln.

#Ein Astro-Projekt mit einem Build pro Website

Für statische Websites baue ich aus einem Astro-Projekt mehrere Ausgaben. astro build kennt den Parameter --mode und lädt dann die passende Datei, zum Beispiel .env.marke-b (Umgebungsvariablen). Eine Hürde nennt die Dokumentation selbst: Astro wertet die Konfiguration aus, bevor es andere Dateien lädt, deshalb steht import.meta.env in astro.config.mjs nicht zur Verfügung. Dort liest loadEnv aus Vite die Werte ein. Aus ihnen setze ich site, aus der Astro Sitemap und Canonical-URLs erzeugt, und outDir, damit jede Website in ein eigenes Verzeichnis gebaut wird (Konfigurationsreferenz). Jede Ausgabe geht danach auf ihre eigene Domain. Getrennte Builds bedeuten getrennte Fehler: Ein Problem in den Inhalten der Marke B hält die Marke A nicht auf.

#Was pro Website getrennt bleibt

Eine gemeinsame Codebasis ist kein gemeinsamer Inhalt. Pro Website liegt bei mir eine Einstellungsdatei mit Domain, Sprache, Navigation, Impressumsangaben, Link zu den Datenschutzhinweisen, Empfänger der Formulare, Konto für die Messung und Logo. Farben und Gestaltung kommen aus Ihren Vorlagen oder von Ihrer Agentur, ich setze sie um.

Die Inhalte jeder Website liegen in einem eigenen Ordner oder in einem eigenen Bereich des Redaktionssystems. Gemeinsam sind nur Bausteine, die auf allen Websites gleich funktionieren: Layout, Formulare, Barrierefreiheit, Bilder, Cookie-Einwilligung als Mechanismus. Was der Banner anzeigt und welche Dienste er freischaltet, bleibt wieder Einstellung der jeweiligen Website.

#Länder-Websites: eigene Domain oder Unterverzeichnis?

Beim Zusammenführen stellt sich die Frage, ob example.ch eine eigene Domain bleibt oder zu example.com/ch/ wird. Google stellt die Optionen in einer Tabelle gegenüber (Websites für mehrere Regionen):

• Länderdomain wie example.de: klare Zuordnung zum Land, Serverstandort egal, Websites leicht zu trennen. Dafür mehr Infrastruktur, je nach Land strenge Vergaberegeln, und sie zielt nur auf ein Land.
• Subdomain wie de.example.com: einfach einzurichten, verschiedene Serverstandorte möglich. Nutzer erkennen aber nicht, ob “de” die Sprache oder das Land meint.
• Unterverzeichnis wie example.com/de/: einfach einzurichten und wenig Pflege, weil alles auf einem Host liegt. Dafür ein Serverstandort und eine schwierigere Trennung.
• URL-Parameter wie ?loc=de: empfiehlt Google nicht.

Für die Codebasis heißt das: Länderdomains passen gut zu einem Build pro Website. Astro bietet zwar i18n.domains, um Sprachen auf eigene Domains zu legen, aber nur für serverseitig gerenderte Projekte mit dem Node- oder Vercel-Adapter und ohne vorgerenderte Seiten (Astro i18n). Für eine statische Website ist der getrennte Build der einfachere Weg.

Bleiben die Länderfassungen auf verschiedenen Domains, verbinden hreflang-Angaben sie trotzdem. Google verlangt, dass jede Fassung sich selbst und alle anderen nennt, und die alternativen URLs müssen nicht auf derselben Domain liegen (Lokalisierte Versionen). In einer gemeinsamen Codebasis erzeuge ich diese Angaben aus einer Tabelle, die jede Seite ihren Gegenstücken auf den anderen Domains zuordnet. Wie ich das für Deutsch, Französisch und Englisch aufbaue, steht auf der Seite für Basel.

#Weiterleitungen auf Domain-Ebene

Google zählt das Zusammenlegen mehrerer Domains oder Hostnamen ausdrücklich zu den Website-Umzügen mit geänderten URLs. Daraus folgen drei Regeln aus dem Leitfaden: jede alte URL auf ihr Gegenstück leiten, Inhalte ohne Gegenstück mit 404 oder 410 beantworten, und die Weiterleitungen so lange wie möglich halten, in der Regel mindestens ein Jahr. Permanente serverseitige Weiterleitungen mit 301 oder 308 sind laut Google der beste Weg (Weiterleitungen).

Wo die Regel steht, hängt vom Aufbau ab:

• Next.js: Zeigt die alte Domain auf dieselbe Anwendung, leitet ein Redirect mit has und dem Typ host sie um. permanent: true erzeugt dabei den Status 308.
• Astro statisch: Ohne Adapter erzeugt die Option redirects nur eine Weiterleitung per Meta-Refresh ohne Statuscode. Die Weiterleitung einer ganzen Domain gehört deshalb zum Hoster oder zum DNS-Anbieter, nicht ins Astro-Projekt.

Die Search Console hilft nur zum Teil. Das Adressänderungstool arbeitet auf Domain- oder Subdomain-Ebene, nicht für Pfade wie example.com/marke/. Es nimmt auch keine Subdomains unterhalb der angegebenen Domain mit, www eingeschlossen. War eine Marke in einer Multisite nur ein Unterverzeichnis, tragen allein die Weiterleitungen den Umzug. Google rät, alle Varianten der alten und neuen Websites zu bestätigen. Wie ich die Karte aus Sitemap, Crawl und Search Console baue und vor dem Start teste, steht auf der Seite für Bremen.

#Impressum und Datenschutz, wenn mehrere Gesellschaften eine Plattform teilen

Eine gemeinsame Codebasis ändert nichts daran, wer Diensteanbieter ist. § 5 DDG verlangt von jedem Anbieter geschäftsmäßiger digitaler Dienste unter anderem Name und Anschrift, bei juristischen Personen Rechtsform und Vertretungsberechtigte, leicht erkennbar und unmittelbar erreichbar (gesetze-im-internet.de). Betreiben eine GmbH in Stuttgart und eine AG in der Schweiz je eine der Websites, stehen im Impressum zwei verschiedene Anbieter. Im Projekt ist das eine Einstellung pro Website.

Beim Datenschutz lohnt eine Frage vor dem Start: Wer entscheidet über die Plattform? Der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden-Württemberg schreibt in seinen FAQ zur Abgrenzung der Verantwortlichkeiten, dass eine gemeinsame Verantwortlichkeit auch dann bestehen kann, wenn ein Unternehmen ein System bereitstellt und andere es nutzen und über Einrichtung oder Einstellungen entscheiden. Entscheidend sei, ob die Nutzer so einen ausschlaggebenden Einfluss auf die Verarbeitung haben (LfDI BW). In seinen Praxishilfen stellt er eine Word-Vorlage für eine Vereinbarung nach Art. 26 Abs. 1 S. 1 DS-GVO bereit. Ob das auf Ihre Gruppe zutrifft, klärt Ihre Datenschutzberatung. Ich liefere ihr die Liste, welche Gesellschaft welche Einstellungen ändern kann und wohin jedes Formular schreibt.

#Ablauf, wenn Sie mich beauftragen

1. Schriftliche Anfrage mit der Domainliste. Rückfragen stelle ich per E-Mail.
2. Bestandsaufnahme. Mit Lesezugriff auf WordPress, Hosting und Search Console fülle ich die Tabelle oben vollständig aus, inklusive Website-IDs, Rollen und aktiver Erweiterungen pro Website.
3. Schriftlicher Umfang. Ein Dokument mit Aufbau (Monorepo, eine App oder ein Build pro Website), Reihenfolge der Websites, Weiterleitungskarte pro Domain und Annahmen. Was dort nicht steht, gehört nicht zum Auftrag.
4. Staging. Jede Website läuft zuerst auf einer nicht indexierten Testadresse, mit ihren eigenen Einstellungen.
5. Abnahme und Umstellung pro Domain. Sie nehmen eine Website ab, ich stelle ihre Domain um und prüfe die Weiterleitungen.
6. Danach. Sie bekommen Repository, Umgebungsvariablen und Bereitstellung. Auf Wunsch übernimmt die Wartung für Stuttgart Updates und Kontrollen.

Was ich von Ihnen brauche: Zugänge, die Gestaltungsvorlagen pro Marke, eine Ansprechperson pro Website für inhaltliche Fragen und die Entscheidung, welche Domains bleiben.

#Checkliste vor dem Zusammenführen

• Liste aller Domains mit allen Varianten, einschließlich vergessener Subdomains.
• Pro Website: Betreiber, Sprache, Zielland, Formularempfänger, Messung.
• Bei einer Multisite: wp site list mit archived und public, Rollen pro Website, aktive Erweiterungen pro Website.
• Entscheidung pro Domain: bleibt, wird Unterverzeichnis oder entfällt.
• Weiterleitungskarte für jede Domain, die nicht bleibt, und eine 404- oder 410-Liste für Inhalte ohne Gegenstück.
• Alle Varianten in der Search Console bestätigt, bevor die erste Domain umzieht.
• Impressum und Datenschutzhinweise pro Website geprüft, Verantwortlichkeiten mit der Datenschutzberatung geklärt.

#Häufige Fragen

#Muss ich alle Websites am selben Tag umstellen?

Nein. Die gemeinsame Codebasis nimmt eine Website nach der anderen auf. Jede Domain zeigt so lange auf das alte System, bis ihre Fassung im neuen Projekt abgenommen ist. Erst dann stelle ich DNS und Weiterleitungen für genau diese Domain um.

#Behalten meine Marken ihre eigenen Domains?

Ja, wenn Sie das wollen. In Next.js binde ich Regeln an den Hostnamen, in Astro baue ich pro Domain eine eigene Ausgabe aus demselben Projekt. Ob einzelne Domains später in Unterverzeichnisse einer Hauptdomain wandern, ist eine eigene Entscheidung mit eigener Weiterleitungskarte.

#Was passiert mit den Benutzerkonten aus der WordPress-Multisite?

Alle Websites eines Netzwerks teilen sich eine Benutzertabelle, die Rollen gelten aber pro Website. wp user list --network zeigt deshalb alle Konten ohne Rollen. Ich lese die Rollen Website für Website aus und lege danach fest, wer im neuen Redaktionssystem was darf.

#Brauche ich das Adressänderungstool der Search Console?

Nur, wenn eine Domain oder Subdomain vollständig in eine andere umzieht. Für Pfade wie example.com/marke/ funktioniert das Tool nicht, und es nimmt keine Subdomains unterhalb der angegebenen Domain mit, auch nicht www. Dort tragen allein die Weiterleitungen den Umzug.

#Wie lange müssen die alten Domains weiterleiten?

Google rät, Weiterleitungen so lange wie möglich zu behalten, in der Regel mindestens ein Jahr. Ich empfehle, die alten Domains registriert zu lassen und die Weiterleitungen dauerhaft stehen zu lassen, weil externe Links auf sie oft noch Jahre später auftauchen.

#Braucht jede Marke ein eigenes Impressum?

Wenn verschiedene Gesellschaften die Websites betreiben, ja: § 5 DDG verpflichtet jeden Diensteanbieter zu eigenen Angaben. In der gemeinsamen Codebasis sind Impressum und Datenschutzhinweise deshalb Einstellungen pro Website und keine gemeinsame Komponente mit festem Text.

#Schreiben Sie mir zu Ihren Websites

Wenn bei Ihnen mehrere Websites nebeneinander gewachsen sind und Sie sie in eine Codebasis bringen möchten, schreiben Sie mir über die Kontaktseite. Am meisten hilft mir die Liste Ihrer Domains, das System hinter jeder davon, welche Domains bleiben sollen, Ihr Ziel und ein gewünschter Termin. Die erste schriftliche Einschätzung ist kostenlos und enthält einen Vorschlag für den Aufbau und die Reihenfolge der Websites. Zu den Frameworks selbst finden Sie die Seiten Next.js in Stuttgart und Astro in Stuttgart, zur Wahl zwischen beiden die Seite zur Migration zu Astro und Next.js.