Internationale Website-Architektur: URL-Strukturen, die mitwachsen

Die internationale Website-Architektur bildet die Entscheidungsgrundlage für jede mehrsprachige und multiregionale SEO-Strategie. Bevor Sie Übersetzungen beauftragen, hreflang einrichten oder Kataloge nach Ländern aufteilen, brauchen Sie ein URL-Schema, das Suchmaschinen crawlen, Nutzer als Lesezeichen speichern und Ihr Team über Jahre hinweg pflegen können. Google dokumentiert mehrere URL-Optionen für unterschiedliche Sprach- und Länderversionen, doch keine davon garantiert Rankings. Der Nutzen liegt in der Klarheit: Jede Sprach- und Marktversion erhält eine eigene, auffindbare Adresse mit konsistenten Auszeichnungen.

Dieser Leitfaden verknüpft die von Google dokumentierten URL-Strukturen mit konkreten Planungsentscheidungen. Er erklärt, wann ccTLDs, Subdomains und Unterverzeichnisse sinnvoll sind, warum Parameter als primäres Mittel für Geotargeting ungeeignet sind und wie sich hreflang und Canonicals aus der Architektur ergeben – nicht umgekehrt. Die strategischen Begriffe zur Ausrichtung auf Sprachen im Vergleich zur Ausrichtung auf Länder erläutert Internationale SEO vs. mehrsprachige SEO.

Fragen, die dieser Leitfaden beantwortet

• Welche URL-Strukturen dokumentiert Google für internationale und multiregionale Websites?
• Wann sollten Teams ccTLDs, Subdomains oder Unterverzeichnisse wählen?
• Warum werden URL-Parameter nicht zur Segmentierung nach geografischen Zielgruppen empfohlen?
• Wie sollte sich die Architektur bei reiner Sprachausrichtung gegenüber einer Länderausrichtung unterscheiden?
• Wie wirken hreflang und Canonicals mit der gewählten URL-Architektur zusammen?
• Welche Sprach- und Ländersignale sind über den URL-Pfad hinaus wichtig?
• Wie sollten Teams Migrationen zwischen internationalen URL-Strukturen angehen?
• Welche Architekturfehler verhindern das Crawlen von Sprach- oder Regionalversionen?

Kurzantwort: Die Architektur folgt der Marktmatrix

Beginnen Sie mit einer Länder-Sprachen-Matrix, nicht mit einem Ordnernamen. Halten Sie für jede Zelle fest, was Nutzer im jeweiligen Markt benötigen: verständliche Inhalte in ihrer Sprache, die lokale Währung, Lieferbedingungen, rechtliche Bestimmungen oder all das zusammen. Die Matrix zeigt Ihnen, ob Sie reine Sprachpfade (/de/), reine Länderpfade (/us/), kombinierte Sprach- und Länderpfade (/en-ca/) oder separate ccTLDs (example.de) brauchen.

Google empfiehlt unterschiedliche URLs für jede Sprachversion, statt die Sprache unter einer einzigen URL über Cookies oder Browsereinstellungen zu wechseln. Ein dynamischer Wechsel verbirgt Varianten, weil der Googlebot häufig ohne Accept-Language und meist über Infrastruktur in den USA crawlt. Die Architektur ist daher in erster Linie eine Entscheidung über die Crawlbarkeit und erst danach eine Frage der Markenführung.

Sobald die Matrix feststeht, wählen Sie eine Struktur, die Ihre Entwicklungs- und Lokalisierungsteams über die nächsten Jahre betreiben können. Unterverzeichnisse auf einer gTLD sind oft die wartungsärmste Standardlösung. ccTLDs sind sinnvoll, wenn rechtliche, markenbezogene oder hostingbedingte Gegebenheiten eine strikte Trennung der Märkte erfordern. Subdomains bilden einen Mittelweg. URL-Parameter sind dokumentiert, werden zur Segmentierung nach geografischen Zielgruppen jedoch nicht empfohlen.

