Astro mehrsprachig: zwei Domains, zwei Sprachen, ein Build

Unsere Website gibt es in zwei Sprachen, und zwar nicht unter /en/, sondern auf zwei Domains: Deutsch auf codeaeffchen.de, Englisch auf codeaeffchen.com. Beides entsteht aus einem einzigen Astro-Projekt und einem einzigen Build. Das klingt nach einer Kleinigkeit, ist aber eine der Stellen, an denen Astro bei statischen Websites aufhört – und an denen man viel falsch machen kann, ohne dass es sofort jemand merkt.

Dieser Artikel zeigt, wann zwei Domains sinnvoll sind, was Astro dafür mitbringt, wo es aufhört und wie wir die Lücke schließen. Die Lösung haben wir als Open-Source-Integration veröffentlicht.

Eigene Domain oder Unterverzeichnis?

Bevor es um Technik geht, die eigentliche Entscheidung. Google beschreibt in seiner Anleitung zu mehrsprachigen und länderspezifischen Websites (Google Search Central) drei gangbare Wege: Unterverzeichnisse wie example.com/en/, Subdomains wie en.example.com und eigene Domains wie example.de und example.com. Keiner davon ist per se falsch.

Die Unterschiede liegen woanders:

• Unterverzeichnis: einfach, eine Domain, alle Signale gebündelt. Für ein internationales Publikum wirkt eine .de-Adresse mit /en/ aber nicht wie ein Anbieter, der dort zu Hause ist.
• Eigene Domain je Sprache oder Markt: Eine Länder-Domain ist ein starkes Signal für den Zielmarkt und wirkt auf Besucher vertraut. Der Preis: Jede Domain baut ihre Autorität getrennt auf, und Analyse, Search Console und Weiterleitungen gibt es doppelt.

Wir haben uns für zwei Domains entschieden, weil die englische Seite für sich stehen soll – mit eigener Adresse, eigenen URLs auf Englisch (/services/ statt /leistungen/) und eigener Messung. Für viele Unternehmenswebsites ist das Unterverzeichnis die einfachere und völlig ausreichende Wahl.

Was Astro mitbringt – und wo es aufhört

Astro hat eine eingebaute Mehrsprachigkeit: Sprachen, Standardsprache und Pfad-Präfixe lassen sich konfigurieren, Hilfsfunktionen erzeugen die passenden URLs. Für Unterverzeichnisse reicht das vollständig.

Für eigene Domains gibt es die Option i18n.domains. Sie hat aber eine Bedingung, die in der Astro-Dokumentation ausdrücklich steht: Sie setzt eine Server-Ausgabe voraus, ohne vorab gerenderte Seiten. Eine rein statische Website – genau das, was Astro bei Marketing-Sites, Unternehmensauftritten und Blogs so stark macht – kann diese Option nicht nutzen.

Bleibt die Frage: Wie kommen die Seiten einer statischen Website auf zwei Domains?

Ein Build, zwei Domains

Unser Ansatz: Astro baut die Website ganz normal – Deutsch im Wurzelverzeichnis, Englisch unter /en/. Danach verteilt ein zusätzlicher Schritt die Ausgabe auf einen Ordner je Domain. Was dabei passieren muss, ist mehr als Dateien kopieren:

1. Gemeinsame Dateien wie Stylesheets, Skripte, Bilder und Schriften landen in beiden Ordnern, damit jede Domain für sich vollständig ist.
2. Links verlieren auf der englischen Domain das /en/-Präfix: aus /en/contact/ wird /contact/.
3. Absolute Adressen – Canonical, hreflang, Open Graph, strukturierte Daten – zeigen auf die richtige Domain.
4. Sitemaps enthalten je Domain nur deren eigene Seiten, unter deren eigener Adresse.
5. robots.txt verweist auf die jeweils richtige Sitemap.
6. Die Fehlerseite liegt dort, wo der Webserver sie erwartet.
7. Weiterleitungen in der .htaccess gelten nur für die Domain, zu der sie gehören.

