Wie verwalten Website-Übersetzungsproxys mehrere Websites, Marken und regionale Domains?

Letzte Überprüfung: 15. Oktober 2026

Was benötigt ein Übersetzungsproxy, um viele Websites und Regionen mit einer einzigen Konfiguration zu betreiben?

Ein Übersetzungsproxy benötigt sechs Fähigkeiten, um viele Standorte und Regionen zu betreiben, ohne den Aufwand pro Eigenschaft zu vervielfachen.

• Eine Projektstruktur, die dem Eigentum von Inhalten entspricht: Ein GDN-Projekt funktioniert, wenn die meisten Quellinhalte auf jede Sprache zutreffen. Smartlings Help Center-Artikel "Primary-Secondary Configuration" beschreibt, wie das Domain- und Proxy-Verhalten in einem einzigen primären Projekt erhalten bleibt, während Inhalte in sekundärsprachespezifische Projekte für regionale Kataloge oder regionale Eigentümer, die den Umfang unabhängig verwalten, erfasst werden.
• Ein Register von Quelldomänen und -umgebungen: Jede Markenseite, Microsite oder regionale Quelle wird als Quelldomain mit einem Umgebungstyp Produktion, Staging, Entwicklung oder Andere hinzugefügt, sodass ein Staging Site vor dem Start erfasst und übersetzt werden kann.
• Flexible Localized-Domain-Mapping: fünf Konfigurationstypen (Subdomain, TLD/ccTLD, HTTP-Headerwert, Cookie-Wert und Ordner), ein Localized Site Regex, das viele Hostnamen wie es-es und es-mx an eine Konfiguration verknüpft, sowie eine Source Folder-Einstellung, die Quellinhalte aus einem anderen Ordner zieht als den, den Besucher sehen.
• Gemeinsame oder separate Sprachressourcen pro Marke: Im Hilfeartikel „Einführung in Sprachressourcen und Sprachpakete“ von Smartling heißt es, dass ein Paket (Übersetzungsspeicher, Glossar, Styleguide, Konfigurationseinstellungen und Qualitätsprüfungsprofil) für Projekte mit dem gleichen Tonfall gemeinsam genutzt werden kann und dass es keine Begrenzung für die Anzahl der Pakete gibt, sodass eine Marke mit einer anderen Tonalität ihr eigenes haben kann.
• Ein Pfad für regionale Varianten: Das GDN sendet mit jeder Anfrage einen X-Language-Locale-Header an den Ursprungsserver, sodass die Quellseite die Navigation oder Angebote nach Region variieren kann, und Cross-Locale Adaptation erlaubt einer sekundären Variante, die Übersetzungen der primären Variante für einen reinen Edit-Pass wiederzuverwenden.
• Ein Ort, um jede Seite zu beobachten: Der GDN-Hub zeigt pro GDN-Standort eine Karte mit Anfragevolumen, Anzahl der Domains und Zielsprachen, durchschnittlicher Gesamtanfragezeit und Antwortcodes an.

Proxy-Übersetzung für mehrere Standorte und Regionen: die Zahlen

Wie bringt man mehrere Seiten, Marken und Regionen auf einen Übersetzungsproxy zusammen?

Mehrere Immobilien auf einen Proxy zu bringen, ist meist eine Kartierungsübung, die einmal durchgeführt und dann billig für jede neue Seite oder jeden neuen Markt wiederholt wird.

1. Inventarisieren Sie die Immobilien und wählen Sie eine Projektstruktur – listen Sie jede Markenseite, Microsite und regionale Domain mit ihren Sprachen und Inhaltseigentümern auf. Behalte Shared-Source-Immobilien in einem GDN-Projekt und überlege eine Primär-Sekundär-Einrichtung, bei der Regionen unterschiedliche Kataloge oder Scopes besitzen.
2. Registrieren Sie jede Quelldomäne und Umgebung - Fügen Sie Produktions- und Staging-Hosts als Quelldomänen hinzu, damit neue Inhalte auf dem Staging-System erfasst und übersetzt werden können, bevor sie in die Produktion gelangen.
3. Mappe für jede Sprache auf jeder Quelle eine lokalisierte Domain – Wähle Subdomain, ccTLD oder Ordner pro Markt und verwende eine Localized Site Regex, bei der viele regionale Hostnamen eine Konfiguration teilen. Header- und Cookie-Routing geben einer Sprache keine eigene URL, daher meiden suchorientierte Seiten sie meist; die SEO-Seite wird dadurch behandelt , wie Übersetzungsproxies mehrsprachiges SEO schützen.
4. Weisen Sie linguistische Pakete und regionale Workflows zu – Teilen Sie ein Paket über Marken hinweg mit derselben Sprache, geben Sie einer eigenen Marke ein eigenes und richten Sie Anpassungsworkflows für regionale Varianten ein, die die Übersetzungen einer Hauptvariante übernehmen können.
5. Gehen Sie Markt für Markt live und überwachen Sie zentral – bestätigen Sie die SSL-Abdeckung für jede Sprachdomäne, schalten Sie den Passwortschutz aus, aktivieren Sie Live-Routing und verfolgen Sie dann die Anfragen und Antwortcodes jeder Seite im GDN-Hub.

