Die Herausforderung
Die meisten mehrsprachigen Websites machen eines von drei Dingen falsch: Duplicate-Content-Flags durch fehlende hreflang-Tags, verwaiste Seiten durch unvollständige reziproke Links oder Schema, das Sprache komplett ignoriert. Wishfy brauchte eine viersprachige Website (Englisch, Niederländisch, Deutsch, Französisch), die alle drei von Tag eins richtig macht — nicht als Nachrüstung, sondern als zentrale architektonische Entscheidung.
Die Einschränkung: eine einzige Domain (`wishfy.ai`), keine Subdomains, keine Ländercode-TLDs. Alles lebt unter Subdirectories: `/en/`, `/nl/`, `/de/`, `/fr/`.
Subdirectory-Strategie
Subdirectories schlagen Subdomains für mehrsprachiges SEO, wenn Sie Domain-Autorität von Grund auf aufbauen. Alle Link-Equity fließt zu einer Domain. Das gesamte Crawl-Budget bleibt in einer Property. Google Search Console zeigt eine einheitliche Ansicht.
Die Routing-Schicht nutzt Astros dynamischen `[lang]`-Parameter. Jede Seitenroute beginnt mit `[lang]/` — Services, Work, Blog, Legal. Die Root `/` leitet zur Standard-Locale (`/en/`) weiter. Kein Content existiert außerhalb eines Sprach-Subdirectory.
hreflang-Implementierung
Jede Seite gibt einen vollständigen Satz hreflang-`<link>`-Tags im `<head>` aus — einen für jede Sprache, in der die Seite existiert, plus ein `x-default`, das auf die englische Version zeigt. Die Implementierung nutzt den `translationKey` jedes Content-Eintrags, um seine Entsprechungen über Locales hinweg zu finden.
Reziprozität wird zur Build-Zeit erzwungen: Wenn `/en/services/seo` eine niederländische Alternative deklariert, muss `/nl/services/seo` die englische Alternative zurück deklarieren. Gebrochene Reziprozität ist der häufigste hreflang-Fehler, und wir fangen ihn vor dem Deployment ab.
Die hreflang-Tags nutzen vollständige URLs mit der kanonischen Domain — `https://wishfy.ai/nl/services/seo`, keine relativen Pfade. Googles Dokumentation ist eindeutig: hreflang-Werte müssen vollständig qualifiziert sein.
Sprachspezifische Sitemaps
Die Website generiert fünf Sitemaps: eine pro Sprache (`sitemap-en.xml`, `sitemap-nl.xml`, `sitemap-de.xml`, `sitemap-fr.xml`) plus einen Sitemap-Index (`sitemap-index.xml`), der alle vier referenziert. Jede Sprach-Sitemap enthält nur URLs für diese Locale, mit `<xhtml:link>`-Alternates, die auf die anderen Sprachversionen zeigen.
Diese Struktur gibt Suchmaschinen ein klares Signal: Hier sind alle englischen Seiten, hier alle niederländischen, und hier die Beziehungen. Keine Mehrdeutigkeit, kein gemischtsprachiges Sitemap-Rauschen.
Content-Collection-Architektur
Content lebt in Locale-prefixed Verzeichnissen innerhalb von Astros Content Collections: `services/en/seo.mdx`, `services/nl/seo.mdx`. Jeder Eintrag trägt ein `locale`-Feld und einen `translationKey`, der Übersetzungen verknüpft. Das Schema erzwingt dies auf Type-Ebene — Sie können keinen Content-Eintrag erstellen, ohne seine Sprache zu deklarieren.
Diese Architektur bedeutet, dass Content-Abfragen immer Locale-aware sind. Der Service-Index für Niederländisch zeigt nur niederländische Einträge. Der Blog für Deutsch zeigt nur deutsche Beiträge. Es gibt kein Laufzeit-Filterraten — das Datenmodell macht versehentliches Sprachmischen unmöglich.
Schema-inLanguage-Abdeckung
Jeder JSON-LD-Schema-Block auf der Website enthält eine `inLanguage`-Eigenschaft, die zur Seiten-Locale passt. Das Organization-Schema auf `/de/` deklariert `"inLanguage": "de"`. Das Service-Schema auf `/fr/services/geo` deklariert `"inLanguage": "fr"`. Dies sagt sowohl Suchmaschinen als auch LLMs genau, zu welchem Sprachkontext jeder strukturierte Datenblock gehört.
Das Ergebnis
Vier Sprachen. Eine Domain. Null Duplicate-Content-Flags in Google Search Console. 100 % hreflang-Reziprozität, verifiziert zur Build-Zeit. Sprachspezifische Sitemaps mit korrekten Alternate-Annotationen. Schema, das weiß, welche Sprache es spricht. So sieht mehrsprachige SEO-Architektur aus, wenn sie ins Fundament eingebaut wird, statt nachträglich angeschraubt.