#lessonlearned – Multi-Domain-Architektur mit zentraler site-config in Nuxt

Wenn viele Websites mit unterschiedlichen Domains, Sprachen und Einstellungen auf einer gemeinsamen technischen Grundlage betrieben werden sollen, steigt die Komplexität schnell an. In unserem Projekt ging es darum, mehr als 30 Websites in einer einzigen Nuxt-Anwendung abzubilden und trotzdem pro Land oder Markt flexibel auf unterschiedliche Anforderungen reagieren zu können. In diesem Lesson Learned zeigen wir, wie wir dafür eine zentrale site-config aufgebaut haben und warum dieser Ansatz für uns besonders gut funktioniert hat.

Warum eine zentrale Konfiguration sinnvoll ist

Die einzelnen Websites unterscheiden sich in unserem Fall unter anderem bei folgenden Punkten:

• Domain

• Sprachen

• Google-Tag-Manager-Codes

• Umgebung, zum Beispiel Produktion oder Entwicklung

• aktivierte Funktionen je nach Markt

Gleichzeitig sollte der Code nicht für jede Website einzeln gepflegt oder separat bereitgestellt werden. Ziel war stattdessen eine zentrale Anwendung, die abhängig von der aufgerufenen Domain erkennt, welche Website gerade ausgeliefert werden soll.

Ohne eine saubere Konfigurationsschicht würde diese Logik früher oder später an vielen Stellen im Code verteilt landen. Genau das wollten wir vermeiden.

Unser Ansatz: eine zentrale site-config für alle Websites

Die zentrale Idee war, alle relevanten Informationen an einer Stelle zusammenzuführen. Dafür nutzen wir eine zentrale Konfigurationsdatei, in der die Zuordnung von Website, Domain, Sprache und Umgebung hinterlegt ist.

Ein vereinfachtes Beispiel sieht so aus:

{
  "sites": {
    "corporate-page-global": {
      "rootId": 438549830,
      "gtmCode": "GTM-...",
      "domains": {
        "www.baywa-re.com": {
          "stage": "production",
          "rootSlug": "corporate-page-global"
        }
      },
      "languages": {
        "en": { "language": "en", "hreflang": "en", "active": true },
        "de": { "language": "de", "hreflang": "de", "active": true }
      }
    },
    "country-page-fr": {
      "domains": {
        "www.baywa-re.fr": {
          "stage": "production",
          "rootSlug": "country-page-fr"
        }
      },
      "languages": {
        "en": { "language": "en", "hreflang": "en-FR", "active": true },
        "fr": { "language": "fr", "hreflang": "fr-FR", "active": true }
      }
    }
  }
}

Damit ist zentral definiert, welche Domain zu welcher Website gehört, welche Sprachen aktiv sind und in welcher Umgebung die Domain betrieben wird.

Domain beim Request erkennen und passende Konfiguration laden

Damit die Anwendung mit dieser Struktur arbeiten kann, wird die Domain direkt beim Request ausgewertet. Ein vorgeschaltetes Nuxt-Plugin liest Hostname, Sprache und Umgebung aus und baut daraus die aktuelle site-config für den Request auf.

Ein vereinfachter Ausschnitt sieht so aus:

// app/plugins/site-config.server.ts
const domain = requestUrl.hostname
const stage = getStageByDomain(domain)
const rootSlug = getRootFolderSlugByDomain(domain)
const locale = extractLocaleFromPath(requestUrl.pathname)

const siteConfig = {
  url: `${requestUrl.protocol}//${requestUrl.host}`,
  stage,
  rootSlug,
  currentLocale: locale
}

updateSiteConfig(siteConfig)

So weiß die Anwendung schon sehr früh, in welchem Kontext sie sich befindet. Alle weiteren Prozesse – vom Laden der Inhalte bis zur Ausgabe von SEO-Daten – können darauf aufbauen.

Inhalte in Storyblok sauber trennen

Ein wichtiger Bestandteil dieses Ansatzes ist die klare Trennung der Inhalte in Storyblok. Jede Website erhält dort einen eigenen Root-Ordner. Alle Anfragen werden automatisch relativ zu diesem Root-Slug gestellt.

const stories = await fetchStory('cdn/stories', {
  slug: `${siteConfig.rootSlug}/${siteConfig.currentLocale}/${pageSlug}`,
  version: config.storyblokVersion
})

Dadurch können mehrere Websites mit derselben Codebasis arbeiten, ohne dass Inhalte versehentlich vermischt werden. Die Domain entscheidet, welcher Root-Ordner verwendet wird, und damit auch, welche Inhalte überhaupt geladen werden.

Mehrsprachigkeit und SEO gleich mitdenken

Da die Sprachen ebenfalls zentral in der site-config hinterlegt sind, lassen sich auch SEO-relevante Angaben wie hreflang strukturiert verwalten.

Das ist besonders wichtig, wenn dieselbe Sprache in verschiedenen Märkten unterschiedlich ausgespielt wird. Englisch auf einer globalen Website ist aus SEO-Sicht etwas anderes als Englisch auf einer länderspezifischen Website für Frankreich.

Durch die gepflegten hreflang-Werte können Suchmaschinen die Sprach- und Länderversionen sauber voneinander unterscheiden und die jeweils passende Seite ausspielen.

Gleiches System für mehrere Umgebungen

Ein weiterer Vorteil der zentralen site-config ist die einfache Abbildung verschiedener Umgebungen. Eine Website kann bei uns nicht nur in der Produktion existieren, sondern auch in Vorstufen oder in der lokalen Entwicklung.

Zum Beispiel:

• Produktion

• Vorproduktionsumgebung

• Integrationsumgebung

• lokale Entwicklungsumgebung

Der Code bleibt dabei identisch. Die Domain entscheidet, in welcher Umgebung sich die Anwendung befindet und welche Einstellungen dafür gelten. So kann zum Beispiel gesteuert werden, ob Inhalte aus dem veröffentlichten Stand oder aus dem Entwurfsmodus geladen werden.

Was sich für uns bewährt hat

Im Projekt hat sich vor allem gezeigt, dass eine zentrale site-config nicht nur technisch hilfreich ist, sondern auch organisatorisch.

Weniger Sonderlogik im Code

Wenn Domains, Sprachen und Umgebungen zentral gepflegt werden, muss diese Logik nicht an mehreren Stellen in Komponenten, Middleware oder API-Aufrufen nachgebaut werden.

Bessere Skalierbarkeit bei neuen Websites

Neue Websites lassen sich deutlich einfacher ergänzen, weil in vielen Fällen nur die Konfiguration erweitert werden muss. Die technische Grundlage bleibt gleich.

Klare Trennung der Inhalte

Durch die Struktur in Storyblok und die Zuordnung über Root-Ordner bleibt sauber nachvollziehbar, welche Inhalte zu welcher Website gehören.

Unser wichtigstes Learning

Unser wichtigstes Learning war, dass eine Multi-Domain-Architektur mit vielen Websites nur dann langfristig wartbar bleibt, wenn Domainlogik, Sprachkonfiguration und Umgebungssteuerung konsequent zentralisiert werden.

Die site-config hat sich für uns dabei als saubere Grundlage erwiesen. Sie reduziert Sonderfälle im Code, erleichtert neue Rollouts und sorgt dafür, dass Inhalte in Storyblok klar voneinander getrennt bleiben. Gerade bei einer größeren internationalen Plattform mit vielen Märkten und Sprachen ist das ein entscheidender Vorteil.