Von Google dokumentierte URL-Strukturen

Googles Dokumentation zu multiregionalen und mehrsprachigen Websites führt vier URL-Schemata für unterschiedliche Sprach- und Länderversionen auf. Jedes stellt eine eigene Adresse pro Version bereit – die Grundvoraussetzung für crawlbare Sprach- und Regionalvarianten.

Keines dieser Muster bestimmt allein das Ranking. Google betrachtet sie als Möglichkeiten, Sprach- und Ländervarianten zugänglich zu machen, nicht als automatische Rankingvorteile.

Die Wahl zwischen ccTLDs, Subdomains und Unterverzeichnissen

Nutzen Sie Entscheidungskriterien, die Ihr Unternehmen bei einer Überprüfung des Architekturentwurfs begründen kann:

ccTLDs senden ein starkes Ländersignal, können aber teuer sein, Einschränkungen unterliegen und sind auf ein einziges Land begrenzt. Google weist darauf hin, dass einige ccTLDs als generische Top-Level-Domains behandelt werden. Prüfen Sie daher, wie Ihre gewählte TLD eingestuft wird, bevor Sie von einer Länderausrichtung ausgehen.

Subdomains (de.example.com) ermöglichen eine flexible Trennung und können unterschiedlichen Backends zugeordnet werden. Google warnt ausdrücklich, dass Subdomain-Kürzel nicht zur Bestimmung der Zielgruppe verwendet werden, sofern Sie diese nicht explizit zuordnen – etwa mit hreflang und konsistenten Hinweisen auf den Seiten.

Unterverzeichnisse (example.com/de/) sind oft die einfachste Lösung auf einem einzigen Host und verursachen weniger laufenden Wartungsaufwand. Der Nachteil ist die Mehrdeutigkeit: /de/ könnte für deutschsprachige Inhalte weltweit, englischsprachige Inhalte für Deutschland oder deutschsprachige Inhalte für Deutschland stehen. Klären Sie die beabsichtigte Ausrichtung in der Matrix, bevor Sie sich auf Verzeichnisnamen festlegen.

Warum Parameter als primäre Geotargeting-Methode ungeeignet sind

Google dokumentiert URL-Parameter als Option für Sprach- und Ländervarianten, empfiehlt sie jedoch nicht zur Segmentierung für Geotargeting. Bei größerem Umfang verursachen Parameter vorhersehbare Probleme:

1. Doppeltes Crawling. Derselbe Pfad mit mehreren ?loc=-Werten kann Parameterkombinationen erzeugen, die Signale verwässern, sofern die Parameterbehandlung nicht sorgfältig konfiguriert ist.
2. Schwache Nutzersignale. Für Lesezeichen, das Teilen und Druckmaterialien sind stabile Pfade besser geeignet. Bei Parametern ist die Sprach- und Länderzuordnung in Analysedaten und Supporttickets weniger gut erkennbar.
3. Lücken bei der Auffindbarkeit. Interne Links, Sitemaps und hreflang-Cluster benötigen allesamt absolute URLs. Architekturen mit vielen Parametern werden häufig mit unvollständigen Sätzen alternativer URLs veröffentlicht.
4. Späterer Migrationsaufwand. Ein späterer Wechsel von ?lang=fr zu /fr/ erfordert Weiterleitungszuordnungen für jede indexierte URL-Variante.

Parameter können weiterhin für Tracking oder Ansichten für angemeldete Nutzer dienen, nicht aber für die primäre Segmentierung.

Sprachbasierte und länderbasierte Architektur im Vergleich

Rein sprachbasierte und rein länderbasierte Ansätze benötigen unterschiedliche URL-Strukturen, auch wenn sie dasselbe CMS nutzen.

Rein sprachbasiertes Targeting (mehrsprachige SEO) beantwortet die Frage: In welcher Sprache soll dieser Nutzer die Inhalte lesen? Typische Muster:

• Unterverzeichnisse /en/, /es/, /ja/
• Subdomains en.example.com, es.example.com
• Eine globale englischsprachige Website mit schrittweise ergänzten Sprachverzeichnissen

Hreflang-Werte bestehen meist nur aus Sprachcodes: hreflang="en", hreflang="es". Die Canonical-Strategie ist unkompliziert, wenn jede URL eine tatsächliche Übersetzung derselben Seite darstellt.

Länderbasiertes Targeting (multiregionale SEO) beantwortet die Frage: Welche auf den jeweiligen Markt zugeschnittene Website-Erfahrung soll dieser Nutzer erhalten? Typische Muster:

• ccTLDs pro Land (example.co.uk, example.com.au)
• Länderspezifische Subdomains oder Verzeichnisse (uk.example.com, example.com/us/)
• Kombinierte Sprach- und Länderverzeichnisse, wenn sowohl Sprache als auch Land variieren (/en-us/, /en-gb/, /fr-ca/)

Hreflang-Werte kombinieren häufig Sprache und Region: hreflang="en-US", hreflang="en-GB". Wenn dieselbe Sprache auf mehreren Länder-URLs mit nahezu identischen Inhalten vorkommt, empfiehlt Google, eine bevorzugte Version auszuwählen und rel="canonical" zusammen mit hreflang zu verwenden.

Die übergreifende Planung mehrsprachiger SEO-Programme bildet den Rahmen für diesen Leitfaden zur URL-Ebene. Dieser Artikel behandelt die Architekturentscheidungen, auf denen solche Programme aufbauen.

Hreflang und Canonicals in der Architektur

Hreflang und Canonicals ersetzen keine URL-Architektur – sie ergänzen die gewählten URLs um Hinweise. Google unterstützt Hreflang über HTML-Link-Tags, HTTP-Header oder Sitemaps; die Methoden sind gleichwertig. Jede lokalisierte URL sollte sich selbst und ihre alternativen Versionen mit vollständig qualifizierten, wechselseitigen Links aufführen. Wenn zwei Seiten nicht aufeinander verweisen, werden Hreflang-Tags möglicherweise ignoriert.

Architekturbedingte Hreflang-Regeln:

• Eine URL pro Sprach- oder Sprach-Regionsvariante im Cluster
• Absolute URLs, die mit der für Nutzer sichtbaren kanonischen Adresse übereinstimmen
• x-default für Sprachen ohne passende Zuordnung, häufig mit Verweis auf eine Sprachauswahl oder eine globale Ersatzversion
• Reine Sprachcodes (de) oder Kombinationen aus Sprache und Region (de-AT) im Einklang mit der Matrix

Zusammenspiel mit Canonicals: Geben Sie bei der Verwendung von Hreflang eine kanonische URL in derselben Sprache an. Falls keine vorhanden ist, wählen Sie die am besten geeignete verfügbare Ersatzsprache. Bei ähnlichen Inhalten in derselben Sprache auf URLs für mehrere Regionen – etwa Deutsch auf example.de und example.com/de/ – legen Sie eine bevorzugte URL fest und kombinieren Canonical mit Hreflang. So kann die Google-Suche die passende regionale URL ausspielen, ohne jedes Duplikat als unkontrollierte Wiederholung zu behandeln.

Lokalisierte Versionen gelten nur dann als problematische Duplikate, wenn der Hauptinhalt unübersetzt bleibt. Geringfügige regionale Unterschiede innerhalb einer Sprache sind ein legitimer Anwendungsfall für alternative Seitenversionen.

Dieser Artikel fasst Hreflang aus Architektursicht zusammen. Rückverweise, ungültige Regionscodes, die Abwägung zwischen Sitemap und HTML sowie die Qualitätssicherung von Clustern werden im Begleitartikel „Die technischen Abläufe von Hreflang-Clustern als eigenständigen Arbeitsbereich behandeln“ ausführlich erläutert. Lesen Sie ihn, wenn Sie vom URL-Design zur Implementierung der Annotationen übergehen.