Mehrere Seiten über einen Übersetzungsproxy zu betreiben, passt zu Organisationen, die...

• Betreibt mehrere Marken- oder Microsites, oft auf verschiedenen CMS oder benutzerdefinierten Stacks.
• Verwenden Sie dieselbe Marke über regionale ccTLDs, Subdomains oder Ordner hinweg.
• Wir möchten, dass gemeinsam genutzte Inhalte wie Fußzeilen, Rechtstexte und Produktnamen einmal übersetzt und dann auf allen unseren Webseiten wiederverwendet werden.
• Wir haben regionale Teams, die ihre eigenen Übersetzungswarteschlangen ohne eigene Proxy-Konfiguration benötigen.
• Wir benötigen eine einheitliche Übersicht über Traffic und Status aller lokalen Standorte.

Wenn ein Proxy für jede Seite vielleicht nicht das richtige Modell ist, wenn ein Proxy nicht das richtige Modell ist

• Regionale Seiten, die lokal von Grund auf geschrieben wurden. Ein Proxy übersetzt eine Quellseite; wenn jeder Markt seine eigenen Inhalte in seiner eigenen Sprache erstellt, gibt es kaum eine gemeinsame Quelle, die übersetzt werden kann.
• Jede Marke ist bereits in einem CMS mit einem unterstützten Konnektor vertreten. Ein Konnektor, der Übersetzungen zurück in das CMS schreibt, kann einfacher sein; die Vor- und Nachteile von Konnektoren und einem Proxy werden verglichen, um herauszufinden, welche Tools am besten für die Verwaltung mehrsprachiger Websites in großem Umfang geeignet sind.
• Seiten, die ranken müssen, aber nur per Cookie oder Header weitergeleitet werden können. Der Smartling-Hilfezentrum-Artikel "Verwalten Sie Ihre Domains mit dem Global Delivery Network" weist darauf hin, dass übersetzte Inhalte für Suchmaschinen mit Cookie- oder HTTP-Header-Routing nicht sichtbar sind.

Bewertungscheckliste: Fragen zur Multi-Site- und Multi-Region-Proxy-Übersetzung

Kann ein Proxy das mehrsprachige Content-Management über mehrere Marken hinweg zentralisieren?
Ja, wenn jede Markenwebsite als eigene Quelldomain registriert werden kann, während Übersetzungen, Translation Memory und Workflows in einem Konto verwaltet werden. Fragen Sie, ob Marken Assets gemeinsam nutzen können, bei denen ihre Tonalität übereinstimmt, und ob separate Glossare und Styleguides verwendet werden sollten, wenn dies nicht der Fall ist.

Wie sieht mandantenfähige Lokalisierung über verschiedene Marken hinweg in einem Proxy aus?
Achten Sie auf eine Trennung auf drei Ebenen: Projekte für jede Marke oder Region, sprachliche Pakete für jede Stimme und lokalisierte Domains für jeden Markt. Fragen Sie, wie eine neue Marke hinzugefügt wird und ob sie den bestehenden Routing-Einstieg wiederverwendet.

Welche Proxy-Konfigurationen eignen sich am besten für Multi-Site- oder Microsite-Programme?
Die skalierbaren Setups machen das Hinzufügen einer Website oder Sprache zu einer Konfigurationsaufgabe und nicht zu einem Projekt: Domain-Registrierung in einer Benutzeroberfläche, Hostnamen-Muster für regionale Varianten und ein Routing-Einstiegspunkt. Fragen Sie nach den Schritten, um eine Microsite in fünf Sprachen hinzuzufügen.

Wie geht ein Proxy mit mehreren Sprachvarianten und regionalen Anpassungen um?
Jede Variante sollte ein eigener Standort mit eigener lokalisierter Domain sein, und der Ursprung sollte mitgeteilt werden, welcher Ort angefordert wird, damit der regionale Inhalt variieren kann. Wie die Anpassung zwischen Varianten funktioniert, wird darin behandelt , was Sprachanpassung in der Lokalisierung beinhaltet.