Bei uns läuft dieser Schritt bei jedem Deploy und verteilt über 400 Seiten. Wir prüfen ihn mit einem einfachen Maßstab: Er muss aus einem frischen Build exakt dieselben Dateien erzeugen wie zuvor – Datei für Datei.

Was wir dabei gelernt haben

Die meisten Fehler bei zwei Domains sind still: Die Seite sieht richtig aus, nur Suchmaschinen bekommen widersprüchliche Signale. Einige davon haben wir selbst erst spät gefunden.

Canonicals von Weiterleitungs-Seiten. Bei umgezogenen URLs erzeugt Astro kleine Weiterleitungsseiten. Deren Canonical entstand aus der Standard-Domain plus /en/ – also eine Adresse, die es nach dem Aufteilen gar nicht gibt. Aufgefallen ist das erst beim Abgleich aller Dateien vor und nach dem Umstieg auf die Integration; sie schreibt beide Schreibweisen um.

Seitenpaare mit unterschiedlichen Adressen. Unser Glossar hat dieselben 69 Begriffe in beiden Sprachen, aber unter verschiedenen Adressen: /glossar/dsgvo/ auf Deutsch, /glossary/gdpr/ auf Englisch. Eine automatische Pfad-Übersetzung findet solche Paare nicht. Ergebnis: Die Seiten waren einen Monat lang nicht per hreflang verknüpft, und der Sprachumschalter führte nur zur Übersicht. Die Lösung ist eine echte Zuordnung der Paare – abgesichert durch einen Test, der abbricht, sobald die Listen auseinanderlaufen.

Dateien, die jede Sprache selbst hat. Manche Dateien liegen im Wurzelverzeichnis, gehören aber zu einer Sprache – bei uns die llms.txt für KI-Systeme. Würde der Verteilschritt sie stumpf kopieren, bekäme die englische Domain die deutsche Fassung.

Alles drumherum gibt es doppelt. Zwei Domains heißen zwei Properties in der Search Console, zwei Sites in der Webanalyse und Weiterleitungen in zwei Formen. Wer das von Anfang an einplant, spart sich später das Rätseln, warum eine Sprache in den Berichten fehlt.

Die Integration nutzen

Den Verteilschritt haben wir als Astro-Integration veröffentlicht: @codeaeffchen/astro-split-domains, Quellcode und Dokumentation auf GitHub, MIT-Lizenz. Eingebunden wird sie in der Astro-Konfiguration – nach der Sitemap, damit deren Ausgabe mit aufgeteilt wird:

import sitemap from '@astrojs/sitemap';
import splitDomains from '@codeaeffchen/astro-split-domains';

export default defineConfig({
  site: 'https://example.de',
  integrations: [
    sitemap(),
    splitDomains({
      enabled: process.env.SPLIT_DOMAINS === '1',
      defaultLocale: { code: 'de', site: 'https://example.de' },
      locales: [{ code: 'en', site: 'https://example.com' }],
    }),
  ],
});

Ein Build mit SPLIT_DOMAINS=1 erzeugt dist/de/ und dist/en/, die jeweils auf ihre Domain hochgeladen werden. Ohne die Variable bleibt die Ausgabe flach – praktisch für die lokale Vorschau und für Prüfungen, die das ganze Projekt sehen sollen.

Die Integration rät nicht: Fehlt ein Sprachordner oder ist die .htaccess nur halb markiert, bricht der Build ab, statt eine kaputte Domain auszuliefern. hreflang-Angaben erzeugt sie bewusst nicht selbst – die gehören in die Seiten, weil nur dort bekannt ist, welche Seite welches Gegenstück hat.

Wie unsere eigene Website darüber hinaus aufgebaut ist und was vor jeder Änderung geprüft wird, steht in der Case Study zu codeaeffchen.de.

---

Du planst eine mehrsprachige Astro-Website – oder willst eine bestehende Seite in mehreren Sprachen auf Astro umziehen? Wir sagen dir, ob eigene Domains für deinen Fall lohnen oder ob ein Unterverzeichnis reicht. Schreib uns kurz.