Sprach- und Regionssignale jenseits des URL-Pfads

Die URL-Struktur ist notwendig, reicht allein aber nicht aus. Google bestimmt die sprachliche und regionale Zielausrichtung anhand mehrerer Signale:

Google ignoriert standortbezogene Meta-Tags wie geo.position beim Geotargeting. Da Geotargeting nicht exakt ist, sollten Nutzer über sichtbare Links Region oder Sprache auswählen können, wenn sie auf der falschen Version landen. Google weist außerdem darauf hin, dass die Ausrichtung auf ein bestimmtes Land die Suchergebnisse dort auf Kosten anderer Sprach- und Regionsversionen verbessern kann – eine Abwägung, kein Versprechen für höhere weltweite Sichtbarkeit.

Für die Spracherkennung gilt eine andere Regel: Google bestimmt die Sprache anhand der sichtbaren Inhalte, nicht anhand von URLs, lang-Attributen oder Hreflang. Die Architektur muss daher Seiten bereitstellen, deren Inhalte und Navigation überwiegend in einer einzigen Sprache gehalten sind.

Sitemaps und URL-Erkennung in großem Maßstab

Mit zunehmender Zahl an Sprach- und Regionsversionen werden Sitemaps neben der internen Verlinkung zu einem der wichtigsten Wege, über die URLs entdeckt werden. Sitemaps für Google können alternative Sprach- und Regionsversionen ausweisen. Das hilft Crawlern, URLs zu finden, die in der internen Navigation möglicherweise tief in facettierten Menüs verborgen liegen.

Nehmen Sie nur kanonische URLs auf, halten Sie Sitemaps bei Änderungen an den Zielmärkten aktuell und stimmen Sie die Hreflang-Einträge in der Sitemap mit den Annotationen in HTML oder HTTP-Headern ab. Wenn ccTLDs auf getrennte Konten verteilt sind, reichen Sie die Sitemaps für jede Property in der Search Console ein. Sobald die Grundlagen für URLs und Annotationen stabil sind, können strukturierte Daten je Sprach- und Regionsversion die Auffindbarkeit über reine URL-Listen hinaus erweitern.

Migrationsszenarien zwischen URL-Strukturen

Selten gelingt Teams schon beim ersten Launch die perfekte Architektur. Häufige Migrationswege sind der Wechsel vom Unterverzeichnis zur ccTLD zur rechtlichen Trennung, von Parametern zu Verzeichnissen zur Wiederherstellung der Crawlbarkeit, die Zusammenführung von Subdomains sowie die Umbenennung von Verzeichnissen. Jeder dieser Schritte erfordert eine Weiterleitungszuordnung für jede indexierte URL aller Sprach- und Regionsversionen – nicht nur für die Startseite – sowie Aktualisierungen von Hreflang und Canonicals im selben Release.

Grundsätze für die Migration: zuerst die Matrix verbindlich festlegen, direkte 301-Weiterleitungen bevorzugen, die Sprachauswahl sofort auf die neuen URLs verweisen lassen und im ersten Monat wöchentlich die wechselseitigen Verweise prüfen. Google nennt keine festen Zeiträume für die Erholung nach einer Migration. Dokumentieren Sie daher die vollständige technische Umsetzung, statt Traffic-Versprechen abzugeben.

Architekturfehler, die Sprach- und Regionsversionen verbergen

Diese Fehler verhindern das Crawling oder führen zu widersprüchlichen Sprach- und Regionssignalen:

Der kostspieligste Fehler ist, Architektur als reine Kosmetik zu behandeln: etwa übersetzte Bedienelemente auf URLs zu veröffentlichen, deren Hauptinhalt weiterhin nur in einer Sprache vorliegt, oder Länderversionen aufzuteilen, ohne die Angaben zur Bestellabwicklung auf der Seite anzupassen. Nutzer und Suchsysteme lesen gleichermaßen, was sichtbar ist.