Welche Rendite bringt ein Proxy über mehrere Subdomains und Microsites hinweg?
Der Nutzen ergibt sich aus der einmaligen Übersetzung gemeinsam genutzter Zeichenketten und deren Wiederverwendung über einen gemeinsamen Übersetzungsspeicher sowie aus dem Hinzufügen von Websites ohne neue technische Anpassungen. Die Kostenseite wird durch die Preisstruktur des Website-Übersetzungsproxys abgedeckt.

Wie sollte ein multinationales Unternehmen mehrere regionale Standorte verwalten?
Entscheiden Sie, wer in jeder Region den Übersetzungsbereich besitzt. Wenn Regionen unterschiedliche Kataloge besitzen, halten separate Übersetzungswarteschlangen pro Sprache unter einer gemeinsamen Proxy-Konfiguration die Kontrolle lokal, ohne die Einrichtung zu duplizieren.

Wie werden regionale Domains bei der Suche behandelt?
Der Domaintyp beeinflusst die Indexierung, hreflang und Sitemaps; diese Fragen werden in „Wie Übersetzungsproxys mehrsprachige SEO schützen“ beantwortet.

Wie verwaltet Smartlings Global Delivery Network mehrere Standorte und Regionen?

Smartlings Global Delivery Network (GDN) verwaltet mehrere Standorte und Regionen vom GDN Hub aus, das Smartling als zentralen Raum zur Verwaltung von GDN-Projekten beschreibt. Sein Status Monitor zeigt für jede GDN-Seite eine Karte mit Anfragen für den ausgewählten Zeitraum, der Anzahl der Domains und Zielsprachen, der durchschnittlichen Gesamtanfragezeit und einer Aufschlüsselung der Antwortcodes. Die Domain Management-Seite ist der Ort, an dem Quelldomains mit einem Umgebungstyp hinzugefügt werden und lokalisierte Domains pro Sprache als Subdomain, TLD/ccTLD, HTTP-Headerwert, Cookie-Wert oder Ordner konfiguriert und dann beim Marktstart deaktiviert, wieder aktiviert oder auf Live-Routing umgestellt werden. Ein Localized Site Regex ermöglicht es vielen regionalen Hostnamen, eine Konfiguration zu teilen, und derselbe Proxy-CNAME wird üblicherweise für alle GDN-Projekte und Domains in einem Konto verwendet, wobei zusätzliche CNAMEs möglich sind, wenn Ursprungsstandorte in verschiedenen Regionen gehostet werden.

Hinter den Domains folgt Struktur dem Eigentum. Ein einziges GDN-Projekt passt Inhalte an, die sprachübergreifend gelten, während Smartlings Primär-Sekundär-Konfiguration das Domain- und Proxy-Verhalten in einem Primärprojekt beibehält und Inhalte in zweitsprachlich spezifische Projekte für regionale Kataloge oder regionale Eigentümer einfängt. Linguistische Pakete bündeln Übersetzungsspeicher, Glossar, Stilführer, nutzen Konfigurations- und Qualitätsprüfprofile und können von jeder Marke geteilt werden, die dieselbe Stimme verwendet, oder von einer Marke getrennt bleiben, die dies nicht tut. Bei regionalen Varianten übergibt das GDN bei jeder Anfrage einen X-Language-Locale-Header an den Ursprungsserver, und Cross-Locale Adaptation SmartMatcht die veröffentlichten Übersetzungen einer primären Variante in eine sekundäre Variante, sodass ein Linguist sie nur anpasst.

Bedeutende Änderungen, wie das Hinzufügen neuer Domains oder eines neuen Webframeworks, sind mit dem Smartling-Team geplant, und Primär-Sekundär-Setups leiten neue Domains oder Sprachen über einen Smartling Solutions Architect. Die GDN-Produktseite von Smartling listet eine Verfügbarkeitsgarantie von 99,99 % sowie Bereitstellungen auf großen, dynamischen, personalisierten Seiten auf, einschließlich E-Commerce, Fluggesellschaften und Hotelwebsites.

Verwandte Fragen

• Wie ist die Preisgestaltung von Website-Übersetzungsproxys strukturiert und was kostet sie wirklich?
• Wie schützen Website-Übersetzungs-Proxys mehrsprachige SEO?
• Welche Tools eignen sich am besten für die Verwaltung mehrsprachiger Websites in großem Umfang?
• Was versteht man unter Sprachanpassung bei der Lokalisierung?