Checkliste für die Implementierung

• Dokumentieren Sie eine Länder-Sprachen-Matrix für die nächsten 12–24 Monate
• Kennzeichnen Sie jede Zelle als rein sprachbezogen, rein länderbezogen oder kombiniert
• Wählen Sie ccTLD, Subdomain oder Unterverzeichnis – vermeiden Sie Geotargeting, das primär auf Parametern basiert
• Weisen Sie jeder Sprach- oder Länderversion eine eigene crawlbare URL zu
• Benennen Sie Verzeichnisse entsprechend der Ausrichtung in der Matrix (wählen Sie bewusst zwischen /en-us/ und /en/)
• Entwerfen Sie hreflang-Cluster mit wechselseitigen Verweisen über absolute URLs
• Definieren Sie Canonical-Regeln für gleichsprachige Inhalte, die sich über mehrere Länderversionen hinweg überschneiden
• Bieten Sie Nutzern eine Sprach- und Regionsauswahl an; deaktivieren Sie erzwungene Weiterleitungen zu Sprach- oder Länderversionen
• Lokalisieren Sie Hauptinhalte und Navigation – nicht nur wiederkehrende Standardtexte
• Veröffentlichen Sie Sitemaps mit kanonischen URLs und Alternate-Annotationen
• Prüfen Sie nach dem Start die Indexierung und die wechselseitigen hreflang-Verweise
• Planen Sie beim Einsatz von ccTLDs das Monitoring in der Search Console für jede Property ein

Crawling und Indexierung durch Suchmaschinen

Googlebot und Bing-Crawler benötigen stabile, verlinkbare Sprach- oder Länder-URLs – ob auf einer ccTLD, einer Subdomain oder in einem Unterverzeichnis. Architekturentscheidungen wirken sich auf das Crawl-Budget, Canonical-Cluster und hreflang-Zuordnungen aus. Stellen Sie Sprach- und Länderversionen als HTML bereit, das Bots ohne undurchsichtiges, rein clientseitiges Routing abrufen können. Messen Sie die Indexabdeckung pro Host oder Verzeichnis in Google Search Console und Bing Webmaster Tools.

Zugriff durch Antwortmaschinen, Quellenauswahl und mehrsprachiges Verständnis

Antwortmaschinen benötigen in der Regel dieselben erreichbaren URLs, die auch Menschen öffnen können. Ist eine Sprachversion nur hinter einer Anmeldung, über blockierte Skripte oder mit wechselnden Parametern verfügbar, eignet sie sich nur bedingt für Quellenverweise oder die Aufnahme als Quelle. Bevorzugen Sie stabile Sprach- und Länderpfade, einen klar erkennbaren Seitenzweck und sprachübergreifend konsistente Angaben zu Entitäten, damit Assistenten dieselbe Organisation auf Französisch, Deutsch oder Japanisch erkennen können. Architektur garantiert keine Quellenverweise; sie beseitigt unbeabsichtigte Hürden für den Zugriff und das Verständnis.

Als Nächstes geplant: plattformspezifische Optimierungsleitfäden für Google, Bing, ChatGPT, Claude, Gemini, Perplexity und Microsoft Copilot.

Optimierung für die Google Suche

Wählen Sie URL-Strukturen, die Google crawlen und per hreflang zuordnen kann: stabile Hosts oder Verzeichnisse, Sprachversionen in HTML und klare interne Links zwischen Sprach- und Länderversionen. Dokumentieren Sie bekannte Grenzen ausdrücklich: Erfinden Sie keine Rankingfaktoren und trennen Sie klassische Indexkennzahlen von Prüfungen auf Quellenverweise in Antwortmaschinen.

Optimierung für Bing

Stellen Sie dieselbe Crawlbarkeit auch für Bingbot sicher und prüfen Sie die Hosts und Pfade der Sprach- und Länderversionen in Bing Webmaster Tools. Dokumentieren Sie bekannte Grenzen ausdrücklich: Erfinden Sie keine Rankingfaktoren und trennen Sie klassische Indexkennzahlen von Prüfungen auf Quellenverweise in Antwortmaschinen.

Plattform-Leitfaden: ChatGPT

Assistenten benötigen erreichbare URLs für Sprach- und Länderversionen. Rein clientseitige Sprachauswahlen, die alternative HTML-Versionen verbergen, verhindern den Zugriff auf Quellen. Dokumentieren Sie bekannte Grenzen ausdrücklich: Erfinden Sie keine Rankingfaktoren und trennen Sie klassische Indexkennzahlen von Prüfungen auf Quellenverweise in Antwortmaschinen.

Plattformleitfaden: Claude

Maßgebliche lokale Dokumentation muss serverseitig erreichbar sein – eine Architektur, die Texte in Apps einschließt, erschwert Claude die Nutzung dieser Quellen. Dokumentieren Sie bekannte Grenzen ausdrücklich: Erfinden Sie keine Rankingfaktoren und trennen Sie klassische Indexkennzahlen von Prüfungen auf Quellenverweise in Antwortmaschinen.

Plattform-Leitfaden: Gemini

Eine indexierbare Architektur für Sprach- und Länderversionen bleibt die praktische Grundlage für KI-Anwendungen im Google-Ökosystem. Dokumentieren Sie bekannte Grenzen ausdrücklich: Erfinden Sie keine Rankingfaktoren und trennen Sie klassische Indexkennzahlen von Prüfungen auf Quellenverweise in Antwortmaschinen.

Plattformleitfaden: Perplexity

Stabile Sprach-URLs sorgen für beständigere Quellenverweise als rein parameterbasierte Behelfslösungen für Sprach- und Länderversionen. Dokumentieren Sie bekannte Grenzen ausdrücklich: Erfinden Sie keine Rankingfaktoren und trennen Sie klassische Indexkennzahlen von Prüfungen auf Quellenverweise in Antwortmaschinen.

Plattformleitfaden: Microsoft Copilot

Soweit die Auffindbarkeit in Copilot mit der Bing-Indexierung zusammenhängt, sollten Sie eine für Bing indexierbare mehrsprachige Architektur beibehalten – ohne Copilot-spezifische Rankingfaktoren zu erfinden. Dokumentieren Sie bekannte Grenzen ausdrücklich: Erfinden Sie keine Rankingfaktoren und trennen Sie klassische Indexkennzahlen von Prüfungen auf Quellenverweise in Antwortmaschinen.

Wie GlotEO unterstützt

Architekturentscheidungen liegen in der Verantwortung der technischen Leitung und der SEO-Leitung. Sie scheitern jedoch ohne Content-Workflows, die jede Sprach- und Länder-URL mit den übersetzten Seiten, Annotationen und Checklisten zur Qualitätssicherung im Einklang halten. Die mehrsprachige SEO-Lösung von GlotEO unterstützt diese redaktionelle Ebene bei mehrsprachigen und internationalen Vorhaben. Sie hilft Teams, crawlbare Sprachversionen mit den gewählten URL-Strukturen zu veröffentlichen, ohne die oben beschriebenen Arbeiten an Matrix und Migration zu ersetzen.

Planen Sie für die laufende Erfolgsmessung die Aufteilung der Search-Console-Properties, hreflang-Berichte und Prüfungen der Indexabdeckung über alle Sprach- und Länderversionen hinweg. Der umfangreiche Einsatz strukturierter Daten kann folgen, sobald die Grundlagen stabil sind.

Teams, die redaktionelle Kontrolle über alle Sprach- und Länderversionen benötigen, können die mehrsprachige SEO-Plattform von GlotEO nutzen und anschließend Preise und Tarife von GlotEO vergleichen.